RFR: 8258284: clean up issues with nested ThreadsListHandles

[Daniel D.Daugherty]

On Fri, 18 Dec 2020 17:40:22 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> While working on JDK-8231627, I discovered there were issues with nested
>> ThreadsListHandles. I added a new test to verify how ThreadsListHandles and
>> nested ThreadsListHandles are supposed to work. I found two bugs:
>> 
>> 1) A failure to restore the expected _threads_hazard_ptr when a nested
>>     ThreadsListHandle is destroyed.
>> 
>> 2) A failure to decrement _nested_threads_hazard_ptr_cnt when a nested
>>     ThreadsListHandle is destroyed.
>> 
>> The second failure mode is what tripped up my fix for JDK-8231627 so that
>> bug fix depends on this bug fix.
>> 
>> Mach5 Tier[1-3] testing has no regressions (macOSX testing is incomplete at the moment).
>
> src/hotspot/share/runtime/threadSMR.cpp line 476:
> 
>> 474:   // Clear the hazard ptr so we can go through the fast path below and
>> 475:   // acquire a nested stable ThreadsList.
>> 476:   _thread->_threads_hazard_ptr = NULL;
> 
> Should be Atomic::store()

That's a bug in the baseline also, but I can fix it since I'm already
touching that line.

I also noticed that we weren't really consistent about using atomic
operations with the _threads_hazard_ptr field and we don't always
use the (mis-named) get_threads_hazard_ptr(). I plan to make
another cleanup pass with a different bug ID for those.

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

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