RFR(XL): 8167108 - SMR and JavaThread Lifecycle

[David Holmes]

Please ignore this gaseous brain explosion. :)

Thanks,
David

On 12/10/2017 7:30 AM, David Holmes wrote:
> On 12/10/2017 1:32 AM, coleen.phillimore at oracle.com wrote:
>>
>> Hi,  From my initial look at this, I really like new interface for 
>> walking the threads list, except every instance but 2 uses of 
>> JavaThreadIterator has a preceding ThreadsListHandle declaration.
>>
>> +  ThreadsListHandle tlh;
>> +  JavaThreadIterator jti(tlh.list());
>>
>>
>> Could there be a wrapper that embeds the ThreadsListHandle, like:
>>
>> class JavaThreadsListIterator {
>>      ThreadsListHandle _tlh;
>> ...
>> }
> 
> The ThreadsListHandle could not itself be a stack-object in that case.
> 
> David
> 
>> Thanks,
>> Coleen
>>
>> On 10/9/17 3:41 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> We have a (eXtra Large) fix for the following bug:
>>>
>>> 8167108 inconsistent handling of SR_lock can lead to crashes
>>> https://bugs.openjdk.java.net/browse/JDK-8167108
>>>
>>> This fix adds a Safe Memory Reclamation (SMR) mechanism based on
>>> Hazard Pointers to manage JavaThread lifecycle.
>>>
>>> Here's a PDF for the internal wiki that we've been using to describe
>>> and track the work on this project:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/SMR_and_JavaThread_Lifecycle-JDK10-04.pdf 
>>>
>>>
>>> Dan has noticed that the indenting is wrong in some of the code quotes
>>> in the PDF that are not present in the internal wiki. We don't have a
>>> solution for that problem yet.
>>>
>>> Here's the webrev for current JDK10 version of this fix:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8167108-webrev/jdk10-04-full
>>>
>>> This fix has been run through many rounds of JPRT and Mach5 tier[2-5]
>>> testing, additional stress testing on Dan's Solaris X64 server, and
>>> additional testing on Erik and Robbin's machines.
>>>
>>> We welcome comments, suggestions and feedback.
>>>
>>> Daniel Daugherty
>>> Erik Osterlund
>>> Robbin Ehn
>>