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

[Axel Boldt-Christmas]

On Fri, 26 Jan 2024 21:01:54 GMT, Daniel D. Daugherty <dcubed 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 21 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream_jdk/pr/16606' into JDK-8319799
>>  - Update variable names in ad files
>>  - Preload markWord unconditionally
>>  - 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
>>  - ... and 11 more: https://git.openjdk.org/jdk/compare/3ef03486...4d37c4b7
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1061:
> 
>> 1059:     stub = new (Compile::current()->comp_arena()) C2FastUnlockLightweightStub(obj, mark, reg_rax, thread);
>> 1060:     Compile::current()->output()->add_stub(stub);
>> 1061:   }
> 
> So what happens if `stub` doesn't get generated?

When `in_scratch_emit_size` is true we are only emitting to calculate the size of the code.  So only dummy labels are used for jumps and no stub is allocated nor registered. 

Later when the final emission occurs (`in_scratch_emit_size` is false) the stub is allocated and registered (so that it can be emitted later with the stubs) and the correct labels are used (and bound). 

Stubs are always generated for the final emission.

As for the stub failing to get allocated, I believe that the arena allocator uses `AllocFailStrategy::EXIT_OOM`, unsure what happens when the compiler arena is exhausted.

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

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