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

Jon Masamitsu jon.masamitsu at oracle.com
Thu Aug 14 16:43:00 UTC 2014



  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?


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

More information about the hotspot-gc-dev mailing list