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