RFR: 8011218 Kitchensink hanged, likely NMT is to blame

[Daniel D. Daugherty]

On 4/17/13 3:33 PM, Zhengyu Gu wrote:
> The thread that runs NMT query can be blocked on NMT snapshot lock, 
> which prevents JVM to reach safepoints.
>
> 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.
>
>
> 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/>

src/share/vm/services/nmtDCmd.cpp
     Since this function has a TRAPS parameter, you don't need to
     fetch the current thread:

     79   Thread* thr = Thread::current();
     80   assert(thr->is_Java_thread(), "Must be a JavaThread");
     81   assert(((JavaThread*)thr)->thread_state() == _thread_in_vm,
     82     "Just check");

     Delete line 79 and change 'thr' usage on lines 80-81 -> 'THREAD'.

     83   // Transition to _vm_in_native state, since NMT query does not 
touch
     84   // Java heap.

     The thread state is '_thread_in_native' not '_vm_in_native'. Also,
     I think it is more than just not touching the Java heap. This 
"JavaThread"
     shouldn't be doing any "Java" operations, but I don't remember if we
     have anything to enforce that.

Dan


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