JTreg spawns java processes and uses all memory with CONCURRENCY=auto

[Alan Bateman]

On 23/05/2013 20:28, Jonathan Gibbons wrote:
> I've incorporated some of the feedback I received here and noted the 
> rest.
>
> 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.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20130524/c48ada05/attachment.html