RFR: 8364141: Remove LockingMode related code from x86 [v2]

[David Holmes]

On Mon, 4 Aug 2025 12:52:39 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Since the integration of [JDK-8359437](https://bugs.openjdk.org/browse/JDK-8359437) the `LockingMode` flag can no longer be set by the user, instead it's declared as `const int LockingMode = LM_LIGHTWEIGHT;`. This means that we can now safely remove all `LockingMode` related code from all platforms.
>> 
>> This PR removes `LockingMode` related code from the **x86** platform.
>> 
>> When all the `LockingMode` code has been removed from all platforms, we can go on and remove it from shared (non-platform specific) files as well. And finally remove the `LockingMode` variable itself.
>> 
>> Passes tier1-tier5 with no added problems.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update one after review

Looks great! I ssuspect there may be more cleanup possible down the track but for now (with whitespace disabled) this PR clearly shows the eradication of the LockingMode.

Some minor nits in pre-existing code, and a couple of queries.

Thanks

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 392:

> 390: // Some commentary on balanced locking:
> 391: //
> 392: // fast_lock and fast_unlock are emitted only for provably balanced lock sites.

I assume this is also correct for `lightweight_lock` and `lightweight_unlock`?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 397:

> 395: // The interpreter provides two properties:
> 396: // I1:  At return-time the interpreter automatically and quietly unlocks any
> 397: //      objects acquired the current activation (frame).  Recall that the

Suggestion:

//      objects acquired in the current activation (frame).  Recall that the

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 401:

> 399: //      a frame.
> 400: // I2:  If a method attempts to unlock an object that is not held by the
> 401: //      the frame the interpreter throws IMSX.

Suggestion:

//      frame the interpreter throws IMSX.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 409:

> 407: //
> 408: // The only other source of unbalanced locking would be JNI.  The "Java Native Interface:
> 409: // Programmer's Guide and Specification" claims that an object locked by jni_monitorenter

Suggestion:

// The only other source of unbalanced locking would be JNI.  The "Java Native Interface
// Specification" states that an object locked by JNI's_MonitorEnter

src/hotspot/cpu/x86/interp_masm_x86.cpp line 1034:

> 1032: 
> 1033:   // Load object pointer into obj_reg
> 1034:   movptr(obj_reg, Address(lock_reg, BasicObjectLock::obj_offset()));

Do you not still need the `in_bytes()` around `obj_offset()`?

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26552#pullrequestreview-3086744966
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253257552
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253258321
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253259156
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253263689
PR Review Comment: https://git.openjdk.org/jdk/pull/26552#discussion_r2253276071