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

[Jon Masamitsu]

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?

Jon

On 8/12/2014 8:09 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this somewhat large refactoring change? It is
> about refactoring the HeapRegionSeq class to manage heap region and
> auxiliary data.
>
> I.e. currently HeapRegionSeq only manages the HeapRegion instances
> corresponding to the heap's region. The change gives HeapRegionSeq more
> responsibilities, encapsulating functionality related to heap memory
> management. This decreases the amount of responsibilities (and
> complexity) for the G1CollectedHeap class: decisions about how heap
> related memory is allocated/freed/iterated (i.e. how the heap regions
> are actually allocated in the heap) is removed from G1CollectedHeap.
>
> This change only changes the interface to this functionality. It is a
> preparatory change for JDK-8038423 "G1: Decommit memory within the
> heap", so the change might be slightly more extensive than really
> required.
>
> The RFR for JDK-8038423 will follow to look at it in context.
>
> There is another CR that renames HeapRegionSeq to HeapRegionmanager too.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8054818
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8054818/webrev/
>
> Testing:
> jprt, nightly and bigapps (kitchensink, ...) with -XX:+UseG1GC
>
> Thanks,
>    Thomas
>
>
>
>