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

[Axel Boldt-Christmas]

On Thu, 18 Jan 2024 15:47:52 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/3042a805...71c48af6
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 968:
> 
>> 966: 
>> 967:     // Load the mark.
>> 968:     movptr(mark, Address(obj, oopDesc::mark_offset_in_bytes()));
> 
> Can this potentially throw NPE?  Like in the c1 case right? Maybe worth a comment if so.  It doesn't look like the c2 code does anything special here like the c1 code does, except this goes to the signal handler, then throws the NPE when it continues.

AFAIK C2 null checks are a part of the graph. I believe they can become explicit, elided or implicit deopt trap depending on control flow and profile data. 

obj should always be non-null here.

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

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