RFR: Delayed heap regions uncommit

[Zhengyu Gu]

Okay.

-Zhengyu

On 08/08/2017 04:24 PM, Aleksey Shipilev wrote:
> On 08/08/2017 02:18 PM, Zhengyu Gu wrote:
>> 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.
>
> I don't think that making this dependent on free set is a good idea. Current code manages all active
> regions, which makes things simpler, at the expense of walking over potentially active regions.
> Which is better for testing purposes: we always exercise that path for all regions. Since we are
> walking all regions, makes no sense to revert the walk direction too. (We shall consider it, though,
> once we approach region-level heap defrag).
>
>> 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.
>
> Oh right! This indeed simplifies things.
>
>> 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
>
> That's right, we need to fix this. I tried to approach it in this patch, but realized much more
> extensive work around humongous regions is needed to get this working properly. Current patch does
> not complicate this task much.
>
> New patch:
>   http://cr.openjdk.java.net/~shade/shenandoah/region-uncommit/webrev.05/
>
> Still passes hotspot_gc_shenandoah.
>
> Thanks,
> -Aleksey
>