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

[Roman Kennke]

On Fri, 18 Aug 2023 13:48:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
>> 
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - Update comment about mark-word layout
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - Fix tests on 32bit builds
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - wqRevert "Rename self-forwarded -> forward-failed"
>>    
>>    This reverts commit 4d9713ca239da8e294c63887426bfb97240d3130.
>>  - Merge branch 'JDK-8305896' into JDK-8305898
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/d2b41e25...cd5f2374
>
> src/hotspot/share/oops/oop.inline.hpp line 292:
> 
>> 290:     m = m.set_self_forwarded();
>> 291:     assert(forwardee(m) == cast_to_oop(this), "encoding must be reversible");
>> 292:     set_mark(m);
> 
> Could you explain why we need to restore the displaced mark word here? I wonder why it matters what the old mark word is and why this code can't be changed to something like this:
> 
>     markWord m = markWord::prototype().set_self_forwarded();
>     set_mark(m);

The main reason why we need to implement the self-forwarding is to preserve the upper bits of the mark-word (specifically, the Klass* that we want to place there with JEP 450). If the header is displaced, we would install the self-forwarded bit in the tagged native-pointer that is in the header, meaning we loose the ability to get to the actual header to fetch the Klass*. We do restore the header later, but GC needs access to the Klass* meanwhile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13779#discussion_r1305779757