Predictable GC does not mean Fast GC
I recently heard some claims from one of our competitors that drove me nuts! Said competitor claimed that they have a very fast VM, which is now even faster given that they have a predictable GC!
Exqueeze me? Baking powder?*
Whoever made these claims clearly has no understanding of how garbage collection works and what the trade-offs involved are.
To achieve predictability, you have to make sacrifices. Even by going from a fully stop-the-world to a more incremental collector, you usually double your garbage collection overhead (that's my rule of thumb at least) and increase your memory footprint.
Going from a simple incremental to a really predictable collector will cost you even more. I have read papers in which a 30%-35% garbage collection overhead is considered a good result in the context of a predictable garbage collector.
In a lot of applications that our customers care about, the garbage collection overhead is maybe 10%, even as low as 5%. Predictability will not decrease that.
Incidentally, I had seen some SPECjbb (2000 I think) results from said competitor and, by looking at the configuration they ran with, I highly doubt that they had any garbage collection activity during the timing window. So, how are they going to improve that with a predictable collector? Eh?
Let me put it another way: they will not be publishing SPECjbb2005 numbers with their predictable collector any time soon...
*If you didn't get the joke, I invite you to watch Wayne's World. Even if you got the joke, watch it anyway!
Posted at 11:01AM Feb 06, 2006 by tony in Sun | Comments[1]
By the way, last week I tuned a GC at a customer's within 1% overhead.
Cheers,
Antonio
Posted by Antonio on February 06, 2006 at 04:33 PM EST #