JDK-8344261 : Obsolete the LockingMode flag and related code
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2024-11-15
  • Updated: 2025-08-09
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 26
26Unresolved
Related Reports
Relates :  
JDK-8334299 - Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR
Relates :  
JDK-8336325 - Add back UseHeavyMonitors as a develop option
Sub Tasks
JDK-8359437 :  
Make users and test suite not able to set LockingMode flag - Resolved
JDK-8364141 :  
Remove LockingMode related code from x86 - In Progress
JDK-8364406 :  
Remove LockingMode related code from aarch64 - In Progress
JDK-8364570 :  
Remove LockingMode related code from riscv64 - In Progress
JDK-8365146 :  
Remove LockingMode related code from ppc64 - In Progress
JDK-8365188 :  
Remove LockingMode related code from s390 - In Progress
JDK-8365189 :  
Remove LockingMode related code from arm - New
JDK-8365190 :  
Remove LockingMode related code from share - New
JDK-8365191 :  
Cleanup after removing LockingMode related code - New
Description
The LockingMode flag was deprecated in JDK 24 and marked for obsoletion in JDK 26.
Comments
The CSR states: > Deprecate LockingMode in JDK 24, make obsolete in 26 and remove in 27. I see no reason to revisit that decision
19-11-2024
Unless you can dig up the complete history of the decision we can't just change it. As I said my recollection is that the code was deliberately left in place in the next LTS.
19-11-2024
The wording in the CSR link is a probably intentionally vague. The deprecation process is that we deprecate in release n, obsolete in release n+x, and remove the option in n+x+1. I do sort of remember we decided for this it should be JDK 24, 26, 27 making the value of x=2. But the CSR comment doesn't actually say that. So I'm wondering if we can and should make the decision to obsolete the option (removing underlying code) in JDK 25.
19-11-2024
I was wondering why we decided this and whether it was a good decision. Maybe it would be better to remove the code in JDK 25.
18-11-2024
[~coleenp] IIRC the decision to obsolete in 26 was so that it would remain available in JDK 25 LTS. I don't recall where that decision was made/recorded, but there are numerous references to it e.g. https://bugs.openjdk.org/browse/JDK-8331076?focusedId=14694107&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14694107
18-11-2024
Did we decide to do this in JDK 26 and not JDK 25?
15-11-2024
Fix version 26 doesn't exist yet so marked tbd
15-11-2024