RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region and auxiliary data

Jon Masamitsu jon.masamitsu at oracle.com
Thu Aug 14 23:10:26 UTC 2014


On 08/14/2014 11:07 AM, Thomas Schatzl wrote:
> Hi,
>
> On Thu, 2014-08-14 at 09:43 -0700, Jon Masamitsu wrote:
>> Thomas,
>>
>> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp.frames.html
>>
>>    800     } else {
>>    801       // Policy: Potentially trigger a defragmentation GC.
>>    802     }
>>
>> Is the" defragmentation GC" a full compacting STW GC?
>> Since this is just a comment I expect that a full compacting STW GC will
>> happen if the allocation fails?  So why contemplate one here?
> No, this one: https://bugs.openjdk.java.net/browse/JDK-8038487
>
> This is the place to calculate the "best" (fewest) regions to evacuate
> using information from HeapRegionSeq (e.g. least amount of commits) and
> the gc efficiences (e.g. largest sum of efficiencies), and execute that
> mixed GC (also reserving this area so that it will not be used during
> GC).
>
> That's just an idea.
>
> A few lines above, before expansion, the code also contains a note about
> that, but that is the wrong place. (It reads: "Alternatively we could do
> a defragmentation gc" - the else part, where this comment you noticed
> is, is this mentioned alternative).

Thanks for the explanation.  Changes look good.

Reviewed.

> Thanks,
>    Thomas
>
>




More information about the hotspot-gc-dev mailing list