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

[Axel Boldt-Christmas]

On Thu, 18 Jan 2024 15:56:07 GMT, Coleen Phillimore <coleenp 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 11 additional commits since the last revision:
>> 
>>  - 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
>>  - top load adjustments
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Fix type
>>  - Move inflated check in fast_locked
>>  - Move top load
>>  - 8319799: Recursive lightweight locking: x86 implementation
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/39a27147...71c48af6
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 977:
> 
>> 975:     jcc(Assembler::notZero, inflated);
>> 976: 
>> 977:     // Check if lock-stack is full.
> 
> Why doesn't this call MacroAssembler::lightweight_lock here?

The main idea is to keep it separate, where the MacroAssembler caters to the interpreters needs. 

The biggest difference is that the interpreter has one less registers, so it does some more juggling. 
And on a fundamental level the interpreter must handles unstructured locking, while C2 does not. There is no practical difference to the lock/enter logic because of this difference, but there is for the unlock/exit logic.

At some level the split should be that we have one implementation that handles the fixed amount of registers and unstructured locking scenario (interpreter). And one implementation which handles the case where we have a register allocator and and assumes structured locking (C1, C2). The native wrapper is somewhere in-between, is structured, but maybe has to use the first implementation due to register pressure.

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

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