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

[Mandy Chung]

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.

Mandy