RFR (XL): 8054818: Refactor HeapRegionSeq to manage heap region and auxiliary data
Thomas Schatzl
thomas.schatzl at oracle.com
Thu Aug 14 18:07:47 UTC 2014
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,
Thomas
More information about the hotspot-gc-dev
mailing list