Re: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390
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. Latest webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.02/ This now only changes -Xmx unconditionally and it bootcycle-builds successfully on linux 32 bit, ppc (32 bit Zero) and s390 (32 bit Zero). I haven't heard back from jdk-submit. It's radio silence since I've pushed the branch. Not sure what's up with that. Magnus, you've OK'ed the patch on the bug. Asking here again to clarify. Is it OK to push this? Thanks, Severin > /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 > >
Re: Amber repo build issue on MacOSX
Looks like this one: https://bugs.openjdk.java.net/browse/JDK-8201508 On 2018-04-17 17:55, Jim Laskey wrote: cp: /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: No such file or directory make[3]: *** [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [generate-link-opt-data] Error 2 make[2]: *** Waiting for unfinished jobs…. Is there a workaround for this issue?
Re: Amber repo build issue on MacOSX
If you have that fix, it could potentially also be that you broke hotspot enough to not be able to generate the classlist file. /Erik On 2018-04-17 09:03, Claes Redestad wrote: Looks like this one: https://bugs.openjdk.java.net/browse/JDK-8201508 On 2018-04-17 17:55, Jim Laskey wrote: cp: /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: No such file or directory make[3]: *** [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [generate-link-opt-data] Error 2 make[2]: *** Waiting for unfinished jobs…. Is there a workaround for this issue?
Amber repo build issue on MacOSX
cp: /Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/link_opt/classlist: No such file or directory make[3]: *** [/Projects/amber/build/macosx-x86_64-normal-server-fastdebug/support/modules_libs/java.base/classlist] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [generate-link-opt-data] Error 2 make[2]: *** Waiting for unfinished jobs…. Is there a workaround for this issue?
Re: RFR: 8201360: Zero fails to build on linux-sparc after 8201236
Hi Magnus! On 04/10/2018 10:01 PM, Magnus Ihse Bursie wrote: > The regression you noted was not caused by JDK-8201236, but by JDK-8198862 > "Stop doing funky compilation stuff for dtrace". In fact, JDK-8201236 (which > is > pushed to jdk/jdk but not yet integrated into jdk/hs, apparently) will once > again remove EXTRA_FILES from the SetupNativeCompilation, making zero work > again. > > So if you just wait until JDK-8201236 moves into jdk/hs, this will be fixed. > Otherwise, you're just creating a merge conflict for the integrator. :( Since the jdk/jdk and jdk/hs merge was finished today, I gave Zero on linux-sparc another shot and lo and behold, it builds fine again :-). Will update the bug report accordingly. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
