JTreg spawns java processes and uses all memory with CONCURRENCY=auto
Alan.Bateman at oracle.com
Fri May 24 02:11:46 PDT 2013
On 23/05/2013 20:28, Jonathan Gibbons wrote:
> I've incorporated some of the feedback I received here and noted the
> I am currently experimenting with the Hotspot test suite to get advice
> for that.
> I've linked the page in to the page "Running tests with jtreg", but
> not to the top level page. I'd prefer to keep the top level page
> relatively simply and well structured. That being said, it seems
> there is a need for some sort of page "Writing tests for jtreg", that
> should contain helpful info or provide pointers to useful info that is
> specific to jtreg (as compared to writing tests in general.) When
> that page appears, I think that deserves to be linked in to the top page.
> -- Jon
A very useful page.
One other thing that might be worth mentioning is timeoutFactor, it
might be needed in some environments where you are running the jdk tests
with -conc:auto. The jdk tests are mostly a wild mix of workloads, but
there are areas, the new streams tests in particular, where tests are
doing parallel ops concurrently. Personally I use -timeoutFactor:2 to
avoid exceeding the threshold intermittently.
Just on this note:
"Empirical evidence suggests that you can run the tests in these
regression test suites with the concurrency set to the number of
processors available on the system."
I mostly agree with this but I'm not sure about the client areas tests
(AWT, Swing, ...). Someone more familiar with those areas would need to
comment on whether these tests can run concurrently (or event in agentvm
mode as I don't recall seeing any change-sets go by on this). It may be
that the exclusiveAccess.dirs list in the jdk's TEST.ROOT needs to be
expanded to include those areas.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jtreg-use