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

Zhengyu Gu zhengyu.gu at oracle.com
Wed Aug 20 20:28:07 UTC 2014


Will do.

Thanks,

-Zhengyu

On 8/20/2014 4:28 PM, Daniel D. Daugherty wrote:
> 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
>>>>
>>>
>>
>



More information about the hotspot-runtime-dev mailing list