Monday Feb 06, 2006

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!

Comments:

Wow! A predictable GC? That's funny!!. What about predicting lottery? :-D
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 #

Post a Comment:
  • HTML Syntax: NOT allowed