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

Deprecate UseRTM* for removal

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Withdrawn
    • Icon: P4 P4
    • 20
    • hotspot
    • None
    • behavioral
    • minimal
    • Hide
      Using RTM instructions for locking should only have a performance impact. And since modern CPUs either don't have the feature or have it disabled (leading to always aborting transactions), the impact of RTM would either be not measurable or even negative.
      In theory it is possible that an application enables RTM locking and logging and then expects to observe certain specific RTM related logging statements, but this seems to be an obscure case.
      Show
      Using RTM instructions for locking should only have a performance impact. And since modern CPUs either don't have the feature or have it disabled (leading to always aborting transactions), the impact of RTM would either be not measurable or even negative. In theory it is possible that an application enables RTM locking and logging and then expects to observe certain specific RTM related logging statements, but this seems to be an obscure case.
    • add/remove/modify command line option
    • Implementation

      Summary

      I'd like to deprecate the following product (x86 and ppc) flags for removal: UseRTMLocking UseRTMDeopt UseRTMForStackLocks UseRTMXendForLockBusy

      Problem

      HotSpot supports RTM (restricted transactional memory) to be used for locking and deoptimization. RTM has since been disabled in Intel processors due to security vulnerabilities [0] and IBM removed support for it since its Power 10 line. RTM adds unnecessarily to complexity and maintenance burden.

      [0] https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs

      Solution

      I am proposing to deprecate the relevant flags for removal, and actually remove the flags and all related code in a later release, unless somebody comes up with a good reason and performance comparison to show that it's worth keeping.

      Specification

      diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
      index 019c8cab92ef..200eac857771 100644
      --- a/src/hotspot/share/runtime/arguments.cpp
      +++ b/src/hotspot/share/runtime/arguments.cpp
      @@ -536,6 +536,10 @@ static SpecialFlag const special_jvm_flags[] = {
         { "DynamicDumpSharedSpaces",      JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
         { "RequireSharedSpaces",          JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
         { "UseSharedSpaces",              JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
      +  { "UseRTMLocking",                JDK_Version::jdk(20), JDK_Version::jdk(21), JDK_Version::jdk(22) },
      +  { "UseRTMDeopt",                  JDK_Version::jdk(20), JDK_Version::jdk(21), JDK_Version::jdk(22) },
      +  { "UseRTMForStackLocks",          JDK_Version::jdk(20), JDK_Version::jdk(21), JDK_Version::undefined() },
      +  { "UseRTMXendForLockBusy",        JDK_Version::jdk(20), JDK_Version::jdk(21), JDK_Version::undefined() },
      
         // --- Deprecated alias flags (see also aliased_jvm_flags) - sorted by obsolete_in then expired_in:
         { "DefaultMaxRAMFraction",        JDK_Version::jdk(8),  JDK_Version::undefined(), JDK_Version::undefined() },

            rkennke Roman Kennke
            rkennke Roman Kennke
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: