Summary
-------

Add a manageable flag called `-XX:SoftMaxtHeapSize` to set a soft limit on the max heap size.

Problem
-------

There are use cases where you might want to specify a fairly large max heap size (using `-Xmx` or `-XX:MaxHeapSize`), but still want to encourage the GC to not grow the heap to its max size unless the GC decides it's necessary to do so.

Example use cases are:

* In environments where resource usage is a concern, you might want to keep the heap footprint down while also retaining the capability to deal with a temporary increase in heap space requirement.
* When using a concurrent GC (e.g. ZGC), you might want to play it safe and increase the confidence level that you will not run into an allocation stall because of an unforeseen increase in allocation rate. Setting a soft max heap size would encourage the GC to maintain a smaller heap, which in turn means the GC will collect garbage more aggressively than it otherwise would have, making it more resilient to a sudden increase in the application allocation rate.

Solution
--------

Introduce a manageable `-XX:SoftMaxHeapSize` flag. This flag will initially be used by ZGC, where it will be used (instead of the max heap size) as input to the heuristic that decides when a GC should start. Other GCs (e.g. G1) will likely use this flag in the future in a similar way.


Specification
-------------

When `-XX:SoftMaxHeapSize` is set, the GC should strive to not grow heap size beyond the specified size, unless the GC decides it's necessary to do so. The soft max heap size should not be allowed to be set to a value smaller than min heap size (`-Xms`) or greater than max heap size (`-Xmx`). When not set on the command-line, this flag should default to the max heap size.

Patch available here: http://cr.openjdk.java.net/~pliden/8222145/webrev.1