Slashdot Mirror
Java Urban Performance Legends
An anonymous reader writes "Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs."
How many JVMs can you afford to run on your system for different apps, and how can you make sure they are all the right size, the garbage collectors are in an appropriate mode that can keep up with generated garbage, etc. I can run lots of native apps, which in many cases have no need for a significant heap like Java brings into the picture in far less space than a single JVM. A JVM runs much heavier on the system, and when I run Netbeans, it is continuously on the verge of eating my 1.2 GB powerbook alive, in fact I have to frequently restart Netbeans to get memory back. It has a long way to go in real practical terms even if they have theoretical solutions to some of the problems. I am porting my server software away from Java for the same reasons. This is JDK 1.4, and I am about to try it on 1.5, but I don't think there is that much difference.
This article is actually debunking some people's reasons why Java has poor performance. It does little to debunk my actual real world experience that it *is* slow. I'm glad to see that performance has increased alot, but I remember some all (well 90% or something) Java applications, like the original JBuilder, that made me want to claw my eyeballs out when using them. Those apps and other early apps are where Java's performance issues really took hold in many people's psyche.
the people who keep telling me allocation in Java is slow (much slower than 10 instructions) are generally experienced Java programmers. I use Ocaml, so I'm quite aware of how fast a generational garbage collector can be (btw, on the x86 in Ocaml, allocations are only 5 simple instructions). But from all first hand reports I've heard, Java allocation is still slow. It may be faster than C++, but it's still slow.
Really? Can provide a few REAL world examples? Can you name one? Personally, I'm running Azureus and Netbeans right now, and they're not perceptably different from C++ desktop applications like KDevelop or OpenOffice.
The typical home machine these days is still sub-ghz, and Java performs so poorly as to be unusable on such machines.
A typical mobile phone is sub-ghz too, and there is plenty of J2ME software running on them...
Java rocks on limited devices AND as server software. It is only on the desktop it isn't a big hit. Yet.
Being bitter is drinking poison and hoping someone else will die
Additionally, even if it takes more instructions per call, glibc malloc() will return freshly used "hot" memory to you, while the JVM will return the coldest memory to you--the author of the article admits that this is a problem, but it is worse than they say.
First, you definately have an L1 cache miss. On a P4, that is a 28 cycle penalty. You also likely have an L2 cache miss. Fast DDR2 memory has an access latency of about 76 ns--call it 220 processor clock cycles. If you miss the D-TLB, then add another 57 cycles. Total cost of your "fast" allocator--305 cycles of memory access latency. 305 is somewhat higher than 100.
Even worse, if you are on a system with a lesser amount of memory, you may miss main memory entirely, causing a page fault. That'll cost you several milliseconds waiting for the disk. That really really hurts, since 8 milliseconds latency from disk is twenty-four million cycles at 3 GHz. 24 million, 24,000,000, 2.4 * 10^6, no matter how you write it, that's a lot of cycles to allocate memory.
All of a sudden, 100 instructions to hit hot memory seems cheap.
And I can always tune garbage collection performance by forcing a garbage collect when I know my app's got the time, like outside of a loop or before creating more objects in storage.
No, you can't. At most you can give the JVM a hint that it would be nice to collect garbage now. The JVM is free to ignore that hint, and many JVMs will do just that.
Blasphemy is a human right. Blasphemophobia kills.