RFR: 8305896: Alternative full GC forwarding [v3]

[Roman Kennke]

> Currently, the full-GC modes of Serial, Parallel, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large because now all headers would be 'interesting' and would have to be preserved.
> 
> I propose to use an alternative encoding for full-GC (sliding-GC) so that the forwarding information fits into the lowest 32 bits of the header. The encoding is similar to compressed-oops encoding: it basically subtracts the forwardee address from the heap-base, shifts that difference into the right place, and sets the lowest two bits (to indicate 'forwarded' state as usual).
> 
> The current implementation preserves the upper 32 bits of the mark-word. This leaves 30 bits for encoding the forwardee, enough for 8GB of heap. As soon as we get Tiny Class-Pointers (planned as part of compact headers upstreaming), we only need 22 bits for the narrow Klass*, and can use 40 bits for forwardee encoding. That's enough for 8TB of heap. If somebody wants to run with larger heap than this, compact headers would be disabled. This change also adds some infrastructure to configure the flags, with the code commented out, to illustrate the intended use.
> 
> An earlier approach to address the problem has been proposed in https://github.com/openjdk/jdk/pull/13582. This has been implemented under the assumption that we would only have 30 bits to encode the forwardee. In the light of changed plans, I don't think it's worth the added complexity and risk of slight performance issues. I will revisit it in the future, for 4-byte-headers.
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but gave up on it for now, because performance was significantly worse than the sliding forwarding encoding.
> 
> This is in preparation of upstreaming compact object headers, and I intend to push it only once all the parts have been approved.
> 
> Testing:
>  - [x] hotspot_gc
>  - [x] tier1
>  - [x] tier2
>  - [x] tier3
>  - [x] tier4

Roman Kennke 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 four additional commits since the last revision:

 - Merge branch 'JDK-8305898-v4' into JDK-8305896-v2
 - Initialize flags in GC specific paths
 - Reviews
 - 8305896O Alternative full GC forwarding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20605/files
  - new: https://git.openjdk.org/jdk/pull/20605/files/932ee693..d5f735fa

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

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20605/head:pull/20605

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