G1 as a CMS replacement
kirk at kodewerk.com
Mon Jun 8 06:51:03 UTC 2015
I should have added to my last email is what I’m looking for is to move the collector to be more useful in big server environments. I’m not sure that you’d want to, or can use the same strategies for smaller or mobile apps. This is why I believe the idea of a 1 size fits all collector fundamentally flawed.
On Jun 7, 2015, at 11:01 PM, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
> 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.
More information about the hotspot-dev