Potential timeout issues - tests running in the same vm
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