G1 as a CMS replacement

[Kirk Pepperdine]

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.

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.

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