On 07/24/2013 01:21 PM, David Holmes wrote: > On 24/07/2013 7:31 PM, Mandy Chung wrote: >> >> On 7/24/2013 4:50 PM, shanliang wrote: >>> So we have 2 kinds of issues here: >>> 1) the test related, like Thread state checking, we can fix them in >>> the test >>> 2) MBean.getThreadCount() issue, we can create a bug to trace it (add >>> your test case to the bug), and add a workaround (sleep or call 2 >>> times) in the test to make the test pass. Mandy is the expert and >>> better to get her opinion. >> >> It's probably a race in the VM implementation in determining the thread >> count. You will need to diagnose the VM implementation and compare the >> thread list and the implementation of getting the thread count (check >> hotspot/src/share/vm/services/threadService.cpp) > > There is a considerable code path between the point where a terminating > thread causes Thread.join() to be allowed to return, and the point where > the live thread count gets decremented. So using join() does not help > here. Arguably JVMTI should have based its counts around the lifecycle > of the Java thread not the underlying native thread.
So, if I understand it correctly, it is not possible to get 100% accuracy of the thread related counters in situations when you create and terminate a number of threads rapidly. In that case this test could be fixed with a small waiting period after all the joined threads were terminated - just to make sure that all the exiting threads were properly collected. The only question remains whether a bug should be filed for the discrepancy between the thread counters obtained from ThreadMXBean and the ones coming from different paths. -JB- > > David > ----- > >> Mandy
