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