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

JDK-8258284 introduced dangling TLH race

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 17
    • Fix Version/s: 17
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • Introduced In Build:
      b03
    • Introduced In Version:
      17
    • Resolved In Build:
      b17
    • CPU:
      generic
    • OS:
      generic

      Description

      I ported some 20 year old tests using JDK-8262881 in order to help
      test [~rehn]'s fix for JDK-8257831. These tests in combination with
      one piece of the fix from JDK-8257831 revealed a bug in my fix for
      JDK-8258284 from back in Dec 2020.

      The race revealed by the ported tests from JDK-8262881 happens
      only with nested ThreadsListHandles. When TLH2 is destroyed, the
      thread updates its threads_hazard_ptr from the TLH2-list to the
      TLH1-list; I made this change back in 2020.12 using JDK-8258284.
      The threads_hazard_ptr can be observed by a thread calling
      ThreadsSMRSupport::free_list() as a stable ThreadsList at the same
      time as the TLH1 destructor is decrementing the nested_handle_cnt
      that permits the ThreadsList to be freed. So the thread calling
      ThreadsSMRSupport::free_list() thinks it has a stable hazard ptr
      (TLH1-list), but that hazard ptr can be freed and causes lots of
      confusion.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              dcubed Daniel Daugherty
              Reporter:
              dcubed Daniel Daugherty
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: