From shahid at us.ibm.com Fri Nov 4 15:38:51 2016 From: shahid at us.ibm.com (Shahid Shaikh) Date: Fri, 4 Nov 2016 21:08:51 +0530 Subject: jdk9/hs repo build issues for s390x Message-ID: Hi, We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository (where the s390x code changes has been merged). However build is failing with following error: On RHEL7.2 / SLES12SP1: Compiling 1 files for java.se.ee Compiling 235 files for jdk.xml.ws Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. Compiling 4 files for BUILD_JIGSAW_TOOLS MacroAssembler::get_dest_of_call_far_patchable_at has a problem at 0x2003009c900: not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8 Could not load hsdis-s390x.so; library not loadable; PrintAssembly is disabled # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614 # Error: ShouldNotReachHere() # # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal +0-2016-11-03-151506..OpenJDK9) # Java VM: OpenJDK 64-Bit Server VM (9-internal +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops, serial gc, linux-s390x) # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /SSWorkspace/OpenJDK9/make/core.48608) # # An error report file with more information is saved as: # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log # # Compiler replay data is saved as: # /SSWorkspace/OpenJDK9/make/replay_pid48608.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # gmake[3]: *** [/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packages_attribute.done] Aborted (core dumped) gmake[2]: *** [exploded-image-optimize] Error 1 On Ubuntu 16.04: Creating libTestJNI.so from 1 file(s) Creating FPRegs from 1 file(s) Creating invoke from 1 file(s) /SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: In function `closeHandle': /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:48: undefined reference to `dlclose' /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:49: undefined reference to `dlerror' /SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: In function `loadJVM': /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:69: undefined reference to `dlopen' /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:77: undefined reference to `dlsym' /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:88: undefined reference to `dlerror' collect2: error: ld returned 1 exit status JtregNative.gmk:111: recipe for target '/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/bin/FPRegs' failed make[3]: *** [/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/bin/FPRegs] Error 1 make[2]: *** [build-test-hotspot-jtreg-native] Error 1 make[2]: *** Waiting for unfinished jobs.... make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native' failed Creating support/symbols/ct.sym ERROR: Build failed for target 'all' in configuration 'linux-s390x-normal-server-release' (exit code 2) Stopping sjavac server We are using following steps to build OpenJDK9: hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9 cd OpenJDK9 bash ./get_source.sh unset JAVA_HOME export LANG=C export PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$ {PATH}" bash ./configure --with-jvm-variants=server --disable-warnings-as-errors make all We tried same on x86 machine and got the same build failure. Please let us know if we are missing anything here. Thanks & Regards, Shahid From volker.simonis at gmail.com Fri Nov 4 19:12:03 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Nov 2016 20:12:03 +0100 Subject: jdk9/hs repo build issues for s390x In-Reply-To: References: Message-ID: On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh wrote: > > Hi, > > We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository (where > the s390x code changes has been merged). However build is failing with > following error: > > On RHEL7.2 / SLES12SP1: > Compiling 1 files for java.se.ee > Compiling 235 files for jdk.xml.ws > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > Compiling 4 files for BUILD_JIGSAW_TOOLS > MacroAssembler::get_dest_of_call_far_patchable_at has a problem at > 0x2003009c900: > not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8 > Could not load hsdis-s390x.so; library not loadable; PrintAssembly is > disabled > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614 > # Error: ShouldNotReachHere() > # > # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal > +0-2016-11-03-151506..OpenJDK9) > # Java VM: OpenJDK 64-Bit Server VM (9-internal > +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops, serial > gc, linux-s390x) > # Core dump will be written. Default location: Core dumps may be processed > with "/usr/share/apport/apport %p %s %c %P" (or dumping > to /SSWorkspace/OpenJDK9/make/core.48608) > # > # An error report file with more information is saved as: > # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log > # > # Compiler replay data is saved as: > # /SSWorkspace/OpenJDK9/make/replay_pid48608.log > # Hi Shahid, sorry to hear you have problems with the port. Could you please send us the two /hs_err_pid48608.log and replay_pid48608.log files so we can further investigate the error. They will be stripped from the mailing list, but if you do a "reply-all" to this mail, my colleagues and I will get them. We've detected one problem with the port and currently do our nightly builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with the attached patch. You could try it but it doesn't seems to be related to your problem. Could you please also send the output of configure along with the log files so we can see what tools you are using. > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > gmake[3]: *** > [/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packages_attribute.done] > Aborted (core dumped) > gmake[2]: *** [exploded-image-optimize] Error 1 > > On Ubuntu 16.04: > Creating libTestJNI.so from 1 file(s) > Creating FPRegs from 1 file(s) > Creating invoke from 1 file(s) > /SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: > In function `closeHandle': > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:48: > undefined reference to `dlclose' > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:49: > undefined reference to `dlerror' > /SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: > In function `loadJVM': > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:69: > undefined reference to `dlopen' > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:77: > undefined reference to `dlsym' > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:88: > undefined reference to `dlerror' > collect2: error: ld returned 1 exit status > JtregNative.gmk:111: recipe for target > '/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/bin/FPRegs' > failed > make[3]: *** > [/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/test/hotspot/jtreg/native/bin/FPRegs] > Error 1 > make[2]: *** [build-test-hotspot-jtreg-native] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native' > failed > Creating support/symbols/ct.sym > > ERROR: Build failed for target 'all' in configuration > 'linux-s390x-normal-server-release' (exit code 2) > Stopping sjavac server > So this seems to be a different problem. It is a known bug that the tests are currently not completely working. Goetz still has a bug open for this (https://bugs.openjdk.java.net/browse/JDK-8166837) but you can already find a webrev which should fix the issue and which should hopefully be pushed soon here: http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02 Can you please try to just build the "images" target and report if that succeeds? If it does, you should find a complete image under images/jdk which you could use for testing. If at least the "images" target succeeds on Ubuntu than the other build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they use another version of GCC which has some problems? Regards, Volker > > We are using following steps to build OpenJDK9: > hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9 > cd OpenJDK9 > bash ./get_source.sh > unset JAVA_HOME > export LANG=C > export > PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$ > {PATH}" > bash ./configure --with-jvm-variants=server --disable-warnings-as-errors > make all > That sounds reasonable. > > We tried same on x86 machine and got the same build failure. > That's strange. I just saw that we also use --with-jtreg on the configure command line which points to the latest version of JTreg we've built. Maybe that's the problem if you have build failures on x86? Again, try to build 'images' first and only if that succeeds try 'test-images' or 'all'. Regards, Volker PS: could you (and your colleagues) please subscribe to the list. Otherwise you mails will be on hold until I moderate them. > Please let us know if we are missing anything here. > > Thanks & Regards, > Shahid -------------- next part -------------- A non-text attachment was scrubbed... Name: s390_indexOfChar_fix.patch Type: text/x-patch Size: 11994 bytes Desc: not available URL: From lutz.schmidt at sap.com Mon Nov 7 14:12:30 2016 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 7 Nov 2016 14:12:30 +0000 Subject: jdk9/hs repo build issues for s390x In-Reply-To: References: Message-ID: Hi, the below error points to an instruction pattern detection issue (what a complicated name :-)). There is a ?Call Far Patchable? at the examined address, because c0e5fffdd3c0 translates into BRASL R14,0xfffdd3c0 The detection code expects the BRASL to be prepended with a nop (0x0700). Either, the nop isn?t there or the examined address is incorrect (two bytes too high). Im not sure if the hs_err_pid48608.log could help here. What we would need is a storage dump/disassembly around the examined address. Regards, Lutz On 04.11.16, 20:12, "s390x-port-dev on behalf of Volker Simonis" wrote: >On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh wrote: >> >> Hi, >> >> We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository >>(where >> the s390x code changes has been merged). However build is failing with >> following error: >> >> On RHEL7.2 / SLES12SP1: >> Compiling 1 files for java.se.ee >> Compiling 235 files for jdk.xml.ws >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> Compiling 4 files for BUILD_JIGSAW_TOOLS >> MacroAssembler::get_dest_of_call_far_patchable_at has a problem at >> 0x2003009c900: >> not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8 >> Could not load hsdis-s390x.so; library not loadable; PrintAssembly is >> disabled >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614 >> # Error: ShouldNotReachHere() >> # >> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal >> +0-2016-11-03-151506..OpenJDK9) >> # Java VM: OpenJDK 64-Bit Server VM (9-internal >> +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops, >>serial >> gc, linux-s390x) >> # Core dump will be written. Default location: Core dumps may be >>processed >> with "/usr/share/apport/apport %p %s %c %P" (or dumping >> to /SSWorkspace/OpenJDK9/make/core.48608) >> # >> # An error report file with more information is saved as: >> # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log >> # >> # Compiler replay data is saved as: >> # /SSWorkspace/OpenJDK9/make/replay_pid48608.log >> # > >Hi Shahid, > >sorry to hear you have problems with the port. > >Could you please send us the two /hs_err_pid48608.log and >replay_pid48608.log files so we can further investigate the error. >They will be stripped from the mailing list, but if you do a >"reply-all" to this mail, my colleagues and I will get them. > >We've detected one problem with the port and currently do our nightly >builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with >the attached patch. You could try it but it doesn't seems to be >related to your problem. > >Could you please also send the output of configure along with the log >files so we can see what tools you are using. > >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> gmake[3]: *** >> >>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packa >>ges_attribute.done] >> Aborted (core dumped) >> gmake[2]: *** [exploded-image-optimize] Error 1 >> >> On Ubuntu 16.04: >> Creating libTestJNI.so from 1 file(s) >> Creating FPRegs from 1 file(s) >> Creating invoke from 1 file(s) >> >>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes >>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: >> In function `closeHandle': >> >>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>Regs.c:48: >> undefined reference to `dlclose' >> >>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>Regs.c:49: >> undefined reference to `dlerror' >> >>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes >>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: >> In function `loadJVM': >> >>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>Regs.c:69: >> undefined reference to `dlopen' >> >>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>Regs.c:77: >> undefined reference to `dlsym' >> >>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>Regs.c:88: >> undefined reference to `dlerror' >> collect2: error: ld returned 1 exit status >> JtregNative.gmk:111: recipe for target >> >>'/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te >>st/hotspot/jtreg/native/bin/FPRegs' >> failed >> make[3]: *** >> >>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te >>st/hotspot/jtreg/native/bin/FPRegs] >> Error 1 >> make[2]: *** [build-test-hotspot-jtreg-native] Error 1 >> make[2]: *** Waiting for unfinished jobs.... >> make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native' >> failed >> Creating support/symbols/ct.sym >> >> ERROR: Build failed for target 'all' in configuration >> 'linux-s390x-normal-server-release' (exit code 2) >> Stopping sjavac server >> > >So this seems to be a different problem. It is a known bug that the >tests are currently not completely working. Goetz still has a bug open >for this (https://bugs.openjdk.java.net/browse/JDK-8166837) but you >can already find a webrev which should fix the issue and which should >hopefully be pushed soon here: > >http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02 > >Can you please try to just build the "images" target and report if >that succeeds? If it does, you should find a complete image under >images/jdk which you could use for testing. > >If at least the "images" target succeeds on Ubuntu than the other >build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they >use another version of GCC which has some problems? > >Regards, >Volker > >> >> We are using following steps to build OpenJDK9: >> hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9 >> cd OpenJDK9 >> bash ./get_source.sh >> unset JAVA_HOME >> export LANG=C >> export >> >>PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$ >> {PATH}" >> bash ./configure --with-jvm-variants=server >>--disable-warnings-as-errors >> make all >> > >That sounds reasonable. > >> >> We tried same on x86 machine and got the same build failure. >> > >That's strange. I just saw that we also use --with-jtreg on the >configure command line which points to the latest version of JTreg >we've built. Maybe that's the problem if you have build failures on >x86? Again, try to build 'images' first and only if that succeeds try >'test-images' or 'all'. > >Regards, >Volker > >PS: could you (and your colleagues) please subscribe to the list. >Otherwise you mails will be on hold until I moderate them. > >> Please let us know if we are missing anything here. >> >> Thanks & Regards, >> Shahid From volker.simonis at gmail.com Tue Nov 8 08:23:43 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Nov 2016 09:23:43 +0100 Subject: jdk9/hs repo build issues for s390x In-Reply-To: References: Message-ID: Hi Shahid, it is surely not related to this issue but it would be highly interesting to know what exact system you are running on. The system detection in the hs_err file looks reads really weird: OS:Red Hat Enterprise Linux Server release 7.2 (Maipo) uname:Linux 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:47:15 UTC 2016 s390x So you really have a RHEL 7.2 installation with a Ubuntu kernel? Thanks, Volker On Mon, Nov 7, 2016 at 5:26 PM, Shahid Shaikh wrote: > Hi Volker/Lutz, > > Thanks for your help. Please find attached hs_err_pid48608.log and > replay_pid48608.log files. Also, the configure and build logs. > > Please find my comments inline. > > Thanks & Regards, > Shahid > > (See attached file: OpenJDK9_rhel7.2_build.log)(See attached file: > OpenJDK9_rhel7.2_configure.log)(See attached file: hs_err_pid30816.log)(See > attached file: replay_pid30816.log) > > "Schmidt, Lutz" ---11/07/2016 07:42:40 PM---Hi, the below error points to an > instruction pattern detection issue (what a > > From: "Schmidt, Lutz" > To: Volker Simonis , Shahid > Shaikh/Austin/Contr/IBM at IBMUS, "Lindenmaier, Goetz" > , "Doerr, Martin" > Cc: "s390x-port-dev at openjdk.java.net" , > Cindy Lee , Amod Borkar/Austin/Contr/IBM at IBMUS > Date: 11/07/2016 07:42 PM > Subject: Re: jdk9/hs repo build issues for s390x > > ________________________________ > > > > Hi, > > > the below error points to an instruction pattern detection issue (what a > complicated name :-)). There is a ?Call Far Patchable? at the examined > address, because > c0e5fffdd3c0 translates into BRASL R14,0xfffdd3c0 > The detection code expects the BRASL to be prepended with a nop (0x0700). > Either, the nop isn?t there or the examined address is incorrect (two > bytes too high). > > Im not sure if the hs_err_pid48608.log could help here. What we would need > is a storage dump/disassembly around the examined address. > > Regards, Lutz > > > On 04.11.16, 20:12, "s390x-port-dev on behalf of Volker Simonis" > volker.simonis at gmail.com> wrote: > >>On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh wrote: >>> >>> Hi, >>> >>> We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository >>>(where >>> the s390x code changes has been merged). However build is failing with >>> following error: >>> >>> On RHEL7.2 / SLES12SP1: >>> Compiling 1 files for java.se.ee >>> Compiling 235 files for jdk.xml.ws >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> Compiling 4 files for BUILD_JIGSAW_TOOLS >>> MacroAssembler::get_dest_of_call_far_patchable_at has a problem at >>> 0x2003009c900: >>> not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8 >>> Could not load hsdis-s390x.so; library not loadable; PrintAssembly is >>> disabled >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614 >>> # Error: ShouldNotReachHere() >>> # >>> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal >>> +0-2016-11-03-151506..OpenJDK9) >>> # Java VM: OpenJDK 64-Bit Server VM (9-internal >>> +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops, >>>serial >>> gc, linux-s390x) >>> # Core dump will be written. Default location: Core dumps may be >>>processed >>> with "/usr/share/apport/apport %p %s %c %P" (or dumping >>> to /SSWorkspace/OpenJDK9/make/core.48608) >>> # >>> # An error report file with more information is saved as: >>> # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log >>> # >>> # Compiler replay data is saved as: >>> # /SSWorkspace/OpenJDK9/make/replay_pid48608.log >>> # >> >>Hi Shahid, >> >>sorry to hear you have problems with the port. >> >>Could you please send us the two /hs_err_pid48608.log and >>replay_pid48608.log files so we can further investigate the error. >>They will be stripped from the mailing list, but if you do a >>"reply-all" to this mail, my colleagues and I will get them. >> >>We've detected one problem with the port and currently do our nightly >>builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with >>the attached patch. You could try it but it doesn't seems to be >>related to your problem. >> >>Could you please also send the output of configure along with the log >>files so we can see what tools you are using. >> >>> # If you would like to submit a bug report, please visit: >>> # http://bugreport.java.com/bugreport/crash.jsp >>> # >>> gmake[3]: *** >>> >>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packa >>>ges_attribute.done] >>> Aborted (core dumped) >>> gmake[2]: *** [exploded-image-optimize] Error 1 >>> >>> On Ubuntu 16.04: >>> Creating libTestJNI.so from 1 file(s) >>> Creating FPRegs from 1 file(s) >>> Creating invoke from 1 file(s) >>> >>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes >>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: >>> In function `closeHandle': >>> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>>Regs.c:48: >>> undefined reference to `dlclose' >>> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>>Regs.c:49: >>> undefined reference to `dlerror' >>> >>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes >>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: >>> In function `loadJVM': >>> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>>Regs.c:69: >>> undefined reference to `dlopen' >>> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>>Regs.c:77: >>> undefined reference to `dlsym' >>> >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP >>>Regs.c:88: >>> undefined reference to `dlerror' >>> collect2: error: ld returned 1 exit status >>> JtregNative.gmk:111: recipe for target >>> >>>'/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te >>>st/hotspot/jtreg/native/bin/FPRegs' >>> failed >>> make[3]: *** >>> >>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te >>>st/hotspot/jtreg/native/bin/FPRegs] >>> Error 1 >>> make[2]: *** [build-test-hotspot-jtreg-native] Error 1 >>> make[2]: *** Waiting for unfinished jobs.... >>> make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native' >>> failed >>> Creating support/symbols/ct.sym >>> >>> ERROR: Build failed for target 'all' in configuration >>> 'linux-s390x-normal-server-release' (exit code 2) >>> Stopping sjavac server >>> >> >>So this seems to be a different problem. It is a known bug that the >>tests are currently not completely working. Goetz still has a bug open >>for this (https://bugs.openjdk.java.net/browse/JDK-8166837) but you >>can already find a webrev which should fix the issue and which should >>hopefully be pushed soon here: >> >>http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02 >> >>Can you please try to just build the "images" target and report if >>that succeeds? If it does, you should find a complete image under >>images/jdk which you could use for testing. >> > > After applying the above code changes manually, the above error is gone for > Ubuntu 16.04 s390x build environment. However the 'make images' command is > still failing and now the error is similar to what we are getting for > RHEL7.2 and SLES12SP1 distributions. > >>If at least the "images" target succeeds on Ubuntu than the other >>build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they >>use another version of GCC which has some problems? >> > > Yes, the 'make' versions are different. Its '4.1' for Ubuntu 16.04 and > '3.82' for RHEL7.2. > >>Regards, >>Volker >> >>> >>> We are using following steps to build OpenJDK9: >>> hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9 >>> cd OpenJDK9 >>> bash ./get_source.sh >>> unset JAVA_HOME >>> export LANG=C >>> export >>> >>>PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$ >>> {PATH}" >>> bash ./configure --with-jvm-variants=server >>>--disable-warnings-as-errors >>> make all >>> >> >>That sounds reasonable. >> >>> >>> We tried same on x86 machine and got the same build failure. >>> >> >>That's strange. I just saw that we also use --with-jtreg on the >>configure command line which points to the latest version of JTreg >>we've built. Maybe that's the problem if you have build failures on >>x86? Again, try to build 'images' first and only if that succeeds try >>'test-images' or 'all'. >> > > We tried with '--with-jtreg' in the configure command (after installing > jtreg) and the 'make images' worked in our Ubuntu 16.04 x86 build > environment. However the 'make all' is still failing. > >>Regards, >>Volker >> >>PS: could you (and your colleagues) please subscribe to the list. >>Otherwise you mails will be on hold until I moderate them. >> > >>> Please let us know if we are missing anything here. >>> >>> Thanks & Regards, >>> Shahid > > > From volker.simonis at gmail.com Fri Nov 25 18:12:26 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Nov 2016 19:12:26 +0100 Subject: jdk9/hs repo build issues for s390x In-Reply-To: References: <7a132164a2bd44898bf549ca89d52c60@DEWDFE13DE10.global.corp.sap> <1a1eca14c372475ea85b6fa70eaed852@DEWDFE13DE10.global.corp.sap> Message-ID: On Fri, Nov 25, 2016 at 3:51 PM, Shahid Shaikh wrote: > > Hi Volker, > > It looks like the issue here may be related to single processor VM. We tried building OpenJDK9 on multi processor VM Ubuntu 16.04 x86 VM today and build was successful. > > We can see following difference in 'configure' logs: > Older VM configure log: > Build performance summary: > * Cores to use: 1 > * Memory limit: 1898 MB > > New VM configure log: > Build performance summary: > * Cores to use: 2 > * Memory limit: 3951 MB > > Could you please verify that you get the same build failure for single processor machine? > Hi Shahid, I don't believe this is an issue with single processor machines. In the end you can always build with "JOBS=1" which should give you the same results like on a single core machine. I actually don't have a single core machine but I've just retried the build with "JOBS=1" and it still succeeded. Also, as far as I remember, you could finally build on a Linux/s390 single core machine after we had fixed the corresponding s390 related bug. Anyway, I'm happy that you can finally build on x86 :) Regards, Volker > > Thanks & Regards, > Shahid > > Volker Simonis ---11/23/2016 06:54:15 PM---Hi Shahid, the first thing I see in configure log is: > > From: Volker Simonis > To: Shahid Shaikh/Austin/Contr/IBM at IBMUS > Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee , "Lindenmaier, Goetz" , "Schmidt, Lutz" , "Doerr, Martin" , "s390x-port-dev at openjdk.java.net" > Date: 11/23/2016 06:54 PM > > > Subject: Re: jdk9/hs repo build issues for s390x > ________________________________ > > > > Hi Shahid, > > the first thing I see in configure log is: > > WARNING: The result of this configuration has overridden an older > configuration. You *should* run 'make clean' to make sure you get a > proper build. Failure to do so might result in strange build problems. > > So you should do "make clean" before building. But maybe this is only there because you've re-executed configure after the build. > > If you have build problems, I always recommend to use LOG=debug JOBS=1 (i.e. 'make all LOG=debug JOBS=1'). This will give you a much more detailed trace of what's going on. > > From your build log file I can see that linking FPRegs fails in your case: > > Creating FPRegs from 1 file(s) > /SSWorkspace/OpenJDK9/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: In function `closeHandle': > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:48: undefined reference to `dlclose' > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:49: undefined reference to `dlerror' > /SSWorkspace/OpenJDK9/build/linux-x86_64-normal-server-release/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: In function `loadJVM': > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:69: undefined reference to `dlopen' > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:77: undefined reference to `dlsym' > /SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c:88: undefined reference to `dlerror' > collect2: error: ld returned 1 exit status > > On my machine the corresponding commands look as follows (if building with LOG=debug): > > Compiling exeFPRegs.c (for FPRegs) > ( /usr/bin/gcc -Wall -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer -D_LITTLE_ENDIAN -DLINUX -D_LP64=1 -DARCH='"amd64"' -Damd64 -DDEBUG -I/priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/modules_include/java.base -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/native/include -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/linux/native/include -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/unix/native/include -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/share/native/libjava -I/usr/work/d046063/OpenJDK/jdk9-hs/jdk/src/java.base/unix/native/libjava -fno-strict-aliasing -g -fstack-protector-all --param ssp-buffer-size=1 -Werror -g -Werror -O0 -DTHIS_FILE='"exeFPRegs.c"' -c -MMD -MF /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.d -o /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o /usr/work/d046063/OpenJDK/jdk9-hs/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFPRegs.c > >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o.log) 2> >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o.log >&2) || ( exitcode=$? && /bin/cp /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o.log /priv/d046063/OpenJDK/output-jdk9-hs-dbg/make-support/failure-logs/support_test_hotspot_jtreg_native_support_exeFPRegs_exeFPRegs.o.log && exit $exitcode ) ) > > Linking executable FPRegs > ( /usr/bin/gcc -Wl,--hash-style=both -Wl,-z,defs -Wl,-z,now -Wl,-z,relro -Wl,--allow-shlib-undefined -L/priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/modules_libs/java.base/amd64 -L/priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/modules_libs/java.base/amd64/server -o /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/bin/FPRegs /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o -ldl > >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/BUILD_TEST_FPRegs_link.log) 2> >(/usr/bin/tee /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/BUILD_TEST_FPRegs_link.log >&2) || ( exitcode=$? && /bin/cp /priv/d046063/OpenJDK/output-jdk9-hs-dbg/support/test/hotspot/jtreg/native/support/exeFPRegs/BUILD_TEST_FPRegs_link.log /priv/d046063/OpenJDK/output-jdk9-hs-dbg/make-support/failure-logs/support_test_hotspot_jtreg_native_support_exeFPRegs_BUILD_TEST_FPRegs_link.log && exit $exitcode ) ) > > Linking exeFPRegs.o into FPRegs seems actually quite trivial. It uses -ldl which contains the various dl* you are missing. > > Can you please do a new, clean build with LOG=debug. If you still get the same problem can you please try the two two command lines (i.e. compiling exeFPRegs.c and linking exeFPRegs.o) manually on the command line. > > Regards, > Volker > > > On Tue, Nov 22, 2016 at 2:49 PM, Shahid Shaikh wrote: > > Hi Martin, > > Please find attached files for the 'configure' and 'make all' command logs (for OpenJDK9 build on Ubuntu 16.04 x86). > > Following are the build steps we are executing: > apt-get install mercurial -y > hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9 > cd OpenJDK9/ > bash ./get_source.sh > apt-get install libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev libasound2-dev libfreetype6-dev libcups2-dev -y > apt-get install openjdk-8-jdk -y > apt-get install zip unzip -y > apt-get install libffi-dev -y > unset JAVA_HOME > export LANG=C > export PATH="/usr/lib/jvm/java-8-openjdk-amd64/bin:${PATH}" > bash ./configure --with-jvm-variants=server --disable-warnings-as-errors > make all > > Please let us know if we're missing anything. > > Thanks & Regards, > Shahid > > (See attached file: Ubuntu16.04_x86_OpenJDK9_configure.log)(See attached file: Ubuntu16.04_x86_OpenJDK9_make all.log) > > Volker Simonis ---11/21/2016 07:31:36 PM---On Fri, Nov 18, 2016 at 2:38 PM, Shahid Shaikh wrote: > Hi Martin, > > From: Volker Simonis > To: Shahid Shaikh/Austin/Contr/IBM at IBMUS > Cc: "Doerr, Martin" , Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee , "Lindenmaier, Goetz" , "Schmidt, Lutz" , "s390x-port-dev at openjdk.java.net" > Date: 11/21/2016 07:31 PM > > > Subject: Re: jdk9/hs repo build issues for s390x > ________________________________ > > > > > > On Fri, Nov 18, 2016 at 2:38 PM, Shahid Shaikh wrote: > > Hi Martin, > > Apologies for late reply. We were working on testing the new 'jdk9/hs' repository where the patch has been pushed. We tested the build on RHEL7.2 and SLES12SP1 s390x VMs and the build is successful. > > >> Do you know if it is the same on single-processor x86 systems? > The x86 VM which we used for testing is multi-processor. > > @Volker/Martin: Could you please give us some insight into 'jdk9/hs' repository? Because when we build OpenJDK9 from 'jdk9/jdk9' (JDK9 master) repository on Ubuntu x86 VM, the build is successful. However when we build 'jdk9/hs' on Ubuntu x86 VM, the build is failing. > > > > I don't understand this. I've just build a fresh version of jdk9/hs without any problems on my Ubuntu 16.04/x86_64 machine (bot 'images' and 'all' targets worked). > > Can you please describe you problem a little bit more detailed? > > > So it looks like 'jdk9/hs' repository may not be in sync with JDK9 master repository. So we are not able to build OpenJDK9 for s390x for z system. > > Please check and let us know if you have any queries/comments. > > Thanks & Regards, > Shahid > > "Doerr, Martin" ---11/15/2016 04:56:31 PM---Hi Shahid, the patch is part of the following change: > > From: "Doerr, Martin" > To: Shahid Shaikh/Austin/Contr/IBM at IBMUS > Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee , "Lindenmaier, Goetz" , "Schmidt, Lutz" , "s390x-port-dev at openjdk.java.net" , Volker Simonis > Date: 11/15/2016 04:56 PM > > > Subject: RE: jdk9/hs repo build issues for s390x > > ________________________________ > > > > Hi Shahid, > > the patch is part of the following change: > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/17a959a33da5 > > It was pushed a couple of days ago. > > I was also wondering about the following part of the hs_err file you had sent: > Threads with active compile tasks: > C1 CompilerThread1 5 1 java.lang.StringLatin1::charAt (28 bytes) > C1 CompilerThread0 4 1 java.lang.String::charAt (25 bytes) > > We should have 1 C1 and 1 C2 compiler thread on single-processor systems. Maybe the message is wrong. > Do you know if it is the same on single-processor x86 systems? > > Best regards, > Martin > > From: Shahid Shaikh [mailto:shahid at us.ibm.com] > Sent: Dienstag, 15. November 2016 11:52 > To: Doerr, Martin > Cc: Amod Borkar ; Cindy Lee ; Lindenmaier, Goetz ; Schmidt, Lutz ; s390x-port-dev at openjdk.java.net; Volker Simonis > Subject: RE: jdk9/hs repo build issues for s390x > > Hi Martin, > > With the given patch, our build is successful for single-processor z system. We tried the build on RHEL7.2 and SLES12SP1 distributions. > > Please let us know when this patch will get merged to the jdk9/hs repository. > > Regards, > Shahid > > "Doerr, Martin" ---11/09/2016 08:57:25 PM---Hi Shahid, if the issue on Ubuntu is still the single-processor LPAR, you can try the following patc > > From: "Doerr, Martin" > To: Shahid Shaikh/Austin/Contr/IBM at IBMUS, Volker Simonis > Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee , "Lindenmaier, Goetz" , "Schmidt, Lutz" , "s390x-port-dev at openjdk.java.net" > Date: 11/09/2016 08:57 PM > Subject: RE: jdk9/hs repo build issues for s390x > > ________________________________ > > > > > Hi Shahid, > > if the issue on Ubuntu is still the single-processor LPAR, you can try the following patch: > http://cr.openjdk.java.net/~mdoerr/s390_singleprocessor.patch > > @Goetz: Please add this to the z fixes change if it resolves the issue. (Need feedback from Shahid.) > > Best regards, > Martin > > > From: Shahid Shaikh [mailto:shahid at us.ibm.com] > Sent: Mittwoch, 9. November 2016 15:49 > To: Volker Simonis > Cc: Amod Borkar ; Cindy Lee ; Lindenmaier, Goetz ; Schmidt, Lutz ; Doerr, Martin ; s390x-port-dev at openjdk.java.net > Subject: Re: jdk9/hs repo build issues for s390x > > Hi Volker, > > As per the suggestion from Martin, we tried building OpenJDK9 on multi-processor z systems and the build is successful on RHEL7.2 and SLES12SP1. However the build is still failing for Ubuntu 16.04 distribution. > > Please let us know what else we can try for Ubuntu. > > Thanks & Regards, > Shahid > > Volker Simonis ---11/08/2016 07:07:11 PM---On Tue, Nov 8, 2016 at 9:53 AM, Shahid Shaikh wrote: > Hi Volker, > > From: Volker Simonis > To: Shahid Shaikh/Austin/Contr/IBM at IBMUS > Cc: Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee , "Lindenmaier, Goetz" , "Schmidt, Lutz" , "Doerr, Martin" , "s390x-port-dev at openjdk.java.net" > Date: 11/08/2016 07:07 PM > Subject: Re: jdk9/hs repo build issues for s390x > > ________________________________ > > > > > > > > On Tue, Nov 8, 2016 at 9:53 AM, Shahid Shaikh wrote: > > Hi Volker, > > Good observation :) > > This difference is because we are using Docker containers to test OpenJDK build. The hs_err file which we sent is extracted from a RHEL7.2 docker container running on Ubuntu 16.04 host. As you said correctly, the issue is not related. We can confirm that we are able to reproduce the same on RHEL7.2 host VM. > > > Thanks for the explanation! > We never saw something similar before but it's good to know where it stems from. One never stops learning :) > > Regards, > Volker > > As per suggestion from Martin Doerr, we are trying to build OpenJDK9 on a multi-processor z system. We will update you once we have the results. > > Thanks & Regards, > Shahid > > Volker Simonis ---11/08/2016 01:53:57 PM---Hi Shahid, it is surely not related to this issue but it would be highly > > From: Volker Simonis > To: Shahid Shaikh/Austin/Contr/IBM at IBMUS > Cc: "Schmidt, Lutz" , Amod Borkar/Austin/Contr/IBM at IBMUS, Cindy Lee , "Lindenmaier, Goetz" , "Doerr, Martin" , "s390x-port-dev at openjdk.java.net" > Date: 11/08/2016 01:53 PM > > > Subject: Re: jdk9/hs repo build issues for s390x > > ________________________________ > > > > > > Hi Shahid, > > it is surely not related to this issue but it would be highly > interesting to know what exact system you are running on. The system > detection in the hs_err file looks reads really weird: > > OS:Red Hat Enterprise Linux Server release 7.2 (Maipo) > uname:Linux 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:47:15 UTC 2016 s390x > > So you really have a RHEL 7.2 installation with a Ubuntu kernel? > > Thanks, > Volker > > > On Mon, Nov 7, 2016 at 5:26 PM, Shahid Shaikh wrote: > > Hi Volker/Lutz, > > > > Thanks for your help. Please find attached hs_err_pid48608.log and > > replay_pid48608.log files. Also, the configure and build logs. > > > > Please find my comments inline. > > > > Thanks & Regards, > > Shahid > > > > (See attached file: OpenJDK9_rhel7.2_build.log)(See attached file: > > OpenJDK9_rhel7.2_configure.log)(See attached file: hs_err_pid30816.log)(See > > attached file: replay_pid30816.log) > > > > "Schmidt, Lutz" ---11/07/2016 07:42:40 PM---Hi, the below error points to an > > instruction pattern detection issue (what a > > > > From: "Schmidt, Lutz" > > To: Volker Simonis , Shahid > > Shaikh/Austin/Contr/IBM at IBMUS, "Lindenmaier, Goetz" > > , "Doerr, Martin" > > Cc: "s390x-port-dev at openjdk.java.net" , > > Cindy Lee , Amod Borkar/Austin/Contr/IBM at IBMUS > > Date: 11/07/2016 07:42 PM > > Subject: Re: jdk9/hs repo build issues for s390x > > > > ________________________________ > > > > > > > > Hi, > > > > > > the below error points to an instruction pattern detection issue (what a > > complicated name :-)). There is a ?Call Far Patchable? at the examined > > address, because > > c0e5fffdd3c0 translates into BRASL R14,0xfffdd3c0 > > The detection code expects the BRASL to be prepended with a nop (0x0700). > > Either, the nop isn?t there or the examined address is incorrect (two > > bytes too high). > > > > Im not sure if the hs_err_pid48608.log could help here. What we would need > > is a storage dump/disassembly around the examined address. > > > > Regards, Lutz > > > > > > On 04.11.16, 20:12, "s390x-port-dev on behalf of Volker Simonis" > > > volker.simonis at gmail.com> wrote: > > > >>On Fri, Nov 4, 2016 at 4:38 PM, Shahid Shaikh wrote: > >>> > >>> Hi, > >>> > >>> We are trying to build OpenJDK9 for s390x from 'jdk9/hs' repository > >>>(where > >>> the s390x code changes has been merged). However build is failing with > >>> following error: > >>> > >>> On RHEL7.2 / SLES12SP1: > >>> Compiling 1 files for java.se.ee > >>> Compiling 235 files for jdk.xml.ws > >>> Note: Some input files use or override a deprecated API. > >>> Note: Recompile with -Xlint:deprecation for details. > >>> Note: Some input files use unchecked or unsafe operations. > >>> Note: Recompile with -Xlint:unchecked for details. > >>> Compiling 4 files for BUILD_JIGSAW_TOOLS > >>> MacroAssembler::get_dest_of_call_far_patchable_at has a problem at > >>> 0x2003009c900: > >>> not a call_far_patchable: c0e5fffdd3c0e320 f0500004c0f40000, len = 8 > >>> Could not load hsdis-s390x.so; library not loadable; PrintAssembly is > >>> disabled > >>> # > >>> # A fatal error has been detected by the Java Runtime Environment: > >>> # > >>> # Internal Error (macroAssembler_s390.cpp:2532), pid=48608, tid=48614 > >>> # Error: ShouldNotReachHere() > >>> # > >>> # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal > >>> +0-2016-11-03-151506..OpenJDK9) > >>> # Java VM: OpenJDK 64-Bit Server VM (9-internal > >>> +0-2016-11-03-151506..OpenJDK9, mixed mode, tiered, compressed oops, > >>>serial > >>> gc, linux-s390x) > >>> # Core dump will be written. Default location: Core dumps may be > >>>processed > >>> with "/usr/share/apport/apport %p %s %c %P" (or dumping > >>> to /SSWorkspace/OpenJDK9/make/core.48608) > >>> # > >>> # An error report file with more information is saved as: > >>> # /SSWorkspace/OpenJDK9/make/hs_err_pid48608.log > >>> # > >>> # Compiler replay data is saved as: > >>> # /SSWorkspace/OpenJDK9/make/replay_pid48608.log > >>> # > >> > >>Hi Shahid, > >> > >>sorry to hear you have problems with the port. > >> > >>Could you please send us the two /hs_err_pid48608.log and > >>replay_pid48608.log files so we can further investigate the error. > >>They will be stripped from the mailing list, but if you do a > >>"reply-all" to this mail, my colleagues and I will get them. > >> > >>We've detected one problem with the port and currently do our nightly > >>builds (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/) with > >>the attached patch. You could try it but it doesn't seems to be > >>related to your problem. > >> > >>Could you please also send the output of configure along with the log > >>files so we can see what tools you are using. > >> > >>> # If you would like to submit a bug report, please visit: > >>> # http://bugreport.java.com/bugreport/crash.jsp > > >>> # > >>> gmake[3]: *** > >>> > >>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/jdk/_packa > >>>ges_attribute.done] > >>> Aborted (core dumped) > >>> gmake[2]: *** [exploded-image-optimize] Error 1 > >>> > >>> On Ubuntu 16.04: > >>> Creating libTestJNI.so from 1 file(s) > >>> Creating FPRegs from 1 file(s) > >>> Creating invoke from 1 file(s) > >>> > >>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes > >>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: > >>> In function `closeHandle': > >>> > >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP > >>>Regs.c:48: > >>> undefined reference to `dlclose' > >>> > >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP > >>>Regs.c:49: > >>> undefined reference to `dlerror' > >>> > >>>/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/tes > >>>t/hotspot/jtreg/native/support/exeFPRegs/exeFPRegs.o: > >>> In function `loadJVM': > >>> > >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP > >>>Regs.c:69: > >>> undefined reference to `dlopen' > >>> > >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP > >>>Regs.c:77: > >>> undefined reference to `dlsym' > >>> > >>>/SSWorkspace/OpenJDK9/hotspot/test/runtime/jni/CalleeSavedRegisters/exeFP > >>>Regs.c:88: > >>> undefined reference to `dlerror' > >>> collect2: error: ld returned 1 exit status > >>> JtregNative.gmk:111: recipe for target > >>> > >>>'/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te > >>>st/hotspot/jtreg/native/bin/FPRegs' > >>> failed > >>> make[3]: *** > >>> > >>>[/SSWorkspace/OpenJDK9/build/linux-s390x-normal-server-release/support/te > >>>st/hotspot/jtreg/native/bin/FPRegs] > >>> Error 1 > >>> make[2]: *** [build-test-hotspot-jtreg-native] Error 1 > >>> make[2]: *** Waiting for unfinished jobs.... > >>> make/Main.gmk:398: recipe for target 'build-test-hotspot-jtreg-native' > >>> failed > >>> Creating support/symbols/ct.sym > >>> > >>> ERROR: Build failed for target 'all' in configuration > >>> 'linux-s390x-normal-server-release' (exit code 2) > >>> Stopping sjavac server > >>> > >> > &g t;>So this seems to be a different problem. It is a known bug that the > > >>tests are currently not completely working. Goetz still has a bug open > >>for this ( > https://bugs.openjdk.java.net/browse/JDK-8166837) but you > > >>can already find a webrev which should fix the issue and which should > >>hopefully be pushed soon here: > >> > >> > http://cr.openjdk.java.net/~goetz/wr16/8166837-jtreg_fixes/jdk-wr.02 > > >> > >>Can you please try to just build the "images" target and report if > >>that succeeds? If it does, you should find a complete image under > >>images/jdk which you could use for testing. > >> > > > > After applying the above code changes manually, the above error is gone for > > Ubuntu 16.04 s390x build environment. However the 'make images' command is > > still failing and now the error is similar to what we are getting for > > RHEL7.2 and SLES12SP1 distributions. > > > >>If at least the "images" target succeeds on Ubuntu than the other > >>build failure seems to be related to RHEL7.2 / SLES12SP1. Maybe they > >>use another version of GCC which has some problems? > >> > > > > Yes, the 'make' versions are different. Its '4.1' for Ubuntu 16.04 and > > '3.82' for RHEL7.2. > > > >>Regards, > >>Volker > >> > >>> > >>> We are using following steps to build OpenJDK9: > >>> hg clone http://hg.openjdk.java.net/jdk9/hs OpenJDK9 > >>> cd OpenJDK9 > >>> bash ./get_source.sh > >>> unset JAVA_HOME > >>> export LANG=C > >>> export > >>> > >>>PATH="/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.s390x/bin:$ > >>> {PATH}" > >>> bash ./configure --with-jvm-variants=server > >>>--disable-warnings-as-errors > >>> make all > >>> > >> > >>That sounds reasonable. > >> > >>> > >>> We tried same on x86 machine and got the same build failure. > >>> > >> > >>That's strange. I just saw that we also use --with-jtreg on the > >>configure command line which points to the latest version of JTreg > >>we've built. Maybe that's the problem if you have build failures on > >>x86? Again, try to build 'images' first and only if that succeeds try > >>'test-images' or 'all'. > >> > > > > We tried with '--with-jtreg' in the configure command (after installing > > jtreg) and the 'make images' worked in our Ubuntu 16.04 x86 build > > environment. However the 'make all' is still failing. > > > >>Regards, > >>Volker > >> > >>PS: could you (and your colleagues) please subscribe to the list. > >>Otherwise you mails will be on hold until I moderate them. > >> > > > >>> Please let us know if we are missing anything here. > >>> > >>> Thanks & Regards, > >>> Shahid > > > > > > > > > From erik.joelsson at oracle.com Mon Nov 28 16:55:00 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 17:55:00 +0100 Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583C5B10.8040204@linux.vnet.ibm.com> References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: <1b332dd2-aa9f-e24b-faaf-b95eacd11dac@oracle.com> Looks good. /Erik On 2016-11-28 17:28, Gustavo Romero wrote: > Hi all, > > I'm re-sending due to JDK title update to include s390x and aarch64 archs. > > Could the following webrev be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > Thank you. > > > Regards, > Gustavo > From volker.simonis at gmail.com Tue Nov 29 09:41:10 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Nov 2016 10:41:10 +0100 Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583C5B10.8040204@linux.vnet.ibm.com> References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: Thanks Gustavo, the change looks good. So now we're just waiting for another review from somebody of the aarch64 folks. Once we have that and the fc-request is approved I'll push the changes. Regards, Volker On Mon, Nov 28, 2016 at 5:28 PM, Gustavo Romero wrote: > Hi all, > > I'm re-sending due to JDK title update to include s390x and aarch64 archs. > > Could the following webrev be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > Thank you. > > > Regards, > Gustavo > From volker.simonis at gmail.com Tue Nov 29 18:06:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Nov 2016 19:06:05 +0100 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583DAD7E.7020807@linux.vnet.ibm.com> References: <583C5B10.8040204@linux.vnet.ibm.com> <583DAD7E.7020807@linux.vnet.ibm.com> Message-ID: On Tue, Nov 29, 2016 at 5:31 PM, Gustavo Romero wrote: > Hi Andrew, > > On 29-11-2016 13:35, Andrew Haley wrote: >> On 29/11/16 09:41, Volker Simonis wrote: >>> Thanks Gustavo, >>> >>> the change looks good. >>> >>> So now we're just waiting for another review from somebody of the aarch64 folks. >>> Once we have that and the fc-request is approved I'll push the changes. >> >> One thing I don't understand: >> >> cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s >> sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s >> >> Do you know what causes the lower digits to be different? Is >> it that Math and StrictMath use different algorithms, not just >> different optimization levels? > > I don't know exactly what's the root cause for that difference (in the result). > The difference is not present on x64, however on PPC64 even with -O0 (as it is > by now) that difference exists. > > Math methods are intrisified, but StricMath are not. But I understand that Math > and StrictMath share the fdlibm code since I already changed some code in fdlibm > that reflected both on Math and StrictMath, so it's not clear to me where the > Math relaxation occurs on PPC64 (given that such a relaxation is allowed [1]). > I think the difference is because Math functions can be intrinsified (and optimized) while StricMath functions can not. HotSpot has different ways of intrinsifying the Math functions. If the CPU is supporting the corresponding function the VM generates special nodes for that. Otherwise, if there exist special optimized assembler stubs for a function (e.g. see "StubRoutines::_dsin = generate_libmSin()" in stubGenerator_x86_64.cpp) the VM makes use of them. Otherwise it still uses leaf-calls into HotSpots internal C++-Implementation of the functions (e.g. SharedRuntime::dsin() in sharedRuntimeTrig.cpp) which are faster than doing a native call into the fdlibm version. The implementation in SharedRuntime doesn't has to be "strict" so it probably uses fused multiplication and it is also build with full optimization without '-ffp-contract=off' (which is OK in this case). @Andrew: are you fine with Gustavos latest version of the change? > For sure others much more experienced than I can comment about difference. > > > Regards, > Gustavo > > [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html > From gromero at linux.vnet.ibm.com Mon Nov 28 16:28:00 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 28 Nov 2016 14:28:00 -0200 Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation Message-ID: <583C5B10.8040204@linux.vnet.ibm.com> Hi all, I'm re-sending due to JDK title update to include s390x and aarch64 archs. Could the following webrev be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ bug: https://bugs.openjdk.java.net/browse/JDK-8170153 Thank you. Regards, Gustavo From aph at redhat.com Tue Nov 29 15:35:16 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Nov 2016 15:35:16 +0000 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: On 29/11/16 09:41, Volker Simonis wrote: > Thanks Gustavo, > > the change looks good. > > So now we're just waiting for another review from somebody of the aarch64 folks. > Once we have that and the fc-request is approved I'll push the changes. One thing I don't understand: cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s Do you know what causes the lower digits to be different? Is it that Math and StrictMath use different algorithms, not just different optimization levels? Andrew. From gromero at linux.vnet.ibm.com Tue Nov 29 16:31:58 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 29 Nov 2016 14:31:58 -0200 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: <583DAD7E.7020807@linux.vnet.ibm.com> Hi Andrew, On 29-11-2016 13:35, Andrew Haley wrote: > On 29/11/16 09:41, Volker Simonis wrote: >> Thanks Gustavo, >> >> the change looks good. >> >> So now we're just waiting for another review from somebody of the aarch64 folks. >> Once we have that and the fc-request is approved I'll push the changes. > > One thing I don't understand: > > cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s > sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s > > Do you know what causes the lower digits to be different? Is > it that Math and StrictMath use different algorithms, not just > different optimization levels? I don't know exactly what's the root cause for that difference (in the result). The difference is not present on x64, however on PPC64 even with -O0 (as it is by now) that difference exists. Math methods are intrisified, but StricMath are not. But I understand that Math and StrictMath share the fdlibm code since I already changed some code in fdlibm that reflected both on Math and StrictMath, so it's not clear to me where the Math relaxation occurs on PPC64 (given that such a relaxation is allowed [1]). For sure others much more experienced than I can comment about difference. Regards, Gustavo [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html From aph at redhat.com Tue Nov 29 18:15:09 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Nov 2016 18:15:09 +0000 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583C5B10.8040204@linux.vnet.ibm.com> <583DAD7E.7020807@linux.vnet.ibm.com> Message-ID: <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com> On 29/11/16 18:06, Volker Simonis wrote: > @Andrew: are you fine with Gustavos latest version of the change? Sure. The StrictMath versions all seem to give the same results. Andrew. From gromero at linux.vnet.ibm.com Tue Nov 29 18:37:01 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 29 Nov 2016 16:37:01 -0200 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com> References: <583C5B10.8040204@linux.vnet.ibm.com> <583DAD7E.7020807@linux.vnet.ibm.com> <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com> Message-ID: <583DCACD.3090803@linux.vnet.ibm.com> Hi Erik, Volker, Andrew On 29-11-2016 16:15, Andrew Haley wrote: > On 29/11/16 18:06, Volker Simonis wrote: >> @Andrew: are you fine with Gustavos latest version of the change? > > Sure. The StrictMath versions all seem to give the same results. > > Andrew. > Thanks for reviewing the change! I changed the "FC Extension Request" status to "reviewed". Regards, Gustavo