RFR: Delayed heap regions uncommit

[Zhengyu Gu]

Hi Aleksey,

1) handle_heap_shrinkage() - walk heap's free set should be sufficient 
(?) and walk the list backward can be beneficial, since the pattern how 
we construct free set, LRU regions are likely at the tail side of list, 
so we can uncommit multiply regions at once.

2) Why not just take HeapLock during shrinking the heap? uncommit is 
magnitude faster than commit, and we do commit under heap lock already.
This should simplify region state transition a lot.

3) commit() can fail. I know we do not deal with it right now (ex. 
SH::grow_heap_by()), but probably we should cover these corner cases

Thoughts?

Thanks,

-Zhengyu



On 08/07/2017 04:32 PM, Aleksey Shipilev wrote:
> Hi,
>
> This is the implementation for delayed heap regions uncommit, which is the third [1] major step for
> a "resizeable" heap for Shenandoah:
>   http://cr.openjdk.java.net/~shade/shenandoah/region-uncommit/webrev.04/
>
> It works on per-region level, keeping the status of an individual region as active, recycled, or
> uncommitted. Once region stays recycled for too long, the asynchronous task would attempt to
> uncommit it. This "delayed" uncommit guarantees that actively used regions (and actively used heap,
> for that matter), does not get uncommitted. All allocation paths have to check and bring region to
> active, before attempting allocation.
>
> Current delay timer is set to 5 minutes, and it gets effectively disabled with -XX:+AlwaysPreTouch.
> Related improvements: track real "committed" size, and report it everywhere, including JMX; make
> Verifier assert that objects never get into non-active regions.
>
> Sample footprint figures:
>   http://cr.openjdk.java.net/~shade/shenandoah/region-uncommit/webrev-04-footprint.png
>
> Testing: hotspot_gc_shenandoah (+ new tests)
>
> Thanks,
> -Aleksey
>
> [1] The first one was actually adding regions under allocation pressure, the code is already there
> for years; the second was periodic GC
>