RFR(M): 8191798 redo nested ThreadsListHandle to drop Threads_lock

[Daniel D. Daugherty]

On 5/1/18 3:43 PM, Erik Österlund wrote:
> Hi Dan,
>
> In case my opinion counts, I think this looks great.

As is usual for Thread-SMR stuff, I plan to list both you and I as
contributors and as reviewers. Robbin reviewed internally and I
expect he will chime in here. David H often reviews Thread-SMR stuff
but he's a bit busy right now... I'm hoping Kim B. chimes in since
I think he ran into this issue with some of his recent changes...

So thanks for the (re-)review!


> Thank you for the thorough testing and various improvements of this 
> patch.

You are quite welcome.

Dan


>
> Thanks,
> /Erik
>
> On 2018-05-01 19:00, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> We have a fix for the following Thread-SMR bug:
>>
>>     JDK-8191798 redo nested ThreadsListHandle to drop Threads_lock
>>     https://bugs.openjdk.java.net/browse/JDK-8191798
>>
>> Erik O is the primary author for this fix; I've only made minor tweaks
>> here and there to the comments, the code and the tests. I have the
>> Thread-SMR stress testing setup on my Solaris-X64 server so I'm the
>> one shepherding the fix forward.
>>
>> Summary: Refactor Thread hazard ptrs and nested ThreadsLists into
>>     SafeThreadsListPtr.
>>
>> Hazard ptr management logic remains the same, but the nested ThreadsList
>> management logic uses a linked list of SafeThreadsListPtr and safe 
>> counters
>> instead of a linked list of NestedThreadsList and the Threads_lock.
>>
>>
>> Webrev URLs:
>>
>> http://cr.openjdk.java.net/~dcubed/8191798-webrev/1_for_jdk_jdk.full_no_code_motion/ 
>>
>>     This is the webrev to look at if you want to see the entire
>>     proposed fix without code motion noise.
>>
>> http://cr.openjdk.java.net/~dcubed/8191798-webrev/1_for_jdk_jdk.code_motion_only/ 
>>
>>     This webrev is only code motion and is here for completeness.
>>
>> http://cr.openjdk.java.net/~dcubed/8191798-webrev/1_for_jdk_jdk.full_with_code_motion/ 
>>
>>     This webrev is everything and is here for completeness.
>>
>> Testing:
>> - Mach5 
>> builds-tier1,jdk-tier1,jdk-tier2,jdk-tier3,hs-tier1,hs-tier2,hs-tier3
>>   - multiple rounds - no test failures
>> - Solaris X64 Thread-SMR stress testing - 2 x 24+ hour runs - no 
>> failures
>>   related to these changes
>>
>> Thanks, in advance, for any comments, suggestions or questions.
>>
>> Dan and Erik
>