Potential timeout issues - tests running in the same vm

Alan Bateman Alan.Bateman at oracle.com
Thu Nov 17 08:29:33 UTC 2011

On 17/11/2011 04:43, David Holmes wrote:
> Given they are not run concurrently with other tests (modulo the 
> testing framework [gtee/ute not jtreg] running multiple testsuites on 
> the same machine) the only issue I can see that would impact samevm 
> mode is if other test lefts threads behind. I'm not sure if this is 
> possible with jtreg, but if it were then it is those other tests that 
> need to be fixed.
When jtreg runs tests in samevm or agentvm mode then it creates a thread 
group for the test. When the test completes then it attempts  "cleanup" 
that I think includes interrupting any remaining non-daemon threads in 
the group. I think there retry logic in there and eventually it gives up 
causing the test to fail (in error). There are other checks to help us 
catch tests that don't clean-up, the main one we used to be (until we 
fixed the tests) that they left files open.

As you mention threads then I should mention that I was looking recently 
into why the tests were taking a long time to run on some systems and 
found a couple of tests that leave daemon threads behind. Here's two 
where tests were leaving spinning threads behind:


Max fixed the first one promptly, I've been meaning to nab Neil about 
the second one.

> As Alan indicated we want to reduce use of othervm where we can 
> because often the overhead of launching a new VM far outweighs the 
> execution time of a successful test.
Right although we have our share of tests that take several seconds (and 
more) to run.

I see Chris's mail points out that some tests do have an unusually small 
timeout. For those tests then I would be tempted to just remove the 
timeout. Most likely the original author of the test put a small timeout 
to make it quick to test on a JDK that didn't have the fix.


More information about the core-libs-dev mailing list