Hi Magnus, On Mon, 2018-04-16 at 10:58 +0200, Magnus Ihse Bursie wrote: > 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.
Thanks for the review! I'll test builds with your proposed changes and see how it goes. Cheers, Severin
