On Jun 20, 2010, at 1:49 AM, Alan Bateman wrote:
Kelly O'Hair wrote:
Looks great to me.
Thanks to everyone for fixing tests like this.
People should keep in mind that some of the test batches in the jdk/
test/Makefile
do NOT run in samevm mode at all, e.g. jdk_awt, jdk_beans2,
jdk_beans3, jdk_management1,
jdk_management2, jdk_nio2, jdk_nio3, jdk_rmi, jdk_security2,
jdk_security3, jdk_swing,
and jdk_tools2. When I tried to run them in samevm mode, there were
too many problems,
so I gave up on the entire batch. Although some of the batches may
make sense to be entirely
othervm tests, like jdk_tools2. But eventually, I think it's a good
idea to mark tests
that need a dedicated VM "othervm", making it explicit.
The jdk_nio3 batch seem to be charsets and sctp tests. I don't think
it should take too much effort to get most of the charsets tests
running in samevm mode. I think Chris might be looking at the sctp
tests already (I think the failures there are due to variation in
the sctp support rather than issues running the tests in the same VM).
That would be great. Thanks to all of you for the testcase work. I
think this will pay off in the
long run.
I'll try to get cycles next week to sort out the jdk_nio2 batch.
There are a dozen of so tests there that require their own VM (might
be able to combine some of the smaller tests to offset the cost of
running them in othervm mode). There are also a couple of tests that
will need to be dialed down as they consume all resources and cause
problems for subsequent tests. Overall I don't expect there will be
a huge performance benefit to running this batch in samevm mode
(some benefit, just not as significant as other batches with lots of
short running tests).
That's what I was thinking with the jdk_tools2 tests, lots of shell
tests, which are by default 'othervm'
tests, BUT I was surprised, it does run faster in samevm, so it
doesn't take very many samevm tests
being in the batch of tests to make a difference in overall run time.
-kto
-Alan.
