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

[Daniel D. Daugherty]

On 7/24/13 1:35 AM, Jaroslav Bachorik wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/24/2013 09:21 AM, shanliang wrote:
>> 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.
> The result is:
>
> 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]
> - ---> MBean.getThreadCount() = 7

The above count == 7, but there are only 6 thread names above it.
That's good confirmation of a race between when a thread is declared
dead (and you can't get its name anymore) and the live thread counter
being off...

This has turned into an interesting test fix...

Dan


> Thread(1): Thread[Signal Dispatcher,9,system]
> Thread(1): Thread[Finalizer,8,system]
> Thread(1): Thread[worker-12,5,main]
> Thread(1): Thread[Reference Handler,10,system]
> Thread(1): Thread[main,5,main]
> Thread(1): Thread[worker-13,5,main]
> - ---> MBean.getThreadCount() = 6
>
> - -JB-
>
>
>> 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
>>>>
>>>
>>>
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJR74OmAAoJELSZyqhGiB1M4k8H/2hM5o2vVe2lfhc374IBaR5R
> R8i9Z2n0prBRKIqg4bTkAcllq5pmdozxwFyaEBzJtAGh9vnL7Tmojn6ksg9K+MMl
> bSgWSeg+gSZyymS7aE8rTVqKigH8vNOpHOogePDrUOCZGeZgJIMpmY1QcVbLeq8k
> mkz5mPYxEE2E7gt8cjvcXknOWeQUTyZILWGIPBfx9FL0iwBtK5h0PnfasR7bCxcR
> DO48USIuTxe+aN687OkAlJq9bCR6HRzWQiaSdi4ROVyrx2xYtir4n9sZtNWJwokv
> 3p5TdX6S64jnVZZMjbPJgCENTYMvTeRCj/8GvCYlI9KQEa9x2zhU2wIp5Zw4ag4=
> =4vkV
> -----END PGP SIGNATURE-----