JDK-8319251 : [REDO] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 23
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2023-11-01
  • Updated: 2024-03-29
  • Resolved: 2024-03-20
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 23
23 b15Fixed
Related Reports
Blocks :  
JDK-8320934 - SPECjbb2005 performance with LM_LIGHTWEIGHT and recursive locking changes
Cloners :  
JDK-8315880 - Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
Relates :  
JDK-8329351 - add recursive Java monitor stress testing
Relates :  
JDK-8319253 - [BACKOUT] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT
Relates :  
JDK-8319797 - Recursive lightweight locking: Runtime implementation
Relates :  
JDK-8319799 - Recursive lightweight locking: x86 implementation
Relates :  
JDK-8320321 - RTM locking not supported for LM_LIGHTWEIGHT
Relates :  
JDK-8328831 - MoCrazy.java stress test hangs on linux-x64 with 1024 threads at 7H+
Relates :  
JDK-8316921 - Perf regressions up to 14% in b16 many benchmarks all platforms
Relates :  
JDK-8319796 - Recursive lightweight locking
Relates :  
JDK-8319801 - Recursive lightweight locking: aarch64 implementation
Sub Tasks
JDK-8319253 :  
[BACKOUT] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT - Resolved
JDK-8327089 :  
Release Note: Change LockingMode Default from `LM_LEGACY` to `LM_LIGHTWEIGHT` - Resolved
Description
From original issue:

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.
Comments
Changeset: 000f4d8d Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2024-03-20 19:59:13 +0000 URL: https://git.openjdk.org/jdk/commit/000f4d8d156a48939fd29f8b4dd84b3dfd7d9d95
20-03-2024
At this point, all performance testing and stress testing is complete. I've updated my PRs to the bits that are in jdk-23+15-1169 and a Mach5 Tier1 passed just fine.
20-03-2024
The original switch to use LM_LIGHTWEIGHT by default was done with: JDK-8315880 Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT That change was backed out via: JDK-8319253 [BACKOUT] Change LockingMode default from LM_LEGACY to LM_LIGHTWEIGHT because of the performance problems described in: JDK-8316921 Perf regressions up to 14% in b16 many benchmarks all platforms All but one of the performance problems is resolved by the group of fixes associated with: JDK-8319796 Recursive lightweight locking For the platforms that Oracle performance tested, the relevant sub-tasks are: JDK-8319797 Recursive lightweight locking: Runtime implementation JDK-8319799 Recursive lightweight locking: x86 implementation JDK-8319801 Recursive lightweight locking: aarch64 implementation The last remaining performance problem was with SPECjbb2005 and the following bug was used to track all the performance work and analysis for it: JDK-8328118 Capture SPECjbb2005 results legacy vs. lightweight
20-03-2024
The original backout was so long ago that it made things very messy for the merge on the closed side task definition changes so I opted to just apply the same fix manually on both the open and closed side. Of course, then I ran into the need for the @requires fix so the open side no longer is a backout of a backout...
20-03-2024
Shouldn't this redo simply be a backout of the backout of the original change?
19-03-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17932 Date: 2024-02-20 16:40:05 +0000
17-03-2024
I rebased the project to jdk-23+14-1012 and I'm rerunning Mach5 testing. Mach5 Tier1: - no failures Mach5 Tier2: - no failures Mach5 Tier3: - no failures Mach5 Tier4: - 1 known, unrelated test failure: - java/awt/KeyboardFocusmanager/TypeAhead/ButtonActionKeyTest/ButtonActionKeyTest.java failed due to JDK-8257529 Mach5 Tier5: - no test failures - 2 task failures: - tier5-client-headful-jtreg-closed_test_jdk_jdk_desktop-windows-x64 The tests all passed, but the task failure after uploading the results: [2024-03-13T07:25:55,097Z] TEST TOTAL PASS FAIL ERROR [2024-03-13T07:25:55,097Z] jtreg:closed/test/jdk:jdk_desktop 583 583 0 0 - tier5-gc-singlegen-zgc-vthreads-jdk_loom-windows-x64-debug-windows-x64-1803-or-later The tests all passed, but the task failed after uploading the results: [2024-03-13T02:29:42,429Z] TEST TOTAL PASS FAIL ERROR [2024-03-13T02:29:42,429Z] jtreg:open/test/jdk:jdk_loom 241 241 0 0 Mach5 Tier6: - no failures Mach5 Tier7: - 3 known, unrelated test failures: - 3 tests failed on windows-x64 due to MACH5-5610 Mach5 Tier8: - 2 test failures: - 2 tests failed on windows-x64 due to MACH5-5610 - 1 task failure: - The test suite passed: [2024-03-15T16:07:53,011Z] jtreg:open/test/hotspot/jtreg:vmTestbase_nsk_monitoring [2024-03-15T16:07:53,011Z] 360 360 0 0 However, the task failed during results upload due to a DNS outage.
17-03-2024
This bug is relevant here: JDK-8320321 RTM locking not supported for LM_LIGHTWEIGHT
20-02-2024