RFR: 8305896: Alternative full GC forwarding
Roman Kennke
rkennke at openjdk.org
Wed Aug 21 11:36:39 UTC 2024
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
-------------
Depends on: https://git.openjdk.org/jdk/pull/20603
Commit messages:
- 8305896O Alternative full GC forwarding
Changes: https://git.openjdk.org/jdk/pull/20605/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20605&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8305896
Stats: 269 lines in 18 files changed: 191 ins; 21 del; 57 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
More information about the hotspot-gc-dev
mailing list