RFR: 8011218 Kitchensink hanged, likely NMT is to blame

Zhengyu Gu zhengyu.gu at oracle.com
Tue Apr 23 07:23:10 PDT 2013


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