RFR (S): 8131734: Add free_archive_regions support to G1 for -Xshared:auto

Thomas Schatzl thomas.schatzl at oracle.com
Wed Aug 12 11:00:59 UTC 2015


Hi,

On Tue, 2015-08-11 at 13:43 -0400, Tom Benson wrote:
> Hi,
> On 8/7/2015 10:56 AM, Tom Benson wrote:
> >
> > The problem is simply that in addition to calling 
> > free_archive_regions, FileMapInfo::unmap_string_regions also unmaps 
> > the memory.... so there's a segv when GC tries to re-use it. Let's 
> > talk directly about the best way to handle it.
> > Tom
> 
> After some discussion, I've changed the definition and name of 
> free_archive_regions.  Now called dealloc_archive_regions, it uncommits 
> the specified regions, unmapping the memory, rather than adding them to 
> the free list.  This means the CDS code will no longer do the unmapping 
> on verification failures.
> 
> Updated full and incremental webrevs of the GC code are at:
> http://cr.openjdk.java.net/~tbenson/8131734/webrev.02/
> http://cr.openjdk.java.net/~tbenson/8131734/webrev.02.vs.01/
> 
> Tested with JPRT and running benchmarks with the dealloc_ performed 
> explicitly.  Jiangli also tested the original failing cases, and will be 
> posting an updated webrev.

- is it possible that shrink_by() uses shrink_at()? This would avoid two
paths that uncommit regions like expand_by()/expand_at()?

- I think the change should call at least HeapRegion::hr_clear() on the
region to remove or reset any auxiliary data structures, if not
G1CollectedHeap::free_region() (without adding the region to the free
list).
Since the HeapRegion* is not deallocated by the uncommit, this may cause
strange behavior later when the region is reused.

Other than that it looks okay.

Thanks,
  Thomas




More information about the hotspot-gc-dev mailing list