From erik.joelsson at oracle.com Thu Oct 1 13:16:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Oct 2015 15:16:08 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560BD900.9000308@oracle.com> References: <560BD900.9000308@oracle.com> Message-ID: <560D3218.5070205@oracle.com> Still looking for an official review from 8u reviewer for this. Ideally someone from Hotspot. /Erik On 2015-09-30 14:43, Erik Joelsson wrote: > Hello, > > Please approve and review this fix for 8u. > > My last fix for this issue, JDK-8136691, was not enough. I made a > mistake while verifying the fix and the problem is still there. > > There are more discrepancies between Solaris and the other platform > makefiles. The excludeSrc.gmk file is not included anywhere when > building on Solaris. The variable Src_Files_EXCLUDE is overwritten in > vm.make instead of appended to, so even when including excludeSrc.gmk, > it wasn't enough. The other platform specific buildtree.make files > also set INCLUDE_TRACE in the generated makefile. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 > Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ > > /Erik From erik.joelsson at oracle.com Thu Oct 1 13:31:36 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Oct 2015 15:31:36 +0200 Subject: RFR: JDK-8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx Message-ID: <560D35B8.70101@oracle.com> Hello, Please review this trivial fix for compiling libjsig on macosx. The compilation of libjsig on macosx is currently not getting the EXTRA_CFLAGS supplied to the hotspot build. This means any kind of sysroot/sdkname setting from configure isn't honored. Historically this has likely not mattered at all, but in the compiler upgrade project, it matters a great deal. Bug: https://bugs.openjdk.java.net/browse/JDK-8138692 Patch: diff -r 983c56341c80 make/bsd/makefiles/jsig.make --- a/make/bsd/makefiles/jsig.make +++ b/make/bsd/makefiles/jsig.make @@ -62,7 +62,7 @@ $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) @echo $(LOG_INFO) Making signal interposition lib... $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) $(EXTRA_CFLAGS) -o $@ $< ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) ifeq ($(OS_VENDOR), Darwin) $(DSYMUTIL) $@ /Erik From magnus.ihse.bursie at oracle.com Thu Oct 1 13:32:43 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 1 Oct 2015 15:32:43 +0200 Subject: RFR: JDK-8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx In-Reply-To: <560D35B8.70101@oracle.com> References: <560D35B8.70101@oracle.com> Message-ID: <560D35FB.8080402@oracle.com> On 2015-10-01 15:31, Erik Joelsson wrote: > Hello, > > Please review this trivial fix for compiling libjsig on macosx. > > The compilation of libjsig on macosx is currently not getting the > EXTRA_CFLAGS supplied to the hotspot build. This means any kind of > sysroot/sdkname setting from configure isn't honored. Historically > this has likely not mattered at all, but in the compiler upgrade > project, it matters a great deal. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138692 > Patch: > diff -r 983c56341c80 make/bsd/makefiles/jsig.make > --- a/make/bsd/makefiles/jsig.make > +++ b/make/bsd/makefiles/jsig.make > @@ -62,7 +62,7 @@ > $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) > @echo $(LOG_INFO) Making signal interposition lib... > $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ > - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< > + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > $(EXTRA_CFLAGS) -o $@ $< > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > ifeq ($(OS_VENDOR), Darwin) > $(DSYMUTIL) $@ > > /Erik Looks good to me. /Magnus From mikael.vidstedt at oracle.com Thu Oct 1 18:35:22 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 1 Oct 2015 11:35:22 -0700 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560D3218.5070205@oracle.com> References: <560BD900.9000308@oracle.com> <560D3218.5070205@oracle.com> Message-ID: <560D7CEA.5050302@oracle.com> Looks ok. (This really needs to be unified, but we know that) Cheers, Mikael On 2015-10-01 06:16, Erik Joelsson wrote: > Still looking for an official review from 8u reviewer for this. > Ideally someone from Hotspot. > > /Erik > > On 2015-09-30 14:43, Erik Joelsson wrote: >> Hello, >> >> Please approve and review this fix for 8u. >> >> My last fix for this issue, JDK-8136691, was not enough. I made a >> mistake while verifying the fix and the problem is still there. >> >> There are more discrepancies between Solaris and the other platform >> makefiles. The excludeSrc.gmk file is not included anywhere when >> building on Solaris. The variable Src_Files_EXCLUDE is overwritten in >> vm.make instead of appended to, so even when including >> excludeSrc.gmk, it wasn't enough. The other platform specific >> buildtree.make files also set INCLUDE_TRACE in the generated makefile. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >> >> /Erik > From mikael.vidstedt at oracle.com Thu Oct 1 18:36:31 2015 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 1 Oct 2015 11:36:31 -0700 Subject: RFR: JDK-8138692: libjsig compilation is missing EXTRA_CFLAGS on macosx In-Reply-To: <560D35B8.70101@oracle.com> References: <560D35B8.70101@oracle.com> Message-ID: <560D7D2F.8060707@oracle.com> Good! Cheers, Mikael On 2015-10-01 06:31, Erik Joelsson wrote: > Hello, > > Please review this trivial fix for compiling libjsig on macosx. > > The compilation of libjsig on macosx is currently not getting the > EXTRA_CFLAGS supplied to the hotspot build. This means any kind of > sysroot/sdkname setting from configure isn't honored. Historically > this has likely not mattered at all, but in the compiler upgrade > project, it matters a great deal. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138692 > Patch: > diff -r 983c56341c80 make/bsd/makefiles/jsig.make > --- a/make/bsd/makefiles/jsig.make > +++ b/make/bsd/makefiles/jsig.make > @@ -62,7 +62,7 @@ > $(LIBJSIG): $(JSIGSRCDIR)/jsig.c $(LIBJSIG_MAPFILE) > @echo $(LOG_INFO) Making signal interposition lib... > $(QUIETLY) $(CC) $(SYMFLAG) $(ARCHFLAG) $(SHARED_FLAG) $(PICFLAG) \ > - $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) -o $@ $< > + $(LFLAGS_JSIG) $(JSIG_DEBUG_CFLAGS) > $(EXTRA_CFLAGS) -o $@ $< > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > ifeq ($(OS_VENDOR), Darwin) > $(DSYMUTIL) $@ > > /Erik From daniel.smith at oracle.com Thu Oct 1 21:20:36 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 1 Oct 2015 15:20:36 -0600 Subject: OS X El Capitan & freetype Message-ID: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> The OS X El Capitan installer cleans out the /usr directory, including /usr/X11R6. This is part of the System Integrity Protection feature [1], which also blocks future third-party installs from writing to that location. Result: configure breaks when it can't find freetype, even after I've re-installed XQuartz. The files can be found in /opt/X11; there's also a symbolic link from /usr/X11 (I'm not sure how that came to be, or why the config script doesn't try it). Workaround: sh configure --with-freetype-include=/opt/X11/include/freetype2 --with-freetype-lib=/opt/X11/lib ?Dan [1] https://en.wikipedia.org/wiki/System_Integrity_Protection From henry.jen at oracle.com Thu Oct 1 21:29:04 2015 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 1 Oct 2015 14:29:04 -0700 Subject: OS X El Capitan & freetype In-Reply-To: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> References: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> Message-ID: <2D347D47-57B4-40F4-AB8F-0BD094685F1E@oracle.com> My upgrade experience is easier, all I need to do is run. xcode-select ?install. Cheers, Henry > On Oct 1, 2015, at 2:20 PM, Dan Smith wrote: > > The OS X El Capitan installer cleans out the /usr directory, including /usr/X11R6. This is part of the System Integrity Protection feature [1], which also blocks future third-party installs from writing to that location. > > Result: configure breaks when it can't find freetype, even after I've re-installed XQuartz. > > The files can be found in /opt/X11; there's also a symbolic link from /usr/X11 (I'm not sure how that came to be, or why the config script doesn't try it). > > Workaround: > > sh configure --with-freetype-include=/opt/X11/include/freetype2 --with-freetype-lib=/opt/X11/lib > > ?Dan > > [1] https://en.wikipedia.org/wiki/System_Integrity_Protection From philip.race at oracle.com Thu Oct 1 21:40:11 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 01 Oct 2015 14:40:11 -0700 Subject: OS X El Capitan & freetype In-Reply-To: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> References: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> Message-ID: <560DA83B.2080005@oracle.com> On an Apple list it was noted that this 10.11 feature also partially breaks the Xserver since files that it needs to place in /System/Fonts are no longer allowed. I think a lot of people are going to find they need to disable this feature. -phil. On 10/1/15, 2:20 PM, Dan Smith wrote: > The OS X El Capitan installer cleans out the /usr directory, including /usr/X11R6. This is part of the System Integrity Protection feature [1], which also blocks future third-party installs from writing to that location. > > Result: configure breaks when it can't find freetype, even after I've re-installed XQuartz. > > The files can be found in /opt/X11; there's also a symbolic link from /usr/X11 (I'm not sure how that came to be, or why the config script doesn't try it). > > Workaround: > > sh configure --with-freetype-include=/opt/X11/include/freetype2 --with-freetype-lib=/opt/X11/lib > > ?Dan > > [1] https://en.wikipedia.org/wiki/System_Integrity_Protection From daniel.smith at oracle.com Thu Oct 1 21:47:04 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 1 Oct 2015 15:47:04 -0600 Subject: OS X El Capitan & freetype In-Reply-To: <560DA83B.2080005@oracle.com> References: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> <560DA83B.2080005@oracle.com> Message-ID: <044735B4-E9AD-4B41-A06D-6C52525FCF2D@oracle.com> Could be, but I don't care at all about running X11. I just want "make images" to work. I'm a little fuzzy on the details here -- who created /usr/X11R6 (it seems to be present on all vanilla Yosemite Macs around my house, but without headers), who created /usr/X11, what the XQuartz installer does. But I can reliably say that XQuartz installs its files in /opt/X11, and that it should not be hard for the configure script to detect that location. ?Dan > On Oct 1, 2015, at 3:40 PM, Philip Race wrote: > > On an Apple list it was noted that this 10.11 feature also partially breaks the > Xserver since files that it needs to place in /System/Fonts are no longer allowed. > I think a lot of people are going to find they need to disable this feature. > > -phil. > > On 10/1/15, 2:20 PM, Dan Smith wrote: >> The OS X El Capitan installer cleans out the /usr directory, including /usr/X11R6. This is part of the System Integrity Protection feature [1], which also blocks future third-party installs from writing to that location. >> >> Result: configure breaks when it can't find freetype, even after I've re-installed XQuartz. >> >> The files can be found in /opt/X11; there's also a symbolic link from /usr/X11 (I'm not sure how that came to be, or why the config script doesn't try it). >> >> Workaround: >> >> sh configure --with-freetype-include=/opt/X11/include/freetype2 --with-freetype-lib=/opt/X11/lib >> >> ?Dan >> >> [1] https://en.wikipedia.org/wiki/System_Integrity_Protection From david.dehaven at oracle.com Thu Oct 1 23:56:02 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 1 Oct 2015 16:56:02 -0700 Subject: OS X El Capitan & freetype In-Reply-To: <044735B4-E9AD-4B41-A06D-6C52525FCF2D@oracle.com> References: <226604B5-EE5C-4A9B-B302-B62953A18825@oracle.com> <560DA83B.2080005@oracle.com> <044735B4-E9AD-4B41-A06D-6C52525FCF2D@oracle.com> Message-ID: <2919BB57-707D-4CC4-A8F2-0B8D105AE08B@oracle.com> > Could be, but I don't care at all about running X11. I just want "make images" to work. > > I'm a little fuzzy on the details here -- who created /usr/X11R6 (it seems to be present on all vanilla Yosemite Macs around my house, but without headers), who created /usr/X11, what the XQuartz installer does. But I can reliably say that XQuartz installs its files in /opt/X11, and that it should not be hard for the configure script to detect that location. IIRC, /usr/X11R6 is populated with stubs that get filled in when the (no longer available) optional X11 package was installed. XQuartz conveniently also installed in that same directory. I think future versions of XQuartz will have to install in /opt instead. -DrD- From erik.joelsson at oracle.com Fri Oct 2 08:13:43 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Oct 2015 10:13:43 +0200 Subject: RFR: JDK-8138739: Enable devkit on macosx in JPRT (again) Message-ID: <560E3CB7.7090604@oracle.com> Hello, Please review this minor fix to the jprt configuration, which again enables the use of devkits for macosx. This will be pushed to jdk9/client as that's where the final fixes needed for this are gathered. Bug: https://bugs.openjdk.java.net/browse/JDK-8138739 Patch: diff -r 1e64ec3d1c60 make/jprt.properties --- a/make/jprt.properties +++ b/make/jprt.properties @@ -127,6 +127,8 @@ ${jprt.i586.build.configure.args} jprt.windows_x64.build.configure.args= \ --with-devkit=$VS2013_HOME +jprt.macosx_x64.build.configure.args= \ + --with-devkit=$XCODE_511_HOME ######## # From erik.joelsson at oracle.com Fri Oct 2 13:34:09 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Oct 2015 15:34:09 +0200 Subject: RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed Message-ID: <560E87D1.9080906@oracle.com> Hello, While trying the macosx build using devkits again, I happened to be on a system where some Xcode install/update error had left the /usr/include directory missing. This shouldn't be an issue since we have all the necessary include files in the SDK inside the devkit/Xcode application. Getting this to work required several changes and cleanups that will actually improve build consistency overall. It will also guarantee that we use the correct system headers in all cases. * Setup SYSROOT_*FLAGS before detecting toolchain and make those flags available to the configure toolchain tests. * Setup the user supplied extra flags before toolchain detection so that those are also used during configure toolchain tests. * When not cross compiling, use the SYSROOT_*FLAGS also when compiling build tools, like adlc in hotspot, and gensrc tools in jdk. Bug: https://bugs.openjdk.java.net/browse/JDK-8138694 Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01/ /Erik From magnus.ihse.bursie at oracle.com Fri Oct 2 14:58:57 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Oct 2015 16:58:57 +0200 Subject: RFR: JDK-8138761 Improved handling of libffi, and cleanup of libraries.m4 Message-ID: <560E9BB1.5080403@oracle.com> To build zero, we need libffi. However, the code in configure to handle libffi is not up to normal library handling standards, so it is not possible to set it using configure arguments. When trying to rectify this, I finally got tired of the mess that libraries.m4 is. I have split it into parts, where each prominent library gets it's own file, and I've switched the logic on dependencies to be positive (i.e. linux needs alsa, not "macosx does NOT need alsa"). The cleanup includes: * Split libraries.m4. * Remove builddeps. * Remove last references to pulse. * Remove HAVE_ALTZONE. * Separate handling of bundled libs. * Set LIBM properly. The libffi support means that we now have --with-libffi[-libs/-include], just like for other libraries. Also, we sanity check that we can actually compile with libffi. Bug: https://bugs.openjdk.java.net/browse/JDK-8138761 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8138761-libffi-and-libraries-cleanup/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Oct 2 15:01:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Oct 2015 17:01:03 +0200 Subject: RFR: JDK-8138739: Enable devkit on macosx in JPRT (again) In-Reply-To: <560E3CB7.7090604@oracle.com> References: <560E3CB7.7090604@oracle.com> Message-ID: <560E9C2F.20706@oracle.com> On 2015-10-02 10:13, Erik Joelsson wrote: > Hello, > > Please review this minor fix to the jprt configuration, which again > enables the use of devkits for macosx. > > This will be pushed to jdk9/client as that's where the final fixes > needed for this are gathered. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138739 > Patch: > diff -r 1e64ec3d1c60 make/jprt.properties > --- a/make/jprt.properties > +++ b/make/jprt.properties > @@ -127,6 +127,8 @@ > ${jprt.i586.build.configure.args} > jprt.windows_x64.build.configure.args= \ > --with-devkit=$VS2013_HOME > +jprt.macosx_x64.build.configure.args= \ > + --with-devkit=$XCODE_511_HOME > > ######## > # > Woho! :-D Ship it. /Magnus From magnus.ihse.bursie at oracle.com Fri Oct 2 15:14:53 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Oct 2015 17:14:53 +0200 Subject: RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed In-Reply-To: <560E87D1.9080906@oracle.com> References: <560E87D1.9080906@oracle.com> Message-ID: <560E9F6D.9030601@oracle.com> On 2015-10-02 15:34, Erik Joelsson wrote: > Hello, > > While trying the macosx build using devkits again, I happened to be on > a system where some Xcode install/update error had left the > /usr/include directory missing. This shouldn't be an issue since we > have all the necessary include files in the SDK inside the > devkit/Xcode application. > > Getting this to work required several changes and cleanups that will > actually improve build consistency overall. It will also guarantee > that we use the correct system headers in all cases. > > * Setup SYSROOT_*FLAGS before detecting toolchain and make those flags > available to the configure toolchain tests. > * Setup the user supplied extra flags before toolchain detection so > that those are also used during configure toolchain tests. > * When not cross compiling, use the SYSROOT_*FLAGS also when compiling > build tools, like adlc in hotspot, and gensrc tools in jdk. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138694 > Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01/ Your changes looks good. However, I notice that there is a problem with the code that you moved. In FLAGS_SETUP_SYSROOT_FLAGS, there is a test: elif test "x$OPENJDK_TARGET_OS" = xmacosx; then # Apple only wants -isysroot , but we also need -iframework/System/Library/Frameworks SYSROOT_CFLAGS="-isysroot $SYSROOT -iframework $SYSROOT/System/Library/Frameworks" SYSROOT_LDFLAGS=$SYSROOT_CFLAGS but this is incorrect. Remove this and instead add the -iframework stuff at the end. There is already a macosx test for adding framework flags, the -iframework addition fits in perfect there. /Magnus From anthony.scarpino at oracle.com Fri Oct 2 17:08:26 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 2 Oct 2015 10:08:26 -0700 Subject: RFR 8133151: Preferred provider configuration for JCE Message-ID: <560EBA0A.7040808@oracle.com> Hi all, I'm need a review of the last developement piece to JEP 246, the configuration changes. I've copied the build-dev in case there were any comments on the minor changes in the make directory related to the java.security file. http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ thanks Tony From sadhak001 at gmail.com Fri Oct 2 19:59:59 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 2 Oct 2015 20:59:59 +0100 Subject: Building Valhalla Message-ID: Hi guys, I get the below build error half way through build the valhalla build of OpenJDK: *ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error 1gmake[3]: Leaving directory `'>gmake[2]: *** [verify-modules] Error 1gmake[2]: Leaving directory `'>make[1]: *** [main] Error 1make[1]: Leaving directory `'>make: *** [images] Error 2Build step 'Execute shell' marked build as failureArchiving artifacts* Here's the link to the detailed logs - https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull Whats the fix to the verify modules issue ? Any flags that would help ? There are a number of errors like "inaccessible reference: valhalla.model3.Model3Converter (java.base) -> com.sun.tools.classfile.AccessFlags (jdk.compiler)". For your info, I'm building from the http://hg.openjdk.java.net/valhalla/valhalla/ repo. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From maurizio.cimadamore at oracle.com Fri Oct 2 20:36:10 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 2 Oct 2015 21:36:10 +0100 Subject: Building Valhalla In-Reply-To: References: Message-ID: <560EEABA.7030804@oracle.com> I believe this has been caused by the latest push... try doing: make jimages afaik that should not run the last verification step ;-) Maurizio On 02/10/15 20:59, Mani Sarkar wrote: > Hi guys, > > I get the below build error half way through build the valhalla build of > OpenJDK: > > > > > > > > > > > *ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error > 1gmake[3]: Leaving directory > ` '>gmake[2]: > *** [verify-modules] Error 1gmake[2]: Leaving directory > ` '>make[1]: > *** [main] Error 1make[1]: Leaving directory > ` '>make: > *** [images] Error 2Build step 'Execute shell' marked build as > failureArchiving artifacts* > > Here's the link to the detailed logs - > https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull > > Whats the fix to the verify modules issue ? Any flags that would help ? > There are a number of errors like "inaccessible reference: > valhalla.model3.Model3Converter (java.base) -> > com.sun.tools.classfile.AccessFlags (jdk.compiler)". > > For your info, I'm building from the > http://hg.openjdk.java.net/valhalla/valhalla/ > repo. > > Cheers, > Mani > From sadhak001 at gmail.com Fri Oct 2 20:44:23 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 2 Oct 2015 21:44:23 +0100 Subject: Building Valhalla In-Reply-To: <560EEABA.7030804@oracle.com> References: <560EEABA.7030804@oracle.com> Message-ID: Maurizio, Thanks for the suggestion - would it build the much useful JRE and JDK images ? Cheers, Mani On Fri, Oct 2, 2015 at 9:36 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I believe this has been caused by the latest push... > > try doing: > > make jimages > > afaik that should not run the last verification step ;-) > > Maurizio > > On 02/10/15 20:59, Mani Sarkar wrote: > >> Hi guys, >> >> I get the below build error half way through build the valhalla build of >> OpenJDK: >> >> >> >> >> >> >> >> >> >> >> *ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error >> 1gmake[3]: Leaving directory >> `< >> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make >> < >> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make >> >'>gmake[2]: >> *** [verify-modules] Error 1gmake[2]: Leaving directory >> `< >> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >> < >> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >> >'>make[1]: >> *** [main] Error 1make[1]: Leaving directory >> `< >> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >> < >> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >> >'>make: >> *** [images] Error 2Build step 'Execute shell' marked build as >> failureArchiving artifacts* >> >> Here's the link to the detailed logs - >> >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull >> >> Whats the fix to the verify modules issue ? Any flags that would help ? >> There are a number of errors like "inaccessible reference: >> valhalla.model3.Model3Converter (java.base) -> >> com.sun.tools.classfile.AccessFlags (jdk.compiler)". >> >> For your info, I'm building from the >> http://hg.openjdk.java.net/valhalla/valhalla/ >> repo. >> >> Cheers, >> Mani >> >> > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From tim.bell at oracle.com Sat Oct 3 23:09:14 2015 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 03 Oct 2015 16:09:14 -0700 Subject: RFR: JDK-8138739: Enable devkit on macosx in JPRT (again) In-Reply-To: <560E3CB7.7090604@oracle.com> References: <560E3CB7.7090604@oracle.com> Message-ID: <5610601A.6030207@oracle.com> Erik: Looks good. Tim > Please review this minor fix to the jprt configuration, which again > enables the use of devkits for macosx. > > This will be pushed to jdk9/client as that's where the final fixes > needed for this are gathered. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138739 > Patch: > diff -r 1e64ec3d1c60 make/jprt.properties > --- a/make/jprt.properties > +++ b/make/jprt.properties > @@ -127,6 +127,8 @@ > ${jprt.i586.build.configure.args} > jprt.windows_x64.build.configure.args= \ > --with-devkit=$VS2013_HOME > +jprt.macosx_x64.build.configure.args= \ > + --with-devkit=$XCODE_511_HOME > > ######## > # > From tim.bell at oracle.com Sat Oct 3 23:18:50 2015 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 03 Oct 2015 16:18:50 -0700 Subject: RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed In-Reply-To: <560E87D1.9080906@oracle.com> References: <560E87D1.9080906@oracle.com> Message-ID: <5610625A.8050305@oracle.com> Erik: > While trying the macosx build using devkits again, I happened to be on > a system where some Xcode install/update error had left the > /usr/include directory missing. This shouldn't be an issue since we > have all the necessary include files in the SDK inside the > devkit/Xcode application. > > Getting this to work required several changes and cleanups that will > actually improve build consistency overall. It will also guarantee > that we use the correct system headers in all cases. > > * Setup SYSROOT_*FLAGS before detecting toolchain and make those flags > available to the configure toolchain tests. > * Setup the user supplied extra flags before toolchain detection so > that those are also used during configure toolchain tests. > * When not cross compiling, use the SYSROOT_*FLAGS also when compiling > build tools, like adlc in hotspot, and gensrc tools in jdk. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138694 > Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01 Looks good to me. /Tim From Alan.Bateman at oracle.com Sun Oct 4 08:58:39 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 4 Oct 2015 09:58:39 +0100 Subject: Building Valhalla In-Reply-To: <560EEABA.7030804@oracle.com> References: <560EEABA.7030804@oracle.com> Message-ID: <5610EA3F.3040906@oracle.com> On 02/10/2015 21:36, Maurizio Cimadamore wrote: > I believe this has been caused by the latest push... > > try doing: > > make jimages > > afaik that should not run the last verification step ;-) > > Maurizio Yeah, I'm sure the usages of the classfile API are just convenience at this point. I assume eventually the references in java.base to types in other modules will be eliminated because it just won't compile but that is for further down the road. -Alan From erik.joelsson at oracle.com Mon Oct 5 07:57:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 09:57:25 +0200 Subject: RFR 8133151: Preferred provider configuration for JCE In-Reply-To: <560EBA0A.7040808@oracle.com> References: <560EBA0A.7040808@oracle.com> Message-ID: <56122D65.4060607@oracle.com> Makefile change looks ok. /Erik On 2015-10-02 19:08, Anthony Scarpino wrote: > Hi all, > > I'm need a review of the last developement piece to JEP 246, the > configuration changes. > > I've copied the build-dev in case there were any comments on the minor > changes in the make directory related to the java.security file. > > http://cr.openjdk.java.net/~ascarpino/8133151/webrev/ > > thanks > > Tony From erik.joelsson at oracle.com Mon Oct 5 07:59:19 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 09:59:19 +0200 Subject: Building Valhalla In-Reply-To: References: <560EEABA.7030804@oracle.com> Message-ID: <56122DD7.3060604@oracle.com> Hello Mani, Yes, it will, but consider it a workaround that may change. /Erik On 2015-10-02 22:44, Mani Sarkar wrote: > Maurizio, > > Thanks for the suggestion - would it build the much useful JRE and JDK > images ? > > Cheers, > Mani > > On Fri, Oct 2, 2015 at 9:36 PM, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> I believe this has been caused by the latest push... >> >> try doing: >> >> make jimages >> >> afaik that should not run the last verification step ;-) >> >> Maurizio >> >> On 02/10/15 20:59, Mani Sarkar wrote: >> >>> Hi guys, >>> >>> I get the below build error half way through build the valhalla build of >>> OpenJDK: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error >>> 1gmake[3]: Leaving directory >>> `< >>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make >>> < >>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make >>>> '>gmake[2]: >>> *** [verify-modules] Error 1gmake[2]: Leaving directory >>> `< >>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>> < >>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>>> '>make[1]: >>> *** [main] Error 1make[1]: Leaving directory >>> `< >>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>> < >>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>>> '>make: >>> *** [images] Error 2Build step 'Execute shell' marked build as >>> failureArchiving artifacts* >>> >>> Here's the link to the detailed logs - >>> >>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull >>> >>> Whats the fix to the verify modules issue ? Any flags that would help ? >>> There are a number of errors like "inaccessible reference: >>> valhalla.model3.Model3Converter (java.base) -> >>> com.sun.tools.classfile.AccessFlags (jdk.compiler)". >>> >>> For your info, I'm building from the >>> http://hg.openjdk.java.net/valhalla/valhalla/ >>> repo. >>> >>> Cheers, >>> Mani >>> >>> > From magnus.ihse.bursie at oracle.com Mon Oct 5 09:21:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Oct 2015 11:21:28 +0200 Subject: RFR: JDK-8138864 Build with nice to lower UI impact Message-ID: <56124118.1010803@oracle.com> Since building the OpenJDK is a heavy operation, the build system tries to make use as of much of the system resources as possible and reasonable. However, on most machines except extremely high-end, this means that few resources are available for other processes. On a developer machine, building means that other work can get laggy and have poor response times. There is a simple remedy for this! Using "nice" to lower the priority for the build process, so the build will wait for normal UI processes. A single "nice" when handling the parallel targets in Init.gmk is sufficient. A potential problem could be if this affects performance on dedicated build servers. I have checked this on Oracle's internal build system, and there were no measurable regressions. This also stands to reason, since if there would be, the build server would be running other processes competing with the build. On a correctly setup build server, this should not be the case. And if such processes existed, it would be bad anyway. Bug: https://bugs.openjdk.java.net/browse/JDK-8138864 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Oct 5 09:31:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 11:31:40 +0200 Subject: RFR: JDK-8138864 Build with nice to lower UI impact In-Reply-To: <56124118.1010803@oracle.com> References: <56124118.1010803@oracle.com> Message-ID: <5612437C.3030307@oracle.com> Looks ok to me, but I suspect someone will be asking for an explicit way of disabling this soon. /Erik On 2015-10-05 11:21, Magnus Ihse Bursie wrote: > Since building the OpenJDK is a heavy operation, the build system > tries to make use as of much of the system resources as possible and > reasonable. > > However, on most machines except extremely high-end, this means that > few resources are available for other processes. On a developer > machine, building means that other work can get laggy and have poor > response times. > > There is a simple remedy for this! Using "nice" to lower the priority > for the build process, so the build will wait for normal UI processes. > A single "nice" when handling the parallel targets in Init.gmk is > sufficient. > > A potential problem could be if this affects performance on dedicated > build servers. I have checked this on Oracle's internal build system, > and there were no measurable regressions. This also stands to reason, > since if there would be, the build server would be running other > processes competing with the build. On a correctly setup build server, > this should not be the case. And if such processes existed, it would > be bad anyway. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138864 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Mon Oct 5 09:38:09 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 11:38:09 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560D3218.5070205@oracle.com> References: <560BD900.9000308@oracle.com> <560D3218.5070205@oracle.com> Message-ID: <56124501.5090702@oracle.com> Another friendly bump for an 8u (R)eviewer for this. /Erik On 2015-10-01 15:16, Erik Joelsson wrote: > Still looking for an official review from 8u reviewer for this. > Ideally someone from Hotspot. > > /Erik > > On 2015-09-30 14:43, Erik Joelsson wrote: >> Hello, >> >> Please approve and review this fix for 8u. >> >> My last fix for this issue, JDK-8136691, was not enough. I made a >> mistake while verifying the fix and the problem is still there. >> >> There are more discrepancies between Solaris and the other platform >> makefiles. The excludeSrc.gmk file is not included anywhere when >> building on Solaris. The variable Src_Files_EXCLUDE is overwritten in >> vm.make instead of appended to, so even when including >> excludeSrc.gmk, it wasn't enough. The other platform specific >> buildtree.make files also set INCLUDE_TRACE in the generated makefile. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >> >> /Erik > From erik.joelsson at oracle.com Mon Oct 5 09:50:38 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 11:50:38 +0200 Subject: RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed In-Reply-To: <560E9F6D.9030601@oracle.com> References: <560E87D1.9080906@oracle.com> <560E9F6D.9030601@oracle.com> Message-ID: <561247EE.9040006@oracle.com> Here is a new webrev where I cleaned up the macosx sysroot flags logic: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.02/ /Erik On 2015-10-02 17:14, Magnus Ihse Bursie wrote: > On 2015-10-02 15:34, Erik Joelsson wrote: >> Hello, >> >> While trying the macosx build using devkits again, I happened to be >> on a system where some Xcode install/update error had left the >> /usr/include directory missing. This shouldn't be an issue since we >> have all the necessary include files in the SDK inside the >> devkit/Xcode application. >> >> Getting this to work required several changes and cleanups that will >> actually improve build consistency overall. It will also guarantee >> that we use the correct system headers in all cases. >> >> * Setup SYSROOT_*FLAGS before detecting toolchain and make those >> flags available to the configure toolchain tests. >> * Setup the user supplied extra flags before toolchain detection so >> that those are also used during configure toolchain tests. >> * When not cross compiling, use the SYSROOT_*FLAGS also when >> compiling build tools, like adlc in hotspot, and gensrc tools in jdk. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138694 >> Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01/ > > Your changes looks good. However, I notice that there is a problem > with the code that you moved. In FLAGS_SETUP_SYSROOT_FLAGS, there is a > test: > > elif test "x$OPENJDK_TARGET_OS" = xmacosx; then > # Apple only wants -isysroot , but we also need > -iframework/System/Library/Frameworks > SYSROOT_CFLAGS="-isysroot $SYSROOT -iframework > $SYSROOT/System/Library/Frameworks" > SYSROOT_LDFLAGS=$SYSROOT_CFLAGS > > but this is incorrect. Remove this and instead add the -iframework > stuff at the end. There is already a macosx test for adding framework > flags, the -iframework addition fits in perfect there. > > /Magnus From magnus.ihse.bursie at oracle.com Mon Oct 5 11:17:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Oct 2015 13:17:28 +0200 Subject: RFR: JDK-8138864 Build with nice to lower UI impact In-Reply-To: <5612437C.3030307@oracle.com> References: <56124118.1010803@oracle.com> <5612437C.3030307@oracle.com> Message-ID: <56125C48.5070509@oracle.com> On 2015-10-05 11:31, Erik Joelsson wrote: > Looks ok to me, but I suspect someone will be asking for an explicit > way of disabling this soon. I was just about to reply "just use configure NICE=", but then I had to go and check that it worked. It didn't. So, here's an updated patch that allow you to override a configure located executable (such as nice) with an empty value. The changes are in basics.4m. http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.02 With this additional fix, you can use "configure NICE=" to disable the use of nice. /Magnus > > /Erik > > On 2015-10-05 11:21, Magnus Ihse Bursie wrote: >> Since building the OpenJDK is a heavy operation, the build system >> tries to make use as of much of the system resources as possible and >> reasonable. >> >> However, on most machines except extremely high-end, this means that >> few resources are available for other processes. On a developer >> machine, building means that other work can get laggy and have poor >> response times. >> >> There is a simple remedy for this! Using "nice" to lower the priority >> for the build process, so the build will wait for normal UI >> processes. A single "nice" when handling the parallel targets in >> Init.gmk is sufficient. >> >> A potential problem could be if this affects performance on dedicated >> build servers. I have checked this on Oracle's internal build system, >> and there were no measurable regressions. This also stands to reason, >> since if there would be, the build server would be running other >> processes competing with the build. On a correctly setup build >> server, this should not be the case. And if such processes existed, >> it would be bad anyway. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138864 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Oct 5 11:18:24 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Oct 2015 13:18:24 +0200 Subject: RFR: JDK-8138694: Devkit build on Macosx still requires Xcode to be installed In-Reply-To: <561247EE.9040006@oracle.com> References: <560E87D1.9080906@oracle.com> <560E9F6D.9030601@oracle.com> <561247EE.9040006@oracle.com> Message-ID: <56125C80.6070507@oracle.com> On 2015-10-05 11:50, Erik Joelsson wrote: > Here is a new webrev where I cleaned up the macosx sysroot flags logic: > > http://cr.openjdk.java.net/~erikj/8138694/webrev.top.02/ Great, thanks! Looks good now. /Magnus > > /Erik > > On 2015-10-02 17:14, Magnus Ihse Bursie wrote: >> On 2015-10-02 15:34, Erik Joelsson wrote: >>> Hello, >>> >>> While trying the macosx build using devkits again, I happened to be >>> on a system where some Xcode install/update error had left the >>> /usr/include directory missing. This shouldn't be an issue since we >>> have all the necessary include files in the SDK inside the >>> devkit/Xcode application. >>> >>> Getting this to work required several changes and cleanups that will >>> actually improve build consistency overall. It will also guarantee >>> that we use the correct system headers in all cases. >>> >>> * Setup SYSROOT_*FLAGS before detecting toolchain and make those >>> flags available to the configure toolchain tests. >>> * Setup the user supplied extra flags before toolchain detection so >>> that those are also used during configure toolchain tests. >>> * When not cross compiling, use the SYSROOT_*FLAGS also when >>> compiling build tools, like adlc in hotspot, and gensrc tools in jdk. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138694 >>> Webrev: http://cr.openjdk.java.net/~erikj/8138694/webrev.top.01/ >> >> Your changes looks good. However, I notice that there is a problem >> with the code that you moved. In FLAGS_SETUP_SYSROOT_FLAGS, there is >> a test: >> >> elif test "x$OPENJDK_TARGET_OS" = xmacosx; then >> # Apple only wants -isysroot , but we also need >> -iframework/System/Library/Frameworks >> SYSROOT_CFLAGS="-isysroot $SYSROOT -iframework >> $SYSROOT/System/Library/Frameworks" >> SYSROOT_LDFLAGS=$SYSROOT_CFLAGS >> >> but this is incorrect. Remove this and instead add the -iframework >> stuff at the end. There is already a macosx test for adding framework >> flags, the -iframework addition fits in perfect there. >> >> /Magnus > From erik.joelsson at oracle.com Mon Oct 5 11:22:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 5 Oct 2015 13:22:41 +0200 Subject: RFR: JDK-8138864 Build with nice to lower UI impact In-Reply-To: <56125C48.5070509@oracle.com> References: <56124118.1010803@oracle.com> <5612437C.3030307@oracle.com> <56125C48.5070509@oracle.com> Message-ID: <56125D81.70006@oracle.com> By at least making sure that works, I'm happy with this for now. /Erik On 2015-10-05 13:17, Magnus Ihse Bursie wrote: > On 2015-10-05 11:31, Erik Joelsson wrote: >> Looks ok to me, but I suspect someone will be asking for an explicit >> way of disabling this soon. > I was just about to reply "just use configure NICE=", but then I had > to go and check that it worked. It didn't. So, here's an updated patch > that allow you to override a configure located executable (such as > nice) with an empty value. The changes are in basics.4m. > > http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.02 > > With this additional fix, you can use "configure NICE=" to disable the > use of nice. > > /Magnus > >> >> /Erik >> >> On 2015-10-05 11:21, Magnus Ihse Bursie wrote: >>> Since building the OpenJDK is a heavy operation, the build system >>> tries to make use as of much of the system resources as possible and >>> reasonable. >>> >>> However, on most machines except extremely high-end, this means that >>> few resources are available for other processes. On a developer >>> machine, building means that other work can get laggy and have poor >>> response times. >>> >>> There is a simple remedy for this! Using "nice" to lower the >>> priority for the build process, so the build will wait for normal UI >>> processes. A single "nice" when handling the parallel targets in >>> Init.gmk is sufficient. >>> >>> A potential problem could be if this affects performance on >>> dedicated build servers. I have checked this on Oracle's internal >>> build system, and there were no measurable regressions. This also >>> stands to reason, since if there would be, the build server would be >>> running other processes competing with the build. On a correctly >>> setup build server, this should not be the case. And if such >>> processes existed, it would be bad anyway. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138864 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.01 >>> >>> /Magnus >>> >> > From sbaiduzh at redhat.com Mon Oct 5 11:28:38 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Mon, 5 Oct 2015 13:28:38 +0200 Subject: RFR: JDK-8138864 Build with nice to lower UI impact In-Reply-To: <56124118.1010803@oracle.com> References: <56124118.1010803@oracle.com> Message-ID: <56125EE6.2080403@redhat.com> On 05/10/15 11:21, Magnus Ihse Bursie wrote: > Since building the OpenJDK is a heavy operation, the build system tries > to make use as of much of the system resources as possible and reasonable. > > However, on most machines except extremely high-end, this means that few > resources are available for other processes. On a developer machine, > building means that other work can get laggy and have poor response times. > > There is a simple remedy for this! Using "nice" to lower the priority > for the build process, so the build will wait for normal UI processes. A > single "nice" when handling the parallel targets in Init.gmk is sufficient. > > A potential problem could be if this affects performance on dedicated > build servers. I have checked this on Oracle's internal build system, > and there were no measurable regressions. This also stands to reason, > since if there would be, the build server would be running other > processes competing with the build. On a correctly setup build server, > this should not be the case. And if such processes existed, it would be > bad anyway. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138864 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.01 But why not just add some recommendations to the readme file to building section? For example, on my system I have crazy powerful CPU but HDD is the bottleneck, so for me the most useful command will be: ionice -n 7 -c 3 make images And to achieve absolutely no impact on the system: nice -n 19 chrt -b 0 ionice -n 7 -c 3 make images -- Regards, Stas From magnus.ihse.bursie at oracle.com Mon Oct 5 12:39:45 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 5 Oct 2015 14:39:45 +0200 Subject: RFR: JDK-8138864 Build with nice to lower UI impact In-Reply-To: <56125EE6.2080403@redhat.com> References: <56124118.1010803@oracle.com> <56125EE6.2080403@redhat.com> Message-ID: <56126F91.60501@oracle.com> On 2015-10-05 13:28, Stanislav Baiduzhyi wrote: > On 05/10/15 11:21, Magnus Ihse Bursie wrote: >> Since building the OpenJDK is a heavy operation, the build system tries >> to make use as of much of the system resources as possible and >> reasonable. >> >> However, on most machines except extremely high-end, this means that few >> resources are available for other processes. On a developer machine, >> building means that other work can get laggy and have poor response >> times. >> >> There is a simple remedy for this! Using "nice" to lower the priority >> for the build process, so the build will wait for normal UI processes. A >> single "nice" when handling the parallel targets in Init.gmk is >> sufficient. >> >> A potential problem could be if this affects performance on dedicated >> build servers. I have checked this on Oracle's internal build system, >> and there were no measurable regressions. This also stands to reason, >> since if there would be, the build server would be running other >> processes competing with the build. On a correctly setup build server, >> this should not be the case. And if such processes existed, it would be >> bad anyway. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8138864 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8138864-make-nice-priority/webrev.01 >> > > But why not just add some recommendations to the readme file to > building section? For example, on my system I have crazy powerful CPU > but HDD is the bottleneck, so for me the most useful command will be: > > ionice -n 7 -c 3 make images > > And to achieve absolutely no impact on the system: > > nice -n 19 chrt -b 0 ionice -n 7 -c 3 make images > Trimming the build system for optimal performance on a specific piece of hardware is a story on it's own. We want to provide suitable defaults that are likely to at least work OK and at least not work really bad on all systems and for all users. I think it would be nice to have some collected documentation on how to tweak build performance, and if we had, your advice would fit right in there. Unfortunately, the documentation is as always underprioritized. :-( /Magnus From sadhak001 at gmail.com Mon Oct 5 20:04:50 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 5 Oct 2015 21:04:50 +0100 Subject: Building Valhalla In-Reply-To: <56122DD7.3060604@oracle.com> References: <560EEABA.7030804@oracle.com> <56122DD7.3060604@oracle.com> Message-ID: Thanks guys I'll be happy to change it back when its rectified on your end. Cheers, Mani On Mon, Oct 5, 2015 at 8:59 AM, Erik Joelsson wrote: > Hello Mani, > > Yes, it will, but consider it a workaround that may change. > > /Erik > > > On 2015-10-02 22:44, Mani Sarkar wrote: > >> Maurizio, >> >> Thanks for the suggestion - would it build the much useful JRE and JDK >> images ? >> >> Cheers, >> Mani >> >> On Fri, Oct 2, 2015 at 9:36 PM, Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >> I believe this has been caused by the latest push... >>> >>> try doing: >>> >>> make jimages >>> >>> afaik that should not run the last verification step ;-) >>> >>> Maurizio >>> >>> On 02/10/15 20:59, Mani Sarkar wrote: >>> >>> Hi guys, >>>> >>>> I get the below build error half way through build the valhalla build of >>>> OpenJDK: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> *ERROR: Failed module access verificationgmake[3]: *** [checkdeps] Error >>>> 1gmake[3]: Leaving directory >>>> `< >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make >>>> < >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla/make >>>> >>>>> '>gmake[2]: >>>>> >>>> *** [verify-modules] Error 1gmake[2]: Leaving directory >>>> `< >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>>> < >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>>> >>>>> '>make[1]: >>>>> >>>> *** [main] Error 1make[1]: Leaving directory >>>> `< >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>>> < >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/job/project-valhalla-OpenJDK/ws/valhalla >>>> >>>>> '>make: >>>>> >>>> *** [images] Error 2Build step 'Execute shell' marked build as >>>> failureArchiving artifacts* >>>> >>>> Here's the link to the detailed logs - >>>> >>>> >>>> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/project-valhalla-OpenJDK/3/consoleFull >>>> >>>> Whats the fix to the verify modules issue ? Any flags that would help ? >>>> There are a number of errors like "inaccessible reference: >>>> valhalla.model3.Model3Converter (java.base) -> >>>> com.sun.tools.classfile.AccessFlags (jdk.compiler)". >>>> >>>> For your info, I'm building from the >>>> http://hg.openjdk.java.net/valhalla/valhalla/ >>>> repo. >>>> >>>> Cheers, >>>> Mani >>>> >>>> >>>> >> > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From james.laskey at oracle.com Tue Oct 6 12:30:48 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 6 Oct 2015 09:30:48 -0300 Subject: CLANG special case Message-ID: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. Cheers, ? Jim diff -r a02911828e48 make/bsd/makefiles/gcc.make --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 @@ -313,21 +313,13 @@ # Work around some compiler bugs. ifeq ($(USE_CLANG), true) - # Clang <= 6.1 - ifeq ($(shell expr \ - $(CC_VER_MAJOR) \< 6 \| \ - \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) \ - ), 1) - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) - OPT_CFLAGS/unsafe.o += -O1 - else - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") - endif + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) + OPT_CFLAGS/unsafe.o += -O1 else # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) - endif + endif endif # Flags for generating make dependency flags. From bengt.rutisson at oracle.com Tue Oct 6 10:01:29 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Tue, 06 Oct 2015 12:01:29 +0200 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <56124501.5090702@oracle.com> References: <560BD900.9000308@oracle.com> <560D3218.5070205@oracle.com> <56124501.5090702@oracle.com> Message-ID: <56139BF9.4030902@oracle.com> Hi Erik, On 2015-10-05 11:38, Erik Joelsson wrote: > Another friendly bump for an 8u (R)eviewer for this. Rubber stamped. (Thanks for walking me through the patch, Erik!) Bengt > > /Erik > > On 2015-10-01 15:16, Erik Joelsson wrote: >> Still looking for an official review from 8u reviewer for this. >> Ideally someone from Hotspot. >> >> /Erik >> >> On 2015-09-30 14:43, Erik Joelsson wrote: >>> Hello, >>> >>> Please approve and review this fix for 8u. >>> >>> My last fix for this issue, JDK-8136691, was not enough. I made a >>> mistake while verifying the fix and the problem is still there. >>> >>> There are more discrepancies between Solaris and the other platform >>> makefiles. The excludeSrc.gmk file is not included anywhere when >>> building on Solaris. The variable Src_Files_EXCLUDE is overwritten >>> in vm.make instead of appended to, so even when including >>> excludeSrc.gmk, it wasn't enough. The other platform specific >>> buildtree.make files also set INCLUDE_TRACE in the generated makefile. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 >>> Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ >>> >>> /Erik >> > From daniel.daugherty at oracle.com Tue Oct 6 14:38:31 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 6 Oct 2015 08:38:31 -0600 Subject: [8u] Request for Approval and Review: JDK-8136980: build for 8u65 and 8u66 for solaris platforms is failing In-Reply-To: <560BD900.9000308@oracle.com> References: <560BD900.9000308@oracle.com> Message-ID: <5613DCE7.1080706@oracle.com> Sorry for missing this review request. I'm still learning to deal with my new e-mail filters (restored from memory after losing my MacBook Pro env). On 9/30/15 6:43 AM, Erik Joelsson wrote: > Hello, > > Please approve and review this fix for 8u. > > My last fix for this issue, JDK-8136691, was not enough. I made a > mistake while verifying the fix and the problem is still there. > > There are more discrepancies between Solaris and the other platform > makefiles. The excludeSrc.gmk file is not included anywhere when > building on Solaris. The variable Src_Files_EXCLUDE is overwritten in > vm.make instead of appended to, so even when including excludeSrc.gmk, > it wasn't enough. The other platform specific buildtree.make files > also set INCLUDE_TRACE in the generated makefile. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8136980 > Webrev: http://cr.openjdk.java.net/~erikj/8136980/webrev.hotspot.01/ make/solaris/makefiles/buildtree.make No comments. make/solaris/makefiles/vm.make No comments. Thumbs up. Dan > > /Erik > From philip.race at oracle.com Tue Oct 6 15:38:24 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 06 Oct 2015 08:38:24 -0700 Subject: CLANG special case In-Reply-To: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> Message-ID: <5613EAF0.6000102@oracle.com> Ideally hotspot would review this, not build. so it would be helpful if hotspot found an engineer to own the bug :- https://bugs.openjdk.java.net/browse/JDK-8138820 So far as I know this is not tracked under any other bug id. -phil. On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: > I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. > > Cheers, > > ? Jim > > > > diff -r a02911828e48 make/bsd/makefiles/gcc.make > --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 > +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 > @@ -313,21 +313,13 @@ > > # Work around some compiler bugs. > ifeq ($(USE_CLANG), true) > - # Clang <= 6.1 > - ifeq ($(shell expr \ > - $(CC_VER_MAJOR) \< 6 \| \ > - \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) \ > - ), 1) > - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > - OPT_CFLAGS/unsafe.o += -O1 > - else > - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") > - endif > + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) > + OPT_CFLAGS/unsafe.o += -O1 > else > # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. > ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) > OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) > - endif > + endif > endif > > # Flags for generating make dependency flags. > From staffan.larsen at oracle.com Tue Oct 6 19:17:46 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 6 Oct 2015 21:17:46 +0200 Subject: CLANG special case In-Reply-To: <5613EAF0.6000102@oracle.com> References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> <5613EAF0.6000102@oracle.com> Message-ID: When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. /Staffan > On 6 okt 2015, at 17:38, Phil Race wrote: > > Ideally hotspot would review this, not build. > so it would be helpful if hotspot found an engineer to own the bug :- > https://bugs.openjdk.java.net/browse/JDK-8138820 > So far as I know this is not tracked under any other bug id. > > -phil. > > On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. >> >> Cheers, >> >> ? Jim >> >> >> >> diff -r a02911828e48 make/bsd/makefiles/gcc.make >> --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 >> +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 >> @@ -313,21 +313,13 @@ >> # Work around some compiler bugs. >> ifeq ($(USE_CLANG), true) >> - # Clang <= 6.1 >> - ifeq ($(shell expr \ >> - $(CC_VER_MAJOR) \< 6 \| \ >> - \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) \ >> - ), 1) >> - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> - OPT_CFLAGS/unsafe.o += -O1 >> - else >> - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >> - endif >> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >> + OPT_CFLAGS/unsafe.o += -O1 >> else >> # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. >> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) >> OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) >> - endif >> + endif >> endif >> # Flags for generating make dependency flags. >> > From james.laskey at oracle.com Tue Oct 6 19:23:26 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 6 Oct 2015 16:23:26 -0300 Subject: CLANG special case In-Reply-To: References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> <5613EAF0.6000102@oracle.com> Message-ID: Since we are will to live with the de-optimization now, we should just remove the condition until proven otherwise. > On Oct 6, 2015, at 4:17 PM, Staffan Larsen wrote: > > When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. > > /Staffan > >> On 6 okt 2015, at 17:38, Phil Race > wrote: >> >> Ideally hotspot would review this, not build. >> so it would be helpful if hotspot found an engineer to own the bug :- >> https://bugs.openjdk.java.net/browse/JDK-8138820 >> So far as I know this is not tracked under any other bug id. >> >> -phil. >> >> On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >>> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. >>> >>> Cheers, >>> >>> ? Jim >>> >>> >>> >>> diff -r a02911828e48 make/bsd/makefiles/gcc.make >>> --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 >>> +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 >>> @@ -313,21 +313,13 @@ >>> # Work around some compiler bugs. >>> ifeq ($(USE_CLANG), true) >>> - # Clang <= 6.1 >>> - ifeq ($(shell expr \ >>> - $(CC_VER_MAJOR) \< 6 \| \ >>> - \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) \ >>> - ), 1) >>> - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>> - OPT_CFLAGS/unsafe.o += -O1 >>> - else >>> - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >>> - endif >>> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>> + OPT_CFLAGS/unsafe.o += -O1 >>> else >>> # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. >>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) >>> OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) >>> - endif >>> + endif >>> endif >>> # Flags for generating make dependency flags. >>> >> > From athenasjim at gmail.com Tue Oct 6 23:19:40 2015 From: athenasjim at gmail.com (Athenas Jimenez) Date: Tue, 6 Oct 2015 18:19:40 -0500 Subject: recipe for target 'hotspot' failed Message-ID: Hello, I have some problems with my openJDK building. I started looking in the internet and I found some similar issues, but the fixes didn't help. Could someone provide me some help? Here is my log: http://pastebin.com/H4GpLZth Thanks in advance. From erik.joelsson at oracle.com Wed Oct 7 07:44:43 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Oct 2015 09:44:43 +0200 Subject: recipe for target 'hotspot' failed In-Reply-To: References: Message-ID: <5614CD6B.3080008@oracle.com> Hello, Hotspot is built with warnings treated as errors turned on by default. It seems your compiler is finding warnings that ours do not. To work around it you can run set WARNINGS_ARE_ERRORS= on the command line to make. What compiler and version are you using? /Erik On 2015-10-07 01:19, Athenas Jimenez wrote: > Hello, > > I have some problems with my openJDK building. I started looking in the > internet and I found some similar issues, but the fixes didn't help. > > Could someone provide me some help? > > Here is my log: http://pastebin.com/H4GpLZth > > Thanks in advance. From erik.joelsson at oracle.com Wed Oct 7 09:59:28 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 7 Oct 2015 11:59:28 +0200 Subject: RFR: JDK-8138761 Improved handling of libffi, and cleanup of libraries.m4 In-Reply-To: <560E9BB1.5080403@oracle.com> References: <560E9BB1.5080403@oracle.com> Message-ID: <5614ED00.5010606@oracle.com> Looks good to me. /Erik On 2015-10-02 16:58, Magnus Ihse Bursie wrote: > To build zero, we need libffi. However, the code in configure to > handle libffi is not up to normal library handling standards, so it is > not possible to set it using configure arguments. > > When trying to rectify this, I finally got tired of the mess that > libraries.m4 is. I have split it into parts, where each prominent > library gets it's own file, and I've switched the logic on > dependencies to be positive (i.e. linux needs alsa, not "macosx does > NOT need alsa"). > > The cleanup includes: > * Split libraries.m4. > * Remove builddeps. > * Remove last references to pulse. > * Remove HAVE_ALTZONE. > * Separate handling of bundled libs. > * Set LIBM properly. > > The libffi support means that we now have > --with-libffi[-libs/-include], just like for other libraries. Also, we > sanity check that we can actually compile with libffi. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8138761 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8138761-libffi-and-libraries-cleanup/webrev.01 > > /Magnus From athenasjim at gmail.com Wed Oct 7 16:13:42 2015 From: athenasjim at gmail.com (Athenas Jimenez) Date: Wed, 7 Oct 2015 11:13:42 -0500 Subject: recipe for target 'hotspot' failed In-Reply-To: <5614CD6B.3080008@oracle.com> References: <5614CD6B.3080008@oracle.com> Message-ID: Hello Erik, I'm compiling with gcc 5.2.0. and my commands are: $ set WARNINGS_ARE_ERRORS= $ bash configure --x-includes=/usr/include/ --x-libraries=/usr/lib64 --with-freetype-lib=/usr/lib64 --with-freetype-include=/usr/include --with-target-bits=64 --disable-warnings-as-errors --enable-debug $ cd build/linux-x86_64-normal-server-fastdebug/ $ make all Sadly, setting WARNINGS_ARE_ERRORS didn't help :( On Wed, Oct 7, 2015 at 2:44 AM, Erik Joelsson wrote: > Hello, > > Hotspot is built with warnings treated as errors turned on by default. It > seems your compiler is finding warnings that ours do not. To work around it > you can run set WARNINGS_ARE_ERRORS= on the command line to make. > > What compiler and version are you using? > > /Erik > > > On 2015-10-07 01:19, Athenas Jimenez wrote: > >> Hello, >> >> I have some problems with my openJDK building. I started looking in the >> internet and I found some similar issues, but the fixes didn't help. >> >> Could someone provide me some help? >> >> Here is my log: http://pastebin.com/H4GpLZth >> >> Thanks in advance. >> > > From erik.joelsson at oracle.com Thu Oct 8 06:48:18 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 8 Oct 2015 08:48:18 +0200 Subject: recipe for target 'hotspot' failed In-Reply-To: References: <5614CD6B.3080008@oracle.com> Message-ID: <561611B2.3070406@oracle.com> You need to set it on the command line to make, otherwise it won't override the make variable. make all WARNINGS_ARE_ERRORS= I'm surprised you need to set all those configure flags. I would expect configure to figure out freetype and X on its own when the locations are that obvious. /Erik On 2015-10-07 18:13, Athenas Jimenez wrote: > Hello Erik, > > I'm compiling with gcc 5.2.0. and my commands are: > > $ set WARNINGS_ARE_ERRORS= > $ bash configure --x-includes=/usr/include/ --x-libraries=/usr/lib64 > --with-freetype-lib=/usr/lib64 --with-freetype-include=/usr/include > --with-target-bits=64 --disable-warnings-as-errors --enable-debug > $ cd build/linux-x86_64-normal-server-fastdebug/ > $ make all > > > Sadly, setting WARNINGS_ARE_ERRORS didn't help :( > > > > > On Wed, Oct 7, 2015 at 2:44 AM, Erik Joelsson > > wrote: > > Hello, > > Hotspot is built with warnings treated as errors turned on by > default. It seems your compiler is finding warnings that ours do > not. To work around it you can run set WARNINGS_ARE_ERRORS= on the > command line to make. > > What compiler and version are you using? > > /Erik > > > On 2015-10-07 01:19, Athenas Jimenez wrote: > > Hello, > > I have some problems with my openJDK building. I started > looking in the > internet and I found some similar issues, but the fixes didn't > help. > > Could someone provide me some help? > > Here is my log: http://pastebin.com/H4GpLZth > > Thanks in advance. > > > From christian.thalinger at oracle.com Thu Oct 8 19:58:43 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 8 Oct 2015 09:58:43 -1000 Subject: CLANG special case In-Reply-To: References: <5A5E3D06-3825-40C9-92BA-511C41ACFEF3@oracle.com> <5613EAF0.6000102@oracle.com> Message-ID: I?ve assigned the bug to me and will verify? > On Oct 6, 2015, at 9:23 AM, Jim Laskey (Oracle) wrote: > > Since we are will to live with the de-optimization now, we should just remove the condition until proven otherwise. > > >> On Oct 6, 2015, at 4:17 PM, Staffan Larsen wrote: >> >> When we upgraded to clang 6.3, I verified that the problem still existed. See: https://bugs.openjdk.java.net/browse/JDK-8077364 which has pointers to the two tests that fail without the workaround. >> >> /Staffan >> >>> On 6 okt 2015, at 17:38, Phil Race > wrote: >>> >>> Ideally hotspot would review this, not build. >>> so it would be helpful if hotspot found an engineer to own the bug :- >>> https://bugs.openjdk.java.net/browse/JDK-8138820 >>> So far as I know this is not tracked under any other bug id. >>> >>> -phil. >>> >>> On 10/06/2015 05:30 AM, Jim Laskey (Oracle) wrote: >>>> I?ve updated to El Capitan and, of course, builds fail, and, of course, I modify hotspot/make/bsd/makefiles/gcc.make one more time and? I think this conditional clause should be removed at the very least (commenting to indicate needs investigation), or someone should research and see which version of clang fixes the issues associate with the patch. Since it?s likely that no one has the cycles, please remove the condition. >>>> >>>> Cheers, >>>> >>>> ? Jim >>>> >>>> >>>> >>>> diff -r a02911828e48 make/bsd/makefiles/gcc.make >>>> --- a/make/bsd/makefiles/gcc.make Wed Sep 30 07:41:36 2015 -0700 >>>> +++ b/make/bsd/makefiles/gcc.make Tue Oct 06 09:22:50 2015 -0300 >>>> @@ -313,21 +313,13 @@ >>>> # Work around some compiler bugs. >>>> ifeq ($(USE_CLANG), true) >>>> - # Clang <= 6.1 >>>> - ifeq ($(shell expr \ >>>> - $(CC_VER_MAJOR) \< 6 \| \ >>>> - \( $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) \<= 1 \) \ >>>> - ), 1) >>>> - OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>>> - OPT_CFLAGS/unsafe.o += -O1 >>>> - else >>>> - $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)") >>>> - endif >>>> + OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) >>>> + OPT_CFLAGS/unsafe.o += -O1 >>>> else >>>> # 6835796. Problem in GCC 4.3.0 with mulnode.o optimized compilation. >>>> ifeq ($(shell expr $(CC_VER_MAJOR) = 4 \& $(CC_VER_MINOR) = 3), 1) >>>> OPT_CFLAGS/mulnode.o += $(OPT_CFLAGS/NOOPT) >>>> - endif >>>> + endif >>>> endif >>>> # Flags for generating make dependency flags. >>>> >>> >> > From erik.helin at oracle.com Fri Oct 9 08:35:26 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 10:35:26 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests Message-ID: <20151009083526.GT14241@ehelin.jrpg.bea.com> Hi all, this small patch add a new top-level Makefile target: test-hotspot-internal. The target is just an easier way to run the unit tests in hotspot (the ones you execute by using the flag -XX:+ExecuteInternalVMTests). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8139256 Webrev: - root: http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ - hotspot: http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ Thanks, Erik From erik.joelsson at oracle.com Fri Oct 9 09:39:39 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Oct 2015 11:39:39 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <20151009083526.GT14241@ehelin.jrpg.bea.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> Message-ID: <56178B5B.7030708@oracle.com> Looks good to me. /Erik On 2015-10-09 10:35, Erik Helin wrote: > Hi all, > > this small patch add a new top-level Makefile target: > test-hotspot-internal. The target is just an easier way to run the unit > tests in hotspot (the ones you execute by using the flag > -XX:+ExecuteInternalVMTests). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139256 > > Webrev: > - root: > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > - hotspot: > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ > > Thanks, > Erik From magnus.ihse.bursie at oracle.com Fri Oct 9 10:42:12 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Oct 2015 12:42:12 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <20151009083526.GT14241@ehelin.jrpg.bea.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> Message-ID: <56179A04.6090404@oracle.com> On 2015-10-09 10:35, Erik Helin wrote: > Hi all, > > this small patch add a new top-level Makefile target: > test-hotspot-internal. The target is just an easier way to run the unit > tests in hotspot (the ones you execute by using the flag > -XX:+ExecuteInternalVMTests). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139256 > > Webrev: > - root: > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > - hotspot: > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ Looks good to me. /Magnus From erik.helin at oracle.com Fri Oct 9 12:09:47 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:09:47 +0200 Subject: RFR: 8139272: Add configure variable to set concurrency for jtreg tests Message-ID: <20151009120947.GU14241@ehelin.jrpg.bea.com> Hi all, this patch adds a new configure variable: --with-test-jobs. The new variable configures how many tests jobs we run concurrently (aka the -concurrency flag to JTReg). Today --with-jobs is passed as the -concurrency flag to JTReg which most likely is too big for most systems with many cores. For hotspot, the only "supported" configuration for running the jtreg tests is with -concurrency:1. However, most machines will run the tests successfully with more concurrency, but I used a default of 1. For the JDK tests I kept --with-jobs as the default concurrency since I want to keep the old behaviour. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8139272 Webrev: http://cr.openjdk.java.net/~ehelin/8139272/webrev.00/ Thanks, Erik From erik.helin at oracle.com Fri Oct 9 12:23:44 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:23:44 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests Message-ID: <20151009122344.GV14241@ehelin.jrpg.bea.com> Hi all, this patch adds a new top-level Makefile to run the hotspot jtreg tests. This is already possible today by running: $ make test TEST="hotspot_all" The new target, test-hotspot-jtreg, is a bit more discoverable in my opinion (will also work with tab completion in supported shells). Enhancement: https://bugs.openjdk.java.net/browse/JDK-8139271 Webrev: http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ Thanks, Erik From erik.helin at oracle.com Fri Oct 9 12:27:32 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:27:32 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <56179A04.6090404@oracle.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> <56179A04.6090404@oracle.com> Message-ID: <20151009122732.GW14241@ehelin.jrpg.bea.com> On 2015-10-09, Magnus Ihse Bursie wrote: > On 2015-10-09 10:35, Erik Helin wrote: > >Hi all, > > > >this small patch add a new top-level Makefile target: > >test-hotspot-internal. The target is just an easier way to run the unit > >tests in hotspot (the ones you execute by using the flag > >-XX:+ExecuteInternalVMTests). > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8139256 > > > >Webrev: > >- root: > > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > >- hotspot: > > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ > > Looks good to me. Thanks! Erik > /Magnus From erik.helin at oracle.com Fri Oct 9 12:27:49 2015 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 9 Oct 2015 14:27:49 +0200 Subject: RFR: 8139256: Add Makefile target to run internal VM tests In-Reply-To: <56178B5B.7030708@oracle.com> References: <20151009083526.GT14241@ehelin.jrpg.bea.com> <56178B5B.7030708@oracle.com> Message-ID: <20151009122749.GX14241@ehelin.jrpg.bea.com> On 2015-10-09, Erik Joelsson wrote: > Looks good to me. Thanks! Erik > /Erik > > On 2015-10-09 10:35, Erik Helin wrote: > >Hi all, > > > >this small patch add a new top-level Makefile target: > >test-hotspot-internal. The target is just an easier way to run the unit > >tests in hotspot (the ones you execute by using the flag > >-XX:+ExecuteInternalVMTests). > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8139256 > > > >Webrev: > >- root: > > http://cr.openjdk.java.net/~ehelin/8139256/root/webrev.00/ > >- hotspot: > > http://cr.openjdk.java.net/~ehelin/8139256/hotspot/webrev.00/ > > > >Thanks, > >Erik > From erik.joelsson at oracle.com Fri Oct 9 12:56:05 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Oct 2015 14:56:05 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests In-Reply-To: <20151009122344.GV14241@ehelin.jrpg.bea.com> References: <20151009122344.GV14241@ehelin.jrpg.bea.com> Message-ID: <5617B965.7080805@oracle.com> Looks good to me. /Erik On 2015-10-09 14:23, Erik Helin wrote: > Hi all, > > this patch adds a new top-level Makefile to run the hotspot jtreg tests. > This is already possible today by running: > $ make test TEST="hotspot_all" > > The new target, test-hotspot-jtreg, is a bit more discoverable in my > opinion (will also work with tab completion in supported shells). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139271 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ > > Thanks, > Erik From magnus.ihse.bursie at oracle.com Fri Oct 9 17:56:23 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 9 Oct 2015 19:56:23 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests In-Reply-To: <20151009122344.GV14241@ehelin.jrpg.bea.com> References: <20151009122344.GV14241@ehelin.jrpg.bea.com> Message-ID: Looks good to me. /Magnus > 9 okt 2015 kl. 14:23 skrev Erik Helin : > > Hi all, > > this patch adds a new top-level Makefile to run the hotspot jtreg tests. > This is already possible today by running: > $ make test TEST="hotspot_all" > > The new target, test-hotspot-jtreg, is a bit more discoverable in my > opinion (will also work with tab completion in supported shells). > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139271 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ > > Thanks, > Erik From jan.lahoda at oracle.com Fri Oct 9 19:48:58 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 09 Oct 2015 21:48:58 +0200 Subject: RFR [9] 8134254: JShell API/tool: REPL for Java into JDK9 Message-ID: <56181A2A.5020207@oracle.com> Hi, I'd like to ask for a review of top-level and jdk repository changes needed for the JShell/REPL tool. The top-level repository changes: http://cr.openjdk.java.net/~rfield/jshell_base_webrev_v0/ The jdk repository changes: http://cr.openjdk.java.net/~rfield/jshell_jdk_webrev_v0/ Any feedback is welcome. Thanks! Jan From Alan.Bateman at oracle.com Fri Oct 9 20:02:17 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Oct 2015 21:02:17 +0100 Subject: RFR [9] 8134254: JShell API/tool: REPL for Java into JDK9 In-Reply-To: <56181A2A.5020207@oracle.com> References: <56181A2A.5020207@oracle.com> Message-ID: <56181D49.8000003@oracle.com> On 09/10/2015 20:48, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of top-level and jdk repository changes > needed for the JShell/REPL tool. > > The top-level repository changes: > http://cr.openjdk.java.net/~rfield/jshell_base_webrev_v0/ > > The jdk repository changes: > http://cr.openjdk.java.net/~rfield/jshell_jdk_webrev_v0/ > > Any feedback is welcome. Looks okay to me, just surprised to see the dependence on the preferences API. -Alan From jan.lahoda at oracle.com Fri Oct 9 20:13:12 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 09 Oct 2015 22:13:12 +0200 Subject: RFR [9] 8134254: JShell API/tool: REPL for Java into JDK9 In-Reply-To: <56181D49.8000003@oracle.com> References: <56181A2A.5020207@oracle.com> <56181D49.8000003@oracle.com> Message-ID: <56181FD8.10406@oracle.com> On 9.10.2015 22:02, Alan Bateman wrote: > On 09/10/2015 20:48, Jan Lahoda wrote: >> Hi, >> >> I'd like to ask for a review of top-level and jdk repository changes >> needed for the JShell/REPL tool. >> >> The top-level repository changes: >> http://cr.openjdk.java.net/~rfield/jshell_base_webrev_v0/ >> >> The jdk repository changes: >> http://cr.openjdk.java.net/~rfield/jshell_jdk_webrev_v0/ >> >> Any feedback is welcome. > Looks okay to me, just surprised to see the dependence on the > preferences API. The reason for that dependency is that the JShell tool currently stores the startup script/code (the code that is processed when the tool starts) and the editing history using java.util.prefs.Preferences. Thanks! Jan > > -Alan From erik.joelsson at oracle.com Mon Oct 12 08:30:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Oct 2015 10:30:21 +0200 Subject: RFR [9] 8134254: JShell API/tool: REPL for Java into JDK9 In-Reply-To: <56181A2A.5020207@oracle.com> References: <56181A2A.5020207@oracle.com> Message-ID: <561B6F9D.8090602@oracle.com> Looks good to me. /Erik On 2015-10-09 21:48, Jan Lahoda wrote: > Hi, > > I'd like to ask for a review of top-level and jdk repository changes > needed for the JShell/REPL tool. > > The top-level repository changes: > http://cr.openjdk.java.net/~rfield/jshell_base_webrev_v0/ > > The jdk repository changes: > http://cr.openjdk.java.net/~rfield/jshell_jdk_webrev_v0/ > > Any feedback is welcome. > > Thanks! > > Jan From magnus.ihse.bursie at oracle.com Mon Oct 12 08:45:24 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 12 Oct 2015 10:45:24 +0200 Subject: RFR: JDK-8139413 Use --with-x to set X11 root directory Message-ID: <561B7324.3030900@oracle.com> Similarly to the other libraries, we should use --with-x as a convenience argument so set the root of the X11 directory, and assume that includes and libraries are found in "include" and "lib" respectively, in this directory. Bug: https://bugs.openjdk.java.net/browse/JDK-8139413 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8139413-use-with-x-to-set-X11-root/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Oct 12 08:52:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Oct 2015 10:52:25 +0200 Subject: RFR: JDK-8139413 Use --with-x to set X11 root directory In-Reply-To: <561B7324.3030900@oracle.com> References: <561B7324.3030900@oracle.com> Message-ID: <561B74C9.7060408@oracle.com> Looks good to me. /Erik On 2015-10-12 10:45, Magnus Ihse Bursie wrote: > Similarly to the other libraries, we should use --with-x as a > convenience argument so set the root of the X11 directory, and assume > that includes and libraries are found in "include" and "lib" > respectively, in this directory. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139413 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8139413-use-with-x-to-set-X11-root/webrev.01 > > /Magnus From matthias.baesken at sap.com Mon Oct 12 14:34:06 2015 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 12 Oct 2015 14:34:06 +0000 Subject: sysroot-like setups on Solaris Message-ID: <98C2119538350A4E92B3DD08E7B4146801A8C1C5A0@DEWDFEMB14B.global.corp.sap> Hello all, in OpenJDK9 there is some support for building using a sysroot-like environment . For instance see common/autoconf/flags.m4 # Solaris Studio does not have a concept of sysroot. Instead we must # make sure the default include and lib dirs are appended to each # compile and link command line. SYSROOT_CFLAGS="-I$SYSROOT/usr/include" SYSROOT_LDFLAGS="-L$SYSROOT/usr/lib$OPENJDK_TARGET_CPU_ISADIR \ -L$SYSROOT/lib$OPENJDK_TARGET_CPU_ISADIR \ -L$SYSROOT/usr/ccs/lib$OPENJDK_TARGET_CPU_ISADIR" Are there also scripts available to create the SYSROOT environment or is it just done by copying a few folders manually ? Thanks, Matthias From erik.joelsson at oracle.com Mon Oct 12 15:06:59 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 12 Oct 2015 17:06:59 +0200 Subject: sysroot-like setups on Solaris In-Reply-To: <98C2119538350A4E92B3DD08E7B4146801A8C1C5A0@DEWDFEMB14B.global.corp.sap> References: <98C2119538350A4E92B3DD08E7B4146801A8C1C5A0@DEWDFEMB14B.global.corp.sap> Message-ID: <561BCC93.7000404@oracle.com> Hello Matthias, The scripts used to create the current sysroot we use internally was never published externally. For the next round of compiler and platform upgrades, which is taking place now, I do intend to publish the scripts for all platforms where we do this. I have it all prepared, but since we are still testing the new compilers, we haven't made the switch yet, and it wouldn't make much sense to push the scripts before that. For the current sysroot, which is based on Solaris10u10, I used the package installer to install a certain set of solaris packages into a new root and then applied a bunch of patches. Here is a list of the packages I needed: system SUNWaudh Audio Header Files system SUNWbinutils binutils - GNU binutils system SUNWbtool CCS tools bundled with SunOS system SUNWcsl Core Solaris, (Shared Libs) system SUNWcslr Core Solaris Libraries (Root) system SUNWdtrc DTrace Clients system SUNWfreetype2 FreeType2 Font library system SUNWhea SunOS Header Files system SUNWlibC Sun Workshop Compilers Bundled libC system SUNWlibm Math & Microtasking Library Headers & Lint Files (Usr) system SUNWpiclh PICL Header Files system SUNWpiclr PICL Framework (Root) system SUNWsprot Solaris Bundled tools system SUNWxwinc X Window System include files system SUNWxwplt X Window System platform software I also added this, which I don't really know the origin for: system SFWcups cups - Common UNIX Printing System Finally I applied these patches. Most of them were listed as needed by the Solaris Studio documentation: Sparc: 149063-01 (fixes gobjcopy) From SS12u3 118683-07 119963-24 120753-10 147436-01 x86: 149064-01 (fixes gobjcopy) From SS12u3 119961-10 119964-24 120754-10 147437-01 Doing this kind of package installation on Solaris 10 was a bit tricky and I had to run the package manager as root. Redoing it in Solaris 11 was much easier. /Erik On 2015-10-12 16:34, Baesken, Matthias wrote: > Hello all, in OpenJDK9 there is some support for building using a sysroot-like environment . > For instance see > > common/autoconf/flags.m4 > > # Solaris Studio does not have a concept of sysroot. Instead we must > # make sure the default include and lib dirs are appended to each > # compile and link command line. > SYSROOT_CFLAGS="-I$SYSROOT/usr/include" > SYSROOT_LDFLAGS="-L$SYSROOT/usr/lib$OPENJDK_TARGET_CPU_ISADIR \ > -L$SYSROOT/lib$OPENJDK_TARGET_CPU_ISADIR \ > -L$SYSROOT/usr/ccs/lib$OPENJDK_TARGET_CPU_ISADIR" > > > Are there also scripts available to create the SYSROOT environment or is it just done by copying a few folders manually ? > > > Thanks, Matthias From magnus.ihse.bursie at oracle.com Wed Oct 14 12:45:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 14 Oct 2015 14:45:55 +0200 Subject: RFR: 8139272: Add configure variable to set concurrency for jtreg tests In-Reply-To: <20151009120947.GU14241@ehelin.jrpg.bea.com> References: <20151009120947.GU14241@ehelin.jrpg.bea.com> Message-ID: <561E4E83.4090502@oracle.com> On 2015-10-09 14:09, Erik Helin wrote: > Hi all, > > this patch adds a new configure variable: --with-test-jobs. The new > variable configures how many tests jobs we run concurrently (aka the > -concurrency flag to JTReg). Today --with-jobs is passed as the > -concurrency flag to JTReg which most likely is too big for most > systems with many cores. > > For hotspot, the only "supported" configuration for running the jtreg > tests is with -concurrency:1. However, most machines will run the tests > successfully with more concurrency, but I used a default of 1. For the JDK > tests I kept --with-jobs as the default concurrency since I want to keep > the old behaviour. > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8139272 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8139272/webrev.00/ Hi Erik, Your patch looks basically sound. A few comments: * It would be good if you could add a comment somewhere, perhaps in the new function in build-performance.m4, that "0" test jobs means "let the test system use the default". * You should add TEST_JOBS to the list of INIT_CONTROL_VARIABLES in InitSupport.gmk, to stop make from complaining on it. * Also, it would be great if you updated the help message in Help.gmk to include TEST_JOBS. /Magnus From erik.joelsson at oracle.com Thu Oct 15 12:39:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 15 Oct 2015 14:39:53 +0200 Subject: RFR: JDK-8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file In-Reply-To: <722F0B41-E99D-46BA-87CE-205AA673B41F@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> <067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> <56051FD0.4010303@oracle.com> <1F931EBE-F2C0-413D-BFE4-787362577384@oracle.com> <56090777.2090807@oracle.com> <2C323894-C058-442D-92CF-BDF969CD6504@oracle.com> <56127149.6060701@oracle.com> <722F0B41-E99D-46BA-87CE-205AA673B41F@oracle.com> Message-ID: <561F9E99.1030802@oracle.com> Hello, Sorry for not noticing this earlier. Here is a fix for the problem with repeating lines in the services file. Bug: https://bugs.openjdk.java.net/browse/JDK-8139657 Patch: diff -r 9ab5571ccea8 make/gensrc/Gensrc-jdk.vm.ci.gmk --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk @@ -108,7 +108,11 @@ ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ for i in $$($(LS)); do \ c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ - $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ + $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c.tmp; \ + done) + ($(CD) $(GENSRC_DIR)/META-INF/services && \ + for i in $$($(LS) *.tmp); do \ + $(MV) $$i $${i%.tmp}; \ done) $(TOUCH) $@ /Erik On 2015-10-08 04:42, Christian Thalinger wrote: >> On Oct 5, 2015, at 2:47 AM, Magnus Ihse Bursie wrote: >> >> On 2015-09-29 03:12, Christian Thalinger wrote: >>>> On Sep 27, 2015, at 11:25 PM, Magnus Ihse Bursie wrote: >>>> >>>> On 2015-09-25 22:00, Christian Thalinger wrote: >>>>> Btw. we found a bug in creating the OptionDescriptors files; we get duplicate entries: >>>>> >>>>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.options.OptionDescriptors >>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>>>> ? >>>>> >>>>> Would this be the right fix? >>>>> >>>>> diff -r db1a815d2f6c make/gensrc/Gensrc-java.base.gmk >>>>> --- a/make/gensrc/Gensrc-java.base.gmkThu Sep 24 15:35:49 2015 -1000 >>>>> +++ b/make/gensrc/Gensrc-java.base.gmkFri Sep 25 18:18:35 2015 +0200 >>>>> @@ -94,6 +94,7 @@ >>>>> $(GENSRC_DIR)/_gensrc_proc_done >>>>> $(MKDIR) -p $(@D) >>>>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.options && \ >>>>> + $(RM) -f $@; \ >>>>> for i in $$(ls); do \ >>>>> echo $${i}_OptionDescriptors >> $@; \ >>>>> done) >>>>> >>>> That seems like a reasonable fix, yes. >>> Thanks, but? (see below) >>> >>>>> And I see the same behavior for HotSpotJVMCIBackendFactory: >>>>> >>>>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory >>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>>>> ? >>>>> >>>>> So I think a similar fix needs to be applied there. >>> ?I?ve look at the code that creates this file and it isn?t obvious to me how to fix it. Any good ideas? >> Try this: >> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ >> for i in $$($(LS)); do \ >> c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ >> + $(RM) $(GENSRC_DIR)/META-INF/services/$$c; \ >> $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ >> done) >> $(TOUCH) $@ >> >> I have not tested it but it should work. > No, this won?t work. Both implementations of HotSpotJVMCIBackendFactory (AMD64HotSpotJVMCIBackendFactory and SPARCHotSpotJVMCIBackendFactory) contain the same service file name: > > jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory > > since we need to collect all available factories in one service. > >> /Magnus From magnus.ihse.bursie at oracle.com Thu Oct 15 14:38:22 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 15 Oct 2015 16:38:22 +0200 Subject: RFR: JDK-8139668 Generate README-build.html from markdown Message-ID: <561FBA5E.1070909@oracle.com> Finished. The build documentation is currently available in README-build.html. The problem with having the build instructions in html format is two-fold: 1) It is hard to read from a terminal 2) It is unnecessary difficult to modify At least 2) means that it is an extra threshold to get over, in order to update or rewrite the build documentation. Instead, we should have the documentation in markdown format, which is easy to read in a console even in source format, and is easy to modify. From this source format, a html version can easily be generated. In this change, I have intentionally *not* modified the contents of the documentation. Instead, this patch will prepare the ground for future fixes to the documentation. There are a few, minor changes that was needed. Tables are not very easy to represent in markdown, so I replaced a few tables with lists. I also modified a few places (e.g. when refering to the documentation file as "html"). The markdown file originated from the old html file. I started out using automated tools for converting html to markdown, but then spent some time polishing the markdown to make sure the resulting html matched the original file as closely as possible. I also wanted to make sure the markdown was readable in itself, to address item 1 above. Bug: https://bugs.openjdk.java.net/browse/JDK-8139668 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8139668-markdown-documentation/webrev.01 From bob.vandette at oracle.com Thu Oct 15 20:48:07 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 15 Oct 2015 16:48:07 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries Message-ID: <2E67CEF6-6524-422B-B854-489FB00545DF@oracle.com> Resending after joining mailing list ? Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. https://bugs.openjdk.java.net/browse/JDK-8136556 The change involves: 1. Producing ?.a? archives for each native libraries. 2. Ensuring that all symbols across the JDK native libraries are unique. 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per the JNI specification. 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries and function. http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ Note: This change does not link every possible static library with the launchers. It is currently limited to the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. Bob. From christian.thalinger at oracle.com Thu Oct 15 22:30:08 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Oct 2015 12:30:08 -1000 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: References: Message-ID: <53008404-633F-4EF9-BC7C-708AFC0B26DF@oracle.com> Copy-pasting the comment I made earlier (internally): >> make/bsd/makefiles/gcc.make: >> >> + ifeq ($(BUILD_STATIC),true) >> + CXXFLAGS += -DSTATIC_BUILD >> + CFLAGS += -DSTATIC_BUILD >> >> Can we use the same name everywhere? > > We were trying to differentiate Makefile options from compile time conditionals. > In one case it?s set to true and the other it?s defined. > > Are there no other cases where this is done? I?m not sure but looking at make/excludeSrc.make all of them use the same name. > On Oct 15, 2015, at 8:10 AM, Bob Vandette wrote: > > Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. > > https://bugs.openjdk.java.net/browse/JDK-8136556 > > The change involves: > > 1. Producing ?.a? archives for each native libraries. > 2. Ensuring that all symbols across the JDK native libraries are unique. > 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per > the JNI specification. > 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries > and function. > > http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ > http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ > http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ > > Note: This change does not link every possible static library with the launchers. It is currently limited to > the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. > > > Bob. From christian.thalinger at oracle.com Thu Oct 15 22:35:05 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 15 Oct 2015 12:35:05 -1000 Subject: RFR: JDK-8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file In-Reply-To: <561F9E99.1030802@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> <067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> <56051FD0.4010303@oracle.com> <1F931EBE-F2C0-413D-BFE4-787362577384@oracle.com> <56090777.2090807@oracle.com> <2C323894-C058-442D-92CF-BDF969CD6504@oracle.com> <56127149.6060701@oracle.com> <722F0B41-E99D-46BA-87CE-205AA673B41F@oracle.com> <561F9E99.1030802@oracle.com> Message-ID: <72E521B8-43D9-4199-86E8-3263E3B14BB9@oracle.com> Looks good. Since you are a JDK 9 Reviewer, will you push this fix? > On Oct 15, 2015, at 2:39 AM, Erik Joelsson wrote: > > Hello, > > Sorry for not noticing this earlier. Here is a fix for the problem with repeating lines in the services file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139657 > Patch: > diff -r 9ab5571ccea8 make/gensrc/Gensrc-jdk.vm.ci.gmk > --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk > +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk > @@ -108,7 +108,11 @@ > ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ > for i in $$($(LS)); do \ > c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ > - $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ > + $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c.tmp; \ > + done) > + ($(CD) $(GENSRC_DIR)/META-INF/services && \ > + for i in $$($(LS) *.tmp); do \ > + $(MV) $$i $${i%.tmp}; \ > done) > $(TOUCH) $@ > > /Erik > > On 2015-10-08 04:42, Christian Thalinger wrote: >>> On Oct 5, 2015, at 2:47 AM, Magnus Ihse Bursie wrote: >>> >>> On 2015-09-29 03:12, Christian Thalinger wrote: >>>>> On Sep 27, 2015, at 11:25 PM, Magnus Ihse Bursie wrote: >>>>> >>>>> On 2015-09-25 22:00, Christian Thalinger wrote: >>>>>> Btw. we found a bug in creating the OptionDescriptors files; we get duplicate entries: >>>>>> >>>>>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.options.OptionDescriptors >>>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>>>>> ? >>>>>> >>>>>> Would this be the right fix? >>>>>> >>>>>> diff -r db1a815d2f6c make/gensrc/Gensrc-java.base.gmk >>>>>> --- a/make/gensrc/Gensrc-java.base.gmkThu Sep 24 15:35:49 2015 -1000 >>>>>> +++ b/make/gensrc/Gensrc-java.base.gmkFri Sep 25 18:18:35 2015 +0200 >>>>>> @@ -94,6 +94,7 @@ >>>>>> $(GENSRC_DIR)/_gensrc_proc_done >>>>>> $(MKDIR) -p $(@D) >>>>>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.options && \ >>>>>> + $(RM) -f $@; \ >>>>>> for i in $$(ls); do \ >>>>>> echo $${i}_OptionDescriptors >> $@; \ >>>>>> done) >>>>>> >>>>> That seems like a reasonable fix, yes. >>>> Thanks, but? (see below) >>>> >>>>>> And I see the same behavior for HotSpotJVMCIBackendFactory: >>>>>> >>>>>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory >>>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>>>>> ? >>>>>> >>>>>> So I think a similar fix needs to be applied there. >>>> ?I?ve look at the code that creates this file and it isn?t obvious to me how to fix it. Any good ideas? >>> Try this: >>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ >>> for i in $$($(LS)); do \ >>> c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ >>> + $(RM) $(GENSRC_DIR)/META-INF/services/$$c; \ >>> $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ >>> done) >>> $(TOUCH) $@ >>> >>> I have not tested it but it should work. >> No, this won?t work. Both implementations of HotSpotJVMCIBackendFactory (AMD64HotSpotJVMCIBackendFactory and SPARCHotSpotJVMCIBackendFactory) contain the same service file name: >> >> jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory >> >> since we need to collect all available factories in one service. >> >>> /Magnus > From Alan.Bateman at oracle.com Fri Oct 16 06:28:43 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 16 Oct 2015 07:28:43 +0100 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: References: Message-ID: <5620991B.8050606@oracle.com> On 15/10/2015 19:07, Bob Vandette wrote: > Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. > > https://bugs.openjdk.java.net/browse/JDK-8136556 > > The change involves: > > 1. Producing ?.a? archives for each native libraries. > 2. Ensuring that all symbols across the JDK native libraries are unique. > 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per > the JNI specification. > 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries > and function. > > http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ > http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ > http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ > > Note: This change does not link every possible static library with the launchers. It is currently limited to > the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. > I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. -Alan From erik.joelsson at oracle.com Fri Oct 16 07:32:58 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Oct 2015 09:32:58 +0200 Subject: RFR: JDK-8139657: Incremental build of jdk.vm.ci-gensrc creates repeated entries in services file In-Reply-To: <72E521B8-43D9-4199-86E8-3263E3B14BB9@oracle.com> References: <2B401EAC-B386-4E42-BC4C-DD267FFD4970@oracle.com> <55F9671C.4000208@oracle.com> <99042B61-9F43-42CE-835C-095CD2858CB1@oracle.com> <55F9F08E.8010506@oracle.com> <08A9DB82-58D0-41F8-97F5-23AD78205263@oracle.com> <067C7DA1-7422-411E-A678-91FBDECEBE1D@oracle.com> <8E92D69B-7207-4CDC-80F7-3AA65AC5C482@oracle.com> <97150580-7329-438F-9B64-F47E3BFE9F08@oracle.com> <56051FD0.4010303@oracle.com> <1F931EBE-F2C0-413D-BFE4-787362577384@oracle.com> <56090777.2090807@oracle.com> <2C323894-C058-442D-92CF-BDF969CD6504@oracle.com> <56127149.6060701@oracle.com> <722F0B41-E99D-46BA-87CE-205AA673B41F@oracle.com> <561F9E99.1030802@oracle.com> <72E521B8-43D9-4199-86E8-3263E3B14BB9@oracle.com> Message-ID: <5620A82A.8020707@oracle.com> I will push it to hs-comp. Thanks for the review! /Erik On 2015-10-16 00:35, Christian Thalinger wrote: > Looks good. > > Since you are a JDK 9 Reviewer, will you push this fix? > >> On Oct 15, 2015, at 2:39 AM, Erik Joelsson wrote: >> >> Hello, >> >> Sorry for not noticing this earlier. Here is a fix for the problem with repeating lines in the services file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139657 >> Patch: >> diff -r 9ab5571ccea8 make/gensrc/Gensrc-jdk.vm.ci.gmk >> --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk >> +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk >> @@ -108,7 +108,11 @@ >> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ >> for i in $$($(LS)); do \ >> c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ >> - $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ >> + $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c.tmp; \ >> + done) >> + ($(CD) $(GENSRC_DIR)/META-INF/services && \ >> + for i in $$($(LS) *.tmp); do \ >> + $(MV) $$i $${i%.tmp}; \ >> done) >> $(TOUCH) $@ >> >> /Erik >> >> On 2015-10-08 04:42, Christian Thalinger wrote: >>>> On Oct 5, 2015, at 2:47 AM, Magnus Ihse Bursie wrote: >>>> >>>> On 2015-09-29 03:12, Christian Thalinger wrote: >>>>>> On Sep 27, 2015, at 11:25 PM, Magnus Ihse Bursie wrote: >>>>>> >>>>>> On 2015-09-25 22:00, Christian Thalinger wrote: >>>>>>> Btw. we found a bug in creating the OptionDescriptors files; we get duplicate entries: >>>>>>> >>>>>>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.options.OptionDescriptors >>>>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>>>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>>>>>> jdk.internal.jvmci.compiler.Compiler_OptionDescriptors >>>>>>> jdk.internal.jvmci.hotspot.HotSpotConstantReflectionProvider_OptionDescriptors >>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaFieldImpl_OptionDescriptors >>>>>>> jdk.internal.jvmci.hotspot.HotSpotResolvedJavaMethodImpl_OptionDescriptors >>>>>>> ? >>>>>>> >>>>>>> Would this be the right fix? >>>>>>> >>>>>>> diff -r db1a815d2f6c make/gensrc/Gensrc-java.base.gmk >>>>>>> --- a/make/gensrc/Gensrc-java.base.gmkThu Sep 24 15:35:49 2015 -1000 >>>>>>> +++ b/make/gensrc/Gensrc-java.base.gmkFri Sep 25 18:18:35 2015 +0200 >>>>>>> @@ -94,6 +94,7 @@ >>>>>>> $(GENSRC_DIR)/_gensrc_proc_done >>>>>>> $(MKDIR) -p $(@D) >>>>>>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.options && \ >>>>>>> + $(RM) -f $@; \ >>>>>>> for i in $$(ls); do \ >>>>>>> echo $${i}_OptionDescriptors >> $@; \ >>>>>>> done) >>>>>>> >>>>>> That seems like a reasonable fix, yes. >>>>> Thanks, but? (see below) >>>>> >>>>>>> And I see the same behavior for HotSpotJVMCIBackendFactory: >>>>>>> >>>>>>> $ cat build/macosx-x86_64-normal-server-release/jdk/modules/java.base/META-INF/services/jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory >>>>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>>>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>>>>>> jdk.internal.jvmci.hotspot.amd64.AMD64HotSpotJVMCIBackendFactory >>>>>>> jdk.internal.jvmci.hotspot.sparc.SPARCHotSpotJVMCIBackendFactory >>>>>>> ? >>>>>>> >>>>>>> So I think a similar fix needs to be applied there. >>>>> ?I?ve look at the code that creates this file and it isn?t obvious to me how to fix it. Any good ideas? >>>> Try this: >>>> ($(CD) $(GENSRC_DIR)/META-INF/jvmci.providers && \ >>>> for i in $$($(LS)); do \ >>>> c=$$($(CAT) $$i | $(TR) -d '\n\r'); \ >>>> + $(RM) $(GENSRC_DIR)/META-INF/services/$$c; \ >>>> $(ECHO) $$i >> $(GENSRC_DIR)/META-INF/services/$$c; \ >>>> done) >>>> $(TOUCH) $@ >>>> >>>> I have not tested it but it should work. >>> No, this won?t work. Both implementations of HotSpotJVMCIBackendFactory (AMD64HotSpotJVMCIBackendFactory and SPARCHotSpotJVMCIBackendFactory) contain the same service file name: >>> >>> jdk.internal.jvmci.hotspot.HotSpotJVMCIBackendFactory >>> >>> since we need to collect all available factories in one service. >>> >>>> /Magnus From erik.joelsson at oracle.com Fri Oct 16 08:26:51 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 16 Oct 2015 10:26:51 +0200 Subject: RFR: JDK-8139735: Switch compilers in JPRT for windows and linux Message-ID: <5620B4CB.2040500@oracle.com> The compilers used for building the product internally at Oracle is changing soon for Windows and Linux. This change is needed to instruct JPRT to use the new compilers. I also include updates to the devkit generating scripts for these platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8139735 Webrev: http://cr.openjdk.java.net/~erikj/8139735/webrev.01/ /Erik From bob.vandette at oracle.com Fri Oct 16 15:11:23 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 16 Oct 2015 11:11:23 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <5620991B.8050606@oracle.com> References: <5620991B.8050606@oracle.com> Message-ID: > On Oct 16, 2015, at 2:28 AM, Alan Bateman wrote: > > On 15/10/2015 19:07, Bob Vandette wrote: >> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. >> >> https://bugs.openjdk.java.net/browse/JDK-8136556 >> >> The change involves: >> >> 1. Producing ?.a? archives for each native libraries. >> 2. Ensuring that all symbols across the JDK native libraries are unique. >> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per >> the JNI specification. >> 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries >> and function. >> >> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ >> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ >> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ >> >> Note: This change does not link every possible static library with the launchers. It is currently limited to >> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. >> > I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. Ok, I?ll take care of that. > > If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. The implementation falls back to the getPosixLocale function when the Framework doesn?t exist. > > Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. I will be setting up a period build on a Mac I?ve got running a Hudson server in our lab until we can get JPRT support for this configuration. Bob. > > -Alan From naoto.sato at oracle.com Fri Oct 16 17:01:52 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 16 Oct 2015 10:01:52 -0700 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: References: <5620991B.8050606@oracle.com> Message-ID: <56212D80.9090404@oracle.com> Hi Bob, Alan, On 10/16/15 8:11 AM, Bob Vandette wrote: >> I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. > Ok, I?ll take care of that. >> >> If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. > The implementation falls back to the getPosixLocale function when the Framework doesn?t exist. In that case, the locale settings in the MacOSX's Settings will not be reflected in Java's default locale. Naoto From aw1621107 at gmail.com Fri Oct 16 16:59:55 2015 From: aw1621107 at gmail.com (Alex Wang) Date: Fri, 16 Oct 2015 12:59:55 -0400 Subject: Building openjdk 8u on OS X 10.11 fails In-Reply-To: References: <7C29F8CD-BF8C-4748-B86C-924AB8005899@gmail.com> <861FA87D-388F-45B8-837E-F2C86D502446@gmail.com> Message-ID: <6BCB3BCE-EE2C-41D5-9A18-2DC92A5F18AF@gmail.com> Hi Dennis, Sorry for not seeing this until now; looks like this got caught up in a filter that I just got around to looking at today. But in any case, thank you for the solution! Wasn't expecting it to be that simple. -Alex > On Sep 17, 2015, at 9:04 AM, Denis Fokin wrote: > > Hi Alex, > > I have just updated to 10.11 and experienced the same problem. > > The solution is "export MACOSX_DEPLOYMENT_TARGET=10.9" > > Thank you, > Denis > > > On Fri, Jul 17, 2015 at 7:56 AM, Alex Wang > wrote: > Edit for formatting. Forgot that soft wraps were a thing. My apologies. > > I?m not really sure if this is something for the jdk developers or an upstream > issue, since the error doesn?t seem to be strictly under idk control (the error > looks to me to be something g++ does); I just thought to check in case there?s > an easy solution (and I?m not really sure if reporting a problem for Xcode 4 > would really accomplish anything). If I?m in the wrong place please let me know. > > Running OS X 10.11, JAVA_HOME is set to a 1.7 install, xcode-select is pointing > at the right application, and I *think* the Xcode 4 command line tools were > installed. Ran xcode-select ?install after switching, and it prompted for an > install, at least. > > ./configure ?with-xcode-path= fails with this in config.log: > > configure:28891: checking for stdio.h > configure:28891: result: yes > configure:28919: checking size of int * > configure:28924: /usr/bin/g++ -o conftest conftest.cpp >&5 > couldn't understand kern.osversion `15.0.0' > ld: library not found for -lgcc_s.10.4 > collect2: ld returned 1 exit status > configure:28924: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h */ > > configure:28938: result: 0 > configure:28960: The tested number of bits in the target (0) differs from the > number of bits expected to be found in the target (64). > configure:28962: I'll retry after setting the platforms compiler target bits > flag to -m64 > configure:28993: checking size of int * > configure:28998: /usr/bin/g++ -o conftest -m64 -m64 conftest.cpp >&5 > couldn't understand kern.osversion `15.0.0' > ld: library not found for -lgcc_s.10.4 > collect2: ld returned 1 exit status > configure:28998: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h */ > > configure:29012: result: 0 > configure:29026: error: The tested number of bits in the target (0) differs from > the number of bits expected to be found in the target (64) > > I looked around for a solution for the missing library, nothing I found really > helped. One suggestion was to symlink it to the OS-provided one (l > Unfortunately, 10.11?s new rootless feature means that I can?t write to that > folder, and I don?t know if disabling that feature just for a build is the best > idea. Another was to change the library in the build scripts. I took a look > around, but the closest thing I could find in the config scripts were -lgcc > flags, so I figured something else was the cause. > > I also tried messing with symlinking bits and pieces of Xcode 7?s toolchain into > Xcode 4 to try and replace the offending binary, but nothing seemed to change. > Using Xcode 4?s gcc sometimes worked, and sometimes produced the same error. I?m > not really sure what about the programs I threw at it caused it to fail or not, > but at least it seemed consistent for any particular program. > > If I can provide more info that would be helpful, I?ll be happy to do so. > > From bob.vandette at oracle.com Fri Oct 16 19:06:15 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 16 Oct 2015 15:06:15 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <56212D80.9090404@oracle.com> References: <5620991B.8050606@oracle.com> <56212D80.9090404@oracle.com> Message-ID: <48D66535-FBBD-469B-A4FF-6DAEF84B45A0@oracle.com> > On Oct 16, 2015, at 1:01 PM, Naoto Sato wrote: > > Hi Bob, Alan, > > On 10/16/15 8:11 AM, Bob Vandette wrote: >>> I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. >> Ok, I?ll take care of that. >>> >>> If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. >> The implementation falls back to the getPosixLocale function when the Framework doesn?t exist. > > In that case, the locale settings in the MacOSX's Settings will not be reflected in Java's default locale. Unless we have the sources to the JavaRuntimeSupport, I see no way around this limitation. Any attempt to load the shared library, causes the JavaRuntimeSupport framework to try to initialize itself. The initialization fails since it can?t detect the presence of the Java runtime that?s trying to load it and a dialog box asking to install Java appears. I think we?re going to have to live with this limitation. Bob. > > Naoto From erik.joelsson at oracle.com Mon Oct 19 11:54:56 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 19 Oct 2015 13:54:56 +0200 Subject: [8u] RFR: JDK-8139813: Base heap size on type of boot jdk, not architecture of build machine Message-ID: <5624DA10.8000905@oracle.com> Hello, Please review this minor configure fix. The logic in configure for setting up proper mx flags for the bootjdk is flawed in that it assumes a 64bit bootjdk if the build machine is 64bit. This patch fixes this by instead testing if the bootjdk is 64bit or not. The problem was discovered in 8u and is causing trouble for certain build setups there. Since it also applies to 9, I'm posting a webrev for each, intending to fix this in both releases. Bug: https://bugs.openjdk.java.net/browse/JDK-8139813 Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.01/ Webrev JDK 8u: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.01/ /Erik From erik.joelsson at oracle.com Mon Oct 19 12:44:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 19 Oct 2015 14:44:57 +0200 Subject: RFR: JDK-8139668 Generate README-build.html from markdown In-Reply-To: <561FBA5E.1070909@oracle.com> References: <561FBA5E.1070909@oracle.com> Message-ID: <5624E5C9.2030708@oracle.com> Looks good to me. /Erik On 2015-10-15 16:38, Magnus Ihse Bursie wrote: > Finished. > The build documentation is currently available in README-build.html. > The problem with having the build instructions in html format is > two-fold: > > 1) It is hard to read from a terminal > > 2) It is unnecessary difficult to modify > > At least 2) means that it is an extra threshold to get over, in order > to update or rewrite the build documentation. > > Instead, we should have the documentation in markdown format, which is > easy to read in a console even in source format, and is easy to > modify. From this source format, a html version can easily be generated. > > In this change, I have intentionally *not* modified the contents of > the documentation. Instead, this patch will prepare the ground for > future fixes to the documentation. There are a few, minor changes that > was needed. Tables are not very easy to represent in markdown, so I > replaced a few tables with lists. I also modified a few places (e.g. > when refering to the documentation file as "html"). > > The markdown file originated from the old html file. I started out > using automated tools for converting html to markdown, but then spent > some time polishing the markdown to make sure the resulting html > matched the original file as closely as possible. I also wanted to > make sure the markdown was readable in itself, to address item 1 above. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139668 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8139668-markdown-documentation/webrev.01 From bob.vandette at oracle.com Mon Oct 19 18:09:21 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 19 Oct 2015 14:09:21 -0400 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <5620991B.8050606@oracle.com> References: <5620991B.8050606@oracle.com> Message-ID: <68E34DF5-8759-4614-AB69-F5301D183716@oracle.com> Here?s the updated set of webrev?s that address two issues: 1. Move jni_util.h out of jawt.h 2. Christians concern over using a single variable name for Makefile and C/C++ logic. http://cr.openjdk.java.net/~bobv/8136556/webrev.01 http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01 http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01 Bob. > On Oct 16, 2015, at 2:28 AM, Alan Bateman wrote: > > On 15/10/2015 19:07, Bob Vandette wrote: >> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. >> >> https://bugs.openjdk.java.net/browse/JDK-8136556 >> >> The change involves: >> >> 1. Producing ?.a? archives for each native libraries. >> 2. Ensuring that all symbols across the JDK native libraries are unique. >> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per >> the JNI specification. >> 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries >> and function. >> >> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ >> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ >> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ >> >> Note: This change does not link every possible static library with the launchers. It is currently limited to >> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. >> > I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. > > If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. > > Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. > > -Alan From christian.thalinger at oracle.com Mon Oct 19 19:25:57 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 19 Oct 2015 09:25:57 -1000 Subject: RFR: 8136556 - Add the ability to perform static builds of MacOSX x64 binaries In-Reply-To: <68E34DF5-8759-4614-AB69-F5301D183716@oracle.com> References: <5620991B.8050606@oracle.com> <68E34DF5-8759-4614-AB69-F5301D183716@oracle.com> Message-ID: > On Oct 19, 2015, at 8:09 AM, Bob Vandette wrote: > > Here?s the updated set of webrev?s that address two issues: > > 1. Move jni_util.h out of jawt.h > 2. Christians concern over using a single variable name for Makefile and C/C++ logic. Thanks. Looks good to me. > > http://cr.openjdk.java.net/~bobv/8136556/webrev.01 > http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.01 > http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.01 > > Bob. > >> On Oct 16, 2015, at 2:28 AM, Alan Bateman > wrote: >> >> On 15/10/2015 19:07, Bob Vandette wrote: >>> Please review this JDK 9 enhancement which allows a completely static build of the JDK for MacOSX x64 platforms. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8136556 > >>> >>> The change involves: >>> >>> 1. Producing ?.a? archives for each native libraries. >>> 2. Ensuring that all symbols across the JDK native libraries are unique. >>> 3. Changing the JNI_OnLoad and JNI_OnUnload (and the Agent equivalents) to have the each library name appended per >>> the JNI specification. >>> 4. Modifications to the launcher and launcher Makefiles to allow them to be linked with the java.base and jdk.jdwp.agent libraries >>> and function. >>> >>> http://cr.openjdk.java.net/~bobv/8136556/webrev.00/ > >>> http://cr.openjdk.java.net/~bobv/8136556/hotspot/webrev.00/ > >>> http://cr.openjdk.java.net/~bobv/8136556/jdk/webrev.00/ > >>> >>> Note: This change does not link every possible static library with the launchers. It is currently limited to >>> the java.base and jdk.jdwp.agent libraries in order to allow for the TCK validation of the base module only. >>> >> I've skimmed through the patches and the DEF_* macros look okay. The only one that doesn't look right is jawt.h/jawt.c. As jawt.h is shipped by the JDK then I think the include of jni_util.h needs to move from jawt.h to jawt.c. >> >> If I read the changes correctly then not loading the JavaRuntimeSupport.framework on Mac means the locale might not be right, is that correct? Brent might remember this issue as we've often pondered the implications of this disappearing in an Mac update. >> >> Will there be continuous or at least regular builds setup so that build breakages will be reported in a timely manner? It would be easy to change something that breaks the static library build. >> >> -Alan > From martinrb at google.com Tue Oct 20 02:25:12 2015 From: martinrb at google.com (Martin Buchholz) Date: Mon, 19 Oct 2015 19:25:12 -0700 Subject: [patch] fix the build with a toolchain with a linker defaulting to ld --as-needed In-Reply-To: <56254D37.3090903@ubuntu.com> References: <56254D37.3090903@ubuntu.com> Message-ID: [+build-dev] On Mon, Oct 19, 2015 at 1:06 PM, Matthias Klose wrote: > Toolchains for some Linux distributions (e.g. Ubuntu, OpenSuse) are > configured to pass --as-needed to the linker by default, only linking with > libraries when required. A common build failure triggered by this default > is having a required library on the command line before the object files > being linked. This happens when linking with a system zlib or system jpeg > library. > > Patch is attached, checked with b87. > > There is one unrelated change, removing the explicit linking with the C > library. Is there any reason to keep that? > > Matthias > > > From tim.bell at oracle.com Tue Oct 20 04:07:32 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 19 Oct 2015 21:07:32 -0700 Subject: RFR: JDK-8139735: Switch compilers in JPRT for windows and linux In-Reply-To: <5620B4CB.2040500@oracle.com> References: <5620B4CB.2040500@oracle.com> Message-ID: <5625BE04.5020400@oracle.com> Erik: > The compilers used for building the product internally at Oracle is > changing soon for Windows and Linux. This change is needed to instruct > JPRT to use the new compilers. > > I also include updates to the devkit generating scripts for these > platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139735 > Webrev: http://cr.openjdk.java.net/~erikj/8139735/webrev.01/ Looks good. Tim From tim.bell at oracle.com Tue Oct 20 04:16:16 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 19 Oct 2015 21:16:16 -0700 Subject: [8u] RFR: JDK-8139813: Base heap size on type of boot jdk, not architecture of build machine In-Reply-To: <5624DA10.8000905@oracle.com> References: <5624DA10.8000905@oracle.com> Message-ID: <5625C010.3030707@oracle.com> Hi Erik: > Please review this minor configure fix. The logic in configure for > setting up proper mx flags for the bootjdk is flawed in that it > assumes a 64bit bootjdk if the build machine is 64bit. This patch > fixes this by instead testing if the bootjdk is 64bit or not. The > problem was discovered in 8u and is causing trouble for certain build > setups there. Since it also applies to 9, I'm posting a webrev for > each, intending to fix this in both releases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139813 > Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.01/ > Webrev JDK 8u: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.01/ Looks good to me. Tim From magnus.ihse.bursie at oracle.com Tue Oct 20 06:38:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 08:38:55 +0200 Subject: RFR: JDK-8139735: Switch compilers in JPRT for windows and linux In-Reply-To: <5620B4CB.2040500@oracle.com> References: <5620B4CB.2040500@oracle.com> Message-ID: <5625E17F.7010009@oracle.com> On 2015-10-16 10:26, Erik Joelsson wrote: > The compilers used for building the product internally at Oracle is > changing soon for Windows and Linux. This change is needed to instruct > JPRT to use the new compilers. > > I also include updates to the devkit generating scripts for these > platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139735 > Webrev: http://cr.openjdk.java.net/~erikj/8139735/webrev.01/ > > /Erik Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Tue Oct 20 06:51:24 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 08:51:24 +0200 Subject: [8u] RFR: JDK-8139813: Base heap size on type of boot jdk, not architecture of build machine In-Reply-To: <5624DA10.8000905@oracle.com> References: <5624DA10.8000905@oracle.com> Message-ID: <5625E46C.3090106@oracle.com> On 2015-10-19 13:54, Erik Joelsson wrote: > Hello, > > Please review this minor configure fix. The logic in configure for > setting up proper mx flags for the bootjdk is flawed in that it > assumes a 64bit bootjdk if the build machine is 64bit. This patch > fixes this by instead testing if the bootjdk is 64bit or not. The > problem was discovered in 8u and is causing trouble for certain build > setups there. Since it also applies to 9, I'm posting a webrev for > each, intending to fix this in both releases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139813 > Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.01/ > Webrev JDK 8u: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.01/ The code seems correct. A suggestion, though: If you break out the 64-bit detection and wrap it in a MSG_CHECKING/RESULT pair, we can get a configure log result that indicates what kind of bootjdk we think we found. And it will be easier to do a 64-bit check elsewhere, should the need arise. /Magnus From david.holmes at oracle.com Tue Oct 20 07:30:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Oct 2015 17:30:12 +1000 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <562557AE.5070408@ubuntu.com> References: <562557AE.5070408@ubuntu.com> Message-ID: <5625ED84.8020702@oracle.com> Hi Matthias, Please direct all these build related issues to build-dev (cc'd). Thanks, David On 20/10/2015 6:50 AM, Matthias Klose wrote: > I'm working around some build failures for zero targets, which fail to > build because the configury in openjdk tries to set -m32/-m64 on it's > own. I assume this behaviour was added for sun/oracle product builds to > build x86 and x86_64 targets on a x86_64 platform. The issue is that > the current configury checks if -m32/-m64 works with the current > compiler, and then enables it without losses. This breaks at least on > the x86_64-linux-gnux32 target. I assume it will break on other targets > as well, which don't recognize -m32/-m64, but usually use other options > like -mabi=. Instead of hard-coding these flags for every > architecture, is there any chance for not passing these flags at all for > the default mode? > > Thanks, Matthias From david.holmes at oracle.com Tue Oct 20 07:36:35 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Oct 2015 17:36:35 +1000 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <5625ED84.8020702@oracle.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> Message-ID: <5625EF03.9050304@oracle.com> > On 20/10/2015 6:50 AM, Matthias Klose wrote: >> I'm working around some build failures for zero targets, which fail to >> build because the configury in openjdk tries to set -m32/-m64 on it's >> own. I assume this behaviour was added for sun/oracle product builds to >> build x86 and x86_64 targets on a x86_64 platform. The issue is that >> the current configury checks if -m32/-m64 works with the current >> compiler, and then enables it without losses. This breaks at least on >> the x86_64-linux-gnux32 target. I assume it will break on other targets >> as well, which don't recognize -m32/-m64, but usually use other options >> like -mabi=. Instead of hard-coding these flags for every >> architecture, is there any chance for not passing these flags at all for >> the default mode? Part of the problem is that the default mode is not known ahead of time, your gcc on your x64 system might be configured to build 32-bit by default. If there is a better way to select this than -m32/-m64 then I'm happy to hear it, but not sure if -march/-mabi gives us anything better on x86. What exactly would you propose? Thanks, David >> >> Thanks, Matthias From erik.joelsson at oracle.com Tue Oct 20 08:20:19 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Oct 2015 10:20:19 +0200 Subject: [8u] RFR: JDK-8139813: Base heap size on type of boot jdk, not architecture of build machine In-Reply-To: <5625E46C.3090106@oracle.com> References: <5624DA10.8000905@oracle.com> <5625E46C.3090106@oracle.com> Message-ID: <5625F943.1050804@oracle.com> Hello, New webrevs implementing the suggestion by Magnus. Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.02/ Webrev JDK 8u: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.02/ /Erik On 2015-10-20 08:51, Magnus Ihse Bursie wrote: > On 2015-10-19 13:54, Erik Joelsson wrote: >> Hello, >> >> Please review this minor configure fix. The logic in configure for >> setting up proper mx flags for the bootjdk is flawed in that it >> assumes a 64bit bootjdk if the build machine is 64bit. This patch >> fixes this by instead testing if the bootjdk is 64bit or not. The >> problem was discovered in 8u and is causing trouble for certain build >> setups there. Since it also applies to 9, I'm posting a webrev for >> each, intending to fix this in both releases. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139813 >> Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.01/ >> Webrev JDK 8u: >> http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.01/ > > The code seems correct. A suggestion, though: If you break out the > 64-bit detection and wrap it in a MSG_CHECKING/RESULT pair, we can get > a configure log result that indicates what kind of bootjdk we think we > found. And it will be easier to do a 64-bit check elsewhere, should > the need arise. > > /Magnus From erik.joelsson at oracle.com Tue Oct 20 08:28:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Oct 2015 10:28:20 +0200 Subject: [patch] fix the build with a toolchain with a linker defaulting to ld --as-needed In-Reply-To: <56254D37.3090903@ubuntu.com> References: <56254D37.3090903@ubuntu.com> Message-ID: <5625FB24.60609@oracle.com> Hello Matthias, I think this looks good and can sponsor the push for you. Have you signed the OCA? /Erik On 2015-10-19 22:06, Matthias Klose wrote: > Toolchains for some Linux distributions (e.g. Ubuntu, OpenSuse) are > configured to pass --as-needed to the linker by default, only linking > with libraries when required. A common build failure triggered by > this default is having a required library on the command line before > the object files being linked. This happens when linking with a > system zlib or system jpeg library. > > Patch is attached, checked with b87. > > There is one unrelated change, removing the explicit linking with the > C library. Is there any reason to keep that? > > Matthias > > From magnus.ihse.bursie at oracle.com Tue Oct 20 09:11:00 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 11:11:00 +0200 Subject: RFR: JDK-8139951 Do not store debug level in OPT part of Verona string Message-ID: <56260524.1020506@oracle.com> After discussion, it was decided that debug level information should not be a part of the new version string as implemented in Verona. Instead, this information should be propagated using other means. (Follow-up bugs will be filed for this). This bug removes the debug-level from the opt part of the version string. Note that this fix will be pushed to verona/stage. Bug: https://bugs.openjdk.java.net/browse/JDK-8139951 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8139951-no-debug-in-opt-for-verona/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Oct 20 09:45:28 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Oct 2015 11:45:28 +0200 Subject: RFR: JDK-8139951 Do not store debug level in OPT part of Verona string In-Reply-To: <56260524.1020506@oracle.com> References: <56260524.1020506@oracle.com> Message-ID: <56260D38.2000107@oracle.com> Looks good to me. Nice to see all that nastiness disappear. /Erik On 2015-10-20 11:11, Magnus Ihse Bursie wrote: > After discussion, it was decided that debug level information should > not be a part of the new version string as implemented in Verona. > Instead, this information should be propagated using other means. > (Follow-up bugs will be filed for this). > > This bug removes the debug-level from the opt part of the version string. > > Note that this fix will be pushed to verona/stage. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139951 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8139951-no-debug-in-opt-for-verona/webrev.01 > > /Magnus > From doko at ubuntu.com Tue Oct 20 11:46:38 2015 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 20 Oct 2015 13:46:38 +0200 Subject: [patch] fix the build with a toolchain with a linker defaulting to ld --as-needed In-Reply-To: <5625FB24.60609@oracle.com> References: <56254D37.3090903@ubuntu.com> <5625FB24.60609@oracle.com> Message-ID: <5626299E.9000504@ubuntu.com> On 20.10.2015 10:28, Erik Joelsson wrote: > Hello Matthias, > > I think this looks good and can sponsor the push for you. Have you signed the OCA? see http://www.oracle.com/technetwork/community/oca-486395.html#k > > /Erik > > On 2015-10-19 22:06, Matthias Klose wrote: >> Toolchains for some Linux distributions (e.g. Ubuntu, OpenSuse) are configured >> to pass --as-needed to the linker by default, only linking with libraries when >> required. A common build failure triggered by this default is having a >> required library on the command line before the object files being linked. >> This happens when linking with a system zlib or system jpeg library. >> >> Patch is attached, checked with b87. >> >> There is one unrelated change, removing the explicit linking with the C >> library. Is there any reason to keep that? >> >> Matthias >> >> > From doko at ubuntu.com Tue Oct 20 12:14:11 2015 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 20 Oct 2015 14:14:11 +0200 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <5625EF03.9050304@oracle.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> Message-ID: <56263013.5050107@ubuntu.com> On 20.10.2015 09:36, David Holmes wrote: >> On 20/10/2015 6:50 AM, Matthias Klose wrote: >>> I'm working around some build failures for zero targets, which fail to >>> build because the configury in openjdk tries to set -m32/-m64 on it's >>> own. I assume this behaviour was added for sun/oracle product builds to >>> build x86 and x86_64 targets on a x86_64 platform. The issue is that >>> the current configury checks if -m32/-m64 works with the current >>> compiler, and then enables it without losses. This breaks at least on >>> the x86_64-linux-gnux32 target. I assume it will break on other targets >>> as well, which don't recognize -m32/-m64, but usually use other options >>> like -mabi=. Instead of hard-coding these flags for every >>> architecture, is there any chance for not passing these flags at all for >>> the default mode? > > Part of the problem is that the default mode is not known ahead of time, your > gcc on your x64 system might be configured to build 32-bit by default. is this really a common configuration? I don't know any Linux distribution shipping such a compiler. The one possibility for a 32bit toolchain on a 64bit host might be a x86 chroot created on a x86_64 host. But usually such build environments are entered with a 32bit personality (see linux32(1)), hiding anything build related from the host. I would expect that the default mode is passed in some way as autoconf option, or by setting CC="gcc -m64" (the latter unfortunately not working because CC is expected to be a file name in some places). > If there is a better way to select this than -m32/-m64 then I'm happy to hear > it, but not sure if -march/-mabi gives us anything better on x86. What exactly > would you propose? I'm not proposing to use -march/-mabi instead, but just avoiding -m32/-m64 at all, unless you explicitly configure for it (e.g. --with-abi= ?). Matthias From magnus.ihse.bursie at oracle.com Tue Oct 20 12:57:24 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 14:57:24 +0200 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <56263013.5050107@ubuntu.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> Message-ID: <56263A34.20203@oracle.com> On 2015-10-20 14:14, Matthias Klose wrote: > On 20.10.2015 09:36, David Holmes wrote: >>> On 20/10/2015 6:50 AM, Matthias Klose wrote: >>>> I'm working around some build failures for zero targets, which fail to >>>> build because the configury in openjdk tries to set -m32/-m64 on it's >>>> own. I assume this behaviour was added for sun/oracle product >>>> builds to >>>> build x86 and x86_64 targets on a x86_64 platform. The issue is that >>>> the current configury checks if -m32/-m64 works with the current >>>> compiler, and then enables it without losses. This breaks at least on >>>> the x86_64-linux-gnux32 target. What does x86_64-linux-gnux32 imply? Some sort of mix between 32 and 64-bit? >>>> I assume it will break on other targets >>>> as well, which don't recognize -m32/-m64, but usually use other >>>> options >>>> like -mabi=. Instead of hard-coding these flags for every >>>> architecture, is there any chance for not passing these flags at >>>> all for >>>> the default mode? >> >> Part of the problem is that the default mode is not known ahead of >> time, your >> gcc on your x64 system might be configured to build 32-bit by default. > > is this really a common configuration? I don't know any Linux > distribution shipping such a compiler. The one possibility for a > 32bit toolchain on a 64bit host might be a x86 chroot created on a > x86_64 host. But usually such build environments are entered with a > 32bit personality (see linux32(1)), hiding anything build related from > the host. Originally we started adding -m32 to force 32-bit builds on 64-bit platforms. I think the wide usage of -m64 more arouse as a symmetrical counterpart, rather than a conscious design decision. I do not think the current implementation is optimal, but it has worked for us. :-) > I would expect that the default mode is passed in some way as autoconf > option, or by setting CC="gcc -m64" (the latter unfortunately not > working because CC is expected to be a file name in some places). Setting CC="compiler -arg" have worked in the past. The intention is that it should work. But since it's not regularly tested, it has probably broken somewhere. Thanks for pointing it out. > >> If there is a better way to select this than -m32/-m64 then I'm happy >> to hear >> it, but not sure if -march/-mabi gives us anything better on x86. >> What exactly >> would you propose? > > I'm not proposing to use -march/-mabi instead, but just avoiding > -m32/-m64 at all, unless you explicitly configure for it (e.g. > --with-abi= ?). Overall, our handling of compiler flags is quite a mess. Erik and I have talked on multiple occasions to rewrite this. Our basic idea was that we should split down the flag definitions into more manageble chunks, that can be selectivly appended to the compilation line. For this case, you could imagine e.g. JDK_ARCH_CFLAGS or JDK_ABI_CFLAGS, which could be set to -m32, -m64 or nothing at all, depending on use case. /Magnus From magnus.ihse.bursie at oracle.com Tue Oct 20 12:59:11 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 14:59:11 +0200 Subject: [8u] RFR: JDK-8139813: Base heap size on type of boot jdk, not architecture of build machine In-Reply-To: <5625F943.1050804@oracle.com> References: <5624DA10.8000905@oracle.com> <5625E46C.3090106@oracle.com> <5625F943.1050804@oracle.com> Message-ID: <56263A9F.2000503@oracle.com> On 2015-10-20 10:20, Erik Joelsson wrote: > Hello, > > New webrevs implementing the suggestion by Magnus. > > Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.02/ > Webrev JDK 8u: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.02/ Looks good. This version was even better than I imagined it would be. Thanks! /Magnus > > /Erik > > On 2015-10-20 08:51, Magnus Ihse Bursie wrote: >> On 2015-10-19 13:54, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this minor configure fix. The logic in configure for >>> setting up proper mx flags for the bootjdk is flawed in that it >>> assumes a 64bit bootjdk if the build machine is 64bit. This patch >>> fixes this by instead testing if the bootjdk is 64bit or not. The >>> problem was discovered in 8u and is causing trouble for certain >>> build setups there. Since it also applies to 9, I'm posting a webrev >>> for each, intending to fix this in both releases. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139813 >>> Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.01/ >>> Webrev JDK 8u: >>> http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.01/ >> >> The code seems correct. A suggestion, though: If you break out the >> 64-bit detection and wrap it in a MSG_CHECKING/RESULT pair, we can >> get a configure log result that indicates what kind of bootjdk we >> think we found. And it will be easier to do a 64-bit check elsewhere, >> should the need arise. >> >> /Magnus > From aph at redhat.com Tue Oct 20 13:06:09 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Oct 2015 14:06:09 +0100 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <56263A34.20203@oracle.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> <56263A34.20203@oracle.com> Message-ID: <56263C41.6000604@redhat.com> On 10/20/2015 01:57 PM, Magnus Ihse Bursie wrote: > What does x86_64-linux-gnux32 imply? Some sort of mix between 32 and 64-bit? I think that's a 32-bit ABI running on a 64-bit processor. https://en.wikipedia.org/wiki/X32_ABI If so, I'm surprised it works at all. Andrew. From magnus.ihse.bursie at oracle.com Tue Oct 20 13:57:39 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 15:57:39 +0200 Subject: RFR: JDK-8139969 Fix unzip in compare.sh broken by JDK-8136813 Message-ID: <56264853.6040806@oracle.com> Unfortunately the logging of compare.sh introduced in JDK-8136813 broke unzip. In JDK-8136813 we started exportin the shell variable UNZIP, which contains the path to UNZIP. Unfortunately, UNZIP is interpreted by UNZIP as a variable containing extra options to add to the command line. Bug: https://bugs.openjdk.java.net/browse/JDK-8139969 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8139969-fix-unzip-in-compare/webrev.01 /Magnus From erik.helin at oracle.com Tue Oct 20 14:05:35 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 20 Oct 2015 16:05:35 +0200 Subject: RFR: 8139272: Add configure variable to set concurrency for jtreg tests In-Reply-To: <561E4E83.4090502@oracle.com> References: <20151009120947.GU14241@ehelin.jrpg.bea.com> <561E4E83.4090502@oracle.com> Message-ID: <20151020140535.GG15817@ehelin.jrpg.bea.com> On 2015-10-14, Magnus Ihse Bursie wrote: > On 2015-10-09 14:09, Erik Helin wrote: > >Hi all, > > > >this patch adds a new configure variable: --with-test-jobs. The new > >variable configures how many tests jobs we run concurrently (aka the > >-concurrency flag to JTReg). Today --with-jobs is passed as the > >-concurrency flag to JTReg which most likely is too big for most > >systems with many cores. > > > >For hotspot, the only "supported" configuration for running the jtreg > >tests is with -concurrency:1. However, most machines will run the tests > >successfully with more concurrency, but I used a default of 1. For the JDK > >tests I kept --with-jobs as the default concurrency since I want to keep > >the old behaviour. > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8139272 > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8139272/webrev.00/ > > Hi Erik, > > Your patch looks basically sound. Thanks for reviewing! > A few comments: > > * It would be good if you could add a comment somewhere, perhaps in the new > function in build-performance.m4, that "0" test jobs means "let the test > system use the default". Fixed. > * You should add TEST_JOBS to the list of INIT_CONTROL_VARIABLES in > InitSupport.gmk, to stop make from complaining on it. Fixed. > * Also, it would be great if you updated the help message in Help.gmk to > include TEST_JOBS. Fixed. Please see new webrevs: - Incremental: http://cr.openjdk.java.net/~ehelin/8139272/webrev.00-01/ - Full: http://cr.openjdk.java.net/~ehelin/8139272/webrev.01/ Thanks, Erik > /Magnus From erik.helin at oracle.com Tue Oct 20 14:10:51 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 20 Oct 2015 16:10:51 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests In-Reply-To: References: <20151009122344.GV14241@ehelin.jrpg.bea.com> Message-ID: <20151020141051.GH15817@ehelin.jrpg.bea.com> On 2015-10-09, Magnus Ihse Bursie wrote: > Looks good to me. Thanks! Erik > /Magnus > > > 9 okt 2015 kl. 14:23 skrev Erik Helin : > > > > Hi all, > > > > this patch adds a new top-level Makefile to run the hotspot jtreg tests. > > This is already possible today by running: > > $ make test TEST="hotspot_all" > > > > The new target, test-hotspot-jtreg, is a bit more discoverable in my > > opinion (will also work with tab completion in supported shells). > > > > Enhancement: > > https://bugs.openjdk.java.net/browse/JDK-8139271 > > > > Webrev: > > http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ > > > > Thanks, > > Erik From erik.helin at oracle.com Tue Oct 20 14:11:05 2015 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 20 Oct 2015 16:11:05 +0200 Subject: RFR: 8139271: Add top-level Makefile target to run hotspots jtreg tests In-Reply-To: <5617B965.7080805@oracle.com> References: <20151009122344.GV14241@ehelin.jrpg.bea.com> <5617B965.7080805@oracle.com> Message-ID: <20151020141105.GI15817@ehelin.jrpg.bea.com> On 2015-10-09, Erik Joelsson wrote: > Looks good to me. Thanks! Erik > /Erik > > On 2015-10-09 14:23, Erik Helin wrote: > >Hi all, > > > >this patch adds a new top-level Makefile to run the hotspot jtreg tests. > >This is already possible today by running: > >$ make test TEST="hotspot_all" > > > >The new target, test-hotspot-jtreg, is a bit more discoverable in my > >opinion (will also work with tab completion in supported shells). > > > >Enhancement: > >https://bugs.openjdk.java.net/browse/JDK-8139271 > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8139271/webrev.00/ > > > >Thanks, > >Erik > From erik.joelsson at oracle.com Tue Oct 20 14:33:38 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 20 Oct 2015 16:33:38 +0200 Subject: RFR: JDK-8139969 Fix unzip in compare.sh broken by JDK-8136813 In-Reply-To: <56264853.6040806@oracle.com> References: <56264853.6040806@oracle.com> Message-ID: <562650C2.6010101@oracle.com> Looks good to me. /Erik On 2015-10-20 15:57, Magnus Ihse Bursie wrote: > Unfortunately the logging of compare.sh introduced in JDK-8136813 > broke unzip. > > In JDK-8136813 we started exportin the shell variable UNZIP, which > contains the path to UNZIP. Unfortunately, UNZIP is interpreted by > UNZIP as a variable containing extra options to add to the command line. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139969 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8139969-fix-unzip-in-compare/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Oct 20 14:48:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 20 Oct 2015 16:48:59 +0200 Subject: [patch] correctly detect 32bit platforms In-Reply-To: <56254F83.2040801@ubuntu.com> References: <56254F83.2040801@ubuntu.com> Message-ID: <5626545B.1040206@oracle.com> On 2015-10-19 22:16, Matthias Klose wrote: > Sorry if this is the wrong ML, but this results in hotspot build > failures on various 32bit zero targets. As you're probably aware by now, build questions should be directed to build-dev at openjdk.java.net. :-) > > common/autoconf/boot-jdk.m4 uses BUILD_NUM_BITS to check for > 32bit-ness, however this is nowhere defined. the current macro seems > to be OPENJDK_BUILD_CPU_BITS. As it happens, the very same code currently has a patch pending for review, https://bugs.openjdk.java.net/browse/JDK-8139813. This patch will remove BUILD_NUM_BITS, and instead test if the bootjdk itself is 32 or 64-bit, which is what we actually want to test. /Magnus From tim.bell at oracle.com Tue Oct 20 15:16:34 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 20 Oct 2015 08:16:34 -0700 Subject: [8u] RFR: JDK-8139813: Base heap size on type of boot jdk, not architecture of build machine In-Reply-To: <56263A9F.2000503@oracle.com> References: <5624DA10.8000905@oracle.com> <5625E46C.3090106@oracle.com> <5625F943.1050804@oracle.com> <56263A9F.2000503@oracle.com> Message-ID: <56265AD2.2030003@oracle.com> On 10/20/15 05:59, Magnus Ihse Bursie wrote: > On 2015-10-20 10:20, Erik Joelsson wrote: >> Hello, >> >> New webrevs implementing the suggestion by Magnus. >> >> Webrev JDK 9: http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.02/ >> Webrev JDK 8u: >> http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.02/ > Looks good. This version was even better than I imagined it would be. > Thanks! > > /Magnus Very nice. Looks good to me as well - both the 9 and 8u versions. Tim >> /Erik >> >> On 2015-10-20 08:51, Magnus Ihse Bursie wrote: >>> On 2015-10-19 13:54, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this minor configure fix. The logic in configure for >>>> setting up proper mx flags for the bootjdk is flawed in that it >>>> assumes a 64bit bootjdk if the build machine is 64bit. This patch >>>> fixes this by instead testing if the bootjdk is 64bit or not. The >>>> problem was discovered in 8u and is causing trouble for certain >>>> build setups there. Since it also applies to 9, I'm posting a >>>> webrev for each, intending to fix this in both releases. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139813 >>>> Webrev JDK 9: >>>> http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk9.01/ >>>> Webrev JDK 8u: >>>> http://cr.openjdk.java.net/~erikj/8139813/webrev.jdk8u.01/ >>> >>> The code seems correct. A suggestion, though: If you break out the >>> 64-bit detection and wrap it in a MSG_CHECKING/RESULT pair, we can >>> get a configure log result that indicates what kind of bootjdk we >>> think we found. And it will be easier to do a 64-bit check >>> elsewhere, should the need arise. >>> >>> /Magnus >> > From tim.bell at oracle.com Tue Oct 20 15:19:01 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 20 Oct 2015 08:19:01 -0700 Subject: RFR: JDK-8139951 Do not store debug level in OPT part of Verona string In-Reply-To: <56260D38.2000107@oracle.com> References: <56260524.1020506@oracle.com> <56260D38.2000107@oracle.com> Message-ID: <56265B65.9010309@oracle.com> Looks good to me as well. /Tim On 10/20/15 02:45, Erik Joelsson wrote: > Looks good to me. Nice to see all that nastiness disappear. > > /Erik > > On 2015-10-20 11:11, Magnus Ihse Bursie wrote: >> After discussion, it was decided that debug level information should >> not be a part of the new version string as implemented in Verona. >> Instead, this information should be propagated using other means. >> (Follow-up bugs will be filed for this). >> >> This bug removes the debug-level from the opt part of the version >> string. >> >> Note that this fix will be pushed to verona/stage. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8139951 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8139951-no-debug-in-opt-for-verona/webrev.01 >> >> /Magnus >> > From christian.thalinger at oracle.com Tue Oct 20 20:19:41 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 20 Oct 2015 10:19:41 -1000 Subject: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes Message-ID: https://bugs.openjdk.java.net/browse/JDK-8139935 The reason this ?works? for a non-bootcycle build is because a JDK 9 javac won't enforce the ?hidden packages? rules when running on a non-JDK 9 platform. diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk Sat Oct 17 19:40:30 2015 -0400 +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk Tue Oct 20 09:57:02 2015 -1000 @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \ $(MKDIR) -p $(@D) $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) $(JAVA_SMALL) $(NEW_JAVAC) \ + -XDignore.symbol.file \ -sourcepath $(SOURCEPATH) \ -implicit:none \ -proc:only \ From david.holmes at oracle.com Wed Oct 21 02:03:59 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Oct 2015 12:03:59 +1000 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <56263013.5050107@ubuntu.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> Message-ID: <5626F28F.1010800@oracle.com> On 20/10/2015 10:14 PM, Matthias Klose wrote: > On 20.10.2015 09:36, David Holmes wrote: >>> On 20/10/2015 6:50 AM, Matthias Klose wrote: >>>> I'm working around some build failures for zero targets, which fail to >>>> build because the configury in openjdk tries to set -m32/-m64 on it's >>>> own. I assume this behaviour was added for sun/oracle product >>>> builds to >>>> build x86 and x86_64 targets on a x86_64 platform. The issue is that >>>> the current configury checks if -m32/-m64 works with the current >>>> compiler, and then enables it without losses. This breaks at least on >>>> the x86_64-linux-gnux32 target. I assume it will break on other >>>> targets >>>> as well, which don't recognize -m32/-m64, but usually use other options >>>> like -mabi=. Instead of hard-coding these flags for every >>>> architecture, is there any chance for not passing these flags at all >>>> for >>>> the default mode? >> >> Part of the problem is that the default mode is not known ahead of >> time, your >> gcc on your x64 system might be configured to build 32-bit by default. > > is this really a common configuration? I don't know any Linux > distribution shipping such a compiler. The one possibility for a 32bit > toolchain on a 64bit host might be a x86 chroot created on a x86_64 > host. But usually such build environments are entered with a 32bit > personality (see linux32(1)), hiding anything build related from the host. > > I would expect that the default mode is passed in some way as autoconf > option, or by setting CC="gcc -m64" (the latter unfortunately not > working because CC is expected to be a file name in some places). The default is to assume you want a build that matches the architecture of the build platform. Configure options can change that - eg --with-target-bits=32 request a 32-bit build on a 64-bit system. That in turn should cause the correct flags to be passed to the compiler to get the desired result. If -m32/-m64 are not the right flags for a given compiler then we may have to look at that, but we have a set of supported compilers and can't try to handle every possibility. >> If there is a better way to select this than -m32/-m64 then I'm happy >> to hear >> it, but not sure if -march/-mabi gives us anything better on x86. What >> exactly >> would you propose? > > I'm not proposing to use -march/-mabi instead, but just avoiding > -m32/-m64 at all, unless you explicitly configure for it (e.g. > --with-abi= ?). That may be possible. David > Matthias > From erik.joelsson at oracle.com Wed Oct 21 07:51:09 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Oct 2015 09:51:09 +0200 Subject: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes In-Reply-To: References: Message-ID: <562743ED.1090807@oracle.com> Looks good to me. /Erik On 2015-10-20 22:19, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8139935 > > The reason this ?works? for a non-bootcycle build is because a JDK 9 javac won't enforce the ?hidden packages? rules when running on a non-JDK 9 platform. > > diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk > --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk Sat Oct 17 19:40:30 2015 -0400 > +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk Tue Oct 20 09:57:02 2015 -1000 > @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \ > $(MKDIR) -p $(@D) > $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) > $(JAVA_SMALL) $(NEW_JAVAC) \ > + -XDignore.symbol.file \ > -sourcepath $(SOURCEPATH) \ > -implicit:none \ > -proc:only \ > From volker.simonis at gmail.com Wed Oct 21 09:43:17 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 21 Oct 2015 11:43:17 +0200 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <56263013.5050107@ubuntu.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> Message-ID: On Tue, Oct 20, 2015 at 2:14 PM, Matthias Klose wrote: > On 20.10.2015 09:36, David Holmes wrote: >>> >>> On 20/10/2015 6:50 AM, Matthias Klose wrote: >>>> >>>> I'm working around some build failures for zero targets, which fail to >>>> build because the configury in openjdk tries to set -m32/-m64 on it's >>>> own. I assume this behaviour was added for sun/oracle product builds to >>>> build x86 and x86_64 targets on a x86_64 platform. The issue is that >>>> the current configury checks if -m32/-m64 works with the current >>>> compiler, and then enables it without losses. This breaks at least on >>>> the x86_64-linux-gnux32 target. I assume it will break on other targets >>>> as well, which don't recognize -m32/-m64, but usually use other options >>>> like -mabi=. Instead of hard-coding these flags for every >>>> architecture, is there any chance for not passing these flags at all for >>>> the default mode? >> >> >> Part of the problem is that the default mode is not known ahead of time, >> your >> gcc on your x64 system might be configured to build 32-bit by default. > > > is this really a common configuration? I don't know any Linux distribution > shipping such a compiler. The one possibility for a 32bit toolchain on a > 64bit host might be a x86 chroot created on a x86_64 host. But usually such > build environments are entered with a 32bit personality (see linux32(1)), > hiding anything build related from the host. > On SLES 10 on Linux/ppc64 for whatever reason the default version of GCC is configured to build 32-bit binaries by default (although we are on a 64-bit platform). I think that was changed in newer releases but for building on SLES 10 (what we still do) '-m64' is required. > I would expect that the default mode is passed in some way as autoconf > option, or by setting CC="gcc -m64" (the latter unfortunately not working > because CC is expected to be a file name in some places). > >> If there is a better way to select this than -m32/-m64 then I'm happy to >> hear >> it, but not sure if -march/-mabi gives us anything better on x86. What >> exactly >> would you propose? > > > I'm not proposing to use -march/-mabi instead, but just avoiding -m32/-m64 > at all, unless you explicitly configure for it (e.g. --with-abi= > ?). > > Matthias > From coleen.phillimore at oracle.com Wed Oct 21 15:43:49 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Oct 2015 11:43:49 -0400 Subject: linux_i586_2.6-productEmb.log Message-ID: <5627B2B5.9010801@oracle.com> Hi, Does anyone know how to build this on a linux x64 system with the 32 bit libraries installed? Ie. the magic flags to 'configure' etc? I fail this in JPRT and want to locally figure out why. thanks, Coleen From erik.joelsson at oracle.com Wed Oct 21 16:16:04 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 21 Oct 2015 18:16:04 +0200 Subject: linux_i586_2.6-productEmb.log In-Reply-To: <5627B2B5.9010801@oracle.com> References: <5627B2B5.9010801@oracle.com> Message-ID: <5627BA44.5030905@oracle.com> Hello, The important ones are: --with-target-bits=32 --with-jvm-variants=client,server,minimal1 --with-jdk-variant=embedded I also recommend adding: --with-devkit=/java/devtools/linux/devkit/gcc4.8.2-OEL5.5 if you have that available, or if your forest has been updated to use the new devkit version, gcc4.9.2-OEL6.4. /Erik On 2015-10-21 17:43, Coleen Phillimore wrote: > Hi, > Does anyone know how to build this on a linux x64 system with the 32 > bit libraries installed? > Ie. the magic flags to 'configure' etc? I fail this in JPRT and want > to locally figure out why. > > thanks, > Coleen From coleen.phillimore at oracle.com Wed Oct 21 18:03:31 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 21 Oct 2015 14:03:31 -0400 Subject: linux_i586_2.6-productEmb.log In-Reply-To: <5627BA44.5030905@oracle.com> References: <5627B2B5.9010801@oracle.com> <5627BA44.5030905@oracle.com> Message-ID: <5627D373.4020606@oracle.com> Thank you!! Coleen On 10/21/15 12:16 PM, Erik Joelsson wrote: > Hello, > > The important ones are: > > --with-target-bits=32 --with-jvm-variants=client,server,minimal1 > --with-jdk-variant=embedded > > I also recommend adding: > > --with-devkit=/java/devtools/linux/devkit/gcc4.8.2-OEL5.5 > > if you have that available, or if your forest has been updated to use > the new devkit version, gcc4.9.2-OEL6.4. > > /Erik > > On 2015-10-21 17:43, Coleen Phillimore wrote: >> Hi, >> Does anyone know how to build this on a linux x64 system with the 32 >> bit libraries installed? >> Ie. the magic flags to 'configure' etc? I fail this in JPRT and want >> to locally figure out why. >> >> thanks, >> Coleen > From christian.thalinger at oracle.com Wed Oct 21 18:22:34 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Oct 2015 08:22:34 -1000 Subject: RFR (XXS): 8139935: Bootcycle builds are broken on jdk9/hs due to JVMCI changes In-Reply-To: <562743ED.1090807@oracle.com> References: <562743ED.1090807@oracle.com> Message-ID: Thanks, Erik. > On Oct 20, 2015, at 9:51 PM, Erik Joelsson wrote: > > Looks good to me. > > /Erik > > On 2015-10-20 22:19, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8139935 >> >> The reason this ?works? for a non-bootcycle build is because a JDK 9 javac won't enforce the ?hidden packages? rules when running on a non-JDK 9 platform. >> >> diff -r a8a8604f890f make/gensrc/Gensrc-jdk.vm.ci.gmk >> --- a/make/gensrc/Gensrc-jdk.vm.ci.gmk Sat Oct 17 19:40:30 2015 -0400 >> +++ b/make/gensrc/Gensrc-jdk.vm.ci.gmk Tue Oct 20 09:57:02 2015 -1000 >> @@ -77,6 +77,7 @@ PROCESSOR_PATH := $(call PathList, \ >> $(MKDIR) -p $(@D) >> $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) >> $(JAVA_SMALL) $(NEW_JAVAC) \ >> + -XDignore.symbol.file \ >> -sourcepath $(SOURCEPATH) \ >> -implicit:none \ >> -proc:only \ >> > From christian.thalinger at oracle.com Wed Oct 21 19:46:21 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Wed, 21 Oct 2015 09:46:21 -1000 Subject: RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug Message-ID: https://bugs.openjdk.java.net/browse/JDK-8140091 http://cr.openjdk.java.net/~twisti/8140091/webrev/ There is a bit more context in JIRA but the bottom line is that we shouldn?t be building the JDK with GCC 4.1.1. We have a workaround in just one place but that doesn?t mean the bug doesn?t show up in other places (especially new code). I?m suggesting to remove the workaround and blacklist this particular GCC version. From magnus.ihse.bursie at oracle.com Wed Oct 21 21:56:34 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 21 Oct 2015 23:56:34 +0200 Subject: RFR: JDK-8140277 Configuration out-of-date check should also check closed sources Message-ID: <56280A12.5060301@oracle.com> In Init.gmk, there is a check if the configure source code has changes. If so, the configuration is out of date and not usable. This check should be extended to the closed configuration sources (if present), not only open. The CUSTOM_CONFIG_DIR is the same as what's being used in common/autoconf/configure and common/autoconf/autogen.sh. Bug: https://bugs.openjdk.java.net/browse/JDK-8140277 Patch inline: diff --git a/make/Init.gmk b/make/Init.gmk --- a/make/Init.gmk +++ b/make/Init.gmk @@ -137,7 +137,9 @@ # The spec files depend on the autoconf source code. This check makes sure # the configuration is up to date after changes to configure. - $(SPECS): $(wildcard $(topdir)/common/autoconf/*) + CUSTOM_CONFIG_DIR ?= $(topdir)/closed/autoconf + + $(SPECS): $(wildcard $(topdir)/common/autoconf/*) $(wildcard $(CUSTOM_CONFIG_DIR)/*) ifeq ($(CONF_CHECK), fail) @echo "Error: The configuration is not up to date for '$(lastword $(subst /, , $(dir $@)))'." $(call PrintConfCheckFailed) /Magnus From magnus.ihse.bursie at oracle.com Wed Oct 21 23:56:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 22 Oct 2015 01:56:06 +0200 Subject: RFR: JDK-8140282 Remove test directories on clean-test-* Message-ID: <56282616.9010808@oracle.com> Using some makefile magic, we transform clean-test-foo-bar-baz into a call to "rm -r $b/support/test/foo/bar/baz". However, this might leave a chain of empty directories $b/support/test/foo/bar, which is not so nice. We should remove these directories as well, if there is no other content in them. Bug: https://bugs.openjdk.java.net/browse/JDK-8140282 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8140282-remove-test-directories/webrev.01 /Magnus From martinrb at google.com Thu Oct 22 00:28:26 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 21 Oct 2015 17:28:26 -0700 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> Message-ID: I agree that configure should try to invoke "the compiler" without any flags by default, but make it easy for users to supply them. If some platform like SLES 10 on Linux/ppc64 wants to build 32-bit binaries, assume that this is intended and let it go ahead! Don't just assume the distro maintainers are wrong. I have some sympathy for the idea that "32-bit ought to be enough for everybody", and if it's not, switch to 64-bit then. The main reason to build everything 64-bit is simple avoidance of confusion and replication of runtime environments. From volker.simonis at gmail.com Thu Oct 22 06:39:37 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 22 Oct 2015 08:39:37 +0200 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <56263C41.6000604@redhat.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> <56263A34.20203@oracle.com> <56263C41.6000604@redhat.com> Message-ID: I only now took a look at the what x86_64-linux-gnux32 really means (thanks Andrew for providing the link). So independently of the discussed build issues I doubt that this currently really makes sense for the OpenJDK. The VM is simply not aware of the new ABI so all the generated code (interpreter, JIT) won't use the extra registers anyway. I also suspect there could be calling conventions problems from generated to native code. Making all this work is a much bigger effort than just passing the right flags to the compiler. On Tue, Oct 20, 2015 at 3:06 PM, Andrew Haley wrote: > On 10/20/2015 01:57 PM, Magnus Ihse Bursie wrote: >> What does x86_64-linux-gnux32 imply? Some sort of mix between 32 and 64-bit? > > I think that's a 32-bit ABI running on a 64-bit processor. > > https://en.wikipedia.org/wiki/X32_ABI > > If so, I'm surprised it works at all. > > Andrew. > From erik.joelsson at oracle.com Thu Oct 22 08:57:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Oct 2015 10:57:20 +0200 Subject: RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug In-Reply-To: References: Message-ID: <5628A4F0.40208@oracle.com> I think this is ok, but we should make sure to add a check in configure in the hotspot build-infra project. /Erik On 2015-10-21 21:46, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8140091 > http://cr.openjdk.java.net/~twisti/8140091/webrev/ > > There is a bit more context in JIRA but the bottom line is that we shouldn?t be building the JDK with GCC 4.1.1. We have a workaround in just one place but that doesn?t mean the bug doesn?t show up in other places (especially new code). > > I?m suggesting to remove the workaround and blacklist this particular GCC version. From magnus.ihse.bursie at oracle.com Thu Oct 22 10:01:51 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 22 Oct 2015 12:01:51 +0200 Subject: [patch] fix the build with a toolchain with a linker defaulting to ld --as-needed In-Reply-To: <5625FB24.60609@oracle.com> References: <56254D37.3090903@ubuntu.com> <5625FB24.60609@oracle.com> Message-ID: <5628B40F.5010605@oracle.com> On 2015-10-20 10:28, Erik Joelsson wrote: > Hello Matthias, > > I think this looks good and can sponsor the push for you. Have you > signed the OCA? The patch looks good to me to. /Magnus > > /Erik > > On 2015-10-19 22:06, Matthias Klose wrote: >> Toolchains for some Linux distributions (e.g. Ubuntu, OpenSuse) are >> configured to pass --as-needed to the linker by default, only linking >> with libraries when required. A common build failure triggered by >> this default is having a required library on the command line before >> the object files being linked. This happens when linking with a >> system zlib or system jpeg library. >> >> Patch is attached, checked with b87. >> >> There is one unrelated change, removing the explicit linking with the >> C library. Is there any reason to keep that? >> >> Matthias >> >> > From erik.joelsson at oracle.com Thu Oct 22 10:38:23 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Oct 2015 12:38:23 +0200 Subject: RFR: JDK-8140312: Enable new sjavac server only mode in jdk build Message-ID: <5628BC9F.6080206@oracle.com> In JDK-8135131, sjavac added a thin server mode, in which only the server part of sjavac is used for running plain javac. This patch adds a configure option to enable this mode of running to the jdk build. Later, if it seems to work well, we will consider making it default. On my workstation (linux) running the default make target went from about 4m55s to 4m05s when activating this. Bug: https://bugs.openjdk.java.net/browse/JDK-8140312 Webrev: http://cr.openjdk.java.net/~erikj/8140312/webrev.01/index.html /Erik From erik.joelsson at oracle.com Thu Oct 22 13:45:44 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Oct 2015 15:45:44 +0200 Subject: RFR: JDK-8140277 Configuration out-of-date check should also check closed sources In-Reply-To: <56280A12.5060301@oracle.com> References: <56280A12.5060301@oracle.com> Message-ID: <5628E888.5040303@oracle.com> Looks good to me. /Erik On 2015-10-21 23:56, Magnus Ihse Bursie wrote: > In Init.gmk, there is a check if the configure source code has > changes. If so, the configuration is out of date and not usable. > > This check should be extended to the closed configuration sources (if > present), not only open. > > The CUSTOM_CONFIG_DIR is the same as what's being used in > common/autoconf/configure and common/autoconf/autogen.sh. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140277 > > Patch inline: > diff --git a/make/Init.gmk b/make/Init.gmk > --- a/make/Init.gmk > +++ b/make/Init.gmk > @@ -137,7 +137,9 @@ > > # The spec files depend on the autoconf source code. This check > makes sure > # the configuration is up to date after changes to configure. > - $(SPECS): $(wildcard $(topdir)/common/autoconf/*) > + CUSTOM_CONFIG_DIR ?= $(topdir)/closed/autoconf > + > + $(SPECS): $(wildcard $(topdir)/common/autoconf/*) $(wildcard > $(CUSTOM_CONFIG_DIR)/*) > ifeq ($(CONF_CHECK), fail) > @echo "Error: The configuration is not up to date for > '$(lastword $(subst /, , $(dir $@)))'." > $(call PrintConfCheckFailed) > > /Magnus From erik.joelsson at oracle.com Thu Oct 22 13:57:13 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Oct 2015 15:57:13 +0200 Subject: RFR: JDK-8140282 Remove test directories on clean-test-* In-Reply-To: <56282616.9010808@oracle.com> References: <56282616.9010808@oracle.com> Message-ID: <5628EB39.10704@oracle.com> Looks good to me. /Erik On 2015-10-22 01:56, Magnus Ihse Bursie wrote: > Using some makefile magic, we transform clean-test-foo-bar-baz into a > call to "rm -r $b/support/test/foo/bar/baz". > > However, this might leave a chain of empty directories > $b/support/test/foo/bar, which is not so nice. We should remove these > directories as well, if there is no other content in them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140282 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8140282-remove-test-directories/webrev.01 > > /Magnus > From christian.thalinger at oracle.com Thu Oct 22 17:50:17 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 22 Oct 2015 07:50:17 -1000 Subject: RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug In-Reply-To: <5628A4F0.40208@oracle.com> References: <5628A4F0.40208@oracle.com> Message-ID: <365D4DCB-0766-48D6-9BD2-956D182F0EAD@oracle.com> > On Oct 21, 2015, at 10:57 PM, Erik Joelsson wrote: > > I think this is ok, but we should make sure to add a check in configure in the hotspot build-infra project. Yes, we should do that. I was looking for something like this but couldn?t find any code so I went ahead and did it in the HotSpot Makefiles. Do you want to add a check in configure with this bug or a separate one? > > /Erik > > On 2015-10-21 21:46, Christian Thalinger wrote: >> https://bugs.openjdk.java.net/browse/JDK-8140091 >> http://cr.openjdk.java.net/~twisti/8140091/webrev/ >> >> There is a bit more context in JIRA but the bottom line is that we shouldn?t be building the JDK with GCC 4.1.1. We have a workaround in just one place but that doesn?t mean the bug doesn?t show up in other places (especially new code). >> >> I?m suggesting to remove the workaround and blacklist this particular GCC version. > From vladimir.kozlov at oracle.com Thu Oct 22 23:11:14 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 23 Oct 2015 07:11:14 +0800 Subject: RFR (S): 8140091: remove VMStructs cast_uint64_t workaround for GCC 4.1.1 bug In-Reply-To: References: Message-ID: <56296D12.9040602@oracle.com> Hotspot changes looks fine. I was surprise that code was added long ago. Thanks, Vladimir On 10/22/15 3:46 AM, Christian Thalinger wrote: > https://bugs.openjdk.java.net/browse/JDK-8140091 > http://cr.openjdk.java.net/~twisti/8140091/webrev/ > > There is a bit more context in JIRA but the bottom line is that we shouldn?t be building the JDK with GCC 4.1.1. We have a workaround in just one place but that doesn?t mean the bug doesn?t show up in other places (especially new code). > > I?m suggesting to remove the workaround and blacklist this particular GCC version. > From peter.brunet at oracle.com Fri Oct 23 14:27:42 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 23 Oct 2015 09:27:42 -0500 Subject: unknown source Message-ID: <562A43DE.6000302@oracle.com> What do I need to do so the dumps know where the source is? -Pete Exception in thread "Thread-2" java.lang.RuntimeException: java.lang.NullPointer Exception at com.sun.java.accessibility.AccessBridge$InvocationUtils.invokeAndWait(AccessBridge.java:7202) at com.sun.java.accessibility.AccessBridge$InvocationUtils.invokeAndWait(AccessBridge.java:7177) at com.sun.java.accessibility.AccessBridge.getAccessibleStatesStringFromContext(AccessBridge.java:1492) at com.sun.java.accessibility.AccessBridge.runDLL(Native Method) at com.sun.java.accessibility.AccessBridge.access$300(AccessBridge.java:57) at com.sun.java.accessibility.AccessBridge$dllRunner.run(AccessBridge.java:141) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NullPointerException at javax.swing.plaf.synth.SynthComboBoxUI.shouldActLikeButton(Unknown Source) at javax.swing.plaf.synth.SynthComboBoxUI.access$900(Unknown Source) at javax.swing.plaf.synth.SynthComboBoxUI$ButtonHandler.isArmed(Unknown Source) at javax.swing.AbstractButton$AccessibleAbstractButton.getAccessibleStateSet(Unknown Source) at com.sun.java.accessibility.AccessBridge$61.call(AccessBridge.java:1495) at com.sun.java.accessibility.AccessBridge$61.call(AccessBridge.java:1492) at com.sun.java.accessibility.AccessBridge$InvocationUtils$CallableWrapper.run(AccessBridge.java:7258) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$500(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source) From magnus.ihse.bursie at oracle.com Fri Oct 23 14:49:52 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Oct 2015 16:49:52 +0200 Subject: Outdated readme files in jdk9 repository In-Reply-To: <55CA3F68.70707@gmail.com> References: <55CA3F68.70707@gmail.com> Message-ID: <562A4910.4060803@oracle.com> On 2015-08-11 20:31, Anthony Vanelverdinghe wrote: > Hi > > While looking for README-builds.html, I came across the following > outdated README: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/README > An equally outdated file is in the langtools repository: > http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/tip/README > In my opinion, these should be updated, analog to what was done in the > other repositories (corba, hotspot, etc.) > > On a side note, the OpenJDK page of the build group [1] contains 2 > broken links: > > "OpenJDK7 Build README" should link to > http://hg.openjdk.java.net/jdk7u/jdk7u/raw-file/tip/README-builds.html > "OpenJDK8 Build README" should link to > http://hg.openjdk.java.net/jdk8u/jdk8u/raw-file/tip/README-builds.html > > And it might also be useful to add a link for OpenJDK9: > http://hg.openjdk.java.net/jdk9/jdk9/raw-file/tip/README-builds.html Hi Anthony, I apolize for the long overdue reply. Thanks for your problem report, and assistance in providing correct links! I have now updated the build web page. Regarding the jdk README file: Funny, I've never even noticed that it existed. :-) I agree that it is not up to date. In fact, none of the sub-repo README files seems fully up to date. I believe they should do nothing more than to point to the top-level build README. I have created https://bugs.openjdk.java.net/browse/JDK-8140394 to track this. /Magnus From magnus.ihse.bursie at oracle.com Fri Oct 23 14:56:31 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Oct 2015 16:56:31 +0200 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> Message-ID: <562A4A9F.7010700@oracle.com> On 2015-10-22 02:28, Martin Buchholz wrote: > I agree that configure should try to invoke "the compiler" without any > flags by default, but make it easy for users to supply them. If some > platform like SLES 10 on Linux/ppc64 wants to build 32-bit binaries, assume > that this is intended and let it go ahead! Don't just assume the distro > maintainers are wrong. I have some sympathy for the idea that "32-bit > ought to be enough for everybody", and if it's not, switch to 64-bit then. > The main reason to build everything 64-bit is simple avoidance of confusion > and replication of runtime environments. The problem here is that we can't just compile the native libraries as 32 bits, without the rest of the build (java, hotspot etc) knowing about it. That's why configure takes this stance, "tell me if you want 32 or 64 bits, and I'll fix it for you" (and the default being the same number of bits as the build platform). If we really wanted to follow through on that idea, we'd have to query the compiler to see what it thinks is default. But I'm not sure that really makes sense, letting whatever the distro maintainer thought gcc should provide as default be what dictates whether we create a JVM that's 32 or 64 bit. It might make sense, though, to not push a -m32/-m64 on all compile lines if it's not needed. But then we'd have to verify at configure time what kind of output the compiler produces as default, and add this flag according to if it behaves as expected or not. /Magnus From magnus.ihse.bursie at oracle.com Fri Oct 23 15:13:09 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Oct 2015 17:13:09 +0200 Subject: Building jdk9 on Windows x64 and Visual Studio 2015 Community edition In-Reply-To: <56056e96.a558c20a.d796d.486a@mx.google.com> References: <56056e96.a558c20a.d796d.486a@mx.google.com> Message-ID: <562A4E85.9070004@oracle.com> On 2015-09-25 17:55, timo.kinnunen at gmail.com wrote: > Hi, > > I?ve been going over the Windows build of the whole JDK for a while with VS 2015 and now I have patches that allow the build to complete. > > I?ve made changes in the root repository as well as in hotspot and jdk repositories. The changes fall broadly in three categories: enabling the v140 toolchain and improving freetype compilation, adding casts to where pointers are truncated and miscellaneous small-scale code changes. > > The patch to the root repository streamlines handling of freetype by implementing a default source directory at $HOME/freetype under Cygwin. It is checked during configure and used for compiling if ?--with-freetype-src? is not specified. A help message giving the unpacking command with the correct directory is also included. This patch is about 90 lines without counting generated-configure.sh changes. > > The patches to jdk and hotspot contain native code changes only and no changes to make-files. These are about 580 and 290 lines, respectively. All patches are generated with ?hg diff -g?. > > Would you be willing to incorporate these? How should I proceed with this? Hi Timo, First of all, I apologize that you have not recieved any response for far too long. :-( Thank you for your interest in helping to improve OpenJDK! In general, a patch to allow compilation on VS 2015 Community edition sounds like a good edition to OpenJDK. I am willing to sponsor this patch and help you work with getting it accepted. My first question to you is: have you signed the OCA? Also, unless you've done so already, reading http://openjdk.java.net/contribute/ is a good start for starting to contribute to OpenJDK. However, supporting a new compiler, without at the same time breaking an older one, can sometimes be tricky business. This means that you might need to iterate your patch a number of times, until it's suitable for inclusion. I don't want to scare you away, just be realistic up front that it might require some more work from your part (and our!). Also, (FYI, we have recently upgraded the compilers used at Oracle to VS2013 SP4, so I know what I'm talking about...) From what you write, I think you should try to separate the freetype-src default directory from the compiler upgrade settings. The former might be easier to start with, as it's less likely to be disruptive for anything else. Also, at this point, I think it would be helpful for me to be able to have an initial look at the patches. You need to be an OpenJDK Author to be able to access the OpenJDK infrastructure, so unfortunately that is not available to you. :-( For a first peek, the patches can be provided just about any way (but attachments to this list is unfortunately not allowed). For a final, proper, code review they need to reside on our infrastructure, but at that point I can help with fixing that. /Magnus From magnus.ihse.bursie at oracle.com Fri Oct 23 15:21:37 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 23 Oct 2015 17:21:37 +0200 Subject: RFR: JDK-8140312: Enable new sjavac server only mode in jdk build In-Reply-To: <5628BC9F.6080206@oracle.com> References: <5628BC9F.6080206@oracle.com> Message-ID: <562A5081.4070202@oracle.com> On 2015-10-22 12:38, Erik Joelsson wrote: > In JDK-8135131, sjavac added a thin server mode, in which only the > server part of sjavac is used for running plain javac. This patch adds > a configure option to enable this mode of running to the jdk build. > Later, if it seems to work well, we will consider making it default. > > On my workstation (linux) running the default make target went from > about 4m55s to 4m05s when activating this. Did that test really use the new sjavac server? :-) The code looks broken, in common/autoconf/build-performance.m4 you set ENABLE_SJAVAC and not ENABLE_JAVAC_SERVER in the new flag. Apart from that, it looks good. :) /Magnus From martijnverburg at gmail.com Sat Oct 24 22:58:23 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 24 Oct 2015 15:58:23 -0700 Subject: A couple of Build Issues (Mac OS X El Capitan / XCode 7.1) Message-ID: Hi all, I'm seeing a couple of issues when running make clean images (Configuration Summary is posted at the bottom): 1.) No rule to make CopyInterimCLDRConverter.gmk - this doesn't halt the build immediately, but looks suspicious. ...... Compiling 5 files for BUILD_GENMODULESLIST make[3]: CopyInterimCLDRConverter.gmk: No such file or directory make[3]: *** No rule to make target `CopyInterimCLDRConverter.gmk'. Stop. make[2]: *** [interim-cldrconverter] Error 2 make[2]: *** Waiting for unfinished jobs.... ...... 2.) An error due to a warning despite switching on --disable-warnings-as-errors .... /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:691:21: warning: 'ePtAttachDeprecated' is deprecated: PT_ATTACH is deprecated. See PT_ATTACHEXC [-Wdeprecated-declarations] if ((res = ptrace(PT_ATTACH, pid, 0, 0)) < 0) { ^ /usr/include/sys/ptrace.h:85:19: note: expanded from macro 'PT_ATTACH' #define PT_ATTACH ePtAttachDeprecated /* trace some running process */ ^ /usr/include/sys/ptrace.h:71:2: note: 'ePtAttachDeprecated' has been explicitly marked deprecated here ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is deprecated. See PT_ATTACHEXC") = 10 ^ 1 warning generated. .... ------------------ Configuration summary: * Debug level: release * HS debug level: product * JDK variant: normal * JVM variants: server * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 Tools summary: * Boot JDK: java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) (at /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home) * Toolchain: clang (clang/LLVM) * C Compiler: Version Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang) * C++ Compiler: Version Apple LLVM version 7.0.0 (clang-700.1.76) Target: x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang++) Build performance summary: * Cores to use: 4 * Memory limit: 16384 MB Cheers, Martijn From martijnverburg at gmail.com Sun Oct 25 22:48:27 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 25 Oct 2015 15:48:27 -0700 Subject: A couple of Build Issues (Mac OS X El Capitan / XCode 7.1) In-Reply-To: References: Message-ID: Nevermind, I wasn't building from the dev forest! Cheers, Martijn On 24 October 2015 at 15:58, Martijn Verburg wrote: > Hi all, > > I'm seeing a couple of issues when running make clean images > (Configuration Summary is posted at the bottom): > > 1.) No rule to make CopyInterimCLDRConverter.gmk - this doesn't halt the > build immediately, but looks suspicious. > > ...... > Compiling 5 files for BUILD_GENMODULESLIST > make[3]: CopyInterimCLDRConverter.gmk: No such file or directory > make[3]: *** No rule to make target `CopyInterimCLDRConverter.gmk'. Stop. > make[2]: *** [interim-cldrconverter] Error 2 > make[2]: *** Waiting for unfinished jobs.... > ...... > > 2.) An error due to a warning despite switching > on --disable-warnings-as-errors > > .... > /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:691:21: > warning: 'ePtAttachDeprecated' is deprecated: PT_ATTACH is deprecated. See > PT_ATTACHEXC [-Wdeprecated-declarations] > if ((res = ptrace(PT_ATTACH, pid, 0, 0)) < 0) { > ^ > /usr/include/sys/ptrace.h:85:19: note: expanded from macro 'PT_ATTACH' > #define PT_ATTACH ePtAttachDeprecated /* trace some running > process */ > ^ > /usr/include/sys/ptrace.h:71:2: note: 'ePtAttachDeprecated' has been > explicitly marked deprecated here > ePtAttachDeprecated __deprecated_enum_msg("PT_ATTACH is > deprecated. See PT_ATTACHEXC") = 10 > ^ > 1 warning generated. > .... > > ------------------ > > Configuration summary: > * Debug level: release > * HS debug level: product > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0_60" Java(TM) SE Runtime Environment > (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, > mixed mode) (at > /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home) > * Toolchain: clang (clang/LLVM) > * C Compiler: Version Apple LLVM version 7.0.0 (clang-700.1.76) > Target: x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang) > * C++ Compiler: Version Apple LLVM version 7.0.0 (clang-700.1.76) > Target: x86_64-apple-darwin15.0.0 Thread model: posix (at /usr/bin/clang++) > > Build performance summary: > * Cores to use: 4 > * Memory limit: 16384 MB > > Cheers, > Martijn > From ioi.lam at oracle.com Mon Oct 26 05:34:48 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 25 Oct 2015 22:34:48 -0700 Subject: RFR [XS] - 8139026 hotspot.script cannot handle command-line arguments with spaces Message-ID: <562DBB78.6090109@oracle.com> Please review a very small fix: http://cr.openjdk.java.net/~iklam/8139026-hotspot-script-arg-quoating/ Bug: hotspot/make/hotspot.script cannot handle command-line arguments with spaces https://bugs.openjdk.java.net/browse/JDK-8139026 Summary of fix: The old script was adding $@ to a string like X="A B $@ C". Doing that would lose the quotation on the arguments. This would cause JTREG to fail when running with Jigsaw modules (see bug report for details). The fix is to pass "$@" directly as arguments to all programs launched by hotspot.script Note that the fix does not address the problem with DBX, but at least it's no worse than before. Tests: I have used the modified version for the past 2 weeks with GDB and JTREG and found no issues. Also, casual testing shows the quotation is retained: $ hotspot 'a a' Error: Could not find or load main class a a $ hotspot "a' a" Error: Could not find or load main class a' a $ hotspot "a\"' a" Error: Could not find or load main class a"' a Thanks - Ioi From erik.joelsson at oracle.com Mon Oct 26 10:55:59 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Oct 2015 11:55:59 +0100 Subject: RFR: JDK-8140484: Vardeps broken when variable value contains '$' Message-ID: <562E06BF.1060405@oracle.com> When I optimized the vardeps functionality in JDK-8136385, I caused a regression when the variable contained '$' characters. By reading the old value as a makefile using "include", variable substitution is applied. To work around this, dollar characters need to be escaped (doubled) prior to printing the variable value to the vardeps makefile. This causes native libraries to be relinked every time they are incrementally built because of the "\$ORIGIN" string. Also updating tests to cover this. Bug: https://bugs.openjdk.java.net/browse/JDK-8140484 Webrev: http://cr.openjdk.java.net/~erikj/8140484/webrev.01/ /Erik From erik.joelsson at oracle.com Mon Oct 26 13:54:35 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 26 Oct 2015 14:54:35 +0100 Subject: RFR: JDK-8140312: Enable new sjavac server only mode in jdk build In-Reply-To: <562A5081.4070202@oracle.com> References: <5628BC9F.6080206@oracle.com> <562A5081.4070202@oracle.com> Message-ID: <562E309B.4040601@oracle.com> I send this review prematurely. Here is a new webrev, which has been properly tested. We had some test code compilations using the boot javac, which hadn't properly declared DISABLE_SJAVAC. The copy paste error in configure has also been corrected. On my workstation, running "make java" with hotspot already built, the speedup goes from 2:32 to 1:35. Running just "make" with the default target goes from about 4:05 to 3:10. Webrev: http://cr.openjdk.java.net/~erikj/8140312/webrev.02/ /Erik On 2015-10-23 17:21, Magnus Ihse Bursie wrote: > On 2015-10-22 12:38, Erik Joelsson wrote: >> In JDK-8135131, sjavac added a thin server mode, in which only the >> server part of sjavac is used for running plain javac. This patch >> adds a configure option to enable this mode of running to the jdk >> build. Later, if it seems to work well, we will consider making it >> default. >> >> On my workstation (linux) running the default make target went from >> about 4m55s to 4m05s when activating this. > > Did that test really use the new sjavac server? :-) The code looks > broken, in common/autoconf/build-performance.m4 you set ENABLE_SJAVAC > and not ENABLE_JAVAC_SERVER in the new flag. > > Apart from that, it looks good. :) > > /Magnus From tim.bell at oracle.com Mon Oct 26 14:08:23 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 26 Oct 2015 07:08:23 -0700 Subject: RFR: JDK-8140484: Vardeps broken when variable value contains '$' In-Reply-To: <562E06BF.1060405@oracle.com> References: <562E06BF.1060405@oracle.com> Message-ID: <562E33D7.3060106@oracle.com> Erik: > When I optimized the vardeps functionality in JDK-8136385, I caused a > regression when the variable contained '$' characters. By reading the > old value as a makefile using "include", variable substitution is > applied. To work around this, dollar characters need to be escaped > (doubled) prior to printing the variable value to the vardeps makefile. > > This causes native libraries to be relinked every time they are > incrementally built because of the "\$ORIGIN" string. > > Also updating tests to cover this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140484 > Webrev: http://cr.openjdk.java.net/~erikj/8140484/webrev.01/ Looks good to me. /Tim From tim.bell at oracle.com Mon Oct 26 14:17:22 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 26 Oct 2015 07:17:22 -0700 Subject: RFR: JDK-8140312: Enable new sjavac server only mode in jdk build In-Reply-To: <562E309B.4040601@oracle.com> References: <5628BC9F.6080206@oracle.com> <562A5081.4070202@oracle.com> <562E309B.4040601@oracle.com> Message-ID: <562E35F2.6090705@oracle.com> Hi Erik: Looks good to me. /Tim > I send this review prematurely. Here is a new webrev, which has been > properly tested. We had some test code compilations using the boot > javac, which hadn't properly declared DISABLE_SJAVAC. The copy paste > error in configure has also been corrected. > > On my workstation, running "make java" with hotspot already built, the > speedup goes from 2:32 to 1:35. Running just "make" with the default > target goes from about 4:05 to 3:10. > > Webrev: http://cr.openjdk.java.net/~erikj/8140312/webrev.02/ > > /Erik > > On 2015-10-23 17:21, Magnus Ihse Bursie wrote: >> On 2015-10-22 12:38, Erik Joelsson wrote: >>> In JDK-8135131, sjavac added a thin server mode, in which only the >>> server part of sjavac is used for running plain javac. This patch >>> adds a configure option to enable this mode of running to the jdk >>> build. Later, if it seems to work well, we will consider making it >>> default. >>> >>> On my workstation (linux) running the default make target went from >>> about 4m55s to 4m05s when activating this. >> >> Did that test really use the new sjavac server? :-) The code looks >> broken, in common/autoconf/build-performance.m4 you set ENABLE_SJAVAC >> and not ENABLE_JAVAC_SERVER in the new flag. >> >> Apart from that, it looks good. :) >> >> /Magnus > From omajid at redhat.com Mon Oct 26 17:30:34 2015 From: omajid at redhat.com (Omair Majid) Date: Mon, 26 Oct 2015 13:30:34 -0400 Subject: RFR: Typo in makefile changes for 8043805 [Allow using a system-installed libjpeg] In-Reply-To: <56255EE4.9050306@oracle.com> References: <562549C5.2070602@ubuntu.com> <56255EE4.9050306@oracle.com> Message-ID: <20151026173033.GB5289@redhat.com> (moving from jdk9-dev) Hi, I have created a webrev at: http://cr.openjdk.java.net/~omajid/webrevs/8139932-typo-makefile-jpeg/00/ Typo in makefile changes for 8043805 [Allow using a system-installed libjpeg] Reviewed-by: omajid, prr Contributed-by: Matthias Klose Regards, Omair * Philip Race [2015-10-19 17:22]: > I filed https://bugs.openjdk.java.net/browse/JDK-8139932 > > -phil. > > On 10/19/15, 12:51 PM, Matthias Klose wrote: > >till seen with b87. The current makefile has a typo, referencing the > >wrong file. > > > >Please create a ticket and a webrev. I don't have access to these tools. > > > >Matthias > > > >libjpeg-fix.diff > > > > > ># DP: Fix libjavajpeg build using the system jpeg library. > > > >Index: b/jdk/make/lib/Awt2dLibraries.gmk > >=================================================================== > >--- a/jdk/make/lib/Awt2dLibraries.gmk > >+++ b/jdk/make/lib/Awt2dLibraries.gmk > >@@ -476,7 +476,7 @@ endif > > ifeq ($(USE_EXTERNAL_LIBJPEG), true) > > LIBJPEG_LIBS := -ljpeg > > BUILD_LIBJAVAJPEG_INCLUDE_FILES := \ > >- imageIOJPEG.c \ > >+ imageioJPEG.c \ > > jpegdecoder.c > > BUILD_LIBJAVAJPEG_HEADERS := > > else -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From erik.joelsson at oracle.com Tue Oct 27 08:22:42 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 27 Oct 2015 09:22:42 +0100 Subject: RFR: Typo in makefile changes for 8043805 [Allow using a system-installed libjpeg] In-Reply-To: <20151026173033.GB5289@redhat.com> References: <562549C5.2070602@ubuntu.com> <56255EE4.9050306@oracle.com> <20151026173033.GB5289@redhat.com> Message-ID: <562F3452.80102@oracle.com> Looks good to me. /Erik On 2015-10-26 18:30, Omair Majid wrote: > (moving from jdk9-dev) > > Hi, > > I have created a webrev at: > http://cr.openjdk.java.net/~omajid/webrevs/8139932-typo-makefile-jpeg/00/ > > Typo in makefile changes for 8043805 [Allow using a system-installed libjpeg] > Reviewed-by: omajid, prr > Contributed-by: Matthias Klose > > Regards, > Omair > > * Philip Race [2015-10-19 17:22]: >> I filed https://bugs.openjdk.java.net/browse/JDK-8139932 >> >> -phil. >> >> On 10/19/15, 12:51 PM, Matthias Klose wrote: >>> till seen with b87. The current makefile has a typo, referencing the >>> wrong file. >>> >>> Please create a ticket and a webrev. I don't have access to these tools. >>> >>> Matthias >>> >>> libjpeg-fix.diff >>> >>> >>> # DP: Fix libjavajpeg build using the system jpeg library. >>> >>> Index: b/jdk/make/lib/Awt2dLibraries.gmk >>> =================================================================== >>> --- a/jdk/make/lib/Awt2dLibraries.gmk >>> +++ b/jdk/make/lib/Awt2dLibraries.gmk >>> @@ -476,7 +476,7 @@ endif >>> ifeq ($(USE_EXTERNAL_LIBJPEG), true) >>> LIBJPEG_LIBS := -ljpeg >>> BUILD_LIBJAVAJPEG_INCLUDE_FILES := \ >>> - imageIOJPEG.c \ >>> + imageioJPEG.c \ >>> jpegdecoder.c >>> BUILD_LIBJAVAJPEG_HEADERS := >>> else From bhanu.prakash.gopularam at oracle.com Tue Oct 27 11:51:08 2015 From: bhanu.prakash.gopularam at oracle.com (Bhanu Gopularam) Date: Tue, 27 Oct 2015 04:51:08 -0700 (PDT) Subject: Issue with Jdk-9 build with boot_jdk as JDK-9 Message-ID: Hi, I am trying to build JDK-9 from dev repo with JDk-9 as BOOT_JDK. I am facing some issues. I have created JDK image with latest jdk-9-dev codebase from hg repo tagged as jdk9-b88. I am using this jdk-image as BOOT_JDK for creating JDK-9 build once again. The JDK-9 build is failing while locating a directory, the modules directory is searched in jdk/lib/* instead of jdk/*. I would like to know if it is possible to build JDK-9 using JDK-9 as BOOT_JDK ? I came across few JBS bugs reporting issues with JDK-9 builds but I didn't see any mention about version of BOOT_JDK supported for building JDK-9. Please let me know if this is supported way to build JDK image. Thanks, Bhanu From erik.joelsson at oracle.com Tue Oct 27 12:03:52 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 27 Oct 2015 13:03:52 +0100 Subject: Issue with Jdk-9 build with boot_jdk as JDK-9 In-Reply-To: References: Message-ID: <562F6828.8010406@oracle.com> The officially supported boot jdk for JDK N is always JDK N-1. Using JDK N should work in most cases, but depending on how old the JDK N build is compared to the sources you are building, all sorts of issues may arise. /Erik On 2015-10-27 12:51, Bhanu Gopularam wrote: > Hi, > > > > I am trying to build JDK-9 from dev repo with JDk-9 as BOOT_JDK. I am facing some issues. > > > > I have created JDK image with latest jdk-9-dev codebase from hg repo tagged as jdk9-b88. I am using this jdk-image as BOOT_JDK for creating JDK-9 build once again. The JDK-9 build is failing while locating a directory, the modules directory is searched in jdk/lib/* instead of jdk/*. > > > > I would like to know if it is possible to build JDK-9 using JDK-9 as BOOT_JDK ? I came across few JBS bugs reporting issues with JDK-9 builds but I didn't see any mention about version of BOOT_JDK supported for building JDK-9. Please let me know if this is supported way to build JDK image. > > > > Thanks, > > Bhanu From magnus.ihse.bursie at oracle.com Tue Oct 27 15:56:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 27 Oct 2015 16:56:03 +0100 Subject: RFR: JDK-8140312: Enable new sjavac server only mode in jdk build In-Reply-To: <562E309B.4040601@oracle.com> References: <5628BC9F.6080206@oracle.com> <562A5081.4070202@oracle.com> <562E309B.4040601@oracle.com> Message-ID: <562F9E93.10805@oracle.com> On 2015-10-26 14:54, Erik Joelsson wrote: > I send this review prematurely. Here is a new webrev, which has been > properly tested. We had some test code compilations using the boot > javac, which hadn't properly declared DISABLE_SJAVAC. The copy paste > error in configure has also been corrected. > > On my workstation, running "make java" with hotspot already built, the > speedup goes from 2:32 to 1:35. Running just "make" with the default > target goes from about 4:05 to 3:10. > > Webrev: http://cr.openjdk.java.net/~erikj/8140312/webrev.02/ Looks good to me. /Magnus > > /Erik > > On 2015-10-23 17:21, Magnus Ihse Bursie wrote: >> On 2015-10-22 12:38, Erik Joelsson wrote: >>> In JDK-8135131, sjavac added a thin server mode, in which only the >>> server part of sjavac is used for running plain javac. This patch >>> adds a configure option to enable this mode of running to the jdk >>> build. Later, if it seems to work well, we will consider making it >>> default. >>> >>> On my workstation (linux) running the default make target went from >>> about 4m55s to 4m05s when activating this. >> >> Did that test really use the new sjavac server? :-) The code looks >> broken, in common/autoconf/build-performance.m4 you set ENABLE_SJAVAC >> and not ENABLE_JAVAC_SERVER in the new flag. >> >> Apart from that, it looks good. :) >> >> /Magnus > From martinrb at google.com Tue Oct 27 20:36:46 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 27 Oct 2015 13:36:46 -0700 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> <56263A34.20203@oracle.com> <56263C41.6000604@redhat.com> Message-ID: The world would be a better place if the current x86 32-bit ABI was replaced by "x32" https://en.wikipedia.org/wiki/X32_ABI but it's looking unlikely that we will get there. For starters, all compilers must be rewritten to target x32, and that includes the jdk jits. And that's a big project, one for compiler writers, not autoconf hackers. Whoever is trying to make x32 happen should also try to take this on. On Wed, Oct 21, 2015 at 11:39 PM, Volker Simonis wrote: > I only now took a look at the what x86_64-linux-gnux32 really means > (thanks Andrew for providing the link). > > So independently of the discussed build issues I doubt that this > currently really makes sense for the OpenJDK. The VM is simply not > aware of the new ABI so all the generated code (interpreter, JIT) > won't use the extra registers anyway. I also suspect there could be > calling conventions problems from generated to native code. Making all > this work is a much bigger effort than just passing the right flags to > the compiler. > > On Tue, Oct 20, 2015 at 3:06 PM, Andrew Haley wrote: > > On 10/20/2015 01:57 PM, Magnus Ihse Bursie wrote: > >> What does x86_64-linux-gnux32 imply? Some sort of mix between 32 and > 64-bit? > > > > I think that's a 32-bit ABI running on a 64-bit processor. > > > > https://en.wikipedia.org/wiki/X32_ABI > > > > If so, I'm surprised it works at all. > > > > Andrew. > > > From magnus.ihse.bursie at oracle.com Wed Oct 28 08:52:00 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 09:52:00 +0100 Subject: RFR: JDK-8140484: Vardeps broken when variable value contains '$' In-Reply-To: <562E06BF.1060405@oracle.com> References: <562E06BF.1060405@oracle.com> Message-ID: The fix looks good. I'm just wondering if there are any other problematic characters that needs to be escaped, such as \. Or should we address such issues when they arise? /Magnus > 26 okt. 2015 kl. 11:55 skrev Erik Joelsson : > > When I optimized the vardeps functionality in JDK-8136385, I caused a regression when the variable contained '$' characters. By reading the old value as a makefile using "include", variable substitution is applied. To work around this, dollar characters need to be escaped (doubled) prior to printing the variable value to the vardeps makefile. > > This causes native libraries to be relinked every time they are incrementally built because of the "\$ORIGIN" string. > > Also updating tests to cover this. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140484 > Webrev: http://cr.openjdk.java.net/~erikj/8140484/webrev.01/ > > /Erik From aph at redhat.com Wed Oct 28 09:32:09 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Oct 2015 09:32:09 +0000 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> <56263A34.20203@oracle.com> <56263C41.6000604@redhat.com> Message-ID: <56309619.2000408@redhat.com> On 27/10/15 20:36, Martin Buchholz wrote: > The world would be a better place if the current x86 32-bit ABI was > replaced by "x32" > https://en.wikipedia.org/wiki/X32_ABI > but it's looking unlikely that we will get there. For starters, all > compilers must be rewritten to target x32, and that includes the jdk > jits. No they wouldn't. The jits don't have to be changed at all because we already can handle compressed OOPs with no shift or base offset, i.e. native 32-bit addresses. The Java calling convention would therefore stay as it is. All that would have to be changed is the native <-> Java interfaces and accesses to native pointer-sized fields in C++ structures. It's not trivial, but neither is it a rewrite. Andrew. From erik.joelsson at oracle.com Wed Oct 28 09:47:23 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Oct 2015 10:47:23 +0100 Subject: RFR: JDK-8140591: Add configure argument specifying make executable in JPRT Message-ID: <563099AB.2020109@oracle.com> I've noticed that on some linux systems (maybe even all OEL6 and 7), there is a /usr/bin/gmake binary. Configure unfortunately picks up this gmake instead of the make binary we explicitly put first in the path. I've fixed this by adding a configure parameter in make/jprt.properties in the jdk9 source. We have reports of make crashing in certain situations and I believe using gnu make 4.0 in JPRT, as has been intended, will fix this problem. In addition to this, I also fixed some issues with setting MAKE= on the configure command line. Configure complains that it doesn't recognize MAKE as a valid parameter. It was also not possible to set just an executable name, just an absolute path. I fixed this by rewriting the make detection to use the BASIC_SETUP_TOOL macro which already implements all of this properly. Bug: https://bugs.openjdk.java.net/browse/JDK-8140591 Webrev: http://cr.openjdk.java.net/~erikj/8140591/webrev.01/ /Erik From erik.joelsson at oracle.com Wed Oct 28 10:14:35 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Oct 2015 11:14:35 +0100 Subject: RFR: JDK-8140593: Add configure parameter for devkit for the build compiler Message-ID: <5630A00B.8090805@oracle.com> In Jake, when crosscompiling, we need to build a subset of the jdk, including hotspot, to be able to run jmod and jlink. Currently, the build compiler is just found on the system so such a configuration requires the build system to basically be able to compile the jdk without a devkit. The idea with devkits was partly to avoid this. The solution would be to add another configure parameter that defines a devkit for the build compiler. Bug: https://bugs.openjdk.java.net/browse/JDK-8140593 Webrev: http://cr.openjdk.java.net/~erikj/8140593/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Wed Oct 28 11:09:27 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 12:09:27 +0100 Subject: RFR: JDK-8140591: Add configure argument specifying make executable in JPRT In-Reply-To: <563099AB.2020109@oracle.com> References: <563099AB.2020109@oracle.com> Message-ID: <697BEA06-B80B-4366-98F3-00CF12BB96D1@oracle.com> Looks good to me. Nice solution in basics.m4! /Magnus > 28 okt. 2015 kl. 10:47 skrev Erik Joelsson : > > I've noticed that on some linux systems (maybe even all OEL6 and 7), there is a /usr/bin/gmake binary. Configure unfortunately picks up this gmake instead of the make binary we explicitly put first in the path. I've fixed this by adding a configure parameter in make/jprt.properties in the jdk9 source. > > We have reports of make crashing in certain situations and I believe using gnu make 4.0 in JPRT, as has been intended, will fix this problem. > > In addition to this, I also fixed some issues with setting MAKE= on the configure command line. Configure complains that it doesn't recognize MAKE as a valid parameter. It was also not possible to set just an executable name, just an absolute path. I fixed this by rewriting the make detection to use the BASIC_SETUP_TOOL macro which already implements all of this properly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140591 > Webrev: http://cr.openjdk.java.net/~erikj/8140591/webrev.01/ > > /Erik From bob.vandette at oracle.com Wed Oct 28 12:31:26 2015 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 28 Oct 2015 08:31:26 -0400 Subject: RFR: 8140396 - BUILD_LIBJIMAGE missing as a dependency to JAVA_BASE_EXPORT_SYMBOLS_SRC Message-ID: Please review this 1 line change to add a missing library dependency from the recent addition of static build support. The new libjimage support was brought into my forest during the merge before I pushed this feature and I missed this dependency. Thanks to Magnus for catching this. https://bugs.openjdk.java.net/browse/JDK-8140396 diff --git a/make/lib/Lib-java.base.gmk b/make/lib/Lib-java.base.gmk --- a/make/lib/Lib-java.base.gmk +++ b/make/lib/Lib-java.base.gmk @@ -54,7 +54,8 @@ # The individual symbol files is generated when the respective lib is built $(JAVA_BASE_EXPORT_SYMBOLS_SRC): $(BUILD_LIBJLI) $(BUILD_LIBJAVA) \ - $(BUILD_LIBNET) $(BUILD_LIBNIO) $(BUILD_LIBVERIFY) $(BUILD_LIBZIP) + $(BUILD_LIBNET) $(BUILD_LIBNIO) $(BUILD_LIBVERIFY) $(BUILD_LIBZIP) \ + $(BUILD_LIBJIMAGE) TARGETS += $(JAVA_BASE_EXPORT_SYMBOL_FILE) endif From erik.joelsson at oracle.com Wed Oct 28 12:43:48 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Oct 2015 13:43:48 +0100 Subject: RFR: 8140396 - BUILD_LIBJIMAGE missing as a dependency to JAVA_BASE_EXPORT_SYMBOLS_SRC In-Reply-To: References: Message-ID: <5630C304.9010700@oracle.com> Looks good to me. /Erik On 2015-10-28 13:31, Bob Vandette wrote: > Please review this 1 line change to add a missing library dependency from > the recent addition of static build support. The new libjimage support > was brought into my forest during the merge before I pushed this feature and > I missed this dependency. Thanks to Magnus for catching this. > > https://bugs.openjdk.java.net/browse/JDK-8140396 > > > diff --git a/make/lib/Lib-java.base.gmk b/make/lib/Lib-java.base.gmk > --- a/make/lib/Lib-java.base.gmk > +++ b/make/lib/Lib-java.base.gmk > @@ -54,7 +54,8 @@ > > # The individual symbol files is generated when the respective lib is built > $(JAVA_BASE_EXPORT_SYMBOLS_SRC): $(BUILD_LIBJLI) $(BUILD_LIBJAVA) \ > - $(BUILD_LIBNET) $(BUILD_LIBNIO) $(BUILD_LIBVERIFY) $(BUILD_LIBZIP) > + $(BUILD_LIBNET) $(BUILD_LIBNIO) $(BUILD_LIBVERIFY) $(BUILD_LIBZIP) \ > + $(BUILD_LIBJIMAGE) > > TARGETS += $(JAVA_BASE_EXPORT_SYMBOL_FILE) > endif From magnus.ihse.bursie at oracle.com Wed Oct 28 13:50:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 14:50:05 +0100 Subject: RFR: 8140396 - BUILD_LIBJIMAGE missing as a dependency to JAVA_BASE_EXPORT_SYMBOLS_SRC In-Reply-To: References: Message-ID: <5630D28D.4030201@oracle.com> On 2015-10-28 13:31, Bob Vandette wrote: > Please review this 1 line change to add a missing library dependency from > the recent addition of static build support. The new libjimage support > was brought into my forest during the merge before I pushed this feature and > I missed this dependency. Thanks to Magnus for catching this. > > https://bugs.openjdk.java.net/browse/JDK-8140396 > > > diff --git a/make/lib/Lib-java.base.gmk b/make/lib/Lib-java.base.gmk > --- a/make/lib/Lib-java.base.gmk > +++ b/make/lib/Lib-java.base.gmk > @@ -54,7 +54,8 @@ > > # The individual symbol files is generated when the respective lib is built > $(JAVA_BASE_EXPORT_SYMBOLS_SRC): $(BUILD_LIBJLI) $(BUILD_LIBJAVA) \ > - $(BUILD_LIBNET) $(BUILD_LIBNIO) $(BUILD_LIBVERIFY) $(BUILD_LIBZIP) > + $(BUILD_LIBNET) $(BUILD_LIBNIO) $(BUILD_LIBVERIFY) $(BUILD_LIBZIP) \ > + $(BUILD_LIBJIMAGE) > > TARGETS += $(JAVA_BASE_EXPORT_SYMBOL_FILE) > endif Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Wed Oct 28 13:56:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 14:56:55 +0100 Subject: RFR: JDK-8140593: Add configure parameter for devkit for the build compiler In-Reply-To: <5630A00B.8090805@oracle.com> References: <5630A00B.8090805@oracle.com> Message-ID: <5630D427.4020408@oracle.com> On 2015-10-28 11:14, Erik Joelsson wrote: > In Jake, when crosscompiling, we need to build a subset of the jdk, > including hotspot, to be able to run jmod and jlink. Currently, the > build compiler is just found on the system so such a configuration > requires the build system to basically be able to compile the jdk > without a devkit. The idea with devkits was partly to avoid this. The > solution would be to add another configure parameter that defines a > devkit for the build compiler. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140593 > Webrev: http://cr.openjdk.java.net/~erikj/8140593/webrev.01/ I'm getting slightly confused on how devkits really propagate their information to configure. I think we're kind of missing a piece here, we're giving configure clues on where to look but we still to not explicitely point to e.g. the complete (relative) compiler binary path in the devkit. Otoh, that's not really part of your fix and if it works, I'm okay with it. One nitpick: + $SED -e "s/^DEVKIT_/BUILD_DEVKIT_/g" \ + -e "s/\$DEVKIT_ROOT/\$BUILD_DEVKIT_ROOT/g" \ I believe the last line here is unnecessary. /Magnus From erik.joelsson at oracle.com Wed Oct 28 14:29:58 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Oct 2015 15:29:58 +0100 Subject: RFR: JDK-8140593: Add configure parameter for devkit for the build compiler In-Reply-To: <5630D427.4020408@oracle.com> References: <5630A00B.8090805@oracle.com> <5630D427.4020408@oracle.com> Message-ID: <5630DBE6.9000609@oracle.com> On 2015-10-28 14:56, Magnus Ihse Bursie wrote: > On 2015-10-28 11:14, Erik Joelsson wrote: >> In Jake, when crosscompiling, we need to build a subset of the jdk, >> including hotspot, to be able to run jmod and jlink. Currently, the >> build compiler is just found on the system so such a configuration >> requires the build system to basically be able to compile the jdk >> without a devkit. The idea with devkits was partly to avoid this. The >> solution would be to add another configure parameter that defines a >> devkit for the build compiler. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140593 >> Webrev: http://cr.openjdk.java.net/~erikj/8140593/webrev.01/ > > I'm getting slightly confused on how devkits really propagate their > information to configure. I think we're kind of missing a piece here, > we're giving configure clues on where to look but we still to not > explicitely point to e.g. the complete (relative) compiler binary path > in the devkit. Otoh, that's not really part of your fix and if it > works, I'm okay with it. > That communication could perhaps be improved yes. > One nitpick: > > + $SED -e "s/^DEVKIT_/BUILD_DEVKIT_/g" \ > + -e "s/\$DEVKIT_ROOT/\$BUILD_DEVKIT_ROOT/g" \ > > > I believe the last line here is unnecessary. > Not so imo. The first one only matches beginning of a line for replacing assignments. The second matches variable references to DEVKIT_ROOT. It's likely unnecessary to be this specific though so I could do a simple "s/DEVKIT_/BUILD_DEVKIT_/g" to cover both cases. /Erik From martinrb at google.com Wed Oct 28 18:50:21 2015 From: martinrb at google.com (Martin Buchholz) Date: Wed, 28 Oct 2015 11:50:21 -0700 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: <56309619.2000408@redhat.com> References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> <56263A34.20203@oracle.com> <56263C41.6000604@redhat.com> <56309619.2000408@redhat.com> Message-ID: On Wed, Oct 28, 2015 at 2:32 AM, Andrew Haley wrote: > On 27/10/15 20:36, Martin Buchholz wrote: > > The world would be a better place if the current x86 32-bit ABI was > > replaced by "x32" > > https://en.wikipedia.org/wiki/X32_ABI > > but it's looking unlikely that we will get there. For starters, all > > compilers must be rewritten to target x32, and that includes the jdk > > jits. > > No they wouldn't. The jits don't have to be changed at all because we > already can handle compressed OOPs with no shift or base offset, > i.e. native 32-bit addresses. The Java calling convention would > therefore stay as it is. All that would have to be changed is the > native <-> Java interfaces and accesses to native pointer-sized fields > in C++ structures. It's not trivial, but neither is it a rewrite. > I'll buy that - it's an "easy" job, but still a job for a compiler writer. Perhaps x32 has less benefit for java programs because jits are already free to generate code that uses 32-bit pointers but takes advantage of the x86_64 instruction set? From magnus.ihse.bursie at oracle.com Wed Oct 28 21:03:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 22:03:46 +0100 Subject: RFR: JDK-8140661 Rename LDFLAGS_SUFFIX to LIBS Message-ID: <56313832.1000105@oracle.com> The build system has not been good at separating LIBS from LDFLAGS. In fact, when we started doing this, the name "LDFLAGS_SUFFIX" was used for what is traditionally called LIBS. This unwieldy name has unfortunately been kept, and possibly as a cause of this, we have not been good at differing between flags to the linker and libraries needed to link with. We should rename LDFLAGS_SUFFIX (and all of it's variants) to LIBS, and make sure we use LDFLAGS for flags and LIBS for libs. I made this patch using sed to automatically replace LDFLAGS_SUFFIX with LIBS. I then manually checked all renamed instances, and verified that new names didn't clash with old names. I also used sed to rename LDFLAGS_JDKLIB_SUFFIX to JDKLIB_LIBS (and correspondingly for JDKEXE). When I had verified that all replacements were sound, I also did some manual cleanup. It turned out that a) we had not unified common libraries across platforms, e.g. repeating them for multiple individual platforms instead of using LIBS_unix. This was originally an explicit design goal to minimize spurious changes compared to the old build system, but that is not relevant any longer and needed to be fixed. b) we had not properly separated LDFLAGS and LIBS, so in some cases we sent linker flags in LIBS (formerly LDFLAGS_SUFFIX, so it might be understandable) and library dependencies in LDFLAGS. (This is acceptable for some linkers, however, for good style, we should use LIBS for libraries consistently across platforms.) I have fixed those issues, were I could find them. Bug: https://bugs.openjdk.java.net/browse/JDK-8140661 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8140661-rename-LDFLAGS_SUFFIX-to-LIBS/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Oct 28 21:09:58 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 22:09:58 +0100 Subject: RFR: JDK-8140661 Rename LDFLAGS_SUFFIX to LIBS In-Reply-To: <56313832.1000105@oracle.com> References: <56313832.1000105@oracle.com> Message-ID: <563139A6.3020109@oracle.com> I forgot to mention that this is part of a larger cleanup of our flag handling. In upcoming patches, I will address issues with CFLAGS, CXXFLAGS and LDFLAGS. (This, in turn, is needed to integrate the new hotspot build system properly.) So while I did some changes to LDFLAGS (where it conflicted with the purpose of LIBS), I have mostly left these unchanged. In case you were wondering. :-) /Magnus On 2015-10-28 22:03, Magnus Ihse Bursie wrote: > The build system has not been good at separating LIBS from LDFLAGS. In > fact, when we started doing this, the name "LDFLAGS_SUFFIX" was used > for what is traditionally called LIBS. This unwieldy name has > unfortunately been kept, and possibly as a cause of this, we have not > been good at differing between flags to the linker and libraries > needed to link with. > > We should rename LDFLAGS_SUFFIX (and all of it's variants) to LIBS, > and make sure we use LDFLAGS for flags and LIBS for libs. > > I made this patch using sed to automatically replace LDFLAGS_SUFFIX > with LIBS. I then manually checked all renamed instances, and verified > that new names didn't clash with old names. I also used sed to rename > LDFLAGS_JDKLIB_SUFFIX to JDKLIB_LIBS (and correspondingly for JDKEXE). > > When I had verified that all replacements were sound, I also did some > manual cleanup. It turned out that > a) we had not unified common libraries across platforms, e.g. > repeating them for multiple individual platforms instead of using > LIBS_unix. This was originally an explicit design goal to minimize > spurious changes compared to the old build system, but that is not > relevant any longer and needed to be fixed. > b) we had not properly separated LDFLAGS and LIBS, so in some cases we > sent linker flags in LIBS (formerly LDFLAGS_SUFFIX, so it might be > understandable) and library dependencies in LDFLAGS. (This is > acceptable for some linkers, however, for good style, we should use > LIBS for libraries consistently across platforms.) > > I have fixed those issues, were I could find them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140661 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8140661-rename-LDFLAGS_SUFFIX-to-LIBS/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Wed Oct 28 21:16:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 22:16:01 +0100 Subject: RFR: JDK-8140593: Add configure parameter for devkit for the build compiler In-Reply-To: <5630DBE6.9000609@oracle.com> References: <5630A00B.8090805@oracle.com> <5630D427.4020408@oracle.com> <5630DBE6.9000609@oracle.com> Message-ID: <56313B11.5000501@oracle.com> On 2015-10-28 15:29, Erik Joelsson wrote: > > > On 2015-10-28 14:56, Magnus Ihse Bursie wrote: >> On 2015-10-28 11:14, Erik Joelsson wrote: >>> In Jake, when crosscompiling, we need to build a subset of the jdk, >>> including hotspot, to be able to run jmod and jlink. Currently, the >>> build compiler is just found on the system so such a configuration >>> requires the build system to basically be able to compile the jdk >>> without a devkit. The idea with devkits was partly to avoid this. >>> The solution would be to add another configure parameter that >>> defines a devkit for the build compiler. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8140593 >>> Webrev: http://cr.openjdk.java.net/~erikj/8140593/webrev.01/ >> >> I'm getting slightly confused on how devkits really propagate their >> information to configure. I think we're kind of missing a piece here, >> we're giving configure clues on where to look but we still to not >> explicitely point to e.g. the complete (relative) compiler binary >> path in the devkit. Otoh, that's not really part of your fix and if >> it works, I'm okay with it. >> > That communication could perhaps be improved yes. >> One nitpick: >> >> + $SED -e "s/^DEVKIT_/BUILD_DEVKIT_/g" \ >> + -e "s/\$DEVKIT_ROOT/\$BUILD_DEVKIT_ROOT/g" \ >> >> >> I believe the last line here is unnecessary. >> > Not so imo. The first one only matches beginning of a line for > replacing assignments. The second matches variable references to > DEVKIT_ROOT. It's likely unnecessary to be this specific though so I > could do a simple "s/DEVKIT_/BUILD_DEVKIT_/g" to cover both cases. I missed the ^, sorry. You're right, they are different and more specific. Keep them that way. /Magnus From magnus.ihse.bursie at oracle.com Wed Oct 28 21:18:27 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 28 Oct 2015 22:18:27 +0100 Subject: RFR [XS] - 8139026 hotspot.script cannot handle command-line arguments with spaces In-Reply-To: <562DBB78.6090109@oracle.com> References: <562DBB78.6090109@oracle.com> Message-ID: <56313BA3.6010807@oracle.com> On 2015-10-26 06:34, Ioi Lam wrote: > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8139026-hotspot-script-arg-quoating/ Looks good to me. As you say, dbx is not fixed, but fixing that properly probably requires more work than it's worth. /Magnus > > Bug: hotspot/make/hotspot.script cannot handle command-line arguments > with spaces > > https://bugs.openjdk.java.net/browse/JDK-8139026 > > Summary of fix: > > The old script was adding $@ to a string like X="A B $@ C". Doing > that would > lose the quotation on the arguments. This would cause JTREG to fail > when running > with Jigsaw modules (see bug report for details). > > The fix is to pass "$@" directly as arguments to all programs > launched by > hotspot.script > > Note that the fix does not address the problem with DBX, but at > least it's no worse > than before. > > Tests: > > I have used the modified version for the past 2 weeks with GDB and > JTREG and found > no issues. > > Also, casual testing shows the quotation is retained: > > $ hotspot 'a a' > Error: Could not find or load main class a a > $ hotspot "a' a" > Error: Could not find or load main class a' a > $ hotspot "a\"' a" > Error: Could not find or load main class a"' a > > Thanks > - Ioi From aph at redhat.com Thu Oct 29 09:21:51 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Oct 2015 09:21:51 +0000 Subject: hardcoding -m32/-m64 is more harmful than using the toolchain defaults In-Reply-To: References: <562557AE.5070408@ubuntu.com> <5625ED84.8020702@oracle.com> <5625EF03.9050304@oracle.com> <56263013.5050107@ubuntu.com> <56263A34.20203@oracle.com> <56263C41.6000604@redhat.com> <56309619.2000408@redhat.com> Message-ID: <5631E52F.90708@redhat.com> On 28/10/15 18:50, Martin Buchholz wrote: > I'll buy that - it's an "easy" job, but still a job for a compiler writer. > > Perhaps x32 has less benefit for java programs because jits are already > free to generate code that uses 32-bit pointers but takes advantage of the > x86_64 instruction set? That's exactly the case. It'd still benefit, but not to the same extent as C. Andrew. From magnus.ihse.bursie at oracle.com Thu Oct 29 10:39:23 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 29 Oct 2015 11:39:23 +0100 Subject: RFR: JDK-8140762 Specifying --without-LIB if not needed should not result in warning Message-ID: <5631F75B.8010203@oracle.com> If we specify e.g. --without-cups on a platform where cups is neither needed nor used, we will get a warning that --with-cups is ignored. In fact, specifying --without-X when X is not needed is the default and it should just be silently skipped by. Bug: https://bugs.openjdk.java.net/browse/JDK-8140762 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8140762-no-warning-for-without-lib/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Oct 29 13:29:23 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Oct 2015 14:29:23 +0100 Subject: RFR: JDK-8140762 Specifying --without-LIB if not needed should not result in warning In-Reply-To: <5631F75B.8010203@oracle.com> References: <5631F75B.8010203@oracle.com> Message-ID: <56321F33.4070901@oracle.com> Looks good to me. /Erik On 2015-10-29 11:39, Magnus Ihse Bursie wrote: > If we specify e.g. --without-cups on a platform where cups is neither > needed nor used, we will get a warning that --with-cups is ignored. In > fact, specifying --without-X when X is not needed is the default and > it should just be silently skipped by. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140762 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8140762-no-warning-for-without-lib/webrev.01 > > > /Magnus > From vladimir.x.ivanov at oracle.com Thu Oct 29 13:43:57 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 29 Oct 2015 16:43:57 +0300 Subject: JDK9: Build wb.jar which depends on JDK9 API Message-ID: <5632229D.7090307@oracle.com> Hi, Quick question: I have to use Java9 API in sun.misc.WhiteBox, but right now it is built using BOOT_JDK. Does the following change [1] look good? The following dependency seems too conservative (depends on hotspot which is not necessary): build-test-lib: $(JAVA_TARGETS) but I haven't found how to enumerate only JDK modules: Thanks! Best regards, Vladimir Ivanov [1] diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -452,6 +452,8 @@ test-make: clean-test-make + build-test-lib: $(JAVA_TARGETS) + build-test-hotspot-jtreg-native: buildtools-jdk build-test-jdk-jtreg-native: buildtools-jdk diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk --- a/make/test/BuildTestLib.gmk +++ b/make/test/BuildTestLib.gmk @@ -35,14 +35,8 @@ TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib -# Unfortunately, test-lib.jar does not compile properly without warnings. -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ - JAVAC := $(JAVAC), \ - FLAGS := -XDignore.symbol.file=true -g, \ -)) - $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ - SETUP := BOOT_JAVAC, \ + SETUP := GENERATE_USINGJDKBYTECODE, \ SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ BIN := $(TEST_LIB_SUPPORT), \ JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ @@ -52,7 +46,7 @@ # test-lib.jar will contain only hprof classes until JDK-8081381 is resolved $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ - SETUP := BOOT_JAVAC_NOWARNINGS, \ + SETUP := GENERATE_USINGJDKBYTECODE, \ SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ BIN := $(TEST_LIB_SUPPORT), \ JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \ From erik.joelsson at oracle.com Thu Oct 29 14:48:15 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Oct 2015 15:48:15 +0100 Subject: JDK9: Build wb.jar which depends on JDK9 API In-Reply-To: <5632229D.7090307@oracle.com> References: <5632229D.7090307@oracle.com> Message-ID: <563231AF.9080702@oracle.com> Hello, On 2015-10-29 14:43, Vladimir Ivanov wrote: > Hi, > > Quick question: I have to use Java9 API in sun.misc.WhiteBox, but > right now it is built using BOOT_JDK. Does the following change [1] > look good? > The changes look ok, but may impact build times as the building of tests will have to wait for a lot more of the product to finish before starting. Of course, if you need it, you need it. > The following dependency seems too conservative (depends on hotspot > which is not necessary): > > build-test-lib: $(JAVA_TARGETS) > > but I haven't found how to enumerate only JDK modules: > The problem is that the java code for jdk.hotspot.agent is built in the monolithic hotspot target. That in turn makes jdk.jdi-gensrc depend on hotspot for now. If we could disentangle that java compilation from hotspot, we would be able to build all the jdk java source without building hotspot. /Erik > Thanks! > Best regards, > Vladimir Ivanov > > [1] diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -452,6 +452,8 @@ > > test-make: clean-test-make > > + build-test-lib: $(JAVA_TARGETS) > + > build-test-hotspot-jtreg-native: buildtools-jdk > > build-test-jdk-jtreg-native: buildtools-jdk > diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk > --- a/make/test/BuildTestLib.gmk > +++ b/make/test/BuildTestLib.gmk > @@ -35,14 +35,8 @@ > TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib > TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib > > -# Unfortunately, test-lib.jar does not compile properly without > warnings. > -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ > - JAVAC := $(JAVAC), \ > - FLAGS := -XDignore.symbol.file=true -g, \ > -)) > - > $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ > - SETUP := BOOT_JAVAC, \ > + SETUP := GENERATE_USINGJDKBYTECODE, \ > SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ > BIN := $(TEST_LIB_SUPPORT), \ > JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ > @@ -52,7 +46,7 @@ > > # test-lib.jar will contain only hprof classes until JDK-8081381 is > resolved > $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ > - SETUP := BOOT_JAVAC_NOWARNINGS, \ > + SETUP := GENERATE_USINGJDKBYTECODE, \ > SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ > BIN := $(TEST_LIB_SUPPORT), \ > JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \ > From erik.joelsson at oracle.com Thu Oct 29 14:56:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 29 Oct 2015 15:56:08 +0100 Subject: RFR: JDK-8140661 Rename LDFLAGS_SUFFIX to LIBS In-Reply-To: <56313832.1000105@oracle.com> References: <56313832.1000105@oracle.com> Message-ID: <56323388.5000300@oracle.com> Looks good to me. /Erik On 2015-10-28 22:03, Magnus Ihse Bursie wrote: > The build system has not been good at separating LIBS from LDFLAGS. In > fact, when we started doing this, the name "LDFLAGS_SUFFIX" was used > for what is traditionally called LIBS. This unwieldy name has > unfortunately been kept, and possibly as a cause of this, we have not > been good at differing between flags to the linker and libraries > needed to link with. > > We should rename LDFLAGS_SUFFIX (and all of it's variants) to LIBS, > and make sure we use LDFLAGS for flags and LIBS for libs. > > I made this patch using sed to automatically replace LDFLAGS_SUFFIX > with LIBS. I then manually checked all renamed instances, and verified > that new names didn't clash with old names. I also used sed to rename > LDFLAGS_JDKLIB_SUFFIX to JDKLIB_LIBS (and correspondingly for JDKEXE). > > When I had verified that all replacements were sound, I also did some > manual cleanup. It turned out that > a) we had not unified common libraries across platforms, e.g. > repeating them for multiple individual platforms instead of using > LIBS_unix. This was originally an explicit design goal to minimize > spurious changes compared to the old build system, but that is not > relevant any longer and needed to be fixed. > b) we had not properly separated LDFLAGS and LIBS, so in some cases we > sent linker flags in LIBS (formerly LDFLAGS_SUFFIX, so it might be > understandable) and library dependencies in LDFLAGS. (This is > acceptable for some linkers, however, for good style, we should use > LIBS for libraries consistently across platforms.) > > I have fixed those issues, were I could find them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140661 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8140661-rename-LDFLAGS_SUFFIX-to-LIBS/webrev.01 > > /Magnus From tim.bell at oracle.com Thu Oct 29 15:42:49 2015 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 29 Oct 2015 08:42:49 -0700 Subject: RFR: JDK-8140591: Add configure argument specifying make executable in JPRT In-Reply-To: <697BEA06-B80B-4366-98F3-00CF12BB96D1@oracle.com> References: <563099AB.2020109@oracle.com> <697BEA06-B80B-4366-98F3-00CF12BB96D1@oracle.com> Message-ID: <56323E79.1030104@oracle.com> Erik: Looks good to me as well. Tim On 10/28/15 04:09, Magnus Ihse Bursie wrote: > Looks good to me. > > Nice solution in basics.m4! > > /Magnus > >> 28 okt. 2015 kl. 10:47 skrev Erik Joelsson : >> >> I've noticed that on some linux systems (maybe even all OEL6 and 7), there is a /usr/bin/gmake binary. Configure unfortunately picks up this gmake instead of the make binary we explicitly put first in the path. I've fixed this by adding a configure parameter in make/jprt.properties in the jdk9 source. >> >> We have reports of make crashing in certain situations and I believe using gnu make 4.0 in JPRT, as has been intended, will fix this problem. >> >> In addition to this, I also fixed some issues with setting MAKE= on the configure command line. Configure complains that it doesn't recognize MAKE as a valid parameter. It was also not possible to set just an executable name, just an absolute path. I fixed this by rewriting the make detection to use the BASIC_SETUP_TOOL macro which already implements all of this properly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140591 >> Webrev: http://cr.openjdk.java.net/~erikj/8140591/webrev.01/ >> >> /Erik From erik.joelsson at oracle.com Fri Oct 30 12:51:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 30 Oct 2015 13:51:02 +0100 Subject: RFR: JDK-8141051: Build test libs -source/-target 9 In-Reply-To: <563231AF.9080702@oracle.com> References: <5632229D.7090307@oracle.com> <563231AF.9080702@oracle.com> Message-ID: <563367B6.2020007@oracle.com> Hello, Here is a new patch for this where I did some more cleanup. Webrev: http://cr.openjdk.java.net/~erikj/8141051/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8141051 /Erik On 2015-10-29 15:48, Erik Joelsson wrote: > Hello, > > On 2015-10-29 14:43, Vladimir Ivanov wrote: >> Hi, >> >> Quick question: I have to use Java9 API in sun.misc.WhiteBox, but >> right now it is built using BOOT_JDK. Does the following change [1] >> look good? >> > The changes look ok, but may impact build times as the building of > tests will have to wait for a lot more of the product to finish before > starting. Of course, if you need it, you need it. >> The following dependency seems too conservative (depends on hotspot >> which is not necessary): >> >> build-test-lib: $(JAVA_TARGETS) >> >> but I haven't found how to enumerate only JDK modules: >> > The problem is that the java code for jdk.hotspot.agent is built in > the monolithic hotspot target. That in turn makes jdk.jdi-gensrc > depend on hotspot for now. If we could disentangle that java > compilation from hotspot, we would be able to build all the jdk java > source without building hotspot. > > /Erik >> Thanks! >> Best regards, >> Vladimir Ivanov >> >> [1] diff --git a/make/Main.gmk b/make/Main.gmk >> --- a/make/Main.gmk >> +++ b/make/Main.gmk >> @@ -452,6 +452,8 @@ >> >> test-make: clean-test-make >> >> + build-test-lib: $(JAVA_TARGETS) >> + >> build-test-hotspot-jtreg-native: buildtools-jdk >> >> build-test-jdk-jtreg-native: buildtools-jdk >> diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk >> --- a/make/test/BuildTestLib.gmk >> +++ b/make/test/BuildTestLib.gmk >> @@ -35,14 +35,8 @@ >> TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib >> TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib >> >> -# Unfortunately, test-lib.jar does not compile properly without >> warnings. >> -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ >> - JAVAC := $(JAVAC), \ >> - FLAGS := -XDignore.symbol.file=true -g, \ >> -)) >> - >> $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ >> - SETUP := BOOT_JAVAC, \ >> + SETUP := GENERATE_USINGJDKBYTECODE, \ >> SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ >> BIN := $(TEST_LIB_SUPPORT), \ >> JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ >> @@ -52,7 +46,7 @@ >> >> # test-lib.jar will contain only hprof classes until JDK-8081381 is >> resolved >> $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ >> - SETUP := BOOT_JAVAC_NOWARNINGS, \ >> + SETUP := GENERATE_USINGJDKBYTECODE, \ >> SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ >> BIN := $(TEST_LIB_SUPPORT), \ >> JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \ >> > From vladimir.x.ivanov at oracle.com Fri Oct 30 13:06:11 2015 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Oct 2015 16:06:11 +0300 Subject: RFR: JDK-8141051: Build test libs -source/-target 9 In-Reply-To: <563367B6.2020007@oracle.com> References: <5632229D.7090307@oracle.com> <563231AF.9080702@oracle.com> <563367B6.2020007@oracle.com> Message-ID: <56336B43.3020404@oracle.com> Looks good. Thanks for fixing it! Best regards, Vladimir Ivanov On 10/30/15 3:51 PM, Erik Joelsson wrote: > Hello, > > Here is a new patch for this where I did some more cleanup. > > Webrev: http://cr.openjdk.java.net/~erikj/8141051/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8141051 > > /Erik > > On 2015-10-29 15:48, Erik Joelsson wrote: >> Hello, >> >> On 2015-10-29 14:43, Vladimir Ivanov wrote: >>> Hi, >>> >>> Quick question: I have to use Java9 API in sun.misc.WhiteBox, but >>> right now it is built using BOOT_JDK. Does the following change [1] >>> look good? >>> >> The changes look ok, but may impact build times as the building of >> tests will have to wait for a lot more of the product to finish before >> starting. Of course, if you need it, you need it. >>> The following dependency seems too conservative (depends on hotspot >>> which is not necessary): >>> >>> build-test-lib: $(JAVA_TARGETS) >>> >>> but I haven't found how to enumerate only JDK modules: >>> >> The problem is that the java code for jdk.hotspot.agent is built in >> the monolithic hotspot target. That in turn makes jdk.jdi-gensrc >> depend on hotspot for now. If we could disentangle that java >> compilation from hotspot, we would be able to build all the jdk java >> source without building hotspot. >> >> /Erik >>> Thanks! >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] diff --git a/make/Main.gmk b/make/Main.gmk >>> --- a/make/Main.gmk >>> +++ b/make/Main.gmk >>> @@ -452,6 +452,8 @@ >>> >>> test-make: clean-test-make >>> >>> + build-test-lib: $(JAVA_TARGETS) >>> + >>> build-test-hotspot-jtreg-native: buildtools-jdk >>> >>> build-test-jdk-jtreg-native: buildtools-jdk >>> diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk >>> --- a/make/test/BuildTestLib.gmk >>> +++ b/make/test/BuildTestLib.gmk >>> @@ -35,14 +35,8 @@ >>> TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib >>> TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib >>> >>> -# Unfortunately, test-lib.jar does not compile properly without >>> warnings. >>> -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ >>> - JAVAC := $(JAVAC), \ >>> - FLAGS := -XDignore.symbol.file=true -g, \ >>> -)) >>> - >>> $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ >>> - SETUP := BOOT_JAVAC, \ >>> + SETUP := GENERATE_USINGJDKBYTECODE, \ >>> SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ >>> BIN := $(TEST_LIB_SUPPORT), \ >>> JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ >>> @@ -52,7 +46,7 @@ >>> >>> # test-lib.jar will contain only hprof classes until JDK-8081381 is >>> resolved >>> $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ >>> - SETUP := BOOT_JAVAC_NOWARNINGS, \ >>> + SETUP := GENERATE_USINGJDKBYTECODE, \ >>> SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ >>> BIN := $(TEST_LIB_SUPPORT), \ >>> JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \ >>> >> > From tim.bell at oracle.com Fri Oct 30 14:23:29 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 30 Oct 2015 07:23:29 -0700 Subject: RFR: JDK-8141051: Build test libs -source/-target 9 In-Reply-To: <56336B43.3020404@oracle.com> References: <5632229D.7090307@oracle.com> <563231AF.9080702@oracle.com> <563367B6.2020007@oracle.com> <56336B43.3020404@oracle.com> Message-ID: <56337D61.3080007@oracle.com> Erik Looks good to me as well. /Tim On 10/30/15 06:06, Vladimir Ivanov wrote: > Looks good. > > Thanks for fixing it! > > Best regards, > Vladimir Ivanov > > On 10/30/15 3:51 PM, Erik Joelsson wrote: >> Hello, >> >> Here is a new patch for this where I did some more cleanup. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8141051/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8141051 >> >> /Erik >> >> On 2015-10-29 15:48, Erik Joelsson wrote: >>> Hello, >>> >>> On 2015-10-29 14:43, Vladimir Ivanov wrote: >>>> Hi, >>>> >>>> Quick question: I have to use Java9 API in sun.misc.WhiteBox, but >>>> right now it is built using BOOT_JDK. Does the following change [1] >>>> look good? >>>> >>> The changes look ok, but may impact build times as the building of >>> tests will have to wait for a lot more of the product to finish before >>> starting. Of course, if you need it, you need it. >>>> The following dependency seems too conservative (depends on hotspot >>>> which is not necessary): >>>> >>>> build-test-lib: $(JAVA_TARGETS) >>>> >>>> but I haven't found how to enumerate only JDK modules: >>>> >>> The problem is that the java code for jdk.hotspot.agent is built in >>> the monolithic hotspot target. That in turn makes jdk.jdi-gensrc >>> depend on hotspot for now. If we could disentangle that java >>> compilation from hotspot, we would be able to build all the jdk java >>> source without building hotspot. >>> >>> /Erik >>>> Thanks! >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] diff --git a/make/Main.gmk b/make/Main.gmk >>>> --- a/make/Main.gmk >>>> +++ b/make/Main.gmk >>>> @@ -452,6 +452,8 @@ >>>> >>>> test-make: clean-test-make >>>> >>>> + build-test-lib: $(JAVA_TARGETS) >>>> + >>>> build-test-hotspot-jtreg-native: buildtools-jdk >>>> >>>> build-test-jdk-jtreg-native: buildtools-jdk >>>> diff --git a/make/test/BuildTestLib.gmk b/make/test/BuildTestLib.gmk >>>> --- a/make/test/BuildTestLib.gmk >>>> +++ b/make/test/BuildTestLib.gmk >>>> @@ -35,14 +35,8 @@ >>>> TEST_LIB_SOURCE_DIR := $(TOPDIR)/test/lib >>>> TEST_LIB_SUPPORT := $(SUPPORT_OUTPUTDIR)/test/lib >>>> >>>> -# Unfortunately, test-lib.jar does not compile properly without >>>> warnings. >>>> -$(eval $(call SetupJavaCompiler, BOOT_JAVAC_NOWARNINGS, \ >>>> - JAVAC := $(JAVAC), \ >>>> - FLAGS := -XDignore.symbol.file=true -g, \ >>>> -)) >>>> - >>>> $(eval $(call SetupJavaCompilation, BUILD_WB_JAR, \ >>>> - SETUP := BOOT_JAVAC, \ >>>> + SETUP := GENERATE_USINGJDKBYTECODE, \ >>>> SRC := $(TEST_LIB_SOURCE_DIR)/sun, \ >>>> BIN := $(TEST_LIB_SUPPORT), \ >>>> JAR := $(TEST_LIB_SUPPORT)/wb.jar, \ >>>> @@ -52,7 +46,7 @@ >>>> >>>> # test-lib.jar will contain only hprof classes until JDK-8081381 is >>>> resolved >>>> $(eval $(call SetupJavaCompilation, BUILD_TEST_LIB_JAR, \ >>>> - SETUP := BOOT_JAVAC_NOWARNINGS, \ >>>> + SETUP := GENERATE_USINGJDKBYTECODE, \ >>>> SRC := $(TEST_LIB_SOURCE_DIR)/share/classes/jdk/test/lib/hprof, \ >>>> BIN := $(TEST_LIB_SUPPORT), \ >>>> JAR := $(TEST_LIB_SUPPORT)/test-lib.jar, \ >>>> >>> >> From christian.thalinger at oracle.com Fri Oct 30 17:58:38 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Fri, 30 Oct 2015 10:58:38 -0700 Subject: RFR [XS] - 8139026 hotspot.script cannot handle command-line arguments with spaces In-Reply-To: <562DBB78.6090109@oracle.com> References: <562DBB78.6090109@oracle.com> Message-ID: <017F8D5E-96C2-4FC0-BF9F-56AC516D1736@oracle.com> > On Oct 25, 2015, at 10:34 PM, Ioi Lam wrote: > > Please review a very small fix: > > http://cr.openjdk.java.net/~iklam/8139026-hotspot-script-arg-quoating/ Looks good. I?m sure you asked, who is still using this script? > > Bug: hotspot/make/hotspot.script cannot handle command-line arguments with spaces > > https://bugs.openjdk.java.net/browse/JDK-8139026 > > Summary of fix: > > The old script was adding $@ to a string like X="A B $@ C". Doing that would > lose the quotation on the arguments. This would cause JTREG to fail when running > with Jigsaw modules (see bug report for details). > > The fix is to pass "$@" directly as arguments to all programs launched by > hotspot.script > > Note that the fix does not address the problem with DBX, but at least it's no worse > than before. > > Tests: > > I have used the modified version for the past 2 weeks with GDB and JTREG and found > no issues. > > Also, casual testing shows the quotation is retained: > > $ hotspot 'a a' > Error: Could not find or load main class a a > $ hotspot "a' a" > Error: Could not find or load main class a' a > $ hotspot "a\"' a" > Error: Could not find or load main class a"' a > > Thanks > - Ioi From ioi.lam at oracle.com Fri Oct 30 20:52:26 2015 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 30 Oct 2015 13:52:26 -0700 Subject: RFR [XS] - 8139026 hotspot.script cannot handle command-line arguments with spaces In-Reply-To: <017F8D5E-96C2-4FC0-BF9F-56AC516D1736@oracle.com> References: <562DBB78.6090109@oracle.com> <017F8D5E-96C2-4FC0-BF9F-56AC516D1736@oracle.com> Message-ID: <5633D88A.4020804@oracle.com> On 10/30/15 10:58 AM, Christian Thalinger wrote: >> On Oct 25, 2015, at 10:34 PM, Ioi Lam wrote: >> >> Please review a very small fix: >> >> http://cr.openjdk.java.net/~iklam/8139026-hotspot-script-arg-quoating/ > Looks good. I?m sure you asked, who is still using this script? Thanks Christian. I think probably very few people still use this script, but I do :-) - Ioi > >> Bug: hotspot/make/hotspot.script cannot handle command-line arguments with spaces >> >> https://bugs.openjdk.java.net/browse/JDK-8139026 >> >> Summary of fix: >> >> The old script was adding $@ to a string like X="A B $@ C". Doing that would >> lose the quotation on the arguments. This would cause JTREG to fail when running >> with Jigsaw modules (see bug report for details). >> >> The fix is to pass "$@" directly as arguments to all programs launched by >> hotspot.script >> >> Note that the fix does not address the problem with DBX, but at least it's no worse >> than before. >> >> Tests: >> >> I have used the modified version for the past 2 weeks with GDB and JTREG and found >> no issues. >> >> Also, casual testing shows the quotation is retained: >> >> $ hotspot 'a a' >> Error: Could not find or load main class a a >> $ hotspot "a' a" >> Error: Could not find or load main class a' a >> $ hotspot "a\"' a" >> Error: Could not find or load main class a"' a >> >> Thanks >> - Ioi