RFR : 8006594/8006595 : Define jdk_core test set

[Alan Bateman]

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.