hotspot-gc-dev Digest, Vol 24, Issue 6

[Dan Hicks]

Well, my experience is quite different, but I suppose it may have to do 
with what you consider "overhead".  I've seen GC consume half the CPU 
cycles (and more), but if you have enough CPU then I guess that's OK.  A 
big unknown is the cost of the read and write barriers, in terms of both 
cycles spent and loss of optimization.
> Message: 1
> Date: Mon, 08 Jun 2009 13:05:54 -0400
> From: Tony Printezis <Antonios.Printezis at sun.com>
> Subject: Re: GC benchmarks
> To: Paul Hohensee <Paul.Hohensee at sun.com>
> Cc: hotspot-gc-dev at openjdk.java.net, Dan Hicks <danhicks at ieee.org>
> Message-ID: <4A2D44F2.1010209 at sun.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi all,
>
> The reality these days is that, with a bit of effort in tuning the GC, 
> GC overhead in applications is really very low (single digit percentage, 
> sometimes even as low as 1% or 2%). The actual overhead / pause times / 
> etc. are very application dependent. So, if you come up with a say 
> synthetic benchmark that does mostly GC, I don't know whether you'll 
> learn anything by comparing how our GCs perform on it. We have a few 
> such benchmarks, but they are mainly used for stress testing, not 
> performance testing.
>
> Tony
>   
---

Dan Hicks
The eyes of others our prisons; their thoughts our cages.  --Virginia Woolf