JDK-8305999 : Add experimental -XX:LockingMode flag
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 21
  • Submitted: 2023-04-14
  • Updated: 2024-06-18
  • Resolved: 2023-05-05
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Description
Summary
-------

Add a command line flag to select different locking modes in HotSpot.

Problem
-------

The current stack-locking implementation does not work well with compact object headers (JDK-8294992) because it racily overloads objects' headers. JDK-8291555 implements an alternative locking scheme that works much better with compact object headers. In order to provide extra safety in the evolution of HotSpot the new feature should be guarded by a flag, and the current (legacy) stack-locking be kept, until we are sufficiently sure that no unexpected regressions arise by the new locking implementation.
In addition to that, there are ongoing efforts to implement a new monitor locking ("Java Object Monitors"), which would also require a similar way to select the new vs old implementation.

Solution
--------

JDK-8291555 introduces a flag -XX:Locking mode that currently provides 3 settings:

 - 0: Heavy monitors only (the same as current -XX:+UseHeavyMonitors)
 - 1: Legacy stack-locking, with monitors as second tier (current default)
 - 2: New lightweight locking, with monitors as second tier

The flag can be extended in later enhancements (e.g. "Java Object Monitors") to provide options for other locking implementations and combinations.

The flag is experimental, with the intention to leave it that way, because we will likely remove options (e.g. the legacy stack-locking) and add new options (e.g. Java Object Monitors). Also, the flag is not really intended to be used by end-users, but mostly for HotSpot engineers to facilitate correctness and performance testing and a migration path from legacy to new implementations. Also, the compact object monitors implementation will programatically select an appropriate locking mode when enabled.

Specification
-------------
```
diff --git a/src/hotspot/share/runtime/globals.hpp b/src/hotspot/share/runtime/globals.hpp
index c67b17ae3fb1..169424ab8eef 100644
--- a/src/hotspot/share/runtime/globals.hpp
+++ b/src/hotspot/share/runtime/globals.hpp
@@ -1974,6 +1974,13 @@ const int ObjectAlignmentInBytes = 8;
           false AARCH64_ONLY(DEBUG_ONLY(||true)),                           \
              "Mark all threads after a safepoint, and clear on a modify "   \
              "fence. Add cleanliness checks.")                              \
+                                                                            \
+  product(int, LockingMode, LM_LEGACY, EXPERIMENTAL,                        \
+          "Select locking mode: "                                           \
+          "0: monitors only, "                                              \
+          "1: monitors & traditional stack-locking (default), "             \
+          "2: monitors & new lightweight locking")                          \
+          range(0, 2)                                                       \
 
 // end of RUNTIME_FLAGS
```

Comments
[~dholmes] and [~rkennke], with my CSR lead hat on, I think it is simplest to keep the rule of "the JEP should (usually) have a CSR" even if the CSR is just a vacuous one -- "no exported interface changes".
09-05-2023

[~rkennke] I'm finding the process for an "experimental" JEP to be somewhat unclear in this regard. The JEP process requires CSR requests but experimental flags do not. Any CSR request for the experimental feature has littler to no bearing on any future attempt to make the feature non-experimental. For the sake of the JEP process perhaps the CSR requests should proceed.
08-05-2023

[~dholmes] Ok thank you for the explanation. I thought that while not strictly necessary, it might be useful. I want to be sure here: For the addition of the -XX:+UseCompactObjectHeaders flag (JDK-8305895) we're not going to need a CSR? I think that new flag is more user-facing than -XX:LockingMode, and thus perhaps warrants a CSR? Or should I drop JDK-8306000?
08-05-2023

To be very clear this CSR request achieves almost nothing in my opinion. This request is for the addition of an experimental feature under an experimental flag. Such a change should have "zero" impact on use of the VM when the feature is not enabled and that is the compatibility risk that is being assessed in this CSR request. When the time comes to make this feature non-experimental, or enabled by default, then a new CSR request will be needed and the compatibility issues will be completely different.
08-05-2023

For administratively simplicity, even though a CSR for this work may not be strictly required, I'm voting to Approve it.
05-05-2023

This is the addition of an experimental flag and as such does not require an approved CSR request. At some point if the feature moves from being experimental then a CSR request would be needed. Any change to the default value of this flag in the future would require a CSR request for the change in behaviour.
02-05-2023

Moving back to Provisional until there are reviewers, at which point the CSR can be Finalized.
28-04-2023

[~stuefe], [~dcubed], [~dholmes], [~shade] Since you have all been involved in reviewing and/or working on JDK-8291555, would you please review this corresponding CSR? Thank you!
28-04-2023

[~darcy] Oh, indeed that is what I wanted. Let me find some reviewers. Sorry for the noise, I am not very familiar with the CSR process. Thank you!
28-04-2023

[~rkennke], did you mean to Finalize this CSR for its second round of review rather than re-Proposing the CSR? If so, please have one or more HotSpot engineers review the request first before the request is Finalized.
28-04-2023

Moving to Provisional for JDK 21.
20-04-2023