On 04/02/2013 16:02, Mike Duigou wrote:
:
If so then I think we have to careful because -concurrency means a lot of
virtual memory and I'm not convinced that we limit it via -vmoption in
jdk/test/Makefile
I could see us wanting to dial this down on 32-bit Windows for example.
We do limit the max size via -Xmx512M which does seem quite small and is
generally well balanced with the number of cores.
I opened a build/infrastructure issue to have MEMORY_SIZE and perhaps some
suggested VM sizes recorded to the spec.gmk I planned to revisit this again
once only new build is supported.
My reading of the make file is that -J-Xmx512m is passed to jtreg and so
it's the maximum heap size of the jtreg process, not the agent VMs
running tests. If we are turning on concurrency then it will need
-vmoption:-Xmx512m too, otherwise you risk each agent reserving 1/4 of
physical memory. In addition, limited virtual memory on Windows 32-bit
will limit the number of agent VMs that you can run and so $(JOBS) may
be too much. You might need to limit it to 2 or 3 on Windows 32-bit.
Also I'm not 100% sure that jdk/test/TEST.ROOT is up to date for the client
area -- that's the place where excludeAccess.dirs lists the directories with
tests that cannot run concurrently.
The makefile currently segregates tests to use othervm or agentvm by target ie.
jdk_beans1 . I haven't checked whether these are synchronized against TEST.ROOT and
indeed it would be a shame if these had not been kept in sync. (This is why I added notes
about "keep this in sync with ..." in various places) I will check this with
Stuart Marks today and plan remediation if necessary.
I think we should ultimately remove the othervm vs. agentvm selection
from the make file.
I just checked TEST.ROOT and othervm.dirs is right. The value of
exclusiveAccess.dirs looks right too but may be incomplete -- I just
don't run the client area tests to know if there are any areas that
cannot run concurrently.
-Alan.
