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

[Axel Boldt-Christmas]

On Tue, 23 Jan 2024 18:59:21 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 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/7c1570b4...bc214b8d
>
> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 77:
> 
>> 75: 
>> 76: int C2FastUnlockLightweightStub::max_size() const {
>> 77:   return 128;
> 
> Is this still 128?

This is just used to preallocate the buffer when emitting stubs. Unused space gets truncated / used by the next stubs emission. (If I recall correctly the buffer is grown with at least 4KB at a time if offset() + next_stub->max_size() > buffer_end.) 

I remember it being somewhere around ~100 bytes depending on ASSERT. So 128 seemed like a good enough number to ensure that the stub could always be emitted. 

But maybe there is value in being more precise so that (assembler) changes which change (grow) the code emission size are captured early.

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

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