RFR: 8011218 Kitchensink hanged, likely NMT is to blame
Karen Kinnear
karen.kinnear at oracle.com
Wed Apr 24 14:04:39 PDT 2013
Reviewed.
I really like this approach. And if we run into any additional delay issues, you have the mechanism
in place to add any needed check_safepoint calls. Thank you for doing it this way.
thanks,
Karen
On Apr 24, 2013, at 3:00 PM, Coleen Phillimore wrote:
>
> Reviewed.
> Coleen
>
> On 4/24/2013 12:21 AM, David Holmes wrote:
>> Thanks Zhengyu, this looks okay to me.
>>
>> David
>>
>> On 24/04/2013 12:23 AM, Zhengyu Gu wrote:
>>> Round 2:
>>>
>>> Based on feedback from David, Dan and Karen, transition thread state to _thread_in_native is dangerous. This fix keeps query thread state in _thread_in_vm, but make locks safepoint aware and explicitly check for safepoint during lengthy baseline operation.
>>>
>>> Webrev: http://cr.openjdk.java.net/~zgu/8011218/webrev.01/
>>>
>>>
>>> Test:
>>> - Manual test, ran kitchensink stress tests with additional NMT queries to stress query threads, monitored gc.log.
>>> After 17 hours, found no long pause between gc messages.
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>>
>>>
>>>
>>> On Apr 18, 2013, at 9:46 AM, Zhengyu Gu wrote:
>>>
>>>> Hi David,
>>>>
>>>> On 4/17/2013 10:59 PM, David Holmes wrote:
>>>>> On 18/04/2013 7:33 AM, Zhengyu Gu wrote:
>>>>>> The thread that runs NMT query can be blocked on NMT snapshot lock,
>>>>>> which prevents JVM to reach safepoints.
>>>>>
>>>>> How? I don't understand this part.
>>>>>
>>>> Currently, NMT acquires locks without safepoint checks (I assumed that query is coming from _thread_in_native, obviously a mistake). Since NMT query can be lengthy, I still want it to run in _thread_in_native state.
>>>>
>>>>>> NMT query does not change Java heap, it does not have to stop for
>>>>>> safepoints. So the solution is to transition to _vm_in_native state,
>>>>>> before executing NMT query.
>>>>>
>>>>> To add to Dan's comments you don't need the assertion:
>>>>>
>>>>> 81 assert(((JavaThread*)thr)->thread_state() == _thread_in_vm,
>>>>> 82 "Just check");
>>>>>
>>>>> because this will be checked by ThreadToNativeFromVM.
>>>>>
>>>>> However I am far from convinced that it is valid to make this state change. You need to be sure that nothing you call from this method - including debug/tracing code that might only be enabled under certain flags - will assume/expect that you are _thread_in_vm.
>>>>>
>>>> NMT query code acquires two locks, both with no_safepoint_check. Besides assertion and tty->print(), I don't recall it uses any vm specific methods, but is there a way to ensure that?
>>>>
>>>> Thanks,
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>>> Thanks,
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>>
>>>>>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8011218
>>>>>> Public bug: not available
>>>>>> Webrev: http://cr.openjdk.java.net/~zgu/8011218/webrev.00/
>>>>>> <http://cr.openjdk.java.net/%7Ezgu/8011218/webrev.00/>
>>>>>>
>>>>>>
>>>>>> Test:
>>>>>> - Run Kitchensink stress test on low power machine Linux x86 machine
>>>>>> with GC trace on, stress out NMT query thread by submitting NMT query in
>>>>>> a loop, NMT query executions become very slow, but GC trace continues
>>>>>> generating message, and does not show long pause.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>>
>>>>
>>>
>
More information about the hotspot-runtime-dev
mailing list