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

[Paul Hohensee]

I'm curious.  Which GC's can consume half the cpu cycles?  I'd believe 
it of Metronome's
real-time GC (because it's designed to work that way if necessary), but 
like Tony, I haven't
seen GC consume that much cpu in the wild.

Paul

Tony Printezis wrote:
> Dan,
>
> Dan Hicks wrote:
>> 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.
> Well, our GCs (minus G1) only have a simple card table write barrier 
> and no read barrier. The card table barrier doesn't cost you much most 
> of the time (maybe a few single digit percent) and it allows much more 
> efficient generational GC, which is a win overall.
>
> Tony
>>> 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
>>
>