RFR: 8264393: JDK-8258284 introduced dangling TLH race

[Daniel D.Daugherty]

On Tue, 30 Mar 2021 16:35:23 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> 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.

@fisk, @robehn and @dholmes-ora - This one is a Threads-SMR race fix that I used
"JDK-8264123 add ThreadsList.is_valid() support" to find. It would be good to have
you guys brush off your Thread-SMR memories and review this fix.

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

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