RFR: On-demand commit as heap resizing strategy

[Aleksey Shipilev]

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