From magnus.ihse.bursie at oracle.com Mon Feb 1 12:12:29 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 1 Feb 2016 13:12:29 +0100 Subject: RFR(M) 8069540: Remove universal binaries support from hotspot build In-Reply-To: <56AB9B98.9000403@oracle.com> References: <56AB9B98.9000403@oracle.com> Message-ID: <56AF4BAD.8060206@oracle.com> On 2016-01-29 18:04, Erik Joelsson wrote: > (adding build-dev) > > Looks good enough to me. Looks good to me too. /Magnus > > /Erik > > On 2016-01-29 17:51, Gerard Ziemski wrote: >> Hi all (and especially the makefiles experts), >> >> This fix removes support for building hotspot universal libraries on >> Mac OS X and simplifies the makefiles. >> >> We are still building Mac OS X hotspot libraries as universal >> libraries, but with only one architecture (x86_64). The rest of JDK >> is built as plain single architecture libraries and there is no >> longer any need for this complexity (since we haven't supported 32bit >> platform on Mac OS X for a while now) >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8069540 >> Webrev: http://cr.openjdk.java.net/~gziemski/8069540_jdk_rev2/ >> Webrev: http://cr.openjdk.java.net/~gziemski/8069540_hotspot_rev2/ >> >> Testing: JPRT + RBT on all platforms. >> >> >> cheers > From erik.joelsson at oracle.com Mon Feb 1 15:01:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 1 Feb 2016 16:01:48 +0100 Subject: RFR: JDK-8148655 LOG=cmdlines and other build-infra fixes In-Reply-To: <56AC900C.1040205@oracle.com> References: <56AC900C.1040205@oracle.com> Message-ID: <56AF735C.3080601@oracle.com> Hello, InitSupport.gmk: The comment still refers to ",nofile". I would probably have made an effort to replace "$(ECHO) $(call ShellQuote, $2) > $(strip $1).cmdline &&" with a call to WriteFile. /Erik On 2016-01-30 11:27, Magnus Ihse Bursie wrote: > This is yet another collection of fixes from the build-infra hotspot > project forest that has a stand-alone value. > > The most important change is the support of a new log option, > cmdlines. This is, like the old "nofile", an option that can be added > to a log level, e.g. "LOG=info,cmdlines" or used standalone > "LOG=cmdlines" (in which case the log level stays at default). With > this in place, the command line of "important" commands are printed. > Examples of "important" commands are compiler and linker calls. > Examples of "non-important" commands are "mkdir" or "cat". Note that > at this point, not all "important" calls are identified, typically in > esoteric stuff like gensrc. > > Apart from this, a few other changes are also included: > * Allow DEBUG_SYMBOLS to be individually turned off (follow up to > JDK-8145596) > * Support .S assembly files > * Expose USERNAME outside configure > * Fix broken indentation > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148655 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.01 > > /Magnus From gerard.ziemski at oracle.com Mon Feb 1 16:07:10 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 1 Feb 2016 10:07:10 -0600 Subject: RFR(M) 8069540: Remove universal binaries support from hotspot build In-Reply-To: <56AB9B98.9000403@oracle.com> References: <56AB9B98.9000403@oracle.com> Message-ID: <330BF8D5-EB11-4187-ADEC-90F8C17AB66F@oracle.com> Thank you for the review! > On Jan 29, 2016, at 11:04 AM, Erik Joelsson wrote: > > (adding build-dev) > > Looks good enough to me. > > /Erik > > On 2016-01-29 17:51, Gerard Ziemski wrote: >> Hi all (and especially the makefiles experts), >> >> This fix removes support for building hotspot universal libraries on Mac OS X and simplifies the makefiles. >> >> We are still building Mac OS X hotspot libraries as universal libraries, but with only one architecture (x86_64). The rest of JDK is built as plain single architecture libraries and there is no longer any need for this complexity (since we haven't supported 32bit platform on Mac OS X for a while now) >> >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8069540 >> Webrev: http://cr.openjdk.java.net/~gziemski/8069540_jdk_rev2/ >> Webrev: http://cr.openjdk.java.net/~gziemski/8069540_hotspot_rev2/ >> >> Testing: JPRT + RBT on all platforms. >> >> >> cheers > From gerard.ziemski at oracle.com Mon Feb 1 16:07:17 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 1 Feb 2016 10:07:17 -0600 Subject: RFR(M) 8069540: Remove universal binaries support from hotspot build In-Reply-To: <56AF4BAD.8060206@oracle.com> References: <56AB9B98.9000403@oracle.com> <56AF4BAD.8060206@oracle.com> Message-ID: Thank you for the review! > On Feb 1, 2016, at 6:12 AM, Magnus Ihse Bursie wrote: > > On 2016-01-29 18:04, Erik Joelsson wrote: >> (adding build-dev) >> >> Looks good enough to me. > > Looks good to me too. > > /Magnus > >> >> /Erik >> >> On 2016-01-29 17:51, Gerard Ziemski wrote: >>> Hi all (and especially the makefiles experts), >>> >>> This fix removes support for building hotspot universal libraries on Mac OS X and simplifies the makefiles. >>> >>> We are still building Mac OS X hotspot libraries as universal libraries, but with only one architecture (x86_64). The rest of JDK is built as plain single architecture libraries and there is no longer any need for this complexity (since we haven't supported 32bit platform on Mac OS X for a while now) >>> >>> Bug link: https://bugs.openjdk.java.net/browse/JDK-8069540 >>> Webrev: http://cr.openjdk.java.net/~gziemski/8069540_jdk_rev2/ >>> Webrev: http://cr.openjdk.java.net/~gziemski/8069540_hotspot_rev2/ >>> >>> Testing: JPRT + RBT on all platforms. >>> >>> >>> cheers >> > From magnus.ihse.bursie at oracle.com Mon Feb 1 21:36:42 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 1 Feb 2016 22:36:42 +0100 Subject: RFR: JDK-8148655 LOG=cmdlines and other build-infra fixes In-Reply-To: <56AF735C.3080601@oracle.com> References: <56AC900C.1040205@oracle.com> <56AF735C.3080601@oracle.com> Message-ID: <56AFCFEA.9030708@oracle.com> On 2016-02-01 16:01, Erik Joelsson wrote: > Hello, > > InitSupport.gmk: > The comment still refers to ",nofile". I'll fix. > > I would probably have made an effort to replace "$(ECHO) $(call > ShellQuote, $2) > $(strip $1).cmdline &&" with a call to WriteFile. I did think about that, yes. However, I didn't figure out a satisfactory way to solve it. The problem is that WriteFile, on GNU Make < 4, results in a $(shell) call, which seemed worse than a chained call to echo, when we already is in a shell command line in a recipe. I wasn't too keen on creating a WriteFileInRecipe version either. So I couldn't figure out a way to do that that I was happy with. But I'm open to suggestions (or even better, working code :-)). /Magnus > > /Erik > > On 2016-01-30 11:27, Magnus Ihse Bursie wrote: >> This is yet another collection of fixes from the build-infra hotspot >> project forest that has a stand-alone value. >> >> The most important change is the support of a new log option, >> cmdlines. This is, like the old "nofile", an option that can be added >> to a log level, e.g. "LOG=info,cmdlines" or used standalone >> "LOG=cmdlines" (in which case the log level stays at default). With >> this in place, the command line of "important" commands are printed. >> Examples of "important" commands are compiler and linker calls. >> Examples of "non-important" commands are "mkdir" or "cat". Note that >> at this point, not all "important" calls are identified, typically in >> esoteric stuff like gensrc. >> >> Apart from this, a few other changes are also included: >> * Allow DEBUG_SYMBOLS to be individually turned off (follow up to >> JDK-8145596) >> * Support .S assembly files >> * Expose USERNAME outside configure >> * Fix broken indentation >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148655 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.01 >> >> /Magnus > From erik.joelsson at oracle.com Tue Feb 2 08:49:12 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Feb 2016 09:49:12 +0100 Subject: RFR: JDK-8148655 LOG=cmdlines and other build-infra fixes In-Reply-To: <56AFCFEA.9030708@oracle.com> References: <56AC900C.1040205@oracle.com> <56AF735C.3080601@oracle.com> <56AFCFEA.9030708@oracle.com> Message-ID: <56B06D88.3090101@oracle.com> On 2016-02-01 22:36, Magnus Ihse Bursie wrote: > On 2016-02-01 16:01, Erik Joelsson wrote: >> Hello, >> >> InitSupport.gmk: >> The comment still refers to ",nofile". > > I'll fix. > >> >> I would probably have made an effort to replace "$(ECHO) $(call >> ShellQuote, $2) > $(strip $1).cmdline &&" with a call to WriteFile. > > I did think about that, yes. However, I didn't figure out a > satisfactory way to solve it. The problem is that WriteFile, on GNU > Make < 4, results in a $(shell) call, which seemed worse than a > chained call to echo, when we already is in a shell command line in a > recipe. I wasn't too keen on creating a WriteFileInRecipe version > either. So I couldn't figure out a way to do that that I was happy > with. But I'm open to suggestions (or even better, working code :-)). > I realize a $(shell) call isn't ideal, but the performance difference will most likely only be noticeable on Windows, where we know we have $(file) anyway. /Erik > /Magnus > >> >> /Erik >> >> On 2016-01-30 11:27, Magnus Ihse Bursie wrote: >>> This is yet another collection of fixes from the build-infra hotspot >>> project forest that has a stand-alone value. >>> >>> The most important change is the support of a new log option, >>> cmdlines. This is, like the old "nofile", an option that can be >>> added to a log level, e.g. "LOG=info,cmdlines" or used standalone >>> "LOG=cmdlines" (in which case the log level stays at default). With >>> this in place, the command line of "important" commands are printed. >>> Examples of "important" commands are compiler and linker calls. >>> Examples of "non-important" commands are "mkdir" or "cat". Note that >>> at this point, not all "important" calls are identified, typically >>> in esoteric stuff like gensrc. >>> >>> Apart from this, a few other changes are also included: >>> * Allow DEBUG_SYMBOLS to be individually turned off (follow up to >>> JDK-8145596) >>> * Support .S assembly files >>> * Expose USERNAME outside configure >>> * Fix broken indentation >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148655 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.01 >>> >>> /Magnus >> > From magnus.ihse.bursie at oracle.com Tue Feb 2 11:03:40 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 2 Feb 2016 12:03:40 +0100 Subject: RFR: JDK-8148655 LOG=cmdlines and other build-infra fixes In-Reply-To: <56B06D88.3090101@oracle.com> References: <56AC900C.1040205@oracle.com> <56AF735C.3080601@oracle.com> <56AFCFEA.9030708@oracle.com> <56B06D88.3090101@oracle.com> Message-ID: <56B08D0C.2040805@oracle.com> On 2016-02-02 09:49, Erik Joelsson wrote: > > > On 2016-02-01 22:36, Magnus Ihse Bursie wrote: >> On 2016-02-01 16:01, Erik Joelsson wrote: >>> Hello, >>> >>> InitSupport.gmk: >>> The comment still refers to ",nofile". >> >> I'll fix. >> >>> >>> I would probably have made an effort to replace "$(ECHO) $(call >>> ShellQuote, $2) > $(strip $1).cmdline &&" with a call to WriteFile. >> >> I did think about that, yes. However, I didn't figure out a >> satisfactory way to solve it. The problem is that WriteFile, on GNU >> Make < 4, results in a $(shell) call, which seemed worse than a >> chained call to echo, when we already is in a shell command line in a >> recipe. I wasn't too keen on creating a WriteFileInRecipe version >> either. So I couldn't figure out a way to do that that I was happy >> with. But I'm open to suggestions (or even better, working code :-)). >> > I realize a $(shell) call isn't ideal, but the performance difference > will most likely only be noticeable on Windows, where we know we have > $(file) anyway. Ok. Here's a version where ExecuteWithLog has gotten even more TLC: http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.02 Changes, compared to the previous webrev, are in the files JavaCompilation.gmk, MakeBase.gmk and InitSupport.gmk. The following changes has been made since the last webrev: * Use WriteFile in ExecuteWithLog * Introduce and use LogCmdlines in ExecuteWithLog, to use $(info) instead of echo. (Together, these two also has the benefit och making LOG=debug more readable) * Introduce and use LogWarn to get correct order of logging (due to LogCmdlines) * Remove one layer of subshells ( ... ) which improves performance slightly * Call MakeDir instead of MKDIR. * Fix MakeDir to properly support a list of directories /Magnus > > /Erik > >> /Magnus >> >>> >>> /Erik >>> >>> On 2016-01-30 11:27, Magnus Ihse Bursie wrote: >>>> This is yet another collection of fixes from the build-infra >>>> hotspot project forest that has a stand-alone value. >>>> >>>> The most important change is the support of a new log option, >>>> cmdlines. This is, like the old "nofile", an option that can be >>>> added to a log level, e.g. "LOG=info,cmdlines" or used standalone >>>> "LOG=cmdlines" (in which case the log level stays at default). With >>>> this in place, the command line of "important" commands are >>>> printed. Examples of "important" commands are compiler and linker >>>> calls. Examples of "non-important" commands are "mkdir" or "cat". >>>> Note that at this point, not all "important" calls are identified, >>>> typically in esoteric stuff like gensrc. >>>> >>>> Apart from this, a few other changes are also included: >>>> * Allow DEBUG_SYMBOLS to be individually turned off (follow up to >>>> JDK-8145596) >>>> * Support .S assembly files >>>> * Expose USERNAME outside configure >>>> * Fix broken indentation >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148655 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.01 >>>> >>>> /Magnus >>> >> > From erik.joelsson at oracle.com Tue Feb 2 11:14:36 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Feb 2016 12:14:36 +0100 Subject: RFR: JDK-8148655 LOG=cmdlines and other build-infra fixes In-Reply-To: <56B08D0C.2040805@oracle.com> References: <56AC900C.1040205@oracle.com> <56AF735C.3080601@oracle.com> <56AFCFEA.9030708@oracle.com> <56B06D88.3090101@oracle.com> <56B08D0C.2040805@oracle.com> Message-ID: <56B08F9C.3080608@oracle.com> Looks good! /Erik On 2016-02-02 12:03, Magnus Ihse Bursie wrote: > On 2016-02-02 09:49, Erik Joelsson wrote: >> >> >> On 2016-02-01 22:36, Magnus Ihse Bursie wrote: >>> On 2016-02-01 16:01, Erik Joelsson wrote: >>>> Hello, >>>> >>>> InitSupport.gmk: >>>> The comment still refers to ",nofile". >>> >>> I'll fix. >>> >>>> >>>> I would probably have made an effort to replace "$(ECHO) $(call >>>> ShellQuote, $2) > $(strip $1).cmdline &&" with a call to WriteFile. >>> >>> I did think about that, yes. However, I didn't figure out a >>> satisfactory way to solve it. The problem is that WriteFile, on GNU >>> Make < 4, results in a $(shell) call, which seemed worse than a >>> chained call to echo, when we already is in a shell command line in >>> a recipe. I wasn't too keen on creating a WriteFileInRecipe version >>> either. So I couldn't figure out a way to do that that I was happy >>> with. But I'm open to suggestions (or even better, working code :-)). >>> >> I realize a $(shell) call isn't ideal, but the performance difference >> will most likely only be noticeable on Windows, where we know we have >> $(file) anyway. > > Ok. > > Here's a version where ExecuteWithLog has gotten even more TLC: > http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.02 > > > Changes, compared to the previous webrev, are in the files > JavaCompilation.gmk, MakeBase.gmk and InitSupport.gmk. > > The following changes has been made since the last webrev: > * Use WriteFile in ExecuteWithLog > * Introduce and use LogCmdlines in ExecuteWithLog, to use $(info) > instead of echo. > (Together, these two also has the benefit och making LOG=debug more > readable) > * Introduce and use LogWarn to get correct order of logging (due to > LogCmdlines) > * Remove one layer of subshells ( ... ) which improves performance > slightly > * Call MakeDir instead of MKDIR. > * Fix MakeDir to properly support a list of directories > > /Magnus > > >> >> /Erik >> >>> /Magnus >>> >>>> >>>> /Erik >>>> >>>> On 2016-01-30 11:27, Magnus Ihse Bursie wrote: >>>>> This is yet another collection of fixes from the build-infra >>>>> hotspot project forest that has a stand-alone value. >>>>> >>>>> The most important change is the support of a new log option, >>>>> cmdlines. This is, like the old "nofile", an option that can be >>>>> added to a log level, e.g. "LOG=info,cmdlines" or used standalone >>>>> "LOG=cmdlines" (in which case the log level stays at default). >>>>> With this in place, the command line of "important" commands are >>>>> printed. Examples of "important" commands are compiler and linker >>>>> calls. Examples of "non-important" commands are "mkdir" or "cat". >>>>> Note that at this point, not all "important" calls are identified, >>>>> typically in esoteric stuff like gensrc. >>>>> >>>>> Apart from this, a few other changes are also included: >>>>> * Allow DEBUG_SYMBOLS to be individually turned off (follow up to >>>>> JDK-8145596) >>>>> * Support .S assembly files >>>>> * Expose USERNAME outside configure >>>>> * Fix broken indentation >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148655 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8148655-LOG-cmdlines-and-misc-fixes/webrev.01 >>>>> >>>>> /Magnus >>>> >>> >> > From peter.brunet at oracle.com Tue Feb 2 18:47:53 2016 From: peter.brunet at oracle.com (Pete Brunet) Date: Tue, 2 Feb 2016 12:47:53 -0600 Subject: latest version of XCode? Message-ID: <56B0F9D9.7010907@oracle.com> What is the latest version of XCode we can use to build? I need to reinstall and am currently at 6.2. From pavel.rappo at oracle.com Tue Feb 2 23:49:57 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 2 Feb 2016 23:49:57 +0000 Subject: latest version of XCode? In-Reply-To: <56B0F9D9.7010907@oracle.com> References: <56B0F9D9.7010907@oracle.com> Message-ID: <3C727E63-DF8C-4AFC-ACB0-4A96F19F9E98@oracle.com> Hi Peter, I've just been able to build jdk9/dev forest with bash ./configure --with-debug-level=release --disable-warnings-as-errors make all Mac OS X 10.11.3, Xcode Version 7.2 (7C68) > On 2 Feb 2016, at 18:47, Pete Brunet wrote: > > What is the latest version of XCode we can use to build? I need to > reinstall and am currently at 6.2. From glewis at eyesbeyond.com Wed Feb 3 03:46:23 2016 From: glewis at eyesbeyond.com (Greg Lewis) Date: Tue, 2 Feb 2016 19:46:23 -0800 Subject: RFR: JDK-8147795 Build system support for BSD In-Reply-To: References: <569F6772.50703@oracle.com> <569F6C5C.1020007@oracle.com> <569F7853.8070400@oracle.com> <569FF95C.8060907@oracle.com> <56A0D2B8.2040004@oracle.com> Message-ID: <20160203034623.GA96785@misty.eyesbeyond.com> I've replied to Magnus separately on the freebsd-java mailing list. This is great and I'd love to see it in either the jdk9 mainline or the bsd-port repo of jdk9. The big barrier has always been the volunteer effort required to get past the TCK and fix whatever relatively non-mainstream bugs that are lurking for BSD. I'm aware of people running openjdk8, for instance, for production purposes on FreeBSD and the OpenBSD and NetBSD likewise seem to be kept relatively up to date (or were last time I looked). I haven't had time to work on the full jdk9 port but have been keeping the repo up to date for when time became available or others were able to contribute. It is nice to see the latter starting to happen. - Greg On Thu, Jan 21, 2016 at 11:41:43AM -0800, Eric Richardson wrote: > Hi Magnus, > > I am just an observer here but good work. I have been on this list for a > long time because of my interest in MacOSX and that port so I naturally > thought that BSD would become part of mainline Java too. More platforms for > Java is better. Because of your work I took a look at BSD and the history > along with the birth of GNU Linux. I really didn't know what a great server > platform BSD is or how much it is used. > > I always see Greg Lewis pulling changes into BSD and wondered why it wasn't > part of the main Java repo. It appears that people must use Java but build > from source. Not sure if that is just standard procedure on FreeBSD for > instance. https://www.freebsd.org/java/ I guess it would only take one > variant of BSD to pass the TCK - not sure if BSD was ever in the mainline. > > Anyway, hope you manage to get your changes accepted and you can make more > progress. > Eric > > On Thu, Jan 21, 2016 at 4:44 AM, dalibor topic > wrote: > > > On 20.01.2016 22:17, Magnus Ihse Bursie wrote: > > > >> A reflection, though: If the requirement for such a > >> port is that a company provides continuous testing and support, then I > >> believe it's unlikely that any BSD port will ever reach the mainline, > >> due to the community based nature of the BSD projects. > >> > > > > Community supported ports have been merged into mainline in the past when > > they have passed the TCK with the expectation that they are kept in shape > > by the corresponding (sub)community in OpenJDK, and if they aren't, that > > they'd get dropped out of mainline again. > > > > A JEP would be a second item to look at, of course, now that we have a JEP > > process in place. > > > > Typically, they'd go through the JDK Release Project in development first > > (i.e. JDK 9 now), and then potentially get backported to an Update release > > Project. > > > > With respect to the BSD Port, the FreeBSD Foundation is listed here: > > http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html but > > I'm not sure if they have completed their respective efforts yet. > > > > We already have the BSD Port Project [1], sponsored by the Porters Group > >> [2]. They maintain their own forests. For jdk8, the forest contains a > >> number of patches for BSD. These have not been included upstream, for > >> reasons I can only speculate in. > >> > > > > I think it unfortunately came down to lack of man power among BSD Port > > developers at the time when the dust after the OS X Port's integration into > > JDK 8 settled. [1] > > > > Making it easier for the BSD port to integrate JDK 9 changes sounds fine > > to me, but I'm not a JDK 9/build area Reviewer. > > > > cheers, > > dalibor topic > > > > [1] > > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2014-April/002245.html > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K??hneh??fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M??nchen > > Registergericht: Amtsgericht M??nchen, HRA 95603 > > > > Komplement??rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch??ftsf??hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From erik.joelsson at oracle.com Wed Feb 3 12:48:00 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Feb 2016 13:48:00 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio Message-ID: <56B1F700.1040401@oracle.com> Hello, Please review this small fix for building on Solaris using a devkit/sysroot. The Solaris Studio compiler does special inlining and intrinsics with system calls, like memcpy. The problem is that it only seems to do this if it finds the definition of the system call in a header file in the /usr/include directory. See bug description and comments for details. I have found a way to work around this. Internally, the compiler adds the option -I-xbuiltin to mark the start of the system header includes when calling a sub process. By adding this to our SYSROOT_CFLAGS, the special inlining is re-enabled. Bug: https://bugs.openjdk.java.net/browse/JDK-8148929 Patch: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -80,8 +80,9 @@ if test "x$OPENJDK_TARGET_OS" = xsolaris; then # 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. - $1SYSROOT_CFLAGS="-I[$]$1SYSROOT/usr/include" + # compile and link command line. Must also add -I-xbuiltin to enable + # inlining of system functions and intrinsics. + $1SYSROOT_CFLAGS="-I-xbuiltin -I[$]$1SYSROOT/usr/include" $1SYSROOT_LDFLAGS="-L[$]$1SYSROOT/usr/lib$OPENJDK_TARGET_CPU_ISADIR \ -L[$]$1SYSROOT/lib$OPENJDK_TARGET_CPU_ISADIR \ -L[$]$1SYSROOT/usr/ccs/lib$OPENJDK_TARGET_CPU_ISADIR" /Erik From david.holmes at oracle.com Wed Feb 3 12:59:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Feb 2016 22:59:06 +1000 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B1F700.1040401@oracle.com> References: <56B1F700.1040401@oracle.com> Message-ID: <56B1F99A.3090106@oracle.com> Hi Erik, On 3/02/2016 10:48 PM, Erik Joelsson wrote: > Hello, > > Please review this small fix for building on Solaris using a > devkit/sysroot. The Solaris Studio compiler does special inlining and > intrinsics with system calls, like memcpy. The problem is that it only > seems to do this if it finds the definition of the system call in a > header file in the /usr/include directory. See bug description and > comments for details. > > I have found a way to work around this. Internally, the compiler adds > the option -I-xbuiltin to mark the start of the system header includes > when calling a sub process. By adding this to our SYSROOT_CFLAGS, the > special inlining is re-enabled. We have no way of knowing whether that will mess with the compilers use of other header files. We seem to be on very thin ice here. We know it fixes this one problem, but we don't know what else it may do! David ---- > Bug: https://bugs.openjdk.java.net/browse/JDK-8148929 > Patch: > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -80,8 +80,9 @@ > if test "x$OPENJDK_TARGET_OS" = xsolaris; then > # 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. > - $1SYSROOT_CFLAGS="-I[$]$1SYSROOT/usr/include" > + # compile and link command line. Must also add -I-xbuiltin to > enable > + # inlining of system functions and intrinsics. > + $1SYSROOT_CFLAGS="-I-xbuiltin -I[$]$1SYSROOT/usr/include" > $1SYSROOT_LDFLAGS="-L[$]$1SYSROOT/usr/lib$OPENJDK_TARGET_CPU_ISADIR \ > -L[$]$1SYSROOT/lib$OPENJDK_TARGET_CPU_ISADIR \ > -L[$]$1SYSROOT/usr/ccs/lib$OPENJDK_TARGET_CPU_ISADIR" > > /Erik From erik.joelsson at oracle.com Wed Feb 3 13:33:09 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Feb 2016 14:33:09 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B1F99A.3090106@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> Message-ID: <56B20195.3050805@oracle.com> On 2016-02-03 13:59, David Holmes wrote: > Hi Erik, > > On 3/02/2016 10:48 PM, Erik Joelsson wrote: >> Hello, >> >> Please review this small fix for building on Solaris using a >> devkit/sysroot. The Solaris Studio compiler does special inlining and >> intrinsics with system calls, like memcpy. The problem is that it only >> seems to do this if it finds the definition of the system call in a >> header file in the /usr/include directory. See bug description and >> comments for details. >> >> I have found a way to work around this. Internally, the compiler adds >> the option -I-xbuiltin to mark the start of the system header includes >> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >> special inlining is re-enabled. > > We have no way of knowing whether that will mess with the compilers > use of other header files. We seem to be on very thin ice here. We > know it fixes this one problem, but we don't know what else it may do! > That is true. But then, we don't really know what else this compiler is doing anyway, as is evident by your latest discovery. The way we live with this is testing. We use the setup we have until it proves not to work, we fix and we test. I'm just trying to do the best I can with what we have. I would much prefer to ditch SS for gcc/clang (where we seem to have way less problems) if it was my choice. I'm not ready to give up the convenience of devkits/portable sysroots just because one of the compilers we (have to) use needs a bit of special handling to behave properly. /Erik From erik.joelsson at oracle.com Wed Feb 3 13:50:27 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Feb 2016 14:50:27 +0100 Subject: RFR: JDK-8148955: libjimage.so compiled with wrong flags Message-ID: <56B205A3.1070205@oracle.com> The library libjimage.so consists of C++ source files, but is currently setup to compile using CFLAGS_JDKLIB instead of CXXFLAGS_JDKLIB. On Solaris, these variables contain quite a few differences due to the compilers taking very different arguments. This makes the build process very noisy in the build log. When correcting the flags, the proper warnings were also enabled. I took the liberty of fixing the warning complaining about the variable "i" hiding a variable in the outer scope. Bug: https://bugs.openjdk.java.net/browse/JDK-8148955 Webrev: http://cr.openjdk.java.net/~erikj/8148955/webrev.jdk.01/ /Erik From Alan.Bateman at oracle.com Wed Feb 3 14:34:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Feb 2016 14:34:17 +0000 Subject: RFR: JDK-8148955: libjimage.so compiled with wrong flags In-Reply-To: <56B205A3.1070205@oracle.com> References: <56B205A3.1070205@oracle.com> Message-ID: <56B20FE9.8000301@oracle.com> On 03/02/2016 13:50, Erik Joelsson wrote: > The library libjimage.so consists of C++ source files, but is > currently setup to compile using CFLAGS_JDKLIB instead of > CXXFLAGS_JDKLIB. On Solaris, these variables contain quite a few > differences due to the compilers taking very different arguments. This > makes the build process very noisy in the build log. > > When correcting the flags, the proper warnings were also enabled. I > took the liberty of fixing the warning complaining about the variable > "i" hiding a variable in the outer scope. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148955 > Webrev: http://cr.openjdk.java.net/~erikj/8148955/webrev.jdk.01/ > This looks okay to me. -Alan. From david.dehaven at oracle.com Wed Feb 3 15:54:33 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 3 Feb 2016 07:54:33 -0800 Subject: latest version of XCode? In-Reply-To: <56B0F9D9.7010907@oracle.com> References: <56B0F9D9.7010907@oracle.com> Message-ID: <5DB57636-D349-491C-9E69-C90B660106CD@oracle.com> > What is the latest version of XCode we can use to build? I need to > reinstall and am currently at 6.2. You can copy Xcode to a different location and use "sudo xcode-select -switch /path/to/old/Xcode.app" if you ever need to go back. Just keep older copies of Xcode.app out of /Applications or App Store will delete them for you. -DrD- From magnus.ihse.bursie at oracle.com Thu Feb 4 11:27:37 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Feb 2016 12:27:37 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B20195.3050805@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> Message-ID: <56B335A9.7010508@oracle.com> On 2016-02-03 14:33, Erik Joelsson wrote: > > > On 2016-02-03 13:59, David Holmes wrote: >> Hi Erik, >> >> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this small fix for building on Solaris using a >>> devkit/sysroot. The Solaris Studio compiler does special inlining and >>> intrinsics with system calls, like memcpy. The problem is that it only >>> seems to do this if it finds the definition of the system call in a >>> header file in the /usr/include directory. See bug description and >>> comments for details. >>> >>> I have found a way to work around this. Internally, the compiler adds >>> the option -I-xbuiltin to mark the start of the system header includes >>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >>> special inlining is re-enabled. >> >> We have no way of knowing whether that will mess with the compilers >> use of other header files. We seem to be on very thin ice here. We >> know it fixes this one problem, but we don't know what else it may do! >> > That is true. But then, we don't really know what else this compiler > is doing anyway, as is evident by your latest discovery. The way we > live with this is testing. We use the setup we have until it proves > not to work, we fix and we test. I'm just trying to do the best I can > with what we have. I would much prefer to ditch SS for gcc/clang > (where we seem to have way less problems) if it was my choice. I'm not > ready to give up the convenience of devkits/portable sysroots just > because one of the compilers we (have to) use needs a bit of special > handling to behave properly. I agree that this is a situation that's not really comfortable. :( But, as with many other things with the solaris studio compiler, in the end it's a result of the limited functionality of that compiler (in this case, the lack of a properly functioning --sysroot alternative). So in light of that, and Erik's comment about testing as the only way to be sure, I'd like to see Eriks fix get in. /Magnus > > /Erik From david.holmes at oracle.com Thu Feb 4 12:29:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Feb 2016 22:29:05 +1000 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B335A9.7010508@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> Message-ID: <56B34411.5040809@oracle.com> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: > On 2016-02-03 14:33, Erik Joelsson wrote: >> >> >> On 2016-02-03 13:59, David Holmes wrote: >>> Hi Erik, >>> >>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this small fix for building on Solaris using a >>>> devkit/sysroot. The Solaris Studio compiler does special inlining and >>>> intrinsics with system calls, like memcpy. The problem is that it only >>>> seems to do this if it finds the definition of the system call in a >>>> header file in the /usr/include directory. See bug description and >>>> comments for details. >>>> >>>> I have found a way to work around this. Internally, the compiler adds >>>> the option -I-xbuiltin to mark the start of the system header includes >>>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >>>> special inlining is re-enabled. >>> >>> We have no way of knowing whether that will mess with the compilers >>> use of other header files. We seem to be on very thin ice here. We >>> know it fixes this one problem, but we don't know what else it may do! >>> >> That is true. But then, we don't really know what else this compiler >> is doing anyway, as is evident by your latest discovery. The way we >> live with this is testing. We use the setup we have until it proves >> not to work, we fix and we test. I'm just trying to do the best I can >> with what we have. I would much prefer to ditch SS for gcc/clang >> (where we seem to have way less problems) if it was my choice. I'm not >> ready to give up the convenience of devkits/portable sysroots just >> because one of the compilers we (have to) use needs a bit of special >> handling to behave properly. > > I agree that this is a situation that's not really comfortable. :( But, > as with many other things with the solaris studio compiler, in the end > it's a result of the limited functionality of that compiler (in this > case, the lack of a properly functioning --sysroot alternative). > > So in light of that, and Erik's comment about testing as the only way to > be sure, I'd like to see Eriks fix get in. Do we have the means to do a binary comparison of the object files before/after the change to ascertain what kind of affect this is having? Thanks, David > /Magnus > > >> >> /Erik > From erik.joelsson at oracle.com Thu Feb 4 12:43:19 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Feb 2016 13:43:19 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B34411.5040809@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> Message-ID: <56B34767.6050709@oracle.com> I will investigate and report back. /Erik On 2016-02-04 13:29, David Holmes wrote: > On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >> On 2016-02-03 14:33, Erik Joelsson wrote: >>> >>> >>> On 2016-02-03 13:59, David Holmes wrote: >>>> Hi Erik, >>>> >>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix for building on Solaris using a >>>>> devkit/sysroot. The Solaris Studio compiler does special inlining and >>>>> intrinsics with system calls, like memcpy. The problem is that it >>>>> only >>>>> seems to do this if it finds the definition of the system call in a >>>>> header file in the /usr/include directory. See bug description and >>>>> comments for details. >>>>> >>>>> I have found a way to work around this. Internally, the compiler adds >>>>> the option -I-xbuiltin to mark the start of the system header >>>>> includes >>>>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >>>>> special inlining is re-enabled. >>>> >>>> We have no way of knowing whether that will mess with the compilers >>>> use of other header files. We seem to be on very thin ice here. We >>>> know it fixes this one problem, but we don't know what else it may do! >>>> >>> That is true. But then, we don't really know what else this compiler >>> is doing anyway, as is evident by your latest discovery. The way we >>> live with this is testing. We use the setup we have until it proves >>> not to work, we fix and we test. I'm just trying to do the best I can >>> with what we have. I would much prefer to ditch SS for gcc/clang >>> (where we seem to have way less problems) if it was my choice. I'm not >>> ready to give up the convenience of devkits/portable sysroots just >>> because one of the compilers we (have to) use needs a bit of special >>> handling to behave properly. >> >> I agree that this is a situation that's not really comfortable. :( But, >> as with many other things with the solaris studio compiler, in the end >> it's a result of the limited functionality of that compiler (in this >> case, the lack of a properly functioning --sysroot alternative). >> >> So in light of that, and Erik's comment about testing as the only way to >> be sure, I'd like to see Eriks fix get in. > > Do we have the means to do a binary comparison of the object files > before/after the change to ascertain what kind of affect this is having? > > Thanks, > David > >> /Magnus >> >> >>> >>> /Erik >> From erik.joelsson at oracle.com Thu Feb 4 13:51:25 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Feb 2016 14:51:25 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B34767.6050709@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> Message-ID: <56B3575D.1050902@oracle.com> Differences are extensive in most C++ object files. The problem with viewing dissassembly diffs is that any difference tend to change all addresses later in the file. /Erik On 2016-02-04 13:43, Erik Joelsson wrote: > I will investigate and report back. > > /Erik > > On 2016-02-04 13:29, David Holmes wrote: >> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>> >>>> >>>> On 2016-02-03 13:59, David Holmes wrote: >>>>> Hi Erik, >>>>> >>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this small fix for building on Solaris using a >>>>>> devkit/sysroot. The Solaris Studio compiler does special inlining >>>>>> and >>>>>> intrinsics with system calls, like memcpy. The problem is that it >>>>>> only >>>>>> seems to do this if it finds the definition of the system call in a >>>>>> header file in the /usr/include directory. See bug description and >>>>>> comments for details. >>>>>> >>>>>> I have found a way to work around this. Internally, the compiler >>>>>> adds >>>>>> the option -I-xbuiltin to mark the start of the system header >>>>>> includes >>>>>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, >>>>>> the >>>>>> special inlining is re-enabled. >>>>> >>>>> We have no way of knowing whether that will mess with the compilers >>>>> use of other header files. We seem to be on very thin ice here. We >>>>> know it fixes this one problem, but we don't know what else it may >>>>> do! >>>>> >>>> That is true. But then, we don't really know what else this compiler >>>> is doing anyway, as is evident by your latest discovery. The way we >>>> live with this is testing. We use the setup we have until it proves >>>> not to work, we fix and we test. I'm just trying to do the best I can >>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>> (where we seem to have way less problems) if it was my choice. I'm not >>>> ready to give up the convenience of devkits/portable sysroots just >>>> because one of the compilers we (have to) use needs a bit of special >>>> handling to behave properly. >>> >>> I agree that this is a situation that's not really comfortable. :( But, >>> as with many other things with the solaris studio compiler, in the end >>> it's a result of the limited functionality of that compiler (in this >>> case, the lack of a properly functioning --sysroot alternative). >>> >>> So in light of that, and Erik's comment about testing as the only >>> way to >>> be sure, I'd like to see Eriks fix get in. >> >> Do we have the means to do a binary comparison of the object files >> before/after the change to ascertain what kind of affect this is having? >> >> Thanks, >> David >> >>> /Magnus >>> >>> >>>> >>>> /Erik >>> > From erik.joelsson at oracle.com Thu Feb 4 15:56:36 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Feb 2016 16:56:36 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B3575D.1050902@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> <56B3575D.1050902@oracle.com> Message-ID: <56B374B4.9040703@oracle.com> A full hotspot run of all solaris targets succeeded with the change. /Erik On 2016-02-04 14:51, Erik Joelsson wrote: > Differences are extensive in most C++ object files. The problem with > viewing dissassembly diffs is that any difference tend to change all > addresses later in the file. > > /Erik > > On 2016-02-04 13:43, Erik Joelsson wrote: >> I will investigate and report back. >> >> /Erik >> >> On 2016-02-04 13:29, David Holmes wrote: >>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>> >>>>> >>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>> Hi Erik, >>>>>> >>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix for building on Solaris using a >>>>>>> devkit/sysroot. The Solaris Studio compiler does special >>>>>>> inlining and >>>>>>> intrinsics with system calls, like memcpy. The problem is that >>>>>>> it only >>>>>>> seems to do this if it finds the definition of the system call in a >>>>>>> header file in the /usr/include directory. See bug description and >>>>>>> comments for details. >>>>>>> >>>>>>> I have found a way to work around this. Internally, the compiler >>>>>>> adds >>>>>>> the option -I-xbuiltin to mark the start of the system header >>>>>>> includes >>>>>>> when calling a sub process. By adding this to our >>>>>>> SYSROOT_CFLAGS, the >>>>>>> special inlining is re-enabled. >>>>>> >>>>>> We have no way of knowing whether that will mess with the compilers >>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>> know it fixes this one problem, but we don't know what else it >>>>>> may do! >>>>>> >>>>> That is true. But then, we don't really know what else this compiler >>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>> live with this is testing. We use the setup we have until it proves >>>>> not to work, we fix and we test. I'm just trying to do the best I can >>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>> (where we seem to have way less problems) if it was my choice. I'm >>>>> not >>>>> ready to give up the convenience of devkits/portable sysroots just >>>>> because one of the compilers we (have to) use needs a bit of special >>>>> handling to behave properly. >>>> >>>> I agree that this is a situation that's not really comfortable. :( >>>> But, >>>> as with many other things with the solaris studio compiler, in the end >>>> it's a result of the limited functionality of that compiler (in this >>>> case, the lack of a properly functioning --sysroot alternative). >>>> >>>> So in light of that, and Erik's comment about testing as the only >>>> way to >>>> be sure, I'd like to see Eriks fix get in. >>> >>> Do we have the means to do a binary comparison of the object files >>> before/after the change to ascertain what kind of affect this is >>> having? >>> >>> Thanks, >>> David >>> >>>> /Magnus >>>> >>>> >>>>> >>>>> /Erik >>>> >> > From magnus.ihse.bursie at oracle.com Thu Feb 4 20:33:03 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Feb 2016 21:33:03 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B3575D.1050902@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> <56B3575D.1050902@oracle.com> Message-ID: <31807A68-6DD4-4FE2-B074-3EDE0A11261C@oracle.com> Blir det skillnader mot v?rt gamla bygge med devkit men utan din nya fix, eller mellan devkit med din fix och en icke-devkit d?r man inte anv?nder sysroot? Dvs kan din fix g?ra s? att devkit blir identiskt med utan devkit? /Magnus > 4 feb. 2016 kl. 14:51 skrev Erik Joelsson : > > Differences are extensive in most C++ object files. The problem with viewing dissassembly diffs is that any difference tend to change all addresses later in the file. > > /Erik > >> On 2016-02-04 13:43, Erik Joelsson wrote: >> I will investigate and report back. >> >> /Erik >> >>> On 2016-02-04 13:29, David Holmes wrote: >>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>> >>>>> >>>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>> Hi Erik, >>>>>> >>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix for building on Solaris using a >>>>>>> devkit/sysroot. The Solaris Studio compiler does special inlining and >>>>>>> intrinsics with system calls, like memcpy. The problem is that it only >>>>>>> seems to do this if it finds the definition of the system call in a >>>>>>> header file in the /usr/include directory. See bug description and >>>>>>> comments for details. >>>>>>> >>>>>>> I have found a way to work around this. Internally, the compiler adds >>>>>>> the option -I-xbuiltin to mark the start of the system header includes >>>>>>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >>>>>>> special inlining is re-enabled. >>>>>> >>>>>> We have no way of knowing whether that will mess with the compilers >>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>> know it fixes this one problem, but we don't know what else it may do! >>>>> That is true. But then, we don't really know what else this compiler >>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>> live with this is testing. We use the setup we have until it proves >>>>> not to work, we fix and we test. I'm just trying to do the best I can >>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>> (where we seem to have way less problems) if it was my choice. I'm not >>>>> ready to give up the convenience of devkits/portable sysroots just >>>>> because one of the compilers we (have to) use needs a bit of special >>>>> handling to behave properly. >>>> >>>> I agree that this is a situation that's not really comfortable. :( But, >>>> as with many other things with the solaris studio compiler, in the end >>>> it's a result of the limited functionality of that compiler (in this >>>> case, the lack of a properly functioning --sysroot alternative). >>>> >>>> So in light of that, and Erik's comment about testing as the only way to >>>> be sure, I'd like to see Eriks fix get in. >>> >>> Do we have the means to do a binary comparison of the object files before/after the change to ascertain what kind of affect this is having? >>> >>> Thanks, >>> David >>> >>>> /Magnus >>>> >>>> >>>>> >>>>> /Erik > From magnus.ihse.bursie at oracle.com Thu Feb 4 20:37:13 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Feb 2016 21:37:13 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <31807A68-6DD4-4FE2-B074-3EDE0A11261C@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> <56B3575D.1050902@oracle.com> <31807A68-6DD4-4FE2-B074-3EDE0A11261C@oracle.com> Message-ID: <56B3B679.6040604@oracle.com> On 2016-02-04 21:33, Magnus Ihse Bursie wrote: > Blir det skillnader mot v?rt gamla bygge med devkit men utan din nya fix, eller mellan devkit med din fix och en icke-devkit d?r man inte anv?nder sysroot? Dvs kan din fix g?ra s? att devkit blir identiskt med utan devkit? I apologize for this, it was intended to be a personal email to Erik but I accidentally hit "Reply all" instead. /Magnus > > /Magnus > >> 4 feb. 2016 kl. 14:51 skrev Erik Joelsson : >> >> Differences are extensive in most C++ object files. The problem with viewing dissassembly diffs is that any difference tend to change all addresses later in the file. >> >> /Erik >> >>> On 2016-02-04 13:43, Erik Joelsson wrote: >>> I will investigate and report back. >>> >>> /Erik >>> >>>> On 2016-02-04 13:29, David Holmes wrote: >>>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>>> >>>>>> >>>>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this small fix for building on Solaris using a >>>>>>>> devkit/sysroot. The Solaris Studio compiler does special inlining and >>>>>>>> intrinsics with system calls, like memcpy. The problem is that it only >>>>>>>> seems to do this if it finds the definition of the system call in a >>>>>>>> header file in the /usr/include directory. See bug description and >>>>>>>> comments for details. >>>>>>>> >>>>>>>> I have found a way to work around this. Internally, the compiler adds >>>>>>>> the option -I-xbuiltin to mark the start of the system header includes >>>>>>>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >>>>>>>> special inlining is re-enabled. >>>>>>> We have no way of knowing whether that will mess with the compilers >>>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>>> know it fixes this one problem, but we don't know what else it may do! >>>>>> That is true. But then, we don't really know what else this compiler >>>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>>> live with this is testing. We use the setup we have until it proves >>>>>> not to work, we fix and we test. I'm just trying to do the best I can >>>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>>> (where we seem to have way less problems) if it was my choice. I'm not >>>>>> ready to give up the convenience of devkits/portable sysroots just >>>>>> because one of the compilers we (have to) use needs a bit of special >>>>>> handling to behave properly. >>>>> I agree that this is a situation that's not really comfortable. :( But, >>>>> as with many other things with the solaris studio compiler, in the end >>>>> it's a result of the limited functionality of that compiler (in this >>>>> case, the lack of a properly functioning --sysroot alternative). >>>>> >>>>> So in light of that, and Erik's comment about testing as the only way to >>>>> be sure, I'd like to see Eriks fix get in. >>>> Do we have the means to do a binary comparison of the object files before/after the change to ascertain what kind of affect this is having? >>>> >>>> Thanks, >>>> David >>>> >>>>> /Magnus >>>>> >>>>> >>>>>> /Erik From erik.joelsson at oracle.com Thu Feb 4 21:55:04 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Feb 2016 22:55:04 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B374B4.9040703@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> <56B3575D.1050902@oracle.com> <56B374B4.9040703@oracle.com> Message-ID: <56B3C8B8.9070500@oracle.com> I followed a suggestion from Magnus to compare a devkit build using the new option with a non devkit build, on a Solaris machine with as close to a matching install as the sysroot as I could find. The comparison of libjvm.so is clean according to compare.sh. (Comparing the sorted list of symbols, dependencies, and disassembly output where dynamically generated symbols and addresses have been filtered out) With this I feel pretty confident about adding the new option. /Erik On 2016-02-04 16:56, Erik Joelsson wrote: > A full hotspot run of all solaris targets succeeded with the change. > > /Erik > > On 2016-02-04 14:51, Erik Joelsson wrote: >> Differences are extensive in most C++ object files. The problem with >> viewing dissassembly diffs is that any difference tend to change all >> addresses later in the file. >> >> /Erik >> >> On 2016-02-04 13:43, Erik Joelsson wrote: >>> I will investigate and report back. >>> >>> /Erik >>> >>> On 2016-02-04 13:29, David Holmes wrote: >>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>>> >>>>>> >>>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>>> Hi Erik, >>>>>>> >>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this small fix for building on Solaris using a >>>>>>>> devkit/sysroot. The Solaris Studio compiler does special >>>>>>>> inlining and >>>>>>>> intrinsics with system calls, like memcpy. The problem is that >>>>>>>> it only >>>>>>>> seems to do this if it finds the definition of the system call >>>>>>>> in a >>>>>>>> header file in the /usr/include directory. See bug description and >>>>>>>> comments for details. >>>>>>>> >>>>>>>> I have found a way to work around this. Internally, the >>>>>>>> compiler adds >>>>>>>> the option -I-xbuiltin to mark the start of the system header >>>>>>>> includes >>>>>>>> when calling a sub process. By adding this to our >>>>>>>> SYSROOT_CFLAGS, the >>>>>>>> special inlining is re-enabled. >>>>>>> >>>>>>> We have no way of knowing whether that will mess with the compilers >>>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>>> know it fixes this one problem, but we don't know what else it >>>>>>> may do! >>>>>>> >>>>>> That is true. But then, we don't really know what else this compiler >>>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>>> live with this is testing. We use the setup we have until it proves >>>>>> not to work, we fix and we test. I'm just trying to do the best I >>>>>> can >>>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>>> (where we seem to have way less problems) if it was my choice. >>>>>> I'm not >>>>>> ready to give up the convenience of devkits/portable sysroots just >>>>>> because one of the compilers we (have to) use needs a bit of special >>>>>> handling to behave properly. >>>>> >>>>> I agree that this is a situation that's not really comfortable. :( >>>>> But, >>>>> as with many other things with the solaris studio compiler, in the >>>>> end >>>>> it's a result of the limited functionality of that compiler (in this >>>>> case, the lack of a properly functioning --sysroot alternative). >>>>> >>>>> So in light of that, and Erik's comment about testing as the only >>>>> way to >>>>> be sure, I'd like to see Eriks fix get in. >>>> >>>> Do we have the means to do a binary comparison of the object files >>>> before/after the change to ascertain what kind of affect this is >>>> having? >>>> >>>> Thanks, >>>> David >>>> >>>>> /Magnus >>>>> >>>>> >>>>>> >>>>>> /Erik >>>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Feb 4 22:07:55 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Feb 2016 23:07:55 +0100 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B3C8B8.9070500@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> <56B3575D.1050902@oracle.com> <56B374B4.9040703@oracle.com> <56B3C8B8.9070500@oracle.com> Message-ID: <56B3CBBB.1000508@oracle.com> On 2016-02-04 22:55, Erik Joelsson wrote: > I followed a suggestion from Magnus to compare a devkit build using > the new option with a non devkit build, on a Solaris machine with as > close to a matching install as the sysroot as I could find. The > comparison of libjvm.so is clean according to compare.sh. (Comparing > the sorted list of symbols, dependencies, and disassembly output where > dynamically generated symbols and addresses have been filtered out) Sounds good. > > With this I feel pretty confident about adding the new option. Me too. /Magnus > > /Erik > > On 2016-02-04 16:56, Erik Joelsson wrote: >> A full hotspot run of all solaris targets succeeded with the change. >> >> /Erik >> >> On 2016-02-04 14:51, Erik Joelsson wrote: >>> Differences are extensive in most C++ object files. The problem with >>> viewing dissassembly diffs is that any difference tend to change all >>> addresses later in the file. >>> >>> /Erik >>> >>> On 2016-02-04 13:43, Erik Joelsson wrote: >>>> I will investigate and report back. >>>> >>>> /Erik >>>> >>>> On 2016-02-04 13:29, David Holmes wrote: >>>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>>>> >>>>>>> >>>>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review this small fix for building on Solaris using a >>>>>>>>> devkit/sysroot. The Solaris Studio compiler does special >>>>>>>>> inlining and >>>>>>>>> intrinsics with system calls, like memcpy. The problem is that >>>>>>>>> it only >>>>>>>>> seems to do this if it finds the definition of the system call >>>>>>>>> in a >>>>>>>>> header file in the /usr/include directory. See bug description >>>>>>>>> and >>>>>>>>> comments for details. >>>>>>>>> >>>>>>>>> I have found a way to work around this. Internally, the >>>>>>>>> compiler adds >>>>>>>>> the option -I-xbuiltin to mark the start of the system header >>>>>>>>> includes >>>>>>>>> when calling a sub process. By adding this to our >>>>>>>>> SYSROOT_CFLAGS, the >>>>>>>>> special inlining is re-enabled. >>>>>>>> >>>>>>>> We have no way of knowing whether that will mess with the >>>>>>>> compilers >>>>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>>>> know it fixes this one problem, but we don't know what else it >>>>>>>> may do! >>>>>>>> >>>>>>> That is true. But then, we don't really know what else this >>>>>>> compiler >>>>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>>>> live with this is testing. We use the setup we have until it proves >>>>>>> not to work, we fix and we test. I'm just trying to do the best >>>>>>> I can >>>>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>>>> (where we seem to have way less problems) if it was my choice. >>>>>>> I'm not >>>>>>> ready to give up the convenience of devkits/portable sysroots just >>>>>>> because one of the compilers we (have to) use needs a bit of >>>>>>> special >>>>>>> handling to behave properly. >>>>>> >>>>>> I agree that this is a situation that's not really comfortable. >>>>>> :( But, >>>>>> as with many other things with the solaris studio compiler, in >>>>>> the end >>>>>> it's a result of the limited functionality of that compiler (in this >>>>>> case, the lack of a properly functioning --sysroot alternative). >>>>>> >>>>>> So in light of that, and Erik's comment about testing as the only >>>>>> way to >>>>>> be sure, I'd like to see Eriks fix get in. >>>>> >>>>> Do we have the means to do a binary comparison of the object files >>>>> before/after the change to ascertain what kind of affect this is >>>>> having? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>>> >>>>>>> /Erik >>>>>> >>>> >>> >> > From david.holmes at oracle.com Fri Feb 5 00:50:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Feb 2016 10:50:43 +1000 Subject: RFR: JDK-8148929: Suboptimal code generated when setting sysroot include with Solaris Studio In-Reply-To: <56B3CBBB.1000508@oracle.com> References: <56B1F700.1040401@oracle.com> <56B1F99A.3090106@oracle.com> <56B20195.3050805@oracle.com> <56B335A9.7010508@oracle.com> <56B34411.5040809@oracle.com> <56B34767.6050709@oracle.com> <56B3575D.1050902@oracle.com> <56B374B4.9040703@oracle.com> <56B3C8B8.9070500@oracle.com> <56B3CBBB.1000508@oracle.com> Message-ID: <56B3F1E3.3000309@oracle.com> On 5/02/2016 8:07 AM, Magnus Ihse Bursie wrote: > On 2016-02-04 22:55, Erik Joelsson wrote: >> I followed a suggestion from Magnus to compare a devkit build using >> the new option with a non devkit build, on a Solaris machine with as >> close to a matching install as the sysroot as I could find. The >> comparison of libjvm.so is clean according to compare.sh. (Comparing >> the sorted list of symbols, dependencies, and disassembly output where >> dynamically generated symbols and addresses have been filtered out) > Sounds good. >> >> With this I feel pretty confident about adding the new option. > Me too. Me three. Thanks for doing the validation work. David > /Magnus > >> >> /Erik >> >> On 2016-02-04 16:56, Erik Joelsson wrote: >>> A full hotspot run of all solaris targets succeeded with the change. >>> >>> /Erik >>> >>> On 2016-02-04 14:51, Erik Joelsson wrote: >>>> Differences are extensive in most C++ object files. The problem with >>>> viewing dissassembly diffs is that any difference tend to change all >>>> addresses later in the file. >>>> >>>> /Erik >>>> >>>> On 2016-02-04 13:43, Erik Joelsson wrote: >>>>> I will investigate and report back. >>>>> >>>>> /Erik >>>>> >>>>> On 2016-02-04 13:29, David Holmes wrote: >>>>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>>>>> Hi Erik, >>>>>>>>> >>>>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review this small fix for building on Solaris using a >>>>>>>>>> devkit/sysroot. The Solaris Studio compiler does special >>>>>>>>>> inlining and >>>>>>>>>> intrinsics with system calls, like memcpy. The problem is that >>>>>>>>>> it only >>>>>>>>>> seems to do this if it finds the definition of the system call >>>>>>>>>> in a >>>>>>>>>> header file in the /usr/include directory. See bug description >>>>>>>>>> and >>>>>>>>>> comments for details. >>>>>>>>>> >>>>>>>>>> I have found a way to work around this. Internally, the >>>>>>>>>> compiler adds >>>>>>>>>> the option -I-xbuiltin to mark the start of the system header >>>>>>>>>> includes >>>>>>>>>> when calling a sub process. By adding this to our >>>>>>>>>> SYSROOT_CFLAGS, the >>>>>>>>>> special inlining is re-enabled. >>>>>>>>> >>>>>>>>> We have no way of knowing whether that will mess with the >>>>>>>>> compilers >>>>>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>>>>> know it fixes this one problem, but we don't know what else it >>>>>>>>> may do! >>>>>>>>> >>>>>>>> That is true. But then, we don't really know what else this >>>>>>>> compiler >>>>>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>>>>> live with this is testing. We use the setup we have until it proves >>>>>>>> not to work, we fix and we test. I'm just trying to do the best >>>>>>>> I can >>>>>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>>>>> (where we seem to have way less problems) if it was my choice. >>>>>>>> I'm not >>>>>>>> ready to give up the convenience of devkits/portable sysroots just >>>>>>>> because one of the compilers we (have to) use needs a bit of >>>>>>>> special >>>>>>>> handling to behave properly. >>>>>>> >>>>>>> I agree that this is a situation that's not really comfortable. >>>>>>> :( But, >>>>>>> as with many other things with the solaris studio compiler, in >>>>>>> the end >>>>>>> it's a result of the limited functionality of that compiler (in this >>>>>>> case, the lack of a properly functioning --sysroot alternative). >>>>>>> >>>>>>> So in light of that, and Erik's comment about testing as the only >>>>>>> way to >>>>>>> be sure, I'd like to see Eriks fix get in. >>>>>> >>>>>> Do we have the means to do a binary comparison of the object files >>>>>> before/after the change to ascertain what kind of affect this is >>>>>> having? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> /Erik >>>>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Fri Feb 5 09:05:55 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Feb 2016 10:05:55 +0100 Subject: RFR: JDK-8148629: Disable remaining warnings in awt/fontmanager Message-ID: <56B465F3.4050001@oracle.com> A while back, Magnus did a tremendous job of disabling most warnings in the JDK native libraries and enabling warnings as errors on most of them. However, some libraries, typically awt related, proved to be harder. One of the reasons was that some toolchains had different warning labels specified for C vs C++ and would not accept the other kind without printing new warning. For libraries containing both C and C++ source files, this prevented us from disabling all warnings. This limitation in SetupNativeCompilation has since been fixed so I could use that functionality to disable most remaining warnings. Another reason is that some source files contain warnings that are deemed severe enough by the compiler that they can't be individually ignored. Since the team owning that source seem unwilling to fix these warnings anyway, I have simply disabled all warnings on those specific files, for the specific toolchains where it applies. I have tried to add descriptive comments explaining each such occurrence. I have tested this by building a full hotspot job and an openjdk only job in JPRT. It is possible that people building with other toolchain versions than Oracle will start seeing new build failures because of more warnings in these libraries. In that case, either --disable-warnings-as-errors, submit fixes for the warnings, or add more warning ignores. Bug: https://bugs.openjdk.java.net/browse/JDK-8148629 Webrev: http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.01/ /Erik From erik.joelsson at oracle.com Fri Feb 5 09:41:38 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Feb 2016 10:41:38 +0100 Subject: RFR: JDK-8148629: Disable remaining warnings in awt/fontmanager In-Reply-To: <56B465F3.4050001@oracle.com> References: <56B465F3.4050001@oracle.com> Message-ID: <56B46E52.5030609@oracle.com> Magnus pointed out that I mistakenly replaced fno-strict-aliasing with -Wno-strict-aliasing. Reverted that change. http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.02/ /Erik On 2016-02-05 10:05, Erik Joelsson wrote: > A while back, Magnus did a tremendous job of disabling most warnings > in the JDK native libraries and enabling warnings as errors on most of > them. However, some libraries, typically awt related, proved to be > harder. > > One of the reasons was that some toolchains had different warning > labels specified for C vs C++ and would not accept the other kind > without printing new warning. For libraries containing both C and C++ > source files, this prevented us from disabling all warnings. This > limitation in SetupNativeCompilation has since been fixed so I could > use that functionality to disable most remaining warnings. > > Another reason is that some source files contain warnings that are > deemed severe enough by the compiler that they can't be individually > ignored. Since the team owning that source seem unwilling to fix these > warnings anyway, I have simply disabled all warnings on those specific > files, for the specific toolchains where it applies. I have tried to > add descriptive comments explaining each such occurrence. > > I have tested this by building a full hotspot job and an openjdk only > job in JPRT. It is possible that people building with other toolchain > versions than Oracle will start seeing new build failures because of > more warnings in these libraries. In that case, either > --disable-warnings-as-errors, submit fixes for the warnings, or add > more warning ignores. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8148629 > Webrev: http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.01/ > > /Erik From magnus.ihse.bursie at oracle.com Fri Feb 5 10:48:49 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 5 Feb 2016 11:48:49 +0100 Subject: RFR: JDK-8129395 Configure should verify that -fstack-protector is valid - take 2 Message-ID: <56B47E11.9060703@oracle.com> A previous fix to check if -fstack-protector is accepted by gcc failed, since when testing the option, gcc emitted a warning and not an error. The one thing I'm thinking here about is if the ssp-buffer-size option should be more tightly coupled with the -fstack-protector flag. It does not harm to have it without the -f flag, but it seems a bit funny. Opinions? I also noted that this flag is added to CFLAGS_DEBUG_OPTIONS. This means that it only gets activated if we generate debug symbols. For Oracle builds we always do so it doesn't really matter, but I'd say that it's technically incorrect. I'd rather not fix that now, though, but save it for the upcoming and long overdue cleanup of flags handling. Bug: https://bugs.openjdk.java.net/browse/JDK-8129395 Patch inline: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -1,5 +1,5 @@ # -# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -426,7 +426,7 @@ # Add runtime stack smashing and undefined behavior checks. # Not all versions of gcc support -fstack-protector STACK_PROTECTOR_CFLAG="-fstack-protector-all" - FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param ssp-buffer-size=1" CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param ssp-buffer-size=1" /Magnus From erik.joelsson at oracle.com Fri Feb 5 10:58:45 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Feb 2016 11:58:45 +0100 Subject: RFR: JDK-8129395 Configure should verify that -fstack-protector is valid - take 2 In-Reply-To: <56B47E11.9060703@oracle.com> References: <56B47E11.9060703@oracle.com> Message-ID: <56B48065.2040700@oracle.com> Change looks good. /Erik On 2016-02-05 11:48, Magnus Ihse Bursie wrote: > A previous fix to check if -fstack-protector is accepted by gcc > failed, since when testing the option, gcc emitted a warning and not > an error. > > The one thing I'm thinking here about is if the ssp-buffer-size option > should be more tightly coupled with the -fstack-protector flag. It > does not harm to have it without the -f flag, but it seems a bit > funny. Opinions? > > I also noted that this flag is added to CFLAGS_DEBUG_OPTIONS. This > means that it only gets activated if we generate debug symbols. For > Oracle builds we always do so it doesn't really matter, but I'd say > that it's technically incorrect. I'd rather not fix that now, though, > but save it for the upcoming and long overdue cleanup of flags handling. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129395 > Patch inline: > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -426,7 +426,7 @@ > # Add runtime stack smashing and undefined behavior checks. > # Not all versions of gcc support -fstack-protector > STACK_PROTECTOR_CFLAG="-fstack-protector-all" > - FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: > [$STACK_PROTECTOR_CFLAG], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: > [$STACK_PROTECTOR_CFLAG -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > > CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > > /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 5 12:12:59 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 5 Feb 2016 13:12:59 +0100 Subject: RFR: JDK-8148629: Disable remaining warnings in awt/fontmanager In-Reply-To: <56B46E52.5030609@oracle.com> References: <56B465F3.4050001@oracle.com> <56B46E52.5030609@oracle.com> Message-ID: <56B491CB.6020207@oracle.com> On 2016-02-05 10:41, Erik Joelsson wrote: > Magnus pointed out that I mistakenly replaced fno-strict-aliasing with > -Wno-strict-aliasing. Reverted that change. > > http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.02/ The new webrev looks good to me. However, the use of -w for individual files is a bit scary. :-( It's not easy to grep for (like "WARNINGS_AS_ERRORS") and it's quite broad. Please make sure you update JDK-8079958 and JDK-8079955 with clear instructions on what have been disabled for these libraries, and how to fix this, so this does not get lost. I believe this is the last instance where we had warnings in native compilation printed during every build, so when this is pushed I think it's time for a small celebration. :-) /Magnus > > /Erik > > On 2016-02-05 10:05, Erik Joelsson wrote: >> A while back, Magnus did a tremendous job of disabling most warnings >> in the JDK native libraries and enabling warnings as errors on most >> of them. However, some libraries, typically awt related, proved to be >> harder. >> >> One of the reasons was that some toolchains had different warning >> labels specified for C vs C++ and would not accept the other kind >> without printing new warning. For libraries containing both C and C++ >> source files, this prevented us from disabling all warnings. This >> limitation in SetupNativeCompilation has since been fixed so I could >> use that functionality to disable most remaining warnings. >> >> Another reason is that some source files contain warnings that are >> deemed severe enough by the compiler that they can't be individually >> ignored. Since the team owning that source seem unwilling to fix >> these warnings anyway, I have simply disabled all warnings on those >> specific files, for the specific toolchains where it applies. I have >> tried to add descriptive comments explaining each such occurrence. >> >> I have tested this by building a full hotspot job and an openjdk only >> job in JPRT. It is possible that people building with other toolchain >> versions than Oracle will start seeing new build failures because of >> more warnings in these libraries. In that case, either >> --disable-warnings-as-errors, submit fixes for the warnings, or add >> more warning ignores. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8148629 >> Webrev: http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.01/ >> >> /Erik > From david.holmes at oracle.com Fri Feb 5 12:25:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Feb 2016 22:25:30 +1000 Subject: RFR: JDK-8129395 Configure should verify that -fstack-protector is valid - take 2 In-Reply-To: <56B47E11.9060703@oracle.com> References: <56B47E11.9060703@oracle.com> Message-ID: <56B494BA.80300@oracle.com> Hi Magnus, This seems reasonable. The proof of course is in the testing. Thanks, David On 5/02/2016 8:48 PM, Magnus Ihse Bursie wrote: > A previous fix to check if -fstack-protector is accepted by gcc failed, > since when testing the option, gcc emitted a warning and not an error. > > The one thing I'm thinking here about is if the ssp-buffer-size option > should be more tightly coupled with the -fstack-protector flag. It does > not harm to have it without the -f flag, but it seems a bit funny. > Opinions? > > I also noted that this flag is added to CFLAGS_DEBUG_OPTIONS. This means > that it only gets activated if we generate debug symbols. For Oracle > builds we always do so it doesn't really matter, but I'd say that it's > technically incorrect. I'd rather not fix that now, though, but save it > for the upcoming and long overdue cleanup of flags handling. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129395 > Patch inline: > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights > reserved. > +# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights > reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -426,7 +426,7 @@ > # Add runtime stack smashing and undefined behavior checks. > # Not all versions of gcc support -fstack-protector > STACK_PROTECTOR_CFLAG="-fstack-protector-all" > - FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: > [$STACK_PROTECTOR_CFLAG], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG > -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) > > CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > > /Magnus From erik.helin at oracle.com Fri Feb 5 12:34:39 2016 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Feb 2016 13:34:39 +0100 Subject: 8149116: Make test/Makefile more silent Message-ID: <20160205123439.GG8777@ehelin.jrpg.bea.com> Hi all, this tiny patch makes the common test targets in test/Makefile a bit more silent. The patch silences the `make` command and also silences the "Entering directory" output from make. For example, running `make test-hotspot-internal` currently prints: Building target 'test-hotspot-internal' in configuration 'x64-slow' make[3]: warning: -jN forced in submake: disabling jobserver mode. make -k -C /home/ehelin/code/jdk9/dev/hotspot/test CONCURRENCY=1 TEST=hotspot_internal hotspot_internal make[4]: Entering directory '/home/ehelin/code/jdk9/dev/hotspot/test' and with the patch applied it prints: Building target 'test-hotspot-internal' in configuration 'x64-slow' make[3]: warning: -jN forced in submake: disabling jobserver mode. Unfortunately I don't know how to get rid of the warning "-jN forced in submake" :( Anyway, below is the patch: # HG changeset patch # User ehelin # Date 1454675226 -3600 # Fri Feb 05 13:27:06 2016 +0100 # Node ID e0f7bec5f61d3619e78f4d1683e208012f1709f5 # Parent 3ca929279adbdbbe590abb727dbaf9e4a9c6bf69 8149116: Make test/Makefile more silent diff -r 3ca929279adb -r e0f7bec5f61d test/Makefile --- a/test/Makefile Fri Feb 05 09:41:16 2016 +0100 +++ b/test/Makefile Fri Feb 05 13:27:06 2016 +0100 @@ -40,8 +40,7 @@ define SUBDIR_TEST # subdirectory target if [ -d $1 ] ; then \ if [ -r $1/test/Makefile ] ; then \ - echo "$(MAKE) -k -C $1/test $2" ; \ - $(MAKE) -k -C $1/test $2 ; \ + $(MAKE) --no-print-directory -k -C $1/test $2 ; \ else \ echo "ERROR: File does not exist: $1/test/Makefile"; \ exit 1; \ Thanks, Erik From erik.joelsson at oracle.com Fri Feb 5 12:44:06 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Feb 2016 13:44:06 +0100 Subject: 8149116: Make test/Makefile more silent In-Reply-To: <20160205123439.GG8777@ehelin.jrpg.bea.com> References: <20160205123439.GG8777@ehelin.jrpg.bea.com> Message-ID: <56B49916.7030305@oracle.com> Looks fine by me. The -jN complaint comes from make/MainSupport.gmk where we add -j1 when calling test/Makefile because we don't trust it to handle parallel make execution. /Erik On 2016-02-05 13:34, Erik Helin wrote: > Hi all, > > this tiny patch makes the common test targets in test/Makefile a bit > more silent. The patch silences the `make` command and also silences the > "Entering directory" output from make. For example, running > `make test-hotspot-internal` currently prints: > > Building target 'test-hotspot-internal' in configuration 'x64-slow' > make[3]: warning: -jN forced in submake: disabling jobserver mode. > make -k -C /home/ehelin/code/jdk9/dev/hotspot/test CONCURRENCY=1 TEST=hotspot_internal hotspot_internal > make[4]: Entering directory '/home/ehelin/code/jdk9/dev/hotspot/test' > > and with the patch applied it prints: > > Building target 'test-hotspot-internal' in configuration 'x64-slow' > make[3]: warning: -jN forced in submake: disabling jobserver mode. > > Unfortunately I don't know how to get rid of the warning > "-jN forced in submake" :( Anyway, below is the patch: > > # HG changeset patch > # User ehelin > # Date 1454675226 -3600 > # Fri Feb 05 13:27:06 2016 +0100 > # Node ID e0f7bec5f61d3619e78f4d1683e208012f1709f5 > # Parent 3ca929279adbdbbe590abb727dbaf9e4a9c6bf69 > 8149116: Make test/Makefile more silent > > diff -r 3ca929279adb -r e0f7bec5f61d test/Makefile > --- a/test/Makefile Fri Feb 05 09:41:16 2016 +0100 > +++ b/test/Makefile Fri Feb 05 13:27:06 2016 +0100 > @@ -40,8 +40,7 @@ > define SUBDIR_TEST # subdirectory target > if [ -d $1 ] ; then \ > if [ -r $1/test/Makefile ] ; then \ > - echo "$(MAKE) -k -C $1/test $2" ; \ > - $(MAKE) -k -C $1/test $2 ; \ > + $(MAKE) --no-print-directory -k -C $1/test $2 ; \ > else \ > echo "ERROR: File does not exist: $1/test/Makefile"; \ > exit 1; \ > > Thanks, > Erik From coleen.phillimore at oracle.com Fri Feb 5 16:20:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 5 Feb 2016 11:20:32 -0500 Subject: RFR: JDK-8148629: Disable remaining warnings in awt/fontmanager In-Reply-To: <56B491CB.6020207@oracle.com> References: <56B465F3.4050001@oracle.com> <56B46E52.5030609@oracle.com> <56B491CB.6020207@oracle.com> Message-ID: <56B4CBD0.3030407@oracle.com> On 2/5/16 7:12 AM, Magnus Ihse Bursie wrote: > On 2016-02-05 10:41, Erik Joelsson wrote: >> Magnus pointed out that I mistakenly replaced fno-strict-aliasing >> with -Wno-strict-aliasing. Reverted that change. >> >> http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.02/ > The new webrev looks good to me. > > However, the use of -w for individual files is a bit scary. :-( It's > not easy to grep for (like "WARNINGS_AS_ERRORS") and it's quite broad. > Please make sure you update JDK-8079958 and JDK-8079955 with clear > instructions on what have been disabled for these libraries, and how > to fix this, so this does not get lost. > > I believe this is the last instance where we had warnings in native > compilation printed during every build, so when this is pushed I think > it's time for a small celebration. :-) Yes, I think there should be a party! I don't understand modern makefiles but I think this is really good and better to turn off certain files with -w than all of them. It looks like you turned on warning-as-errors so if awt has new warnings in different files, they can fix them. That seems good. Thanks!! Coleen > > /Magnus > >> >> /Erik >> >> On 2016-02-05 10:05, Erik Joelsson wrote: >>> A while back, Magnus did a tremendous job of disabling most warnings >>> in the JDK native libraries and enabling warnings as errors on most >>> of them. However, some libraries, typically awt related, proved to >>> be harder. >>> >>> One of the reasons was that some toolchains had different warning >>> labels specified for C vs C++ and would not accept the other kind >>> without printing new warning. For libraries containing both C and >>> C++ source files, this prevented us from disabling all warnings. >>> This limitation in SetupNativeCompilation has since been fixed so I >>> could use that functionality to disable most remaining warnings. >>> >>> Another reason is that some source files contain warnings that are >>> deemed severe enough by the compiler that they can't be individually >>> ignored. Since the team owning that source seem unwilling to fix >>> these warnings anyway, I have simply disabled all warnings on those >>> specific files, for the specific toolchains where it applies. I have >>> tried to add descriptive comments explaining each such occurrence. >>> >>> I have tested this by building a full hotspot job and an openjdk >>> only job in JPRT. It is possible that people building with other >>> toolchain versions than Oracle will start seeing new build failures >>> because of more warnings in these libraries. In that case, either >>> --disable-warnings-as-errors, submit fixes for the warnings, or add >>> more warning ignores. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8148629 >>> Webrev: http://cr.openjdk.java.net/~erikj/8148629/webrev.jdk.01/ >>> >>> /Erik >> > From mikael.vidstedt at oracle.com Fri Feb 5 18:26:44 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 5 Feb 2016 10:26:44 -0800 Subject: 8149116: Make test/Makefile more silent In-Reply-To: <56B49916.7030305@oracle.com> References: <20160205123439.GG8777@ehelin.jrpg.bea.com> <56B49916.7030305@oracle.com> Message-ID: <56B4E964.7090901@oracle.com> Looks good, ship it! /Mikael On 2016-02-05 04:44, Erik Joelsson wrote: > Looks fine by me. > > The -jN complaint comes from make/MainSupport.gmk where we add -j1 > when calling test/Makefile because we don't trust it to handle > parallel make execution. > > /Erik > > On 2016-02-05 13:34, Erik Helin wrote: >> Hi all, >> >> this tiny patch makes the common test targets in test/Makefile a bit >> more silent. The patch silences the `make` command and also silences the >> "Entering directory" output from make. For example, running >> `make test-hotspot-internal` currently prints: >> >> Building target 'test-hotspot-internal' in configuration 'x64-slow' >> make[3]: warning: -jN forced in submake: disabling jobserver mode. >> make -k -C /home/ehelin/code/jdk9/dev/hotspot/test CONCURRENCY=1 >> TEST=hotspot_internal hotspot_internal >> make[4]: Entering directory '/home/ehelin/code/jdk9/dev/hotspot/test' >> >> and with the patch applied it prints: >> >> Building target 'test-hotspot-internal' in configuration 'x64-slow' >> make[3]: warning: -jN forced in submake: disabling jobserver mode. >> >> Unfortunately I don't know how to get rid of the warning >> "-jN forced in submake" :( Anyway, below is the patch: >> >> # HG changeset patch >> # User ehelin >> # Date 1454675226 -3600 >> # Fri Feb 05 13:27:06 2016 +0100 >> # Node ID e0f7bec5f61d3619e78f4d1683e208012f1709f5 >> # Parent 3ca929279adbdbbe590abb727dbaf9e4a9c6bf69 >> 8149116: Make test/Makefile more silent >> >> diff -r 3ca929279adb -r e0f7bec5f61d test/Makefile >> --- a/test/Makefile Fri Feb 05 09:41:16 2016 +0100 >> +++ b/test/Makefile Fri Feb 05 13:27:06 2016 +0100 >> @@ -40,8 +40,7 @@ >> define SUBDIR_TEST # subdirectory target >> if [ -d $1 ] ; then \ >> if [ -r $1/test/Makefile ] ; then \ >> - echo "$(MAKE) -k -C $1/test $2" ; \ >> - $(MAKE) -k -C $1/test $2 ; \ >> + $(MAKE) --no-print-directory -k -C $1/test $2 ; \ >> else \ >> echo "ERROR: File does not exist: $1/test/Makefile"; \ >> exit 1; \ >> >> Thanks, >> Erik > From xueming.shen at oracle.com Fri Feb 5 18:55:45 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 5 Feb 2016 10:55:45 -0800 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib Message-ID: <56B4F031.6040501@oracle.com> Hi Please help codereview the change to build the jdk9 runtime to use the system zlib on Solaris and Linux platforms by default. Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ Background info: Compression is heavily used in Java based big data/middle-ware applications. There are many products in market today that help compression performance either through software or hardware acceleration and most likely these products support the zlib interface as API, for example Intel's IPP library has a faster version of compression libraries. To configure the Java runtime to use the system zlib would make these acceleration capabilities available to java users through java.util.zip package directly. The jdk already has a build configuration option to build the jdk to use the system zlib via "--with-zlib=system" and the OSX is by default built to use the system zlib. This proposal is to propose to build the jdk to use the system zlib library (the zlib bundled by the underlying Solaris/ Linuxplatforms), instead of the binary built from source code jdk repository (current 1.2.8 from the open source zlib.org) Thanks, Sherman btw, attached is the similar change in the closed repo: autoconf/generated-configure.sh ------------------------------------------------------------- # Do not change or remove the following line, it is needed for consistency checks: -DATE_WHEN_GENERATED=1454436146 +DATE_WHEN_GENERATED=1454626552 ############################################################################### # # Initialization / Boot-strapping # ------------------------------------------------------------------------ @@ -58839,14 +58839,14 @@ { $as_echo "$as_me:${as_lineno-$LINENO}: checking for which zlib to use" >&5 $as_echo_n "checking for which zlib to use... " >&6; } - DEFAULT_ZLIB=bundled - if test "x$OPENJDK_TARGET_OS" = xmacosx; then - # On macosx default is system...on others default is bundled DEFAULT_ZLIB=system + if test "x$OPENJDK_TARGET_OS" = xwindows; then + # On windows default is bundled...on others default is system + DEFAULT_ZLIB=bundled fi if test "x${ZLIB_FOUND}" != "xyes"; then # If we don't find any system...set default to bundled DEFAULT_ZLIB=bundled From Alan.Bateman at oracle.com Fri Feb 5 20:50:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Feb 2016 20:50:09 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56B4F031.6040501@oracle.com> References: <56B4F031.6040501@oracle.com> Message-ID: <56B50B01.60003@oracle.com> On 05/02/2016 18:55, Xueming Shen wrote: > Hi > > Please help codereview the change to build the jdk9 runtime to use the > system zlib on > Solaris and Linux platforms by default. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 > Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ I'm happy to see the default changed for Linux and Solaris builds. One thing is that the patch to lib-bundled.m4 switches the build on all non-Windows to use the system zlib. This may be something the SAP (AIX port maintainers) might want to comment on. -Alan. From igor.ignatyev at oracle.com Sun Feb 7 21:22:15 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 8 Feb 2016 00:22:15 +0300 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com> Message-ID: <7B6E32C6-67B3-44D8-8A81-0AAC87DE206C@oracle.com> Hi Kim, could you please take a look at the updated webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.03 I agree that ?+w? isn?t related to WARNINGS_ARE_ERRORS, so it was moved to CFLAGS_WARN. Regarding compiler version based conditions, I think it?d be better for build team to decide how to deal w/ them. PS I?ve checked that w/ the patch applied warnings, which normally cause a build error, don?t cause any build errors w/ --disable-warnings-as-errors. Thanks, Igor > On Dec 17, 2015, at 11:30 PM, Kim Barrett wrote: > > On Dec 17, 2015, at 8:22 AM, Igor Ignatyev wrote: >> >> >>> On Dec 17, 2015, at 2:10 AM, Kim Barrett wrote: >>> make/solaris/makefiles/adlc.make >>> 77 WARNINGS_ARE_ERRORS ?= -w -xwe >>> >>> I'm pretty sure "-w" is wrong here, and should be removed. >> you are right, I made a typo, it was ?+w? before. the new webrev : http://cr.openjdk.java.net/~iignatyev/8144695/webrev.02/ >> >>> And it's >>> not clear why this assignment should be conditional on the compiler >>> version. >> it was added as a fix for https://bugs.openjdk.java.net/browse/JDK-6851829, excerpt from Chris?s evaluation: >> >>> Since some of the errors are in system headers we can only disable the "+w -errwarn" on SS11 and below. > > "+w" has nothing to do with warnings being errors; it just turns on > more warnings. So it shouldn't be in WARNINGS_ARE_ERRORS. > > CFLAGS_WARN is (according to various comments) supposed to hold > options to enable/disable warnings, so "+w" there was reasonable, > while -errwarn should not have been there by that definition. > > The conditionalization disables additional warnings and "warnings are > errors" for older compilers that I think we're no longer using for > jdk9. Are we allowed to retire support for such? > > The conditionalization may only be needed for "+w", though without > testing on a no longer officially supported version of the compiler > that would be hard to prove. From erik.helin at oracle.com Mon Feb 8 06:47:49 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 8 Feb 2016 07:47:49 +0100 Subject: 8149116: Make test/Makefile more silent In-Reply-To: <56B4E964.7090901@oracle.com> References: <20160205123439.GG8777@ehelin.jrpg.bea.com> <56B49916.7030305@oracle.com> <56B4E964.7090901@oracle.com> Message-ID: <56B83A15.6050308@oracle.com> Thanks Mikael and Erik! Erik On 02/05/2016 07:26 PM, Mikael Vidstedt wrote: > > Looks good, ship it! > > /Mikael > > On 2016-02-05 04:44, Erik Joelsson wrote: >> Looks fine by me. >> >> The -jN complaint comes from make/MainSupport.gmk where we add -j1 >> when calling test/Makefile because we don't trust it to handle >> parallel make execution. >> >> /Erik >> >> On 2016-02-05 13:34, Erik Helin wrote: >>> Hi all, >>> >>> this tiny patch makes the common test targets in test/Makefile a bit >>> more silent. The patch silences the `make` command and also silences the >>> "Entering directory" output from make. For example, running >>> `make test-hotspot-internal` currently prints: >>> >>> Building target 'test-hotspot-internal' in configuration 'x64-slow' >>> make[3]: warning: -jN forced in submake: disabling jobserver mode. >>> make -k -C /home/ehelin/code/jdk9/dev/hotspot/test CONCURRENCY=1 >>> TEST=hotspot_internal hotspot_internal >>> make[4]: Entering directory '/home/ehelin/code/jdk9/dev/hotspot/test' >>> >>> and with the patch applied it prints: >>> >>> Building target 'test-hotspot-internal' in configuration 'x64-slow' >>> make[3]: warning: -jN forced in submake: disabling jobserver mode. >>> >>> Unfortunately I don't know how to get rid of the warning >>> "-jN forced in submake" :( Anyway, below is the patch: >>> >>> # HG changeset patch >>> # User ehelin >>> # Date 1454675226 -3600 >>> # Fri Feb 05 13:27:06 2016 +0100 >>> # Node ID e0f7bec5f61d3619e78f4d1683e208012f1709f5 >>> # Parent 3ca929279adbdbbe590abb727dbaf9e4a9c6bf69 >>> 8149116: Make test/Makefile more silent >>> >>> diff -r 3ca929279adb -r e0f7bec5f61d test/Makefile >>> --- a/test/Makefile Fri Feb 05 09:41:16 2016 +0100 >>> +++ b/test/Makefile Fri Feb 05 13:27:06 2016 +0100 >>> @@ -40,8 +40,7 @@ >>> define SUBDIR_TEST # subdirectory target >>> if [ -d $1 ] ; then \ >>> if [ -r $1/test/Makefile ] ; then \ >>> - echo "$(MAKE) -k -C $1/test $2" ; \ >>> - $(MAKE) -k -C $1/test $2 ; \ >>> + $(MAKE) --no-print-directory -k -C $1/test $2 ; \ >>> else \ >>> echo "ERROR: File does not exist: $1/test/Makefile"; \ >>> exit 1; \ >>> >>> Thanks, >>> Erik >> > From sean.coffey at oracle.com Mon Feb 8 09:42:22 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 8 Feb 2016 09:42:22 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56B4F031.6040501@oracle.com> References: <56B4F031.6040501@oracle.com> Message-ID: <56B862FE.5000000@oracle.com> Is there an option to fall back to the older v.1.2.8 implementation if necessary ? It would certainly alleviate issues for any applications that might run into issues with the latest and greatest zlib libraries. JDK-8133206 would be one such example. Regards, Sean. On 05/02/2016 18:55, Xueming Shen wrote: > Hi > > Please help codereview the change to build the jdk9 runtime to use the > system zlib on > Solaris and Linux platforms by default. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 > Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ > > Background info: > > Compression is heavily used in Java based big data/middle-ware > applications. > There are many products in market today that help compression performance > either through software or hardware acceleration and most likely these > products > support the zlib interface as API, for example Intel's IPP library has > a faster > version of compression libraries. To configure the Java runtime to use > the system > zlib would make these acceleration capabilities available to java > users through > java.util.zip package directly. The jdk already has a build > configuration option > to build the jdk to use the system zlib via "--with-zlib=system" and > the OSX is > by default built to use the system zlib. This proposal is to propose > to build > the jdk to use the system zlib library (the zlib bundled by the > underlying Solaris/ > Linuxplatforms), instead of the binary built from source code jdk > repository > (current 1.2.8 from the open source zlib.org) > > Thanks, > Sherman > > > btw, attached is the similar change in the closed repo: > autoconf/generated-configure.sh > ------------------------------------------------------------- > > # Do not change or remove the following line, it is needed for > consistency checks: > -DATE_WHEN_GENERATED=1454436146 > +DATE_WHEN_GENERATED=1454626552 > > ############################################################################### > > # > # Initialization / Boot-strapping > # > > ------------------------------------------------------------------------ > > @@ -58839,14 +58839,14 @@ > > > { $as_echo "$as_me:${as_lineno-$LINENO}: checking for which zlib to > use" >&5 > $as_echo_n "checking for which zlib to use... " >&6; } > > - DEFAULT_ZLIB=bundled > - if test "x$OPENJDK_TARGET_OS" = xmacosx; then > - # On macosx default is system...on others default is bundled > DEFAULT_ZLIB=system > + if test "x$OPENJDK_TARGET_OS" = xwindows; then > + # On windows default is bundled...on others default is system > + DEFAULT_ZLIB=bundled > fi > > if test "x${ZLIB_FOUND}" != "xyes"; then > # If we don't find any system...set default to bundled > DEFAULT_ZLIB=bundled > > From Alan.Bateman at oracle.com Mon Feb 8 09:55:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Feb 2016 10:55:47 +0100 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56B862FE.5000000@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> Message-ID: <56B86623.4090602@oracle.com> On 08/02/2016 10:42, Se?n Coffey wrote: > Is there an option to fall back to the older v.1.2.8 implementation if > necessary ? It would certainly alleviate issues for any applications > that might run into issues with the latest and greatest zlib > libraries. JDK-8133206 would be one such example. Just at build time but if the zlib on the platform is broken then it impacts tools and probably lots of things. I would assume the OS would patch such issues quickly. In the case of JDK-8133206 then was the issue addressed in the libzip wrapper or in the zlib code? I thought it was the former. On a fallback or some way to configure at launch time then Sandhya Viswanathan (Intel) has a proposal here last year. I think we mostly agreed on that thread that switching the build to use the system zlib by default would be better. -Alan From magnus.ihse.bursie at oracle.com Mon Feb 8 10:29:41 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Feb 2016 11:29:41 +0100 Subject: RFR: JDK-8129395 Configure should verify that -fstack-protector is valid - take 2 In-Reply-To: <56B494BA.80300@oracle.com> References: <56B47E11.9060703@oracle.com> <56B494BA.80300@oracle.com> Message-ID: <56B86E15.7000805@oracle.com> On 2016-02-05 13:25, David Holmes wrote: > Hi Magnus, > > This seems reasonable. The proof of course is in the testing. Testing on our JPRT systems that include a gcc which does not support -fstack-protector showed in the configure log that it was not enabled. /Magnus > > Thanks, > David > > On 5/02/2016 8:48 PM, Magnus Ihse Bursie wrote: >> A previous fix to check if -fstack-protector is accepted by gcc failed, >> since when testing the option, gcc emitted a warning and not an error. >> >> The one thing I'm thinking here about is if the ssp-buffer-size option >> should be more tightly coupled with the -fstack-protector flag. It does >> not harm to have it without the -f flag, but it seems a bit funny. >> Opinions? >> >> I also noted that this flag is added to CFLAGS_DEBUG_OPTIONS. This means >> that it only gets activated if we generate debug symbols. For Oracle >> builds we always do so it doesn't really matter, but I'd say that it's >> technically incorrect. I'd rather not fix that now, though, but save it >> for the upcoming and long overdue cleanup of flags handling. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129395 >> Patch inline: >> diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 >> --- a/common/autoconf/flags.m4 >> +++ b/common/autoconf/flags.m4 >> @@ -1,5 +1,5 @@ >> # >> -# Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights >> reserved. >> +# Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights >> reserved. >> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> # >> # This code is free software; you can redistribute it and/or modify it >> @@ -426,7 +426,7 @@ >> # Add runtime stack smashing and undefined behavior checks. >> # Not all versions of gcc support -fstack-protector >> STACK_PROTECTOR_CFLAG="-fstack-protector-all" >> - FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: >> [$STACK_PROTECTOR_CFLAG], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) >> + FLAGS_COMPILER_CHECK_ARGUMENTS(ARGUMENT: [$STACK_PROTECTOR_CFLAG >> -Werror], IF_FALSE: [STACK_PROTECTOR_CFLAG=""]) >> >> CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >> ssp-buffer-size=1" >> CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >> ssp-buffer-size=1" >> >> /Magnus From magnus.ihse.bursie at oracle.com Mon Feb 8 13:42:18 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Feb 2016 14:42:18 +0100 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56B50B01.60003@oracle.com> References: <56B4F031.6040501@oracle.com> <56B50B01.60003@oracle.com> Message-ID: <56B89B3A.6070002@oracle.com> On 2016-02-05 21:50, Alan Bateman wrote: > On 05/02/2016 18:55, Xueming Shen wrote: >> Hi >> >> Please help codereview the change to build the jdk9 runtime to use >> the system zlib on >> Solaris and Linux platforms by default. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8031767 >> Webrev: http://cr.openjdk.java.net/~sherman/8031767/webrev/ Looks good to me. > I'm happy to see the default changed for Linux and Solaris builds. One > thing is that the patch to lib-bundled.m4 switches the build on all > non-Windows to use the system zlib. This may be something the SAP (AIX > port maintainers) might want to comment on. As a rule of thumb, almost everyone else than Oracle uses system libraries as far as possible. :) Also, changing the default is seldom a problem for anyone, as long as the old behavior can be achieved by a properly crafted configure command line. /Magnus > > -Alan. From david.dehaven at oracle.com Mon Feb 8 18:39:38 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 8 Feb 2016 10:39:38 -0800 Subject: [9] RFR: 8147754: Configure fails to detect freetype installed by XQuartz on OSX 10.11 Message-ID: <8CEA8EE3-E225-4E07-83AF-FA0248FBED2C@oracle.com> JBS link: https://bugs.openjdk.java.net/browse/JDK-8147754 Please review this small fix for locating Freetype with the updated version of XQuartz (for OSX 10.11): --- cut here --- diff --git a/common/autoconf/lib-freetype.m4 b/common/autoconf/lib-freetype.m4 --- a/common/autoconf/lib-freetype.m4 +++ b/common/autoconf/lib-freetype.m4 @@ -349,6 +349,14 @@ LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], [$FREETYPE_BASE_DIR/lib], [well-known location]) fi + if test "x$OPENJDK_TARGET_OS" = xmacosx; then + if test "x$FOUND_FREETYPE" != xyes; then + # Due to changes in OSX 10.11 XQuartz now installs to /opt/X11 + FREETYPE_BASE_DIR="$SYSROOT/opt/X11" + LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], [$FREETYPE_BASE_DIR/lib], [well-known location]) + fi + fi + if test "x$FOUND_FREETYPE" != xyes; then FREETYPE_BASE_DIR="$SYSROOT/usr/sfw" LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], [$FREETYPE_BASE_DIR/lib], [well-known location]) --- cut here --- Tested on OSX 10.11 (El Capitan) with XQuartz 2.7.8: $ sh ./configure ... checking for freetype includes... /opt/X11/include/freetype2 checking for freetype libraries... /opt/X11/lib ... Build seems to work fine too. -DrD- From kim.barrett at oracle.com Mon Feb 8 19:37:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Feb 2016 14:37:34 -0500 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <7B6E32C6-67B3-44D8-8A81-0AAC87DE206C@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com> <7B6E32C6-67B3-44D8-8A81-0AAC87DE206C@oracle.com> Message-ID: <97585ABE-82C2-42C6-AC3A-2418C8F9AC85@oracle.com> > On Feb 7, 2016, at 4:22 PM, Igor Ignatyev wrote: > > Hi Kim, > > could you please take a look at the updated webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.03 > > I agree that ?+w? isn?t related to WARNINGS_ARE_ERRORS, so it was moved to CFLAGS_WARN. > > Regarding compiler version based conditions, I think it?d be better for build team to decide how to deal w/ them. > > PS I?ve checked that w/ the patch applied warnings, which normally cause a build error, don?t cause any build errors w/ --disable-warnings-as-errors. Looks good. From erik.joelsson at oracle.com Mon Feb 8 19:43:02 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Feb 2016 20:43:02 +0100 Subject: [9] RFR: 8147754: Configure fails to detect freetype installed by XQuartz on OSX 10.11 In-Reply-To: <8CEA8EE3-E225-4E07-83AF-FA0248FBED2C@oracle.com> References: <8CEA8EE3-E225-4E07-83AF-FA0248FBED2C@oracle.com> Message-ID: <19da22f7-06d2-43b4-8ab8-473a6124ef53@typeapp.com> Looks good to me. /Erik On Feb 8, 2016, 19:40, at 19:40, David DeHaven wrote: > >JBS link: >https://bugs.openjdk.java.net/browse/JDK-8147754 > >Please review this small fix for locating Freetype with the updated >version of XQuartz (for OSX 10.11): > >--- cut here --- >diff --git a/common/autoconf/lib-freetype.m4 >b/common/autoconf/lib-freetype.m4 >--- a/common/autoconf/lib-freetype.m4 >+++ b/common/autoconf/lib-freetype.m4 >@@ -349,6 +349,14 @@ >LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], >[$FREETYPE_BASE_DIR/lib], [well-known location]) > fi > >+ if test "x$OPENJDK_TARGET_OS" = xmacosx; then >+ if test "x$FOUND_FREETYPE" != xyes; then >+ # Due to changes in OSX 10.11 XQuartz now installs to >/opt/X11 >+ FREETYPE_BASE_DIR="$SYSROOT/opt/X11" >+ >LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], >[$FREETYPE_BASE_DIR/lib], [well-known location]) >+ fi >+ fi >+ > if test "x$FOUND_FREETYPE" != xyes; then > FREETYPE_BASE_DIR="$SYSROOT/usr/sfw" >LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], >[$FREETYPE_BASE_DIR/lib], [well-known location]) >--- cut here --- > >Tested on OSX 10.11 (El Capitan) with XQuartz 2.7.8: >$ sh ./configure >... >checking for freetype includes... /opt/X11/include/freetype2 >checking for freetype libraries... /opt/X11/lib >... > >Build seems to work fine too. > >-DrD- From magnus.ihse.bursie at oracle.com Mon Feb 8 19:48:26 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Feb 2016 20:48:26 +0100 Subject: [9] RFR: 8147754: Configure fails to detect freetype installed by XQuartz on OSX 10.11 In-Reply-To: <8CEA8EE3-E225-4E07-83AF-FA0248FBED2C@oracle.com> References: <8CEA8EE3-E225-4E07-83AF-FA0248FBED2C@oracle.com> Message-ID: <4C9F26D3-528B-4C9E-B002-6C2F30B28BAA@oracle.com> Looks good to me. /Magnus > 8 feb. 2016 kl. 19:39 skrev David DeHaven : > > > JBS link: > https://bugs.openjdk.java.net/browse/JDK-8147754 > > Please review this small fix for locating Freetype with the updated version of XQuartz (for OSX 10.11): > > --- cut here --- > diff --git a/common/autoconf/lib-freetype.m4 b/common/autoconf/lib-freetype.m4 > --- a/common/autoconf/lib-freetype.m4 > +++ b/common/autoconf/lib-freetype.m4 > @@ -349,6 +349,14 @@ > LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], [$FREETYPE_BASE_DIR/lib], [well-known location]) > fi > > + if test "x$OPENJDK_TARGET_OS" = xmacosx; then > + if test "x$FOUND_FREETYPE" != xyes; then > + # Due to changes in OSX 10.11 XQuartz now installs to /opt/X11 > + FREETYPE_BASE_DIR="$SYSROOT/opt/X11" > + LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], [$FREETYPE_BASE_DIR/lib], [well-known location]) > + fi > + fi > + > if test "x$FOUND_FREETYPE" != xyes; then > FREETYPE_BASE_DIR="$SYSROOT/usr/sfw" > LIB_CHECK_POTENTIAL_FREETYPE([$FREETYPE_BASE_DIR/include], [$FREETYPE_BASE_DIR/lib], [well-known location]) > --- cut here --- > > Tested on OSX 10.11 (El Capitan) with XQuartz 2.7.8: > $ sh ./configure > ... > checking for freetype includes... /opt/X11/include/freetype2 > checking for freetype libraries... /opt/X11/lib > ... > > Build seems to work fine too. > > -DrD- > From magnus.ihse.bursie at oracle.com Tue Feb 9 09:54:13 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Feb 2016 10:54:13 +0100 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <97585ABE-82C2-42C6-AC3A-2418C8F9AC85@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com> <7B6E32C6-67B3-44D8-8A81-0AAC87DE206C@oracle.com> <97585ABE-82C2-42C6-AC3A-2418C8F9AC85@oracle.com> Message-ID: <56B9B745.20504@oracle.com> On 2016-02-08 20:37, Kim Barrett wrote: >> On Feb 7, 2016, at 4:22 PM, Igor Ignatyev wrote: >> >> Hi Kim, >> >> could you please take a look at the updated webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.03 >> >> I agree that ?+w? isn?t related to WARNINGS_ARE_ERRORS, so it was moved to CFLAGS_WARN. >> >> Regarding compiler version based conditions, I think it?d be better for build team to decide how to deal w/ them. >> >> PS I?ve checked that w/ the patch applied warnings, which normally cause a build error, don?t cause any build errors w/ --disable-warnings-as-errors. > Looks good. > Looks good to me to, now. /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 9 09:57:48 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Feb 2016 10:57:48 +0100 Subject: question on jigsaw build In-Reply-To: <56A61869.2020802@oracle.com> References: <56A61869.2020802@oracle.com> Message-ID: <56B9B81C.9020606@oracle.com> On 2016-01-25 13:43, Maurizio Cimadamore wrote: > Hi, > the current build system in JDK 9 has a way to recover all the source > dirs for a given module, by doing something like this: > > $(call ALL_SRC_DIRS,$(mod)) > > That is, the build system exports a function that can be passed a > module name and will return all the source roots for the module with > that name. > > This is an extremely helpful piece of functionality when building > things like IDE support - as one can leverage the knowledge of the > build system in order to put together an IDE projects with the right > paths in it, regardless of the OS and ARCH (details which are all > taken care of by the build itself). > > I see that this functionality is now removed from the current jigsaw > build - which instead declares a sequence of (dynamically defined) > targets to compile a module with name xyz; as a result, the variables > containing the source roots for xyz are not exported anymore, thus > severely impacting usability from 3rd party build tools. > > What is the plan in this direction? Is there any talks about having > the build system export a pseudo API for querying variables (source > roots, generated sources, output dirs) for a given module w/o > compiling them? We can surely expose an API if there is such a need. However, it needs to be driven by an explicit need. Is there anything else you'd need apart from a list of all source roots for a given module? /Magnus From chris.hegarty at oracle.com Tue Feb 9 10:12:14 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 9 Feb 2016 10:12:14 +0000 Subject: question on jigsaw build In-Reply-To: <56B9B81C.9020606@oracle.com> References: <56A61869.2020802@oracle.com> <56B9B81C.9020606@oracle.com> Message-ID: <56B9BB7E.6@oracle.com> Magnus, Thank you for your reply. On 09/02/16 09:57, Magnus Ihse Bursie wrote: > On 2016-01-25 13:43, Maurizio Cimadamore wrote: >> Hi, >> the current build system in JDK 9 has a way to recover all the source >> dirs for a given module, by doing something like this: >> >> $(call ALL_SRC_DIRS,$(mod)) >> >> That is, the build system exports a function that can be passed a >> module name and will return all the source roots for the module with >> that name. >> >> This is an extremely helpful piece of functionality when building >> things like IDE support - as one can leverage the knowledge of the >> build system in order to put together an IDE projects with the right >> paths in it, regardless of the OS and ARCH (details which are all >> taken care of by the build itself). >> >> I see that this functionality is now removed from the current jigsaw >> build - which instead declares a sequence of (dynamically defined) >> targets to compile a module with name xyz; as a result, the variables >> containing the source roots for xyz are not exported anymore, thus >> severely impacting usability from 3rd party build tools. >> >> What is the plan in this direction? Is there any talks about having >> the build system export a pseudo API for querying variables (source >> roots, generated sources, output dirs) for a given module w/o >> compiling them? > > We can surely expose an API if there is such a need. However, it needs > to be driven by an explicit need. +1. With recent build changes the JDK IDEA project is dead, even with JDK 9. We need to get this up and running again, as quickly as possible. I know there are, at least, double digit numbers of developers using the project. > Is there anything else you'd need > apart from a list of all source roots for a given module? For now, this is the main requirement ( I am not aware of others ). Once we get this resolved, the plan is to get the IDEA project pushed to the JDK 9 mainline where it can be evolved and maintained, as appropriate. -Chris. From igor.ignatyev at oracle.com Tue Feb 9 10:14:54 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 9 Feb 2016 13:14:54 +0300 Subject: RFR(XS) : 8144695 : --disable-warnings-as-errors does not work for HotSpot build In-Reply-To: <56B9B745.20504@oracle.com> References: <5BE45063-15F7-446E-9001-3AFA3B00578C@oracle.com> <5FB23711-1ED5-4ABB-8F1C-D6EEA551ED22@oracle.com> <100FFD7C-1F76-4C17-BA8F-293C99F1B6C1@oracle.com> <7B6E32C6-67B3-44D8-8A81-0AAC87DE206C@oracle.com> <97585ABE-82C2-42C6-AC3A-2418C8F9AC85@oracle.com> <56B9B745.20504@oracle.com> Message-ID: <12EB23A0-5446-437E-AB09-B79B47EB0B00@oracle.com> Kim, Magnus, Thank you for review. ? Igor > On Feb 9, 2016, at 12:54 PM, Magnus Ihse Bursie wrote: > > On 2016-02-08 20:37, Kim Barrett wrote: >>> On Feb 7, 2016, at 4:22 PM, Igor Ignatyev wrote: >>> >>> Hi Kim, >>> >>> could you please take a look at the updated webrev: http://cr.openjdk.java.net/~iignatyev/8144695/webrev.03 >>> >>> I agree that ?+w? isn?t related to WARNINGS_ARE_ERRORS, so it was moved to CFLAGS_WARN. >>> >>> Regarding compiler version based conditions, I think it?d be better for build team to decide how to deal w/ them. >>> >>> PS I?ve checked that w/ the patch applied warnings, which normally cause a build error, don?t cause any build errors w/ --disable-warnings-as-errors. >> Looks good. >> > Looks good to me to, now. > > /Magnus > From yasuenag at gmail.com Tue Feb 9 13:43:33 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 9 Feb 2016 22:43:33 +0900 Subject: RFR: JDK-8149466: configure failed after JDK-8148351 Message-ID: <56B9ED05.60409@gmail.com> Hi all, After JDK-8148351, configure script failed as below: ---- configure: Using default toolchain gcc (GNU Compiler Collection) checking for gcc... /usr/lib64/ccache/gcc checking resolved symbolic links for CC... /usr/bin/ccache configure: Please use --enable-ccache instead of providing a wrapped compiler. configure: error: /usr/lib64/ccache/gcc is a symbolic link to ccache. This is not supported. configure exiting with result code 1 ---- I added --enable-ccache to configure option, but I cannot avoid this error. Cause of this is that symlink check in toolchain.m4 did not treat --enable-ccache. I've uploaded webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8149466/webrev.00/ Thanks, Yasumasa From magnus.ihse.bursie at oracle.com Tue Feb 9 14:14:05 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Feb 2016 15:14:05 +0100 Subject: RFR: JDK-8149466: configure failed after JDK-8148351 In-Reply-To: <56B9ED05.60409@gmail.com> References: <56B9ED05.60409@gmail.com> Message-ID: <56B9F42D.90206@oracle.com> On 2016-02-09 14:43, Yasumasa Suenaga wrote: > Hi all, > > After JDK-8148351, configure script failed as below: > > ---- > configure: Using default toolchain gcc (GNU Compiler Collection) > checking for gcc... /usr/lib64/ccache/gcc > checking resolved symbolic links for CC... /usr/bin/ccache > configure: Please use --enable-ccache instead of providing a wrapped compiler. > configure: error: /usr/lib64/ccache/gcc is a symbolic link to ccache. This is not supported. > configure exiting with result code 1 > ---- > > I added --enable-ccache to configure option, but I cannot avoid this error. This is since the requirements for running configure has slightly changed. As the error message says: Please use --enable-ccache instead of providing a wrapped compiler. You have a /usr/lib64/ccache on your PATH, ahead of where your real gcc lies. This has never been a supported configuration. Prior to JDK-8148351, we tried to be "clever" and just override this configuration. Now we stop and alert the user, and asks them to handle the situation themselves. I recommend that you remove /usr/lib64/ccache from your PATH. If this is not possible, then you can specify your compiler explicitely using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. /Magnus From yasuenag at gmail.com Tue Feb 9 14:29:01 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 9 Feb 2016 23:29:01 +0900 Subject: RFR: JDK-8149466: configure failed after JDK-8148351 In-Reply-To: <56B9F42D.90206@oracle.com> References: <56B9ED05.60409@gmail.com> <56B9F42D.90206@oracle.com> Message-ID: <56B9F7AD.4020102@gmail.com> Hi Magnus, > If this is not possible, then you can specify your compiler explicitely > using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. I could avoid it with these options. Error message says that we can avoid this error with --enable-ccache. However, I could not avoid with it. Thus I think that we should fix to affect --enable-cache to these logic. Thanks, Yasumasa On 2016/02/09 23:14, Magnus Ihse Bursie wrote: > On 2016-02-09 14:43, Yasumasa Suenaga wrote: >> Hi all, >> >> After JDK-8148351, configure script failed as below: >> >> ---- >> configure: Using default toolchain gcc (GNU Compiler Collection) >> checking for gcc... /usr/lib64/ccache/gcc >> checking resolved symbolic links for CC... /usr/bin/ccache >> configure: Please use --enable-ccache instead of providing a wrapped compiler. >> configure: error: /usr/lib64/ccache/gcc is a symbolic link to ccache. This is not supported. >> configure exiting with result code 1 >> ---- >> >> I added --enable-ccache to configure option, but I cannot avoid this error. > This is since the requirements for running configure has slightly changed. > > As the error message says: Please use --enable-ccache instead of > providing a wrapped compiler. > > You have a /usr/lib64/ccache on your PATH, ahead of where your real gcc > lies. This has never been a supported configuration. Prior to > JDK-8148351, we tried to be "clever" and just override this > configuration. Now we stop and alert the user, and asks them to handle > the situation themselves. > > I recommend that you remove /usr/lib64/ccache from your PATH. > > If this is not possible, then you can specify your compiler explicitely > using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Feb 9 14:33:33 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Feb 2016 15:33:33 +0100 Subject: RFR: JDK-8149466: configure failed after JDK-8148351 In-Reply-To: <56B9F7AD.4020102@gmail.com> References: <56B9ED05.60409@gmail.com> <56B9F42D.90206@oracle.com> <56B9F7AD.4020102@gmail.com> Message-ID: <56B9F8BD.3020807@oracle.com> On 2016-02-09 15:29, Yasumasa Suenaga wrote: > Hi Magnus, > >> If this is not possible, then you can specify your compiler explicitely >> using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. > I could avoid it with these options. > > Error message says that we can avoid this error with --enable-ccache. > However, I could not avoid with it. No, error message says you should not supply a ccache wrapper as compiler. Since the typical reason for supplying a ccache wrapper is to get a ccache enhanced build, the message says that the proper way to achieve this is to use --enable-ccache. If you just add --enable-ccache, you're not doing this "instead of". /Magnus > > Thus I think that we should fix to affect --enable-cache to these logic. > > > Thanks, > > Yasumasa > > > On 2016/02/09 23:14, Magnus Ihse Bursie wrote: >> On 2016-02-09 14:43, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> After JDK-8148351, configure script failed as below: >>> >>> ---- >>> configure: Using default toolchain gcc (GNU Compiler Collection) >>> checking for gcc... /usr/lib64/ccache/gcc >>> checking resolved symbolic links for CC... /usr/bin/ccache >>> configure: Please use --enable-ccache instead of providing a wrapped compiler. >>> configure: error: /usr/lib64/ccache/gcc is a symbolic link to ccache. This is not supported. >>> configure exiting with result code 1 >>> ---- >>> >>> I added --enable-ccache to configure option, but I cannot avoid this error. >> This is since the requirements for running configure has slightly changed. >> >> As the error message says: Please use --enable-ccache instead of >> providing a wrapped compiler. >> >> You have a /usr/lib64/ccache on your PATH, ahead of where your real gcc >> lies. This has never been a supported configuration. Prior to >> JDK-8148351, we tried to be "clever" and just override this >> configuration. Now we stop and alert the user, and asks them to handle >> the situation themselves. >> >> I recommend that you remove /usr/lib64/ccache from your PATH. >> >> If this is not possible, then you can specify your compiler explicitely >> using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. >> >> /Magnus >> From yasuenag at gmail.com Tue Feb 9 14:48:54 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 9 Feb 2016 23:48:54 +0900 Subject: RFR: JDK-8149466: configure failed after JDK-8148351 In-Reply-To: <56B9F8BD.3020807@oracle.com> References: <56B9ED05.60409@gmail.com> <56B9F42D.90206@oracle.com> <56B9F7AD.4020102@gmail.com> <56B9F8BD.3020807@oracle.com> Message-ID: <56B9FC56.3090604@gmail.com> Hi Magnus, Thanks, I've understood. I closed JDK-8149466 as "Not an issue" . Yasumasa On 2016/02/09 23:33, Magnus Ihse Bursie wrote: > On 2016-02-09 15:29, Yasumasa Suenaga wrote: >> Hi Magnus, >> >>> If this is not possible, then you can specify your compiler explicitely >>> using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. >> I could avoid it with these options. >> >> Error message says that we can avoid this error with --enable-ccache. >> However, I could not avoid with it. > No, error message says you should not supply a ccache wrapper as > compiler. Since the typical reason for supplying a ccache wrapper is to > get a ccache enhanced build, the message says that the proper way to > achieve this is to use --enable-ccache. > > If you just add --enable-ccache, you're not doing this "instead of". > > /Magnus > >> >> Thus I think that we should fix to affect --enable-cache to these logic. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/02/09 23:14, Magnus Ihse Bursie wrote: >>> On 2016-02-09 14:43, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> After JDK-8148351, configure script failed as below: >>>> >>>> ---- >>>> configure: Using default toolchain gcc (GNU Compiler Collection) >>>> checking for gcc... /usr/lib64/ccache/gcc >>>> checking resolved symbolic links for CC... /usr/bin/ccache >>>> configure: Please use --enable-ccache instead of providing a wrapped compiler. >>>> configure: error: /usr/lib64/ccache/gcc is a symbolic link to ccache. This is not supported. >>>> configure exiting with result code 1 >>>> ---- >>>> >>>> I added --enable-ccache to configure option, but I cannot avoid this error. >>> This is since the requirements for running configure has slightly changed. >>> >>> As the error message says: Please use --enable-ccache instead of >>> providing a wrapped compiler. >>> >>> You have a /usr/lib64/ccache on your PATH, ahead of where your real gcc >>> lies. This has never been a supported configuration. Prior to >>> JDK-8148351, we tried to be "clever" and just override this >>> configuration. Now we stop and alert the user, and asks them to handle >>> the situation themselves. >>> >>> I recommend that you remove /usr/lib64/ccache from your PATH. >>> >>> If this is not possible, then you can specify your compiler explicitely >>> using "configure CC=/usr/bin/gcc CXX=/usr/bin/g++" or whatever. >>> >>> /Magnus >>> > From erik.joelsson at oracle.com Tue Feb 9 19:54:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Feb 2016 20:54:54 +0100 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD Message-ID: <56BA440E.7000309@oracle.com> Hello, Please review these fixes for compare.sh and the COMPARE_BUILD flag for make. The rather new feature COMPARE_BUILD, which builds twice, applying some kind of change between them, is really neat. Especially when run through JPRT to check all platforms at once. The problem is that compare.sh currently isn't clean on all these platforms. There are also some special peculiarities particular to when JPRT is running the build which confuses compare.sh. Given that COMPARE_BUILD uses the exact same output directory, and JPRT sets the version-opt string to a fix value for both builds, we should be able to achieve a clean and stable baseline for an empty patch file. Which I now have. I also changed COMPARE_BUILD to fail the build when differences are found and added an option to COMPARE_BUILD to disable failing. Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ /Erik From erik.joelsson at oracle.com Tue Feb 9 20:00:36 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Feb 2016 21:00:36 +0100 Subject: RFR: JDK-8145789: Switch JDK 9 to use Jib in JPRT In-Reply-To: <5677DBDA.5000508@oracle.com> References: <5677DBDA.5000508@oracle.com> Message-ID: <56BA4564.7040906@oracle.com> This never made it in because of various issues. Those have now been resolved, so reposting this, updated to latest jdk9/dev. Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.02/ /Erik On 2015-12-21 12:00, Erik Joelsson wrote: > Hello, > > With Jib support in JDK 9, it would be nice to start using it in JPRT > instead of having JPRT having to track dependencies and > configurations. This change enables Jib in JPRT and disables all the > JPRT functionality for tracking dependencies (build.needs and most > configure args). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145789 > Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.01/ > > /Erik From tim.bell at oracle.com Wed Feb 10 06:13:14 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 09 Feb 2016 22:13:14 -0800 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BA440E.7000309@oracle.com> References: <56BA440E.7000309@oracle.com> Message-ID: <56BAD4FA.5050601@oracle.com> Erik: > Please review these fixes for compare.sh and the COMPARE_BUILD flag > for make. > > The rather new feature COMPARE_BUILD, which builds twice, applying > some kind of change between them, is really neat. Especially when run > through JPRT to check all platforms at once. The problem is that > compare.sh currently isn't clean on all these platforms. There are > also some special peculiarities particular to when JPRT is running the > build which confuses compare.sh. > > Given that COMPARE_BUILD uses the exact same output directory, and > JPRT sets the version-opt string to a fix value for both builds, we > should be able to achieve a clean and stable baseline for an empty > patch file. Which I now have. > > I also changed COMPARE_BUILD to fail the build when differences are > found and added an option to COMPARE_BUILD to disable failing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 > Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ 1) Regarding common/bin/compare.sh lines 336...341 and lines 344...349 in the new version - this is not directly related to 8149479 but I wish those regexes were only coded once. If they ever get out of sync the results will be puzzling. 2) make/InitSupport.gmk line 366 in the new version - typo? COMPARE_BUILD_FAILE is COMPARE_BUILD_FAIL elsewhere Looks good otherwise. Tim From magnus.ihse.bursie at oracle.com Wed Feb 10 10:23:54 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Feb 2016 11:23:54 +0100 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BAD4FA.5050601@oracle.com> References: <56BA440E.7000309@oracle.com> <56BAD4FA.5050601@oracle.com> Message-ID: <56BB0FBA.2040105@oracle.com> On 2016-02-10 07:13, Tim Bell wrote: > Erik: > >> Please review these fixes for compare.sh and the COMPARE_BUILD flag >> for make. >> >> The rather new feature COMPARE_BUILD, which builds twice, applying >> some kind of change between them, is really neat. Especially when run >> through JPRT to check all platforms at once. The problem is that >> compare.sh currently isn't clean on all these platforms. There are >> also some special peculiarities particular to when JPRT is running >> the build which confuses compare.sh. >> >> Given that COMPARE_BUILD uses the exact same output directory, and >> JPRT sets the version-opt string to a fix value for both builds, we >> should be able to achieve a clean and stable baseline for an empty >> patch file. Which I now have. >> >> I also changed COMPARE_BUILD to fail the build when differences are >> found and added an option to COMPARE_BUILD to disable failing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 >> Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ > > 1) Regarding common/bin/compare.sh lines 336...341 and lines 344...349 > in the new version - this is not directly related to 8149479 but I > wish those regexes were only coded once. If they ever get out of sync > the results will be puzzling. > > 2) make/InitSupport.gmk line 366 in the new version - typo? > COMPARE_BUILD_FAILE is COMPARE_BUILD_FAIL elsewhere Also, the comment lists an additional "FAIL_BUILD=" which should be deleted. Apart from that (and the typo Tim found), the patch looks good to me. However, I'd like to use the opportunity to talk a bit about the compare script. :-) I think it is a very good initiative to fix the compare script so that two consequitive builds on the same machine should compare equal. Apparently, that's as close to a reproducible build we'll ever get at the moment. This patch does that, and that's good. However, the "naive" way to get to a clean compare is to stop comparing anything of value. :-) I'm not suggesting that you are doing that (or that you should do that), but in a less extreme form, that's my main worry. Or to phrase it differently, how can we tell that we're not hiding something important? For instance, all these "accepted size differences" on solaris. Are they still relevant? Is there some way to run the compare script without the exceptions file (apart from hacking it)? If we do that, what would happen? Could we trim down the exception lists? The dis filters seems a bit non-optimal too. We have a "global" dis filter in compare.sh (introduced by me when I didn't know about the specific dis filters in the exception file), and a specific dis filter per platform in the exception file. The main task for the dis filters is to remove differences in hexadecimal numbers, and I think that could be generalized enough to just be in the global part. Any highly platform specific filtering, like the "literal pool" stuff for macosx, could still live in the exception file. Finally, I still would like to get the string literal comparison into the configure script, now I run it manually using: objdump -s -j .rodata $LIBRARY | grep "^ " | xxd -r | strings (The main hurdle to do this is adding detection for xxd in configure, I think) /Magnus From erik.joelsson at oracle.com Wed Feb 10 13:11:02 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Feb 2016 14:11:02 +0100 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BAD4FA.5050601@oracle.com> References: <56BA440E.7000309@oracle.com> <56BAD4FA.5050601@oracle.com> Message-ID: <56BB36E6.8030207@oracle.com> Hello Tim, New webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.02/ I agree about 1, so I started looking at it. Got confused why any changes to it didn't seem to have any effect until I realized the docs are no longer compared, which is what that was added for. So I fixed comparing of docs and reduced the sed expressions to what is actually necessary today, which was much less. 2 was indeed a typo and it could have hidden compare failures in my JPRT runs. Luckily, it was still clean. I also fixed the comment Magnus pointed out. /Erik On 2016-02-10 07:13, Tim Bell wrote: > Erik: > >> Please review these fixes for compare.sh and the COMPARE_BUILD flag >> for make. >> >> The rather new feature COMPARE_BUILD, which builds twice, applying >> some kind of change between them, is really neat. Especially when run >> through JPRT to check all platforms at once. The problem is that >> compare.sh currently isn't clean on all these platforms. There are >> also some special peculiarities particular to when JPRT is running >> the build which confuses compare.sh. >> >> Given that COMPARE_BUILD uses the exact same output directory, and >> JPRT sets the version-opt string to a fix value for both builds, we >> should be able to achieve a clean and stable baseline for an empty >> patch file. Which I now have. >> >> I also changed COMPARE_BUILD to fail the build when differences are >> found and added an option to COMPARE_BUILD to disable failing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 >> Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ > > 1) Regarding common/bin/compare.sh lines 336...341 and lines 344...349 > in the new version - this is not directly related to 8149479 but I > wish those regexes were only coded once. If they ever get out of sync > the results will be puzzling. > > 2) make/InitSupport.gmk line 366 in the new version - typo? > COMPARE_BUILD_FAILE is COMPARE_BUILD_FAIL elsewhere > > Looks good otherwise. > > Tim > From erik.joelsson at oracle.com Wed Feb 10 13:14:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Feb 2016 14:14:54 +0100 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BB0FBA.2040105@oracle.com> References: <56BA440E.7000309@oracle.com> <56BAD4FA.5050601@oracle.com> <56BB0FBA.2040105@oracle.com> Message-ID: <56BB37CE.4000902@oracle.com> On 2016-02-10 11:23, Magnus Ihse Bursie wrote: > > However, I'd like to use the opportunity to talk a bit about the > compare script. :-) > > I think it is a very good initiative to fix the compare script so that > two consequitive builds on the same machine should compare equal. > Apparently, that's as close to a reproducible build we'll ever get at > the moment. > > This patch does that, and that's good. > > However, the "naive" way to get to a clean compare is to stop > comparing anything of value. :-) I'm not suggesting that you are doing > that (or that you should do that), but in a less extreme form, that's > my main worry. Or to phrase it differently, how can we tell that we're > not hiding something important? For instance, all these "accepted size > differences" on solaris. Are they still relevant? > I agree, it would be good to reevaluate a lot of the exceptions. I have removed some that were obviously just working around differences between build-infra and old build in JDK 8. > Is there some way to run the compare script without the exceptions > file (apart from hacking it)? If we do that, what would happen? Could > we trim down the exception lists? > No, there isn't. Yes, at least some of those exceptions are needed. I'm sure we can remove a bunch of them if we assume exact same output dir, but not all. > The dis filters seems a bit non-optimal too. We have a "global" dis > filter in compare.sh (introduced by me when I didn't know about the > specific dis filters in the exception file), and a specific dis filter > per platform in the exception file. The main task for the dis filters > is to remove differences in hexadecimal numbers, and I think that > could be generalized enough to just be in the global part. Any highly > platform specific filtering, like the "literal pool" stuff for macosx, > could still live in the exception file. > Maybe, not sure. In some cases, the specialized filters also take local variations on commands like sed into account. > Finally, I still would like to get the string literal comparison into > the configure script, now I run it manually using: > objdump -s -j .rodata $LIBRARY | grep "^ " | xxd -r | strings > (The main hurdle to do this is adding detection for xxd in configure, > I think) > If you have more comparisons, please add them. /Erik From magnus.ihse.bursie at oracle.com Wed Feb 10 13:16:30 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Feb 2016 14:16:30 +0100 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BB36E6.8030207@oracle.com> References: <56BA440E.7000309@oracle.com> <56BAD4FA.5050601@oracle.com> <56BB36E6.8030207@oracle.com> Message-ID: <56BB382E.9050509@oracle.com> On 2016-02-10 14:11, Erik Joelsson wrote: > Hello Tim, > > New webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.02/ > > I agree about 1, so I started looking at it. Got confused why any > changes to it didn't seem to have any effect until I realized the docs > are no longer compared, which is what that was added for. So I fixed > comparing of docs and reduced the sed expressions to what is actually > necessary today, which was much less. > > 2 was indeed a typo and it could have hidden compare failures in my > JPRT runs. Luckily, it was still clean. > > I also fixed the comment Magnus pointed out. Almost, at least. ;-) You lost a colon: - # Syntax: COMPARE_BUILD=CONF=:PATCH=: + # Syntax: COMPARE_BUILD=CONF=:PATCH= If you just restore that colon, I'm fine with the new version. /Magnus > > /Erik > > On 2016-02-10 07:13, Tim Bell wrote: >> Erik: >> >>> Please review these fixes for compare.sh and the COMPARE_BUILD flag >>> for make. >>> >>> The rather new feature COMPARE_BUILD, which builds twice, applying >>> some kind of change between them, is really neat. Especially when >>> run through JPRT to check all platforms at once. The problem is that >>> compare.sh currently isn't clean on all these platforms. There are >>> also some special peculiarities particular to when JPRT is running >>> the build which confuses compare.sh. >>> >>> Given that COMPARE_BUILD uses the exact same output directory, and >>> JPRT sets the version-opt string to a fix value for both builds, we >>> should be able to achieve a clean and stable baseline for an empty >>> patch file. Which I now have. >>> >>> I also changed COMPARE_BUILD to fail the build when differences are >>> found and added an option to COMPARE_BUILD to disable failing. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 >>> Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ >> >> 1) Regarding common/bin/compare.sh lines 336...341 and lines >> 344...349 in the new version - this is not directly related to >> 8149479 but I wish those regexes were only coded once. If they ever >> get out of sync the results will be puzzling. >> >> 2) make/InitSupport.gmk line 366 in the new version - typo? >> COMPARE_BUILD_FAILE is COMPARE_BUILD_FAIL elsewhere >> >> Looks good otherwise. >> >> Tim >> > From erik.joelsson at oracle.com Wed Feb 10 13:19:05 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Feb 2016 14:19:05 +0100 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BB382E.9050509@oracle.com> References: <56BA440E.7000309@oracle.com> <56BAD4FA.5050601@oracle.com> <56BB36E6.8030207@oracle.com> <56BB382E.9050509@oracle.com> Message-ID: <56BB38C9.4080108@oracle.com> Updated in place. /Erik On 2016-02-10 14:16, Magnus Ihse Bursie wrote: > On 2016-02-10 14:11, Erik Joelsson wrote: >> Hello Tim, >> >> New webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.02/ >> >> I agree about 1, so I started looking at it. Got confused why any >> changes to it didn't seem to have any effect until I realized the >> docs are no longer compared, which is what that was added for. So I >> fixed comparing of docs and reduced the sed expressions to what is >> actually necessary today, which was much less. >> >> 2 was indeed a typo and it could have hidden compare failures in my >> JPRT runs. Luckily, it was still clean. >> >> I also fixed the comment Magnus pointed out. > Almost, at least. ;-) > > You lost a colon: > > - # Syntax: COMPARE_BUILD=CONF=:PATCH=: > + # Syntax: COMPARE_BUILD=CONF=:PATCH= > > > If you just restore that colon, I'm fine with the new version. > > /Magnus > >> >> /Erik >> >> On 2016-02-10 07:13, Tim Bell wrote: >>> Erik: >>> >>>> Please review these fixes for compare.sh and the COMPARE_BUILD flag >>>> for make. >>>> >>>> The rather new feature COMPARE_BUILD, which builds twice, applying >>>> some kind of change between them, is really neat. Especially when >>>> run through JPRT to check all platforms at once. The problem is >>>> that compare.sh currently isn't clean on all these platforms. There >>>> are also some special peculiarities particular to when JPRT is >>>> running the build which confuses compare.sh. >>>> >>>> Given that COMPARE_BUILD uses the exact same output directory, and >>>> JPRT sets the version-opt string to a fix value for both builds, we >>>> should be able to achieve a clean and stable baseline for an empty >>>> patch file. Which I now have. >>>> >>>> I also changed COMPARE_BUILD to fail the build when differences are >>>> found and added an option to COMPARE_BUILD to disable failing. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ >>> >>> 1) Regarding common/bin/compare.sh lines 336...341 and lines >>> 344...349 in the new version - this is not directly related to >>> 8149479 but I wish those regexes were only coded once. If they ever >>> get out of sync the results will be puzzling. >>> >>> 2) make/InitSupport.gmk line 366 in the new version - typo? >>> COMPARE_BUILD_FAILE is COMPARE_BUILD_FAIL elsewhere >>> >>> Looks good otherwise. >>> >>> Tim >>> >> > From sean.coffey at oracle.com Wed Feb 10 13:57:58 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Feb 2016 13:57:58 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56B86623.4090602@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> Message-ID: <56BB41E6.3060102@oracle.com> On 08/02/16 09:55, Alan Bateman wrote: > > On 08/02/2016 10:42, Se?n Coffey wrote: >> Is there an option to fall back to the older v.1.2.8 implementation >> if necessary ? It would certainly alleviate issues for any >> applications that might run into issues with the latest and greatest >> zlib libraries. JDK-8133206 would be one such example. > Just at build time so - we introduce a runtime dependency on the underlying zlib libraries on the OS by default. I would be very concerned with this approach. We've run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for the most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an inflation issue[1]. When JDK was upgraded to zlib v1.2.8, we received reports of performance/OOM issues [2]. > but if the zlib on the platform is broken then it impacts tools and > probably lots of things. I would assume the OS would patch such issues > quickly. In the case of JDK-8133206 then was the issue addressed in > the libzip wrapper or in the zlib code? I thought it was the former. The code change is proposed in the libzip wrapper but the issue was triggered by the zlib library update. > > On a fallback or some way to configure at launch time then Sandhya > Viswanathan (Intel) has a proposal here last year. I think we mostly > agreed on that thread that switching the build to use the system zlib > by default would be better. I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS zlib libraries. Could we at least consider a runtime property to allow linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ? regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8044725 [2] https://bugs.openjdk.java.net/browse/JDK-8133206 From Alan.Bateman at oracle.com Wed Feb 10 14:29:06 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Feb 2016 14:29:06 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BB41E6.3060102@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> Message-ID: <56BB4932.7060105@oracle.com> On 10/02/2016 13:57, Se?n Coffey wrote: > I'm all for allowing one to introduce a new version of zlib to their > JDK at runtime. I just don't think it's in the interests of > enterprises and stability to introduce a dependency to the JDK on the > underlying OS zlib libraries. Could we at least consider a runtime > property to allow linking to the (currently bundled) zlib v.1.2.8 port > in case issues arise ? Don't the LD_* environment variables serve this need already? Once the JDK is using the system zlib then this is the simplest way to get it to use a different libz library at runtime. -Alan From sean.coffey at oracle.com Wed Feb 10 14:41:40 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 10 Feb 2016 14:41:40 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BB4932.7060105@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> Message-ID: <56BB4C24.7090607@oracle.com> On 10/02/16 14:29, Alan Bateman wrote: > > On 10/02/2016 13:57, Se?n Coffey wrote: >> I'm all for allowing one to introduce a new version of zlib to their >> JDK at runtime. I just don't think it's in the interests of >> enterprises and stability to introduce a dependency to the JDK on the >> underlying OS zlib libraries. Could we at least consider a runtime >> property to allow linking to the (currently bundled) zlib v.1.2.8 >> port in case issues arise ? > Don't the LD_* environment variables serve this need already? Once the > JDK is using the system zlib then this is the simplest way to get it > to use a different libz library at runtime. No - I don't see that as a solution. You've still made the default JDK config become dependent on OS environment for all libzip operations. I don't think we even capture the zlib version that the JDK would be operating with in any diagnostics. An application wanting a tried/tested and stable libzip version has extra work to do now. Letting the default be system dependent has just increased risk for QA teams also. A system property just makes this all go away. In fact - I would say that for JDK9, the default should be the JDK bundled libzip library. For those looking for libzip experimenting and performance benefits, they could take the system property approach. regards, Sean. > > -Alan On 08/02/16 09:55, Alan Bateman wrote: > > On 08/02/2016 10:42, Se?n Coffey wrote: >> Is there an option to fall back to the older v.1.2.8 implementation >> if necessary ? It would certainly alleviate issues for any >> applications that might run into issues with the latest and greatest >> zlib libraries. JDK-8133206 would be one such example. > Just at build time so - we introduce a runtime dependency on the underlying zlib libraries on the OS by default. I would be very concerned with this approach. We've run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for the most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an inflation issue[1]. When JDK was upgraded to zlib v1.2.8, we received reports of performance/OOM issues [2]. > but if the zlib on the platform is broken then it impacts tools and > probably lots of things. I would assume the OS would patch such issues > quickly. In the case of JDK-8133206 then was the issue addressed in > the libzip wrapper or in the zlib code? I thought it was the former. The code change is proposed in the libzip wrapper but the issue was triggered by the zlib library update. > > On a fallback or some way to configure at launch time then Sandhya > Viswanathan (Intel) has a proposal here last year. I think we mostly > agreed on that thread that switching the build to use the system zlib > by default would be better. I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS zlib libraries. Could we at least consider a runtime property to allow linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ? regards, Sean. [1] https://bugs.openjdk.java.net/browse/JDK-8044725 [2] https://bugs.openjdk.java.net/browse/JDK-8133206 From erik.joelsson at oracle.com Wed Feb 10 16:27:14 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Feb 2016 17:27:14 +0100 Subject: RFR: JDK-8145789: Switch JDK 9 to use Jib in JPRT In-Reply-To: <56BA4564.7040906@oracle.com> References: <5677DBDA.5000508@oracle.com> <56BA4564.7040906@oracle.com> Message-ID: <56BB64E2.1070207@oracle.com> Accidentally left some debug lines. Also reverted the change to set --with-jobs. http://cr.openjdk.java.net/~erikj/8145789/webrev.top.03/ /Erik On 2016-02-09 21:00, Erik Joelsson wrote: > This never made it in because of various issues. Those have now been > resolved, so reposting this, updated to latest jdk9/dev. > > Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.02/ > > /Erik > > On 2015-12-21 12:00, Erik Joelsson wrote: >> Hello, >> >> With Jib support in JDK 9, it would be nice to start using it in JPRT >> instead of having JPRT having to track dependencies and >> configurations. This change enables Jib in JPRT and disables all the >> JPRT functionality for tracking dependencies (build.needs and most >> configure args). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8145789 >> Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.01/ >> >> /Erik > From tim.bell at oracle.com Wed Feb 10 19:29:53 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 10 Feb 2016 11:29:53 -0800 Subject: RFR: JDK-8149479: Fix compare.sh to have a clean baseline with COMPARE_BUILD In-Reply-To: <56BB38C9.4080108@oracle.com> References: <56BA440E.7000309@oracle.com> <56BAD4FA.5050601@oracle.com> <56BB36E6.8030207@oracle.com> <56BB382E.9050509@oracle.com> <56BB38C9.4080108@oracle.com> Message-ID: <56BB8FB1.4060304@oracle.com> Erik: Looks good to me as well. Tim > Updated in place. > > /Erik > > On 2016-02-10 14:16, Magnus Ihse Bursie wrote: >> On 2016-02-10 14:11, Erik Joelsson wrote: >>> Hello Tim, >>> >>> New webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.02/ >>> >>> I agree about 1, so I started looking at it. Got confused why any >>> changes to it didn't seem to have any effect until I realized the >>> docs are no longer compared, which is what that was added for. So I >>> fixed comparing of docs and reduced the sed expressions to what is >>> actually necessary today, which was much less. >>> >>> 2 was indeed a typo and it could have hidden compare failures in my >>> JPRT runs. Luckily, it was still clean. >>> >>> I also fixed the comment Magnus pointed out. >> Almost, at least. ;-) >> >> You lost a colon: >> >> - # Syntax: COMPARE_BUILD=CONF=:PATCH=: >> + # Syntax: COMPARE_BUILD=CONF=:PATCH= >> >> >> If you just restore that colon, I'm fine with the new version. >> >> /Magnus >> >>> >>> /Erik >>> >>> On 2016-02-10 07:13, Tim Bell wrote: >>>> Erik: >>>> >>>>> Please review these fixes for compare.sh and the COMPARE_BUILD >>>>> flag for make. >>>>> >>>>> The rather new feature COMPARE_BUILD, which builds twice, applying >>>>> some kind of change between them, is really neat. Especially when >>>>> run through JPRT to check all platforms at once. The problem is >>>>> that compare.sh currently isn't clean on all these platforms. >>>>> There are also some special peculiarities particular to when JPRT >>>>> is running the build which confuses compare.sh. >>>>> >>>>> Given that COMPARE_BUILD uses the exact same output directory, and >>>>> JPRT sets the version-opt string to a fix value for both builds, >>>>> we should be able to achieve a clean and stable baseline for an >>>>> empty patch file. Which I now have. >>>>> >>>>> I also changed COMPARE_BUILD to fail the build when differences >>>>> are found and added an option to COMPARE_BUILD to disable failing. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149479 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8149479/webrev.01/ >>>> >>>> 1) Regarding common/bin/compare.sh lines 336...341 and lines >>>> 344...349 in the new version - this is not directly related to >>>> 8149479 but I wish those regexes were only coded once. If they ever >>>> get out of sync the results will be puzzling. >>>> >>>> 2) make/InitSupport.gmk line 366 in the new version - typo? >>>> COMPARE_BUILD_FAILE is COMPARE_BUILD_FAIL elsewhere >>>> >>>> Looks good otherwise. >>>> >>>> Tim >>>> >>> >> > From martinrb at google.com Wed Feb 10 19:43:44 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Feb 2016 11:43:44 -0800 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BB41E6.3060102@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> Message-ID: There's an endless debate about the pros and cons of "dynamic linking". I think it would be best for the JDK to link to system libraries by default, if possible. For a particular JDK image, one can drop a patched libz into a suitable lib directory to override the system one. It should also be relatively easy to build a JDK with a static libz.a. And all the cool kids are building docker images where they control everything. The zlib/info-zip projects don't exhibit a high level of code health, but OOTO they seem quite stable these days. From jesper.wilhelmsson at oracle.com Wed Feb 10 22:10:51 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 10 Feb 2016 23:10:51 +0100 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BB9E07.7030208@oracle.com> References: <56BB9E07.7030208@oracle.com> Message-ID: <56BBB56B.5020506@oracle.com> Sending again to include the build-dev list. /Jesper Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: > Hi, > > Please review this cleanup of the Hotspot makefiles. > > Since I have been spending some time in the makefiles lately there were a few > random cleanups that I couldn't stop myself from doing. Most of these are made > to make the linux and bsd makefiles more alike. This has helped a lot when > porting the framework to the different platforms. > > There are a couple of preparing alignment changes that I included in this > cleanup to make the Google test patch easier to review later. > > There are also a couple of "real" changes: > > * In make/bsd/makefiles/buildtree.make we set up OS_VENDOR with the motivation > that we don't include defs.make. Three lines below we include defs.make. > > * In make/bsd/makefiles/buildtree.make the 'install' target depends on > 'install_jsigs'. There is no rule called 'install_jsigs', it is called > 'install_jsig'. > > > Another difference that I find interesting but that I have not changed in this > patch (I can do that if requested) is that in the bsd version of fastdebug.make > VERSION is set to "fastdebug" but in the linux version it is set to "optimized". > Given the name of the makefile fastdebug seems more correct, but whichever is > the correct value, shouldn't they be the same on linux and bsd? > > > https://bugs.openjdk.java.net/browse/JDK-8149594 > http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ > > Thanks, > /Jesper From kim.barrett at oracle.com Wed Feb 10 22:34:56 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Feb 2016 17:34:56 -0500 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BBB56B.5020506@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> Message-ID: <16426566-DBB7-45E7-B934-2F68FF136745@oracle.com> Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: > https://bugs.openjdk.java.net/browse/JDK-8149594 > http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ ------------------------------------------------------------------------------ I might have preferred two webrevs, one of only whitespace changes and one of other changes. ------------------------------------------------------------------------------ make/bsd/Makefile make/linux/Makefile 172 TARGETS = debug fastdebug optimized product ... 200 BUILDTREE = $(MAKE) -f $(BUILDTREE_MAKE) $(BUILDTREE_VARS) If there's a non-whitespace change (increasing the separation between the variables and the "=" or "+="), I couldn't find it. I'm guessing this is being done because the planned later changes introduce something in here that leads to that reformatting? ------------------------------------------------------------------------------ make/bsd/makefiles/gcc.make 278 WARNING_FLAGS += -Wconversion Oh, cool! So we haven't been using that option after all! Note: This is a "real change" that wasn't mentioned in the RFR. I've been meaning to file a bug report against this for a while. The pre-gcc4.3 version of -Wconversion probably ought not be used in a production context anyway. https://gcc.gnu.org/wiki/NewWconversion The old behavior for -Wconversion was intended to aid translation of old C code to modern C standards by identifying places where adding function prototypes may result in different behavior. That's just not an issue for C++, nor for our code in general. And we're not prepared to use the new -Wconversion; see JDK-8135181. So rather than changing our builds to actually use this option with old compilers that Oracle doesn't support (so we can't locally test this change), I suggest removing the option entirely, since it hasn't actually been used anyway. ------------------------------------------------------------------------------ make/bsd/makefiles/jvmti.make make/linux/makefiles/trace.make The only non-copyright change in these files seem to be the addition of a blank line to the end of the file. ------------------------------------------------------------------------------ make/bsd/makefiles/top.make 88 vm_build_preliminaries: checks $(Cached_plat) $(AD_Files_If_Required) trace_stuff jvmti_stuff dtrace_stuff What is the point of re-ordering trace_stuff and jvmti_stuff? Also, elsewhere the whitespace after the target's ":" is minimized, but not here. ------------------------------------------------------------------------------ From magnus.ihse.bursie at oracle.com Wed Feb 10 23:09:28 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Feb 2016 00:09:28 +0100 Subject: RFR: JDK-8145789: Switch JDK 9 to use Jib in JPRT In-Reply-To: <56BB64E2.1070207@oracle.com> References: <5677DBDA.5000508@oracle.com> <56BA4564.7040906@oracle.com> <56BB64E2.1070207@oracle.com> Message-ID: <56BBC328.1010306@oracle.com> On 2016-02-10 17:27, Erik Joelsson wrote: > Accidentally left some debug lines. Also reverted the change to set > --with-jobs. > > http://cr.openjdk.java.net/~erikj/8145789/webrev.top.03/ Looks good to me. Go jib! :) /Magnus > > /Erik > > On 2016-02-09 21:00, Erik Joelsson wrote: >> This never made it in because of various issues. Those have now been >> resolved, so reposting this, updated to latest jdk9/dev. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.02/ >> >> /Erik >> >> On 2015-12-21 12:00, Erik Joelsson wrote: >>> Hello, >>> >>> With Jib support in JDK 9, it would be nice to start using it in >>> JPRT instead of having JPRT having to track dependencies and >>> configurations. This change enables Jib in JPRT and disables all the >>> JPRT functionality for tracking dependencies (build.needs and most >>> configure args). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145789 >>> Webrev: http://cr.openjdk.java.net/~erikj/8145789/webrev.top.01/ >>> >>> /Erik >> > From xueming.shen at oracle.com Thu Feb 11 00:25:51 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 10 Feb 2016 16:25:51 -0800 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BB4C24.7090607@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> <56BB4C24.7090607@oracle.com> Message-ID: <56BBD50F.8070803@oracle.com> One of the benefits of moving to the system libz is actually for better/easy maintenance. Just replacing the offending version of libz with an earlier/later version that works, instead of waiting for a customized jdk/jre image with a working/bundled libz, or the next update release. Especially given the fact that we have decided not to touch the libz at source level. Having dependency on the system libz is really not that bad. The experience suggests those binaries are quite stable. And it should always be easier to replace the system libz than a java runtime, in case of problem. Sherman On 02/10/2016 06:41 AM, Se?n Coffey wrote: > > On 10/02/16 14:29, Alan Bateman wrote: >> >> On 10/02/2016 13:57, Se?n Coffey wrote: >>> I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS zlib libraries. Could we at least consider a runtime property to allow linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ? >> Don't the LD_* environment variables serve this need already? Once the JDK is using the system zlib then this is the simplest way to get it to use a different libz library at runtime. > No - I don't see that as a solution. You've still made the default JDK config become dependent on OS environment for all libzip operations. I don't think we even capture the zlib version that the JDK would be operating with in any diagnostics. An application wanting a tried/tested and stable libzip version has extra work to do now. Letting the default be system dependent has just increased risk for QA teams also. A system property just makes this all go away. In fact - I would say that for JDK9, the default should be the JDK bundled libzip library. For those looking for libzip experimenting and performance benefits, they could take the system property approach. > > regards, > Sean. >> >> -Alan > > > On 08/02/16 09:55, Alan Bateman wrote: >> >> On 08/02/2016 10:42, Se?n Coffey wrote: >>> Is there an option to fall back to the older v.1.2.8 implementation if necessary ? It would certainly alleviate issues for any applications that might run into issues with the latest and greatest zlib libraries. JDK-8133206 would be one such example. >> Just at build time > so - we introduce a runtime dependency on the underlying zlib libraries on the OS by default. I would be very concerned with this approach. We've run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for the most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an inflation issue[1]. When JDK was upgraded to zlib v1.2.8, we received reports of performance/OOM issues [2]. >> but if the zlib on the platform is broken then it impacts tools and probably lots of things. I would assume the OS would patch such issues quickly. In the case of JDK-8133206 then was the issue addressed in the libzip wrapper or in the zlib code? I thought it was the former. > The code change is proposed in the libzip wrapper but the issue was triggered by the zlib library update. >> >> On a fallback or some way to configure at launch time then Sandhya Viswanathan (Intel) has a proposal here last year. I think we mostly agreed on that thread that switching the build to use the system zlib by default would be better. > I'm all for allowing one to introduce a new version of zlib to their JDK at runtime. I just don't think it's in the interests of enterprises and stability to introduce a dependency to the JDK on the underlying OS zlib libraries. Could we at least consider a runtime property to allow linking to the (currently bundled) zlib v.1.2.8 port in case issues arise ? > > regards, > Sean. > > [1] https://bugs.openjdk.java.net/browse/JDK-8044725 > [2] https://bugs.openjdk.java.net/browse/JDK-8133206 > From jesper.wilhelmsson at oracle.com Thu Feb 11 00:51:51 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Feb 2016 01:51:51 +0100 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <16426566-DBB7-45E7-B934-2F68FF136745@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> <16426566-DBB7-45E7-B934-2F68FF136745@oracle.com> Message-ID: <56BBDB27.4040107@oracle.com> Hi Kim, Thanks for looking at this! Den 10/2/16 kl. 23:34, skrev Kim Barrett: > Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: >> https://bugs.openjdk.java.net/browse/JDK-8149594 >> http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ > > > ------------------------------------------------------------------------------ > I might have preferred two webrevs, one of only whitespace changes and > one of other changes. Yes, I'll split it up in the next version if there is a need for it. > ------------------------------------------------------------------------------ > make/bsd/Makefile > make/linux/Makefile > 172 TARGETS = debug fastdebug optimized product > ... > 200 BUILDTREE = $(MAKE) -f $(BUILDTREE_MAKE) $(BUILDTREE_VARS) > > If there's a non-whitespace change (increasing the separation between > the variables and the "=" or "+="), I couldn't find it. I'm guessing > this is being done because the planned later changes introduce > something in here that leads to that reformatting? Yes, this is one of those changes that is motivated by future changes. I wanted to separate this whitespace change from the actual change to make that one easier to review. > > ------------------------------------------------------------------------------ > make/bsd/makefiles/gcc.make > 278 WARNING_FLAGS += -Wconversion > > Oh, cool! So we haven't been using that option after all! > > Note: This is a "real change" that wasn't mentioned in the RFR. > > I've been meaning to file a bug report against this for a while. The > pre-gcc4.3 version of -Wconversion probably ought not be used in a > production context anyway. > > https://gcc.gnu.org/wiki/NewWconversion > The old behavior for -Wconversion was intended to aid translation of > old C code to modern C standards by identifying places where adding > function prototypes may result in different behavior. That's just not > an issue for C++, nor for our code in general. > > And we're not prepared to use the new -Wconversion; see JDK-8135181. > > So rather than changing our builds to actually use this option with > old compilers that Oracle doesn't support (so we can't locally test > this change), I suggest removing the option entirely, since it hasn't > actually been used anyway. This typo was only present on bsd. Are you suggesting to remove it only on bsd, or on linux as well? > > ------------------------------------------------------------------------------ > make/bsd/makefiles/jvmti.make > make/linux/makefiles/trace.make > > The only non-copyright change in these files seem to be the addition > of a blank line to the end of the file. Yes, this is to make the bsd and linux versions of the files the same. It makes it easier to apply patches from one platform to the other when porting stuff. > > ------------------------------------------------------------------------------ > make/bsd/makefiles/top.make > 88 vm_build_preliminaries: checks $(Cached_plat) $(AD_Files_If_Required) trace_stuff jvmti_stuff dtrace_stuff > > What is the point of re-ordering trace_stuff and jvmti_stuff? To make the bsd and linux versions the same. > > Also, elsewhere the whitespace after the target's ":" is minimized, > but not here. Oops. I'll fix that. /Jesper > > ------------------------------------------------------------------------------ > From kim.barrett at oracle.com Thu Feb 11 01:15:34 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 10 Feb 2016 20:15:34 -0500 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BBDB27.4040107@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> <16426566-DBB7-45E7-B934-2F68FF136745@oracle.com> <56BBDB27.4040107@oracle.com> Message-ID: > On Feb 10, 2016, at 7:51 PM, Jesper Wilhelmsson wrote: > Den 10/2/16 kl. 23:34, skrev Kim Barrett: >> Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: >>> https://bugs.openjdk.java.net/browse/JDK-8149594 >>> http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ >> >> >> ------------------------------------------------------------------------------ >> I might have preferred two webrevs, one of only whitespace changes and >> one of other changes. > > Yes, I'll split it up in the next version if there is a need for it. Thanks. >> ------------------------------------------------------------------------------ >> make/bsd/makefiles/gcc.make >> 278 WARNING_FLAGS += -Wconversion >> >> Oh, cool! So we haven't been using that option after all! >> >> Note: This is a "real change" that wasn't mentioned in the RFR. >> >> I've been meaning to file a bug report against this for a while. The >> pre-gcc4.3 version of -Wconversion probably ought not be used in a >> production context anyway. >> >> https://gcc.gnu.org/wiki/NewWconversion >> The old behavior for -Wconversion was intended to aid translation of >> old C code to modern C standards by identifying places where adding >> function prototypes may result in different behavior. That's just not >> an issue for C++, nor for our code in general. >> >> And we're not prepared to use the new -Wconversion; see JDK-8135181. >> >> So rather than changing our builds to actually use this option with >> old compilers that Oracle doesn't support (so we can't locally test >> this change), I suggest removing the option entirely, since it hasn't >> actually been used anyway. > > This typo was only present on bsd. Are you suggesting to remove it only on bsd, or on linux as well? Oh, ick! I forgot there are two of these. *I* think it should be removed in both. But maybe doing anything either way should be done as a separate thing? And whatever is done here should be checked with folks like SAP who actually build with old versions of gcc. From david.holmes at oracle.com Thu Feb 11 02:07:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Feb 2016 12:07:49 +1000 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BBB56B.5020506@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> Message-ID: <56BBECF5.6050708@oracle.com> Jesper, Magnus is rewriting all of the hotspot build system. Are these cleanups really worthwhile at this stage? David On 11/02/2016 8:10 AM, Jesper Wilhelmsson wrote: > Sending again to include the build-dev list. > /Jesper > > Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: >> Hi, >> >> Please review this cleanup of the Hotspot makefiles. >> >> Since I have been spending some time in the makefiles lately there >> were a few >> random cleanups that I couldn't stop myself from doing. Most of these >> are made >> to make the linux and bsd makefiles more alike. This has helped a lot >> when >> porting the framework to the different platforms. >> >> There are a couple of preparing alignment changes that I included in this >> cleanup to make the Google test patch easier to review later. >> >> There are also a couple of "real" changes: >> >> * In make/bsd/makefiles/buildtree.make we set up OS_VENDOR with the >> motivation >> that we don't include defs.make. Three lines below we include defs.make. >> >> * In make/bsd/makefiles/buildtree.make the 'install' target depends on >> 'install_jsigs'. There is no rule called 'install_jsigs', it is called >> 'install_jsig'. >> >> >> Another difference that I find interesting but that I have not changed >> in this >> patch (I can do that if requested) is that in the bsd version of >> fastdebug.make >> VERSION is set to "fastdebug" but in the linux version it is set to >> "optimized". >> Given the name of the makefile fastdebug seems more correct, but >> whichever is >> the correct value, shouldn't they be the same on linux and bsd? >> >> >> https://bugs.openjdk.java.net/browse/JDK-8149594 >> http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ >> >> Thanks, >> /Jesper From martinrb at google.com Thu Feb 11 03:19:35 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 Feb 2016 19:19:35 -0800 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BBD50F.8070803@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> <56BB4C24.7090607@oracle.com> <56BBD50F.8070803@oracle.com> Message-ID: I'm actually very happy that we've dropped private patches against libz. And using the system libz seems like the right thing to do on Unix systems, where libz should be ubiquitous. On Wed, Feb 10, 2016 at 4:25 PM, Xueming Shen wrote: > > One of the benefits of moving to the system libz is actually for better/easy > maintenance. Just replacing the offending version of libz with an > earlier/later > version that works, instead of waiting for a customized jdk/jre image with a > working/bundled libz, or the next update release. Especially given the fact > that we have decided not to touch the libz at source level. Having > dependency > on the system libz is really not that bad. The experience suggests those > binaries are quite stable. And it should always be easier to replace the > system libz than a java runtime, in case of problem. > > Sherman > > > On 02/10/2016 06:41 AM, Se?n Coffey wrote: >> >> >> On 10/02/16 14:29, Alan Bateman wrote: >>> >>> >>> On 10/02/2016 13:57, Se?n Coffey wrote: >>>> >>>> I'm all for allowing one to introduce a new version of zlib to their JDK >>>> at runtime. I just don't think it's in the interests of enterprises and >>>> stability to introduce a dependency to the JDK on the underlying OS zlib >>>> libraries. Could we at least consider a runtime property to allow linking to >>>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>> >>> Don't the LD_* environment variables serve this need already? Once the >>> JDK is using the system zlib then this is the simplest way to get it to use >>> a different libz library at runtime. >> >> No - I don't see that as a solution. You've still made the default JDK >> config become dependent on OS environment for all libzip operations. I don't >> think we even capture the zlib version that the JDK would be operating with >> in any diagnostics. An application wanting a tried/tested and stable libzip >> version has extra work to do now. Letting the default be system dependent >> has just increased risk for QA teams also. A system property just makes this >> all go away. In fact - I would say that for JDK9, the default should be the >> JDK bundled libzip library. For those looking for libzip experimenting and >> performance benefits, they could take the system property approach. >> >> regards, >> Sean. >>> >>> >>> -Alan >> >> >> >> On 08/02/16 09:55, Alan Bateman wrote: >>> >>> >>> On 08/02/2016 10:42, Se?n Coffey wrote: >>>> >>>> Is there an option to fall back to the older v.1.2.8 implementation if >>>> necessary ? It would certainly alleviate issues for any applications that >>>> might run into issues with the latest and greatest zlib libraries. >>>> JDK-8133206 would be one such example. >>> >>> Just at build time >> >> so - we introduce a runtime dependency on the underlying zlib libraries on >> the OS by default. I would be very concerned with this approach. We've run >> JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for the >> most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an inflation >> issue[1]. When JDK was upgraded to zlib v1.2.8, we received reports of >> performance/OOM issues [2]. >>> >>> but if the zlib on the platform is broken then it impacts tools and >>> probably lots of things. I would assume the OS would patch such issues >>> quickly. In the case of JDK-8133206 then was the issue addressed in the >>> libzip wrapper or in the zlib code? I thought it was the former. >> >> The code change is proposed in the libzip wrapper but the issue was >> triggered by the zlib library update. >>> >>> >>> On a fallback or some way to configure at launch time then Sandhya >>> Viswanathan (Intel) has a proposal here last year. I think we mostly agreed >>> on that thread that switching the build to use the system zlib by default >>> would be better. >> >> I'm all for allowing one to introduce a new version of zlib to their JDK >> at runtime. I just don't think it's in the interests of enterprises and >> stability to introduce a dependency to the JDK on the underlying OS zlib >> libraries. Could we at least consider a runtime property to allow linking to >> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >> >> regards, >> Sean. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8044725 >> [2] https://bugs.openjdk.java.net/browse/JDK-8133206 >> > From jesper.wilhelmsson at oracle.com Thu Feb 11 07:35:25 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 11 Feb 2016 08:35:25 +0100 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BBECF5.6050708@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> <56BBECF5.6050708@oracle.com> Message-ID: <56BC39BD.6010303@oracle.com> Den 11/2/16 kl. 03:07, skrev David Holmes: > Jesper, > > Magnus is rewriting all of the hotspot build system. Are these cleanups really > worthwhile at this stage? The cleanups are worthwhile to me since I work on mostly Mac and port all my changes over to the linux makefiles in bulk, and without these cleanups my patches won't apply cleanly. The reason I want to push them now even though it is a while left until the GTest stuff is done, is that every time anyone makes a change in the makefiles (which happens more often than I had expected) I get merge conflicts everywhere. /Jesper > > David > > On 11/02/2016 8:10 AM, Jesper Wilhelmsson wrote: >> Sending again to include the build-dev list. >> /Jesper >> >> Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: >>> Hi, >>> >>> Please review this cleanup of the Hotspot makefiles. >>> >>> Since I have been spending some time in the makefiles lately there >>> were a few >>> random cleanups that I couldn't stop myself from doing. Most of these >>> are made >>> to make the linux and bsd makefiles more alike. This has helped a lot >>> when >>> porting the framework to the different platforms. >>> >>> There are a couple of preparing alignment changes that I included in this >>> cleanup to make the Google test patch easier to review later. >>> >>> There are also a couple of "real" changes: >>> >>> * In make/bsd/makefiles/buildtree.make we set up OS_VENDOR with the >>> motivation >>> that we don't include defs.make. Three lines below we include defs.make. >>> >>> * In make/bsd/makefiles/buildtree.make the 'install' target depends on >>> 'install_jsigs'. There is no rule called 'install_jsigs', it is called >>> 'install_jsig'. >>> >>> >>> Another difference that I find interesting but that I have not changed >>> in this >>> patch (I can do that if requested) is that in the bsd version of >>> fastdebug.make >>> VERSION is set to "fastdebug" but in the linux version it is set to >>> "optimized". >>> Given the name of the makefile fastdebug seems more correct, but >>> whichever is >>> the correct value, shouldn't they be the same on linux and bsd? >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8149594 >>> http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ >>> >>> Thanks, >>> /Jesper From sean.coffey at oracle.com Thu Feb 11 10:34:20 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 11 Feb 2016 10:34:20 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BBD50F.8070803@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> <56BB4C24.7090607@oracle.com> <56BBD50F.8070803@oracle.com> Message-ID: <56BC63AC.9050702@oracle.com> On 11/02/2016 00:25, Xueming Shen wrote: > > One of the benefits of moving to the system libz is actually for > better/easy > maintenance. Just replacing the offending version of libz with an > earlier/later > version that works, instead of waiting for a customized jdk/jre image > with a > working/bundled libz, or the next update release. Especially given the > fact > that we have decided not to touch the libz at source level. Having > dependency > on the system libz is really not that bad. The experience suggests those > binaries are quite stable. And it should always be easier to replace the > system libz than a java runtime, in case of problem. I think people overestimate people's ability to 'just replace' a zlib library. Adding a new system property is a struggle for some enterprises. We'll enjoy supporting a many to one matrix of zlib:JDK scenarios now rather than old style 1:1. It's great to have system library support - I'm just highlighting a possible risk. A fall back option solves that but there's no appetite for such a solution. Let's see how it goes. regards, Sean. > > Sherman > > On 02/10/2016 06:41 AM, Se?n Coffey wrote: >> >> On 10/02/16 14:29, Alan Bateman wrote: >>> >>> On 10/02/2016 13:57, Se?n Coffey wrote: >>>> I'm all for allowing one to introduce a new version of zlib to >>>> their JDK at runtime. I just don't think it's in the interests of >>>> enterprises and stability to introduce a dependency to the JDK on >>>> the underlying OS zlib libraries. Could we at least consider a >>>> runtime property to allow linking to the (currently bundled) zlib >>>> v.1.2.8 port in case issues arise ? >>> Don't the LD_* environment variables serve this need already? Once >>> the JDK is using the system zlib then this is the simplest way to >>> get it to use a different libz library at runtime. >> No - I don't see that as a solution. You've still made the default >> JDK config become dependent on OS environment for all libzip >> operations. I don't think we even capture the zlib version that the >> JDK would be operating with in any diagnostics. An application >> wanting a tried/tested and stable libzip version has extra work to do >> now. Letting the default be system dependent has just increased risk >> for QA teams also. A system property just makes this all go away. In >> fact - I would say that for JDK9, the default should be the JDK >> bundled libzip library. For those looking for libzip experimenting >> and performance benefits, they could take the system property approach. >> >> regards, >> Sean. >>> >>> -Alan >> >> >> On 08/02/16 09:55, Alan Bateman wrote: >>> >>> On 08/02/2016 10:42, Se?n Coffey wrote: >>>> Is there an option to fall back to the older v.1.2.8 implementation >>>> if necessary ? It would certainly alleviate issues for any >>>> applications that might run into issues with the latest and >>>> greatest zlib libraries. JDK-8133206 would be one such example. >>> Just at build time >> so - we introduce a runtime dependency on the underlying zlib >> libraries on the OS by default. I would be very concerned with this >> approach. We've run JDK 6 for 10+ years with zlib v1.1.3. It was >> consistent and reliable for the most part. When we moved JDK7/8 to >> zlib v1.2.5, we encountered an inflation issue[1]. When JDK was >> upgraded to zlib v1.2.8, we received reports of performance/OOM >> issues [2]. >>> but if the zlib on the platform is broken then it impacts tools and >>> probably lots of things. I would assume the OS would patch such >>> issues quickly. In the case of JDK-8133206 then was the issue >>> addressed in the libzip wrapper or in the zlib code? I thought it >>> was the former. >> The code change is proposed in the libzip wrapper but the issue was >> triggered by the zlib library update. >>> >>> On a fallback or some way to configure at launch time then Sandhya >>> Viswanathan (Intel) has a proposal here last year. I think we mostly >>> agreed on that thread that switching the build to use the system >>> zlib by default would be better. >> I'm all for allowing one to introduce a new version of zlib to their >> JDK at runtime. I just don't think it's in the interests of >> enterprises and stability to introduce a dependency to the JDK on the >> underlying OS zlib libraries. Could we at least consider a runtime >> property to allow linking to the (currently bundled) zlib v.1.2.8 >> port in case issues arise ? >> >> regards, >> Sean. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8044725 >> [2] https://bugs.openjdk.java.net/browse/JDK-8133206 >> > From magnus.ihse.bursie at oracle.com Thu Feb 11 11:20:07 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Feb 2016 12:20:07 +0100 Subject: RFR: JDK-8149647 Incremental enhancements from build-infra Message-ID: <56BC6E67.300@oracle.com> Here is another batch of small fixes and enhancements from the build-infra project forest. * Compiler version framework: - Create a TOOLCHAIN_CHECK_COMPILER_VERSION macro - Test for minimum versions for certain compilers in configure * Start supporting mapfiles on all platforms (windows and macosx as well) * Fix errors/bad looking output in configure * Fix bugs for debug symbols on macosx when building with --with-native-debug-symbols=external * Simplify hotspot version.rc: replace HS_VER with JDK_VER, and HS_DOTVER with JDK_DOTVER (they are always the same) * INCLUDE_SA fixes: - Move the check of INCLUDE_SA to jdk-options.m4. - Use INCLUDE_SA for proper testing for SA in makefiles. * Set --with-native-debug-symbols default to "none" for STATIC_BUILD. * Compare script improvements * Incremental fixes in NativeCompilation.gmk. * Incremental fixes in flags.m4 * Remove left-over comments * Misc other changes * Whitespace fixes Bug: https://bugs.openjdk.java.net/browse/JDK-8149647 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8149647-incremental-build-infra-fixes-incl-compiler-version/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Feb 11 13:26:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Feb 2016 14:26:46 +0100 Subject: RFR: JDK-8149647 Incremental enhancements from build-infra In-Reply-To: <56BC6E67.300@oracle.com> References: <56BC6E67.300@oracle.com> Message-ID: <56BC8C16.9080808@oracle.com> flags.m4: spelling "contitionally" Otherwise it looks good enough to me provided that it builds and output is still the same. /Erik On 2016-02-11 12:20, Magnus Ihse Bursie wrote: > Here is another batch of small fixes and enhancements from the > build-infra project forest. > > * Compiler version framework: > - Create a TOOLCHAIN_CHECK_COMPILER_VERSION macro > - Test for minimum versions for certain compilers in configure > * Start supporting mapfiles on all platforms (windows and macosx as well) > * Fix errors/bad looking output in configure > * Fix bugs for debug symbols on macosx when building with > --with-native-debug-symbols=external > * Simplify hotspot version.rc: replace HS_VER with JDK_VER, and > HS_DOTVER with JDK_DOTVER (they are always the same) > * INCLUDE_SA fixes: > - Move the check of INCLUDE_SA to jdk-options.m4. > - Use INCLUDE_SA for proper testing for SA in makefiles. > * Set --with-native-debug-symbols default to "none" for STATIC_BUILD. > * Compare script improvements > * Incremental fixes in NativeCompilation.gmk. > * Incremental fixes in flags.m4 > * Remove left-over comments > * Misc other changes > * Whitespace fixes > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149647 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8149647-incremental-build-infra-fixes-incl-compiler-version/webrev.01 > > /Magnus > From alexey.ivanov at oracle.com Thu Feb 11 14:19:12 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 11 Feb 2016 17:19:12 +0300 Subject: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc Message-ID: <56BC9860.7050006@oracle.com> Hello, Could you please review the fix for JDK-8147807 and approve push to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ The issue is not relevant to jdk 9. The fix just removes kcms service leaving lcms as the only option which is the default in jdk8. Thanks in advance, Alexey From martinrb at google.com Thu Feb 11 18:49:21 2016 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Feb 2016 10:49:21 -0800 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: <56BC63AC.9050702@oracle.com> References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> <56BB4C24.7090607@oracle.com> <56BBD50F.8070803@oracle.com> <56BC63AC.9050702@oracle.com> Message-ID: Currently the pendulum is swinging away from multiple applications sharing common libraries towards every application being self-contained, perhaps because disk space is dirt cheap and because of the rise of "containers". It may be that much of the packaging of jdks will be picked up by third parties who package up the JDK and any of its dependencies - e.g. I already see https://hub.docker.com/_/java/ On Thu, Feb 11, 2016 at 2:34 AM, Se?n Coffey wrote: > > On 11/02/2016 00:25, Xueming Shen wrote: >> >> >> One of the benefits of moving to the system libz is actually for >> better/easy >> maintenance. Just replacing the offending version of libz with an >> earlier/later >> version that works, instead of waiting for a customized jdk/jre image with >> a >> working/bundled libz, or the next update release. Especially given the >> fact >> that we have decided not to touch the libz at source level. Having >> dependency >> on the system libz is really not that bad. The experience suggests those >> binaries are quite stable. And it should always be easier to replace the >> system libz than a java runtime, in case of problem. > > > I think people overestimate people's ability to 'just replace' a zlib > library. Adding a new system property is a struggle for some enterprises. > We'll enjoy supporting a many to one matrix of zlib:JDK scenarios now rather > than old style 1:1. It's great to have system library support - I'm just > highlighting a possible risk. A fall back option solves that but there's no > appetite for such a solution. Let's see how it goes. > > regards, > Sean. > >> >> Sherman >> >> On 02/10/2016 06:41 AM, Se?n Coffey wrote: >>> >>> >>> On 10/02/16 14:29, Alan Bateman wrote: >>>> >>>> >>>> On 10/02/2016 13:57, Se?n Coffey wrote: >>>>> >>>>> I'm all for allowing one to introduce a new version of zlib to their >>>>> JDK at runtime. I just don't think it's in the interests of enterprises and >>>>> stability to introduce a dependency to the JDK on the underlying OS zlib >>>>> libraries. Could we at least consider a runtime property to allow linking to >>>>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>>> >>>> Don't the LD_* environment variables serve this need already? Once the >>>> JDK is using the system zlib then this is the simplest way to get it to use >>>> a different libz library at runtime. >>> >>> No - I don't see that as a solution. You've still made the default JDK >>> config become dependent on OS environment for all libzip operations. I don't >>> think we even capture the zlib version that the JDK would be operating with >>> in any diagnostics. An application wanting a tried/tested and stable libzip >>> version has extra work to do now. Letting the default be system dependent >>> has just increased risk for QA teams also. A system property just makes this >>> all go away. In fact - I would say that for JDK9, the default should be the >>> JDK bundled libzip library. For those looking for libzip experimenting and >>> performance benefits, they could take the system property approach. >>> >>> regards, >>> Sean. >>>> >>>> >>>> -Alan >>> >>> >>> >>> On 08/02/16 09:55, Alan Bateman wrote: >>>> >>>> >>>> On 08/02/2016 10:42, Se?n Coffey wrote: >>>>> >>>>> Is there an option to fall back to the older v.1.2.8 implementation if >>>>> necessary ? It would certainly alleviate issues for any applications that >>>>> might run into issues with the latest and greatest zlib libraries. >>>>> JDK-8133206 would be one such example. >>>> >>>> Just at build time >>> >>> so - we introduce a runtime dependency on the underlying zlib libraries >>> on the OS by default. I would be very concerned with this approach. We've >>> run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for >>> the most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an >>> inflation issue[1]. When JDK was upgraded to zlib v1.2.8, we received >>> reports of performance/OOM issues [2]. >>>> >>>> but if the zlib on the platform is broken then it impacts tools and >>>> probably lots of things. I would assume the OS would patch such issues >>>> quickly. In the case of JDK-8133206 then was the issue addressed in the >>>> libzip wrapper or in the zlib code? I thought it was the former. >>> >>> The code change is proposed in the libzip wrapper but the issue was >>> triggered by the zlib library update. >>>> >>>> >>>> On a fallback or some way to configure at launch time then Sandhya >>>> Viswanathan (Intel) has a proposal here last year. I think we mostly agreed >>>> on that thread that switching the build to use the system zlib by default >>>> would be better. >>> >>> I'm all for allowing one to introduce a new version of zlib to their JDK >>> at runtime. I just don't think it's in the interests of enterprises and >>> stability to introduce a dependency to the JDK on the underlying OS zlib >>> libraries. Could we at least consider a runtime property to allow linking to >>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>> >>> regards, >>> Sean. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8044725 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8133206 >>> >> > From magnus.ihse.bursie at oracle.com Fri Feb 12 08:17:12 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 09:17:12 +0100 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BC39BD.6010303@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> <56BBECF5.6050708@oracle.com> <56BC39BD.6010303@oracle.com> Message-ID: <56BD9508.6060406@oracle.com> On 2016-02-11 08:35, Jesper Wilhelmsson wrote: > Den 11/2/16 kl. 03:07, skrev David Holmes: >> Jesper, >> >> Magnus is rewriting all of the hotspot build system. Are these >> cleanups really >> worthwhile at this stage? > > The cleanups are worthwhile to me since I work on mostly Mac and port > all my changes over to the linux makefiles in bulk, and without these > cleanups my patches won't apply cleanly. The reason I want to push > them now even though it is a while left until the GTest stuff is done, > is that every time anyone makes a change in the makefiles (which > happens more often than I had expected) I get merge conflicts everywhere. If you want to make whitespace change, and/or structural changes that do not affect the behavior (and you can swear honest-to-god that it does not do any such thing), I have no objection. It is perhaps not the best spent time to clean up the old makefiles, but if you've already done it, what the heck. However, I'm wary of *actual* changes. First, I'm afraid that any real change may have unintended consequences. I saw your and Kim's discussion about -Wconversion. I didn't follow it entirely, but I know that we have previously actively *disabled* -Wconversion since it lead to problems. Just haphazardly enabling it again sounds like a bad idea. Second, any real changes pushed to the old hotspot make system must be re-implemented by me in the new hotspot build (until the point comes where it is merged into mainline). If they are hidden in the midst of a sea of whitespace changes (and even worse, if they are done unintentionally), that's a hopelessly time-consuming and in essence unneccessary work for me. So, I will not reject your patch, but I do require that you at least separate whitespace (and other structural but non-functional) changes into a separate fix. If you have any *real* changes, these must be tested thoroughly on all relevant platforms and compilers. /Magnus > /Jesper > >> >> David >> >> On 11/02/2016 8:10 AM, Jesper Wilhelmsson wrote: >>> Sending again to include the build-dev list. >>> /Jesper >>> >>> Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: >>>> Hi, >>>> >>>> Please review this cleanup of the Hotspot makefiles. >>>> >>>> Since I have been spending some time in the makefiles lately there >>>> were a few >>>> random cleanups that I couldn't stop myself from doing. Most of these >>>> are made >>>> to make the linux and bsd makefiles more alike. This has helped a lot >>>> when >>>> porting the framework to the different platforms. >>>> >>>> There are a couple of preparing alignment changes that I included >>>> in this >>>> cleanup to make the Google test patch easier to review later. >>>> >>>> There are also a couple of "real" changes: >>>> >>>> * In make/bsd/makefiles/buildtree.make we set up OS_VENDOR with the >>>> motivation >>>> that we don't include defs.make. Three lines below we include >>>> defs.make. >>>> >>>> * In make/bsd/makefiles/buildtree.make the 'install' target depends on >>>> 'install_jsigs'. There is no rule called 'install_jsigs', it is called >>>> 'install_jsig'. >>>> >>>> >>>> Another difference that I find interesting but that I have not changed >>>> in this >>>> patch (I can do that if requested) is that in the bsd version of >>>> fastdebug.make >>>> VERSION is set to "fastdebug" but in the linux version it is set to >>>> "optimized". >>>> Given the name of the makefile fastdebug seems more correct, but >>>> whichever is >>>> the correct value, shouldn't they be the same on linux and bsd? >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8149594 >>>> http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ >>>> >>>> Thanks, >>>> /Jesper From alexey.ivanov at oracle.com Fri Feb 12 08:19:02 2016 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 12 Feb 2016 11:19:02 +0300 Subject: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BC9860.7050006@oracle.com> References: <56BC9860.7050006@oracle.com> Message-ID: <56BD9576.4090904@oracle.com> I forgot to add jdk8u-dev list... On 11.02.2016 17:19, Alexey Ivanov wrote: > Hello, > > Could you please review the fix for JDK-8147807 and approve push to > 8u-dev? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 > Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ > > The issue is not relevant to jdk 9. > > The fix just removes kcms service leaving lcms as the only option > which is the default in jdk8. > > > Thanks in advance, > Alexey From magnus.ihse.bursie at oracle.com Fri Feb 12 08:22:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 09:22:19 +0100 Subject: RFR: 8149594 - Clean up Hotspot makefiles In-Reply-To: <56BBB56B.5020506@oracle.com> References: <56BB9E07.7030208@oracle.com> <56BBB56B.5020506@oracle.com> Message-ID: <56BD963B.6070904@oracle.com> On 2016-02-10 23:10, Jesper Wilhelmsson wrote: > Sending again to include the build-dev list. > /Jesper > > Den 10/2/16 kl. 21:31, skrev Jesper Wilhelmsson: >> Hi, >> >> Please review this cleanup of the Hotspot makefiles. >> >> Since I have been spending some time in the makefiles lately there >> were a few >> random cleanups that I couldn't stop myself from doing. Most of these >> are made >> to make the linux and bsd makefiles more alike. This has helped a lot >> when >> porting the framework to the different platforms. >> >> There are a couple of preparing alignment changes that I included in >> this >> cleanup to make the Google test patch easier to review later. >> >> There are also a couple of "real" changes: >> >> * In make/bsd/makefiles/buildtree.make we set up OS_VENDOR with the >> motivation >> that we don't include defs.make. Three lines below we include defs.make. ... and the very first thing we do with OS_VENDOR in defs.make is: ifeq ($(OS_VENDOR), Darwin) ifneq ($(MACOSX_UNIVERSAL), true) EXPORT_LIB_ARCH_DIR = $(EXPORT_LIB_DIR) endif endif which will not be done if you change buildtree.make. The old build system is a real mess. All changes can have unintended consequences unless carefully followed all the way. Now, there's a separate patch on the way to remove the universal build (don't know the status of that one) so maybe this doesn't matter. But still. Any "real" changes to the hotspot makefiles seems like an unneccessary risk at this point, at least if mixed with tons of whitespace changes. >> * In make/bsd/makefiles/buildtree.make the 'install' target depends on >> 'install_jsigs'. There is no rule called 'install_jsigs', it is called >> 'install_jsig'. So is this a bug fix? Apparently the libjsig is build properly on macosx, so what would this change achieve? /Magnus >> >> >> Another difference that I find interesting but that I have not >> changed in this >> patch (I can do that if requested) is that in the bsd version of >> fastdebug.make >> VERSION is set to "fastdebug" but in the linux version it is set to >> "optimized". >> Given the name of the makefile fastdebug seems more correct, but >> whichever is >> the correct value, shouldn't they be the same on linux and bsd? >> >> >> https://bugs.openjdk.java.net/browse/JDK-8149594 >> http://cr.openjdk.java.net/~jwilhelm/8149594/webrev.00/ >> >> Thanks, >> /Jesper From sean.coffey at oracle.com Fri Feb 12 09:15:27 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 12 Feb 2016 09:15:27 +0000 Subject: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BD9576.4090904@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> Message-ID: <56BDA2AF.9000209@oracle.com> Approved for jdk8u-dev once you have a peer code review. Regards, Sean. On 12/02/2016 08:19, Alexey Ivanov wrote: > I forgot to add jdk8u-dev list... > > On 11.02.2016 17:19, Alexey Ivanov wrote: >> Hello, >> >> Could you please review the fix for JDK-8147807 and approve push to >> 8u-dev? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >> >> The issue is not relevant to jdk 9. >> >> The fix just removes kcms service leaving lcms as the only option >> which is the default in jdk8. >> >> >> Thanks in advance, >> Alexey > From magnus.ihse.bursie at oracle.com Fri Feb 12 10:11:42 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 11:11:42 +0100 Subject: RFR: JDK-8149647 Incremental enhancements from build-infra In-Reply-To: <56BC8C16.9080808@oracle.com> References: <56BC6E67.300@oracle.com> <56BC8C16.9080808@oracle.com> Message-ID: <56BDAFDE.4030707@oracle.com> On 2016-02-11 14:26, Erik Joelsson wrote: > flags.m4: spelling "contitionally" Fixed. > > Otherwise it looks good enough to me provided that it builds and > output is still the same. I ran it through JPRT with your new and improved compare script. I got a compare failure on macosx for libosxui.dylib. I re-ran the test and it passed (!). I ran a separate test with an empty patch file on macosx, and it too failed on libosxui. Most libraries, but not libosxui.dylib are listed in the ACCEPTED_BIN_DIFF section. So I took the liberty of adding libosxui.dylib to that section as well, as part of the patch. Hope you don't mind. :) /Magnus > > /Erik > > On 2016-02-11 12:20, Magnus Ihse Bursie wrote: >> Here is another batch of small fixes and enhancements from the >> build-infra project forest. >> >> * Compiler version framework: >> - Create a TOOLCHAIN_CHECK_COMPILER_VERSION macro >> - Test for minimum versions for certain compilers in configure >> * Start supporting mapfiles on all platforms (windows and macosx as >> well) >> * Fix errors/bad looking output in configure >> * Fix bugs for debug symbols on macosx when building with >> --with-native-debug-symbols=external >> * Simplify hotspot version.rc: replace HS_VER with JDK_VER, and >> HS_DOTVER with JDK_DOTVER (they are always the same) >> * INCLUDE_SA fixes: >> - Move the check of INCLUDE_SA to jdk-options.m4. >> - Use INCLUDE_SA for proper testing for SA in makefiles. >> * Set --with-native-debug-symbols default to "none" for STATIC_BUILD. >> * Compare script improvements >> * Incremental fixes in NativeCompilation.gmk. >> * Incremental fixes in flags.m4 >> * Remove left-over comments >> * Misc other changes >> * Whitespace fixes >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8149647 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8149647-incremental-build-infra-fixes-incl-compiler-version/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Feb 12 11:25:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Feb 2016 12:25:19 +0100 Subject: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BDA2AF.9000209@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> <56BDA2AF.9000209@oracle.com> Message-ID: <56BDC11F.6000403@oracle.com> On 2016-02-12 10:15, Se?n Coffey wrote: > Approved for jdk8u-dev once you have a peer code review. Makefile change look good. /Magnus > > Regards, > Sean. > > On 12/02/2016 08:19, Alexey Ivanov wrote: >> I forgot to add jdk8u-dev list... >> >> On 11.02.2016 17:19, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for JDK-8147807 and approve push to >>> 8u-dev? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >>> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >>> >>> The issue is not relevant to jdk 9. >>> >>> The fix just removes kcms service leaving lcms as the only option >>> which is the default in jdk8. >>> >>> >>> Thanks in advance, >>> Alexey >> > From erik.joelsson at oracle.com Mon Feb 15 09:00:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Feb 2016 10:00:54 +0100 Subject: RFR: JDK-8149647 Incremental enhancements from build-infra In-Reply-To: <56BDAFDE.4030707@oracle.com> References: <56BC6E67.300@oracle.com> <56BC8C16.9080808@oracle.com> <56BDAFDE.4030707@oracle.com> Message-ID: <56C193C6.6000202@oracle.com> On 2016-02-12 11:11, Magnus Ihse Bursie wrote: > On 2016-02-11 14:26, Erik Joelsson wrote: >> flags.m4: spelling "contitionally" > Fixed. >> >> Otherwise it looks good enough to me provided that it builds and >> output is still the same. > > I ran it through JPRT with your new and improved compare script. I got > a compare failure on macosx for libosxui.dylib. I re-ran the test and > it passed (!). I ran a separate test with an empty patch file on > macosx, and it too failed on libosxui. Most libraries, but not > libosxui.dylib are listed in the ACCEPTED_BIN_DIFF section. So I took > the liberty of adding libosxui.dylib to that section as well, as part > of the patch. Hope you don't mind. :) > The intermittent differences are hard to catch and will require continuous maintenance of the script. The lib in question is newer than compare.sh IIRC. Thanks for fixing it! /Erik > /Magnus > >> >> /Erik >> >> On 2016-02-11 12:20, Magnus Ihse Bursie wrote: >>> Here is another batch of small fixes and enhancements from the >>> build-infra project forest. >>> >>> * Compiler version framework: >>> - Create a TOOLCHAIN_CHECK_COMPILER_VERSION macro >>> - Test for minimum versions for certain compilers in configure >>> * Start supporting mapfiles on all platforms (windows and macosx as >>> well) >>> * Fix errors/bad looking output in configure >>> * Fix bugs for debug symbols on macosx when building with >>> --with-native-debug-symbols=external >>> * Simplify hotspot version.rc: replace HS_VER with JDK_VER, and >>> HS_DOTVER with JDK_DOTVER (they are always the same) >>> * INCLUDE_SA fixes: >>> - Move the check of INCLUDE_SA to jdk-options.m4. >>> - Use INCLUDE_SA for proper testing for SA in makefiles. >>> * Set --with-native-debug-symbols default to "none" for STATIC_BUILD. >>> * Compare script improvements >>> * Incremental fixes in NativeCompilation.gmk. >>> * Incremental fixes in flags.m4 >>> * Remove left-over comments >>> * Misc other changes >>> * Whitespace fixes >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8149647 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8149647-incremental-build-infra-fixes-incl-compiler-version/webrev.01 >>> >>> /Magnus >>> >> > From erik.joelsson at oracle.com Mon Feb 15 09:02:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Feb 2016 10:02:23 +0100 Subject: [8u-dev] Request for review and approval for bug 8147807: crash in libkcms.so on linux-sparc In-Reply-To: <56BDA2AF.9000209@oracle.com> References: <56BC9860.7050006@oracle.com> <56BD9576.4090904@oracle.com> <56BDA2AF.9000209@oracle.com> Message-ID: <56C1941F.3040900@oracle.com> Looks good. /Erik On 2016-02-12 10:15, Se?n Coffey wrote: > Approved for jdk8u-dev once you have a peer code review. > > Regards, > Sean. > > On 12/02/2016 08:19, Alexey Ivanov wrote: >> I forgot to add jdk8u-dev list... >> >> On 11.02.2016 17:19, Alexey Ivanov wrote: >>> Hello, >>> >>> Could you please review the fix for JDK-8147807 and approve push to >>> 8u-dev? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8147807 >>> Webrev: http://cr.openjdk.java.net/~aivanov/8147807/jdk8/webrev.00/ >>> >>> The issue is not relevant to jdk 9. >>> >>> The fix just removes kcms service leaving lcms as the only option >>> which is the default in jdk8. >>> >>> >>> Thanks in advance, >>> Alexey >> > From sandhya.viswanathan at intel.com Mon Feb 15 18:20:49 2016 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 15 Feb 2016 18:20:49 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> <56BB4C24.7090607@oracle.com> <56BBD50F.8070803@oracle.com> <56BC63AC.9050702@oracle.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B75955BE0@FMSMSX112.amr.corp.intel.com> I would like to reiterate the need for system zlib support by the JVM instead of bundled zlib from the performance point of view. Compression is one of the hotspots in Big Data, Genomics and Middleware applications. There are many solutions in market today which help improve compression performance either through software or hardware acceleration. Intel has faster compression libraries as part of IPP as Sherman mentioned. Also there are hardware compression accelerators from Intel like QuickAssist. Both of these provide the acceleration through the zlib interface. Support for system zlib by the JVM would make these acceleration capabilities available to Java applications almost seamlessly through java.util.zip. Best Regards, Sandhya -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Martin Buchholz Sent: Thursday, February 11, 2016 10:49 AM To: Se?n Coffey Cc: build-dev; core-libs-dev Subject: Re: RFR: JDK-8031767 Support system or alternative implementations of zlib Currently the pendulum is swinging away from multiple applications sharing common libraries towards every application being self-contained, perhaps because disk space is dirt cheap and because of the rise of "containers". It may be that much of the packaging of jdks will be picked up by third parties who package up the JDK and any of its dependencies - e.g. I already see https://hub.docker.com/_/java/ On Thu, Feb 11, 2016 at 2:34 AM, Se?n Coffey wrote: > > On 11/02/2016 00:25, Xueming Shen wrote: >> >> >> One of the benefits of moving to the system libz is actually for >> better/easy >> maintenance. Just replacing the offending version of libz with an >> earlier/later >> version that works, instead of waiting for a customized jdk/jre image with >> a >> working/bundled libz, or the next update release. Especially given the >> fact >> that we have decided not to touch the libz at source level. Having >> dependency >> on the system libz is really not that bad. The experience suggests those >> binaries are quite stable. And it should always be easier to replace the >> system libz than a java runtime, in case of problem. > > > I think people overestimate people's ability to 'just replace' a zlib > library. Adding a new system property is a struggle for some enterprises. > We'll enjoy supporting a many to one matrix of zlib:JDK scenarios now rather > than old style 1:1. It's great to have system library support - I'm just > highlighting a possible risk. A fall back option solves that but there's no > appetite for such a solution. Let's see how it goes. > > regards, > Sean. > >> >> Sherman >> >> On 02/10/2016 06:41 AM, Se?n Coffey wrote: >>> >>> >>> On 10/02/16 14:29, Alan Bateman wrote: >>>> >>>> >>>> On 10/02/2016 13:57, Se?n Coffey wrote: >>>>> >>>>> I'm all for allowing one to introduce a new version of zlib to their >>>>> JDK at runtime. I just don't think it's in the interests of enterprises and >>>>> stability to introduce a dependency to the JDK on the underlying OS zlib >>>>> libraries. Could we at least consider a runtime property to allow linking to >>>>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>>> >>>> Don't the LD_* environment variables serve this need already? Once the >>>> JDK is using the system zlib then this is the simplest way to get it to use >>>> a different libz library at runtime. >>> >>> No - I don't see that as a solution. You've still made the default JDK >>> config become dependent on OS environment for all libzip operations. I don't >>> think we even capture the zlib version that the JDK would be operating with >>> in any diagnostics. An application wanting a tried/tested and stable libzip >>> version has extra work to do now. Letting the default be system dependent >>> has just increased risk for QA teams also. A system property just makes this >>> all go away. In fact - I would say that for JDK9, the default should be the >>> JDK bundled libzip library. For those looking for libzip experimenting and >>> performance benefits, they could take the system property approach. >>> >>> regards, >>> Sean. >>>> >>>> >>>> -Alan >>> >>> >>> >>> On 08/02/16 09:55, Alan Bateman wrote: >>>> >>>> >>>> On 08/02/2016 10:42, Se?n Coffey wrote: >>>>> >>>>> Is there an option to fall back to the older v.1.2.8 implementation if >>>>> necessary ? It would certainly alleviate issues for any applications that >>>>> might run into issues with the latest and greatest zlib libraries. >>>>> JDK-8133206 would be one such example. >>>> >>>> Just at build time >>> >>> so - we introduce a runtime dependency on the underlying zlib libraries >>> on the OS by default. I would be very concerned with this approach. We've >>> run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for >>> the most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an >>> inflation issue[1]. When JDK was upgraded to zlib v1.2.8, we received >>> reports of performance/OOM issues [2]. >>>> >>>> but if the zlib on the platform is broken then it impacts tools and >>>> probably lots of things. I would assume the OS would patch such issues >>>> quickly. In the case of JDK-8133206 then was the issue addressed in the >>>> libzip wrapper or in the zlib code? I thought it was the former. >>> >>> The code change is proposed in the libzip wrapper but the issue was >>> triggered by the zlib library update. >>>> >>>> >>>> On a fallback or some way to configure at launch time then Sandhya >>>> Viswanathan (Intel) has a proposal here last year. I think we mostly agreed >>>> on that thread that switching the build to use the system zlib by default >>>> would be better. >>> >>> I'm all for allowing one to introduce a new version of zlib to their JDK >>> at runtime. I just don't think it's in the interests of enterprises and >>> stability to introduce a dependency to the JDK on the underlying OS zlib >>> libraries. Could we at least consider a runtime property to allow linking to >>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>> >>> regards, >>> Sean. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8044725 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8133206 >>> >> > From sandhya.viswanathan at intel.com Mon Feb 15 18:09:11 2016 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Mon, 15 Feb 2016 18:09:11 +0000 Subject: RFR: JDK-8031767 Support system or alternative implementations of zlib In-Reply-To: References: <56B4F031.6040501@oracle.com> <56B862FE.5000000@oracle.com> <56B86623.4090602@oracle.com> <56BB41E6.3060102@oracle.com> <56BB4932.7060105@oracle.com> <56BB4C24.7090607@oracle.com> <56BBD50F.8070803@oracle.com> <56BC63AC.9050702@oracle.com> Message-ID: <02FCFB8477C4EF43A2AD8E0C60F3DA2B75955B9F@FMSMSX112.amr.corp.intel.com> I would like to reiterate the need for system zlib support by the JVM instead of bundled zlib from the performance point of view. Compression is one of the hotspots in Big Data, Genomics and Middleware applications. There are many solutions in market today which help improve compression performance either through software or hardware acceleration. Intel has faster compression libraries as part of IPP as Sherman mentioned. Also there are hardware compression accelerators from Intel like QuickAssist. Both of these provide the acceleration through the zlib interface. Support for system zlib by the JVM would make these acceleration capabilities available to Java applications almost seamlessly through java.util.zip. Best Regards, Sandhya -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Martin Buchholz Sent: Thursday, February 11, 2016 10:49 AM To: Se?n Coffey Cc: build-dev; core-libs-dev Subject: Re: RFR: JDK-8031767 Support system or alternative implementations of zlib Currently the pendulum is swinging away from multiple applications sharing common libraries towards every application being self-contained, perhaps because disk space is dirt cheap and because of the rise of "containers". It may be that much of the packaging of jdks will be picked up by third parties who package up the JDK and any of its dependencies - e.g. I already see https://hub.docker.com/_/java/ On Thu, Feb 11, 2016 at 2:34 AM, Se?n Coffey wrote: > > On 11/02/2016 00:25, Xueming Shen wrote: >> >> >> One of the benefits of moving to the system libz is actually for >> better/easy >> maintenance. Just replacing the offending version of libz with an >> earlier/later >> version that works, instead of waiting for a customized jdk/jre image with >> a >> working/bundled libz, or the next update release. Especially given the >> fact >> that we have decided not to touch the libz at source level. Having >> dependency >> on the system libz is really not that bad. The experience suggests those >> binaries are quite stable. And it should always be easier to replace the >> system libz than a java runtime, in case of problem. > > > I think people overestimate people's ability to 'just replace' a zlib > library. Adding a new system property is a struggle for some enterprises. > We'll enjoy supporting a many to one matrix of zlib:JDK scenarios now rather > than old style 1:1. It's great to have system library support - I'm just > highlighting a possible risk. A fall back option solves that but there's no > appetite for such a solution. Let's see how it goes. > > regards, > Sean. > >> >> Sherman >> >> On 02/10/2016 06:41 AM, Se?n Coffey wrote: >>> >>> >>> On 10/02/16 14:29, Alan Bateman wrote: >>>> >>>> >>>> On 10/02/2016 13:57, Se?n Coffey wrote: >>>>> >>>>> I'm all for allowing one to introduce a new version of zlib to their >>>>> JDK at runtime. I just don't think it's in the interests of enterprises and >>>>> stability to introduce a dependency to the JDK on the underlying OS zlib >>>>> libraries. Could we at least consider a runtime property to allow linking to >>>>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>>> >>>> Don't the LD_* environment variables serve this need already? Once the >>>> JDK is using the system zlib then this is the simplest way to get it to use >>>> a different libz library at runtime. >>> >>> No - I don't see that as a solution. You've still made the default JDK >>> config become dependent on OS environment for all libzip operations. I don't >>> think we even capture the zlib version that the JDK would be operating with >>> in any diagnostics. An application wanting a tried/tested and stable libzip >>> version has extra work to do now. Letting the default be system dependent >>> has just increased risk for QA teams also. A system property just makes this >>> all go away. In fact - I would say that for JDK9, the default should be the >>> JDK bundled libzip library. For those looking for libzip experimenting and >>> performance benefits, they could take the system property approach. >>> >>> regards, >>> Sean. >>>> >>>> >>>> -Alan >>> >>> >>> >>> On 08/02/16 09:55, Alan Bateman wrote: >>>> >>>> >>>> On 08/02/2016 10:42, Se?n Coffey wrote: >>>>> >>>>> Is there an option to fall back to the older v.1.2.8 implementation if >>>>> necessary ? It would certainly alleviate issues for any applications that >>>>> might run into issues with the latest and greatest zlib libraries. >>>>> JDK-8133206 would be one such example. >>>> >>>> Just at build time >>> >>> so - we introduce a runtime dependency on the underlying zlib libraries >>> on the OS by default. I would be very concerned with this approach. We've >>> run JDK 6 for 10+ years with zlib v1.1.3. It was consistent and reliable for >>> the most part. When we moved JDK7/8 to zlib v1.2.5, we encountered an >>> inflation issue[1]. When JDK was upgraded to zlib v1.2.8, we received >>> reports of performance/OOM issues [2]. >>>> >>>> but if the zlib on the platform is broken then it impacts tools and >>>> probably lots of things. I would assume the OS would patch such issues >>>> quickly. In the case of JDK-8133206 then was the issue addressed in the >>>> libzip wrapper or in the zlib code? I thought it was the former. >>> >>> The code change is proposed in the libzip wrapper but the issue was >>> triggered by the zlib library update. >>>> >>>> >>>> On a fallback or some way to configure at launch time then Sandhya >>>> Viswanathan (Intel) has a proposal here last year. I think we mostly agreed >>>> on that thread that switching the build to use the system zlib by default >>>> would be better. >>> >>> I'm all for allowing one to introduce a new version of zlib to their JDK >>> at runtime. I just don't think it's in the interests of enterprises and >>> stability to introduce a dependency to the JDK on the underlying OS zlib >>> libraries. Could we at least consider a runtime property to allow linking to >>> the (currently bundled) zlib v.1.2.8 port in case issues arise ? >>> >>> regards, >>> Sean. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8044725 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8133206 >>> >> > From aph at redhat.com Tue Feb 16 14:40:54 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 16 Feb 2016 14:40:54 +0000 Subject: Building with GCC 6 Message-ID: <56C334F6.4050005@redhat.com> GCC Version 6 doesn't build a working HotSpot without two flags: -fno-delete-null-pointer-checks -fno-lifetime-dse These are because HotSpot uses undefined behaviour in some places. "-fno-delete-null-pointer-checks" is needed because HotSpot dereferences null pointers in soe places. "-fno-lifetime-dse" refers to the practice of initializing objects before the start of a constructor, which is explicitly forbidden by Standard C++, but is used by HotSpot. GCC 6 is quite new, so we have a little time before the various users of OpenJDK start to hit these problems, but I'd like to help get some build fixes in as soon as we can. Also, it's not just about JDK9: 8u fails to build too. Thanks, Andrew. From chris.hegarty at oracle.com Wed Feb 17 10:03:13 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 17 Feb 2016 10:03:13 +0000 Subject: Fwd: RFR[9] 8068686: Remove meta-index support References: <08F34760-D34C-441C-80AB-DCB0E744466C@oracle.com> Message-ID: Forwarding, there are some small build changes. Begin forwarded message: > From: Chris Hegarty > Date: 16 February 2016 at 19:19:35 GMT > To: core-libs-dev > Subject: RFR[9] 8068686: Remove meta-index support > > The Modular Run-Time image, integrated in b41, no longer has JAR files, > see JEP 220 [1], The meta-index is no longer generated or used. This > issue proposes to remove the meta-index support from the runtime and > the build. > > http://cr.openjdk.java.net/~chegar/8068686/ > https://bugs.openjdk.java.net/browse/JDK-8068686 > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8061971 From erik.joelsson at oracle.com Wed Feb 17 10:08:47 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Feb 2016 11:08:47 +0100 Subject: Fwd: RFR[9] 8068686: Remove meta-index support In-Reply-To: References: <08F34760-D34C-441C-80AB-DCB0E744466C@oracle.com> Message-ID: <56C446AF.9020506@oracle.com> Looks good to me. /Erik On 2016-02-17 11:03, Chris Hegarty wrote: > Forwarding, there are some small build changes. > > Begin forwarded message: > >> From: Chris Hegarty >> Date: 16 February 2016 at 19:19:35 GMT >> To: core-libs-dev >> Subject: RFR[9] 8068686: Remove meta-index support >> >> The Modular Run-Time image, integrated in b41, no longer has JAR files, >> see JEP 220 [1], The meta-index is no longer generated or used. This >> issue proposes to remove the meta-index support from the runtime and >> the build. >> >> http://cr.openjdk.java.net/~chegar/8068686/ >> https://bugs.openjdk.java.net/browse/JDK-8068686 >> >> -Chris. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8061971 From erik.joelsson at oracle.com Wed Feb 17 10:16:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Feb 2016 11:16:46 +0100 Subject: RFR: JDK-8149963: build errors during API docs build Message-ID: <56C4488E.1050507@oracle.com> Hello, There is a dependency issue in the Javadoc makefile when building custom additions. Since the include of the custom Javadoc.gmk happens before the core api build rule declaration, the targets in the custom file cannot properly depend on the core api. The fix is to move the variable definition of the core api javadoc target to before the include. Bug: https://bugs.openjdk.java.net/browse/JDK-8149963 Webrev: http://cr.openjdk.java.net/~erikj/8149963/webrev.01/ /Erik From tim.bell at oracle.com Wed Feb 17 15:28:23 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 17 Feb 2016 07:28:23 -0800 Subject: RFR: JDK-8149963: build errors during API docs build In-Reply-To: <56C4488E.1050507@oracle.com> References: <56C4488E.1050507@oracle.com> Message-ID: <56C49197.7000600@oracle.com> Erik: > There is a dependency issue in the Javadoc makefile when building > custom additions. Since the include of the custom Javadoc.gmk happens > before the core api build rule declaration, the targets in the custom > file cannot properly depend on the core api. The fix is to move the > variable definition of the core api javadoc target to before the include. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149963 > Webrev: http://cr.openjdk.java.net/~erikj/8149963/webrev.01/ Looks good to me. Tim From magnus.ihse.bursie at oracle.com Wed Feb 17 15:47:36 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 Feb 2016 16:47:36 +0100 Subject: RFR: JDK-8149963: build errors during API docs build In-Reply-To: <56C4488E.1050507@oracle.com> References: <56C4488E.1050507@oracle.com> Message-ID: <56C49618.5010004@oracle.com> On 2016-02-17 11:16, Erik Joelsson wrote: > Hello, > > There is a dependency issue in the Javadoc makefile when building > custom additions. Since the include of the custom Javadoc.gmk happens > before the core api build rule declaration, the targets in the custom > file cannot properly depend on the core api. The fix is to move the > variable definition of the core api javadoc target to before the include. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8149963 > Webrev: http://cr.openjdk.java.net/~erikj/8149963/webrev.01/ Looks good to me. /Magnus From volker.simonis at gmail.com Thu Feb 18 08:32:06 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Feb 2016 09:32:06 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') Message-ID: Hi, after integration of "8148629: Disable remaining warnings in awt/fontmanager" I get the following error messages: Bad value 'wbadlkginit' for flag '-erroff' for '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. Bad value 'w_novirtualdescr' for flag '-erroff' for '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. Bad value 'arrowrtn2' for flag '-erroff' for '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, according to [1] should be the supported solaris compiler for jdk9. Unfortunately I couldn't find any list of supported tags for the '-erroff' command [2]. Any idea why I'm seeing this and how I can et rid of the problem? Thank you and best regards, Volker [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe From erik.joelsson at oracle.com Thu Feb 18 08:58:00 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Feb 2016 09:58:00 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: References: Message-ID: <56C58798.9010201@oracle.com> Oh right, that wiki is not updated. We switched to SS12u4 a couple of months ago and I updated README-builds. I think you can get around it with --disable-warnings-as-errors. /Erik On 2016-02-18 09:32, Volker Simonis wrote: > Hi, > > after integration of "8148629: Disable remaining warnings in > awt/fontmanager" I get the following error messages: > > Bad value 'wbadlkginit' for flag '-erroff' for > '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. > Bad value 'w_novirtualdescr' for flag '-erroff' for > '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. > Bad value 'arrowrtn2' for flag '-erroff' for > '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. > > I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, > according to [1] should be the supported solaris compiler for jdk9. > Unfortunately I couldn't find any list of supported tags for the > '-erroff' command [2]. > > Any idea why I'm seeing this and how I can et rid of the problem? > > Thank you and best regards, > Volker > > [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe From volker.simonis at gmail.com Thu Feb 18 09:13:44 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Feb 2016 10:13:44 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: <56C58798.9010201@oracle.com> References: <56C58798.9010201@oracle.com> Message-ID: Hi Erik, thanks for the info. Can you please also update the Wiki? Regards, Volker On Thu, Feb 18, 2016 at 9:58 AM, Erik Joelsson wrote: > Oh right, that wiki is not updated. We switched to SS12u4 a couple of months > ago and I updated README-builds. I think you can get around it with > --disable-warnings-as-errors. > > /Erik > > > On 2016-02-18 09:32, Volker Simonis wrote: >> >> Hi, >> >> after integration of "8148629: Disable remaining warnings in >> awt/fontmanager" I get the following error messages: >> >> Bad value 'wbadlkginit' for flag '-erroff' for >> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >> Bad value 'w_novirtualdescr' for flag '-erroff' for >> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >> Bad value 'arrowrtn2' for flag '-erroff' for >> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >> >> I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, >> according to [1] should be the supported solaris compiler for jdk9. >> Unfortunately I couldn't find any list of supported tags for the >> '-erroff' command [2]. >> >> Any idea why I'm seeing this and how I can et rid of the problem? >> >> Thank you and best regards, >> Volker >> >> [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >> [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe > > From erik.joelsson at oracle.com Thu Feb 18 09:42:58 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Feb 2016 10:42:58 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: References: <56C58798.9010201@oracle.com> Message-ID: <56C59222.4090908@oracle.com> I updated the part with the compilers used by Oracle. On 2016-02-18 10:13, Volker Simonis wrote: > Hi Erik, > > thanks for the info. Can you please also update the Wiki? > > Regards, > Volker > > > On Thu, Feb 18, 2016 at 9:58 AM, Erik Joelsson wrote: >> Oh right, that wiki is not updated. We switched to SS12u4 a couple of months >> ago and I updated README-builds. I think you can get around it with >> --disable-warnings-as-errors. >> >> /Erik >> >> >> On 2016-02-18 09:32, Volker Simonis wrote: >>> Hi, >>> >>> after integration of "8148629: Disable remaining warnings in >>> awt/fontmanager" I get the following error messages: >>> >>> Bad value 'wbadlkginit' for flag '-erroff' for >>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>> Bad value 'w_novirtualdescr' for flag '-erroff' for >>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>> Bad value 'arrowrtn2' for flag '-erroff' for >>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>> >>> I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, >>> according to [1] should be the supported solaris compiler for jdk9. >>> Unfortunately I couldn't find any list of supported tags for the >>> '-erroff' command [2]. >>> >>> Any idea why I'm seeing this and how I can et rid of the problem? >>> >>> Thank you and best regards, >>> Volker >>> >>> [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >>> [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe >> From volker.simonis at gmail.com Thu Feb 18 10:17:28 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 18 Feb 2016 11:17:28 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: <56C59222.4090908@oracle.com> References: <56C58798.9010201@oracle.com> <56C59222.4090908@oracle.com> Message-ID: Thanks. Unfortunately, --disable-warnings-as-errors doesn't help in this case. If we want to still make it possible to build with 12u3 we have to filter out the corresponding -erroff options depending on the compiler version. At least I found a machine with SS12u4 and could verify that it builds fine. Regards, Volker On Thu, Feb 18, 2016 at 10:42 AM, Erik Joelsson wrote: > I updated the part with the compilers used by Oracle. > > > On 2016-02-18 10:13, Volker Simonis wrote: >> >> Hi Erik, >> >> thanks for the info. Can you please also update the Wiki? >> >> Regards, >> Volker >> >> >> On Thu, Feb 18, 2016 at 9:58 AM, Erik Joelsson >> wrote: >>> >>> Oh right, that wiki is not updated. We switched to SS12u4 a couple of >>> months >>> ago and I updated README-builds. I think you can get around it with >>> --disable-warnings-as-errors. >>> >>> /Erik >>> >>> >>> On 2016-02-18 09:32, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> after integration of "8148629: Disable remaining warnings in >>>> awt/fontmanager" I get the following error messages: >>>> >>>> Bad value 'wbadlkginit' for flag '-erroff' for >>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>> Bad value 'w_novirtualdescr' for flag '-erroff' for >>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>> Bad value 'arrowrtn2' for flag '-erroff' for >>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>> >>>> I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, >>>> according to [1] should be the supported solaris compiler for jdk9. >>>> Unfortunately I couldn't find any list of supported tags for the >>>> '-erroff' command [2]. >>>> >>>> Any idea why I'm seeing this and how I can et rid of the problem? >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> [1] >>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >>>> [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe >>> >>> > From dalibor.topic at oracle.com Thu Feb 18 12:20:41 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 18 Feb 2016 13:20:41 +0100 Subject: Building with GCC 6 In-Reply-To: <56C334F6.4050005@redhat.com> References: <56C334F6.4050005@redhat.com> Message-ID: <56C5B719.5020309@oracle.com> On 16.02.2016 15:40, Andrew Haley wrote: > GCC 6 is quite new, so we have a little time before the various users > of OpenJDK start to hit these problems, What does the general adoption timeline for GCC 6 look for Linux distributions? cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Thu Feb 18 12:46:23 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Feb 2016 12:46:23 +0000 Subject: Building with GCC 6 In-Reply-To: <56C5B719.5020309@oracle.com> References: <56C334F6.4050005@redhat.com> <56C5B719.5020309@oracle.com> Message-ID: <56C5BD1F.7070006@redhat.com> On 02/18/2016 12:20 PM, dalibor topic wrote: > On 16.02.2016 15:40, Andrew Haley wrote: >> GCC 6 is quite new, so we have a little time before the various users >> of OpenJDK start to hit these problems, > > What does the general adoption timeline for GCC 6 look for Linux > distributions? It's not possible to say in general, but for Fedora maybe a few months, Debian LTS several years; everything else is in between. Andrew. From dalibor.topic at oracle.com Thu Feb 18 13:41:29 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 18 Feb 2016 14:41:29 +0100 Subject: Building with GCC 6 In-Reply-To: <56C5BD1F.7070006@redhat.com> References: <56C334F6.4050005@redhat.com> <56C5B719.5020309@oracle.com> <56C5BD1F.7070006@redhat.com> Message-ID: <56C5CA09.1040601@oracle.com> Thanks, Andrew - it sounds like it could affect 8u as well within the year, then. cheers, dalibor topic On 18.02.2016 13:46, Andrew Haley wrote: > On 02/18/2016 12:20 PM, dalibor topic wrote: >> On 16.02.2016 15:40, Andrew Haley wrote: >>> GCC 6 is quite new, so we have a little time before the various users >>> of OpenJDK start to hit these problems, >> >> What does the general adoption timeline for GCC 6 look for Linux >> distributions? > > It's not possible to say in general, but for Fedora maybe a few > months, Debian LTS several years; everything else is in between. > > Andrew. > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Thu Feb 18 13:46:09 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 18 Feb 2016 13:46:09 +0000 Subject: Building with GCC 6 In-Reply-To: <56C5CA09.1040601@oracle.com> References: <56C334F6.4050005@redhat.com> <56C5B719.5020309@oracle.com> <56C5BD1F.7070006@redhat.com> <56C5CA09.1040601@oracle.com> Message-ID: <56C5CB21.7000702@redhat.com> On 02/18/2016 01:41 PM, dalibor topic wrote: > Thanks, Andrew - it sounds like it could affect 8u as well within the > year, then. Certainly. We've patched OpenJDK for Fedora -- so we're running -- but we really need to get some build fixes into OpenJDK. We might as well do it now. Andrew. From magnus.ihse.bursie at oracle.com Thu Feb 18 20:45:34 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 18 Feb 2016 21:45:34 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: References: <56C58798.9010201@oracle.com> <56C59222.4090908@oracle.com> Message-ID: <56C62D6E.2090605@oracle.com> On 2016-02-18 11:17, Volker Simonis wrote: > Thanks. > > Unfortunately, --disable-warnings-as-errors doesn't help in this case. > If we want to still make it possible to build with 12u3 we have to > filter out the corresponding -erroff options depending on the compiler > version. Due to reasons like this, we would like to support a minimal span of versions for the solstudio compiler. So if you are alright with upgrading to 12u4, we'd prefer to drop support for 12u3 completely. Filtering out error options like this is quite a pain, otherwise. I believe there are few community users that care much about Solaris and solstudio. Had you not told me you were building on Solaris, I would have guessed only Oracle did so. This gives us, I believe, a better chance at enforcing stricter restrictions on the set of supported versions, compared to the situation for e.g. gcc and linux. /Magnus > > At least I found a machine with SS12u4 and could verify that it builds fine. > > Regards, > Volker > > On Thu, Feb 18, 2016 at 10:42 AM, Erik Joelsson > wrote: >> I updated the part with the compilers used by Oracle. >> >> >> On 2016-02-18 10:13, Volker Simonis wrote: >>> Hi Erik, >>> >>> thanks for the info. Can you please also update the Wiki? >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, Feb 18, 2016 at 9:58 AM, Erik Joelsson >>> wrote: >>>> Oh right, that wiki is not updated. We switched to SS12u4 a couple of >>>> months >>>> ago and I updated README-builds. I think you can get around it with >>>> --disable-warnings-as-errors. >>>> >>>> /Erik >>>> >>>> >>>> On 2016-02-18 09:32, Volker Simonis wrote: >>>>> Hi, >>>>> >>>>> after integration of "8148629: Disable remaining warnings in >>>>> awt/fontmanager" I get the following error messages: >>>>> >>>>> Bad value 'wbadlkginit' for flag '-erroff' for >>>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>>> Bad value 'w_novirtualdescr' for flag '-erroff' for >>>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>>> Bad value 'arrowrtn2' for flag '-erroff' for >>>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>>> >>>>> I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, >>>>> according to [1] should be the supported solaris compiler for jdk9. >>>>> Unfortunately I couldn't find any list of supported tags for the >>>>> '-erroff' command [2]. >>>>> >>>>> Any idea why I'm seeing this and how I can et rid of the problem? >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>>> [1] >>>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >>>>> [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe >>>> From magnus.ihse.bursie at oracle.com Thu Feb 18 23:16:52 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Feb 2016 00:16:52 +0100 Subject: RFR (S): JDK-8150201 Restore missing -g flags to files with OPT_CFLAGS/per-file Message-ID: <56C650E4.6020905@oracle.com> There seems to be a bit of confusion as to OPT_CFLAGS meant "CFLAGS for optimization" or "CFLAGS for optimized/product build". Some usages seems to suggest the first interpretation, while other usages seems to have made the second (where OPT_CFLAGS align with DEBUG_CFLAGS/FASTDEBUG_CFLAGS). The first interpretation seems to have been used for the code that make it possible to override OPT_CFLAGS on a per-file basis by setting e.g. OPT_CFLAGS/foo.o is set. In this case, the general value of OPT_CFLAGS is discarded, including any -O flags. However, the second interpretation seems to have been used for FDS, where -g (or -g0 -xs on solaris) are added to OPT_CFLAGS. The end result is that whenever the OPT_CFLAGS/foo.o mechanism is used, the FDS -g flag is lost. :-( This patch is a minimal fix to restore the -g flag to these files. A more general approach to fix this was originally suggested as part of JDK-8142909, but was deemed inadequate. After some discussion, the entire problem with the missing -g flags was dropped from that bug. However, one of the key points in the discussion was that an explicit add of -g would be a better solution, which is what I have adopted here (short of a major rewrite of the flag handling in the old build system, which is not going to happen). I have also made a more thorough check this time to really catch all such issues (at least for default Oracle builds). The main reason for bringing this change in now is to make it possible to compare the build results between the upcoming new hotspot build, and the old. Since the new build always adds -g to all files (if we need debug symbols, that is), there will be huge discrepances between the two build system in the affected files. Bug: https://bugs.openjdk.java.net/browse/JDK-8150201 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8150201-restore-missing-g-flag/webrev.01 /Magnus From david.holmes at oracle.com Thu Feb 18 23:40:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Feb 2016 09:40:27 +1000 Subject: RFR (S): JDK-8150201 Restore missing -g flags to files with OPT_CFLAGS/per-file In-Reply-To: <56C650E4.6020905@oracle.com> References: <56C650E4.6020905@oracle.com> Message-ID: <56C6566B.9020309@oracle.com> Hi Magnus, On 19/02/2016 9:16 AM, Magnus Ihse Bursie wrote: > There seems to be a bit of confusion as to OPT_CFLAGS meant "CFLAGS for > optimization" or "CFLAGS for optimized/product build". Some usages seems > to suggest the first interpretation, while other usages seems to have > made the second (where OPT_CFLAGS align with > DEBUG_CFLAGS/FASTDEBUG_CFLAGS). > The first interpretation seems to have been used for the code that make > it possible to override OPT_CFLAGS on a per-file basis by setting e.g. > OPT_CFLAGS/foo.o is set. In this case, the general value of OPT_CFLAGS > is discarded, including any -O flags. > > However, the second interpretation seems to have been used for FDS, > where -g (or -g0 -xs on solaris) are added to OPT_CFLAGS. > > The end result is that whenever the OPT_CFLAGS/foo.o mechanism is used, > the FDS -g flag is lost. :-( As I understand it if you use per-file flags then you are taking full responsibility for that set of flags and so have to ensure that any desired "common" flags are also included. But I can understand if other people have not seen it that way, or realized that was the way it worked. > This patch is a minimal fix to restore the -g flag to these files. Changes seem fine as you have done them. > A more general approach to fix this was originally suggested as part of > JDK-8142909, but was deemed inadequate. After some discussion, the > entire problem with the missing -g flags was dropped from that bug. > However, one of the key points in the discussion was that an explicit > add of -g would be a better solution, which is what I have adopted here > (short of a major rewrite of the flag handling in the old build system, > which is not going to happen). I have also made a more thorough check > this time to really catch all such issues (at least for default Oracle > builds). Defining a FULL_DEBUG_SYMBOLS_CFLAGS that was always added to CFLAGS and not caught up with the XXX_CFLAGS would be simpler, and doesn't quite amount to a full rewrite of the flags support. But I understand not wanting to waste cycles on this. Thanks, David > > The main reason for bringing this change in now is to make it possible > to compare the build results between the upcoming new hotspot build, and > the old. Since the new build always adds -g to all files (if we need > debug symbols, that is), there will be huge discrepances between the two > build system in the affected files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150201 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8150201-restore-missing-g-flag/webrev.01 > > > /Magnus From volker.simonis at gmail.com Fri Feb 19 08:40:17 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Feb 2016 09:40:17 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: <56C62D6E.2090605@oracle.com> References: <56C58798.9010201@oracle.com> <56C59222.4090908@oracle.com> <56C62D6E.2090605@oracle.com> Message-ID: On Thu, Feb 18, 2016 at 9:45 PM, Magnus Ihse Bursie wrote: > On 2016-02-18 11:17, Volker Simonis wrote: >> >> Thanks. >> >> Unfortunately, --disable-warnings-as-errors doesn't help in this case. >> If we want to still make it possible to build with 12u3 we have to >> filter out the corresponding -erroff options depending on the compiler >> version. > > Due to reasons like this, we would like to support a minimal span of > versions for the solstudio compiler. So if you are alright with upgrading to > 12u4, we'd prefer to drop support for 12u3 completely. Filtering out error > options like this is quite a pain, otherwise. > > I believe there are few community users that care much about Solaris and > solstudio. Had you not told me you were building on Solaris, I would have > guessed only Oracle did so. This gives us, I believe, a better chance at > enforcing stricter restrictions on the set of supported versions, compared > to the situation for e.g. gcc and linux. > For our product builds we will most probably have to stay with older version for a couple of reasons (building on older OS release, dependency on other products/libraries, licensing/support issues, etc). But as long as the problem is just a few unknown compiler options I'm fine if you say you don't want to support them any more (we can easily remove them in our proprietary build). This assessment would of course change if it would be necessary to make bigger source code changes (i.e. template code) in order to support older compilers. But fortunately we're not there until now :) By the way, do you know if the upcoming "HotSpot C++ Unit-Test Framework" (JEP 281) will impose further restrictions on the supported C++ compilers? Regards, Volker > /Magnus > > >> >> At least I found a machine with SS12u4 and could verify that it builds >> fine. >> >> Regards, >> Volker >> >> On Thu, Feb 18, 2016 at 10:42 AM, Erik Joelsson >> wrote: >>> >>> I updated the part with the compilers used by Oracle. >>> >>> >>> On 2016-02-18 10:13, Volker Simonis wrote: >>>> >>>> Hi Erik, >>>> >>>> thanks for the info. Can you please also update the Wiki? >>>> >>>> Regards, >>>> Volker >>>> >>>> >>>> On Thu, Feb 18, 2016 at 9:58 AM, Erik Joelsson >>>> >>>> wrote: >>>>> >>>>> Oh right, that wiki is not updated. We switched to SS12u4 a couple of >>>>> months >>>>> ago and I updated README-builds. I think you can get around it with >>>>> --disable-warnings-as-errors. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2016-02-18 09:32, Volker Simonis wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> after integration of "8148629: Disable remaining warnings in >>>>>> awt/fontmanager" I get the following error messages: >>>>>> >>>>>> Bad value 'wbadlkginit' for flag '-erroff' for >>>>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>>>> Bad value 'w_novirtualdescr' for flag '-erroff' for >>>>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>>>> Bad value 'arrowrtn2' for flag '-erroff' for >>>>>> '/sapmnt/global/tools/compiler/SS12u3/SUNWspro/prod/bin/ccfe'. >>>>>> >>>>>> I'm using SS 12u3 (i.e. CC: Sun C++ 5.12 SunOS_i386 2011/11/16) which, >>>>>> according to [1] should be the supported solaris compiler for jdk9. >>>>>> Unfortunately I couldn't find any list of supported tags for the >>>>>> '-erroff' command [2]. >>>>>> >>>>>> Any idea why I'm seeing this and how I can et rid of the problem? >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> [1] >>>>>> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms >>>>>> [2] https://docs.oracle.com/cd/E24457_01/html/E21990/bjapr.html#bjaqe >>>>> >>>>> > From erik.joelsson at oracle.com Fri Feb 19 09:03:37 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 19 Feb 2016 10:03:37 +0100 Subject: RFR (S): JDK-8150201 Restore missing -g flags to files with OPT_CFLAGS/per-file In-Reply-To: <56C650E4.6020905@oracle.com> References: <56C650E4.6020905@oracle.com> Message-ID: <56C6DA69.1030405@oracle.com> Looks ok to me. Thanks for fixing this. /Erik On 2016-02-19 00:16, Magnus Ihse Bursie wrote: > There seems to be a bit of confusion as to OPT_CFLAGS meant "CFLAGS > for optimization" or "CFLAGS for optimized/product build". Some usages > seems to suggest the first interpretation, while other usages seems to > have made the second (where OPT_CFLAGS align with > DEBUG_CFLAGS/FASTDEBUG_CFLAGS). > > The first interpretation seems to have been used for the code that > make it possible to override OPT_CFLAGS on a per-file basis by setting > e.g. OPT_CFLAGS/foo.o is set. In this case, the general value of > OPT_CFLAGS is discarded, including any -O flags. > > However, the second interpretation seems to have been used for FDS, > where -g (or -g0 -xs on solaris) are added to OPT_CFLAGS. > > The end result is that whenever the OPT_CFLAGS/foo.o mechanism is > used, the FDS -g flag is lost. :-( > > This patch is a minimal fix to restore the -g flag to these files. > > A more general approach to fix this was originally suggested as part > of JDK-8142909, but was deemed inadequate. After some discussion, the > entire problem with the missing -g flags was dropped from that bug. > However, one of the key points in the discussion was that an explicit > add of -g would be a better solution, which is what I have adopted > here (short of a major rewrite of the flag handling in the old build > system, which is not going to happen). I have also made a more > thorough check this time to really catch all such issues (at least for > default Oracle builds). > > The main reason for bringing this change in now is to make it possible > to compare the build results between the upcoming new hotspot build, > and the old. Since the new build always adds -g to all files (if we > need debug symbols, that is), there will be huge discrepances between > the two build system in the affected files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150201 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8150201-restore-missing-g-flag/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 19 15:51:18 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Feb 2016 16:51:18 +0100 Subject: RFR: JDK-8150203 Incremental update from build-infra project Message-ID: <56C739F6.7010509@oracle.com> More incremental fixes from the build-infra project. The list of fixes include: * More ExecuteWithLog. * Native buildtools fixes. * Make DTDParser quiet. * LIBM cleanups. * Export LDFLAGS_HASH_STYLE. * Remove superfluous -export on LDFLAGS_windows. (JNIEXPORT used) * Don't let make reconfigure delete spec.gmk on abort I have run this using JPRT and the COMPARE_BUILD functionality, which shows no differences. I'm still awaiting results from the last platforms, but so far it's looking good. (I'll report back if something breaks.) Bug: https://bugs.openjdk.java.net/browse/JDK-8150203 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8150203-incremental-build-infra-fixes/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 19 16:09:35 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Feb 2016 17:09:35 +0100 Subject: RFR: JDK-8150257 Remove softfloat lib support Message-ID: <56C73E3F.8030309@oracle.com> We have some quite ugly hacks in place to support injecting the softfloat lib on certain platforms. This is not needed anymore and should be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8150257 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8150257-remove-softfloat-lib-support/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Feb 19 16:46:01 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Feb 2016 17:46:01 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: References: <56C58798.9010201@oracle.com> <56C59222.4090908@oracle.com> <56C62D6E.2090605@oracle.com> Message-ID: <56C746C9.8040508@oracle.com> On 2016-02-19 09:40, Volker Simonis wrote: > On Thu, Feb 18, 2016 at 9:45 PM, Magnus Ihse Bursie > wrote: >> On 2016-02-18 11:17, Volker Simonis wrote: >>> Thanks. >>> >>> Unfortunately, --disable-warnings-as-errors doesn't help in this case. >>> If we want to still make it possible to build with 12u3 we have to >>> filter out the corresponding -erroff options depending on the compiler >>> version. >> Due to reasons like this, we would like to support a minimal span of >> versions for the solstudio compiler. So if you are alright with upgrading to >> 12u4, we'd prefer to drop support for 12u3 completely. Filtering out error >> options like this is quite a pain, otherwise. >> >> I believe there are few community users that care much about Solaris and >> solstudio. Had you not told me you were building on Solaris, I would have >> guessed only Oracle did so. This gives us, I believe, a better chance at >> enforcing stricter restrictions on the set of supported versions, compared >> to the situation for e.g. gcc and linux. >> > For our product builds we will most probably have to stay with older > version for a couple of reasons (building on older OS release, > dependency on other products/libraries, licensing/support issues, > etc). But as long as the problem is just a few unknown compiler > options I'm fine if you say you don't want to support them any more > (we can easily remove them in our proprietary build). > > This assessment would of course change if it would be necessary to > make bigger source code changes (i.e. template code) in order to > support older compilers. But fortunately we're not there until now :) > > By the way, do you know if the upcoming "HotSpot C++ Unit-Test > Framework" (JEP 281) will impose further restrictions on the supported > C++ compilers? Not that I know of, no. But perhaps no-one have ever tried compiling GTest on xlc, so you might have some porting work to do if you want to be able to use the unit test framework. /Magnus > > Regards, > Volker > From volker.simonis at gmail.com Fri Feb 19 16:50:34 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Feb 2016 17:50:34 +0100 Subject: Compile error on Solaris (Bad value 'wbadlkginit' for flag '-erroff') In-Reply-To: <56C746C9.8040508@oracle.com> References: <56C58798.9010201@oracle.com> <56C59222.4090908@oracle.com> <56C62D6E.2090605@oracle.com> <56C746C9.8040508@oracle.com> Message-ID: On Fri, Feb 19, 2016 at 5:46 PM, Magnus Ihse Bursie wrote: > On 2016-02-19 09:40, Volker Simonis wrote: >> >> On Thu, Feb 18, 2016 at 9:45 PM, Magnus Ihse Bursie >> wrote: >>> >>> On 2016-02-18 11:17, Volker Simonis wrote: >>>> >>>> Thanks. >>>> >>>> Unfortunately, --disable-warnings-as-errors doesn't help in this case. >>>> If we want to still make it possible to build with 12u3 we have to >>>> filter out the corresponding -erroff options depending on the compiler >>>> version. >>> >>> Due to reasons like this, we would like to support a minimal span of >>> versions for the solstudio compiler. So if you are alright with upgrading >>> to >>> 12u4, we'd prefer to drop support for 12u3 completely. Filtering out >>> error >>> options like this is quite a pain, otherwise. >>> >>> I believe there are few community users that care much about Solaris and >>> solstudio. Had you not told me you were building on Solaris, I would have >>> guessed only Oracle did so. This gives us, I believe, a better chance at >>> enforcing stricter restrictions on the set of supported versions, >>> compared >>> to the situation for e.g. gcc and linux. >>> >> For our product builds we will most probably have to stay with older >> version for a couple of reasons (building on older OS release, >> dependency on other products/libraries, licensing/support issues, >> etc). But as long as the problem is just a few unknown compiler >> options I'm fine if you say you don't want to support them any more >> (we can easily remove them in our proprietary build). >> >> This assessment would of course change if it would be necessary to >> make bigger source code changes (i.e. template code) in order to >> support older compilers. But fortunately we're not there until now :) >> >> By the way, do you know if the upcoming "HotSpot C++ Unit-Test >> Framework" (JEP 281) will impose further restrictions on the supported >> C++ compilers? > > > Not that I know of, no. But perhaps no-one have ever tried compiling GTest > on xlc, so you might have some porting work to do if you want to be able to > use the unit test framework. > Yet another adventure we have to survive :) > /Magnus > > >> >> Regards, >> Volker >> > From volker.simonis at gmail.com Fri Feb 19 17:20:02 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 19 Feb 2016 18:20:02 +0100 Subject: RFR(S): JDK-8150197: Integrate AIX fixes from build-infra Message-ID: Hi, can I please have a reviewer and sponsor for this AIX build change: http://cr.openjdk.java.net/~simonis/webrevs/2016/8150197/ https://bugs.openjdk.java.net/browse/JDK-8150197 The change is actually a downport from build-infra and it has already been informally reviewed by Magnus in that repository. The change itself updates the AIX link flags and uses a new option during linking which produces a so called "loadmap". That's a file which summarizes the link step and can be used to quickly detect linking problems. The option has been already used for the HotSpot build and will now be used for every shared library. Thank you and best regards, Volker From andreas.lundblad at oracle.com Fri Feb 19 21:06:17 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Fri, 19 Feb 2016 22:06:17 +0100 Subject: Sjavac build times Message-ID: <20160219210615.GA5711@e6430> I spent some time measuring the build times of the java modules with different settings. Attaching a chart of the result. Red bars: - Plain old javac. Sjavac disabled. Green bars: - Sjavac, without breaking up each module into multiple javac invocations. (This is the default setting.) Blue bars: - Sjavac where each module is split into three parallel javac invocations. (Note that even without this parallelism the build still parallelises on a module level.) I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the "make clean-java; make java-only" so there should have been no native compilations going on in the background. I don't think there are any surprises in the chart. Since we're (most of the time) compiling many modules in parallel we get full CPU utilization without splitting each module into smaller parts. When splitting into smaller parts, we get lots of implicit compilation for each part, so we're just wasting lots of cycles. IF however, one were to do this experiment on a, say, 32 core machine, one might actually get a small speedup by splitting (because even when we have lots of modules being compiled in parallel, we have cores to spare). But I'm not sure considering how small most of the modules are. -- Andreas From andreas.lundblad at oracle.com Sat Feb 20 09:27:06 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Sat, 20 Feb 2016 10:27:06 +0100 Subject: Sjavac build times In-Reply-To: <20160219210615.GA5711@e6430> References: <20160219210615.GA5711@e6430> Message-ID: <20160220092704.GA13092@e6430> Thought I attached the chart. Here's another attempt. -- Andreas On Fri, Feb 19, 2016 at 10:06:17PM +0100, Andreas Lundblad wrote: > I spent some time measuring the build times of the java modules with different settings. > > Attaching a chart of the result. > > Red bars: > - Plain old javac. Sjavac disabled. > > Green bars: > - Sjavac, without breaking up each module into multiple javac invocations. (This is the default setting.) > > Blue bars: > - Sjavac where each module is split into three parallel javac invocations. (Note that even without this parallelism the build still parallelises on a module level.) > > > I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the "make clean-java; make java-only" so there should have been no native compilations going on in the background. > > I don't think there are any surprises in the chart. Since we're (most of the time) compiling many modules in parallel we get full CPU utilization without splitting each module into smaller parts. When splitting into smaller parts, we get lots of implicit compilation for each part, so we're just wasting lots of cycles. IF however, one were to do this experiment on a, say, 32 core machine, one might actually get a small speedup by splitting (because even when we have lots of modules being compiled in parallel, we have cores to spare). But I'm not sure considering how small most of the modules are. > > -- Andreas From erik.joelsson at oracle.com Sat Feb 20 14:02:36 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Sat, 20 Feb 2016 06:02:36 -0800 Subject: Sjavac build times In-Reply-To: <20160220092704.GA13092@e6430> References: <20160219210615.GA5711@e6430> <20160220092704.GA13092@e6430> Message-ID: <56C871FC.1070405@oracle.com> The openjdk mailing list server eats attachements. Can you put it on cr.openjdk.java.net instead? /Erik On 2016-02-20 01:27, Andreas Lundblad wrote: > Thought I attached the chart. Here's another attempt. > > -- Andreas > > On Fri, Feb 19, 2016 at 10:06:17PM +0100, Andreas Lundblad wrote: >> I spent some time measuring the build times of the java modules with different settings. >> >> Attaching a chart of the result. >> >> Red bars: >> - Plain old javac. Sjavac disabled. >> >> Green bars: >> - Sjavac, without breaking up each module into multiple javac invocations. (This is the default setting.) >> >> Blue bars: >> - Sjavac where each module is split into three parallel javac invocations. (Note that even without this parallelism the build still parallelises on a module level.) >> >> >> I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the "make clean-java; make java-only" so there should have been no native compilations going on in the background. >> >> I don't think there are any surprises in the chart. Since we're (most of the time) compiling many modules in parallel we get full CPU utilization without splitting each module into smaller parts. When splitting into smaller parts, we get lots of implicit compilation for each part, so we're just wasting lots of cycles. IF however, one were to do this experiment on a, say, 32 core machine, one might actually get a small speedup by splitting (because even when we have lots of modules being compiled in parallel, we have cores to spare). But I'm not sure considering how small most of the modules are. >> >> -- Andreas From erik.joelsson at oracle.com Sat Feb 20 14:19:44 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Sat, 20 Feb 2016 06:19:44 -0800 Subject: RFR(S): JDK-8150197: Integrate AIX fixes from build-infra In-Reply-To: References: Message-ID: <56C87600.4080700@oracle.com> Looks good to me. /Erik On 2016-02-19 09:20, Volker Simonis wrote: > Hi, > > can I please have a reviewer and sponsor for this AIX build change: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8150197/ > https://bugs.openjdk.java.net/browse/JDK-8150197 > > The change is actually a downport from build-infra and it has already > been informally reviewed by Magnus in that repository. > The change itself updates the AIX link flags and uses a new option > during linking which produces a so called "loadmap". That's a file > which summarizes the link step and can be used to quickly detect > linking problems. The option has been already used for the HotSpot > build and will now be used for every shared library. > > Thank you and best regards, > Volker From erik.joelsson at oracle.com Sat Feb 20 14:25:15 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Sat, 20 Feb 2016 06:25:15 -0800 Subject: RFR: JDK-8150203 Incremental update from build-infra project In-Reply-To: <56C739F6.7010509@oracle.com> References: <56C739F6.7010509@oracle.com> Message-ID: <56C8774B.8040601@oracle.com> Looks good to me. /Erik On 2016-02-19 07:51, Magnus Ihse Bursie wrote: > More incremental fixes from the build-infra project. The list of fixes > include: > > * More ExecuteWithLog. > * Native buildtools fixes. > * Make DTDParser quiet. > * LIBM cleanups. > * Export LDFLAGS_HASH_STYLE. > * Remove superfluous -export on LDFLAGS_windows. (JNIEXPORT used) > * Don't let make reconfigure delete spec.gmk on abort > > I have run this using JPRT and the COMPARE_BUILD functionality, which > shows no differences. I'm still awaiting results from the last > platforms, but so far it's looking good. (I'll report back if > something breaks.) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150203 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8150203-incremental-build-infra-fixes/webrev.01 > > /Magnus From david.holmes at oracle.com Sun Feb 21 23:23:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Feb 2016 09:23:26 +1000 Subject: RFR: JDK-8150257 Remove softfloat lib support In-Reply-To: <56C73E3F.8030309@oracle.com> References: <56C73E3F.8030309@oracle.com> Message-ID: <56CA46EE.60402@oracle.com> Hi Magnus, On 20/02/2016 2:09 AM, Magnus Ihse Bursie wrote: > We have some quite ugly hacks in place to support injecting the > softfloat lib on certain platforms. This is not needed anymore and > should be removed. Is this no longer relevant to the iOS-arm build in mobile-dev? They will need to add this back if they still need it, but perhaps in a cleaner way. Otherwise removal looks good. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8150257 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8150257-remove-softfloat-lib-support/webrev.01 > > > /Magnus From andreas.lundblad at oracle.com Mon Feb 22 07:00:31 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Mon, 22 Feb 2016 08:00:31 +0100 Subject: Sjavac build times In-Reply-To: <20160219210615.GA5711@e6430> References: <20160219210615.GA5711@e6430> Message-ID: <20160222070031.GA26377@e6430> Sorry folks. I have now learned that OpenJDK mailer strips attachments. Here's the chart: http://cr.openjdk.java.net/~alundblad/build-times/build-times.png -- Andreas On Fri, Feb 19, 2016 at 10:06:17PM +0100, Andreas Lundblad wrote: > I spent some time measuring the build times of the java modules with different settings. > > Attaching a chart of the result. > > Red bars: > - Plain old javac. Sjavac disabled. > > Green bars: > - Sjavac, without breaking up each module into multiple javac invocations. (This is the default setting.) > > Blue bars: > - Sjavac where each module is split into three parallel javac invocations. (Note that even without this parallelism the build still parallelises on a module level.) > > > I did the measurements on my laptop (4 core, i7 @ 2.8 GHz). I measured the "make clean-java; make java-only" so there should have been no native compilations going on in the background. > > I don't think there are any surprises in the chart. Since we're (most of the time) compiling many modules in parallel we get full CPU utilization without splitting each module into smaller parts. When splitting into smaller parts, we get lots of implicit compilation for each part, so we're just wasting lots of cycles. IF however, one were to do this experiment on a, say, 32 core machine, one might actually get a small speedup by splitting (because even when we have lots of modules being compiled in parallel, we have cores to spare). But I'm not sure considering how small most of the modules are. > > -- Andreas From magnus.ihse.bursie at oracle.com Mon Feb 22 10:27:23 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 22 Feb 2016 11:27:23 +0100 Subject: RFR(S): JDK-8150197: Integrate AIX fixes from build-infra In-Reply-To: <56C87600.4080700@oracle.com> References: <56C87600.4080700@oracle.com> Message-ID: <56CAE28B.1060509@oracle.com> On 2016-02-20 15:19, Erik Joelsson wrote: > Looks good to me. Looks good to me to. I'll push it for you, Volker. /Magnus > > /Erik > > On 2016-02-19 09:20, Volker Simonis wrote: >> Hi, >> >> can I please have a reviewer and sponsor for this AIX build change: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8150197/ >> https://bugs.openjdk.java.net/browse/JDK-8150197 >> >> The change is actually a downport from build-infra and it has already >> been informally reviewed by Magnus in that repository. >> The change itself updates the AIX link flags and uses a new option >> during linking which produces a so called "loadmap". That's a file >> which summarizes the link step and can be used to quickly detect >> linking problems. The option has been already used for the HotSpot >> build and will now be used for every shared library. >> >> Thank you and best regards, >> Volker > From gary.adams at oracle.com Mon Feb 22 13:07:05 2016 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 22 Feb 2016 08:07:05 -0500 Subject: RFR: JDK-8150257 Remove softfloat lib support In-Reply-To: <56CA46EE.60402@oracle.com> References: <56C73E3F.8030309@oracle.com> <56CA46EE.60402@oracle.com> Message-ID: <56CB07F9.1000004@oracle.com> As far as I know the only build that uses the sflt libs is the legacy armv5 linux systems. http://closedjdk.us.oracle.com/ejdk9/dev/closed/file/a2055fab159f/bin/build-embedded.csh#l331 ... # ARMv5t, non-thumb, soft-float emulation, soft-float ABI case linux-arm-sflt: set JVM_VARIANT = "--with-jvm-variants=client,minimal1" set DEVKIT = --with-devkit=$TOOLKIT_ROOT/gcc/linux/arm/arm-linaro-4.7 set X11KIT = --with-x=$TOOLKIT_ROOT/gcc/linux/arm/arm-linaro-4.7/arm-linux-gnueabi/libc/usr/X11R6 set SFLT_LIB_PATH = --with-sflt-lib-path=$TOOLKIT_ROOT/gcc/linux/arm/ext set CROSS_COMPILE_ARCH = --openjdk-target=arm-linux-gnueabi set ABI_PROFILE = --with-abi-profile=arm-sflt breaksw On 02/21/16 18:23, David Holmes wrote: > Hi Magnus, > > On 20/02/2016 2:09 AM, Magnus Ihse Bursie wrote: >> We have some quite ugly hacks in place to support injecting the >> softfloat lib on certain platforms. This is not needed anymore and >> should be removed. > > Is this no longer relevant to the iOS-arm build in mobile-dev? They > will need to add this back if they still need it, but perhaps in a > cleaner way. > > Otherwise removal looks good. > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150257 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8150257-remove-softfloat-lib-support/webrev.01 >> >> >> >> /Magnus From erik.joelsson at oracle.com Tue Feb 23 22:50:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Feb 2016 14:50:23 -0800 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit Message-ID: <56CCE22F.4090301@oracle.com> The windows 32 bit build is currently DOA. In JDK-8150203, the following build warning on Windows x64 was eliminated: CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; using first specification This warning is emitted because the function both has a JNIEXPORT declaration and a link time -export:ZIP_CRC32. The change removed the -export link flag which removed the warning. On Windows x86, removing the explicit -export link flag is causing trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not the same thing as the link flag -export. The first will export _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for the symbol ZIP_CRC32 and will fail without the -export link flag. My proposed fix is to readd the -export and remove the JNIEXPORT from this function. This would mimic the pattern of the other exported symbols in this library. Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 Patch: diff -r 9d536355b828 make/lib/CoreLibraries.gmk --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 @@ -225,7 +225,7 @@ $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close -export:ZIP_FindEntry \ -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ - -export:ZIP_InflateFully, \ + -export:ZIP_InflateFully -export:ZIP_CRC32, \ LIBS_unix := -ljvm -ljava $(LIBZ), \ LIBS_solaris := -lc, \ LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 2016 +0100 +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 2016 +0100 @@ -54,7 +54,7 @@ return crc; } -JNIEXPORT jint JNICALL +jint JNICALL ZIP_CRC32(jint crc, const jbyte *buf, jint len) { return crc32(crc, (Bytef*)buf, len); /Erik From magnus.ihse.bursie at oracle.com Tue Feb 23 23:05:21 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 24 Feb 2016 00:05:21 +0100 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE22F.4090301@oracle.com> References: <56CCE22F.4090301@oracle.com> Message-ID: <56CCE5B1.5010602@oracle.com> On 2016-02-23 23:50, Erik Joelsson wrote: > The windows 32 bit build is currently DOA. > > In JDK-8150203, the following build warning on Windows x64 was > eliminated: > > CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; > using first specification > > This warning is emitted because the function both has a JNIEXPORT > declaration and a link time -export:ZIP_CRC32. The change removed the > -export link flag which removed the warning. > > On Windows x86, removing the explicit -export link flag is causing > trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not > the same thing as the link flag -export. The first will export > _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for > the symbol ZIP_CRC32 and will fail without the -export link flag. > > My proposed fix is to readd the -export and remove the JNIEXPORT from > this function. This would mimic the pattern of the other exported > symbols in this library. Looks good to me. But in that case, probably all the removals of -export:* in JDK-8150203 was incorrect and should be fixed. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 > Patch: > diff -r 9d536355b828 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 > @@ -225,7 +225,7 @@ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close > -export:ZIP_FindEntry \ > -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ > - -export:ZIP_InflateFully, \ > + -export:ZIP_InflateFully -export:ZIP_CRC32, \ > LIBS_unix := -ljvm -ljava $(LIBZ), \ > LIBS_solaris := -lc, \ > LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ > diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c > --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 > 2016 +0100 > +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 > 2016 +0100 > @@ -54,7 +54,7 @@ > return crc; > } > > -JNIEXPORT jint JNICALL > +jint JNICALL > ZIP_CRC32(jint crc, const jbyte *buf, jint len) > { > return crc32(crc, (Bytef*)buf, len); > > /Erik From tim.bell at oracle.com Tue Feb 23 23:05:58 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 23 Feb 2016 15:05:58 -0800 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE22F.4090301@oracle.com> References: <56CCE22F.4090301@oracle.com> Message-ID: <56CCE5D6.2060603@oracle.com> Erik: Looks good. Tim On 02/23/16 14:50, Erik Joelsson wrote: > The windows 32 bit build is currently DOA. > > In JDK-8150203, the following build warning on Windows x64 was > eliminated: > > CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; > using first specification > > This warning is emitted because the function both has a JNIEXPORT > declaration and a link time -export:ZIP_CRC32. The change removed the > -export link flag which removed the warning. > > On Windows x86, removing the explicit -export link flag is causing > trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not > the same thing as the link flag -export. The first will export > _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for > the symbol ZIP_CRC32 and will fail without the -export link flag. > > My proposed fix is to readd the -export and remove the JNIEXPORT from > this function. This would mimic the pattern of the other exported > symbols in this library. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 > Patch: > diff -r 9d536355b828 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 > @@ -225,7 +225,7 @@ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close > -export:ZIP_FindEntry \ > -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ > - -export:ZIP_InflateFully, \ > + -export:ZIP_InflateFully -export:ZIP_CRC32, \ > LIBS_unix := -ljvm -ljava $(LIBZ), \ > LIBS_solaris := -lc, \ > LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ > diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c > --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 > 2016 +0100 > +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 > 2016 +0100 > @@ -54,7 +54,7 @@ > return crc; > } > > -JNIEXPORT jint JNICALL > +jint JNICALL > ZIP_CRC32(jint crc, const jbyte *buf, jint len) > { > return crc32(crc, (Bytef*)buf, len); > > /Erik From erik.joelsson at oracle.com Tue Feb 23 23:07:53 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Feb 2016 15:07:53 -0800 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE5B1.5010602@oracle.com> References: <56CCE22F.4090301@oracle.com> <56CCE5B1.5010602@oracle.com> Message-ID: <56CCE649.4010300@oracle.com> I will followup on that in a separate bug. /Erik On 2016-02-23 15:05, Magnus Ihse Bursie wrote: > On 2016-02-23 23:50, Erik Joelsson wrote: >> The windows 32 bit build is currently DOA. >> >> In JDK-8150203, the following build warning on Windows x64 was >> eliminated: >> >> CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple >> times; using first specification >> >> This warning is emitted because the function both has a JNIEXPORT >> declaration and a link time -export:ZIP_CRC32. The change removed the >> -export link flag which removed the warning. >> >> On Windows x86, removing the explicit -export link flag is causing >> trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is >> not the same thing as the link flag -export. The first will export >> _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look >> for the symbol ZIP_CRC32 and will fail without the -export link flag. >> >> My proposed fix is to readd the -export and remove the JNIEXPORT from >> this function. This would mimic the pattern of the other exported >> symbols in this library. > > Looks good to me. But in that case, probably all the removals of > -export:* in JDK-8150203 was incorrect and should be fixed. > > /Magnus > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 >> Patch: >> diff -r 9d536355b828 make/lib/CoreLibraries.gmk >> --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 >> +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 >> @@ -225,7 +225,7 @@ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close >> -export:ZIP_FindEntry \ >> -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ >> - -export:ZIP_InflateFully, \ >> + -export:ZIP_InflateFully -export:ZIP_CRC32, \ >> LIBS_unix := -ljvm -ljava $(LIBZ), \ >> LIBS_solaris := -lc, \ >> LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ >> diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c >> --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 >> 2016 +0100 >> +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 >> 2016 +0100 >> @@ -54,7 +54,7 @@ >> return crc; >> } >> >> -JNIEXPORT jint JNICALL >> +jint JNICALL >> ZIP_CRC32(jint crc, const jbyte *buf, jint len) >> { >> return crc32(crc, (Bytef*)buf, len); >> >> /Erik > From david.holmes at oracle.com Tue Feb 23 23:12:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Feb 2016 09:12:07 +1000 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE22F.4090301@oracle.com> References: <56CCE22F.4090301@oracle.com> Message-ID: <56CCE747.40405@oracle.com> Erik, There seems to be some confusion as there are two different problems on 32-bit windows. The build failure as reported in https://bugs.openjdk.java.net/browse/JDK-8150456 is a build failure in the install phase. The fix you are proposing below fixes a runtime failure at VM initialization time. David ----- On 24/02/2016 8:50 AM, Erik Joelsson wrote: > The windows 32 bit build is currently DOA. > > In JDK-8150203, the following build warning on Windows x64 was eliminated: > > CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; > using first specification > > This warning is emitted because the function both has a JNIEXPORT > declaration and a link time -export:ZIP_CRC32. The change removed the > -export link flag which removed the warning. > > On Windows x86, removing the explicit -export link flag is causing > trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not > the same thing as the link flag -export. The first will export > _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for > the symbol ZIP_CRC32 and will fail without the -export link flag. > > My proposed fix is to readd the -export and remove the JNIEXPORT from > this function. This would mimic the pattern of the other exported > symbols in this library. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 > Patch: > diff -r 9d536355b828 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 > @@ -225,7 +225,7 @@ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close > -export:ZIP_FindEntry \ > -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ > - -export:ZIP_InflateFully, \ > + -export:ZIP_InflateFully -export:ZIP_CRC32, \ > LIBS_unix := -ljvm -ljava $(LIBZ), \ > LIBS_solaris := -lc, \ > LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ > diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c > --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 2016 > +0100 > +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 2016 > +0100 > @@ -54,7 +54,7 @@ > return crc; > } > > -JNIEXPORT jint JNICALL > +jint JNICALL > ZIP_CRC32(jint crc, const jbyte *buf, jint len) > { > return crc32(crc, (Bytef*)buf, len); > > /Erik From david.holmes at oracle.com Tue Feb 23 23:19:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Feb 2016 09:19:56 +1000 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE747.40405@oracle.com> References: <56CCE22F.4090301@oracle.com> <56CCE747.40405@oracle.com> Message-ID: <56CCE91C.2040300@oracle.com> On 24/02/2016 9:12 AM, David Holmes wrote: > Erik, > > There seems to be some confusion as there are two different problems on > 32-bit windows. The build failure as reported in > > https://bugs.openjdk.java.net/browse/JDK-8150456 > > is a build failure in the install phase. The fix you are proposing below > fixes a runtime failure at VM initialization time. Sorry, now I see the full picture - the runtime failure causes a later part of the build to fail. David ----- > David > ----- > > On 24/02/2016 8:50 AM, Erik Joelsson wrote: >> The windows 32 bit build is currently DOA. >> >> In JDK-8150203, the following build warning on Windows x64 was >> eliminated: >> >> CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; >> using first specification >> >> This warning is emitted because the function both has a JNIEXPORT >> declaration and a link time -export:ZIP_CRC32. The change removed the >> -export link flag which removed the warning. >> >> On Windows x86, removing the explicit -export link flag is causing >> trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not >> the same thing as the link flag -export. The first will export >> _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for >> the symbol ZIP_CRC32 and will fail without the -export link flag. >> >> My proposed fix is to readd the -export and remove the JNIEXPORT from >> this function. This would mimic the pattern of the other exported >> symbols in this library. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 >> Patch: >> diff -r 9d536355b828 make/lib/CoreLibraries.gmk >> --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 >> +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 >> @@ -225,7 +225,7 @@ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close >> -export:ZIP_FindEntry \ >> -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ >> - -export:ZIP_InflateFully, \ >> + -export:ZIP_InflateFully -export:ZIP_CRC32, \ >> LIBS_unix := -ljvm -ljava $(LIBZ), \ >> LIBS_solaris := -lc, \ >> LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ >> diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c >> --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 2016 >> +0100 >> +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 2016 >> +0100 >> @@ -54,7 +54,7 @@ >> return crc; >> } >> >> -JNIEXPORT jint JNICALL >> +jint JNICALL >> ZIP_CRC32(jint crc, const jbyte *buf, jint len) >> { >> return crc32(crc, (Bytef*)buf, len); >> >> /Erik From erik.joelsson at oracle.com Tue Feb 23 23:23:28 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Feb 2016 15:23:28 -0800 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE747.40405@oracle.com> References: <56CCE22F.4090301@oracle.com> <56CCE747.40405@oracle.com> Message-ID: <56CCE9F0.3030204@oracle.com> It was concluded in that bug that the install failure was a consequence of pack200 failing with the same error I saw. They actually run the newly built pack200, so if the jvm is DOA, the install build will fail. These errors were reported through different channels at the same time, caused by the same change. I'm currently verifying that this fix really does fix the install build, but I'm quite confident it does. /Erik On 2016-02-23 15:12, David Holmes wrote: > Erik, > > There seems to be some confusion as there are two different problems > on 32-bit windows. The build failure as reported in > > https://bugs.openjdk.java.net/browse/JDK-8150456 > > is a build failure in the install phase. The fix you are proposing > below fixes a runtime failure at VM initialization time. > > David > ----- > > On 24/02/2016 8:50 AM, Erik Joelsson wrote: >> The windows 32 bit build is currently DOA. >> >> In JDK-8150203, the following build warning on Windows x64 was >> eliminated: >> >> CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; >> using first specification >> >> This warning is emitted because the function both has a JNIEXPORT >> declaration and a link time -export:ZIP_CRC32. The change removed the >> -export link flag which removed the warning. >> >> On Windows x86, removing the explicit -export link flag is causing >> trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not >> the same thing as the link flag -export. The first will export >> _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for >> the symbol ZIP_CRC32 and will fail without the -export link flag. >> >> My proposed fix is to readd the -export and remove the JNIEXPORT from >> this function. This would mimic the pattern of the other exported >> symbols in this library. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 >> Patch: >> diff -r 9d536355b828 make/lib/CoreLibraries.gmk >> --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 >> +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 >> @@ -225,7 +225,7 @@ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close >> -export:ZIP_FindEntry \ >> -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ >> - -export:ZIP_InflateFully, \ >> + -export:ZIP_InflateFully -export:ZIP_CRC32, \ >> LIBS_unix := -ljvm -ljava $(LIBZ), \ >> LIBS_solaris := -lc, \ >> LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ >> diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c >> --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 2016 >> +0100 >> +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 2016 >> +0100 >> @@ -54,7 +54,7 @@ >> return crc; >> } >> >> -JNIEXPORT jint JNICALL >> +jint JNICALL >> ZIP_CRC32(jint crc, const jbyte *buf, jint len) >> { >> return crc32(crc, (Bytef*)buf, len); >> >> /Erik From erik.joelsson at oracle.com Tue Feb 23 23:40:25 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Feb 2016 15:40:25 -0800 Subject: RFR: JDK-8150456: jdk 9 nightly build fails on Windows 32 bit In-Reply-To: <56CCE91C.2040300@oracle.com> References: <56CCE22F.4090301@oracle.com> <56CCE747.40405@oracle.com> <56CCE91C.2040300@oracle.com> Message-ID: <56CCEDE9.3070308@oracle.com> For the record, the full build is passing now. /Erik On 2016-02-23 15:19, David Holmes wrote: > On 24/02/2016 9:12 AM, David Holmes wrote: >> Erik, >> >> There seems to be some confusion as there are two different problems on >> 32-bit windows. The build failure as reported in >> >> https://bugs.openjdk.java.net/browse/JDK-8150456 >> >> is a build failure in the install phase. The fix you are proposing below >> fixes a runtime failure at VM initialization time. > > Sorry, now I see the full picture - the runtime failure causes a later > part of the build to fail. > > David > ----- > >> David >> ----- >> >> On 24/02/2016 8:50 AM, Erik Joelsson wrote: >>> The windows 32 bit build is currently DOA. >>> >>> In JDK-8150203, the following build warning on Windows x64 was >>> eliminated: >>> >>> CRC32.c: warning LNK4197: export 'ZIP_CRC32' specified multiple times; >>> using first specification >>> >>> This warning is emitted because the function both has a JNIEXPORT >>> declaration and a link time -export:ZIP_CRC32. The change removed the >>> -export link flag which removed the warning. >>> >>> On Windows x86, removing the explicit -export link flag is causing >>> trouble. Just using JNIEXPORT (or really __declspec(dllexport)) is not >>> the same thing as the link flag -export. The first will export >>> _ZIP_CRC32 and the second ZIP_CRC32. In hotspot, jvm.dll will look for >>> the symbol ZIP_CRC32 and will fail without the -export link flag. >>> >>> My proposed fix is to readd the -export and remove the JNIEXPORT from >>> this function. This would mimic the pattern of the other exported >>> symbols in this library. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150456 >>> Patch: >>> diff -r 9d536355b828 make/lib/CoreLibraries.gmk >>> --- a/make/lib/CoreLibraries.gmk Tue Feb 23 09:49:04 2016 +0100 >>> +++ b/make/lib/CoreLibraries.gmk Tue Feb 23 23:49:10 2016 +0100 >>> @@ -225,7 +225,7 @@ >>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> LDFLAGS_windows := -export:ZIP_Open -export:ZIP_Close >>> -export:ZIP_FindEntry \ >>> -export:ZIP_ReadEntry -export:ZIP_GetNextEntry \ >>> - -export:ZIP_InflateFully, \ >>> + -export:ZIP_InflateFully -export:ZIP_CRC32, \ >>> LIBS_unix := -ljvm -ljava $(LIBZ), \ >>> LIBS_solaris := -lc, \ >>> LIBS_windows := jvm.lib $(WIN_JAVA_LIB), \ >>> diff -r 9d536355b828 src/java.base/share/native/libzip/CRC32.c >>> --- a/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 09:49:04 >>> 2016 >>> +0100 >>> +++ b/src/java.base/share/native/libzip/CRC32.c Tue Feb 23 23:49:10 >>> 2016 >>> +0100 >>> @@ -54,7 +54,7 @@ >>> return crc; >>> } >>> >>> -JNIEXPORT jint JNICALL >>> +jint JNICALL >>> ZIP_CRC32(jint crc, const jbyte *buf, jint len) >>> { >>> return crc32(crc, (Bytef*)buf, len); >>> >>> /Erik From david.holmes at oracle.com Wed Feb 24 02:00:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Feb 2016 12:00:36 +1000 Subject: sjavac problems continue Message-ID: <56CD0EC4.4060406@oracle.com> I just had a failed JPRT build on Solaris sparc caused by: === Output from failing command(s) repeated here === /usr/ccs/bin/printf "* For target support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" * For target support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log || true) | /usr/ccs/bin/head -n 12 Connection attempt failed: Connection refused Connection attempt failed: Connection refused Connection attempt failed: Connection refused Giving up [CLIENT] Exception caught: java.io.IOException: Could not connect to server java.io.IOException: Could not connect to server at com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) at com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) at com.sun.tools.sjavac.Main.go(Main.java:56) at com.sun.tools.sjavac.Main.main(Main.java:46) David From thomas.stuefe at gmail.com Wed Feb 24 08:33:55 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Feb 2016 09:33:55 +0100 Subject: sjavac problems continue In-Reply-To: <56CD0EC4.4060406@oracle.com> References: <56CD0EC4.4060406@oracle.com> Message-ID: Just to add another small annoyance, it seems that if I build on Windows in cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac server hangs and blocks the output directory. It takes some minutes for it to timeout, or I go hunting for the process in Process Explorer. I really like the sjavac server, it makes the builds much faster, but without these glitches I would like it even better :) On Wed, Feb 24, 2016 at 3:00 AM, David Holmes wrote: > I just had a failed JPRT build on Solaris sparc caused by: > > === Output from failing command(s) repeated here === > /usr/ccs/bin/printf "* For target > support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" > > * For target > support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: > (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < > /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log > || true) | /usr/ccs/bin/head -n 12 > Connection attempt failed: Connection refused > Connection attempt failed: Connection refused > Connection attempt failed: Connection refused > Giving up > [CLIENT] Exception caught: java.io.IOException: Could not connect to server > java.io.IOException: Could not connect to server > at > com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) > at > com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) > at com.sun.tools.sjavac.Main.go(Main.java:56) > at com.sun.tools.sjavac.Main.main(Main.java:46) > > David > From andreas.lundblad at oracle.com Wed Feb 24 18:14:18 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 24 Feb 2016 19:14:18 +0100 Subject: sjavac problems continue In-Reply-To: <56CD0EC4.4060406@oracle.com> References: <56CD0EC4.4060406@oracle.com> Message-ID: <20160224181417.GA22178@e6430> On Wed, Feb 24, 2016 at 12:00:36PM +1000, David Holmes wrote: > I just had a failed JPRT build on Solaris sparc caused by: Sorry to hear this. I've been ill today (not sure how I'll feel tomorrow) but I'll look into this issue before doing anything else. There's always the --disable-javac-server workaround. -- Andreas > === Output from failing command(s) repeated here === > /usr/ccs/bin/printf "* For target support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" > > * For target support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: > (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log > || true) | /usr/ccs/bin/head -n 12 > Connection attempt failed: Connection refused > Connection attempt failed: Connection refused > Connection attempt failed: Connection refused > Giving up > [CLIENT] Exception caught: java.io.IOException: Could not connect to server > java.io.IOException: Could not connect to server > at com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) > at com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) > at com.sun.tools.sjavac.Main.go(Main.java:56) > at com.sun.tools.sjavac.Main.main(Main.java:46) > > David From andreas.lundblad at oracle.com Wed Feb 24 18:17:02 2016 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 24 Feb 2016 19:17:02 +0100 Subject: sjavac problems continue In-Reply-To: References: <56CD0EC4.4060406@oracle.com> Message-ID: <20160224181701.GB22178@e6430> On Wed, Feb 24, 2016 at 09:33:55AM +0100, Thomas St?fe wrote: > Just to add another small annoyance, it seems that if I build on Windows in > cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac > server hangs and blocks the output directory. It takes some minutes for it > to timeout, or I go hunting for the process in Process Explorer. Interesting. I don't know if there's an easy solution to this one. (I.e. if there's a way to terminate the server upon Ctrl+C of make.) The sjavac server stops if the portfile is removed though, so a "make clean" might do the trick. -- Andreas > I really like the sjavac server, it makes the builds much faster, but > without these glitches I would like it even better :) > > On Wed, Feb 24, 2016 at 3:00 AM, David Holmes > wrote: > > > I just had a failed JPRT build on Solaris sparc caused by: > > > > === Output from failing command(s) repeated here === > > /usr/ccs/bin/printf "* For target > > support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" > > > > * For target > > support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: > > (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < > > /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log > > || true) | /usr/ccs/bin/head -n 12 > > Connection attempt failed: Connection refused > > Connection attempt failed: Connection refused > > Connection attempt failed: Connection refused > > Giving up > > [CLIENT] Exception caught: java.io.IOException: Could not connect to server > > java.io.IOException: Could not connect to server > > at > > com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) > > at > > com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) > > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) > > at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) > > at com.sun.tools.sjavac.Main.go(Main.java:56) > > at com.sun.tools.sjavac.Main.main(Main.java:46) > > > > David > > From thomas.stuefe at gmail.com Wed Feb 24 18:52:58 2016 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Feb 2016 19:52:58 +0100 Subject: sjavac problems continue In-Reply-To: <20160224181701.GB22178@e6430> References: <56CD0EC4.4060406@oracle.com> <20160224181701.GB22178@e6430> Message-ID: Hi Andreas, On Wed, Feb 24, 2016 at 7:17 PM, Andreas Lundblad < andreas.lundblad at oracle.com> wrote: > On Wed, Feb 24, 2016 at 09:33:55AM +0100, Thomas St?fe wrote: > > Just to add another small annoyance, it seems that if I build on Windows > in > > cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac > > server hangs and blocks the output directory. It takes some minutes for > it > > to timeout, or I go hunting for the process in Process Explorer. > > Interesting. I don't know if there's an easy solution to this one. (I.e. > if there's a way to terminate the server upon Ctrl+C of make.) > > The sjavac server stops if the portfile is removed though, so a "make > clean" might do the trick. > > I think I tried this, but if memory serves right (I am out of office) the portfile is locked at file level. Kind Regards, Thomas > -- Andreas > > > I really like the sjavac server, it makes the builds much faster, but > > without these glitches I would like it even better :) > > > > On Wed, Feb 24, 2016 at 3:00 AM, David Holmes > > wrote: > > > > > I just had a failed JPRT build on Solaris sparc caused by: > > > > > > === Output from failing command(s) repeated here === > > > /usr/ccs/bin/printf "* For target > > > > support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" > > > > > > * For target > > > > support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: > > > (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < > > > > /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log > > > || true) | /usr/ccs/bin/head -n 12 > > > Connection attempt failed: Connection refused > > > Connection attempt failed: Connection refused > > > Connection attempt failed: Connection refused > > > Giving up > > > [CLIENT] Exception caught: java.io.IOException: Could not connect to > server > > > java.io.IOException: Could not connect to server > > > at > > > > com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) > > > at > > > com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) > > > at > com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) > > > at > com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) > > > at com.sun.tools.sjavac.Main.go(Main.java:56) > > > at com.sun.tools.sjavac.Main.main(Main.java:46) > > > > > > David > > > > From david.holmes at oracle.com Wed Feb 24 20:15:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Feb 2016 06:15:35 +1000 Subject: sjavac problems continue In-Reply-To: <20160224181417.GA22178@e6430> References: <56CD0EC4.4060406@oracle.com> <20160224181417.GA22178@e6430> Message-ID: <56CE0F67.5040809@oracle.com> On 25/02/2016 4:14 AM, Andreas Lundblad wrote: > On Wed, Feb 24, 2016 at 12:00:36PM +1000, David Holmes wrote: >> I just had a failed JPRT build on Solaris sparc caused by: > > Sorry to hear this. > > I've been ill today (not sure how I'll feel tomorrow) but I'll look into this issue before doing anything else. > > There's always the --disable-javac-server workaround. No workaround possible when doing a push through JPRT. Thanks, David > -- Andreas > > >> === Output from failing command(s) repeated here === >> /usr/ccs/bin/printf "* For target support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" >> >> * For target support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: >> (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log >> || true) | /usr/ccs/bin/head -n 12 >> Connection attempt failed: Connection refused >> Connection attempt failed: Connection refused >> Connection attempt failed: Connection refused >> Giving up >> [CLIENT] Exception caught: java.io.IOException: Could not connect to server >> java.io.IOException: Could not connect to server >> at com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) >> at com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) >> at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) >> at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) >> at com.sun.tools.sjavac.Main.go(Main.java:56) >> at com.sun.tools.sjavac.Main.main(Main.java:46) >> >> David From magnus.ihse.bursie at oracle.com Wed Feb 24 21:28:13 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 24 Feb 2016 22:28:13 +0100 Subject: sjavac problems continue In-Reply-To: <20160224181701.GB22178@e6430> References: <56CD0EC4.4060406@oracle.com> <20160224181701.GB22178@e6430> Message-ID: I've noted this as well. We should probably store the port file in /tmp, instead of in the build directory. /Magnus > 24 feb. 2016 kl. 19:17 skrev Andreas Lundblad : > >> On Wed, Feb 24, 2016 at 09:33:55AM +0100, Thomas St?fe wrote: >> Just to add another small annoyance, it seems that if I build on Windows in >> cygwin and I cancel the build for whatever reason with CTRL+C, the sjavac >> server hangs and blocks the output directory. It takes some minutes for it >> to timeout, or I go hunting for the process in Process Explorer. > > Interesting. I don't know if there's an easy solution to this one. (I.e. if there's a way to terminate the server upon Ctrl+C of make.) > > The sjavac server stops if the portfile is removed though, so a "make clean" might do the trick. > > -- Andreas > >> I really like the sjavac server, it makes the builds much faster, but >> without these glitches I would like it even better :) >> >> On Wed, Feb 24, 2016 at 3:00 AM, David Holmes >> wrote: >> >>> I just had a failed JPRT build on Solaris sparc caused by: >>> >>> === Output from failing command(s) repeated here === >>> /usr/ccs/bin/printf "* For target >>> support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch:\n" >>> >>> * For target >>> support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch: >>> (/usr/ccs/bin/ggrep -v -e "^Note: including file:" < >>> /opt/jprt/T/P1/001448.daholme/s/build/solaris-sparcv9-debug/make-support/failure-logs/support_test_hotspot_closed_tonga_dist_java_classes__the.BUILD_JAVA_TOOLS_classes_batch.log >>> || true) | /usr/ccs/bin/head -n 12 >>> Connection attempt failed: Connection refused >>> Connection attempt failed: Connection refused >>> Connection attempt failed: Connection refused >>> Giving up >>> [CLIENT] Exception caught: java.io.IOException: Could not connect to server >>> java.io.IOException: Could not connect to server >>> at >>> com.sun.tools.sjavac.client.SjavacClient.tryConnect(SjavacClient.java:183) >>> at >>> com.sun.tools.sjavac.client.SjavacClient.compile(SjavacClient.java:126) >>> at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:84) >>> at com.sun.tools.sjavac.client.ClientMain.run(ClientMain.java:47) >>> at com.sun.tools.sjavac.Main.go(Main.java:56) >>> at com.sun.tools.sjavac.Main.main(Main.java:46) >>> >>> David >>> From jvanek at redhat.com Thu Feb 25 11:24:21 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 25 Feb 2016 12:24:21 +0100 Subject: Provide zipped javadoc archive from make Message-ID: <56CEE465.40107@redhat.com> Hello! Firs, sorry for spamming three lists but imho it is really touching all of them - it will be change in makefile, and it is new feature for old docs.... Currently, when you run make all, javadoc is generated as directory. I do not wont to touch this. However, I would like to add target, which will pack generated javadoc... Lets say correctly to zip archive. Having javadoc as directory have its advantages, but having javadoc as archive have another set of advantages. (eg main user of javadoc are IDEs. and all IDEs I know support archived javadocs. All library javadocs distributed over web are distributed as zips, and they are not expected to be unpacked. Many tools crate archved javadocs by default and so on...) I'm packaging openjdk for fedora, and next to java-1.X.0-openjdk-javadoc, and I wonted to provide java-1.X.0-openjdk-javadoc-zip so users have an choice to select zipped/unzipped javadoc depending on theirs usage. You may argue that size do not meter, but having four (6,7,8,9) jdks on machine, and so having 4 javadocs - it metres if it is 4x250mb or 4x50mb. Also, when I was preparing this simple patch to my packages, I realised - am I compressing all? Am I compressing it correctly and in best way? Is delivering of *JDK's* javadoc as archive even safe? So I would say that having this supported in upstream is much better then just pack zip it in distribution packages. What do you think? If you are interested, I will elaborate patch for jdk9 with wish for jdk8. Change should be simple, and the benefits worthy. Thanx! J. From erik.joelsson at oracle.com Thu Feb 25 14:50:16 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Feb 2016 06:50:16 -0800 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CEE465.40107@redhat.com> References: <56CEE465.40107@redhat.com> Message-ID: <56CF14A8.6040209@oracle.com> Hello Jiri, Adding a build target for creating bundles of all our images, including docs, is currently on my todo here: https://bugs.openjdk.java.net/browse/JDK-8136777 I believe our intention there is use tar.gz bundles for the most part. I would assume your usecase would require zip? This is certainly something to take into consideration if that's the case. /Erik On 2016-02-25 03:24, Jiri Vanek wrote: > Hello! > > Firs, sorry for spamming three lists but imho it is really touching > all of them - it will be change in makefile, and it is new feature for > old docs.... > > > Currently, when you run make all, javadoc is generated as directory. I > do not wont to touch this. However, I would like to add target, which > will pack generated javadoc... Lets say correctly to zip archive. > > Having javadoc as directory have its advantages, but having javadoc as > archive have another set of advantages. (eg main user of javadoc are > IDEs. and all IDEs I know support archived javadocs. All library > javadocs distributed over web are distributed as zips, and they are > not expected to be unpacked. Many tools crate archved javadocs by > default and so on...) > > I'm packaging openjdk for fedora, and next to > java-1.X.0-openjdk-javadoc, and I wonted to provide > java-1.X.0-openjdk-javadoc-zip so users have an choice to select > zipped/unzipped javadoc depending on theirs usage. You may argue that > size do not meter, but having four (6,7,8,9) jdks on machine, and so > having 4 javadocs - it metres if it is 4x250mb or 4x50mb. > > Also, when I was preparing this simple patch to my packages, I > realised - am I compressing all? Am I compressing it correctly and in > best way? Is delivering of *JDK's* javadoc as archive even safe? > > So I would say that having this supported in upstream is much better > then just pack zip it in distribution packages. > > What do you think? > > If you are interested, I will elaborate patch for jdk9 with wish for > jdk8. Change should be simple, and the benefits worthy. > > Thanx! > J. From jvanek at redhat.com Thu Feb 25 15:04:49 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 25 Feb 2016 16:04:49 +0100 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CF14A8.6040209@oracle.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> Message-ID: <56CF1811.9090704@redhat.com> On 02/25/2016 03:50 PM, Erik Joelsson wrote: > Hello Jiri, > > Adding a build target for creating bundles of all our images, including docs, is currently on my > todo here: > > https://bugs.openjdk.java.net/browse/JDK-8136777 > > I believe our intention there is use tar.gz bundles for the most part. I would assume your usecase > would require zip? This is certainly something to take into consideration if that's the case. Hello! Thank you for reply! And thanx for link, I was not expecting somebody is already on it:) Both zip api and gzip api are part of java, so most tool can be expected to work both with tar.gz and zip however... Sometimes the tools are expecting javadocs in jar - so having the docs tar.gzed is killing this. Most troubeling case may be my beloved netbeans. I'm sure (tried few seconds ago) that they are not able to add tar.gz-ed javadoc. Because of NB and because of jar~=zip I would rather go with zip as default. But if gzip have somehow better compression, then go with gzip, and force tools (like NB) to allow to use it. Was there some special reason why you had chosen gzip over zip? Thanx! J. > > /Erik > > On 2016-02-25 03:24, Jiri Vanek wrote: >> Hello! >> >> Firs, sorry for spamming three lists but imho it is really touching all of them - it will be >> change in makefile, and it is new feature for old docs.... >> >> >> Currently, when you run make all, javadoc is generated as directory. I do not wont to touch this. >> However, I would like to add target, which will pack generated javadoc... Lets say correctly to >> zip archive. >> >> Having javadoc as directory have its advantages, but having javadoc as archive have another set of >> advantages. (eg main user of javadoc are IDEs. and all IDEs I know support archived javadocs. All >> library javadocs distributed over web are distributed as zips, and they are not expected to be >> unpacked. Many tools crate archved javadocs by default and so on...) >> >> I'm packaging openjdk for fedora, and next to java-1.X.0-openjdk-javadoc, and I wonted to provide >> java-1.X.0-openjdk-javadoc-zip so users have an choice to select zipped/unzipped javadoc depending >> on theirs usage. You may argue that size do not meter, but having four (6,7,8,9) jdks on machine, >> and so having 4 javadocs - it metres if it is 4x250mb or 4x50mb. >> >> Also, when I was preparing this simple patch to my packages, I realised - am I compressing all? Am >> I compressing it correctly and in best way? Is delivering of *JDK's* javadoc as archive even safe? >> >> So I would say that having this supported in upstream is much better then just pack zip it in >> distribution packages. >> >> What do you think? >> >> If you are interested, I will elaborate patch for jdk9 with wish for jdk8. Change should be >> simple, and the benefits worthy. >> >> Thanx! >> J. > From jonathan.gibbons at oracle.com Thu Feb 25 15:31:15 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Feb 2016 07:31:15 -0800 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CF14A8.6040209@oracle.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> Message-ID: <56CF1E43.5080000@oracle.com> Erik, It sounds like you may describing something different to that which Jiri is asking for. You are describing "bundles of the images, including docs". The docs image contains the output from many separate runs of javadoc, and it sounds like you are considering a make target to generate a single .tar.gz file containing all that javadoc output. But if I understand Jiri's request correctly, he is asking for each individual collection of output from javadoc to be zipped. In other words, we would end up with a dozen or so .zip files from all the various runs of javadoc in the build. -- Jon On 02/25/2016 06:50 AM, Erik Joelsson wrote: > Hello Jiri, > > Adding a build target for creating bundles of all our images, > including docs, is currently on my todo here: > > https://bugs.openjdk.java.net/browse/JDK-8136777 > > I believe our intention there is use tar.gz bundles for the most part. > I would assume your usecase would require zip? This is certainly > something to take into consideration if that's the case. > > /Erik > > On 2016-02-25 03:24, Jiri Vanek wrote: >> Hello! >> >> Firs, sorry for spamming three lists but imho it is really touching >> all of them - it will be change in makefile, and it is new feature >> for old docs.... >> >> >> Currently, when you run make all, javadoc is generated as directory. >> I do not wont to touch this. However, I would like to add target, >> which will pack generated javadoc... Lets say correctly to zip archive. >> >> Having javadoc as directory have its advantages, but having javadoc >> as archive have another set of advantages. (eg main user of javadoc >> are IDEs. and all IDEs I know support archived javadocs. All library >> javadocs distributed over web are distributed as zips, and they are >> not expected to be unpacked. Many tools crate archved javadocs by >> default and so on...) >> >> I'm packaging openjdk for fedora, and next to >> java-1.X.0-openjdk-javadoc, and I wonted to provide >> java-1.X.0-openjdk-javadoc-zip so users have an choice to select >> zipped/unzipped javadoc depending on theirs usage. You may argue that >> size do not meter, but having four (6,7,8,9) jdks on machine, and so >> having 4 javadocs - it metres if it is 4x250mb or 4x50mb. >> >> Also, when I was preparing this simple patch to my packages, I >> realised - am I compressing all? Am I compressing it correctly and in >> best way? Is delivering of *JDK's* javadoc as archive even safe? >> >> So I would say that having this supported in upstream is much better >> then just pack zip it in distribution packages. >> >> What do you think? >> >> If you are interested, I will elaborate patch for jdk9 with wish for >> jdk8. Change should be simple, and the benefits worthy. >> >> Thanx! >> J. > From jvanek at redhat.com Thu Feb 25 17:23:00 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 25 Feb 2016 18:23:00 +0100 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CF1E43.5080000@oracle.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> <56CF1E43.5080000@oracle.com> Message-ID: <56CF3874.1060806@redhat.com> On 02/25/2016 04:31 PM, Jonathan Gibbons wrote: > Erik, > > It sounds like you may describing something different to that which Jiri is asking for. Well right. Sorry. I read the bug to rashly. > > You are describing "bundles of the images, including docs". The docs image contains the output from many separate runs of javadoc, and it sounds like you are considering a make target to generate a single .tar.gz file containing all that javadoc output. > > But if I understand Jiri's request correctly, he is asking for each individual collection of output from javadoc to be zipped. Indeed. I would like to have the javadoc, once generated to be possible to pack it as separate target. But *only* javadoc. > In other words, we would end up with a dozen or so .zip files from all the various runs of javadoc in the build. I must be missing something. Dozens? Of varius runs of javadoc? I thought that javadoc ending at the end in single drectory is one single javadoc for java. If you are referring to javadoc generated by "per module" then one jjoined zip is enough for me. Thank you for involvement! J. > > -- Jon > > > On 02/25/2016 06:50 AM, Erik Joelsson wrote: >> Hello Jiri, >> >> Adding a build target for creating bundles of all our images, including docs, is currently on my todo here: >> >> https://bugs.openjdk.java.net/browse/JDK-8136777 >> >> I believe our intention there is use tar.gz bundles for the most part. I would assume your usecase would require zip? This is certainly something to take into consideration if that's the case. >> >> /Erik >> >> On 2016-02-25 03:24, Jiri Vanek wrote: >>> Hello! >>> >>> Firs, sorry for spamming three lists but imho it is really touching all of them - it will be change in makefile, and it is new feature for old docs.... >>> >>> >>> Currently, when you run make all, javadoc is generated as directory. I do not wont to touch this. However, I would like to add target, which will pack generated javadoc... Lets say correctly to zip archive. >>> >>> Having javadoc as directory have its advantages, but having javadoc as archive have another set of advantages. (eg main user of javadoc are IDEs. and all IDEs I know support archived javadocs. All library javadocs distributed over web are distributed as zips, and they are not expected to be unpacked. Many tools crate archved javadocs by default and so on...) >>> >>> I'm packaging openjdk for fedora, and next to java-1.X.0-openjdk-javadoc, and I wonted to provide java-1.X.0-openjdk-javadoc-zip so users have an choice to select zipped/unzipped javadoc depending on theirs usage. You may argue that size do not meter, but having four (6,7,8,9) jdks on machine, and so having 4 javadocs - it metres if it is 4x250mb or 4x50mb. >>> >>> Also, when I was preparing this simple patch to my packages, I realised - am I compressing all? Am I compressing it correctly and in best way? Is delivering of *JDK's* javadoc as archive even safe? >>> >>> So I would say that having this supported in upstream is much better then just pack zip it in distribution packages. >>> >>> What do you think? >>> >>> If you are interested, I will elaborate patch for jdk9 with wish for jdk8. Change should be simple, and the benefits worthy. >>> >>> Thanx! >>> J. >> > From jonathan.gibbons at oracle.com Thu Feb 25 17:34:09 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Feb 2016 09:34:09 -0800 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CF3874.1060806@redhat.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> <56CF1E43.5080000@oracle.com> <56CF3874.1060806@redhat.com> Message-ID: <56CF3B11.2010001@oracle.com> On 02/25/2016 09:23 AM, Jiri Vanek wrote: > > I must be missing something. Dozens? Of varius runs of javadoc? > > I thought that javadoc ending at the end in single drectory is one > single javadoc for java. If you are referring to javadoc generated by > "per module" then one jjoined zip is enough for me. Jiri, If you accept the premise that javadoc writes one stylesheet.css file per run of javadoc, take a look at the following list: $ find build/linux-x86_64-normal-server-release/images/docs/ -name stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css The "main"/"Java SE" javadoc bundle that most are aware of is the shortest filename, in the middle of the list, but there are lots of other smaller APIs that get their own doc bundle. You can get at most of them in released doc sets through the top-level "brick wall" page, or by using your favorite search engine. -- Jon From erik.joelsson at oracle.com Fri Feb 26 02:42:41 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Feb 2016 18:42:41 -0800 Subject: RFR: JDK-8150497: 32 jshell tests failed on Windows 32 bit Message-ID: <56CFBBA1.1090802@oracle.com> Here is some more fallout from [1]. The same kind of issue as in [2], but this time in jdi libs. The fix is to restore the -export link flags and remove the then redundant JNIEXPORT annotations in the code. I have verified that this fixes the tests in question. Bug: https://bugs.openjdk.java.net/browse/JDK-8150497 Webrev: http://cr.openjdk.java.net/~erikj/8150497/webrev.jdk.01/index.html [1] JDK-8150203 Incremental update from build-infra project [2] JDK-8150456 jdk 9 nightly build fails on Windows 32 bit From joe.darcy at oracle.com Fri Feb 26 03:43:32 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Feb 2016 19:43:32 -0800 Subject: RFR: JDK-8150497: 32 jshell tests failed on Windows 32 bit In-Reply-To: <56CFBBA1.1090802@oracle.com> References: <56CFBBA1.1090802@oracle.com> Message-ID: <56CFC9E4.5040108@oracle.com> Looks fine Erik; thanks, -Joe On 2/25/2016 6:42 PM, Erik Joelsson wrote: > Here is some more fallout from [1]. The same kind of issue as in [2], > but this time in jdi libs. The fix is to restore the -export link > flags and remove the then redundant JNIEXPORT annotations in the code. > I have verified that this fixes the tests in question. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150497 > Webrev: > http://cr.openjdk.java.net/~erikj/8150497/webrev.jdk.01/index.html > > > [1] JDK-8150203 > Incremental update > from build-infra project > [2] JDK-8150456 jdk > 9 nightly build fails on Windows 32 bit From tim.bell at oracle.com Fri Feb 26 04:08:24 2016 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 25 Feb 2016 20:08:24 -0800 Subject: RFR: JDK-8150497: 32 jshell tests failed on Windows 32 bit In-Reply-To: <56CFC9E4.5040108@oracle.com> References: <56CFBBA1.1090802@oracle.com> <56CFC9E4.5040108@oracle.com> Message-ID: <56CFCFB8.6080006@oracle.com> Hi Erik Looks good to me as well. Tim On 02/25/16 19:43, joe darcy wrote: > Looks fine Erik; thanks, > > -Joe > > On 2/25/2016 6:42 PM, Erik Joelsson wrote: >> Here is some more fallout from [1]. The same kind of issue as in [2], >> but this time in jdi libs. The fix is to restore the -export link >> flags and remove the then redundant JNIEXPORT annotations in the >> code. I have verified that this fixes the tests in question. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8150497 >> Webrev: >> http://cr.openjdk.java.net/~erikj/8150497/webrev.jdk.01/index.html >> >> >> [1] JDK-8150203 >> Incremental update >> from build-infra project >> [2] JDK-8150456 jdk >> 9 nightly build fails on Windows 32 bit > From david.holmes at oracle.com Fri Feb 26 04:24:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Feb 2016 14:24:56 +1000 Subject: RFR: JDK-8150497: 32 jshell tests failed on Windows 32 bit In-Reply-To: <56CFBBA1.1090802@oracle.com> References: <56CFBBA1.1090802@oracle.com> Message-ID: <56CFD398.50403@oracle.com> Hi Erik, On 26/02/2016 12:42 PM, Erik Joelsson wrote: > Here is some more fallout from [1]. The same kind of issue as in [2], Is there anything in place to ensure that [1] does not push up to jdk9/jdk9 without these follow up fixes in tow? We are already unfortunately hitting the problem in the opposite direction with broken jdk9/dev code being pulled into jdk9/hs and the hotspot group repos. :( Thanks, David > but this time in jdi libs. The fix is to restore the -export link flags > and remove the then redundant JNIEXPORT annotations in the code. I have > verified that this fixes the tests in question. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150497 > Webrev: http://cr.openjdk.java.net/~erikj/8150497/webrev.jdk.01/index.html > > > [1] JDK-8150203 > Incremental update > from build-infra project > [2] JDK-8150456 jdk 9 > nightly build fails on Windows 32 bit From joe.darcy at oracle.com Fri Feb 26 04:43:58 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Feb 2016 20:43:58 -0800 Subject: RFR: JDK-8150497: 32 jshell tests failed on Windows 32 bit In-Reply-To: <56CFD398.50403@oracle.com> References: <56CFBBA1.1090802@oracle.com> <56CFD398.50403@oracle.com> Message-ID: <56CFD80E.8010600@oracle.com> On 2/25/2016 8:24 PM, David Holmes wrote: > Hi Erik, > > On 26/02/2016 12:42 PM, Erik Joelsson wrote: >> Here is some more fallout from [1]. The same kind of issue as in [2], > > Is there anything in place to ensure that [1] does not push up to > jdk9/jdk9 without these follow up fixes in tow? We are already > unfortunately hitting the problem in the opposite direction with > broken jdk9/dev code being pulled into jdk9/hs and the hotspot group > repos. :( These failures are on the radar to be resolved before the snapshot is taken for the next dev -> master integration. If everything goes according to plan, the snapshot for a dev -> master integration is taken on Friday for the following week; if there is no suitable build (and these 32 tests failing would be a disqualification), then a snapshot on Monday can be taken. HTH, -Joe From jvanek at redhat.com Fri Feb 26 11:49:38 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 26 Feb 2016 12:49:38 +0100 Subject: Provide zipped javadoc archive from make In-Reply-To: <56CF3B11.2010001@oracle.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> <56CF1E43.5080000@oracle.com> <56CF3874.1060806@redhat.com> <56CF3B11.2010001@oracle.com> Message-ID: <56D03BD2.20109@redhat.com> On 02/25/2016 06:34 PM, Jonathan Gibbons wrote: > On 02/25/2016 09:23 AM, Jiri Vanek wrote: >> >> I must be missing something. Dozens? Of varius runs of javadoc? >> >> I thought that javadoc ending at the end in single drectory is one single javadoc for java. If >> you are referring to javadoc generated by "per module" then one jjoined zip is enough for me. > > > Jiri, > > If you accept the premise that javadoc writes one stylesheet.css file per run of javadoc, take a > look at the following list: Then my goal will be to crate a trget, which takes build/linux-x86_64-normal-server-release/images/docs/ and pack it to build/linux-x86_64-normal-server-release/images/javadoc.zip It should contains also the "smaller api" you are mentioning below? If not, then those should appear in this zip too. > > $ find build/linux-x86_64-normal-server-release/images/docs/ -name stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css > build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css > > The "main"/"Java SE" javadoc bundle that most are aware of is the shortest filename, in the middle > of the list, but there are lots of other smaller APIs that get their own doc bundle. You can get at > most of them in released doc sets through the top-level "brick wall" page, or by using your favorite > search engine. Hmm.. Do you have some? javadoc offline search is quite painful think. (Even with new search in 9, which seems to have some troubles on local filesystem). The best search engine I know is (unluckily) https://github.com/judovana/JavadocOfflineSearch > > -- Thanx a lot! J. From yasuenag at gmail.com Fri Feb 26 12:28:55 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 26 Feb 2016 21:28:55 +0900 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. Message-ID: <56D04507.5040607@gmail.com> Hi all, HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) are missing in appmodules.jimage . They should be contained to appmodules.jimage . I've uploaded a webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ Could you review it? Thanks, Yasumasa From erik.joelsson at oracle.com Fri Feb 26 16:59:39 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Feb 2016 08:59:39 -0800 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D04507.5040607@gmail.com> References: <56D04507.5040607@gmail.com> Message-ID: <56D0847B.8020306@oracle.com> Hello, Actually you only need this: erik at pilot:/localhome/hg/jdk9-dev$ hg diff diff -r c7be2a78c31b make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk +++ b/make/CompileJavaModules.gmk @@ -381,7 +381,7 @@ DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ FILES := $(wildcard $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ )) - jdk.hotspot.agent: $(COPY_SA_IMAGES) + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) endif ################################################################################ However, the real fix is to move the gifs out of the images dir so that they have the correct subdir relative to the classes dir in both the source and the output. Then we can remove this whole SetupCopyFiles construct and just add .gif to jdk.hotspot.agent_COPY. /Erik On 2016-02-26 04:28, Yasumasa Suenaga wrote: > Hi all, > > HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) > are missing in appmodules.jimage . > They should be contained to appmodules.jimage . > > I've uploaded a webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ > > Could you review it? > > > Thanks, > > Yasumasa From jonathan.gibbons at oracle.com Fri Feb 26 19:05:26 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 26 Feb 2016 11:05:26 -0800 Subject: Provide zipped javadoc archive from make In-Reply-To: <56D03BD2.20109@redhat.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> <56CF1E43.5080000@oracle.com> <56CF3874.1060806@redhat.com> <56CF3B11.2010001@oracle.com> <56D03BD2.20109@redhat.com> Message-ID: <56D0A1F6.7020906@oracle.com> On 02/26/2016 03:49 AM, Jiri Vanek wrote: > On 02/25/2016 06:34 PM, Jonathan Gibbons wrote: >> On 02/25/2016 09:23 AM, Jiri Vanek wrote: >>> >>> I must be missing something. Dozens? Of varius runs of javadoc? >>> >>> I thought that javadoc ending at the end in single drectory is one >>> single javadoc for java. If >>> you are referring to javadoc generated by "per module" then one >>> jjoined zip is enough for me. >> >> >> Jiri, >> >> If you accept the premise that javadoc writes one stylesheet.css >> file per run of javadoc, take a >> look at the following list: > > Then my goal will be to crate a trget, which takes > build/linux-x86_64-normal-server-release/images/docs/ > and pack it to > build/linux-x86_64-normal-server-release/images/javadoc.zip > > It should contains also the "smaller api" you are mentioning below? If > not, then those should appear in this zip too. >> >> $ find build/linux-x86_64-normal-server-release/images/docs/ -name >> stylesheet.css >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css >> build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css >> >> build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css >> >> >> The "main"/"Java SE" javadoc bundle that most are aware of is the >> shortest filename, in the middle >> of the list, but there are lots of other smaller APIs that get their >> own doc bundle. You can get at >> most of them in released doc sets through the top-level "brick wall" >> page, or by using your favorite >> search engine. > > Hmm.. Do you have some? javadoc offline search is quite painful > think. (Even with new search in 9, which seems to have some troubles > on local filesystem). The best search engine I know is (unluckily) > https://github.com/judovana/JavadocOfflineSearch The point of the preceding list was to say that each directory containing stylesheet.css is the root of a separate, distinct, javadoc bundle. So the smaller APIs that get their own bundle are precisely the ones given in the preceding list, other than the main javadoc bundle. The point of the comment about the brick wall and search engines was to indicate how most people will find these doc bundles in normal use, when they don't have a cheat sheet like the list above. As far as IDEs wanting to access javadoc bundles, I would expect that to make all the docs available, you would want to zip up *each* directory containing stylesheet.css given in the preceding list. If you just zip up the top API directory, sure, that will include all the files, but the reality is that the IDE will likely not have any way of knowing about the minor doc bundles in all jre/ and jdk/ directories and subdirectories. -- Jon >> >> -- > > > Thanx a lot! > J. From yasuenag at gmail.com Sat Feb 27 03:44:11 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 27 Feb 2016 12:44:11 +0900 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D0847B.8020306@oracle.com> References: <56D04507.5040607@gmail.com> <56D0847B.8020306@oracle.com> Message-ID: <56D11B8B.5080208@gmail.com> Hi Erik, Thanks! I've uploaded new webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/ > However, the real fix is to move the gifs out of the images dir so that > they have the correct subdir relative to the classes dir in both the > source and the output. Then we can remove this whole SetupCopyFiles > construct and just add .gif to jdk.hotspot.agent_COPY. Comments in CompileJavaModules.gmk are as below: ------------ ### Copy gif files # Special handling to copy gif files in images/toolbarButtonGraphics \ # -> classes/toolbarButtonGraphics. # These can't be handled by COPY to SetupJavaCompilation since they chop off # one directory level. ------------ According to them, I guess that our fix makes expected behavior. If we should fix as you say, I think that we work for it in another issue. Thanks, Yasumasa On 2016/02/27 1:59, Erik Joelsson wrote: > Hello, > > Actually you only need this: > > erik at pilot:/localhome/hg/jdk9-dev$ hg diff > diff -r c7be2a78c31b make/CompileJavaModules.gmk > --- a/make/CompileJavaModules.gmk > +++ b/make/CompileJavaModules.gmk > @@ -381,7 +381,7 @@ > DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ > FILES := $(wildcard > $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ > )) > - jdk.hotspot.agent: $(COPY_SA_IMAGES) > + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) > endif > > ################################################################################ > > However, the real fix is to move the gifs out of the images dir so that > they have the correct subdir relative to the classes dir in both the > source and the output. Then we can remove this whole SetupCopyFiles > construct and just add .gif to jdk.hotspot.agent_COPY. > > /Erik > > On 2016-02-26 04:28, Yasumasa Suenaga wrote: >> Hi all, >> >> HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) >> are missing in appmodules.jimage . >> They should be contained to appmodules.jimage . >> >> I've uploaded a webrev: >> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ >> >> Could you review it? >> >> >> Thanks, >> >> Yasumasa > > From erik.joelsson at oracle.com Mon Feb 29 08:45:08 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Feb 2016 09:45:08 +0100 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D11B8B.5080208@gmail.com> References: <56D04507.5040607@gmail.com> <56D0847B.8020306@oracle.com> <56D11B8B.5080208@gmail.com> Message-ID: <56D40514.9050003@oracle.com> On 2016-02-27 04:44, Yasumasa Suenaga wrote: > Hi Erik, > > Thanks! > I've uploaded new webrev. Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/ This looks ok to me. >> However, the real fix is to move the gifs out of the images dir so that >> they have the correct subdir relative to the classes dir in both the >> source and the output. Then we can remove this whole SetupCopyFiles >> construct and just add .gif to jdk.hotspot.agent_COPY. > Comments in CompileJavaModules.gmk are as below: > ------------ > ### Copy gif files > # Special handling to copy gif files in images/toolbarButtonGraphics \ > # -> classes/toolbarButtonGraphics. > # These can't be handled by COPY to SetupJavaCompilation since they chop off > # one directory level. > ------------ > > According to them, I guess that our fix makes expected behavior. > If we should fix as you say, I think that we work for it in another issue. Yes, I implemented that logic to work around the broken src layout. It's not intended, just sad. I'm just annoyed that they aren't cleaning up and fixing it. Then it wouldn't have broken when the main target in CompileJavaModules.gmk changes from "$(MODULE)" to "all". /Erik > > Thanks, > > Yasumasa > > > On 2016/02/27 1:59, Erik Joelsson wrote: >> Hello, >> >> Actually you only need this: >> >> erik at pilot:/localhome/hg/jdk9-dev$ hg diff >> diff -r c7be2a78c31b make/CompileJavaModules.gmk >> --- a/make/CompileJavaModules.gmk >> +++ b/make/CompileJavaModules.gmk >> @@ -381,7 +381,7 @@ >> DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ >> FILES := $(wildcard >> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ >> )) >> - jdk.hotspot.agent: $(COPY_SA_IMAGES) >> + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) >> endif >> >> ################################################################################ >> >> However, the real fix is to move the gifs out of the images dir so that >> they have the correct subdir relative to the classes dir in both the >> source and the output. Then we can remove this whole SetupCopyFiles >> construct and just add .gif to jdk.hotspot.agent_COPY. >> >> /Erik >> >> On 2016-02-26 04:28, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) >>> are missing in appmodules.jimage . >>> They should be contained to appmodules.jimage . >>> >>> I've uploaded a webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >> From dmitry.samersoff at oracle.com Mon Feb 29 08:52:33 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 29 Feb 2016 11:52:33 +0300 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D11B8B.5080208@gmail.com> References: <56D04507.5040607@gmail.com> <56D0847B.8020306@oracle.com> <56D11B8B.5080208@gmail.com> Message-ID: <56D406D1.9070806@oracle.com> Yasumasa, I think it's better to have a complete fix rather than yet another workaround. Could you move gif files to correct location and remove custom makefile logic? I'll sponsor the push then. -Dmitry On 2016-02-27 06:44, Yasumasa Suenaga wrote: > Hi Erik, > > Thanks! > I've uploaded new webrev. Could you review it? > http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/ > >> However, the real fix is to move the gifs out of the images dir so that >> they have the correct subdir relative to the classes dir in both the >> source and the output. Then we can remove this whole SetupCopyFiles >> construct and just add .gif to jdk.hotspot.agent_COPY. > > Comments in CompileJavaModules.gmk are as below: > ------------ > ### Copy gif files > # Special handling to copy gif files in images/toolbarButtonGraphics \ > # -> classes/toolbarButtonGraphics. > # These can't be handled by COPY to SetupJavaCompilation since they chop off > # one directory level. > ------------ > > According to them, I guess that our fix makes expected behavior. > If we should fix as you say, I think that we work for it in another issue. > > > Thanks, > > Yasumasa > > > On 2016/02/27 1:59, Erik Joelsson wrote: >> Hello, >> >> Actually you only need this: >> >> erik at pilot:/localhome/hg/jdk9-dev$ hg diff >> diff -r c7be2a78c31b make/CompileJavaModules.gmk >> --- a/make/CompileJavaModules.gmk >> +++ b/make/CompileJavaModules.gmk >> @@ -381,7 +381,7 @@ >> DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ >> FILES := $(wildcard >> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ >> )) >> - jdk.hotspot.agent: $(COPY_SA_IMAGES) >> + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) >> endif >> >> ################################################################################ >> >> However, the real fix is to move the gifs out of the images dir so that >> they have the correct subdir relative to the classes dir in both the >> source and the output. Then we can remove this whole SetupCopyFiles >> construct and just add .gif to jdk.hotspot.agent_COPY. >> >> /Erik >> >> On 2016-02-26 04:28, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) >>> are missing in appmodules.jimage . >>> They should be contained to appmodules.jimage . >>> >>> I've uploaded a webrev: >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ >>> >>> Could you review it? >>> >>> >>> Thanks, >>> >>> Yasumasa >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From erik.joelsson at oracle.com Mon Feb 29 10:19:50 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Feb 2016 11:19:50 +0100 Subject: RFR: JDK-8150822: Fix typo in JDK-8150201 Message-ID: <56D41B46.7000900@oracle.com> In JDK-8150201, some debug flags were corrected. In one of the overrides, the file name was misspelled so the debug flag correction is not in effect. Bug: https://bugs.openjdk.java.net/browse/JDK-8150822 Patch: diff -r 63a9e10565c4 make/solaris/makefiles/amd64.make --- a/make/solaris/makefiles/amd64.make +++ b/make/solaris/makefiles/amd64.make @@ -39,7 +39,7 @@ # of OPT_CFLAGS. Restore it here. ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) OPT_CFLAGS/generateOptoStub.o += -g0 -xs - OPT_CFLAGS/LinearScan.o += -g0 -xs + OPT_CFLAGS/c1_LinearScan.o += -g0 -xs endif /Erik From magnus.ihse.bursie at oracle.com Mon Feb 29 12:12:52 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 29 Feb 2016 13:12:52 +0100 Subject: RFR: JDK-8150822: Fix typo in JDK-8150201 In-Reply-To: <56D41B46.7000900@oracle.com> References: <56D41B46.7000900@oracle.com> Message-ID: <9B27630C-9DCF-42A8-9CBA-5C93EAFF2FA8@oracle.com> Looks good to me. /Magnus > 29 feb. 2016 kl. 11:19 skrev Erik Joelsson : > > In JDK-8150201, some debug flags were corrected. In one of the overrides, the file name was misspelled so the debug flag correction is not in effect. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150822 > > Patch: > diff -r 63a9e10565c4 make/solaris/makefiles/amd64.make > --- a/make/solaris/makefiles/amd64.make > +++ b/make/solaris/makefiles/amd64.make > @@ -39,7 +39,7 @@ > # of OPT_CFLAGS. Restore it here. > ifeq ($(ENABLE_FULL_DEBUG_SYMBOLS),1) > OPT_CFLAGS/generateOptoStub.o += -g0 -xs > - OPT_CFLAGS/LinearScan.o += -g0 -xs > + OPT_CFLAGS/c1_LinearScan.o += -g0 -xs > endif > > > > /Erik From volker.simonis at gmail.com Mon Feb 29 12:16:11 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 29 Feb 2016 13:16:11 +0100 Subject: Should we use '-fno-asynchronous-unwind-tables' to reduce the size of libjvm.so by 10 percent? Message-ID: Hi, We are currently building and linking the libjvm.so on Linux with -fnoexceptions because we currently don't use C++ exception handling in the HotSpot. Nevertheless, g++ generates unwind tables (i.e. .eh_frame sections) in the object files and shared libraries which can not be stripped from the binary. In the case of libjvm.so, these sections consume 10% of the whole library. It is possible to omit the creation of these sections by using the '-fno-asynchronous-unwind-tables' option during compilation and linking. Ive verified that this indeed reduces the size of libjvm.so by 10% on Linux/x86_64 for a product build: -rwxrwxr-x 1 simonis simonis 18798859 Feb 24 18:32 hotspot/linux_amd64_compiler2/product/libjvm.so -rwxrwxr-x 1 simonis simonis 17049867 Feb 25 18:12 hotspot_no_unwind/linux_amd64_compiler2/product/libjvm.so The gcc documentation mentions that the unwind information is used "for stack unwinding from asynchronous events (such as debugger or garbage collector)". But various references [1,2] also mention that using '-fno-asynchronous-unwind-tables' together with '-g' will force gcc to create this information in the debug sections of the object files (i.e. .debug_frame) which can easily be stripped from the object files and libraries. As we build the product version of the libjvm.so with '-g' anyway, I'd suggest to use '-fno-asynchronous-unwind-tables' to reduce its size. I've done some quick tests (debugging, creation of hs_err files) with a product version of libjvm.so which was build with '-fno-asynchronous-unwind-tables' and couldn't find any draw backs. I could observe that all the date from the current .eh_frame sections has bee moved to the .debug_frame sections in the stripped out data of the libjvm.debuginfo file. I've opened "8150828: Consider using '-fno-asynchronous-unwind-tables' to reduce the size of libjvm.so by 10 percent" to track this issue: https://bugs.openjdk.java.net/browse/JDK-8150828 and would be interested what others think about this "optimization"? The only reason for not using it I can currently think of is that we might have to switch exception handling on when we are integrating the new "JEP 281: HotSpot C++ Unit-Test Framework". Regards, Volker [1] http://stackoverflow.com/questions/26300819/why-gcc-compiled-c-program-needs-eh-frame-section [2] https://www.chromium.org/chromium-os/build/c-exception-support From yasuenag at gmail.com Mon Feb 29 13:26:02 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 29 Feb 2016 22:26:02 +0900 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D406D1.9070806@oracle.com> References: <56D04507.5040607@gmail.com> <56D0847B.8020306@oracle.com> <56D11B8B.5080208@gmail.com> <56D406D1.9070806@oracle.com> Message-ID: <56D446EA.4020808@gmail.com> Hi Dmitry, Erik, I've uploaded new webrev: hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/hotspot/ makefile: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/make/ > Could you move gif files to correct location and remove custom makefile > logic? I moved classes/images/toolbarButtonGraphics to classes/toolbarButtonGraphics . Could you review it? > I'll sponsor the push then. Thanks! Yasumasa On 2016/02/29 17:52, Dmitry Samersoff wrote: > Yasumasa, > > I think it's better to have a complete fix rather than yet another > workaround. > > Could you move gif files to correct location and remove custom makefile > logic? > > I'll sponsor the push then. > > -Dmitry > > On 2016-02-27 06:44, Yasumasa Suenaga wrote: >> Hi Erik, >> >> Thanks! >> I've uploaded new webrev. Could you review it? >> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/ >> >>> However, the real fix is to move the gifs out of the images dir so that >>> they have the correct subdir relative to the classes dir in both the >>> source and the output. Then we can remove this whole SetupCopyFiles >>> construct and just add .gif to jdk.hotspot.agent_COPY. >> >> Comments in CompileJavaModules.gmk are as below: >> ------------ >> ### Copy gif files >> # Special handling to copy gif files in images/toolbarButtonGraphics \ >> # -> classes/toolbarButtonGraphics. >> # These can't be handled by COPY to SetupJavaCompilation since they chop off >> # one directory level. >> ------------ >> >> According to them, I guess that our fix makes expected behavior. >> If we should fix as you say, I think that we work for it in another issue. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/02/27 1:59, Erik Joelsson wrote: >>> Hello, >>> >>> Actually you only need this: >>> >>> erik at pilot:/localhome/hg/jdk9-dev$ hg diff >>> diff -r c7be2a78c31b make/CompileJavaModules.gmk >>> --- a/make/CompileJavaModules.gmk >>> +++ b/make/CompileJavaModules.gmk >>> @@ -381,7 +381,7 @@ >>> DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ >>> FILES := $(wildcard >>> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ >>> )) >>> - jdk.hotspot.agent: $(COPY_SA_IMAGES) >>> + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) >>> endif >>> >>> ################################################################################ >>> >>> However, the real fix is to move the gifs out of the images dir so that >>> they have the correct subdir relative to the classes dir in both the >>> source and the output. Then we can remove this whole SetupCopyFiles >>> construct and just add .gif to jdk.hotspot.agent_COPY. >>> >>> /Erik >>> >>> On 2016-02-26 04:28, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) >>>> are missing in appmodules.jimage . >>>> They should be contained to appmodules.jimage . >>>> >>>> I've uploaded a webrev: >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ >>>> >>>> Could you review it? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>> >>> > > From dmitry.samersoff at oracle.com Mon Feb 29 13:28:09 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 29 Feb 2016 16:28:09 +0300 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D446EA.4020808@gmail.com> References: <56D04507.5040607@gmail.com> <56D0847B.8020306@oracle.com> <56D11B8B.5080208@gmail.com> <56D406D1.9070806@oracle.com> <56D446EA.4020808@gmail.com> Message-ID: <56D44769.1080407@oracle.com> Yasumasa, Looks good for me! -Dmitry On 2016-02-29 16:26, Yasumasa Suenaga wrote: > Hi Dmitry, Erik, > > I've uploaded new webrev: > > hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/hotspot/ > makefile: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/make/ > > >> Could you move gif files to correct location and remove custom makefile >> logic? > > I moved classes/images/toolbarButtonGraphics to classes/toolbarButtonGraphics . > Could you review it? > >> I'll sponsor the push then. > > Thanks! > > > Yasumasa > > > On 2016/02/29 17:52, Dmitry Samersoff wrote: >> Yasumasa, >> >> I think it's better to have a complete fix rather than yet another >> workaround. >> >> Could you move gif files to correct location and remove custom makefile >> logic? >> >> I'll sponsor the push then. >> >> -Dmitry >> >> On 2016-02-27 06:44, Yasumasa Suenaga wrote: >>> Hi Erik, >>> >>> Thanks! >>> I've uploaded new webrev. Could you review it? >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/ >>> >>>> However, the real fix is to move the gifs out of the images dir so that >>>> they have the correct subdir relative to the classes dir in both the >>>> source and the output. Then we can remove this whole SetupCopyFiles >>>> construct and just add .gif to jdk.hotspot.agent_COPY. >>> >>> Comments in CompileJavaModules.gmk are as below: >>> ------------ >>> ### Copy gif files >>> # Special handling to copy gif files in images/toolbarButtonGraphics \ >>> # -> classes/toolbarButtonGraphics. >>> # These can't be handled by COPY to SetupJavaCompilation since they chop off >>> # one directory level. >>> ------------ >>> >>> According to them, I guess that our fix makes expected behavior. >>> If we should fix as you say, I think that we work for it in another issue. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/02/27 1:59, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Actually you only need this: >>>> >>>> erik at pilot:/localhome/hg/jdk9-dev$ hg diff >>>> diff -r c7be2a78c31b make/CompileJavaModules.gmk >>>> --- a/make/CompileJavaModules.gmk >>>> +++ b/make/CompileJavaModules.gmk >>>> @@ -381,7 +381,7 @@ >>>> DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ >>>> FILES := $(wildcard >>>> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ >>>> )) >>>> - jdk.hotspot.agent: $(COPY_SA_IMAGES) >>>> + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) >>>> endif >>>> >>>> ################################################################################ >>>> >>>> However, the real fix is to move the gifs out of the images dir so that >>>> they have the correct subdir relative to the classes dir in both the >>>> source and the output. Then we can remove this whole SetupCopyFiles >>>> construct and just add .gif to jdk.hotspot.agent_COPY. >>>> >>>> /Erik >>>> >>>> On 2016-02-26 04:28, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) >>>>> are missing in appmodules.jimage . >>>>> They should be contained to appmodules.jimage . >>>>> >>>>> I've uploaded a webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ >>>>> >>>>> Could you review it? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From erik.joelsson at oracle.com Mon Feb 29 13:39:28 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Feb 2016 14:39:28 +0100 Subject: RFR: JDK-8150723: HSDB toolbar icons are missing. In-Reply-To: <56D44769.1080407@oracle.com> References: <56D04507.5040607@gmail.com> <56D0847B.8020306@oracle.com> <56D11B8B.5080208@gmail.com> <56D406D1.9070806@oracle.com> <56D446EA.4020808@gmail.com> <56D44769.1080407@oracle.com> Message-ID: <56D44A10.3050209@oracle.com> Looks correct to me. Thanks for doing this! /Erik On 2016-02-29 14:28, Dmitry Samersoff wrote: > Yasumasa, > > Looks good for me! > > -Dmitry > > > On 2016-02-29 16:26, Yasumasa Suenaga wrote: >> Hi Dmitry, Erik, >> >> I've uploaded new webrev: >> >> hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/hotspot/ >> makefile: http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.02/make/ >> >> >>> Could you move gif files to correct location and remove custom makefile >>> logic? >> I moved classes/images/toolbarButtonGraphics to classes/toolbarButtonGraphics . >> Could you review it? >> >>> I'll sponsor the push then. >> Thanks! >> >> >> Yasumasa >> >> >> On 2016/02/29 17:52, Dmitry Samersoff wrote: >>> Yasumasa, >>> >>> I think it's better to have a complete fix rather than yet another >>> workaround. >>> >>> Could you move gif files to correct location and remove custom makefile >>> logic? >>> >>> I'll sponsor the push then. >>> >>> -Dmitry >>> >>> On 2016-02-27 06:44, Yasumasa Suenaga wrote: >>>> Hi Erik, >>>> >>>> Thanks! >>>> I've uploaded new webrev. Could you review it? >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.01/ >>>> >>>>> However, the real fix is to move the gifs out of the images dir so that >>>>> they have the correct subdir relative to the classes dir in both the >>>>> source and the output. Then we can remove this whole SetupCopyFiles >>>>> construct and just add .gif to jdk.hotspot.agent_COPY. >>>> Comments in CompileJavaModules.gmk are as below: >>>> ------------ >>>> ### Copy gif files >>>> # Special handling to copy gif files in images/toolbarButtonGraphics \ >>>> # -> classes/toolbarButtonGraphics. >>>> # These can't be handled by COPY to SetupJavaCompilation since they chop off >>>> # one directory level. >>>> ------------ >>>> >>>> According to them, I guess that our fix makes expected behavior. >>>> If we should fix as you say, I think that we work for it in another issue. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/02/27 1:59, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Actually you only need this: >>>>> >>>>> erik at pilot:/localhome/hg/jdk9-dev$ hg diff >>>>> diff -r c7be2a78c31b make/CompileJavaModules.gmk >>>>> --- a/make/CompileJavaModules.gmk >>>>> +++ b/make/CompileJavaModules.gmk >>>>> @@ -381,7 +381,7 @@ >>>>> DEST := $(JDK_OUTPUTDIR)/modules/$(MODULE), \ >>>>> FILES := $(wildcard >>>>> $(HOTSPOT_TOPDIR)/src/jdk.hotspot.agent/share/classes/images/*/*/*.gif), \ >>>>> )) >>>>> - jdk.hotspot.agent: $(COPY_SA_IMAGES) >>>>> + jdk.hotspot.agent_COPY_EXTRA += $(COPY_SA_IMAGES) >>>>> endif >>>>> >>>>> ################################################################################ >>>>> >>>>> However, the real fix is to move the gifs out of the images dir so that >>>>> they have the correct subdir relative to the classes dir in both the >>>>> source and the output. Then we can remove this whole SetupCopyFiles >>>>> construct and just add .gif to jdk.hotspot.agent_COPY. >>>>> >>>>> /Erik >>>>> >>>>> On 2016-02-26 04:28, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> HSDB toolbar icons (hotspot/src/jdk.hotspot.agent/share/classes/images/toolbarButtonGraphics) >>>>>> are missing in appmodules.jimage . >>>>>> They should be contained to appmodules.jimage . >>>>>> >>>>>> I've uploaded a webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8150723/webrev.00/ >>>>>> >>>>>> Could you review it? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>> >>> > From jvanek at redhat.com Mon Feb 29 15:24:03 2016 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 29 Feb 2016 16:24:03 +0100 Subject: Provide zipped javadoc archive from make In-Reply-To: <56D0A1F6.7020906@oracle.com> References: <56CEE465.40107@redhat.com> <56CF14A8.6040209@oracle.com> <56CF1E43.5080000@oracle.com> <56CF3874.1060806@redhat.com> <56CF3B11.2010001@oracle.com> <56D03BD2.20109@redhat.com> <56D0A1F6.7020906@oracle.com> Message-ID: <56D46293.3020102@redhat.com> On 02/26/2016 08:05 PM, Jonathan Gibbons wrote: > On 02/26/2016 03:49 AM, Jiri Vanek wrote: >> On 02/25/2016 06:34 PM, Jonathan Gibbons wrote: >>> On 02/25/2016 09:23 AM, Jiri Vanek wrote: >>>> >>>> I must be missing something. Dozens? Of varius runs of javadoc? >>>> >>>> I thought that javadoc ending at the end in single drectory is one single javadoc for java. If >>>> you are referring to javadoc generated by "per module" then one jjoined zip is enough for me. >>> >>> >>> Jiri, >>> >>> If you accept the premise that javadoc writes one stylesheet.css file per run of javadoc, take a >>> look at the following list: >> >> Then my goal will be to crate a trget, which takes >> build/linux-x86_64-normal-server-release/images/docs/ >> and pack it to >> build/linux-x86_64-normal-server-release/images/javadoc.zip >> >> It should contains also the "smaller api" you are mentioning below? If not, then those should >> appear in this zip too. >>> >>> $ find build/linux-x86_64-normal-server-release/images/docs/ -name stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/dynalink/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/attach/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javac/tree/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/jconsole/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/jpda/jdi/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/doclet/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/doclet/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/javadoc/old/taglet/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jdk/api/nashorn/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/api/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/nio/sctp/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/plugin/dom/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jaas/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/security/smartcardio/spec/stylesheet.css >>> >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/security/jgss/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/management/extension/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/net/httpserver/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/net/socketoptions/spec/stylesheet.css >>> build/linux-x86_64-normal-server-release/images/docs/jre/api/accessibility/jaccess/spec/stylesheet.css >>> >>> >>> The "main"/"Java SE" javadoc bundle that most are aware of is the shortest filename, in the middle >>> of the list, but there are lots of other smaller APIs that get their own doc bundle. You can get at >>> most of them in released doc sets through the top-level "brick wall" page, or by using your favorite >>> search engine. >> >> Hmm.. Do you have some? javadoc offline search is quite painful think. (Even with new search in >> 9, which seems to have some troubles on local filesystem). The best search engine I know is >> (unluckily) https://github.com/judovana/JavadocOfflineSearch > > The point of the preceding list was to say that each directory containing stylesheet.css is the root > of a separate, distinct, javadoc bundle. So the smaller APIs that get their own bundle are > precisely the ones given in the preceding list, other than the main javadoc bundle. > > The point of the comment about the brick wall and search engines was to indicate how most people > will find these doc bundles in normal use, when they don't have a cheat sheet like the list above. yes I got that. But Then this compressed shattered javadoc needs more thoughts. What is expected format of distribution? I can imagine: web accessible, unapcked "all docs" and "zipepd "all docs". But never several zips, or several directories. What is what I'm missing behind this effort to deliver javadocs per-module? > > As far as IDEs wanting to access javadoc bundles, I would expect that to make all the docs > available, you would want to zip up *each* directory containing stylesheet.css given in the > preceding list. If you just zip up the top API directory, sure, that will include all the files, but > the reality is that the IDE will likely not have any way of knowing about the minor doc bundles in > all jre/ and jdk/ directories and subdirectories. Indeed, when you pack top level javadoc directroy as top level of archive (so javadco will become zipped1.zip!javadoc) then indeed, Netbeasn refuse to load it whole 9just few parts) However when you pack it that content of javadoc will be the top of the archive (zipped2.zip!{api,jdk,jre,platform}) then NB loads it fine. If even this is wrong, then as last approach is really to restructuralise docs after theirs generation/before zipping to structure where top level directory will the "one with style" dynalink/stylesheet.css spec/stylesheet.css tree/stylesheet.css spec/stylesheet.css jdi/stylesheet.css doclet/stylesheet.css nashorn/stylesheet.css api/stylesheet.css spec/stylesheet.css dom/stylesheet.css spec/stylesheet.css spec/stylesheet.css ... But looking to the occurences of "spec" There is something wrong with those assumptions :) As for indexing and viewing tools - They works fine with both zipepd1 and zipped2 (but there is not much to try) Seeing the impact of packaging, I think it is one more +1 to add this packing target, so JDK's javadoc is pacaked in known, "laodable" way. Thanx! J. > > -- Jon > > >>> >>> -- >> >> >> Thanx a lot! >> J. >