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

[Tom Benson]

Hi Kim,

On 8/11/2015 5:24 PM, Kim Barrett wrote:
> 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.
shrink_by looks for free ranges it can uncommit.  Here, we want to 
uncommit the specific region(s) allocated with alloc_archive_regions.  
There is an expand_at that takes a specific index, which shrink_at is 
intended to be analogous to.

G1 is designed to allow uncommitted holes.   Even without this change, 
there is a big 'hole' in committed space:    All the regions between the 
low end of the heap where mutator allocation is occurring (initially 
sized by Xms)  and these archive regions which are at the highest end of 
the (Xmx-sized) heap.

In a way,  as used by CDS, calling dealloc_archive_regions is *removing* 
that hole. 8^)     The entire upper portion of the heap (above Xms) will 
again be uncommitted, as if alloc_archive_regions had never been called.

Tom

>
> 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.