RFR : 8006594/8006595 : Define jdk_core test set

[Alan Bateman]

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