Just to be a test, after terminated 8 threads and checked their states by calling Thread.join() (must be same to Thread.getState()), DO sleep sometime and then call mbean.getThreadCount(), if it reports a right number, then we may need to verify mbean.getThreadCount() method.

Shanliang

Jaroslav Bachorik wrote:
On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote:
On 7/24/2013 2:09 PM, Daniel Fuchs wrote:
On 7/24/13 8:01 AM, Mandy Chung wrote:
I am catching up on this thread....

The thread count counts Java threads that are not hidden.  I believe
all VM internal threads are hidden from external API. This test runs
in othervm mode and AFAICT the thread count is expected to be
deterministic.  I don't expect the VM will start and terminate any
thread any time.

I agree with David that we should diagnose why there is one
additional thread started before the reset.  If it is the
LogManager$Cleaner thread, like David said, the VM is shutting down
while the test is still running which doesn't quite make sense.
I think that Shanliang's suspicion that a thread might be still alive
if unscheduled just after having
called its barrier.signal() is a very good suggestion. I would advise
calling thread.join() on all threads in
terminateThreads, just to make sure they are all really dead and not
in some comatose state...
If Shanliang is right then the test would be failing because some of
the threads we think are dead are
not actually dead yet - and not because of some new VM thread that
nobody can see :-)
Thanks for pointing that out.

I agree that the test should be changed to call Thread.join(). There
may be other java.lang.management tests that should also be fixed to
call Thread.join.

I've tried using Thread.join() but I am still getting the thread count discrepancy.

Specifically:
1. 10 worker threads have been successfully started - mben.getThreadCount() reports 14 and Thread.getAllStackTraces() returns 14 items
---
Thread: Thread[Signal Dispatcher,9,system]
Thread: Thread[worker-5,5,main]
Thread: Thread[worker-7,5,main]
Thread: Thread[worker-9,5,main]
Thread: Thread[worker-12,5,main]
Thread: Thread[worker-11,5,main]
Thread: Thread[Reference Handler,10,system]
Thread: Thread[main,5,main]
Thread: Thread[worker-10,5,main]
Thread: Thread[worker-8,5,main]
Thread: Thread[Finalizer,8,system]
Thread: Thread[worker-6,5,main]
Thread: Thread[worker-13,5,main]
Thread: Thread[worker-4,5,main]
---
2. Terminating 8 threads
3. After the threads have been terminated (waiting on Thread.join() for them to die) - mbean.getThreadCount() reports 7 while Thread.getAllStackTraces() returns only 6 items
---
Thread: Thread[Signal Dispatcher,9,system]
Thread: Thread[Finalizer,8,system]
Thread: Thread[worker-12,5,main]
Thread: Thread[Reference Handler,10,system]
Thread: Thread[main,5,main]
Thread: Thread[worker-13,5,main]
---

This would almost point to mbean.getThreadCount() reporting a stale value. Is that possible?

-JB-

Mandy



Reply via email to