RFR: 8319799: Recursive lightweight locking: x86 implementation [v12]

[Axel Boldt-Christmas]

On Wed, 24 Jan 2024 12:21:16 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Axel Boldt-Christmas 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 18 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Add more expressive stub continuation names
>>  - Remove outdated anonymous owner fix in stub
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Remove C2HandleAnonOMOwnerStub definitions on x86.
>>  - Add MFENCE comment
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/ef08ca7a...bc214b8d
>
> src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 144:
> 
>> 142:     lightweight_unlock(obj, disp_hdr, r15_thread, hdr, slow_case);
>> 143: #else
>> 144:     // This relies on the implementation of lightweight_unlock knowing that it
> 
> I wonder if is would be less brittle (fewer dependencies), if we didn't pass thread as register into lightweight_unlock() and keep the thread-loading and register-shuffling in that method? Same (perhaps) for lightweight_loc().

The only annoying thing is that the generate native wrapper x86_32 path has a dedicated thread register. Have to either signal this to lightweight_{unlock,lock} or just reload the thread in this path.

I will see if I can find a cleaner solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16607#discussion_r1465997990