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


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

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).


More information about the hotspot-gc-dev mailing list