G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector]

[Kirk Pepperdine]

I think the bigger problem is a combination of algorithmic complexity of RSet management and the multi-space effects on floating garbage adding to the volume of “live” objects that need to be processed.

On Jul 29, 2015, at 8:27 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> IIRC Erik's proposal involves TLB shootdowns, which I'm not sure will speed
> this up.  A few months back there was a discussion around this in the
> context of adding full fence with CMS when UseConditionalCardMarking is
> enabled (which I'm not sure if that change went in actually) and
> interaction with precleaning.
> 
> There was also talk of making G1 default ergonomically, with it being on
> for large heaps.  I think that makes sense.
> 
> sent from my phone
> On Jul 29, 2015 1:56 PM, "Doug Lea" <dl at cs.oswego.edu> wrote:
> 
>> On 07/29/2015 12:09 PM, Andrew Haley wrote:
>> 
>>> I am concerned that G1 does not perform well with some important
>>> workloads.  In particular, on heavily-loaded systems some
>>> multi-threaded programs which generate a lot of garbage run
>>> significantly more slowly with G1.  I've been measuring the
>>> performance loss and it's about 20-30%, depending on the application.
>>> 
>> 
>> The problem is that there is a full memory fence when issuing
>> cross-region GC write barriers. Most concurrent producer-consumer
>> designs hit this case frequently, and can run almost arbitrarily
>> slower, down to the rate of issuing fences (MFENCE/DMB/etc).
>> I know that Erik Osterlund (and possibly others) are looking into ways
>> of removing this fence. I sure hope they succeed before jdk9 ships!
>> 
>> -Doug
>> 
>> 
>>