8201495: [Zero] Reduce limits of max heap size for boot JDK on s390
Severin Gehwolf
sgehwolf at redhat.com
Mon Apr 16 09:34:19 UTC 2018
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
More information about the build-dev
mailing list