On 05/02/2013 20:10, Mike Duigou wrote:
On Feb 4 2013, at 08:33 , Alan Bateman wrote:
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.
OK, that is my misunderstanding. I thought it was being applied to both the
jtreg vm and the test vms. I think for now I will just remove concurrent rather
than try to set VM sizing.
No problem, it's not obvious. Maurizio and I were looking at the
Makefile in langtools recently and we noticed the same thing, since then
it has been updated by Vincente to specify -vmoption. I think we should
do the same in jdk/test/Makefile and I think 512m is about right (the
temptation is to set it higher but there are a lot of tests in the jdk
repo that are othervm tests so actual number of VMs running can be *2,
or even more when multi-process tests are run. This can of course be
something for another update, and I'm okay with the other changes in the
last webrev.
-Alan
