Bug ID: JDK-8344261 Obsolete the LockingMode flag and related code

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.

Other
tbdUnresolved

[~cjplummer] I think this task is effectively complete as far as the LockingMode and any associated warnings is concerned. Those PL entries should now be able to be removed. I created a new sub-task for that: JDK-8370257
21-10-2025
There are a number of tests failing due the warning produced and are problem listed because of this flag. I seem to recall some discussion on whether or not the warning should instead be filtered by the tests so they don't need to be problem listed, and it was decided to wait for this fix instead. However, this fix is a long time in coming, and in the meantime the tests remain problem listed. BTW, I might be remembering this wrong. I also seem to recall that we were going to remove the LockingMode test task that was causing the warning to appear. Maybe that has already been done and these tests don't need to be problem listed anymore.
20-10-2025
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

Relates :	JDK-8334299 - Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR
Relates :	JDK-8336325 - Add back UseHeavyMonitors as a develop option

JDK-8359437 :	Make users and test suite not able to set LockingMode flag - Resolved
JDK-8364141 :	Remove LockingMode related code from x86 - Resolved
JDK-8364406 :	Remove LockingMode related code from aarch64 - Resolved
JDK-8364570 :	Remove LockingMode related code from riscv64 - Resolved
JDK-8365146 :	Remove LockingMode related code from ppc64 - Resolved
JDK-8365188 :	Remove LockingMode related code from s390 - Resolved
JDK-8365189 :	Remove LockingMode related code from arm32 - Resolved
JDK-8365190 :	Remove LockingMode related code from share - Resolved
JDK-8365191 :	Cleanup after removing LockingMode related code - Resolved
JDK-8367601 :	Remove held_monitor_count - Resolved
JDK-8367982 :	Unify ObjectSynchronizer and LightweightSynchronizer - Resolved
JDK-8370257 :	Remove ProblemListed tests from ProblemList.txt - Resolved