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

Kim Barrett kim.barrett at oracle.com
Tue Aug 11 21:24:01 UTC 2015

On Aug 11, 2015, at 1:43 PM, Tom Benson <tom.benson at oracle.com> 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.

Can this introduce uncommitted "holes" in committed space?  It seems
like it might.  Otherwise, why introduce shrink_at, rather than just
using shrink_by.  I'm not sure such holes are presently possible, and
I'm not sure they are handled properly everywhere.

For example, I think such a hole might confuse
HeapRegionManager::shrink_by.  I haven't looked carefully for other
code that might be confused by uncommitted holes.

More information about the hotspot-gc-dev mailing list