Bug ID: JDK-8315880 Change LockingMode default from LM_LEGACY to LM

JDK-8315880 : Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 22,23

Priority: P4
Status: Closed
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2023-09-07
Updated: 2024-01-18
Resolved: 2023-09-20

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 22
22 b16Fixed

Related Reports

CSR :	JDK-8315881 - Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
Cloners :	JDK-8319251 - [REDO] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
Relates :	JDK-8316921 - Perf regressions up to 14% in b16 many benchmarks all platforms
Relates :	JDK-8316397 - StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with "SingleStep event is NOT expected"
Relates :	JDK-8316880 - AArch64: "stop: Header is not fast-locked" with -XX:-UseLSE since JDK-8315880
Relates :	JDK-8316401 - sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock"
Relates :	JDK-8316746 - Top of lock-stack does not match the unlocked object
Relates :	JDK-8316751 - IllegalMonitorStateException: current thread is not owner
Relates :	JDK-8315884 - New Object to ObjectMonitor mapping
Relates :	JDK-8317262 - LockStack::contains(oop) fails "assert(t->is_Java_thread()) failed: incorrect cast to JavaThread"
Relates :	JDK-8318895 - Deoptimization results in incorrect lightweight locking stack
Relates :	JDK-8323781 - [lworld] Synchronization on inline type does not throw IllegalMonitorStateException with lightweight locking
Relates :	JDK-8291555 - Implement alternative fast-locking scheme
Relates :	JDK-8315061 - Make LockingMode a product flag
Relates :	JDK-8316735 - Print LockStack in hs_err files
Relates :	JDK-8324114 - [lworld] GTestWrapper.java fails with "assert(LockingMode == LM_LEGACY) failed: should only be called with legacy stack locking"
Relates :	JDK-8319253 - [BACKOUT] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT

Description

The LockingMode flag from JDK-8291555 was implemented as an
experimental flag. We made it a regular product flag in JDK22 in
preparation for project Lilliput (See JDK-8315061).

In the next release, we plan to change the default of the LockingMode
flag from LM_LEGACY to LM_LIGHTWEIGHT. Project Lilliput needs
the LockingMode flag to be LM_LIGHTWEIGHT. In a release sometime
after the next release, we place to remove support for LM_LEGACY.

Insert additional justification for Lilliput here.

Comments

Due to performance issues this change is being backed out of 22 and be re-done for 23.
01-11-2023
This fix was integrated in jdk-22+16-1240.
04-10-2023
Changeset: 455cfae1 Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2023-09-20 15:27:27 +0000 URL: https://git.openjdk.org/jdk/commit/455cfae1e137ff3055b3cc858e8954f60bdf3147
20-09-2023
Mach5 testing of cr1 version of the patch (run3): open baseline is ce93d27fe5725af6424573ceb29cc12f20165f69 Changes in this patch version: - cr0 - change the default of LockingMode to LM_LIGHTWEIGHT - cr1 - change tier3-rt-LightweightLocking task into tier3-rt-LegacyLocking Mach5 Tier1: - no failures Mach5 Tier2: - no failures Mach5 Tier3: - no failures Mach5 Tier4: - 1 known, unrelated test failure: - java/awt/Mouse/EnterExitEvents/DragWindowTest.java due to JDK-8298823 - 1 known, unrelated failed task: - sjavac failed with "IOException caught during compilation: Could not connect to server" Mach5 Tier5: - no failures Mach5 Tier6: - no failures Mach5 Tier7: - no failures Mach5 Tier8: - 2 known, unrelated test failures: - compiler/interpreter/TestVerifyStackAfterDeopt.java due to JDK-8316392 - applications/javafuzzer/BigTest.java due to JDK-8308392
20-09-2023
The Tech Leads and Managers meeting has requested that we try to get this change into JDK22 so that it can be available earlier for the Lilliput project. We definitely have the soak time available in JDK22.
18-09-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/15797 Date: 2023-09-18 20:47:13 +0000
18-09-2023
Mach5 testing of cr1 version of the patch (run2): open baseline is ce93d27fe5725af6424573ceb29cc12f20165f69 Changes in this patch version: - cr0 - change the default of LockingMode to LM_LIGHTWEIGHT - cr1 - change tier3-rt-LightweightLocking task into tier3-rt-LegacyLocking Mach5 Tier1: - no failures Mach5 Tier2: - no failures Mach5 Tier3: - no failures Mach5 Tier4: - 2 known, unrelated client test failures: - java/awt/Mouse/EnterExitEvents/DragWindowTest.java due to JDK-8298823 Mach5 Tier5: - 1 unknown, possibly related failure: - sun/tools/jhsdb/JStackStressTest.java failed with: "InternalError: We should have found a thread that owns the anonymous lock" - filed new bug: JDK-8316401 sun/tools/jhsdb/JStackStressTest.java failed with "InternalError: We should have found a thread that owns the anonymous lock" Mach5 Tier6: - no failures Mach5 Tier7: - no failures Mach5 Tier8: - 2 known, unrelated test failures: - compiler/interpreter/TestVerifyStackAfterDeopt.java due to JDK-8316392 - applications/javafuzzer/BigTest.java due to JDK-8308392
18-09-2023
Mach5 testing of cr1 version of the patch: open baseline is ce93d27fe5725af6424573ceb29cc12f20165f69 Changes in this patch version: - cr0 - change the default of LockingMode to LM_LIGHTWEIGHT - cr1 - change tier3-rt-LightweightLocking task into tier3-rt-LegacyLocking Mach5 Tier1: - no failures Mach5 Tier2: - no failures Mach5 Tier3: - no failures Mach5 Tier4: - 1 unknown failure: - serviceability/jvmti/stress/StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with "FATAL ERROR in native method: SingleStep event is NOT expected" - filed new bug: JDK-8316397 StackTrace/Suspended/GetStackTraceSuspendedStressTest.java failed with "SingleStep event is NOT expected" Mach5 Tier5: - no failures Mach5 Tier6: - no failures Mach5 Tier7: - no failures Mach5 Tier8: - 2 known, unrelated test failures: - vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java due to JDK-8299493 - applications/runthese/RunThese8H.java due to JDK-8312631
18-09-2023
Mach5 testing of cr0 version of the patch: open baseline is 4c6d7fc2584ce969649d06a366fb4b8688a3aaa9 Mach5 Tier1: - no failures Mach5 Tier2: - no failures Mach5 Tier3: - no failures Mach5 Tier4: - 2 known, unrelated test failures: - javax/swing/PopupFactory/6276087/NonOpaquePopupMenuTest.java - javax/swing/Popup/TaskbarPositionTest.java Mach5 Tier5: - 5 known, unrelated test failures: - java/foreign/TestLinker.java due to JDK-8315891 - 4x vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java due to JDK-8315930 Mach5 Tier6: - 3 known, unrelated test failures: - 3x vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java due to JDK-8315930 Mach5 Tier7: - no failures Mach5 Tier8: - 1 unknown test failure: - applications/runthese/RunThese8H.java test task with JVM args of: -XX:+UseZGC -XX:+ZGenerational on linux-x64-debug timed out at 600 minutes. I cannot find a bug tracking an existing issue like this.
15-09-2023
Please note that the fix version is currently '23' since that was the original plan. This may change to '22' depending on discussions.
07-09-2023