Aside: it is really annoying that jmx-dev mangles the subject such that
cross-posts end up creating two different email threads :(
On 24/07/2013 9:50 PM, Jaroslav Bachorik wrote:
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.
Correct.
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.
Yes.
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.
I'm unclear what the "different paths" are.
David
-----
-JB-
David
-----
Mandy
