Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8305999

Add experimental -XX:LockingMode flag

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P4 P4
    • 21
    • hotspot
    • None
    • behavioral
    • minimal
    • Assuming no implementation errors, there should at most be performance differences between the different locking modes.
    • add/remove/modify command line option
    • Implementation

      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

            rkennke Roman Kennke
            rkennke Roman Kennke
            Aleksey Shipilev, Daniel Daugherty
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: