RFR: 8011218 Kitchensink hanged, likely NMT is to blame

[Coleen Phillimore]

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
>>>>>
>>>>>
>>>
>>