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
