RFR: 8328744: Parallel: Parallel GC throws OOM before heap is fully expanded

[Zhengyu Gu]

Parallel Scavenge may give up if it determines that current old gen does not have enough free space to accommodate estimated promotion size, and fall back to compact GC.

If compact GC can not reclaim enough space, this vicious cycle continues until OOM, without any intentions to expand old gen. We saw our production instances running hundreds compact GCs, while there heaps were not fully utilized.

I believe when Scavenge determines if there is enough old space for the promotion, it should also consider the free space may be created by expanding the old gen.

Tests:
   hotspot_gc, tier1 and tier2 with Parallel GC (fastdebug and release) on x86_64 and MacOSX

-------------

Commit messages:
 - Merge branch 'master' into JDK-8328744
 - v0
 - 8328744: Parallel: Parallel GC throws OOM before heap is fully expanded
 - 8328612: AdaptiveSizePolicySpaceOverheadTester::is_exceeded() print max_eden_size twice

Changes: https://git.openjdk.org/jdk/pull/18463/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18463&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328744
  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/18463.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18463/head:pull/18463

PR: https://git.openjdk.org/jdk/pull/18463