8201495: [Zero] Reduce limits of max heap size for boot JDK on s390

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Apr 16 08:58:03 UTC 2018

On 2018-04-13 15:40, Severin Gehwolf wrote:
> Hi,
> We (Red Hat) have been building Zero on s390 for a while now. In order
> to do so we needed to have this patch to reduce the maximum heap size
> setting for big workloads. Otherwise we see this during (JDK 9) builds:
> ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-
> ++ /usr/bin/tee /builddir/build/BUILD/java-9-openjdk-
> Error occurred during initialization of VM
> Could not reserve enough space for 1048576KB object heap
> NOTE: JDK 9 has the same build logic than JDK 11 in terms of big
> workloads' JVM switches.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8201495
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.01/

Hi Severin,

As I said in the bug report (didn't notice that you've already sent out 
a webrev here), I'm not really fond of adding platforms guard if they 
can be avoided. Normally, Java programs use more or less the same amount 
of heap regardless of platforms they run on, differing only by platform 
word size. So if a lower mx is enough on s390 builds, it's mostly likely 
to be enough on all platforms, and thus the guard is unnecessary, and 
will only make it harder to update the code in the future.

Also, the value of ms is typically of less concern. While mx is setting 
an upper bound on resource allocation, ms is more of a "performance 
hint" to the gc. Unless this is needed for your fix to work, I recommend 
you leave it at it's current value.


> Testing: Run configure on s390 and inspected the big workloads settings:
> Before:
> checking flags for bootcycle boot jdk java command for big workloads... -Xms64M -Xmx998M -XX:ThreadStackSize=768
> After:
> checking flags for bootcycle boot jdk java command for big workloads... -Xms256M -Xmx768M -XX:ThreadStackSize=768
> This should be fairly low risk, since the check is guarded by s390
> archicture checks. Other architectures should be unaffected.
> Thanks,
> Severin

More information about the build-dev mailing list