G1 as a CMS replacement

Jon Masamitsu jon.masamitsu at oracle.com
Sun Jun 7 21:01:14 UTC 2015

On 6/7/2015 1:20 AM, Kirk Pepperdine wrote:
> Hi Jon,
> I’ve been holding back on this because my thoughts are still not well formed but since we’re on the subject I thought I’d throw out my bad ideas in hopes that they inspire a better idea.
>> I also know that the static initiating occupancy of G1 can be
>> a hindrance and that the larger G1 process footprint is a
>> disadvantage.  Are either of those blocker for transition to
>> G1 for some applications.


> I’m not sure that a static IHOP is really the problem. From what I can see, it’s the accumulated cruft in regions that are not deemed “ripe” enough to sweep that is a bigger problem. From the GC logs I’m getting from various customers trying to use G1 I where period calls to full collections are made, I can see that when this cruft gets cleaned up there is a corresponding and proportional drop in subsequent young collection pause times.

When you say cruft you mean live data spread throughout the heap, 
right?  You're not
talking about some side effect of floating garbage.

> Since this drop in pause all seems to be connected to RSet refinement/processing, it would seem to suggest that there might be some benefits if some how the RSets of target young regions could be cleaned during one of the concurrent phases of the concurrent mark in tenured. Maybe there could be a concurrent sweep (without the evacuation) phase added at the end of the cycle that could simply clean RSets of the pointers coming from said cruft. A full evacuation of a region would still be the domain of the young gen sweep.

I'm going to have to read some code tomorrow to see what cleaning is 
done but one side effect
of a full GC could be that the "cruft" that was spread out over 10 
regions is compacted into 1
region.  That would affect RSet's such that a young region collected 
before the full GC would
have RSets for 10 regions.  A collection of a young region after the 
full GC might only have
a RSet for 1 region (where all the cruft is).  Is this a possible 
interpretation of what you're
seeing?  If not, as I said, I'll look at what's done in terms of 
precleaning and get back.  Thanks
for asking.


> The current alternative is too simply make the collector more aggressive in how it selects regions. However, I feel tuning this way defeats the purpose or intent behind the G1.
> Regards,
> Kirk

More information about the hotspot-dev mailing list