RFR: 8264393: JDK-8258284 introduced dangling TLH race

[Daniel D.Daugherty]

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.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/3255

Commit messages:
 - 8264393.00.patch

Changes: https://git.openjdk.java.net/jdk/pull/3272/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3272&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264393
  Stats: 61 lines in 2 files changed: 22 ins; 21 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3272.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3272/head:pull/3272

PR: https://git.openjdk.java.net/jdk/pull/3272