Discussions

News: Mustang (1.6) versus Tiger (1.5) Performance Comparison

  1. The first benchmark of Mustang (JDK1.6) versus Tiger (JDK1.5) shows that Java users are up for an agreable surprise. According to this JavaLobby discussion the virtual machine raw speed has improved significantly (40-100%). Although, the core library implementation (e.g. collections) could also benefit from some rework/optimizations.

    Threaded Messages (46)

  2. Seems kind of thin[ Go to top ]

    I'm not so sure about these benchmarks. One of the really interesting improvements in 1.6 is stack allocation of Objects. In order for this to occur, you cannot let the Object reference escape the stack. Do these benchmarks use proper scoping in order to take advantage of that?
  3. Re:Seems kind of thin[ Go to top ]

    Javolution benchmarks were written to compare Javolution classes (http://javolution.org) versus JDK classes. The interesting thing about the results is that JDK and Javolution do see a significant boost in performance (even more so for Javolution).
    Javolution classes being "all-purpose" (e.g. Text) and some quite complex (e.g. xml marshalling/unmarshalling), to see an increase of more than 40% on those (with no code change), is a good omen for users which are likely to see similar performance gain in their application code as well.
  4. Re:Seems kind of thin[ Go to top ]

    Javolution benchmarks were written to compare Javolution classes (http://javolution.org) versus JDK classes. The interesting thing about the results is that JDK and Javolution do see a significant boost in performance (even more so for Javolution).
    Javolution classes being "all-purpose" (e.g. Text) and some quite complex (e.g. xml marshalling/unmarshalling), to see an increase of more than 40% on those (with no code change), is a good omen for users who are likely to see similar performance gains in their application code as well.
  5. Stack allocation[ Go to top ]

    By the way stack allocation was implemented along time ago in Microsoft JVM. Nice to hear that Sun finally have implemented it.
  6. Stack allocation[ Go to top ]

    Yeah. Actually, I suggested this optimization and a number of others that have come to pass while I was working on Visual J++ in 1996. Not that I was the only person to think of it or anything... that particular thing has always seemed obvious.
  7. Stack allocation[ Go to top ]

    Stack allocation is NOT implemented in Mustang. See the post: http://forums.java.net/jive/thread.jspa?forumID=25&threadID=2664&messageID=37562#37562
  8. Stack allocation[ Go to top ]

    Yes. My suggestion was to Microsoft at that time, not Sun.
  9. Stack allocation[ Go to top ]

    By the way stack allocation was implemented along time ago in Microsoft JVM. Nice to hear that Sun finally have implemented it.

    Actually the "stack" allocation mentioned in the benchmark is Javolution specific (thread-local object recycling). It is my understanding that VM stack allocation (for objects) will not be available until Dolphin (1.7).
  10. Not quite[ Go to top ]

    In C# you have to tell the compiler its that sort of "struct" rather then a class. So you have to make the explicit decision. I am not sure about .Net 2.0 though.. may have improved.
    Its a MASSIVE jump to make it automatic, and is in the spirit of a modern VM.
  11. java should be faster than c++ then?[ Go to top ]

    well. If every jdk release increases the speed by 40-100% then java should be faster thatn C++ ?! :-)
  12. java should be faster than c++ then?[ Go to top ]

    well. If every jdk release increases the speed by 40-100% then java should be faster thatn C++ ?! :-)

    Well, I measured the one JVM as being faster than gcc on Linux for some numerical algorithms a couple of years ago.
  13. java should be faster than c++ then?[ Go to top ]

    Well, I measured the one JVM as being faster than gcc on Linux for some numerical algorithms a couple of years ago.

    Yeah right. There's been lots of measurements for lots of things. We all know that proper C++ template code will still spank the shit out of Java code.

    But of course we also know that the commercial 3d engine programmers are loving the benefits of Java. heh.

    Can we ask Carmack or Sweeney why they still won't be using Java for their next engines?
  14. Can we ask Carmack or Sweeney why they still won't be using Java for their next engines?

    Yeah, Sweeney is looking at Haskell:

    http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf

    (Credit Cedric Beust for the link)

    http://beust.com/weblog/archives/000375.html
  15. java should be faster than c++ then?[ Go to top ]

    Well, I measured the one JVM as being faster than gcc on Linux for some numerical algorithms a couple of years ago.
    Yeah right. There's been lots of measurements for lots of things.

    I take measurement seriously, as I have a background in computational chemistry, where the performance of numerical algorithms is important.

    Java performance is much misunderstood. One of the worst examples of benchmarks I have seen was a site that compared Java and C++, but only allowed each program a few hundred milliseconds to run. This meant that not only did the benchmark include the JVM startup time, but there was little change for Hotspot to kick in. By increasing the run time tenfold, I was able to get Java matching C++ performance.

    I would be happy to use Java in place of C++ or even in place of Fortran for numerical work (if I ever get the chance to get back to research).
  16. I'm waiting they will use better spec. in the implemention of the Floating point variables, It's a disaster...
  17. java should be faster than c++ then?[ Go to top ]

    Well, I measured the one JVM as being faster than gcc on Linux for some numerical algorithms a couple of years ago.
    Yeah right. There's been lots of measurements for lots of things. We all know that proper C++ template code will still spank the shit out of Java code.But of course we also know that the commercial 3d engine programmers are loving the benefits of Java. heh. Can we ask Carmack or Sweeney why they still won't be using Java for their next engines?

    Well, first, Steve doesn't have any reason to lie, so how about considering your implication? Second, to my knowledge, there aren't any Java based libraries for things like DirectX, so that alone would prevent Tim Sweeney from considering Java, I'll bet. I mean, since DirectX doesn't work on anything but Windows, the question wouldn't even come up. Ditto for device drivers for video cards, right?
  18. Second, to my knowledge, there aren't any Java based libraries for things like DirectX, so that alone would prevent Tim Sweeney from considering Java, I'll bet. I mean, since DirectX doesn't work on anything but Windows, the question wouldn't even come up. Ditto for device drivers for video cards, right?

    To be fair, I could never see Java becoming the language of choice of games developers. It's just too slow for the type of 3D FPS stuff that is the most popular genre. Sure, theoretically it's fast enough, but empirically it would seem that it isn't. Of course, Java is far better suited to building lots of other application types that C++ fares more poorly with.
  19. To be fair, I could never see Java becoming the language of choice of games developers. It's just too slow for the type of 3D FPS stuff that is the most popular genre. Sure, theoretically it's fast enough, but empirically it would seem that it isn't. Of course, Java is far better suited to building lots of other application types that C++ fares more poorly with.

    I beg to differ. I could easily see Java eventually becoming the language of choice. Games are frequently (not always) limited not by the CPU, but the GPU. With the performance improvements that seem to come out with each release of Java, and the ever faster processors coming out, I can envision a day where Java would be more than up to the task. Garbage collection would be the biggest concern as you could occasionally have a drop in FPS unless you configured the JVM correctly.

    Plus, with more multi-core processors coming out, the JVM can easily use those extra cores, even if the program wasn't originally designed to run on 2, 4, 8, etc. cores. You cant get those benefits with a C++ program unless you design with that in mind from the beginning.

    Take a look at the new chips for XBox 360 and the PS3. Both have 3 cores. Both Microsoft and Sony admitted that games from their current consoles might run WORSE on these machines because they aren't designed with multiple cores in mind. The games need to be rewritten to take full advantage of the chip. Java wouldn't have that problem.

    Think of some of the things that want to do with those cores. One is your central cooridator, another can drive a physics engine, the last drives the GPU. Java would give each thread its own core. Have additional threads (network, I/O)? They'll share time for now. But when a 6 core chip comes out, they dont need to. Do you have to rewrite your code again? With C/++, maybe.

    The biggest barrier to Java becoming a gaming language is the investment of the companies in their current code. Businesses are hesitant to switch languages, and given the complexity of code in games nowadays, I cant see someone like EA Games suddenly switching to all Java. I think you'll see new companies who are starting from scratch make the leap before John Carmack.

    Will it happen tomorrow? Doubt it. But I wouldn't use the word "never".
  20. Games in Java? Take a look at this: http://www.lwjgl.org/projects.php

    One that should be highlighted in that list is TribalTrouble, which won a prize for best (RTS?) game somewhere on the internet I can't remember right now...

    Regarding lack of drivers or such, there's OpenGL, so one shouldn't be tied to windows/directX. Of course in any case it involves JNI calls to native graphic libraries, but the rest is pure java.

    I can't say for sure, but it's probable some fancy games will be done in java in the future.
  21. java should be faster than c++ then?[ Go to top ]

    well. If every jdk release increases the speed by 40-100% then java should be faster thatn C++ ?! :-)
    Well, I measured the one JVM as being faster than gcc on Linux for some numerical algorithms a couple of years ago.

    How can that be technically true?

    There must have been something wrong with the C++ code that slowed it down, giving the impression that Java was faster.

    In many areas, Java can be almost (not never exactly) as fast as C++. In other areas, involving memory management for example, it just can not be as fast.



    PJ Murray, CodeFutures Software
    >Data Access Objects and Service Data Objects
  22. Of course it can be true depending on what you are doing. Obviously both languages end up in the CPU as machnine code so its all about available compile time and runtime optimizations and how cleverly they are applied. A couple advantages for Java include the fact that it can continue to optimize as it runs the code and have the advantage of seeing how the code is actually being used (run time) instead of speculating (compile time) and the fact that the JVM functions that implement the byte code can be optimized by the JVM implementor. Implementors can hand tweak machine code if they like. How often do C++ programmers do that? (And then it wouldn't be C++ programming anymore would it?)

    The question that matters the most is how efficient the code is given the time and skill it takes to write and maintain the code. Obviously you can make assembler or machine code that is more efficient than any higher level language. We don't do much of that anymore because its not worth it. How many really really good C++ programmers are there and how many of that tiny number have the luxury of time necessary to fully optimize their code? And then there is the debugging problem. C++ bugs can be far more insidious and dangerous than a Java (or .NET or Pascal) bug. Its all about the tradeoffs.
  23. In many areas, Java can be almost (not never exactly) as fast as C++.

    I'm not a compiler guru, but this is basically the opposite of what I've been told over the years... As another poster mentions above:
    [The JVM] can continue to optimize as it runs the code and has the advantage of seeing how the code is actually being used (run time) instead of speculating (compile time).

    Anyone that knows their stuff care to comment?
  24. java should be faster than c++ then?[ Go to top ]

    Well, I measured the one JVM as being faster than gcc on Linux for some numerical algorithms a couple of years ago.
    How can that be technically true?There must have been something wrong with the C++ code that slowed it down, giving the impression that Java was faster.

    Why? It is well established that different compilers can produce different qualities of machine code. Different C++ compilers can give different results on the same machine. There is no reason why a quality run-time optimiser for Java should result in better machine code than that produced by a C++ implementation.
    In many areas, Java can be almost (not never exactly) as fast as C++.

    There is no technical reason why not. High performance optimising C++ compilers and high-performance Java hotspot optimisers should both produce reasonably optimal machine code.
    In other areas, involving memory management for example, it just can not be as fast.

    Of course it can. Memory management by garbage collection is a very well-established and well-studied approach, and there is no reason why garbage collection should not be as fast as manual malloc/free.
  25. Of course it can. Memory management by garbage collection is a very well-established and well-studied approach, and there is no reason why garbage collection should not be as fast as manual malloc/free.

    Malloc/free are really kind of crappy and in many cases, especially for applications with long process lifetimes (this IS "the server side") where heap fragmentation can take place.

    C++ is really designed for the memory management layer to be treated as just another layer that the programmer is free to customize directly or through libraries.

    If you know exactly how your code works, how it will be used, and are really smart about memory allocation, you probably can write an allocator that's faster than the GC in Java. In fact, once that layers is written, it may even provide significantly safer memory allocation than the Java GC.

    If you're persistent, you probably can come up with a microbenchmark that says Python has the fastest memory allocation.

    But for the rest of us, GC is pretty good.
  26. I would agree for C++ experts[ Go to top ]

    Of course it can. Memory management by garbage collection is a very well-established and well-studied approach, and there is no reason why garbage collection should not be as fast as manual malloc/free.

    Malloc/free are really kind of crappy and in many cases, especially for applications with long process lifetimes (this IS "the server side") where heap fragmentation can take place.C++ is really designed for the memory management layer to be treated as just another layer that the programmer is free to customize directly or through libraries.

    If you know exactly how your code works, how it will be used, and are really smart about memory allocation, you probably can write an allocator that's faster than the GC in Java. In fact, once that layers is written, it may even provide significantly safer memory allocation than the Java GC.

    If you're persistent, you probably can come up with a microbenchmark that says Python has the fastest memory allocation.But for the rest of us, GC is pretty good.

    I think the statement is accurate, but only for top notch C++ developers with several years of serverside experience. I've met plenty of C++ developers who suck and couldn't optimize memory allocation and GC to save their life. I don't have any hard numbers or reliable statistics, but in my short 8 years of programming, I've only met a handful of guys who were that good.

    Even for guys who are experts at writing high performance/high availability serverside apps in C++, it takes a lot of time. In some cases, it takes years. Writing high performance apps is no easier in Java though and in cases where a developer has the skills to optimize at the low level, java becomes a barrier.

    If some had the C++ skills, they would be crazy to go with Java. But it's hardly that simple. What happens when that guy leaves for another job, how can the company extend the application? If they can't find someone with equal experience, chances are the application might become totally unstable. I couldn't code C++ worth a lick, but I atleast have a tiny clue about how hard it is.

    for someone who is a guru, I'm sure it's a piece of cake. my 2 bits of noise

    peter
  27. I would agree for C++ experts[ Go to top ]

    Writing high performance apps is no easier in Java though and in cases where a developer has the skills to optimize at the low level, java becomes a barrier.

    If some had the C++ skills, they would be crazy to go with Java.


    Then I am crazy! I agree that writing high performance apps isn't easy in Java - it isn't easy in any language. But, there are standard approaches ("write all your code as if you are using old-fashioned FORTRAN" is pretty effective for numerical work in both C++ and Java!).

    An issue I have come across is that C++ developers not used to Java do indeed come across a barrier - they can't fiddle with low level things in a way that they are used to in attempt to optimise code. The question is, do they need to? For example, there is no need to inline methods yourself when the JVM will do this for you as needed.

    But anyway, I was very glad to give up the horrors of C++. Even if Java was marginally slower, the benefits of code safety more than made up for things.
  28. I would agree for C++ experts[ Go to top ]

    Writing high performance apps is no easier in Java though and in cases where a developer has the skills to optimize at the low level, java becomes a barrier.If some had the C++ skills, they would be crazy to go with Java.

    Then I am crazy! I agree that writing high performance apps isn't easy in Java - it isn't easy in any language. But, there are standard approaches ("write all your code as if you are using old-fashioned FORTRAN" is pretty effective for numerical work in both C++ and Java!). An issue I have come across is that C++ developers not used to Java do indeed come across a barrier - they can't fiddle with low level things in a way that they are used to in attempt to optimise code. The question is, do they need to?

    For example, there is no need to inline methods yourself when the JVM will do this for you as needed.But anyway, I was very glad to give up the horrors of C++. Even if Java was marginally slower, the benefits of code safety more than made up for things.

    nah, you're not crazy. I was thinking of a very specific case where the server needs to load 5Gb+ of data into memory and execute queries within 50ms. Doing that in Java in this specific case could be pain for very painful. Considering 32bit JVM can't do it and I don't know 64bit JVM, C++ feels like a "better" solution for the case I'm thinking of.

    For serverside apps that don't need it, I agree there may not be any benefit or real gain in performance or productivity.

    peter
  29. I would agree for C++ experts[ Go to top ]

    The JVMs I tested all had significantly larger response times due to the garbage collection. With a 5GB heap I would expect a dropout for at least (probably much more) 1 second when a full garbage collection runs. This depends on the number of objects. The GC algorithm is O(N^2) where N is the number of objects.

    The new BEA JVM claims to be real time and might have shorter drop outs. Has anybody experience with this JVM?

    For those who don't belive. Simply fill an ArrayList with Objects until you get an out of memory error. And then look the garbage collection times. I never managed to go below 500ms for a 500MB heap full of objects.
  30. I would agree for C++ experts[ Go to top ]

    The JVMs I tested all had significantly larger response times due to the garbage collection. With a 5GB heap I would expect a dropout for at least (probably much more) 1 second when a full garbage collection runs.

    Without tuning, it's easy to get a 30 second GC with just a 1GB heap. We recently had a customer show us a log with three back-to-back full GCs, total time over 240000ms (4 minutes).

    What a nightmare!

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  31. I would agree for C++ experts[ Go to top ]

    I was thinking of a very specific case where the server needs to load 5Gb+ of data into memory and execute queries within 50ms. Doing that in Java in this specific case could be pain for very painful. Considering 32bit JVM can't do it and I don't know 64bit JVM, C++ feels like a "better" solution for the case I'm thinking of.

    With Java, you can do that with a response time pretty much guaranteed under 25ms, even using 32-bit JVMs; here's how we do it with Coherence: Just partition the data across a number of servers, run the query in parallel across the servers, and limit the GC to 15ms using the jRockit real time features.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  32. I would agree for C++ experts[ Go to top ]

    I was thinking of a very specific case where the server needs to load 5Gb+ of data into memory and execute queries within 50ms. Doing that in Java in this specific case could be pain for very painful. Considering 32bit JVM can't do it and I don't know 64bit JVM, C++ feels like a "better" solution for the case I'm thinking of.

    With Java, you can do that with a response time pretty much guaranteed under 25ms, even using 32-bit JVMs; here's how we do it with Coherence: Just partition the data across a number of servers, run the query in parallel across the servers, and limit the GC to 15ms using the jRockit real time features.Peace,Cameron PurdyTangosol Coherence: Clustered Shared Memory for Java

    Yeah, one definitely could use coherence for that :) I was thinking of cases where someone couldn't use coherence, gigaspaces or other existing commercial solutions that are proven. Usually due to non-technical political causes.

    Coherence proves the same problem can be solve with different techniques. Makes me wonder how "hard" it would be for a C++ guru to duplicate coherence performance. Since I know close to nothing about writing high performance C++ server apps, maybe someone with the experience can give their opinion.

    peter
  33. I would agree for C++ experts[ Go to top ]

    Coherence proves the same problem can be solve with different techniques. Makes me wonder how "hard" it would be for a C++ guru to duplicate coherence performance. Since I know close to nothing about writing high performance C++ server apps, maybe someone with the experience can give their opinion.

    Really, you have to break it down into two questions:
    1. How hard would it be to duplicate the performance provided by Coherence in C++?
    2. How hard would it be to duplicate the level of abstraction provided by Coherence in C++?

    I think the challenge is in #2. Much of it comes from the fact that C++ doesn't have (at least to my knowledge) any sort of standardized serialization mechanism or reflection API. Consequently, you either have to (1) make the programmer define a function to serialize each class, or (2) use some sort of source processor or precompiler to automatically generate the serialization code and/or the class metadata required to perform serialization.

    Once that's done, assuming you don't have to deal with any libraries that consume and hold raw pointers or references, you can perform all your object access through smart pointers or handles that can abstract away just about everything about the physical location of the object.

    Unfortunately I don't think the assumption about libraries holds very often. There's always some library that wants raw pointers or references, and consequently abstraction ends up being reduced to the lowest common denominator. Either that or the libraries must be laboriously wrapped in friendlier code.
  34. Interesting[ Go to top ]

    thanks for playing along, since I had no clue.
    Coherence proves the same problem can be solve with different techniques. Makes me wonder how "hard" it would be for a C++ guru to duplicate coherence performance. Since I know close to nothing about writing high performance C++ server apps, maybe someone with the experience can give their opinion.

    Really, you have to break it down into two questions:
    1. How hard would it be to duplicate the performance provided by Coherence in C++?
    2. How hard would it be to duplicate the level of abstraction provided by Coherence in C++?

    I think the challenge is in #2. Much of it comes from the fact that C++ doesn't have (at least to my knowledge) any sort of standardized serialization mechanism or reflection API. Consequently, you either have to (1) make the programmer define a function to serialize each class, or (2) use some sort of source processor or precompiler to automatically generate the serialization code and/or the class metadata required to perform serialization.

    Once that's done, assuming you don't have to deal with any libraries that consume and hold raw pointers or references, you can perform all your object access through smart pointers or handles that can abstract away just about everything about the physical location of the object.

    Unfortunately I don't think the assumption about libraries holds very often. There's always some library that wants raw pointers or references, and consequently abstraction ends up being reduced to the lowest common denominator. Either that or the libraries must be laboriously wrapped in friendlier code.

    From your description, it sounds like even though C++ provides lower level access, discipline becomes a bigger issue. Since Java doesn't allow pointer manipulation, there's built-in gaurantee some library won't do "funky" stuff. Whereas in C++, there's a high degree something "un-expected" might go bump.

    From my knowledge of how ART rule engine handled memory management, their approach was to laboriously wrap stuff. I've also worked with an application built in C++ that loads 8-10Gb of data into memory using a single process. In the C++ case, the data changes monthly, so it didn't do all the fancy real-time stuff that coherence or gigaspaces does out of the box.

    In a real world situation, if given a choice of hiring a few C++ experts to write a home grown app or using an existing data grid product like coherence, have to say I'd choose coherence. Chances are, unless I already know guys with the exact skills, it would take me months or even a year to find the right developers.

    peter
  35. I would agree for C++ experts[ Go to top ]

    Coherence proves the same problem can be solve with different techniques. Makes me wonder how "hard" it would be for a C++ guru to duplicate coherence performance. Since I know close to nothing about writing high performance C++ server apps, maybe someone with the experience can give their opinion.

    If the data were only relational, I'd say that you'd have a shot of doing it with C++, since the type domain is easily countable.

    However, the type domain is limitless, because the types are user types, and in addition to being composed of data, the types are composed of logic. Erik is spot on with his comment -- the hard part is duplicating the immense amount of capability that Java provides "out of the box". You really wouldn't want to do it in C++ ;-)

    As far as performance goes, I can guarantee that I could do it more performantly in C++, for several low-level technical reasons, all of which are irrelevant to the discussion. However, it would be extremely difficult to implement that much functionality in C++ with the level of quality (e.g. Continuous Availability) that we've achieved using Java. (And having written hundreds of thousands of lines of C++ code, including an in-memory relational engine, I unfortunately have some idea. ;-)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  36. I would agree for C++ experts[ Go to top ]

    thanks for the detailed response :)

    Once I finish my rule engine, I'm gonna have to hook it up to coherence and try it out on a few systems.

    peter
  37. Malloc/free are really kind of crappy and in many cases, especially for applications with long process lifetimes (this IS "the server side") where heap fragmentation can take place.

    Having written many high-performance/throughput network apps with C++ (like multimedia conferencing software) I can only say that the standard memory allocation mechanisms of C++ are inadequate for high-performance applications.

    I wrote my own memory manager for everything. All pointers were wrapped 'auto-pointers' that would even batch deallocations when value objects were falling out of scope - a bit like garbage collection. Allocation would never look for free memory slots, it was immediately available.

    All I was doing was creating Java-like objects with garbage collection. It was significantly faster than anything standard C++ memory management can do.
  38. How can that be technically true?There must have been something wrong with the C++ code that slowed it down, giving the impression that Java was faster. In many areas, Java can be almost (not never exactly) as fast as C++. In other areas, involving memory management for example, it just can not be as fast.PJ Murray, CodeFutures Software

    Well, C++ hardly is the pinnacle of optimization that nothing can surpass. It is actually quite far from it. The runtime is fixed; all optimizations have to be done in code or during compilation.

    A lot of the optimizations depend on the behaviour of the application. Compiled code can not analyze itself and rewrite itself to match the behaviour. You can only do wholesale optimizations with compiler flags or spend a lot of expensive time figuring out what extra you need to program into your application to make it go fast. Many times you end up writing your own memory allocations and such.

    You can make C++ go faster, but at what cost? Often that cost is not worth it - not anywhere near worth it.
  39. C memory performance[ Go to top ]

    You know that you are totally wrong. The Java memory management is typically much faster than the C or OS memory management.
    An malloc in C requires a first-fit or a best-fit algorithm to run to find the memory area to return. The JVM simply returns the memory from directly from the stack.
    The releasing of the memory in Java is also quite efficient. Typically more than 95% of the objects are short living objects. This kind of objects is kept in the memory area with a copy collector. A copy collector uses two memory buffers. If the first is full, the "living" objects are copied to the new buffer. That means that typically only 5% of the objects are touched. That means that the "destructors" are not called for these objects.
    Other aspects are fragmentation. C is not able to compact the heap since the memory is referenced and C doesn't know from what. Depending on the memory requirements this can be a real issue since you have plenty of memory but no block that is large enough for your needs.
    Sorry I can not provide the references but tests have shown that the tested C programs used 20-30% of their runtime for memory allocation and release. Typical Java programs use about 5% of their runtime for the garbage collection.
  40. Escape Anaylsis?[ Go to top ]

    Or is stack allocation just a new term for the java folks?
  41. Escape Anaylsis?[ Go to top ]

    Kindof like "Object" is a new term for C++ people?
  42. really?[ Go to top ]

    really?
  43. We are waiting[ Go to top ]

    We hope so
  44. That much ?[ Go to top ]

    Java's been around more than 10 years and people still find that much room for performance improvement ??? 40-100% is really huge... Especially since JDK 1.5 was advertised to improve that much from JDK 1.4 ! It should be faster than assembly by JDK 1.7 :)
  45. This dramatic improvements are mostly for client VM as there were room for improvements. Server VM is already tuned a lot, so I do not expect dramatic improvements like these in server VM.

    I also read somewhere that stack allocation is postponed for JDK 1.7. Could someone from within Sun's JVM team comment on this?
  46. I looked at the javolution benchmark and perf classes / methods. It looks to me that compilers can make aggressive optimisations the way it has been coded (no use of results).
    I suggest you look at Anatomy of a * flawed microbenchmark at Brian Goetz * Publications
    However the results as they are are still interesting.
    I would personnaly use the SpecJBB2000 or SpecJBB2005 benchmarks to compare Tiger and Mustang.
  47. Because it is just so much faster, and is actually more stable than 1.5. I think the 40-100% speed improvement is accurate. Not that 1.6 doesn't have its problems, but almost all are problems that 1.5 has. Latency for making socket connections is a big problem, and where IBM's jvm kicks butt. Except that we have problems with the IBM jvm crashing machines when the jvm uses a ton of memory (7 gigs). So we actually go with JRockit in some production settings. When you do a search at Dumbfind (www.dumbfind.com), you are actually hitting a JRockit instance that distributes to IBM instances, and a few Sun 1.6 instances. We will use anything to get the job done! We don't use Sun 1.5 at all.