RFR(XS) 8055236: Deadlock during NMT2 shutdown on Windows

[Daniel D. Daugherty]

Sounds reasonable to me.

Please add a short blurb to the bug report itself.

Thumbs up.

Dan


On 8/20/14 2:25 PM, Zhengyu Gu wrote:
> Hi Dan,
>
> Before NMT2, MemTracker::shutdown() only sets flag that signals a 
> pending shutdown request, there is no lock taken. Upon seeing the 
> shutdown pending flag, NMT worker thread actually does the real 
> cleanup work.
>
> Thanks,
>
> -Zhengyu
>
>
>
> On 8/20/2014 4:04 PM, Daniel D. Daugherty wrote:
>> On 8/20/14 7:21 AM, Zhengyu Gu wrote:
>>> The problem is caused by acquiring locks inside 
>>> MemTracker::shutdown(), which could be held by threads that have 
>>> been already killed.
>>>
>>> Given the MemTracker::shutdown() call is on JVM exiting path, the 
>>> call is not necessary, should be removed.
>>>
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055236
>>> Webrev: http://cr.openjdk.java.net/~zgu/8055236/webrev.00/ 
>>> <http://cr.openjdk.java.net/%7Ezgu/8055236/webrev.00/>
>>
>> src/os/windows/vm/os_windows.cpp
>>     No comments.
>>
>> I have no issues with removing the work around code, but there is
>> no analysis here or in the bug report that explains why this work
>> around is no longer necessary. There's also no explanation about
>> why this deadlock is seen now and why it wasn't seen before NMT2.
>>
>> I'll hold off on a thumbs up until I see some reasonable analysis.
>>
>> Dan
>>
>>
>>>
>>>
>>> Test:
>>>    Tested on Windows x64 with following tests:
>>>      nsk/jvmti/scenarios/allocation
>>>      runtime/ParallelClassLoading
>>>
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>
>