jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently

[Jaroslav Bachorik]

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