RFR: On-demand commit as heap resizing strategy

[Zhengyu Gu]

Okay.

-Zhengyu

On 08/29/2017 12:28 PM, Aleksey Shipilev wrote:
> Hi,
> 
> One of the adopters' GC logs I looked into had this weird initial burst of GC cycles, counting
> minutes in total. The cause was the omitted -Xms option that made Shenandoah try to operate on much
> smaller -Xms heap with back-to-back GC cycles, until we "luckily" run into freeset exhaustion and
> the associated heap resizing.
> 
> Recent work around region state handling enables us to rethink the heap resizing strategy in
> commit/uncommit sequences. Uncommit part is already functional (see ShenandoahUncommitDelay), and we
> might want to redo the commit part now:
>    http://cr.openjdk.java.net/~shade/shenandoah/heap-expansion-commit/webrev.01/
> 
> This does several things:
>    a) Instantiates all regions upfront, but keeps some of them uncommitted. -Xms now defines the
> number of initially committed regions;
>    b) Removes the distinction between max_regions and num_regions, because now we have the constant
> number of regions in the heap;
>    c) Simplifies allocation logic, because it does not have to care about adding regions anymore --
> the "expansion" is now implicit, as allocation code would try to commit regions on-demand. Failure
> to provide -Xms (or providing a bad value) would be innocuous;
>    d) Handles AlwaysPreTouch a bit better: touches everything up to Xmx, not Xms, as before;
> 
> After this, -Xmx defines everything.
> 
> Further work that I want to defer to other patches:
>    - I had to disable TestHeapAlloc test, because we don't expand the heap as the test expects to. We
> would revisit this when handling commit failures for individual regions.
>    - VirtualSpace is almost not needed for ShenandoahHeap now, used only in monitoring -- we can
> purge it later;
> 
> Testing: hotspot_gc_shenandoah, RSS tests
> 
> Thanks,
> -Aleksey
>