RFR: Delayed heap regions uncommit

[Aleksey Shipilev]

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