JEP 248: Make G1 the Default Garbage Collector
charlie.hunt at oracle.com
Fri Jul 31 13:09:23 UTC 2015
Thanks for bringing this back into focus!
Indeed we will take a look & investigate.
> On Jul 30, 2015, at 2:57 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 07/30/2015 11:42 AM, charlie hunt wrote:
>> While we really like hearing about experiences with G1 GC, (and the other
>> collectors as well), let’s try to keep the discussion on this thread on the
>> subject G1 GC being made the default GC for JDK 9 by talking about the
>> scenarios and the observations of those potentially impacted.
> In case my last post was not clear :-), there is a scenario
> encountered by java.util.concurrent users in which G1 performance
> is much, much worse:
>> ... 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).
> Maybe usage is not common enough to outweigh the pathological
> performance. Also, I've been experimenting with some changes
> in j.u.c algorithms to mitigate impact, but I don't think I can
> make a large dent in the big slowdowns I see on microbenchmarks.
> So until that fence is removed, all we can do is tell heavy j.u.c
> users to turn off G1 in jdk9.
> As mentioned in other discussions, G1 might otherwise be
> a good choice in some heavily concurrent programs.
> Before they put in that fence, I used to see about an
> equal number of ups and downs vs other collectors in test programs.
More information about the hotspot-dev