RFR: 8011218 Kitchensink hanged, likely NMT is to blame

[David Holmes]

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.

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

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