RFR(XXS): 8077392 and 8131715 - fix for hang in Contended Locking "fast enter" bucket

[Daniel D. Daugherty]

On 3/24/16 3:12 PM, Vladimir Kozlov wrote:
> On 3/24/16 12:23 PM, David Holmes wrote:
>> Hi Dan,
>>
>> Couldn't pass up the chance to review this - truly great debugging here!
>
> +1
>
> Changes are good.

Thanks!

Dan


>
> Thanks,
> Vladimir
>
>>
>> The changes of course look good.
>>
>> I was surprised to notice that before this fix the Lock argument 
>> (which should be lower-case lock if you don't mind
>> adjusting that) was actually unused in quick_enter! So one has to 
>> wonder why it was passed in.
>>
>> Cheers,
>> David
>>
>>
>>
>> On 23/03/2016 6:41 AM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have fixes for the following two bugs:
>>>
>>>      JDK-8077392 Stream fork/join tasks occasionally fail to complete
>>>      https://bugs.openjdk.java.net/browse/JDK-8077392
>>>
>>>      JDK-8131715 backout the fix for JDK-8079359 when JDK-8077392 is 
>>> fixed
>>>      https://bugs.openjdk.java.net/browse/JDK-8131715
>>>
>>> Both fixes are very, very small and will be bundled together in the
>>> same changeset for obvious reasons.
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/8077392_8131715-webrev/0-jdk9-hs-rt/
>>>
>>> While the fix for JDK-8077392 is a simple 1-liner, the explanation of
>>> the race is much, much longer. I've attached the detailed evaluation
>>> to this RFR; it is a copy of the same note that I added to
>>> https://bugs.openjdk.java.net/browse/JDK-8077392, but the attached
>>> copy has all the indentation white space intact. I don't know why
>>> JBS likes to reformat the notes, but it does... :-(
>>>
>>> Testing:
>>>
>>> - the original failing test is running in a parallel stress config
>>>    on my Solaris X64 server; just under 23 hours and just under
>>>    3000 iterations without a failure in either instance; I'm planning
>>>    to let the stress run go for at least 72 hours.
>>> - RT/SVC nightly equivalent (in progress)
>>>
>>> As always, comments, suggestions and/or questions are welcome.
>>>
>>> Dan