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-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
++ /usr/bin/tee
/builddir/build/BUILD/java-9-openjdk-9.0.4.12-5.openjdk9.el7.s390/openjdk/build/jdk/modules/java.base/_the.java.base_batch.log
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.
/Magnus
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
