8365190: Remove LockingMode related code from share #27041

fbredber · 2025-09-02T08:24:10Z

Since the integration of JDK-8359437 the LockingMode flag can no longer be set by the user. After that, a number of PRs has been integrated which has removed all LockingMode related code from all platforms (except from zero, which is done in this PR).

This PR removes LockingMode related code from the shared (non-platform specific) files. It also removes the LockingMode variable itself.

Passes tier1-tier5 with no added problems.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8365190: Remove LockingMode related code from share (Sub-task - P4)

Reviewers

Albert Mingkun Yang (@albertnetymk - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/27041/head:pull/27041
$ git checkout pull/27041

Update a local copy of the PR:
$ git checkout pull/27041
$ git pull https://git.openjdk.org/jdk.git pull/27041/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27041

View PR using the GUI difftool:
$ git pr show -t 27041

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/27041.diff

Using Webrev

Link to Webrev Comment

bridgekeeper · 2025-09-02T08:25:12Z

👋 Welcome back fbredberg! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-09-02T08:26:20Z

@fbredber This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8365190: Remove LockingMode related code from share

Reviewed-by: ayang

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 21 new commits pushed to the master branch:

a029245: 8365983: Tests should throw SkippedException when SCTP not supported
7103543: 8366063: Parallel: Refactor copy_unmarked_to_survivor_space
1feb9bd: 8365557: Parallel: Refactor ParallelScavengeHeap::mem_allocate_work
... and 18 more: https://git.openjdk.org/jdk/compare/dacd9af9a02464d2d6144e29d851216641e836c9...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-09-02T08:27:00Z

@fbredber The following labels will be automatically applied to this pull request:

graal
hotspot
serviceability
shenandoah

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2025-09-02T11:07:00Z

Webrevs

00: Full (71038b71)

robcasloz · 2025-09-02T13:46:11Z

src/hotspot/share/opto/phaseX.cpp

@@ -1669,7 +1669,7 @@ bool PhaseIterGVN::verify_Ideal_for(Node* n, bool can_reshape) {
    //
    // Found (linux x64 only?) with:
    //   serviceability/sa/ClhsdbThreadContext.java
-    //   -XX:+UnlockExperimentalVMOptions -XX:LockingMode=1 -XX:+IgnoreUnrecognizedVMOptions -XX:VerifyIterativeGVN=1110


For traceability, I suggest leaving this line untouched and adding a comment in the next line clarifying that -XX:LockingMode is not available anymore.

coleenp

A few comments and suggestions for your next RFE.

coleenp · 2025-09-02T20:11:15Z

src/hotspot/share/jvmci/vmStructs_jvmci.cpp

@@ -341,7 +341,6 @@
  volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
  volatile_nonstatic_field(ObjectMonitor,      _entry_list,                                   ObjectWaiter*)                         \
  volatile_nonstatic_field(ObjectMonitor,      _succ,                                         int64_t)                               \
-  volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \


There are some jvmci tests that check that the java side of jvmci matches, ie:

make test TEST=compiler/jvmci

coleenp · 2025-09-02T20:15:51Z

src/hotspot/share/runtime/basicLock.hpp

  void set_bad_metadata_deopt() { set_metadata(badDispHeaderDeopt); }

-  // LM_LEGACY
-  inline markWord displaced_header() const;
-  inline void set_displaced_header(markWord header);
  static int displaced_header_offset_in_bytes() { return metadata_offset_in_bytes(); }


Also delete line 51 ?

coleenp · 2025-09-02T20:19:06Z

src/hotspot/share/runtime/javaThread.cpp

-  assert(_held_monitor_count >= _jni_monitor_count || is_exiting(), "Monitor count discrepancy detected - held count "
-         "%zd is less than JNI count %zd", _held_monitor_count, _jni_monitor_count);
+  // Nothing to do. Just do some sanity check.
+  assert(_held_monitor_count == 0, "counter should not be used");


In further cleanup, can we now remove _held_monitor_count next?

coleenp · 2025-09-02T20:20:02Z

src/hotspot/share/runtime/lightweightSynchronizer.cpp

-// an inflated ObjectMonitor* for a monitor, and expects to throw a
-// java.lang.IllegalMonitorStateException if it is not held by the current
-// thread. Such as notify/wait and jni_exit. LM_LIGHTWEIGHT keeps it invariant
+// ObjectMonitor* when lightweight locking is used. It is used from contexts


I guess you don't need the phrase "when lightweight locking is used".

coleenp · 2025-09-02T20:22:45Z

src/hotspot/share/runtime/lightweightSynchronizer.cpp

-  // that the locking_thread == Thread::current() or is suspended throughout the call by
-  // some other mechanism.
-  // Even with LM_LIGHTWEIGHT the thread might be nullptr when called from a non
+  // The JavaThread* locking_thread parameter is only used by lightweight locking and


Same here. suggestion:

// The JavaThread* locking parameter requires that the locking_thread == JavaThread::current, or is suspended // throughout the call by some other mechanism.

coleenp · 2025-09-02T20:27:14Z

src/hotspot/share/runtime/synchronizer.cpp

-    // dropped by the calling thread.
-    monitor = inflate(current, obj(), inflate_cause_notify);
-  }
+  monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);


Declare and initialize on the same line:

ObjectMonitor* monitor = LightwightSynchronizer::inflate_locked_or_imse(obj...);

coleenp · 2025-09-02T20:29:29Z

src/hotspot/share/runtime/synchronizer.cpp

-    // dropped by the calling thread.
-    monitor = inflate(current, obj(), inflate_cause_notify);
-  }
+  monitor = LightweightSynchronizer::inflate_locked_or_imse(obj(), inflate_cause_notify, CHECK);


same here with
ObjectMonitor* monitor = LIght ...

I think we should have another RFE to look at eliminating the middle call. Call these in LIghtweightSynchronizer::notify, notifyAll and waitInterruptably directly and remove these functions.

coleenp · 2025-09-02T20:32:12Z

src/hotspot/share/runtime/synchronizer.inline.hpp

@@ -45,11 +45,7 @@ inline ObjectMonitor* ObjectSynchronizer::read_monitor(Thread* current, oop obj,
 inline void ObjectSynchronizer::enter(Handle obj, BasicLock* lock, JavaThread* current) {
  assert(current == Thread::current(), "must be");

-  if (LockingMode == LM_LIGHTWEIGHT) {
    LightweightSynchronizer::enter(obj, lock, current);


In the further RFE, we should remove these dispatch functions too.

8365190: Remove LockingMode related code from share

71038b7

openjdk bot added graal [email protected] serviceability [email protected] hotspot [email protected] shenandoah [email protected] labels Sep 2, 2025

fbredber marked this pull request as ready for review September 2, 2025 11:03

openjdk bot added the rfr Pull request is ready for review label Sep 2, 2025

albertnetymk approved these changes Sep 2, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 2, 2025

robcasloz reviewed Sep 2, 2025

View reviewed changes

coleenp reviewed Sep 2, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

8365190: Remove LockingMode related code from share #27041

8365190: Remove LockingMode related code from share #27041

fbredber commented Sep 2, 2025 •

edited by openjdk bot

Loading

Uh oh!

bridgekeeper bot commented Sep 2, 2025

Uh oh!

openjdk bot commented Sep 2, 2025 •

edited

Loading

Uh oh!

openjdk bot commented Sep 2, 2025

Uh oh!

mlbridge bot commented Sep 2, 2025

Uh oh!

robcasloz Sep 2, 2025

Uh oh!

coleenp left a comment

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

coleenp Sep 2, 2025

Uh oh!

Uh oh!

8365190: Remove LockingMode related code from share #27041

Are you sure you want to change the base?

8365190: Remove LockingMode related code from share #27041

Conversation

fbredber commented Sep 2, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Reviewing

Uh oh!

bridgekeeper bot commented Sep 2, 2025

Uh oh!

openjdk bot commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Sep 2, 2025

Uh oh!

mlbridge bot commented Sep 2, 2025

Webrevs

Uh oh!

Choose a reason for hiding this comment

Uh oh!

coleenp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

fbredber commented Sep 2, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Sep 2, 2025 •

edited

Loading