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

[Thomas Schatzl]

Hi,

On Thu, 2014-08-14 at 20:07 +0200, 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.

I.e. other conditions could be thought of: e.g. potentially it is
sufficient to do a young-only gc to free up enough contiguous space.

Note that this is sort of almost-last resort as one could try to avoid
fragmentation during normal gc in the first place.

The very-last resort would probably be a full gc that also moves
humongous objects (which the current one does not).

Thomas