Potential timeout issues - tests running in the same vm

[Alan Bateman]

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:

http://bugs.sun.com/view_bug.do?bug_id=7094842
http://bugs.sun.com/view_bug.do?bug_id=7094995

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.

-Alan.