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

Deprecate UseRTM* flags for removal

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P4 P4
    • 23
    • 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

      Deprecate the following x86 HotSpot product RTM flags for removal:

      UseRTMLocking, UseRTMDeopt, RTMRetryCount

      Problem

      HotSpot supports RTM (restricted transactional memory) to be used for locking since JDK 8 on Intel's CPU (JDK-8031320). It was added to other platforms but has since been disabled and removed on all but Intel processors. There was attempt to deprecate it (JDK-8292082) during JDK 20 development but at that time it was decided to keep it. Recently we discussed this with Intel and they agreed with RTM deprecation and removal from HotSpot.

      RTM adds complexity and maintenance burden to HotSpot locking code. It was never enabled by default because it only helped some cases of heavy lock contention. We don't test it since JDK 14 after we problem-list related tests.

      New LIGHTWEIGHT locking implementation will not support it (JDK-8320321).

      Solution

      I propose to deprecate the related flags and remove the flags and all related code in a later release.

      Specification

      diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
      index 6885cde4ee3..81b73a015fb 100644
      --- a/src/hotspot/share/runtime/arguments.cpp
      +++ b/src/hotspot/share/runtime/arguments.cpp
      @@ -501,7 +501,11 @@ static SpecialFlag const special_jvm_flags[] = {
         { "RequireSharedSpaces",          JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
         { "UseSharedSpaces",              JDK_Version::jdk(18), JDK_Version::jdk(19), JDK_Version::undefined() },
         { "RegisterFinalizersAtInit",     JDK_Version::jdk(22), JDK_Version::jdk(23), JDK_Version::jdk(24) },
      -
      +#if defined(X86)
      +  { "UseRTMLocking",                JDK_Version::jdk(23), JDK_Version::jdk(24), JDK_Version::jdk(25) },
      +  { "UseRTMDeopt",                  JDK_Version::jdk(23), JDK_Version::jdk(24), JDK_Version::jdk(25) },
      +  { "RTMRetryCount",                JDK_Version::jdk(23), JDK_Version::jdk(24), JDK_Version::jdk(25) },
      +#endif // X86
         // --- Deprecated alias flags (see also aliased_jvm_flags) - sorted by obsolete_in then expired_in:
         { "CreateMinidumpOnCrash",        JDK_Version::jdk(9),  JDK_Version::undefined(), JDK_Version::undefined() },

            kvn Vladimir Kozlov
            kvn Vladimir Kozlov
            Coleen Phillimore, David Holmes, Vladimir Ivanov
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: