G1 Performance [Was: JEP 248: Make G1 the Default Garbage Collector]
kirk.pepperdine at gmail.com
Thu Jul 30 06:47:53 UTC 2015
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!
More information about the hotspot-dev