RFR: 8305898: Alternative self-forwarding mechanism [v4]

[Roman Kennke]

On Thu, 8 Feb 2024 14:37:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the Serial, Parallel and G1 GCs store a pointer to self into object headers to indicate promotion failure. This is problematic for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) because it would (temporarily) over-write the crucial class information, which we need for heap parsing. I would like to propose an alternative: use the currently unused 3rd header bit (previously biased-locking bit) to indicate that an object is 'self-forwarded'. That preserves the crucial class information in the upper bits of the header until the full header gets restored.
>> 
>> This is a trimmed-down/simplified version of the original proposal #13779:
>>  - It doesn't use/introduce any flags and avoids the associated branching.
>>  - It doesn't (need to) deal with displaced headers. (Current code would preserve header if necessary, Lilliput code would not use displaced headers and set the 3rd bit directly in existing header.)
>> 
>> Testing:
>>  - [x] hotspot_gc
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More consistent use of markWord::is_forwarded()

A potential improvement to this might be that we could avoid preserving the header around self-forwarding/promo-failure (and therefore remove a bunch of code/complexity). What's needed for this is a fast way to detect is_forwarded() that includes both scenarios normal-forwarded and self-forwarded.

Currently I also set normal-forwarded bits when self-forwarding to facilitate simple (v & 3) == 3 test. We would need something like ((v & 4) != 0) || ((v & 3) == 3) test, but ideally without the branch. Since we don't really care about 0b111 (should not happen), we could test ((v + 1) & 4) != 0. That is one more op (e.g. single cycle) compared to the current test, but that should hardly be noticeable (dominated by the load of the header anyway).

Then, instead of init-ing the self-forwarded header, and restoring any 'interesting' marks (hashed, locked), we could simply flip-back the self-fwd bit and that'd be it.

1. Do we want this?
2. Do we want this in this PR, or better in a follow-up PR (including the removal of header-preservation around promo-failures)?

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

PR Comment: https://git.openjdk.org/jdk/pull/17755#issuecomment-1964062243