Java is so slow…

… you would think. Maybe not, but many people seem to agree with that. One interesting fact is that, though, Java’s allocations are much faster than classic malloc allocations. This is due to the highly optimized nature of allocation in modern JVMs and the way they handle heap allocations and deallocations. Generational collectors is one of these techniques:

 

Generational collectors try to benefit from the empirically observed property that most allocated objects live for a very short time, while a small percentage of them live much longer. If an object survives one collection, chances are it will survive many collections. If the collector copies objects or compacts the heap, these long lived objects are copied over and over again. Generational techniques split the heap into several sub-heaps and segregates the objects in the sub-heaps according to their age. New objects are allocated in the first generation sub-heap. When the application runs out of memory, only the first generation sub-heap is scanned. The objects that survive one or more collections are moved to the second generation heap. If most objects are indeed short-lived, most of the first generation heap is freed and few objects need copying to the second generation heap. The older generation sub-heaps are scanned less frequently. Since smaller fragments of the heap are scanned and proportionally more storage space is recovered, the overall efficiency of the garbage collector improves.

 

Memory allocations are certainly just one aspect of application performance, and Java is still slow for performance-critical applications. Also don’t forget that programming languages like C and C++ still wins since most of the objects are allocated on the stack, hence free allocations.

Nevertheless, it is surprising to see that allocations in Java are even faster than malloc. Surprising as it is, calling the new operator in Java requires execution of about 10 instructions whereas a malloc call executes 60 to 100 instructions, hence making Java’s allocations 6 to 10 times faster! Make sure to check the article titled “Java theory and practice: Urban performance legends, revisited” by Brian Goetz if you are interested in details.

Finally, I’d like to share a few funny quotes this article reminds me about Java:

  • If Java had true garbage collection, most programs would delete themselves upon execution. Robert Sewell
  • Java: the elegant simplicity of C++ and the blazing speed of Smalltalk.
  • Java is high performance. By high performance we mean adequate. By adequate we mean slow. Mr. Bunny
  • Java is, in many ways, C++--. Michael Feldman

Take care 😀

4 comments

  1. Allocation/Deallocation is one thing to keep in mind, but not necessarily means that the language will be fast. In C++ a clever programmer can optimize the code, by introducing some semantic knowledge a compiler will not be able to add (at least not for the near future). Here is just a simple issue;

    http://www.jroller.com/gonenc/entry/continuous_object_array_allocation

    The constraints enforced by Java, to keep the language design simple is causing a problem for a good cache usage, since everything in Java is an Object (or in other words pointers).

  2. Thanks for pointing that out, it was an interesting read for me.

    Of course there are many drawbacks of using managed languages when it comes to performance, let alone Java which has even more significant performance problems compared to languages like C#. But the fact that managed languages can be faster than native code in some aspects, like allocations, is interesting in my opinion.

    I completely agree with you that the effort put to keep these languages as simple as they are makes them less efficient in terms of speed and memory usage. Because this basically means taking the burden off developers’ shoulders and putting them on JVM, in Java case, and we know that computers are not as good with the ‘big picture’ as humans. This usually prevents making optimizations that are related to the semantic structure of programs.

    But I don’t think that’s much of an issue with most of the Java developers, since the point of Java is to shorten the development time where runtime performance loss is acceptable to some degree, for most people anyway. I don’t think the aim of SUN with Java is to make it a cross platform C++ abstraction, as complicated but not nearly as fast. Though some people claim that it is already the case, see the second quote at the end of the article. 😉

  3. Hello cetin, I agree :P. Long time no see, Ive lost contact with you so I am posting on your website to find you again. 😀

Leave a Reply