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

Reply via email to