RFR: 8011218 Kitchensink hanged, likely NMT is to blame

[Zhengyu Gu]

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