RFR: JDK-8320368: Per-CPU optimization of Klass range reservation [v4]

[Thomas Stuefe]

> In `Metaspace::reserve_address_space_for_compressed_classes`, we reserve space for the future Klass range. We place the Klass range somewhere that allows us to use "good" narrow Klass decoding later when initializing the encoding scheme.
> 
> Narrow Klass decoding is inherently CPU-specific, so doing this in shared coding is awkward. It leads to many ifdefs, vague code comments that are difficult to explain, and missed optimizations. 
> 
> There are common patterns: 
> - all platforms benefit from unscaled encoding so trying to reserve <4GB for CDS=off is worthwhile. 
> 
> But there are more differences than one would think:
> - some platforms (s390, riscv) benefit from reservation < 4GB even with CDS=on since a 32-bit immediate requires fewer instructions
> - some platforms (aarch64) don't benefit from zero-based encoding, so no need to try that
> - some platforms benefit from optimizing the base for 16-bit moves (PPC, s390, aarch64) or for other immediate formats (riscv)
> 
> It would be much better to have this section per CPU so that every CPU can implement its perfect, well documented version. A bit of code duplication is a good price for code clarity.
> 
> -------------
> 
> This patch splits out `Metaspace::reserve_address_space_for_compressed_classes` into five variants, one per CPU (moving the code to CompressedKlassPointers); it also splits out `CompressedKlassPointers::initialize` into two variants, one for aarch64, one for all other platforms. 
> 
> Changes per-CPU:
> 
> #### aarch64:
> 
> Don't attempt to reserve for zero-based encoding; since lsl is not faster than movk. We reserve for movk mode right away if reserve for unscaled fails or if CDS=on.
> 
> We also add a last-ditch attempt to reserve optimized for movk via over-alignment. We only do this on aarch64 to prevent errors like this one JDK-8318119: "Invalid narrow Klass base on aarch64 post 8312018"
> 
> Since we don't want zero-based encoding, we need an aarch64-specific version for `CompressedKlassPointers::initialize()`
> 
> #### riscv:
> 
> We attempt to reserve at a "good" base that has only bits set either in [12..32), [32, 44) or in [44, 64).
> 
> #### s390:
> 
> We attempt to allocate < 4GB unconditionally.

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 ten additional commits since the last revision:

 - fix mistake
 - feedback andrew
 - Merge upstream
 - EOR mode reservation for aarch64
 - Merge branch 'JDK-8320368-Per-CPU-optimization-of-Klass-range-reservation' of github.com:tstuefe/jdk into JDK-8320368-Per-CPU-optimization-of-Klass-range-reservation
 - Update compressedKlass_aarch64.cpp
 - Regression Test
 - JDK-8320368-Per-CPU-optimization-of-Klass-range-reservation
 - JDK-8320382-Remove-CompressedKlassPointers-is_valid_base

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16743/files
  - new: https://git.openjdk.org/jdk/pull/16743/files/943889b0..e4e23388

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

  Stats: 10112 lines in 372 files changed: 6424 ins; 1337 del; 2351 mod
  Patch: https://git.openjdk.org/jdk/pull/16743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16743/head:pull/16743

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