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