RFR: JDK-8312018: Improve zero-base-optimized reservation of class space [v4]

[Thomas Stuefe]

> TL;DR This patch introduces a new reservation API to reserve memory in low address space; depending on the OS, it may use optimized placement techniques. That new API is used to optimize the placement of class space and CDS for zero-based encoding. 
> 
> A future RFE will use the same API to optimize the zero-based heap reservation and thereby consolidate a lot of coding. We also plan to use this API in other places, e.g. for Shenandoah CollectionSet reservation.
> 
> -------
> 
> With CDS off or at dump time, we currently attempt to optimize class space location by reserving in low address ranges.
> 
> We do this by examining the *java heap* end (which has been allocated at that point) and, if that had been allocated in lower address regions, attempt to allocate adjacent to it. Essentially, we piggyback on what we hope for is an optimized heap placement. If that fails, we attempt to map at HeapBaseMinAddress.
> 
> This approach has many disadvantages:
> 
> - it depends on the VM either using CompressedOops and getting a zero-based heap or the region around HeapBaseMinAddress being free. 
>  
> - HeapBaseMinAddress is an odd choice: it is 2G on all platforms, for reasons unknown to me, but that denies us half of the valuable low address range below 4G right away.
> 
> - We only get 1 shot. It's either one of these two addresses.
> 
> - And we only use this strategy for CDS=off or CDS=dumptime; we don't use it for the CDS-runtime-fallback-case when attaching to the primary attach point failed.
> 
> - It assumes narrow Klass encoding uses the same geometry (bit size, shift) as narrow Oops, which is not guaranteed with future developments (lilliput).
> 
> - It actually reduces the chance of getting a zero-based *java heap*. This is because when attempting to place the heap, we leave a gap for what we assume will be the later class space. That gap is `CompressedClassSpaceSize` bytes, which is often grossly over-dimensioned. A zero-based heap is more valuable than a zero-based class space. Therefore the heap should get the best chance of low-address heap reservation.
> 
> - It introduces an unnecessary dependency between heap reservation, narrow Oop encoding, and class space reservation. That makes the code base brittle.
> 
> - Getting the heap region to place class space adjacent to it is actually tricky. We lack a common get-heaprange-API because ZGC. This code misuses the CompressedOops interface. But CompressedOops is the encoding range and thus only loosely correlated to the heap range (the latter must cont...

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Feedback David
 - Merge branch 'master' into JDK-8312018-Improve-zero-base-optimized-reservation-of-class-space
 - Fix Windows
 - Feedback Roman; fix off-by-1; fix tracing
 - better zero-based reservation strategy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14867/files
  - new: https://git.openjdk.org/jdk/pull/14867/files/8d6a1ed4..60923aad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14867&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14867&range=02-03

  Stats: 8259 lines in 261 files changed: 6693 ins; 758 del; 808 mod
  Patch: https://git.openjdk.org/jdk/pull/14867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14867/head:pull/14867

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