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

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed May 2 12:43:04 UTC 2018


On 5/2/18 6:23 AM, Robbin Ehn wrote:
> On 2018-05-01 22:07, Daniel D. Daugherty wrote:
>> On 5/1/18 3:43 PM, Erik Österlund wrote:
>>> Hi Dan,
>>>
>>> In case my opinion counts, I think this looks great.
>
> +1

Thanks for the re-review!

>
>>
>> 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.
>
> Yes, thanks Dan!

You are also quite welcome.

Dan


>
> /Robbin
>
>>
>> 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
>>>
>>



More information about the hotspot-runtime-dev mailing list