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.
