RFR: 8014510: Fix sjavac on all platforms in jprt

[Erik Joelsson]

Thanks for looking into this. I took the liberty of tuning this some 
more and finally arrived at this set of changes:

http://cr.openjdk.java.net/~erikj/8014510/webrev.root.01/

First of all I wanted to get rid of the big if-else construct, so I 
changed that into a simple MEMORY_SIZE/2 for sjavac server mx flag. Then 
I did some tests on my machine and with the modules build, sjavac really 
isn't that memory intensive anymore. I set a cap at 2GB (1,5 for 32 bit 
jvms) and also set a minimum of 512M, which I have verified still works. 
I also removed the verbosegc flag.

When changing these settings, it struck me that the mx in BIG_JAVA_FLAGS 
is a static configuration and should probably also be tuned in the same 
way. I left the old values as the maximum caps and let them go as low as 
512. This has also been verified to be enough.

Finally, since the memory requirements of the java instances in the 
build have been reduced, I also chose to tweak the memory based limiter 
on the default number of jobs.

With this I'm able to run builds through JPRT with sjavac enabled and I 
believe that there should be no trouble enabling it for every day use on 
most build configurations. We still cannot enable it by default until 
JDK-8054717 is fixed however, as it's currently not guaranteeing a 
correct incremental build.

/Erik

On 2014-08-20 16:55, Andreas Lundblad wrote:
> Hi build-dev,
>
> Please review the fix for JDK-8014510: Fix sjavac on all platforms in jprt
>
> Description:
> JPRT jobs fail (on Sparc) with sjavac enabled. This is because the JVM can't allocate the requested amount of memory upon launch. This patch changes the the -Xms setting (which ranges from 1G to 10G) to 512M.
>
> Link to webrev:
> http://cr.openjdk.java.net/~alundblad/8014510
>
> Links to bug report:
> https://bugs.openjdk.java.net/browse/JDK-8014510
>
> -- Andreas