RFR: 8305896: Alternative full GC forwarding

[Stefan Karlsson]

On Thu, 15 Aug 2024 22:54:39 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> 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

src/hotspot/share/gc/shared/gcForwarding.cpp line 42:

> 40:   //  FLAG_SET_DEFAULT(UseCompactObjectHeaders, false);
> 41:   // }
> 42: }

ZGC doesn't use this and even if it did using MaxHeapSize wouldn't work since we have a larger address space than max heap size. Could you move the call to this function out of  `GCArguments::initialize_heap_sizes` and into the GCs that will use `GCForwarding`?

so could you move this out to the GCs that actually uses it?

src/hotspot/share/gc/shared/gcForwarding.inline.hpp line 56:

> 54: 
> 55: bool GCForwarding::is_forwarded(oop obj) {
> 56:   return obj->mark().is_marked();

Is this intentionally using `is_marked` instead of `is_forwarded`? If it is, could you write a short comment explaining why?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20605#discussion_r1725706745
PR Review Comment: https://git.openjdk.org/jdk/pull/20605#discussion_r1725711518