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
