From vladimir.kozlov at oracle.com Tue Nov 1 00:52:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 31 Oct 2016 17:52:56 -0700 Subject: [9] RFR(M) 8166416: [AOT] Integrate JDK build changes and launcher 'jaotc' for AOT compiler In-Reply-To: <7bb59402-ecba-692b-9718-16414fe17efd@redhat.com> References: <58114E0C.107@oracle.com> <58124A47.5010604@oracle.com> <581304B6.7030804@oracle.com> <9f52669e-75fe-7139-78cb-d28ae1aff0a7@redhat.com> <58137448.6040205@oracle.com> <23d2851f-027d-f142-e4d1-8c42e4a011f2@redhat.com> <7bb59402-ecba-692b-9718-16414fe17efd@redhat.com> Message-ID: <94ac122b-6ff8-d038-f0c5-fb8011a661dd@oracle.com> Thank you, Andrew I fixed compiledCI_aarch64.cpp and updated webrev in place. Thanks, Vladimir On 10/31/16 8:35 AM, Andrew Dinn wrote: > Hi Vladimir, > > On 31/10/16 11:38, Andrew Dinn wrote: >> On 28/10/16 16:52, Vladimir Kozlov wrote: >>> Thank you, Andrew, for verifying that build changes do not break AArch64. >>> But it would be nice if you can also apply Hotspot changes (revert >>> hs.make.webrev changes before that since hs.webrev have them): >>> >>> http://cr.openjdk.java.net/~kvn/aot/hs.webrev/ >>> >>> and jaotc sources (which are located in Hotspot repo): >>> >>> http://cr.openjdk.java.net/~kvn/aot/jaotc.webrev/ >> >> I tried this and found two missing changes to compiledIC_aarch64.cpp >> (basically a missing arg in each of two class to find_stub() -- see >> below for diff). >> >> However, I then ran into the problem Volker saw: >> >> Compiling 15 files for jdk.attach >> /home/adinn/openjdk/hs/hotspot/src/jdk.vm.ci/share/classes/module-info.java:40: >> error: module not found: jdk.vm.compiler >> jdk.vm.compiler; >> ^ >> /home/adinn/openjdk/hs/hotspot/src/jdk.vm.ci/share/classes/module-info.java:43: >> error: module not found: jdk.vm.compiler >> jdk.vm.compiler; >> >> . . . >> >> I assume fixing this second problem requires me to clone the graal-core >> repo into my tree and the apply the graal.webrev patch then rebuild. > > I cloned and patched the graal-core/graal tree and then copied it into > my hotspot space as follows > > $ cp /path/to/graal-core/graal \ > /otherpath/to/hs/hotspot/src/share/classes/jdk.vm.compiler > > With this and the extra tweaks to compiledCI_aarch64.cpp mentioned in > the previous reply I managed to build a slowdebug release which > successfully ran 'java Hello' and 'javac Hello.java'. > > Andrew Haley is currently trying to get Graal itself to run on AArch64. > So, this is probably good enough for now to confirm the acceptability of > the hs and jaotc change sets. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From erik.joelsson at oracle.com Tue Nov 1 09:27:45 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Nov 2016 10:27:45 +0100 Subject: RfR JDK-8167213 Move include/bridge/AccessBridgeCalls.c to the source directory In-Reply-To: <01aa9716-c1a7-8690-765c-de8583ba1bd1@oracle.com> References: <75ed1c5e-a595-7251-59ae-e124c54de735@oracle.com> <2df1cd94-bcad-4629-bd86-513da156b875@oracle.com> <2d5c916f-fef2-5dfd-08ca-1b135ed9737c@oracle.com> <6cd646da-99a6-002c-c98a-f82a305046de@oracle.com> <6c0528b7-17c5-3b01-a82c-8dd546485801@oracle.com> <63082BA6-907F-42D3-B7B3-068EE7269125@oracle.com> <66b7f262-b523-d722-beef-25ea5e702737@oracle.com> <0632C661-D179-4CE3-A49F-C1D5A4D562ED@oracle.com> <81c655fa-f668-c990-dd2d-ad1944681ac3@oracle.com> <7EA7214A-E72A-4D22-9A7D-3E144684B8C7@oracle.com> <5813BC1E.1030809@oracle.com> <01aa9716-c1a7-8690-765c-de8583ba1bd1@oracle.com> Message-ID: <342460f6-1faf-3891-0dbb-01b8c445525e@oracle.com> Looks good. /Erik On 2016-10-31 15:36, Pete Brunet wrote: > > On 10/28/16 8:14 PM, Mandy Chung wrote: >>> On Oct 28, 2016, at 1:59 PM, Philip Race wrote: >>> >>> If it is not in the image then there is no point in the file existing. >>> Maybe this could just be a comment at the top of the include file. >>> >> This works for me. > Updated: > http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.09/ >> Mandy >> >>> -phil. >>> >>> On 10/28/16, 12:42 PM, Mandy Chung wrote: >>>>> On Oct 28, 2016, at 11:32 AM, Pete Brunet wrote: >>>>> >>>>> Hi Mandy, That simplifies things. The new patch is at: >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8167213/webrev.08/ >>>> Looks better. >>>> >>>> I only notice now that the readme.html is in the include directory. That should be in the documentation as you proposed earlier. I don?t think it should be copied to the image. >>>> >>>> Mandy >>>> From erik.joelsson at oracle.com Tue Nov 1 09:46:05 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Nov 2016 10:46:05 +0100 Subject: RFR: JDK-8168982: Missing dependency for docs-copy In-Reply-To: <65AFD988-9B96-453B-AFF1-84DBC7FC2990@oracle.com> References: <8C1F675C-37C2-492F-A1F4-9D7F86670739@oracle.com> <65AFD988-9B96-453B-AFF1-84DBC7FC2990@oracle.com> Message-ID: <0d42d48d-7586-1312-ba03-adf02abb3069@oracle.com> Hello, Magnus is correct. When rewriting the docs build in JDK-8168772, a dependency was missed on the top level. The docs-copy target needs jdk.jdi-gensrc as a prerequisite since that target generates support/javadoc/platform/jpda/jdwp/jdwp-protocol.html, which is used by docs-copy. Bug: https://bugs.openjdk.java.net/browse/JDK-8168982 Patch: diff -r a327b728bbe7 make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -683,7 +683,8 @@ docs-javadoc: $(GENSRC_TARGETS) rmic - docs-copy: hotspot + # The gensrc step for jdk.jdi creates an html file that is used by docs-copy. + docs-copy: hotspot jdk.jdi-gensrc docs-zip: docs-javadoc docs-copy Verified by doing: $ make clean $ make docs-copy /Erik On 2016-11-01 00:27, Lance Andersen wrote: > In case this bites anyone else, the workaround below will keep you going :-) > > Thank you again Magnus > > Best > Lance >> On Oct 31, 2016, at 2:09 PM, Magnus Ihse Bursie wrote: >> >> Lance, >> >> This is most likely due to a missed dependency in the recent Javadoc refactoring, which is triggered on your build platform. >> >> A workaround for you right now is to do 'make jdk.jdi' first, which will make sure the Javadoc stage later will succeed. >> >> Sorry for the inconvenience. :-( >> >> /Magnus >> >>> 31 okt. 2016 kl. 19:07 skrev Lance Andersen : >>> >>> Hi, >>> >>> I just pulled the latest JDK 9 source (open and closed) and can no longer build as I am getting the following error: >>> >>> make[3]: *** No rule to make target `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/gensrc/jdk.jdi/jdwp-protocol.html', needed by `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/javadoc/platform/jpda/jdwp/jdwp-protocol.html'. Stop. >>> make[2]: *** [docs-copy] Error 2 >>> >>> >>> >>> I did a make clean prior to make all. >>> >>> Anyone else encounter this? >>> >>> >>> Thank you in advance? >>> >>> Best >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From tim.bell at oracle.com Tue Nov 1 14:32:29 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 1 Nov 2016 07:32:29 -0700 Subject: RFR: JDK-8168982: Missing dependency for docs-copy In-Reply-To: <0d42d48d-7586-1312-ba03-adf02abb3069@oracle.com> References: <8C1F675C-37C2-492F-A1F4-9D7F86670739@oracle.com> <65AFD988-9B96-453B-AFF1-84DBC7FC2990@oracle.com> <0d42d48d-7586-1312-ba03-adf02abb3069@oracle.com> Message-ID: Erik: Looks good. Tim > Magnus is correct. When rewriting the docs build in JDK-8168772, a > dependency was missed on the top level. The docs-copy target needs > jdk.jdi-gensrc as a prerequisite since that target generates > support/javadoc/platform/jpda/jdwp/jdwp-protocol.html, which is used by > docs-copy. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168982 > > Patch: > > diff -r a327b728bbe7 make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -683,7 +683,8 @@ > > docs-javadoc: $(GENSRC_TARGETS) rmic > > - docs-copy: hotspot > + # The gensrc step for jdk.jdi creates an html file that is used by > docs-copy. > + docs-copy: hotspot jdk.jdi-gensrc > > docs-zip: docs-javadoc docs-copy > > Verified by doing: > > $ make clean > $ make docs-copy > > /Erik > > On 2016-11-01 00:27, Lance Andersen wrote: >> In case this bites anyone else, the workaround below will keep you >> going :-) >> >> Thank you again Magnus >> >> Best >> Lance >>> On Oct 31, 2016, at 2:09 PM, Magnus Ihse Bursie >>> wrote: >>> >>> Lance, >>> >>> This is most likely due to a missed dependency in the recent Javadoc >>> refactoring, which is triggered on your build platform. >>> >>> A workaround for you right now is to do 'make jdk.jdi' first, which >>> will make sure the Javadoc stage later will succeed. >>> >>> Sorry for the inconvenience. :-( >>> >>> /Magnus >>> >>>> 31 okt. 2016 kl. 19:07 skrev Lance Andersen >>>> : >>>> >>>> Hi, >>>> >>>> I just pulled the latest JDK 9 source (open and closed) and can no >>>> longer build as I am getting the following error: >>>> >>>> make[3]: *** No rule to make target >>>> `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/gensrc/jdk.jdi/jdwp-protocol.html', >>>> needed by >>>> `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/javadoc/platform/jpda/jdwp/jdwp-protocol.html'. >>>> Stop. >>>> make[2]: *** [docs-copy] Error 2 >>>> >>>> >>>> >>>> I did a make clean prior to make all. >>>> >>>> Anyone else encounter this? >>>> >>>> >>>> Thank you in advance? >>>> >>>> Best >>>> Lance >>>> >>>> >>>> >>>> Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From magnus.ihse.bursie at oracle.com Tue Nov 1 16:05:16 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 1 Nov 2016 18:05:16 +0200 Subject: RFR: JDK-8168982: Missing dependency for docs-copy In-Reply-To: <0d42d48d-7586-1312-ba03-adf02abb3069@oracle.com> References: <8C1F675C-37C2-492F-A1F4-9D7F86670739@oracle.com> <65AFD988-9B96-453B-AFF1-84DBC7FC2990@oracle.com> <0d42d48d-7586-1312-ba03-adf02abb3069@oracle.com> Message-ID: Looks good to me. /Magnus > 1 nov. 2016 kl. 11:46 skrev Erik Joelsson : > > Hello, > > Magnus is correct. When rewriting the docs build in JDK-8168772, a dependency was missed on the top level. The docs-copy target needs jdk.jdi-gensrc as a prerequisite since that target generates support/javadoc/platform/jpda/jdwp/jdwp-protocol.html, which is used by docs-copy. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168982 > > Patch: > > diff -r a327b728bbe7 make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -683,7 +683,8 @@ > > docs-javadoc: $(GENSRC_TARGETS) rmic > > - docs-copy: hotspot > + # The gensrc step for jdk.jdi creates an html file that is used by docs-copy. > + docs-copy: hotspot jdk.jdi-gensrc > > docs-zip: docs-javadoc docs-copy > > Verified by doing: > > $ make clean > $ make docs-copy > > /Erik > >> On 2016-11-01 00:27, Lance Andersen wrote: >> In case this bites anyone else, the workaround below will keep you going :-) >> >> Thank you again Magnus >> >> Best >> Lance >>> On Oct 31, 2016, at 2:09 PM, Magnus Ihse Bursie wrote: >>> >>> Lance, >>> >>> This is most likely due to a missed dependency in the recent Javadoc refactoring, which is triggered on your build platform. >>> >>> A workaround for you right now is to do 'make jdk.jdi' first, which will make sure the Javadoc stage later will succeed. >>> >>> Sorry for the inconvenience. :-( >>> >>> /Magnus >>> >>>> 31 okt. 2016 kl. 19:07 skrev Lance Andersen : >>>> >>>> Hi, >>>> >>>> I just pulled the latest JDK 9 source (open and closed) and can no longer build as I am getting the following error: >>>> >>>> make[3]: *** No rule to make target `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/gensrc/jdk.jdi/jdwp-protocol.html', needed by `/Users/ljanders/Documents/hg-workspaces/openjdk9/modular-dev/build/macosx-x86_64-normal-server-release/support/javadoc/platform/jpda/jdwp/jdwp-protocol.html'. Stop. >>>> make[2]: *** [docs-copy] Error 2 >>>> >>>> >>>> >>>> I did a make clean prior to make all. >>>> >>>> Anyone else encounter this? >>>> >>>> >>>> Thank you in advance? >>>> >>>> Best >>>> Lance >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com > From erik.joelsson at oracle.com Tue Nov 1 16:22:29 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Nov 2016 17:22:29 +0100 Subject: RFR: JDK-8063154: Checked in jvmti.h not in sync with generated jvmti.h Message-ID: Hello, The header file jvmti.h is generated in the hotspot build. There is also a copy of this file in the jdk repository which is the one that is actually included in the jdk image. This patch removes the copy and uses the generated file instead. JDK-8147943 fixed the generated file so that it has the correct license header, making the files equivalent at this time, so this change is not changing the build output. Bug: https://bugs.openjdk.java.net/browse/JDK-8063154 Webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.01/ /Erik From erik.joelsson at oracle.com Tue Nov 1 16:56:34 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 1 Nov 2016 17:56:34 +0100 Subject: RFR: JDK-8063154: Checked in jvmti.h not in sync with generated jvmti.h In-Reply-To: References: Message-ID: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> New webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.02/ I had not managed to revert all changes from another patch. /Erik On 2016-11-01 17:22, Erik Joelsson wrote: > Hello, > > The header file jvmti.h is generated in the hotspot build. There is > also a copy of this file in the jdk repository which is the one that > is actually included in the jdk image. This patch removes the copy and > uses the generated file instead. JDK-8147943 fixed the generated file > so that it has the correct license header, making the files equivalent > at this time, so this change is not changing the build output. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8063154 > > Webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.01/ > > /Erik > From tim.bell at oracle.com Tue Nov 1 18:38:14 2016 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 1 Nov 2016 11:38:14 -0700 Subject: RFR: JDK-8063154: Checked in jvmti.h not in sync with generated jvmti.h In-Reply-To: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> References: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> Message-ID: Erik: > New webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.02/ > > I had not managed to revert all changes from another patch. > > /Erik > > > On 2016-11-01 17:22, Erik Joelsson wrote: >> Hello, >> >> The header file jvmti.h is generated in the hotspot build. There is >> also a copy of this file in the jdk repository which is the one that >> is actually included in the jdk image. This patch removes the copy and >> uses the generated file instead. JDK-8147943 fixed the generated file >> so that it has the correct license header, making the files equivalent >> at this time, so this change is not changing the build output. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8063154 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.01/ Looks good. Approved. It is nice to get down to one copy of jvmti.h. Tim From ajit.ghaisas at oracle.com Wed Nov 2 07:01:13 2016 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 2 Nov 2016 00:01:13 -0700 (PDT) Subject: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt In-Reply-To: <7de3eaf1-f9b3-a8be-d409-620a1e0ad2b3@oracle.com> References: <7de3eaf1-f9b3-a8be-d409-620a1e0ad2b3@oracle.com> Message-ID: <9afc5079-bd65-42ba-ba94-c3045ae33a4b@default> Can I get another +1 for this fix? Regards, Ajit -----Original Message----- From: Erik Joelsson Sent: Thursday, October 27, 2016 3:30 PM To: Ajit Ghaisas; build-dev at openjdk.java.net; awt-dev at openjdk.java.net Subject: Re: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt Looks good. /Erik On 2016-10-27 11:02, Ajit Ghaisas wrote: > Hi, > > > > Fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8165232"JDK-8165232 has fixed the 'deprecated' warnings from libawt_xawt. > > Now, only removing warning suppression from makefile remains. This webrev does it. > > > > http://cr.openjdk.java.net/~aghaisas/8160146/webrev.0/ > > > > I have run JPRT and builds are successful. > > > > Request you to review. > > > > Regards, > > Ajit > > From serguei.spitsyn at oracle.com Wed Nov 2 13:27:30 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 2 Nov 2016 09:27:30 -0400 Subject: RFR: JDK-8063154: Checked in jvmti.h not in sync with generated jvmti.h In-Reply-To: References: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> Message-ID: <63867662-ed60-081d-a96e-fc5e2eecfb6b@oracle.com> Hi Erik +1 to what Tim said. Thank you a lot for fixing this issue! Thanks, Serguei On 11/1/16 14:38, Tim Bell wrote: > Erik: > >> New webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.02/ >> >> I had not managed to revert all changes from another patch. >> >> /Erik >> >> >> On 2016-11-01 17:22, Erik Joelsson wrote: >>> Hello, >>> >>> The header file jvmti.h is generated in the hotspot build. There is >>> also a copy of this file in the jdk repository which is the one that >>> is actually included in the jdk image. This patch removes the copy and >>> uses the generated file instead. JDK-8147943 fixed the generated file >>> so that it has the correct license header, making the files equivalent >>> at this time, so this change is not changing the build output. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8063154 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.01/ > > Looks good. Approved. It is nice to get down to one copy of jvmti.h. > > Tim > > From erik.joelsson at oracle.com Wed Nov 2 16:55:34 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Nov 2016 17:55:34 +0100 Subject: RFR: JDK-8168108: lib/classlist should be packaged in java.base.jmod Message-ID: This patch changes how the dynamically generated lib/classlist is packaged. We already create an interim-image from java.base and java.logging to generate the classlist during the build. We then copy it into the jdk and jre images using makefile logic after jlinking those images. With this patch, lib/classlist is instead included in java.base.jmod. To achieve this, I have introduced the concept of interim jmods for the jmods used to create the interim-image. These can be built explicitly from the top level using targets -interim-jmod. It adds a little bit of build time, but it's hardly noticeable. Bug: https://bugs.openjdk.java.net/browse/JDK-8168108 Webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.01/ /Erik From mandy.chung at oracle.com Wed Nov 2 17:52:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 2 Nov 2016 10:52:18 -0700 Subject: RFR: JDK-8168108: lib/classlist should be packaged in java.base.jmod In-Reply-To: References: Message-ID: > On Nov 2, 2016, at 9:55 AM, Erik Joelsson wrote: > > This patch changes how the dynamically generated lib/classlist is packaged. We already create an interim-image from java.base and java.logging to generate the classlist during the build. We then copy it into the jdk and jre images using makefile logic after jlinking those images. With this patch, lib/classlist is instead included in java.base.jmod. > > To achieve this, I have introduced the concept of interim jmods for the jmods used to create the interim-image. These can be built explicitly from the top level using targets -interim-jmod. It adds a little bit of build time, but it's hardly noticeable. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168108 > > Webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.01/ I like the interim jmods idea. The solution is clean. jdk/make/GenerateClasslist.gmk 62 $(call MakeDir, $(@D) $(SUPPORT_OUTPUTDIR)/classlist) Is the directory $(SUPPORT_OUTPUTDIR)/classlist needed? I can?t tell why this line needs to be changed. 63 $(call LogInfo, Generating lib/classlist) It might be better to print $(CLASSLIST_FILE) in the log instead? Otherwise, looks fine. Mandy From Sergey.Bylokhov at oracle.com Thu Nov 3 10:11:35 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 3 Nov 2016 13:11:35 +0300 Subject: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt In-Reply-To: <9afc5079-bd65-42ba-ba94-c3045ae33a4b@default> References: <7de3eaf1-f9b3-a8be-d409-620a1e0ad2b3@oracle.com> <9afc5079-bd65-42ba-ba94-c3045ae33a4b@default> Message-ID: <4e5f8c9c-c6c0-ef94-2855-bbcfc56da9be@oracle.com> On 02.11.16 10:01, Ajit Ghaisas wrote: > Can I get another +1 for this fix? +1 > > Regards, > Ajit > > -----Original Message----- > From: Erik Joelsson > Sent: Thursday, October 27, 2016 3:30 PM > To: Ajit Ghaisas; build-dev at openjdk.java.net; awt-dev at openjdk.java.net > Subject: Re: Fix for JDK-8160146 : Resolve disabled GCC warning 'deprecated-declarations' for libawt_xawt > > Looks good. > > /Erik > > > On 2016-10-27 11:02, Ajit Ghaisas wrote: >> Hi, >> >> >> >> Fix of HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8165232"JDK-8165232 has fixed the 'deprecated' warnings from libawt_xawt. >> >> Now, only removing warning suppression from makefile remains. This webrev does it. >> >> >> >> http://cr.openjdk.java.net/~aghaisas/8160146/webrev.0/ >> >> >> >> I have run JPRT and builds are successful. >> >> >> >> Request you to review. >> >> >> >> Regards, >> >> Ajit >> >> > -- Best regards, Sergey. From erik.joelsson at oracle.com Thu Nov 3 12:01:59 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Nov 2016 13:01:59 +0100 Subject: RFR: JDK-8168108: lib/classlist should be packaged in java.base.jmod In-Reply-To: References: Message-ID: <12bbbeb4-b6ba-dc7d-78bc-28c2ec756195@oracle.com> Hello, New webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.02/ On 2016-11-02 18:52, Mandy Chung wrote: >> On Nov 2, 2016, at 9:55 AM, Erik Joelsson wrote: >> >> This patch changes how the dynamically generated lib/classlist is packaged. We already create an interim-image from java.base and java.logging to generate the classlist during the build. We then copy it into the jdk and jre images using makefile logic after jlinking those images. With this patch, lib/classlist is instead included in java.base.jmod. >> >> To achieve this, I have introduced the concept of interim jmods for the jmods used to create the interim-image. These can be built explicitly from the top level using targets -interim-jmod. It adds a little bit of build time, but it's hardly noticeable. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168108 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.01/ > I like the interim jmods idea. The solution is clean. > > jdk/make/GenerateClasslist.gmk > 62 $(call MakeDir, $(@D) $(SUPPORT_OUTPUTDIR)/classlist) > > Is the directory $(SUPPORT_OUTPUTDIR)/classlist needed? I can?t tell why this line needs to be changed. Yes it was, since jli_trace.out is also generated by this target. I realize this becomes a bit convoluted so renamed the output dir, the makefile and the top level target to reflect that more things than classlist are generated here. I fixed the make rules so that both the classlist and jli_trace.out works correctly if either is removed before a rebuild. > > 63 $(call LogInfo, Generating lib/classlist) > > It might be better to print $(CLASSLIST_FILE) in the log instead? Fixed the log messages. /Erik > Otherwise, looks fine. > > Mandy From erik.joelsson at oracle.com Thu Nov 3 14:32:05 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Nov 2016 15:32:05 +0100 Subject: RFR: JDK-8160491: tar.gz bundles missing files containing $ Message-ID: The build logic for tar.gz bundles cannot handle files containing $. For the Oracle internal docs bundle, this is a problem since there are example inner classes included. Escaping of $ is always a pain point when working with make. After having investigated this quite thoroughly I have found what I think is the best solution. What happens here is something like this: LIST_OF_FILES := $(some find expression creating a list of files) $(eval $(call SomeMacro, FOO, \ FILES := $(LIST_OF_FILES), \ ... \ )) If LIST_OF_FILES contains a file with a $, that $ will get eaten by the $(eval). When we supply arguments to such macros inline, we currently have to escape them two times like this (in order to get EXCLUDES to contain foo$bar): $(eval $(call SomeMacro, FOO, \ EXCLUDES := foo$$$$bar, \ ... \ )) Because of this, I think the best solution is to modify the logic evaluating the parameters for such macros, with a strategically placed call to DoubleDollar to compensate for the extra evaluation of the parameter values. Then the first example will just work and the second becomes: $(eval $(call SomeMacro, FOO, \ EXCLUDES := foo$$bar, \ ... \ )) Bug: https://bugs.openjdk.java.net/browse/JDK-8160491 Webrev: http://cr.openjdk.java.net/~erikj/8160491/webrev.01/ /Erik From mandy.chung at oracle.com Thu Nov 3 14:48:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 3 Nov 2016 07:48:27 -0700 Subject: RFR: JDK-8168108: lib/classlist should be packaged in java.base.jmod In-Reply-To: <12bbbeb4-b6ba-dc7d-78bc-28c2ec756195@oracle.com> References: <12bbbeb4-b6ba-dc7d-78bc-28c2ec756195@oracle.com> Message-ID: <173C26E2-80A8-48FB-A703-8A7AB0AC4771@oracle.com> > On Nov 3, 2016, at 5:01 AM, Erik Joelsson wrote: > > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.02/ Looks good. Mandy From erik.joelsson at oracle.com Thu Nov 3 15:01:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Nov 2016 16:01:21 +0100 Subject: RFR: JDK-8160491: tar.gz bundles missing files containing $ In-Reply-To: References: Message-ID: <6616811d-2f2c-0c49-796a-8c3ca21d3216@oracle.com> Found more places needing to be adjusted for this, will post new webrev. /Erik On 2016-11-03 15:32, Erik Joelsson wrote: > The build logic for tar.gz bundles cannot handle files containing $. > For the Oracle internal docs bundle, this is a problem since there are > example inner classes included. Escaping of $ is always a pain point > when working with make. After having investigated this quite > thoroughly I have found what I think is the best solution. > > What happens here is something like this: > > LIST_OF_FILES := $(some find expression creating a list of files) > $(eval $(call SomeMacro, FOO, \ > FILES := $(LIST_OF_FILES), \ > ... \ > )) > > If LIST_OF_FILES contains a file with a $, that $ will get eaten by > the $(eval). When we supply arguments to such macros inline, we > currently have to escape them two times like this (in order to get > EXCLUDES to contain foo$bar): > > $(eval $(call SomeMacro, FOO, \ > EXCLUDES := foo$$$$bar, \ > ... \ > )) > > Because of this, I think the best solution is to modify the logic > evaluating the parameters for such macros, with a strategically placed > call to DoubleDollar to compensate for the extra evaluation of the > parameter values. Then the first example will just work and the second > becomes: > > $(eval $(call SomeMacro, FOO, \ > EXCLUDES := foo$$bar, \ > ... \ > )) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8160491 > Webrev: http://cr.openjdk.java.net/~erikj/8160491/webrev.01/ > > /Erik From erik.joelsson at oracle.com Thu Nov 3 18:04:47 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 Nov 2016 19:04:47 +0100 Subject: RFR: JDK-8160491: tar.gz bundles missing files containing $ In-Reply-To: <6616811d-2f2c-0c49-796a-8c3ca21d3216@oracle.com> References: <6616811d-2f2c-0c49-796a-8c3ca21d3216@oracle.com> Message-ID: Here is a new webrev that actually works. http://cr.openjdk.java.net/~erikj/8160491/webrev.02/ /Erik On 2016-11-03 16:01, Erik Joelsson wrote: > Found more places needing to be adjusted for this, will post new webrev. > > /Erik > > > On 2016-11-03 15:32, Erik Joelsson wrote: >> The build logic for tar.gz bundles cannot handle files containing $. >> For the Oracle internal docs bundle, this is a problem since there >> are example inner classes included. Escaping of $ is always a pain >> point when working with make. After having investigated this quite >> thoroughly I have found what I think is the best solution. >> >> What happens here is something like this: >> >> LIST_OF_FILES := $(some find expression creating a list of files) >> $(eval $(call SomeMacro, FOO, \ >> FILES := $(LIST_OF_FILES), \ >> ... \ >> )) >> >> If LIST_OF_FILES contains a file with a $, that $ will get eaten by >> the $(eval). When we supply arguments to such macros inline, we >> currently have to escape them two times like this (in order to get >> EXCLUDES to contain foo$bar): >> >> $(eval $(call SomeMacro, FOO, \ >> EXCLUDES := foo$$$$bar, \ >> ... \ >> )) >> >> Because of this, I think the best solution is to modify the logic >> evaluating the parameters for such macros, with a strategically >> placed call to DoubleDollar to compensate for the extra evaluation of >> the parameter values. Then the first example will just work and the >> second becomes: >> >> $(eval $(call SomeMacro, FOO, \ >> EXCLUDES := foo$$bar, \ >> ... \ >> )) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8160491 >> Webrev: http://cr.openjdk.java.net/~erikj/8160491/webrev.01/ >> >> /Erik > From sean.coffey at oracle.com Fri Nov 4 13:42:16 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 4 Nov 2016 13:42:16 +0000 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates Message-ID: <581C9038.9060808@oracle.com> Looking to push this enhancement to jdk8u. The change introduces the new Security property which was brought into JDK 9 via JDK-8061842. The code differs in that jar files continue to be used and backwards compatibility is maintained. If the new security property is not defined and the policy jar files exist in the legacy locations, then those jar files will continue to be honoured. https://bugs.openjdk.java.net/browse/JDK-8157561 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ -- Regards, Sean. From erik.joelsson at oracle.com Fri Nov 4 14:16:41 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Nov 2016 15:16:41 +0100 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: <581C9038.9060808@oracle.com> References: <581C9038.9060808@oracle.com> Message-ID: <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> Build changes look ok to me. /Erik On 2016-11-04 14:42, Se?n Coffey wrote: > Looking to push this enhancement to jdk8u. The change introduces the > new Security property which was brought into JDK 9 via JDK-8061842. > > The code differs in that jar files continue to be used and backwards > compatibility is maintained. If the new security property is not > defined and the policy jar files exist in the legacy locations, then > those jar files will continue to be honoured. > > https://bugs.openjdk.java.net/browse/JDK-8157561 > webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ > From erik.joelsson at oracle.com Fri Nov 4 14:22:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Nov 2016 15:22:46 +0100 Subject: RFR: JDK-8169255: Link gtestLauncher statically if libjvm is configured for static linking Message-ID: In the build, we have a global setting for linking libstdc++ static or dynamic on Linux. All libraries and executables that go in the product honor this setting. The gtestLauncher currently doesn't. This causes trouble in testing where some machines might not have the 32bit libstdc++.so installed. Since installing that library is not needed for just running the product, it's awkward to have to install it to run certain tests. This patch adds the LIBCXX flags from configure when linking gtestLauncher. The resulting file actually comes out a little bit smaller, so there is no footprint overhead. The tests still pass. Bug: https://bugs.openjdk.java.net/browse/JDK-8169255 Patch: diff -r 246f6fb74bf1 make/lib/CompileGtest.gmk --- a/make/lib/CompileGtest.gmk +++ b/make/lib/CompileGtest.gmk @@ -107,6 +107,7 @@ LDFLAGS := $(LDFLAGS_JDKEXE), \ LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call SET_SHARED_LIBRARY_ORIGIN), \ LDFLAGS_solaris := -library=stlport4, \ + LIBS_linux := $(LIBCXX), \ LIBS_unix := -ljvm, \ LIBS_windows := $(JVM_OUTPUTDIR)/gtest/objs/jvm.lib, \ COPY_DEBUG_SYMBOLS := $(GTEST_COPY_DEBUG_SYMBOLS), \ /Erik From tim.bell at oracle.com Fri Nov 4 14:31:21 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 4 Nov 2016 07:31:21 -0700 Subject: RFR: JDK-8169255: Link gtestLauncher statically if libjvm is configured for static linking In-Reply-To: References: Message-ID: Erik: > In the build, we have a global setting for linking libstdc++ static or > dynamic on Linux. All libraries and executables that go in the product > honor this setting. The gtestLauncher currently doesn't. This causes > trouble in testing where some machines might not have the 32bit > libstdc++.so installed. Since installing that library is not needed for > just running the product, it's awkward to have to install it to run > certain tests. > > This patch adds the LIBCXX flags from configure when linking > gtestLauncher. The resulting file actually comes out a little bit > smaller, so there is no footprint overhead. The tests still pass. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169255 > > Patch: > > diff -r 246f6fb74bf1 make/lib/CompileGtest.gmk > --- a/make/lib/CompileGtest.gmk > +++ b/make/lib/CompileGtest.gmk > @@ -107,6 +107,7 @@ > LDFLAGS := $(LDFLAGS_JDKEXE), \ > LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call > SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_solaris := -library=stlport4, \ > + LIBS_linux := $(LIBCXX), \ > LIBS_unix := -ljvm, \ > LIBS_windows := $(JVM_OUTPUTDIR)/gtest/objs/jvm.lib, \ > COPY_DEBUG_SYMBOLS := $(GTEST_COPY_DEBUG_SYMBOLS), \ Looks good to me. Tim From bradford.wetmore at oracle.com Fri Nov 4 22:56:07 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 4 Nov 2016 15:56:07 -0700 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> References: <581C9038.9060808@oracle.com> <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> Message-ID: I didn't see anything majorly different in what I looked at earlier, I didn't check java.security or the test case. CryptoLevel.java ================ 49: Your usage mentions only unlimited|limited. Do you want to include a check for that? JceSecurity.java ================ 300: Indention problem. Looks ok otherwise. Thanks, Brad On 11/4/2016 7:16 AM, Erik Joelsson wrote: > Build changes look ok to me. > > /Erik > > > On 2016-11-04 14:42, Se?n Coffey wrote: >> Looking to push this enhancement to jdk8u. The change introduces the >> new Security property which was brought into JDK 9 via JDK-8061842. >> >> The code differs in that jar files continue to be used and backwards >> compatibility is maintained. If the new security property is not >> defined and the policy jar files exist in the legacy locations, then >> those jar files will continue to be honoured. >> >> https://bugs.openjdk.java.net/browse/JDK-8157561 >> webrev : >> http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ >> > From david.holmes at oracle.com Sat Nov 5 18:48:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Nov 2016 04:48:28 +1000 Subject: RFR: JDK-8169255: Link gtestLauncher statically if libjvm is configured for static linking In-Reply-To: References: Message-ID: <7ffb2f76-9bc9-f774-7224-e6ff30b0e33c@oracle.com> Looks good. Thanks for fixing this Erik. David On 5/11/2016 12:22 AM, Erik Joelsson wrote: > In the build, we have a global setting for linking libstdc++ static or > dynamic on Linux. All libraries and executables that go in the product > honor this setting. The gtestLauncher currently doesn't. This causes > trouble in testing where some machines might not have the 32bit > libstdc++.so installed. Since installing that library is not needed for > just running the product, it's awkward to have to install it to run > certain tests. > > This patch adds the LIBCXX flags from configure when linking > gtestLauncher. The resulting file actually comes out a little bit > smaller, so there is no footprint overhead. The tests still pass. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169255 > > Patch: > > diff -r 246f6fb74bf1 make/lib/CompileGtest.gmk > --- a/make/lib/CompileGtest.gmk > +++ b/make/lib/CompileGtest.gmk > @@ -107,6 +107,7 @@ > LDFLAGS := $(LDFLAGS_JDKEXE), \ > LDFLAGS_unix := -L$(JVM_OUTPUTDIR)/gtest $(call > SET_SHARED_LIBRARY_ORIGIN), \ > LDFLAGS_solaris := -library=stlport4, \ > + LIBS_linux := $(LIBCXX), \ > LIBS_unix := -ljvm, \ > LIBS_windows := $(JVM_OUTPUTDIR)/gtest/objs/jvm.lib, \ > COPY_DEBUG_SYMBOLS := $(GTEST_COPY_DEBUG_SYMBOLS), \ > > > /Erik > From sean.coffey at oracle.com Mon Nov 7 11:34:00 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Mon, 7 Nov 2016 11:34:00 +0000 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: References: <581C9038.9060808@oracle.com> <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> Message-ID: <582066A8.502@oracle.com> Thanks for review Brad. I've included an extra check in CryptoLevel to check for "limited/unlimited" input. Addressed the JceSecurity indentation issue also. http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/ Regards, Sean. On 04/11/16 22:56, Bradford Wetmore wrote: > I didn't see anything majorly different in what I looked at earlier, I > didn't check java.security or the test case. > > > CryptoLevel.java > ================ > 49: Your usage mentions only unlimited|limited. Do you want to > include a check for that? > > JceSecurity.java > ================ > 300: Indention problem. > > Looks ok otherwise. > > Thanks, > > Brad > > > > > On 11/4/2016 7:16 AM, Erik Joelsson wrote: >> Build changes look ok to me. >> >> /Erik >> >> >> On 2016-11-04 14:42, Se?n Coffey wrote: >>> Looking to push this enhancement to jdk8u. The change introduces the >>> new Security property which was brought into JDK 9 via JDK-8061842. >>> >>> The code differs in that jar files continue to be used and backwards >>> compatibility is maintained. If the new security property is not >>> defined and the policy jar files exist in the legacy locations, then >>> those jar files will continue to be honoured. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157561 >>> webrev : >>> http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ >>> >> From magnus.ihse.bursie at oracle.com Mon Nov 7 12:30:11 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 7 Nov 2016 13:30:11 +0100 Subject: RFR: JDK-8160491: tar.gz bundles missing files containing $ In-Reply-To: References: <6616811d-2f2c-0c49-796a-8c3ca21d3216@oracle.com> Message-ID: <582073D3.1030601@oracle.com> On 2016-11-03 19:04, Erik Joelsson wrote: > Here is a new webrev that actually works. > > http://cr.openjdk.java.net/~erikj/8160491/webrev.02/ It looks reasonable, but these kinds of changes are always scary. The new solution, if it works correctly, seems easier to understand, though. If you feel that you trust your testing, I'm ok with the change. /Magnus > > /Erik > > > On 2016-11-03 16:01, Erik Joelsson wrote: >> Found more places needing to be adjusted for this, will post new webrev. >> >> /Erik >> >> >> On 2016-11-03 15:32, Erik Joelsson wrote: >>> The build logic for tar.gz bundles cannot handle files containing $. >>> For the Oracle internal docs bundle, this is a problem since there >>> are example inner classes included. Escaping of $ is always a pain >>> point when working with make. After having investigated this quite >>> thoroughly I have found what I think is the best solution. >>> >>> What happens here is something like this: >>> >>> LIST_OF_FILES := $(some find expression creating a list of files) >>> $(eval $(call SomeMacro, FOO, \ >>> FILES := $(LIST_OF_FILES), \ >>> ... \ >>> )) >>> >>> If LIST_OF_FILES contains a file with a $, that $ will get eaten by >>> the $(eval). When we supply arguments to such macros inline, we >>> currently have to escape them two times like this (in order to get >>> EXCLUDES to contain foo$bar): >>> >>> $(eval $(call SomeMacro, FOO, \ >>> EXCLUDES := foo$$$$bar, \ >>> ... \ >>> )) >>> >>> Because of this, I think the best solution is to modify the logic >>> evaluating the parameters for such macros, with a strategically >>> placed call to DoubleDollar to compensate for the extra evaluation >>> of the parameter values. Then the first example will just work and >>> the second becomes: >>> >>> $(eval $(call SomeMacro, FOO, \ >>> EXCLUDES := foo$$bar, \ >>> ... \ >>> )) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160491 >>> Webrev: http://cr.openjdk.java.net/~erikj/8160491/webrev.01/ >>> >>> /Erik >> > From magnus.ihse.bursie at oracle.com Mon Nov 7 12:40:56 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 7 Nov 2016 13:40:56 +0100 Subject: RFR: JDK-8168108: lib/classlist should be packaged in java.base.jmod In-Reply-To: <12bbbeb4-b6ba-dc7d-78bc-28c2ec756195@oracle.com> References: <12bbbeb4-b6ba-dc7d-78bc-28c2ec756195@oracle.com> Message-ID: <58207658.3090405@oracle.com> Hi, The webrev haven't picked up the relationship between the LinkOpt and Classlist files. It seems that it is a rename + modifications. Can you please redo it using hg mv? And update the webrev so the changes in the file is visible. The name "LinkOptData", is it supposed to be read "link optional data"? I'm not sure in what way it is an improvement of Classlist (even though this name was no good either). Why do you pass JMODS_DIR and _TEMPDIR in Main.gmk to CreateJmods.gmk? I understand that you need to specify the module and that we're building interim jmods, but the rest seems to be redundant. /Magnus On 2016-11-03 13:01, Erik Joelsson wrote: > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.02/ > > > On 2016-11-02 18:52, Mandy Chung wrote: >>> On Nov 2, 2016, at 9:55 AM, Erik Joelsson >>> wrote: >>> >>> This patch changes how the dynamically generated lib/classlist is >>> packaged. We already create an interim-image from java.base and >>> java.logging to generate the classlist during the build. We then >>> copy it into the jdk and jre images using makefile logic after >>> jlinking those images. With this patch, lib/classlist is instead >>> included in java.base.jmod. >>> >>> To achieve this, I have introduced the concept of interim jmods for >>> the jmods used to create the interim-image. These can be built >>> explicitly from the top level using targets -interim-jmod. >>> It adds a little bit of build time, but it's hardly noticeable. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168108 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.01/ >> I like the interim jmods idea. The solution is clean. >> >> jdk/make/GenerateClasslist.gmk >> 62 $(call MakeDir, $(@D) $(SUPPORT_OUTPUTDIR)/classlist) >> >> Is the directory $(SUPPORT_OUTPUTDIR)/classlist needed? I can?t tell >> why this line needs to be changed. > Yes it was, since jli_trace.out is also generated by this target. I > realize this becomes a bit convoluted so renamed the output dir, the > makefile and the top level target to reflect that more things than > classlist are generated here. I fixed the make rules so that both the > classlist and jli_trace.out works correctly if either is removed > before a rebuild. >> >> 63 $(call LogInfo, Generating lib/classlist) >> >> It might be better to print $(CLASSLIST_FILE) in the log instead? > Fixed the log messages. > > /Erik >> Otherwise, looks fine. >> >> Mandy > From magnus.ihse.bursie at oracle.com Mon Nov 7 12:43:38 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 7 Nov 2016 13:43:38 +0100 Subject: RFR: JDK-8063154: Checked in jvmti.h not in sync with generated jvmti.h In-Reply-To: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> References: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> Message-ID: <582076FA.4060505@oracle.com> Hi, On 2016-11-01 17:56, Erik Joelsson wrote: > New webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.02/ > > I had not managed to revert all changes from another patch. Looks good to me, but please remove this comment as well: # Disable copy of jvmti.h from hotspot until this has been cleared up. The file # is currently being copied from the jdk repository. See JDK-8167078. /Magnus > > /Erik > > > On 2016-11-01 17:22, Erik Joelsson wrote: >> Hello, >> >> The header file jvmti.h is generated in the hotspot build. There is >> also a copy of this file in the jdk repository which is the one that >> is actually included in the jdk image. This patch removes the copy >> and uses the generated file instead. JDK-8147943 fixed the generated >> file so that it has the correct license header, making the files >> equivalent at this time, so this change is not changing the build >> output. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8063154 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.01/ >> >> /Erik >> > From erik.joelsson at oracle.com Mon Nov 7 13:13:09 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Nov 2016 14:13:09 +0100 Subject: RFR: JDK-8168108: lib/classlist should be packaged in java.base.jmod In-Reply-To: <58207658.3090405@oracle.com> References: <12bbbeb4-b6ba-dc7d-78bc-28c2ec756195@oracle.com> <58207658.3090405@oracle.com> Message-ID: Hello, On 2016-11-07 13:40, Magnus Ihse Bursie wrote: > Hi, > > The webrev haven't picked up the relationship between the LinkOpt and > Classlist files. It seems that it is a rename + modifications. Can you > please redo it using hg mv? And update the webrev so the changes in > the file is visible. > The file was moved between repositories. I'm not aware of a way to get webrev to display that as a diff. > The name "LinkOptData", is it supposed to be read "link optional > data"? I'm not sure in what way it is an improvement of Classlist > (even though this name was no good either). Opt -> optimization. We are creating data that is used for optimizing the images in the jlink step. > > Why do you pass JMODS_DIR and _TEMPDIR in Main.gmk to CreateJmods.gmk? > I understand that you need to specify the module and that we're > building interim jmods, but the rest seems to be redundant. > Right, it started out as sending in specific modifications to existing variables in CreateJmods.gmk, but then I converted one of them to an explicit "interim" setting. It would make sense to let CreateJmods.gmk just use this "interim" setting to pick the correct directories. I have however already pushed this so further changes will need to be done in a followup cleanup change. /Erik > /Magnus > > On 2016-11-03 13:01, Erik Joelsson wrote: >> Hello, >> >> New webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.02/ >> >> >> On 2016-11-02 18:52, Mandy Chung wrote: >>>> On Nov 2, 2016, at 9:55 AM, Erik Joelsson >>>> wrote: >>>> >>>> This patch changes how the dynamically generated lib/classlist is >>>> packaged. We already create an interim-image from java.base and >>>> java.logging to generate the classlist during the build. We then >>>> copy it into the jdk and jre images using makefile logic after >>>> jlinking those images. With this patch, lib/classlist is instead >>>> included in java.base.jmod. >>>> >>>> To achieve this, I have introduced the concept of interim jmods for >>>> the jmods used to create the interim-image. These can be built >>>> explicitly from the top level using targets -interim-jmod. >>>> It adds a little bit of build time, but it's hardly noticeable. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168108 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8168108/webrev.01/ >>> I like the interim jmods idea. The solution is clean. >>> >>> jdk/make/GenerateClasslist.gmk >>> 62 $(call MakeDir, $(@D) $(SUPPORT_OUTPUTDIR)/classlist) >>> >>> Is the directory $(SUPPORT_OUTPUTDIR)/classlist needed? I can?t >>> tell why this line needs to be changed. >> Yes it was, since jli_trace.out is also generated by this target. I >> realize this becomes a bit convoluted so renamed the output dir, the >> makefile and the top level target to reflect that more things than >> classlist are generated here. I fixed the make rules so that both the >> classlist and jli_trace.out works correctly if either is removed >> before a rebuild. >>> >>> 63 $(call LogInfo, Generating lib/classlist) >>> >>> It might be better to print $(CLASSLIST_FILE) in the log instead? >> Fixed the log messages. >> >> /Erik >>> Otherwise, looks fine. >>> >>> Mandy >> > From erik.joelsson at oracle.com Mon Nov 7 13:13:51 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Nov 2016 14:13:51 +0100 Subject: RFR: JDK-8063154: Checked in jvmti.h not in sync with generated jvmti.h In-Reply-To: <582076FA.4060505@oracle.com> References: <38fd15e8-e5f9-4efa-da9f-68009e7a4839@oracle.com> <582076FA.4060505@oracle.com> Message-ID: Good catch, but unfortunately this has already been pushed. /Erik On 2016-11-07 13:43, Magnus Ihse Bursie wrote: > Hi, > > On 2016-11-01 17:56, Erik Joelsson wrote: >> New webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.02/ >> >> I had not managed to revert all changes from another patch. > > Looks good to me, but please remove this comment as well: > > # Disable copy of jvmti.h from hotspot until this has been cleared > up. The file > # is currently being copied from the jdk repository. See JDK-8167078. > > /Magnus >> >> /Erik >> >> >> On 2016-11-01 17:22, Erik Joelsson wrote: >>> Hello, >>> >>> The header file jvmti.h is generated in the hotspot build. There is >>> also a copy of this file in the jdk repository which is the one that >>> is actually included in the jdk image. This patch removes the copy >>> and uses the generated file instead. JDK-8147943 fixed the generated >>> file so that it has the correct license header, making the files >>> equivalent at this time, so this change is not changing the build >>> output. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8063154 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8063154/webrev.01/ >>> >>> /Erik >>> >> > From kumar.x.srinivasan at oracle.com Mon Nov 7 18:47:48 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 07 Nov 2016 10:47:48 -0800 Subject: 8169001: Remove launcher's built-in ergonomics Message-ID: <5820CC54.4010401@oracle.com> Hello, Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8169001 Webrev at: http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ Background: > Launcher ergonomics was introduced last decade to help determine > if the execution system is "Server Class", this was necessary to > choose server VM on platforms that supported both client and server > VMs (primarily for Solaris and Linux 32-bit). > > The algorithm involves computing and detecting the number of CPUs > and the amount of memory on the target system. All modern computers > systems with hyper-threading cause the ergonomics to choose server. > > JDK9 Platforms that have only server vm. > > ./linux-x64/lib/amd64/server/libjvm.so > ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so > ./solaris-sparcv9/lib/sparcv9/server/libjvm.so > ./solaris-x64/lib/amd64/server/libjvm.so > ./windows-x86/bin/server/jvm.dll > ./windows-x64/bin/server/jvm.dll > > JDK9 Platforms that have more than one vm variant: > ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) > ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so > > ./linux-x86/lib/i386/server/libjvm.so (default) > ./linux-x86/lib/i386/minimal/libjvm.so > > > In the cases where multiple VMs are supported the ergnomics > has no effect, and the default platforms are chosen by the > jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. Thanks Kumar From bradford.wetmore at oracle.com Mon Nov 7 18:53:46 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 7 Nov 2016 10:53:46 -0800 Subject: RFR: 8157561 :Ship the unlimited policy files in JDK Updates In-Reply-To: <582066A8.502@oracle.com> References: <581C9038.9060808@oracle.com> <94915582-6f28-1ceb-3625-eb534f295e63@oracle.com> <582066A8.502@oracle.com> Message-ID: <52d9d607-4c41-1866-401c-1627b0b53230@oracle.com> Great, thanks. Looks good. Brad On 11/7/2016 3:34 AM, Se?n Coffey wrote: > Thanks for review Brad. I've included an extra check in CryptoLevel to > check for "limited/unlimited" input. Addressed the JceSecurity > indentation issue also. > > http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v5/webrev/ > > Regards, > Sean. > > On 04/11/16 22:56, Bradford Wetmore wrote: >> I didn't see anything majorly different in what I looked at earlier, I >> didn't check java.security or the test case. >> >> >> CryptoLevel.java >> ================ >> 49: Your usage mentions only unlimited|limited. Do you want to >> include a check for that? >> >> JceSecurity.java >> ================ >> 300: Indention problem. >> >> Looks ok otherwise. >> >> Thanks, >> >> Brad >> >> >> >> >> On 11/4/2016 7:16 AM, Erik Joelsson wrote: >>> Build changes look ok to me. >>> >>> /Erik >>> >>> >>> On 2016-11-04 14:42, Se?n Coffey wrote: >>>> Looking to push this enhancement to jdk8u. The change introduces the >>>> new Security property which was brought into JDK 9 via JDK-8061842. >>>> >>>> The code differs in that jar files continue to be used and backwards >>>> compatibility is maintained. If the new security property is not >>>> defined and the policy jar files exist in the legacy locations, then >>>> those jar files will continue to be honoured. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157561 >>>> webrev : >>>> http://cr.openjdk.java.net/~coffeys/webrev.8157561.8u.jdk.v4/webrev/ >>>> >>> > From david.holmes at oracle.com Mon Nov 7 23:24:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Nov 2016 09:24:33 +1000 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <5820CC54.4010401@oracle.com> References: <5820CC54.4010401@oracle.com> Message-ID: <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> Hi Kumar, On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: > > Hello, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8169001 > > Webrev at: > http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ Overall this looks like a complete eradication of the launcher ergonomics. A few specific comments: src/java.base/share/native/launcher/main.c ! const_cpwildcard, const_javaw, 0); Can you clarify this change with ! const_cpwildcard, const_javaw, 0 /* unused */); Thanks. --- src/java.base/share/native/libjli/java.c 220 jint ergo /* unused */ I assume JLI_Launch is an exported API otherwise I'd expect this to be deleted. The fact it is unused should also be documented in src/java.base/share/native/libjli/java.h. But I'm also wondering where this API change is being documented for external users? - FreeKnownVMs(); /* after last possible PrintUsage() */ Not clear why you no longer need to free here. But if you don't then FreeKnownVMs() seems to be dead code now. --- src/java.base/unix/conf/i586/jvm.cfg I think you still need an entry for "-client KNOWN" as anyone can build the client VM if they choose. Ditto for src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds are obsolete now). --- You have updated a number of copyright notices but not all of them. --- I see no changes to tests, but I'm pretty sure we have a test for server-class-machine somewhere (or we did - I recall it breaking at some point). Thanks, David > Background: >> Launcher ergonomics was introduced last decade to help determine >> if the execution system is "Server Class", this was necessary to >> choose server VM on platforms that supported both client and server >> VMs (primarily for Solaris and Linux 32-bit). >> >> The algorithm involves computing and detecting the number of CPUs >> and the amount of memory on the target system. All modern computers >> systems with hyper-threading cause the ergonomics to choose server. >> >> JDK9 Platforms that have only server vm. >> >> ./linux-x64/lib/amd64/server/libjvm.so >> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >> ./solaris-x64/lib/amd64/server/libjvm.so >> ./windows-x86/bin/server/jvm.dll >> ./windows-x64/bin/server/jvm.dll >> >> JDK9 Platforms that have more than one vm variant: >> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >> >> ./linux-x86/lib/i386/server/libjvm.so (default) >> ./linux-x86/lib/i386/minimal/libjvm.so >> >> >> In the cases where multiple VMs are supported the ergnomics >> has no effect, and the default platforms are chosen by the >> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. > > Thanks > Kumar > From erik.joelsson at oracle.com Tue Nov 8 08:23:37 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 Nov 2016 09:23:37 +0100 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <5820CC54.4010401@oracle.com> References: <5820CC54.4010401@oracle.com> Message-ID: <501f7c83-19a4-5927-2116-a8c9ed506d08@oracle.com> Build changes look ok. /Erik On 2016-11-07 19:47, Kumar Srinivasan wrote: > > Hello, > > Please review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8169001 > > Webrev at: > http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ > > Background: >> Launcher ergonomics was introduced last decade to help determine >> if the execution system is "Server Class", this was necessary to >> choose server VM on platforms that supported both client and server >> VMs (primarily for Solaris and Linux 32-bit). >> >> The algorithm involves computing and detecting the number of CPUs >> and the amount of memory on the target system. All modern computers >> systems with hyper-threading cause the ergonomics to choose server. >> >> JDK9 Platforms that have only server vm. >> >> ./linux-x64/lib/amd64/server/libjvm.so >> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >> ./solaris-x64/lib/amd64/server/libjvm.so >> ./windows-x86/bin/server/jvm.dll >> ./windows-x64/bin/server/jvm.dll >> >> JDK9 Platforms that have more than one vm variant: >> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >> >> ./linux-x86/lib/i386/server/libjvm.so (default) >> ./linux-x86/lib/i386/minimal/libjvm.so >> >> >> In the cases where multiple VMs are supported the ergnomics >> has no effect, and the default platforms are chosen by the >> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. > > Thanks > Kumar > From kumar.x.srinivasan at oracle.com Tue Nov 8 17:28:06 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 08 Nov 2016 09:28:06 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> Message-ID: <58220B26.9020907@oracle.com> Hi David, Thanks for the review please see embedded comments: > Hi Kumar, > > On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >> >> Hello, >> >> Please review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8169001 >> >> Webrev at: >> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ > > Overall this looks like a complete eradication of the launcher > ergonomics. A few specific comments: > > src/java.base/share/native/launcher/main.c > > ! const_cpwildcard, const_javaw, 0); > > Can you clarify this change with > > ! const_cpwildcard, const_javaw, 0 /* unused */); To clarify: -159 const_cpwildcard, const_javaw, const_ergo_class); +159 const_cpwildcard, const_javaw, 0); JLI_Launch is an *internal* entry point, this is primarily used in main.c, and this is called by JDK's tool launchers which sets "NEVER_ACT_AS_SERVER", also this entry point is used by the java packager and deployment, I have cc'ed Chris Bensen and David DeHaven, my take is not to change the signature now. Chris, David ? > > Thanks. > > --- > > src/java.base/share/native/libjli/java.c > > 220 jint ergo /* unused */ > > I assume JLI_Launch is an exported API otherwise I'd expect this to be > deleted. The fact it is unused should also be documented in > src/java.base/share/native/libjli/java.h. But I'm also wondering where > this API change is being documented for external users? This entry point is for internal users only. > > - FreeKnownVMs(); /* after last possible PrintUsage() */ > > Not clear why you no longer need to free here. But if you don't then > FreeKnownVMs() seems to be dead code now. Ugh (and thanks!), I was too aggressive, this should remain, I will put it back in the next revision. > > --- > > src/java.base/unix/conf/i586/jvm.cfg > > I think you still need an entry for "-client KNOWN" as anyone can > build the client VM if they choose. Ditto for > src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds > are obsolete now). I had to mull on this, one hand jvm.cfg should reflect the VMs we support, but we could have someone build client vm. I will go with making the change you suggested. > > --- > > You have updated a number of copyright notices but not all of them. Yes, I vaguely recall, that the CR should be updated if there is any content that ought to be copyrighted, in this case several changes are typo fixups in the comments. So I don't think it is warranted. > > --- > > I see no changes to tests, but I'm pretty sure we have a test for > server-class-machine somewhere (or we did - I recall it breaking at > some point). I ran -testset pit, saw no failures, I will perform a -testset hotspot. Note though, several test changes had to be made, when Solaris 32-bit was yanked out. Thanks Kumar > > Thanks, > David > >> Background: >>> Launcher ergonomics was introduced last decade to help determine >>> if the execution system is "Server Class", this was necessary to >>> choose server VM on platforms that supported both client and server >>> VMs (primarily for Solaris and Linux 32-bit). >>> >>> The algorithm involves computing and detecting the number of CPUs >>> and the amount of memory on the target system. All modern computers >>> systems with hyper-threading cause the ergonomics to choose server. >>> >>> JDK9 Platforms that have only server vm. >>> >>> ./linux-x64/lib/amd64/server/libjvm.so >>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>> ./solaris-x64/lib/amd64/server/libjvm.so >>> ./windows-x86/bin/server/jvm.dll >>> ./windows-x64/bin/server/jvm.dll >>> >>> JDK9 Platforms that have more than one vm variant: >>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>> >>> ./linux-x86/lib/i386/server/libjvm.so (default) >>> ./linux-x86/lib/i386/minimal/libjvm.so >>> >>> >>> In the cases where multiple VMs are supported the ergnomics >>> has no effect, and the default platforms are chosen by the >>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >> >> Thanks >> Kumar >> From david.holmes at oracle.com Wed Nov 9 00:22:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Nov 2016 10:22:42 +1000 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <58220B26.9020907@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <58220B26.9020907@oracle.com> Message-ID: <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> Hi Kumar, FYI regarding the test, I was mis-remembering - it was actually an issue with the VM's notion of is_server_class_machine(), not the launcher. It's used for GC ergonomic selection. Cheers, David On 9/11/2016 3:28 AM, Kumar Srinivasan wrote: > > Hi David, > > Thanks for the review please see embedded comments: > >> Hi Kumar, >> >> On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >>> >>> Hello, >>> >>> Please review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >> >> Overall this looks like a complete eradication of the launcher >> ergonomics. A few specific comments: >> >> src/java.base/share/native/launcher/main.c >> >> ! const_cpwildcard, const_javaw, 0); >> >> Can you clarify this change with >> >> ! const_cpwildcard, const_javaw, 0 /* unused */); > > To clarify: > > -159 const_cpwildcard, const_javaw, const_ergo_class); > +159 const_cpwildcard, const_javaw, 0); > > > JLI_Launch is an *internal* entry point, this is primarily used in main.c, > and this is called by JDK's tool launchers which sets > "NEVER_ACT_AS_SERVER", > also this entry point is used by the java packager and deployment, I > have cc'ed > Chris Bensen and David DeHaven, my take is not to change the signature now. > Chris, David ? > >> >> Thanks. >> >> --- >> >> src/java.base/share/native/libjli/java.c >> >> 220 jint ergo /* unused */ >> >> I assume JLI_Launch is an exported API otherwise I'd expect this to be >> deleted. The fact it is unused should also be documented in >> src/java.base/share/native/libjli/java.h. But I'm also wondering where >> this API change is being documented for external users? > > This entry point is for internal users only. > >> >> - FreeKnownVMs(); /* after last possible PrintUsage() */ >> >> Not clear why you no longer need to free here. But if you don't then >> FreeKnownVMs() seems to be dead code now. > > Ugh (and thanks!), I was too aggressive, this should remain, I will put > it back in the next revision. > >> >> --- >> >> src/java.base/unix/conf/i586/jvm.cfg >> >> I think you still need an entry for "-client KNOWN" as anyone can >> build the client VM if they choose. Ditto for >> src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds >> are obsolete now). > > I had to mull on this, one hand jvm.cfg should reflect the VMs we support, > but we could have someone build client vm. I will go with making the change > you suggested. > >> >> --- >> >> You have updated a number of copyright notices but not all of them. > > Yes, I vaguely recall, that the CR should be updated if there is any > content > that ought to be copyrighted, in this case several changes are typo > fixups in the > comments. So I don't think it is warranted. > >> >> --- >> >> I see no changes to tests, but I'm pretty sure we have a test for >> server-class-machine somewhere (or we did - I recall it breaking at >> some point). > > I ran -testset pit, saw no failures, I will perform a -testset hotspot. > Note though, several test changes had to be made, when Solaris 32-bit > was yanked out. > > Thanks > Kumar > >> >> Thanks, >> David >> >>> Background: >>>> Launcher ergonomics was introduced last decade to help determine >>>> if the execution system is "Server Class", this was necessary to >>>> choose server VM on platforms that supported both client and server >>>> VMs (primarily for Solaris and Linux 32-bit). >>>> >>>> The algorithm involves computing and detecting the number of CPUs >>>> and the amount of memory on the target system. All modern computers >>>> systems with hyper-threading cause the ergonomics to choose server. >>>> >>>> JDK9 Platforms that have only server vm. >>>> >>>> ./linux-x64/lib/amd64/server/libjvm.so >>>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>>> ./solaris-x64/lib/amd64/server/libjvm.so >>>> ./windows-x86/bin/server/jvm.dll >>>> ./windows-x64/bin/server/jvm.dll >>>> >>>> JDK9 Platforms that have more than one vm variant: >>>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>>> >>>> ./linux-x86/lib/i386/server/libjvm.so (default) >>>> ./linux-x86/lib/i386/minimal/libjvm.so >>>> >>>> >>>> In the cases where multiple VMs are supported the ergnomics >>>> has no effect, and the default platforms are chosen by the >>>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >>> >>> Thanks >>> Kumar >>> > From david.dehaven at oracle.com Wed Nov 9 18:13:05 2016 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 9 Nov 2016 10:13:05 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <58220B26.9020907@oracle.com> <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> Message-ID: >>>> Please review the fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>>> >>>> Webrev at: >>>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >>> >>> Overall this looks like a complete eradication of the launcher >>> ergonomics. A few specific comments: >>> >>> src/java.base/share/native/launcher/main.c >>> >>> ! const_cpwildcard, const_javaw, 0); >>> >>> Can you clarify this change with >>> >>> ! const_cpwildcard, const_javaw, 0 /* unused */); >> >> To clarify: >> >> -159 const_cpwildcard, const_javaw, const_ergo_class); >> +159 const_cpwildcard, const_javaw, 0); >> >> >> JLI_Launch is an *internal* entry point, this is primarily used in main.c, >> and this is called by JDK's tool launchers which sets >> "NEVER_ACT_AS_SERVER", >> also this entry point is used by the java packager and deployment, I >> have cc'ed >> Chris Bensen and David DeHaven, my take is not to change the signature now. >> Chris, David ? We (deploy) pass 0 for ergo policy, so we're fine as long as the signature doesn't change. I would appreciate if we could leave the signature alone as that would require us to support both forms at least until Java 12. It's easy to adapt to changing signatures in Java, but not native as we'll get the same function pointer regardless of what the function arguments are. Sending an improperly set up stack frame to a function can cause Very Bad Things(tm) to happen. While it may work on one system, purely by virtue of the fact that it's the last argument in the list, there's no guarantee it will behave properly for future compilers or even different optimization levels. And just so I don't appear entirely selfish here, you'll also impact anyone using JLI_Launch in third party software. Since jli.h is included in the JDK it really should be viewed as external API, or at least externally accessible. -DrD- From chris.bensen at oracle.com Wed Nov 9 18:30:33 2016 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 9 Nov 2016 10:30:33 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <58220B26.9020907@oracle.com> <9b86332d-be53-2fd4-f5bd-498b3c94fe05@oracle.com> Message-ID: > On Nov 9, 2016, at 10:13 AM, David DeHaven wrote: > > >>>>> Please review the fix for: >>>>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>>>> >>>>> Webrev at: >>>>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >>>> >>>> Overall this looks like a complete eradication of the launcher >>>> ergonomics. A few specific comments: >>>> >>>> src/java.base/share/native/launcher/main.c >>>> >>>> ! const_cpwildcard, const_javaw, 0); >>>> >>>> Can you clarify this change with >>>> >>>> ! const_cpwildcard, const_javaw, 0 /* unused */); >>> >>> To clarify: >>> >>> -159 const_cpwildcard, const_javaw, const_ergo_class); >>> +159 const_cpwildcard, const_javaw, 0); >>> >>> >>> JLI_Launch is an *internal* entry point, this is primarily used in main.c, >>> and this is called by JDK's tool launchers which sets >>> "NEVER_ACT_AS_SERVER", >>> also this entry point is used by the java packager and deployment, I >>> have cc'ed >>> Chris Bensen and David DeHaven, my take is not to change the signature now. >>> Chris, David ? > > We (deploy) pass 0 for ergo policy, so we're fine as long as the signature doesn't change. > > I would appreciate if we could leave the signature alone as that would require us to support both forms at least until Java 12. It's easy to adapt to changing signatures in Java, but not native as we'll get the same function pointer regardless of what the function arguments are. Sending an improperly set up stack frame to a function can cause Very Bad Things(tm) to happen. While it may work on one system, purely by virtue of the fact that it's the last argument in the list, there's no guarantee it will behave properly for future compilers or even different optimization levels. > > And just so I don't appear entirely selfish here, you'll also impact anyone using JLI_Launch in third party software. Since jli.h is included in the JDK it really should be viewed as external API, or at least externally accessible. As long as the signature doesn?t change the Java Packager will be fine. If there is a signature change I?d suggest changing the name of the method especially if it happens during a minor release so there is some way the Java Packager?s launcher can determine what to call. Chris From kumar.x.srinivasan at oracle.com Thu Nov 10 21:10:51 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 10 Nov 2016 13:10:51 -0800 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> Message-ID: <5824E25B.2040008@oracle.com> Hi David, Here is the updated revision * added back in FreeUnknowVMS * add -client KNOWN as you suggested delta webrev http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/ full webrev (for reference): http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/ Thanks Kumar On 11/7/2016 3:24 PM, David Holmes wrote: > Hi Kumar, > > On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >> >> Hello, >> >> Please review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8169001 >> >> Webrev at: >> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ > > Overall this looks like a complete eradication of the launcher > ergonomics. A few specific comments: > > src/java.base/share/native/launcher/main.c > > ! const_cpwildcard, const_javaw, 0); > > Can you clarify this change with > > ! const_cpwildcard, const_javaw, 0 /* unused */); > > Thanks. > > --- > > src/java.base/share/native/libjli/java.c > > 220 jint ergo /* unused */ > > I assume JLI_Launch is an exported API otherwise I'd expect this to be > deleted. The fact it is unused should also be documented in > src/java.base/share/native/libjli/java.h. But I'm also wondering where > this API change is being documented for external users? > > - FreeKnownVMs(); /* after last possible PrintUsage() */ > > Not clear why you no longer need to free here. But if you don't then > FreeKnownVMs() seems to be dead code now. > > --- > > src/java.base/unix/conf/i586/jvm.cfg > > I think you still need an entry for "-client KNOWN" as anyone can > build the client VM if they choose. Ditto for > src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds > are obsolete now). > > --- > > You have updated a number of copyright notices but not all of them. > > --- > > I see no changes to tests, but I'm pretty sure we have a test for > server-class-machine somewhere (or we did - I recall it breaking at > some point). > > Thanks, > David > >> Background: >>> Launcher ergonomics was introduced last decade to help determine >>> if the execution system is "Server Class", this was necessary to >>> choose server VM on platforms that supported both client and server >>> VMs (primarily for Solaris and Linux 32-bit). >>> >>> The algorithm involves computing and detecting the number of CPUs >>> and the amount of memory on the target system. All modern computers >>> systems with hyper-threading cause the ergonomics to choose server. >>> >>> JDK9 Platforms that have only server vm. >>> >>> ./linux-x64/lib/amd64/server/libjvm.so >>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>> ./solaris-x64/lib/amd64/server/libjvm.so >>> ./windows-x86/bin/server/jvm.dll >>> ./windows-x64/bin/server/jvm.dll >>> >>> JDK9 Platforms that have more than one vm variant: >>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>> >>> ./linux-x86/lib/i386/server/libjvm.so (default) >>> ./linux-x86/lib/i386/minimal/libjvm.so >>> >>> >>> In the cases where multiple VMs are supported the ergnomics >>> has no effect, and the default platforms are chosen by the >>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >> >> Thanks >> Kumar >> From david.holmes at oracle.com Thu Nov 10 21:47:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Nov 2016 07:47:31 +1000 Subject: 8169001: Remove launcher's built-in ergonomics In-Reply-To: <5824E25B.2040008@oracle.com> References: <5820CC54.4010401@oracle.com> <6a3463cb-6e3f-a5cd-601a-2bb6f715eef1@oracle.com> <5824E25B.2040008@oracle.com> Message-ID: <64688e3b-41dd-224a-b990-fdc2c4c6cee6@oracle.com> Looks good! Thanks, David On 11/11/2016 7:10 AM, Kumar Srinivasan wrote: > Hi David, > > Here is the updated revision > * added back in FreeUnknowVMS > * add -client KNOWN as you suggested > > delta webrev > http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/ > > full webrev (for reference): > http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/ > > Thanks > Kumar > > > > > On 11/7/2016 3:24 PM, David Holmes wrote: >> Hi Kumar, >> >> On 8/11/2016 4:47 AM, Kumar Srinivasan wrote: >>> >>> Hello, >>> >>> Please review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8169001 >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/ >> >> Overall this looks like a complete eradication of the launcher >> ergonomics. A few specific comments: >> >> src/java.base/share/native/launcher/main.c >> >> ! const_cpwildcard, const_javaw, 0); >> >> Can you clarify this change with >> >> ! const_cpwildcard, const_javaw, 0 /* unused */); >> >> Thanks. >> >> --- >> >> src/java.base/share/native/libjli/java.c >> >> 220 jint ergo /* unused */ >> >> I assume JLI_Launch is an exported API otherwise I'd expect this to be >> deleted. The fact it is unused should also be documented in >> src/java.base/share/native/libjli/java.h. But I'm also wondering where >> this API change is being documented for external users? >> >> - FreeKnownVMs(); /* after last possible PrintUsage() */ >> >> Not clear why you no longer need to free here. But if you don't then >> FreeKnownVMs() seems to be dead code now. >> >> --- >> >> src/java.base/unix/conf/i586/jvm.cfg >> >> I think you still need an entry for "-client KNOWN" as anyone can >> build the client VM if they choose. Ditto for >> src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds >> are obsolete now). >> >> --- >> >> You have updated a number of copyright notices but not all of them. >> >> --- >> >> I see no changes to tests, but I'm pretty sure we have a test for >> server-class-machine somewhere (or we did - I recall it breaking at >> some point). >> >> Thanks, >> David >> >>> Background: >>>> Launcher ergonomics was introduced last decade to help determine >>>> if the execution system is "Server Class", this was necessary to >>>> choose server VM on platforms that supported both client and server >>>> VMs (primarily for Solaris and Linux 32-bit). >>>> >>>> The algorithm involves computing and detecting the number of CPUs >>>> and the amount of memory on the target system. All modern computers >>>> systems with hyper-threading cause the ergonomics to choose server. >>>> >>>> JDK9 Platforms that have only server vm. >>>> >>>> ./linux-x64/lib/amd64/server/libjvm.so >>>> ./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so >>>> ./solaris-sparcv9/lib/sparcv9/server/libjvm.so >>>> ./solaris-x64/lib/amd64/server/libjvm.so >>>> ./windows-x86/bin/server/jvm.dll >>>> ./windows-x64/bin/server/jvm.dll >>>> >>>> JDK9 Platforms that have more than one vm variant: >>>> ./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default) >>>> ./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so >>>> >>>> ./linux-x86/lib/i386/server/libjvm.so (default) >>>> ./linux-x86/lib/i386/minimal/libjvm.so >>>> >>>> >>>> In the cases where multiple VMs are supported the ergnomics >>>> has no effect, and the default platforms are chosen by the >>>> jvm.cfg. Thus the launcher ergonomics is obsolete and redundant. >>> >>> Thanks >>> Kumar >>> > From volker.simonis at gmail.com Mon Nov 14 10:09:46 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Nov 2016 11:09:46 +0100 Subject: RFR(XS): 8169625: Libjsig build doesn't set flags for ppc64/s390 builds Message-ID: Hi, can I please have a review and sponsor for the following small change which only affects ppc64/s390x but touches a shared make file: http://cr.openjdk.java.net/~simonis/webrevs/2016/8169625/ https://bugs.openjdk.java.net/browse/JDK-8169625 It is unfortunate that the build of the libjsig library (see make/lib/CompileLibjsig.gmk) doesn't reuse the generic compiler flags used by the hotspot build (i.e. the ones specified in JVM_CFLAGS). Instead, CompileLibjsig.gmk defines its own compiler flags in LIBJSIG_CPU_FLAGS but not for ppc64 and s390x. This leads to problems if the compiler on these platforms uses other default settings as configured for the OpenJDK build. Thank you and best regards, Volker From erik.joelsson at oracle.com Mon Nov 14 10:12:36 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Nov 2016 11:12:36 +0100 Subject: RFR: JDK-8169632: Update compare script for clean compare Message-ID: <9e87e8c8-9490-dff5-cde3-a4dceb7ee3b7@oracle.com> The build compare script needs to be updated to handle some new exceptions and tweaking some old so that we have a clean baseline again. * The special treatment of the lib/classlist file needs to apply in macosx bundle images. * Since the changes to debug symbols handling, the native comparison on Windows can be greatly simplified by just building an _NT_SYMBOL_PATH that covers all known locations for pdb files in the build output, with no need to unzip any .diz files dynamically. This removes the need for special cases which currently aren't working. * The sec-bin files on Windows now contain .pdb and .map files, which need to be added to exception list. We still have non deterministic output from javadoc which makes comparisons fail intermittently. Filing separate issue for that. Bug: https://bugs.openjdk.java.net/browse/JDK-8169632 Webrev: http://cr.openjdk.java.net/~erikj/8169632/webrev.01/ /Erik From erik.joelsson at oracle.com Mon Nov 14 10:14:00 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Nov 2016 11:14:00 +0100 Subject: RFR(XS): 8169625: Libjsig build doesn't set flags for ppc64/s390 builds In-Reply-To: References: Message-ID: Looks good. I will push it. /Erik On 2016-11-14 11:09, Volker Simonis wrote: > Hi, > > can I please have a review and sponsor for the following small change > which only affects ppc64/s390x but touches a shared make file: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8169625/ > https://bugs.openjdk.java.net/browse/JDK-8169625 > > It is unfortunate that the build of the libjsig library (see > make/lib/CompileLibjsig.gmk) doesn't reuse the generic compiler flags > used by the hotspot build (i.e. the ones specified in JVM_CFLAGS). > Instead, CompileLibjsig.gmk defines its own compiler flags in > LIBJSIG_CPU_FLAGS but not for ppc64 and s390x. This leads to problems > if the compiler on these platforms uses other default settings as > configured for the OpenJDK build. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Mon Nov 14 10:15:09 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Nov 2016 11:15:09 +0100 Subject: RFR(XS): 8169625: Libjsig build doesn't set flags for ppc64/s390 builds In-Reply-To: References: Message-ID: Thanks a lot Erik! Volker On Mon, Nov 14, 2016 at 11:14 AM, Erik Joelsson wrote: > Looks good. I will push it. > > /Erik > > > > On 2016-11-14 11:09, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and sponsor for the following small change >> which only affects ppc64/s390x but touches a shared make file: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8169625/ >> https://bugs.openjdk.java.net/browse/JDK-8169625 >> >> It is unfortunate that the build of the libjsig library (see >> make/lib/CompileLibjsig.gmk) doesn't reuse the generic compiler flags >> used by the hotspot build (i.e. the ones specified in JVM_CFLAGS). >> Instead, CompileLibjsig.gmk defines its own compiler flags in >> LIBJSIG_CPU_FLAGS but not for ppc64 and s390x. This leads to problems >> if the compiler on these platforms uses other default settings as >> configured for the OpenJDK build. >> >> Thank you and best regards, >> Volker > > From volker.simonis at gmail.com Mon Nov 14 10:19:28 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Nov 2016 11:19:28 +0100 Subject: RFR(XXS): 8169630: Fix wrong cpu build flag for Linux/ppc64le build Message-ID: Hi, can somebody please review and sponsor the following tiny build fix which only affects ppc64le but requires the re-generation of generated-config.sh: http://cr.openjdk.java.net/~simonis/webrevs/2016/8169630/ https://bugs.openjdk.java.net/browse/JDK-8169630 On ppc64le we use "-mcpu=power7 -mtune=power8" for historical reasons, but the first Power CPU with "real" little-endian support is Power8 so this should be changed to "-mcpu=power8 -mtune=power8". Thank you and best regards, Volker PS: @Erik - I promise, this is the last build change for today :) From erik.joelsson at oracle.com Mon Nov 14 10:46:32 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Nov 2016 11:46:32 +0100 Subject: RFR(XXS): 8169630: Fix wrong cpu build flag for Linux/ppc64le build In-Reply-To: References: Message-ID: <98b8ec63-7693-53da-0c1a-0905160a9d90@oracle.com> Looks good. Will sponsor. /Erik On 2016-11-14 11:19, Volker Simonis wrote: > Hi, > > can somebody please review and sponsor the following tiny build fix > which only affects ppc64le but requires the re-generation of > generated-config.sh: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8169630/ > https://bugs.openjdk.java.net/browse/JDK-8169630 > > On ppc64le we use "-mcpu=power7 -mtune=power8" for historical reasons, > but the first Power CPU with "real" little-endian support is Power8 so > this should be changed to "-mcpu=power8 -mtune=power8". > > Thank you and best regards, > Volker > > PS: @Erik - I promise, this is the last build change for today :) From tim.bell at oracle.com Mon Nov 14 15:00:21 2016 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 14 Nov 2016 07:00:21 -0800 Subject: RFR: JDK-8169632: Update compare script for clean compare In-Reply-To: <9e87e8c8-9490-dff5-cde3-a4dceb7ee3b7@oracle.com> References: <9e87e8c8-9490-dff5-cde3-a4dceb7ee3b7@oracle.com> Message-ID: <3fd59eaa-e7b3-43ed-4e3f-160cd9176df1@oracle.com> Erik: > The build compare script needs to be updated to handle some new > exceptions and tweaking some old so that we have a clean baseline again. > > * The special treatment of the lib/classlist file needs to apply in > macosx bundle images. > * Since the changes to debug symbols handling, the native comparison on > Windows can be greatly simplified by just building an _NT_SYMBOL_PATH > that covers all known locations for pdb files in the build output, with > no need to unzip any .diz files dynamically. This removes the need for > special cases which currently aren't working. > * The sec-bin files on Windows now contain .pdb and .map files, which > need to be added to exception list. > > We still have non deterministic output from javadoc which makes > comparisons fail intermittently. Filing separate issue for that. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169632 > > Webrev: http://cr.openjdk.java.net/~erikj/8169632/webrev.01/ Looks good. Tim From david.holmes at oracle.com Thu Nov 17 02:31:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Nov 2016 12:31:48 +1000 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <582D0BCE.2030209@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> Message-ID: <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> Adding in build-dev as they need to scrutinize all build changes. David On 17/11/2016 11:45 AM, Gustavo Romero wrote: > Hi, > > Currently, optimization for building fdlibm is disabled, except for the > "solaris" OS target [1]. > > As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, > sin(), cos(), and tan() perform verify poor in comparison to the same methods > in Math class [2]: > > Math StrictMath > ========= ========== > sin 0m29.984s 1m41.184s > cos 0m30.031s 1m41.200s > tan 0m31.772s 1m46.976s > asin 0m4.577s 0m4.543s > acos 0m4.539s 0m4.525s > atan 0m12.929s 0m12.896s > exp 0m1.071s 0m4.570s > log 0m3.272s 0m14.239s > log10 0m4.362s 0m20.236s > sqrt 0m0.913s 0m0.981s > cbrt 0m10.786s 0m10.808s > sinh 0m4.438s 0m4.433s > cosh 0m4.496s 0m4.478s > tanh 0m3.360s 0m3.353s > expm1 0m4.076s 0m4.094s > log1p 0m13.518s 0m13.527s > IEEEremainder 0m38.803s 0m38.909s > atan2 0m20.100s 0m20.057s > pow 0m14.096s 0m19.938s > hypot 0m5.136s 0m5.122s > > > Switching on the O3 optimization can damage precision of those methods, > nonetheless it's possible to avoid that side effect and yet get huge benefits of > the -O3 optimization on PPC64 if -fno-expensive-optimizations is passed in > addition to the -O3 optimization flag. > > In that sense the following change is proposed to resolve the issue: > > diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 > @@ -33,10 +33,16 @@ > # libfdlibm is statically linked with libjava below and not delivered into the > # product on its own. > > -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +BUILD_LIBFDLIBM_OPTIMIZATION := NONE > > -ifneq ($(OPENJDK_TARGET_OS), solaris) > - BUILD_LIBFDLIBM_OPTIMIZATION := NONE > +ifeq ($(OPENJDK_TARGET_OS), solaris) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +endif > + > +ifeq ($(OPENJDK_TARGET_OS), linux) > + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > + endif > endif > > LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm > @@ -51,6 +57,7 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ > CFLAGS_windows_debug := -DLOGGING, \ > CFLAGS_aix := -qfloat=nomaf, \ > + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ > DISABLED_WARNINGS_gcc := sign-compare, \ > DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ > ARFLAGS := $(ARFLAGS), \ > > > diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 +0100 > +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 -0500 > @@ -569,16 +569,19 @@ > $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) $$($1_EXTRA_OBJECT_FILES)) > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CFLAGS. > - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) > + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ > + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) > ifneq ($(DEBUG_LEVEL),release) > # Pickup extra debug dependent variables for CFLAGS > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) > else > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) > endif > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CXXFLAGS. > > > After enabling the optimization it's possible to again up to 3x on performance > regarding the aforementioned methods without losing precision: > > StrictMath, original StrictMath, optimized > ============================ ============================ > sin 1.7136493465700542 1m41.184s 1.7136493465700542 0m33.895s > cos 0.1709843554185943 1m41.200s 0.1709843554185943 0m33.884s > tan -5.5500322522995315E7 1m46.976s -5.5500322522995315E7 0m36.461s > asin NaN 0m4.543s NaN 0m3.175s > acos NaN 0m4.525s NaN 0m3.211s > atan 1.5707961389886132E8 0m12.896s 1.5707961389886132E8 0m7.100s > exp Infinity 0m4.570s Infinity 0m3.187s > log 1.7420680845245087E9 0m14.239s 1.7420680845245087E9 0m7.170s > log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 0m9.610s > sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 0m0.948s > cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 0m10.786s > sinh Infinity 0m4.433s Infinity 0m3.179s > cosh Infinity 0m4.478s Infinity 0m3.174s > tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 0m3.208s > expm1 Infinity 0m4.094s Infinity 0m3.185s > log1p 1.7420681029451895E9 0m13.527s 1.7420681029451895E9 0m8.756s > IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s > atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 0m10.510s > pow Infinity 0m19.938s Infinity 0m20.204s > hypot 5.000000099033372E15 0m5.122s 5.000000099033372E15 0m5.130s > > > I believe that as the FC is passed but FEC is not the change can, after the due > scrutiny and review, be pushed if a special exception approval grants it. Once > on 9, I'll request the downport to 8. > > Could I open a bug to address that issue? > > Thank you very much. > > > Regards, > Gustavo > > [1] http://hg.openjdk.java.net/jdk9/hs/jdk/file/81eb4bd34611/make/lib/CoreLibraries.gmk#l39 > [2] https://github.com/gromero/strictmath (comparison script used to get the results) > From erik.joelsson at oracle.com Thu Nov 17 09:17:33 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 Nov 2016 10:17:33 +0100 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> Message-ID: <9dea2dbf-4413-c03e-1cd6-8aceb0e263a0@oracle.com> Hello, Overall this looks reasonable to me. However, if we want to introduce a new possible tuple for specifying compilation flags to SetupNativeCompilation, we (the build team) would prefer if we used OPENJDK_TARGET_CPU instead of OPENJDK_TARGET_CPU_ARCH. /Erik On 2016-11-17 03:31, David Holmes wrote: > Adding in build-dev as they need to scrutinize all build changes. > > David > > On 17/11/2016 11:45 AM, Gustavo Romero wrote: >> Hi, >> >> Currently, optimization for building fdlibm is disabled, except for the >> "solaris" OS target [1]. >> >> As a consequence on PPC64 (Linux) StrictMath methods like, but not >> limited to, >> sin(), cos(), and tan() perform verify poor in comparison to the same >> methods >> in Math class [2]: >> >> Math StrictMath >> ========= ========== >> sin 0m29.984s 1m41.184s >> cos 0m30.031s 1m41.200s >> tan 0m31.772s 1m46.976s >> asin 0m4.577s 0m4.543s >> acos 0m4.539s 0m4.525s >> atan 0m12.929s 0m12.896s >> exp 0m1.071s 0m4.570s >> log 0m3.272s 0m14.239s >> log10 0m4.362s 0m20.236s >> sqrt 0m0.913s 0m0.981s >> cbrt 0m10.786s 0m10.808s >> sinh 0m4.438s 0m4.433s >> cosh 0m4.496s 0m4.478s >> tanh 0m3.360s 0m3.353s >> expm1 0m4.076s 0m4.094s >> log1p 0m13.518s 0m13.527s >> IEEEremainder 0m38.803s 0m38.909s >> atan2 0m20.100s 0m20.057s >> pow 0m14.096s 0m19.938s >> hypot 0m5.136s 0m5.122s >> >> >> Switching on the O3 optimization can damage precision of those methods, >> nonetheless it's possible to avoid that side effect and yet get huge >> benefits of >> the -O3 optimization on PPC64 if -fno-expensive-optimizations is >> passed in >> addition to the -O3 optimization flag. >> >> In that sense the following change is proposed to resolve the issue: >> >> diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk >> --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 >> +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 >> @@ -33,10 +33,16 @@ >> # libfdlibm is statically linked with libjava below and not >> delivered into the >> # product on its own. >> >> -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH >> +BUILD_LIBFDLIBM_OPTIMIZATION := NONE >> >> -ifneq ($(OPENJDK_TARGET_OS), solaris) >> - BUILD_LIBFDLIBM_OPTIMIZATION := NONE >> +ifeq ($(OPENJDK_TARGET_OS), solaris) >> + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH >> +endif >> + >> +ifeq ($(OPENJDK_TARGET_OS), linux) >> + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >> + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH >> + endif >> endif >> >> LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm >> @@ -51,6 +57,7 @@ >> CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ >> CFLAGS_windows_debug := -DLOGGING, \ >> CFLAGS_aix := -qfloat=nomaf, \ >> + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ >> DISABLED_WARNINGS_gcc := sign-compare, \ >> DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ >> ARFLAGS := $(ARFLAGS), \ >> >> >> diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk >> --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 >> +0100 >> +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 >> -0500 >> @@ -569,16 +569,19 @@ >> $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) >> $$($1_EXTRA_OBJECT_FILES)) >> >> # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS >> dependent variables for CFLAGS. >> - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) >> $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) >> + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) >> $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ >> + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) >> ifneq ($(DEBUG_LEVEL),release) >> # Pickup extra debug dependent variables for CFLAGS >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) >> + >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) >> else >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) >> + >> $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) >> endif >> >> # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS >> dependent variables for CXXFLAGS. >> >> >> After enabling the optimization it's possible to again up to 3x on >> performance >> regarding the aforementioned methods without losing precision: >> >> StrictMath, original StrictMath, optimized >> ============================ >> ============================ >> sin 1.7136493465700542 1m41.184s 1.7136493465700542 >> 0m33.895s >> cos 0.1709843554185943 1m41.200s 0.1709843554185943 >> 0m33.884s >> tan -5.5500322522995315E7 1m46.976s >> -5.5500322522995315E7 0m36.461s >> asin NaN 0m4.543s >> NaN 0m3.175s >> acos NaN 0m4.525s >> NaN 0m3.211s >> atan 1.5707961389886132E8 0m12.896s >> 1.5707961389886132E8 0m7.100s >> exp Infinity 0m4.570s Infinity 0m3.187s >> log 1.7420680845245087E9 0m14.239s >> 1.7420680845245087E9 0m7.170s >> log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 >> 0m9.610s >> sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 >> 0m0.948s >> cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 >> 0m10.786s >> sinh Infinity 0m4.433s Infinity 0m3.179s >> cosh Infinity 0m4.478s Infinity 0m3.174s >> tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 >> 0m3.208s >> expm1 Infinity 0m4.094s Infinity 0m3.185s >> log1p 1.7420681029451895E9 0m13.527s >> 1.7420681029451895E9 0m8.756s >> IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s >> atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 >> 0m10.510s >> pow Infinity 0m19.938s Infinity 0m20.204s >> hypot 5.000000099033372E15 0m5.122s >> 5.000000099033372E15 0m5.130s >> >> >> I believe that as the FC is passed but FEC is not the change can, >> after the due >> scrutiny and review, be pushed if a special exception approval grants >> it. Once >> on 9, I'll request the downport to 8. >> >> Could I open a bug to address that issue? >> >> Thank you very much. >> >> >> Regards, >> Gustavo >> >> [1] >> http://hg.openjdk.java.net/jdk9/hs/jdk/file/81eb4bd34611/make/lib/CoreLibraries.gmk#l39 >> [2] https://github.com/gromero/strictmath (comparison script used to >> get the results) >> From magnus.ihse.bursie at oracle.com Thu Nov 17 09:27:24 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 17 Nov 2016 10:27:24 +0100 Subject: RFR: JDK-8169860 Clean up and unify the refactored Javadoc generation Message-ID: <07a2aa22-75d8-c109-3dc7-ef7ca1ecec7d@oracle.com> This is a follow-up to JDK-8168772 . In that bug, the goal was to just refactor the generation, and keep output identical, by whatever means neccessary. This bug takes the final step, and cleans up the code. The changes will have the following kind of effects: 1) The .options files will change, but it will not affect the generated Javadoc. 2) The generated Javadoc will change, but it is a bug fix since the old Javadoc was broken. 3) The generated Javadoc will change, but the change is minor and is just intended root out odd special cases to make all Javadoc look more the same. On top of that are some more changes to clean up the build logic. Here is a list of actual changes: * DependOnVariable now handles # properly (patch by Erik!) * Automatically determine core packages * Bug fix: use iso-8859-1 encoding everywhere to avoid broken characters * Bug fix: use proper link reference to coredocs from jshell * "Invert" doclint behaviour, so we need to explicitely disable those that causes warnings * Enable all passing doclint checks * Fix workarounds introduced in previous Javadoc cleanup used needed to keep consistency with .options/.packages files * Increase consistency by removing odd behavior for individual javadoc packages * Remove [NON_]CORE_PKGS.gmk. * Simplify hard-coded texts * Add -notimestamp to make javadocs comparable between builds * Ensure split index is used in all cases where the index file is >= ~200 kB. * Clarify non-GA build titles Bug: https://bugs.openjdk.java.net/browse/JDK-8169860 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8169860-simplify-javadoc/webrev.01 /Magnus From joe.darcy at oracle.com Thu Nov 17 17:35:05 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 17 Nov 2016 09:35:05 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <582D0BCE.2030209@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> Message-ID: Hello, On 11/16/2016 5:45 PM, Gustavo Romero wrote: > Hi, > > Currently, optimization for building fdlibm is disabled, except for the > "solaris" OS target [1]. The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. > > As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, > sin(), cos(), and tan() perform verify poor in comparison to the same methods > in Math class [2]: If you are doing your work against JDK 9, note that the pow, hypot, and cbrt fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: Port fdlibm to Java). I have intentions to port the remaining methods to Java, but it is unclear whether or not this will occur for JDK 9. Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. > > Math StrictMath > ========= ========== > sin 0m29.984s 1m41.184s > cos 0m30.031s 1m41.200s > tan 0m31.772s 1m46.976s > asin 0m4.577s 0m4.543s > acos 0m4.539s 0m4.525s > atan 0m12.929s 0m12.896s > exp 0m1.071s 0m4.570s > log 0m3.272s 0m14.239s > log10 0m4.362s 0m20.236s > sqrt 0m0.913s 0m0.981s > cbrt 0m10.786s 0m10.808s > sinh 0m4.438s 0m4.433s > cosh 0m4.496s 0m4.478s > tanh 0m3.360s 0m3.353s > expm1 0m4.076s 0m4.094s > log1p 0m13.518s 0m13.527s > IEEEremainder 0m38.803s 0m38.909s > atan2 0m20.100s 0m20.057s > pow 0m14.096s 0m19.938s > hypot 0m5.136s 0m5.122s > > > Switching on the O3 optimization can damage precision of those methods, > nonetheless it's possible to avoid that side effect and yet get huge benefits of > the -O3 optimization on PPC64 if -fno-expensive-optimizations is passed in > addition to the -O3 optimization flag. > > In that sense the following change is proposed to resolve the issue: > > diff -r 81eb4bd34611 make/lib/CoreLibraries.gmk > --- a/make/lib/CoreLibraries.gmk Wed Nov 09 13:37:19 2016 +0100 > +++ b/make/lib/CoreLibraries.gmk Wed Nov 16 19:11:11 2016 -0500 > @@ -33,10 +33,16 @@ > # libfdlibm is statically linked with libjava below and not delivered into the > # product on its own. > > -BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +BUILD_LIBFDLIBM_OPTIMIZATION := NONE > > -ifneq ($(OPENJDK_TARGET_OS), solaris) > - BUILD_LIBFDLIBM_OPTIMIZATION := NONE > +ifeq ($(OPENJDK_TARGET_OS), solaris) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > +endif > + > +ifeq ($(OPENJDK_TARGET_OS), linux) > + ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) > + BUILD_LIBFDLIBM_OPTIMIZATION := HIGH > + endif > endif > > LIBFDLIBM_SRC := $(JDK_TOPDIR)/src/java.base/share/native/libfdlibm > @@ -51,6 +57,7 @@ > CFLAGS := $(CFLAGS_JDKLIB) $(LIBFDLIBM_CFLAGS), \ > CFLAGS_windows_debug := -DLOGGING, \ > CFLAGS_aix := -qfloat=nomaf, \ > + CFLAGS_linux_ppc := -fno-expensive-optimizations, \ > DISABLED_WARNINGS_gcc := sign-compare, \ > DISABLED_WARNINGS_microsoft := 4146 4244 4018, \ > ARFLAGS := $(ARFLAGS), \ > > > diff -r 2a1f97c0ad3d make/common/NativeCompilation.gmk > --- a/make/common/NativeCompilation.gmk Wed Nov 09 15:32:39 2016 +0100 > +++ b/make/common/NativeCompilation.gmk Wed Nov 16 19:08:06 2016 -0500 > @@ -569,16 +569,19 @@ > $1_ALL_OBJS := $$(sort $$($1_EXPECTED_OBJS) $$($1_EXTRA_OBJECT_FILES)) > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CFLAGS. > - $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) > + $1_EXTRA_CFLAGS:=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CFLAGS_$(OPENJDK_TARGET_OS)) \ > + $$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)) > ifneq ($(DEBUG_LEVEL),release) > # Pickup extra debug dependent variables for CFLAGS > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_debug) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_debug) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_debug) > else > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS_TYPE)_release) > $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_release) > + $1_EXTRA_CFLAGS+=$$($1_CFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU_ARCH)_release) > endif > > # Pickup extra OPENJDK_TARGET_OS_TYPE and/or OPENJDK_TARGET_OS dependent variables for CXXFLAGS. > > > After enabling the optimization it's possible to again up to 3x on performance > regarding the aforementioned methods without losing precision: > > StrictMath, original StrictMath, optimized > ============================ ============================ > sin 1.7136493465700542 1m41.184s 1.7136493465700542 0m33.895s > cos 0.1709843554185943 1m41.200s 0.1709843554185943 0m33.884s > tan -5.5500322522995315E7 1m46.976s -5.5500322522995315E7 0m36.461s > asin NaN 0m4.543s NaN 0m3.175s > acos NaN 0m4.525s NaN 0m3.211s > atan 1.5707961389886132E8 0m12.896s 1.5707961389886132E8 0m7.100s > exp Infinity 0m4.570s Infinity 0m3.187s > log 1.7420680845245087E9 0m14.239s 1.7420680845245087E9 0m7.170s > log10 7.565705562087342E8 0m20.236s 7.565705562087342E8 0m9.610s > sqrt 6.66666671666567E11 0m0.981s 6.66666671666567E11 0m0.948s > cbrt 3.481191648389617E10 0m10.808s 3.481191648389617E10 0m10.786s > sinh Infinity 0m4.433s Infinity 0m3.179s > cosh Infinity 0m4.478s Infinity 0m3.174s > tanh 9.999999971990079E7 0m3.353s 9.999999971990079E7 0m3.208s > expm1 Infinity 0m4.094s Infinity 0m3.185s > log1p 1.7420681029451895E9 0m13.527s 1.7420681029451895E9 0m8.756s > IEEEremainder 502000.0 0m38.909s 502000.0 0m14.055s > atan2 1.570453905253704E8 0m20.057s 1.570453905253704E8 0m10.510s > pow Infinity 0m19.938s Infinity 0m20.204s > hypot 5.000000099033372E15 0m5.122s 5.000000099033372E15 0m5.130s > > > I believe that as the FC is passed but FEC is not the change can, after the due > scrutiny and review, be pushed if a special exception approval grants it. Once > on 9, I'll request the downport to 8. Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. Cheers, -Joe From gromero at linux.vnet.ibm.com Thu Nov 17 17:45:59 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Nov 2016 15:45:59 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> Message-ID: <582DECD7.4020901@linux.vnet.ibm.com> Hi David, On 17-11-2016 00:31, David Holmes wrote: > Adding in build-dev as they need to scrutinize all build changes. Thanks a lot. Regards, Gustavo From gromero at linux.vnet.ibm.com Thu Nov 17 17:47:40 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Nov 2016 15:47:40 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <9dea2dbf-4413-c03e-1cd6-8aceb0e263a0@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <37b58c35-72b2-cc19-f175-6d1cff410213@oracle.com> <9dea2dbf-4413-c03e-1cd6-8aceb0e263a0@oracle.com> Message-ID: <582DED3C.5030507@linux.vnet.ibm.com> Hi Erik, On 17-11-2016 07:17, Erik Joelsson wrote: > Overall this looks reasonable to me. However, if we want to introduce a new possible tuple for specifying compilation flags to SetupNativeCompilation, we (the build team) would prefer if we used > OPENJDK_TARGET_CPU instead of OPENJDK_TARGET_CPU_ARCH. Got it. Thanks a lot for that info. I'll take that into account. Regards, Gustavo From gromero at linux.vnet.ibm.com Thu Nov 17 18:31:00 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 17 Nov 2016 16:31:00 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> Message-ID: <582DF764.70504@linux.vnet.ibm.com> Hi Joe, Thanks a lot for your valuable comments. On 17-11-2016 15:35, joe darcy wrote: >> Currently, optimization for building fdlibm is disabled, except for the >> "solaris" OS target [1]. > > The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the > Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does not affect the precision, even if setting -O3 does not improve the performance as much as on PPC64. >> As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, >> sin(), cos(), and tan() perform verify poor in comparison to the same methods >> in Math class [2]: > > If you are doing your work against JDK 9, note that the pow, hypot, and cbrt fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: Port fdlibm to Java). I have intentions to > port the remaining methods to Java, but it is unclear whether or not this will occur for JDK 9. Yes, I'm doing my work against 9. So is there any problem if I proceed with my change? I understand that there is no conflict as JDK-8134780 progresses and replaces the StrictMath methods by their counterparts in Java. Please, advice. Is it intended to downport JDK-8134780 to 8? > Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. I agree. It's just that the issue on StrictMath methods was first noted due to that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. > Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. > The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. That's really good point, thanks for letting me know about that. I'll re-test my change under that perspective. > Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. Got it. By "the JDK math library regression tests" you mean exactly which test suite? the jtreg tests? For testing against JCK/TCK I'll need some help on that. Thank you very much. Regards, Gustavo From joe.darcy at oracle.com Thu Nov 17 21:33:48 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 17 Nov 2016 13:33:48 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <582DF764.70504@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> Message-ID: Hi Gustavo, On 11/17/2016 10:31 AM, Gustavo Romero wrote: > Hi Joe, > > Thanks a lot for your valuable comments. > > On 17-11-2016 15:35, joe darcy wrote: >>> Currently, optimization for building fdlibm is disabled, except for the >>> "solaris" OS target [1]. >> The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the >> Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. > oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm > optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does > not affect the precision, even if setting -O3 does not improve the performance > as much as on PPC64. The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would run afoul of these fdlibm coding practices. >>> As a consequence on PPC64 (Linux) StrictMath methods like, but not limited to, >>> sin(), cos(), and tan() perform verify poor in comparison to the same methods >>> in Math class [2]: >> If you are doing your work against JDK 9, note that the pow, hypot, and cbrt fdlibm methods required by StrictMath have been ported to Java (JDK-8134780: Port fdlibm to Java). I have intentions to >> port the remaining methods to Java, but it is unclear whether or not this will occur for JDK 9. > Yes, I'm doing my work against 9. So is there any problem if I proceed with my > change? I understand that there is no conflict as JDK-8134780 progresses and > replaces the StrictMath methods by their counterparts in Java. Please, advice. If I manage to finish the fdlibm C -> Java port in JDK 9, the changes you are proposing would eventually be removed as unneeded since the C code wouldn't be there to get compiled anymore. > > Is it intended to downport JDK-8134780 to 8? Such a backport would be technically possible, but we at Oracle don't currently plan to do so. > > >> Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. > I agree. It's just that the issue on StrictMath methods was first noted due to > that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. Depending on how Math.{sin, cos} is implemented on PPC64, compiling the fdlibm sin/cos with more aggressive optimizations should not be expected to close the performance gap. In particular, if Math.{sin, cos} is an intrinsic on PPC64 (I haven't checked the sources) that used platform-specific feature (say fused multiply add instructions) then just compiling fdlibm more aggressively wouldn't necessarily make up that gap. To allow cross-platform and cross-release reproducibility, StrictMath is specified to use the particular fdlibm algorithms, which precludes using better algorithms developed more recently. If we were to start with a clean slate today, to get such reproducibility we would specify correctly-rounded behavior of all those methods, but such an approach was much less tractable technical 20+ years ago without benefit of the research that was been done in the interim, such as the work of Prof. Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > > >> Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. >> The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. > That's really good point, thanks for letting me know about that. I'll re-test my > change under that perspective. > > >> Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. > Got it. By "the JDK math library regression tests" you mean exactly which test > suite? the jtreg tests? Specifically, the regression tests under test/java/lang/Math and test/java/lang/StrictMath in the jdk repository. There are some other math library tests in the hotspot repo, but I don't know where they are offhand. A note on methodologies, when I've been writing test for my port I've tried to include test cases that exercise all the branches point in the code. Due to the large input space (~2^64 for a single-argument method), random sampling alone is an inefficient way to try to find differences in behavior. > For testing against JCK/TCK I'll need some help on that. > I believe the JCK/TCK does have additional testcases relevant here. HTH; thanks, -Joe From chris.plummer at oracle.com Thu Nov 17 21:48:36 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 17 Nov 2016 13:48:36 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> Message-ID: <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> On 11/17/16 1:33 PM, joe darcy wrote: > Hi Gustavo, > > > On 11/17/2016 10:31 AM, Gustavo Romero wrote: >> Hi Joe, >> >> Thanks a lot for your valuable comments. >> >> On 17-11-2016 15:35, joe darcy wrote: >>>> Currently, optimization for building fdlibm is disabled, except for >>>> the >>>> "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers >>> have had sufficient discipline and control regarding floating-point >>> semantics and compiler optimizations to still implement the >>> Java-mandated results when optimization was enabled. The gcc family >>> of compilers, for example, has lacked such discipline. >> oh, I see. Thanks for clarifying that. I was exactly wondering why >> fdlibm >> optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 >> only, does >> not affect the precision, even if setting -O3 does not improve the >> performance >> as much as on PPC64. > > The fdlibm code relies on aliasing a two-element array of int with a > double to do bit-level reads and writes of floating-point values. As I > understand it, the C spec allows compilers to assume values of > different types don't overlap in memory. The compilation environment > has to be configured in such a way that the C compiler disables code > generation and optimization techniques that would run afoul of these > fdlibm coding practices. This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more than 12 years since I last dealt with fdlibm and compiler aliasing issues. Chris > >>>> As a consequence on PPC64 (Linux) StrictMath methods like, but not >>>> limited to, >>>> sin(), cos(), and tan() perform verify poor in comparison to the >>>> same methods >>>> in Math class [2]: >>> If you are doing your work against JDK 9, note that the pow, hypot, >>> and cbrt fdlibm methods required by StrictMath have been ported to >>> Java (JDK-8134780: Port fdlibm to Java). I have intentions to >>> port the remaining methods to Java, but it is unclear whether or not >>> this will occur for JDK 9. >> Yes, I'm doing my work against 9. So is there any problem if I >> proceed with my >> change? I understand that there is no conflict as JDK-8134780 >> progresses and >> replaces the StrictMath methods by their counterparts in Java. >> Please, advice. > > If I manage to finish the fdlibm C -> Java port in JDK 9, the changes > you are proposing would eventually be removed as unneeded since the C > code wouldn't be there to get compiled anymore. > >> >> Is it intended to downport JDK-8134780 to 8? > > Such a backport would be technically possible, but we at Oracle don't > currently plan to do so. > >> >> >>> Methods in the Math class, such as pow, are often intrinsified and >>> use a different algorithm so a straight performance comparison may >>> not be as fair or meaningful in those cases. >> I agree. It's just that the issue on StrictMath methods was first >> noted due to >> that huge gap (Math vs StrictMath) on PPC64, which is not prominent >> on x64. > > Depending on how Math.{sin, cos} is implemented on PPC64, compiling > the fdlibm sin/cos with more aggressive optimizations should not be > expected to close the performance gap. In particular, if Math.{sin, > cos} is an intrinsic on PPC64 (I haven't checked the sources) that > used platform-specific feature (say fused multiply add instructions) > then just compiling fdlibm more aggressively wouldn't necessarily make > up that gap. > > To allow cross-platform and cross-release reproducibility, StrictMath > is specified to use the particular fdlibm algorithms, which precludes > using better algorithms developed more recently. If we were to start > with a clean slate today, to get such reproducibility we would specify > correctly-rounded behavior of all those methods, but such an approach > was much less tractable technical 20+ years ago without benefit of the > research that was been done in the interim, such as the work of Prof. > Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > >> >> >>> Accumulating the the results of the functions and comparisons the >>> sums is not a sufficiently robust way of checking to see if the >>> optimized versions are indeed equivalent to the non-optimized ones. >>> The specification of StrictMath requires a particular result for >>> each set of floating-point arguments and sums get round-away >>> low-order bits that differ. >> That's really good point, thanks for letting me know about that. I'll >> re-test my >> change under that perspective. >> >> >>> Running the JDK math library regression tests and corresponding JCK >>> tests is recommended for work in this area. >> Got it. By "the JDK math library regression tests" you mean exactly >> which test >> suite? the jtreg tests? > > Specifically, the regression tests under test/java/lang/Math and > test/java/lang/StrictMath in the jdk repository. There are some other > math library tests in the hotspot repo, but I don't know where they > are offhand. > > A note on methodologies, when I've been writing test for my port I've > tried to include test cases that exercise all the branches point in > the code. Due to the large input space (~2^64 for a single-argument > method), random sampling alone is an inefficient way to try to find > differences in behavior. >> For testing against JCK/TCK I'll need some help on that. >> > > I believe the JCK/TCK does have additional testcases relevant here. > > HTH; thanks, > > -Joe From Derek.White at cavium.com Thu Nov 17 22:47:58 2016 From: Derek.White at cavium.com (White, Derek) Date: Thu, 17 Nov 2016 22:47:58 +0000 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> Message-ID: Hi Joe, Although neither a floating point expert (as I think I've proven to you over the years), or a gcc expert, I checked with our in-house gcc expert and got this following answer: "Yes using -fno-strict-aliasing fixes the issues. Also there are many forks of fdlibm which has this fixed including the code inside glibc. " FWIW, - Derek -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Chris Plummer Sent: Thursday, November 17, 2016 4:49 PM To: joe darcy ; Gustavo Romero ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: build-dev Subject: Re: PPC64: Poor StrictMath performance due to non-optimized compilation On 11/17/16 1:33 PM, joe darcy wrote: > Hi Gustavo, > > > On 11/17/2016 10:31 AM, Gustavo Romero wrote: >> Hi Joe, >> >> Thanks a lot for your valuable comments. >> >> On 17-11-2016 15:35, joe darcy wrote: >>>> Currently, optimization for building fdlibm is disabled, except for >>>> the "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers >>> have had sufficient discipline and control regarding floating-point >>> semantics and compiler optimizations to still implement the >>> Java-mandated results when optimization was enabled. The gcc family >>> of compilers, for example, has lacked such discipline. >> oh, I see. Thanks for clarifying that. I was exactly wondering why >> fdlibm optimization is off even for x86_x64 as it, AFAICS regarding >> gcc 5 only, does not affect the precision, even if setting -O3 does >> not improve the performance as much as on PPC64. > > The fdlibm code relies on aliasing a two-element array of int with a > double to do bit-level reads and writes of floating-point values. As I > understand it, the C spec allows compilers to assume values of > different types don't overlap in memory. The compilation environment > has to be configured in such a way that the C compiler disables code > generation and optimization techniques that would run afoul of these > fdlibm coding practices. This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more than 12 years since I last dealt with fdlibm and compiler aliasing issues. Chris > >>>> As a consequence on PPC64 (Linux) StrictMath methods like, but not >>>> limited to, sin(), cos(), and tan() perform verify poor in >>>> comparison to the same methods in Math class [2]: >>> If you are doing your work against JDK 9, note that the pow, hypot, >>> and cbrt fdlibm methods required by StrictMath have been ported to >>> Java (JDK-8134780: Port fdlibm to Java). I have intentions to port >>> the remaining methods to Java, but it is unclear whether or not this >>> will occur for JDK 9. >> Yes, I'm doing my work against 9. So is there any problem if I >> proceed with my change? I understand that there is no conflict as >> JDK-8134780 progresses and replaces the StrictMath methods by their >> counterparts in Java. >> Please, advice. > > If I manage to finish the fdlibm C -> Java port in JDK 9, the changes > you are proposing would eventually be removed as unneeded since the C > code wouldn't be there to get compiled anymore. > >> >> Is it intended to downport JDK-8134780 to 8? > > Such a backport would be technically possible, but we at Oracle don't > currently plan to do so. > >> >> >>> Methods in the Math class, such as pow, are often intrinsified and >>> use a different algorithm so a straight performance comparison may >>> not be as fair or meaningful in those cases. >> I agree. It's just that the issue on StrictMath methods was first >> noted due to that huge gap (Math vs StrictMath) on PPC64, which is >> not prominent on x64. > > Depending on how Math.{sin, cos} is implemented on PPC64, compiling > the fdlibm sin/cos with more aggressive optimizations should not be > expected to close the performance gap. In particular, if Math.{sin, > cos} is an intrinsic on PPC64 (I haven't checked the sources) that > used platform-specific feature (say fused multiply add instructions) > then just compiling fdlibm more aggressively wouldn't necessarily make > up that gap. > > To allow cross-platform and cross-release reproducibility, StrictMath > is specified to use the particular fdlibm algorithms, which precludes > using better algorithms developed more recently. If we were to start > with a clean slate today, to get such reproducibility we would specify > correctly-rounded behavior of all those methods, but such an approach > was much less tractable technical 20+ years ago without benefit of the > research that was been done in the interim, such as the work of Prof. > Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > >> >> >>> Accumulating the the results of the functions and comparisons the >>> sums is not a sufficiently robust way of checking to see if the >>> optimized versions are indeed equivalent to the non-optimized ones. >>> The specification of StrictMath requires a particular result for >>> each set of floating-point arguments and sums get round-away >>> low-order bits that differ. >> That's really good point, thanks for letting me know about that. I'll >> re-test my change under that perspective. >> >> >>> Running the JDK math library regression tests and corresponding JCK >>> tests is recommended for work in this area. >> Got it. By "the JDK math library regression tests" you mean exactly >> which test >> suite? the jtreg tests? > > Specifically, the regression tests under test/java/lang/Math and > test/java/lang/StrictMath in the jdk repository. There are some other > math library tests in the hotspot repo, but I don't know where they > are offhand. > > A note on methodologies, when I've been writing test for my port I've > tried to include test cases that exercise all the branches point in > the code. Due to the large input space (~2^64 for a single-argument > method), random sampling alone is an inefficient way to try to find > differences in behavior. >> For testing against JCK/TCK I'll need some help on that. >> > > I believe the JCK/TCK does have additional testcases relevant here. > > HTH; thanks, > > -Joe From erik.joelsson at oracle.com Fri Nov 18 13:16:11 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Nov 2016 14:16:11 +0100 Subject: RFR: JDK-8169860 Clean up and unify the refactored Javadoc generation In-Reply-To: <07a2aa22-75d8-c109-3dc7-ef7ca1ecec7d@oracle.com> References: <07a2aa22-75d8-c109-3dc7-ef7ca1ecec7d@oracle.com> Message-ID: <55907f56-575b-b74b-e631-2303ee3d3f54@oracle.com> Looks good to me. /Erik On 2016-11-17 10:27, Magnus Ihse Bursie wrote: > This is a follow-up to JDK-8168772 > . In that bug, the > goal was to just refactor the generation, and keep output identical, > by whatever means neccessary. > > This bug takes the final step, and cleans up the code. The changes > will have the following kind of effects: > > 1) The .options files will change, but it will not affect the > generated Javadoc. > 2) The generated Javadoc will change, but it is a bug fix since the > old Javadoc was broken. > 3) The generated Javadoc will change, but the change is minor and is > just intended root out odd special cases to make all Javadoc look more > the same. > > On top of that are some more changes to clean up the build logic. > > Here is a list of actual changes: > > * DependOnVariable now handles # properly (patch by Erik!) > * Automatically determine core packages > * Bug fix: use iso-8859-1 encoding everywhere to avoid broken characters > * Bug fix: use proper link reference to coredocs from jshell > * "Invert" doclint behaviour, so we need to explicitely disable those > that causes warnings > * Enable all passing doclint checks > * Fix workarounds introduced in previous Javadoc cleanup used needed > to keep consistency with .options/.packages files > * Increase consistency by removing odd behavior for individual javadoc > packages > * Remove [NON_]CORE_PKGS.gmk. > * Simplify hard-coded texts > * Add -notimestamp to make javadocs comparable between builds > * Ensure split index is used in all cases where the index file is >= > ~200 kB. > * Clarify non-GA build titles > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169860 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8169860-simplify-javadoc/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Fri Nov 18 15:30:20 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 Nov 2016 16:30:20 +0100 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images Message-ID: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Hello, Please review this change which removes the $ARCH sub directory in the lib directory of the runtime images, which is an outstanding issue from the new runtime images. Most of the changes are in the build, but there are some in hotspot and launcher source. I have verified -testset hotspot and default in JPRT as well as tried to run as many jtreg tests as possible locally. I could only really find two tests that needed to be adjusted. Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 /Erik From tim.bell at oracle.com Fri Nov 18 16:34:03 2016 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 18 Nov 2016 08:34:03 -0800 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: <9846f58b-0c80-b8ce-674f-cf3fd239b01f@oracle.com> Erik: > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue from > the new runtime images. Most of the changes are in the build, but there > are some in hotspot and launcher source. I have verified -testset > hotspot and default in JPRT as well as tried to run as many jtreg tests > as possible locally. I could only really find two tests that needed to > be adjusted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 hotspot/test/runtime/ThreadSignalMask/exeThreadSignalMask.c jdk/make/copy/Copy-java.desktop.gmk jdk/src/java.base/unix/classes/java/lang/ProcessImpl.java These legal notices need to be updated for 2016. No need to redo the webrev if this is all the feedback you get. Looks fine otherwise. Tim From vladimir.kozlov at oracle.com Fri Nov 18 16:41:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 18 Nov 2016 08:41:29 -0800 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Finally! :) Hotspot changes looks fine to me. But you missed hotspot/make/hotspot.script file. Our colleges in RH and SAP should test these changes on their platforms. Next step would be removal of client/server sub-directories on platforms where we have only Server JVM (64-bit JDK has only Server JVM). Thanks, Vladimir On 11/18/16 7:30 AM, Erik Joelsson wrote: > Hello, > > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue from > the new runtime images. Most of the changes are in the build, but there > are some in hotspot and launcher source. I have verified -testset > hotspot and default in JPRT as well as tried to run as many jtreg tests > as possible locally. I could only really find two tests that needed to > be adjusted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > > /Erik > From magnus.ihse.bursie at oracle.com Fri Nov 18 20:40:58 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Nov 2016 21:40:58 +0100 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: On 2016-11-18 16:30, Erik Joelsson wrote: > Hello, > > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue > from the new runtime images. Most of the changes are in the build, but > there are some in hotspot and launcher source. I have verified > -testset hotspot and default in JPRT as well as tried to run as many > jtreg tests as possible locally. I could only really find two tests > that needed to be adjusted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 Looks good to me. If anything, the switch statement in ProcessImpl.java seems superfluous now, and you could possibly prune that bit even harder. Nice to see this go. :) /Magnus From magnus.ihse.bursie at oracle.com Mon Nov 21 09:25:32 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 21 Nov 2016 10:25:32 +0100 Subject: RFR: JDK-8170077 Properly parallelize javadoc generation Message-ID: The current javadoc generation first creates the coredocs Javadoc, and after that all the remaining javadoc instances. This dependency is not really needed, all that is required is that the remaining javadoc instances gets a proper pointer to a package-list file for coredocs. Fixing that will allow them to run in parallel with the coredoc generation. In addition to this performance fix, I've also cleaned up the (now unnecessary) logic of storing the javadoc command line in .options/.packages files. Bug: https://bugs.openjdk.java.net/browse/JDK-8170077 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8170077-parallelize-javadoc/webrev.01 /Magnus From Alan.Burlison at oracle.com Mon Nov 21 11:14:19 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Mon, 21 Nov 2016 11:14:19 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> Message-ID: <00f0f008-fe90-2940-d176-47c17f4fdf9a@oracle.com> On 18/11/16 15:30, Erik Joelsson wrote: > Please review this change which removes the $ARCH sub directory in the > lib directory of the runtime images, which is an outstanding issue from > the new runtime images. Most of the changes are in the build, but there > are some in hotspot and launcher source. I have verified -testset > hotspot and default in JPRT as well as tried to run as many jtreg tests > as possible locally. I could only really find two tests that needed to > be adjusted. This directly impacts on another bug which I'm in the process of investigating. On Solaris it was always possible to directly execute a JAR file as the kernel knows how to handle them, via jexec. When 32-bit support for Solaris was removed this broke as the 64-bit version of jexec was not being built. The fix is easy but it appears jexec is delivered into the $ARCH directory, and that location is hard-coded into the Solaris kernel, and is covered by a cross-product engineering contract. In the case of jexec that contract needs modifying, what I don't know is if there are any other similar cross-product dependencies that will be affected by this change. -- Alan Burlison -- From goetz.lindenmaier at sap.com Mon Nov 21 11:35:20 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Nov 2016 11:35:20 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: <1156e3bb13944547977e904fd8d79ccb@DEROTE13DE08.global.corp.sap> Hi, we appreciate this change a lot, and also if /server would go away. I built and tested it on linuxppcle, aixppc and linuxs390. There is still a place that refers to a removed variables and breaks the build: jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME You can probably just replace LIBARCHNAME by ARCH which is set to the same value. I would propose to remove VM_CPU from hotspot/test/test_env.sh after you removed the last place where it is used. (VM_BITS is dead, too.) Best regards, Goetz. > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Vladimir Kozlov > Sent: Freitag, 18. November 2016 17:41 > To: Erik Joelsson ; build-dev dev at openjdk.java.net>; core-libs-dev ; > hotspot-dev developers > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > and Solaris images > > Finally! :) > > Hotspot changes looks fine to me. But you missed > hotspot/make/hotspot.script file. > > Our colleges in RH and SAP should test these changes on their platforms. > > Next step would be removal of client/server sub-directories on platforms > where we have only Server JVM (64-bit JDK has only Server JVM). > > Thanks, > Vladimir > > On 11/18/16 7:30 AM, Erik Joelsson wrote: > > Hello, > > > > Please review this change which removes the $ARCH sub directory in the > > lib directory of the runtime images, which is an outstanding issue from > > the new runtime images. Most of the changes are in the build, but there > > are some in hotspot and launcher source. I have verified -testset > > hotspot and default in JPRT as well as tried to run as many jtreg tests > > as possible locally. I could only really find two tests that needed to > > be adjusted. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > > > > /Erik > > From goetz.lindenmaier at sap.com Mon Nov 21 13:10:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Nov 2016 13:10:15 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: Hi, linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function ServerClassMachineImpl: jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) before LIBARCHNAME Best regards, Goetz > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 21. November 2016 12:35 > To: 'Vladimir Kozlov' ; Erik Joelsson > ; build-dev ; > core-libs-dev ; hotspot-dev developers > > Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > and Solaris images > > Hi, > > we appreciate this change a lot, and also if /server would go away. > > I built and tested it on linuxppcle, aixppc and linuxs390. > > There is still a place that refers to a removed variables > and breaks the build: > jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME > You can probably just replace LIBARCHNAME by ARCH which is set to > the same value. > > I would propose to remove VM_CPU from hotspot/test/test_env.sh after > you > removed the last place where it is used. (VM_BITS is dead, too.) > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > > Behalf Of Vladimir Kozlov > > Sent: Freitag, 18. November 2016 17:41 > > To: Erik Joelsson ; build-dev > dev at openjdk.java.net>; core-libs-dev ; > > hotspot-dev developers > > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > > and Solaris images > > > > Finally! :) > > > > Hotspot changes looks fine to me. But you missed > > hotspot/make/hotspot.script file. > > > > Our colleges in RH and SAP should test these changes on their platforms. > > > > Next step would be removal of client/server sub-directories on platforms > > where we have only Server JVM (64-bit JDK has only Server JVM). > > > > Thanks, > > Vladimir > > > > On 11/18/16 7:30 AM, Erik Joelsson wrote: > > > Hello, > > > > > > Please review this change which removes the $ARCH sub directory in the > > > lib directory of the runtime images, which is an outstanding issue from > > > the new runtime images. Most of the changes are in the build, but there > > > are some in hotspot and launcher source. I have verified -testset > > > hotspot and default in JPRT as well as tried to run as many jtreg tests > > > as possible locally. I could only really find two tests that needed to > > > be adjusted. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > > > > > > Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > > > > > > /Erik > > > From erik.joelsson at oracle.com Mon Nov 21 13:26:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 Nov 2016 14:26:54 +0100 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: Hello Goetz, Thanks for trying this out. Note that the ergo* files were removed in JDK-8169001 which is currently in jdk9/dev but not yet in hs. /Erik On 2016-11-21 14:10, Lindenmaier, Goetz wrote: > Hi, > > linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: > > jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function ServerClassMachineImpl: > jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) before LIBARCHNAME > > Best regards, > Goetz > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Montag, 21. November 2016 12:35 >> To: 'Vladimir Kozlov' ; Erik Joelsson >> ; build-dev ; >> core-libs-dev ; hotspot-dev developers >> >> Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux >> and Solaris images >> >> Hi, >> >> we appreciate this change a lot, and also if /server would go away. >> >> I built and tested it on linuxppcle, aixppc and linuxs390. >> >> There is still a place that refers to a removed variables >> and breaks the build: >> jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME >> You can probably just replace LIBARCHNAME by ARCH which is set to >> the same value. >> >> I would propose to remove VM_CPU from hotspot/test/test_env.sh after >> you >> removed the last place where it is used. (VM_BITS is dead, too.) >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >>> Behalf Of Vladimir Kozlov >>> Sent: Freitag, 18. November 2016 17:41 >>> To: Erik Joelsson ; build-dev >> dev at openjdk.java.net>; core-libs-dev ; >>> hotspot-dev developers >>> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux >>> and Solaris images >>> >>> Finally! :) >>> >>> Hotspot changes looks fine to me. But you missed >>> hotspot/make/hotspot.script file. >>> >>> Our colleges in RH and SAP should test these changes on their platforms. >>> >>> Next step would be removal of client/server sub-directories on platforms >>> where we have only Server JVM (64-bit JDK has only Server JVM). >>> >>> Thanks, >>> Vladimir >>> >>> On 11/18/16 7:30 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this change which removes the $ARCH sub directory in the >>>> lib directory of the runtime images, which is an outstanding issue from >>>> the new runtime images. Most of the changes are in the build, but there >>>> are some in hotspot and launcher source. I have verified -testset >>>> hotspot and default in JPRT as well as tried to run as many jtreg tests >>>> as possible locally. I could only really find two tests that needed to >>>> be adjusted. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 >>>> >>>> /Erik >>>> From goetz.lindenmaier at sap.com Mon Nov 21 13:43:21 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Nov 2016 13:43:21 +0000 Subject: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux and Solaris images In-Reply-To: References: <9bdf96a7-c15f-cc73-06ef-38e02428aba1@oracle.com> <1b0e979f-bcba-a912-66d8-c1282075461e@oracle.com> Message-ID: Ah, ok, so this is fine. Best regards, Goetz. > -----Original Message----- > From: Erik Joelsson [mailto:erik.joelsson at oracle.com] > Sent: Montag, 21. November 2016 14:27 > To: Lindenmaier, Goetz ; Vladimir Kozlov > ; build-dev ; > core-libs-dev ; hotspot-dev developers > > Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from Linux > and Solaris images > > Hello Goetz, > > Thanks for trying this out. Note that the ergo* files were removed in > JDK-8169001 which is currently in jdk9/dev but not yet in hs. > > /Erik > > > On 2016-11-21 14:10, Lindenmaier, Goetz wrote: > > Hi, > > > > linuxx86_64 has the same issue. I tested it with the jdk9/hs repo: > > > > jdk/src/java.base/unix/native/libjli/ergo_i586.c: In function > ServerClassMachineImpl: > > jdk/src/java.base/unix/native/libjli/ergo_i586.c:196:30: error: expected ) > before LIBARCHNAME > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Montag, 21. November 2016 12:35 > >> To: 'Vladimir Kozlov' ; Erik Joelsson > >> ; build-dev ; > >> core-libs-dev ; hotspot-dev > developers > >> > >> Subject: RE: RFR: JDK-8066474: Remove the lib/$ARCH directory from > Linux > >> and Solaris images > >> > >> Hi, > >> > >> we appreciate this change a lot, and also if /server would go away. > >> > >> I built and tested it on linuxppcle, aixppc and linuxs390. > >> > >> There is still a place that refers to a removed variables > >> and breaks the build: > >> jdk/src/java.base/unix/native/libjli/ergo.c:94 LIBARCHNAME > >> You can probably just replace LIBARCHNAME by ARCH which is set to > >> the same value. > >> > >> I would propose to remove VM_CPU from hotspot/test/test_env.sh after > >> you > >> removed the last place where it is used. (VM_BITS is dead, too.) > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > >>> Behalf Of Vladimir Kozlov > >>> Sent: Freitag, 18. November 2016 17:41 > >>> To: Erik Joelsson ; build-dev >>> dev at openjdk.java.net>; core-libs-dev dev at openjdk.java.net>; > >>> hotspot-dev developers > >>> Subject: Re: RFR: JDK-8066474: Remove the lib/$ARCH directory from > Linux > >>> and Solaris images > >>> > >>> Finally! :) > >>> > >>> Hotspot changes looks fine to me. But you missed > >>> hotspot/make/hotspot.script file. > >>> > >>> Our colleges in RH and SAP should test these changes on their platforms. > >>> > >>> Next step would be removal of client/server sub-directories on > platforms > >>> where we have only Server JVM (64-bit JDK has only Server JVM). > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 11/18/16 7:30 AM, Erik Joelsson wrote: > >>>> Hello, > >>>> > >>>> Please review this change which removes the $ARCH sub directory in > the > >>>> lib directory of the runtime images, which is an outstanding issue from > >>>> the new runtime images. Most of the changes are in the build, but > there > >>>> are some in hotspot and launcher source. I have verified -testset > >>>> hotspot and default in JPRT as well as tried to run as many jtreg tests > >>>> as possible locally. I could only really find two tests that needed to > >>>> be adjusted. > >>>> > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066474 > >>>> > >>>> Webrev: http://cr.openjdk.java.net/~erikj/8066474/webrev.01 > >>>> > >>>> /Erik > >>>> From gromero at linux.vnet.ibm.com Tue Nov 22 00:27:10 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:27:10 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> Message-ID: <583390DE.5050406@linux.vnet.ibm.com> Hi Joe, On 17-11-2016 19:33, joe darcy wrote: >>>> Currently, optimization for building fdlibm is disabled, except for the >>>> "solaris" OS target [1]. >>> The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the >>> Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. >> oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm >> optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does >> not affect the precision, even if setting -O3 does not improve the performance >> as much as on PPC64. > > The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume values > of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would run afoul > of these fdlibm coding practices. On discussing with the Power toolchain folks we narrowed down the issue on PPC64 to the FMA. -fno-strict-aliasing has no effect and when used with an aggressive optimization does not solve the issue on precision. Thus -ffp-contract=off is the best options we have by now to optimize the fdlibm on PPC64. >>> Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. >> I agree. It's just that the issue on StrictMath methods was first noted due to >> that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. > > Depending on how Math.{sin, cos} is implemented on PPC64, compiling the fdlibm sin/cos with more aggressive optimizations should not be expected to close the performance gap. In particular, if > Math.{sin, cos} is an intrinsic on PPC64 (I haven't checked the sources) that used platform-specific feature (say fused multiply add instructions) then just compiling fdlibm more aggressively wouldn't > necessarily make up that gap. In our case (PPC64) it does close the gap. Non-optimized code will suffer a lot, for instance, from load-hit-store issues. Contrary to what happens on PPC64, the gap on x64 seems to be quite small as you said. > > To allow cross-platform and cross-release reproducibility, StrictMath is specified to use the particular fdlibm algorithms, which precludes using better algorithms developed more recently. If we were > to start with a clean slate today, to get such reproducibility we would specify correctly-rounded behavior of all those methods, but such an approach was much less tractable technical 20+ years ago > without benefit of the research that was been done in the interim, such as the work of Prof. Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. > >> >> >>> Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. >>> The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. >> That's really good point, thanks for letting me know about that. I'll re-test my >> change under that perspective. >> >> >>> Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. >> Got it. By "the JDK math library regression tests" you mean exactly which test >> suite? the jtreg tests? > > Specifically, the regression tests under test/java/lang/Math and test/java/lang/StrictMath in the jdk repository. There are some other math library tests in the hotspot repo, but I don't know where > they are offhand. > > A note on methodologies, when I've been writing test for my port I've tried to include test cases that exercise all the branches point in the code. Due to the large input space (~2^64 for a > single-argument method), random sampling alone is an inefficient way to try to find differences in behavior. >> For testing against JCK/TCK I'll need some help on that. >> > > I believe the JCK/TCK does have additional testcases relevant here. > > HTH; thanks, > > -Joe > Thank you very much for the valuable comments. I'll send a webrev accordingly for review. I filed a bug: https://bugs.openjdk.java.net/browse/JDK-8170153 Best regards, Gustavo From gromero at linux.vnet.ibm.com Tue Nov 22 00:34:37 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:34:37 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> Message-ID: <5833929D.9000602@linux.vnet.ibm.com> Hi Chris, On 17-11-2016 19:48, Chris Plummer wrote: >> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume >> values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would >> run afoul of these fdlibm coding practices. > This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more > than 12 years since I last dealt with fdlibm and compiler aliasing issues. I've tested with -O3 and -fno-strict-aliasing as you suggested but it did not fix the fp precision issue on PPC64. After finding that -fno-expensive-optimizations solved the problem, we narrowed down the problem to the FMA: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Thank you. Regards, Gustavo From gromero at linux.vnet.ibm.com Tue Nov 22 00:41:34 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:41:34 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> Message-ID: <5833943E.9010807@linux.vnet.ibm.com> Hi Derek, On 17-11-2016 20:47, White, Derek wrote: > Hi Joe, > > Although neither a floating point expert (as I think I've proven to you over the years), or a gcc expert, I checked with our in-house gcc expert and got this following answer: > > "Yes using -fno-strict-aliasing fixes the issues. Also there are many forks of fdlibm which has this fixed including the code inside glibc. " I've tried on PPC64 -O3 and -fno-strict-aliasing but it didn't work. Disabling the FMA fixed the issue although. Do you know if the gap between Math and StrictMath is also huge on aarch64? Thank you. Regards, Gustavo: From joe.darcy at oracle.com Tue Nov 22 00:42:10 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 21 Nov 2016 16:42:10 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5833929D.9000602@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833929D.9000602@linux.vnet.ibm.com> Message-ID: <8d21cafc-a4f5-0ed7-1f8f-4c40ccf4ecbe@oracle.com> Hello, On 11/21/2016 4:34 PM, Gustavo Romero wrote: > Hi Chris, > > On 17-11-2016 19:48, Chris Plummer wrote: >>> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume >>> values of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would >>> run afoul of these fdlibm coding practices. >> This is the strict aliasing issue right? It's a long standing problem with fdlibm that kept getting worse as gcc got smarter. IIRC, compiling with -fno-strict-aliasing fixes it, but it's been more >> than 12 years since I last dealt with fdlibm and compiler aliasing issues. > I've tested with -O3 and -fno-strict-aliasing as you suggested but it did not > fix the fp precision issue on PPC64. > > After finding that -fno-expensive-optimizations solved the problem, we narrowed > down the problem to the FMA: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > That makes sense; an FMA will by its nature provide different results than separate (unfused) multiple and add operations. While the polynomials used in fdlibm would benefit performance-wise from implicit replacement with FMA, such a replacement would violate the StrictMath contract. Therefore, if FDLIBM is left in C sources, it must be compiled in such a way that FMA is *not* substituted for multiply and add. Thanks, -Joe From gromero at linux.vnet.ibm.com Tue Nov 22 00:43:49 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 21 Nov 2016 22:43:49 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation Message-ID: <583394C5.3030206@linux.vnet.ibm.com> Hi, Could the following change be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ bug: https://bugs.openjdk.java.net/browse/JDK-8170153 It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds up the StrictMath methods (in some cases up to 3x) on that platform. On PPC64 fdlibm optimization can be done without precision issues if floating-point expression contraction is disable, i.e. if the compiler does not use floating-point multiply-add (FMA). For further details please refer to gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 No regression was observed on Math and StrictMath tests: Passed: java/lang/Math/AbsPositiveZero.java Passed: java/lang/Math/Atan2Tests.java Passed: java/lang/Math/CeilAndFloorTests.java Passed: java/lang/Math/CubeRootTests.java Passed: java/lang/Math/DivModTests.java Passed: java/lang/Math/ExactArithTests.java Passed: java/lang/Math/Expm1Tests.java Passed: java/lang/Math/FusedMultiplyAddTests.java Passed: java/lang/Math/HyperbolicTests.java Passed: java/lang/Math/HypotTests.java Passed: java/lang/Math/IeeeRecommendedTests.java Passed: java/lang/Math/Log10Tests.java Passed: java/lang/Math/Log1pTests.java Passed: java/lang/Math/MinMax.java Passed: java/lang/Math/MultiplicationTests.java Passed: java/lang/Math/PowTests.java Passed: java/lang/Math/Rint.java Passed: java/lang/Math/RoundTests.java Passed: java/lang/Math/SinCosCornerCasesTests.java Passed: java/lang/Math/TanTests.java Passed: java/lang/Math/WorstCaseTests.java Test results: passed: 21 Passed: java/lang/StrictMath/CubeRootTests.java Passed: java/lang/StrictMath/ExactArithTests.java Passed: java/lang/StrictMath/Expm1Tests.java Passed: java/lang/StrictMath/HyperbolicTests.java Passed: java/lang/StrictMath/HypotTests.java Passed: java/lang/StrictMath/Log10Tests.java Passed: java/lang/StrictMath/Log1pTests.java Passed: java/lang/StrictMath/PowTests.java Test results: passed: 8 and also on the following hotspot tests: Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java Passed: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java Passed: compiler/intrinsics/mathexact/AddExactICondTest.java Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java Passed: compiler/intrinsics/mathexact/CompareTest.java Passed: compiler/intrinsics/mathexact/DecExactITest.java Passed: compiler/intrinsics/mathexact/DecExactLTest.java Passed: compiler/intrinsics/mathexact/GVNTest.java Passed: compiler/intrinsics/mathexact/IncExactITest.java Passed: compiler/intrinsics/mathexact/IncExactLTest.java Passed: compiler/intrinsics/mathexact/MulExactICondTest.java Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java Passed: compiler/intrinsics/mathexact/SubExactICondTest.java Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java Test results: passed: 50 Thank you. Regards, Gustavo From chris.plummer at oracle.com Tue Nov 22 01:33:08 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 21 Nov 2016 17:33:08 -0800 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583390DE.5050406@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <583390DE.5050406@linux.vnet.ibm.com> Message-ID: On 11/21/16 4:27 PM, Gustavo Romero wrote: > Hi Joe, > > On 17-11-2016 19:33, joe darcy wrote: >>>>> Currently, optimization for building fdlibm is disabled, except for the >>>>> "solaris" OS target [1]. >>>> The reason for that is because historically the Solaris compilers have had sufficient discipline and control regarding floating-point semantics and compiler optimizations to still implement the >>>> Java-mandated results when optimization was enabled. The gcc family of compilers, for example, has lacked such discipline. >>> oh, I see. Thanks for clarifying that. I was exactly wondering why fdlibm >>> optimization is off even for x86_x64 as it, AFAICS regarding gcc 5 only, does >>> not affect the precision, even if setting -O3 does not improve the performance >>> as much as on PPC64. >> The fdlibm code relies on aliasing a two-element array of int with a double to do bit-level reads and writes of floating-point values. As I understand it, the C spec allows compilers to assume values >> of different types don't overlap in memory. The compilation environment has to be configured in such a way that the C compiler disables code generation and optimization techniques that would run afoul >> of these fdlibm coding practices. > On discussing with the Power toolchain folks we narrowed down the issue on PPC64 > to the FMA. -fno-strict-aliasing has no effect and when used with an aggressive > optimization does not solve the issue on precision. Thus -ffp-contract=off is > the best options we have by now to optimize the fdlibm on PPC64. Ah! I should have thought of this. I dealt with with fdlibm FMA issues on ppc about 15 years ago. At the time -mno-fused-madd was the solution. I don't think -ffp-contract=off existed back then. Chris > > >>>> Methods in the Math class, such as pow, are often intrinsified and use a different algorithm so a straight performance comparison may not be as fair or meaningful in those cases. >>> I agree. It's just that the issue on StrictMath methods was first noted due to >>> that huge gap (Math vs StrictMath) on PPC64, which is not prominent on x64. >> Depending on how Math.{sin, cos} is implemented on PPC64, compiling the fdlibm sin/cos with more aggressive optimizations should not be expected to close the performance gap. In particular, if >> Math.{sin, cos} is an intrinsic on PPC64 (I haven't checked the sources) that used platform-specific feature (say fused multiply add instructions) then just compiling fdlibm more aggressively wouldn't >> necessarily make up that gap. > In our case (PPC64) it does close the gap. Non-optimized code will suffer a lot, > for instance, from load-hit-store issues. Contrary to what happens on PPC64, the > gap on x64 seems to be quite small as you said. > > >> To allow cross-platform and cross-release reproducibility, StrictMath is specified to use the particular fdlibm algorithms, which precludes using better algorithms developed more recently. If we were >> to start with a clean slate today, to get such reproducibility we would specify correctly-rounded behavior of all those methods, but such an approach was much less tractable technical 20+ years ago >> without benefit of the research that was been done in the interim, such as the work of Prof. Muller and associates: https://lipforge.ens-lyon.fr/projects/crlibm/. >> >>> >>>> Accumulating the the results of the functions and comparisons the sums is not a sufficiently robust way of checking to see if the optimized versions are indeed equivalent to the non-optimized ones. >>>> The specification of StrictMath requires a particular result for each set of floating-point arguments and sums get round-away low-order bits that differ. >>> That's really good point, thanks for letting me know about that. I'll re-test my >>> change under that perspective. >>> >>> >>>> Running the JDK math library regression tests and corresponding JCK tests is recommended for work in this area. >>> Got it. By "the JDK math library regression tests" you mean exactly which test >>> suite? the jtreg tests? >> Specifically, the regression tests under test/java/lang/Math and test/java/lang/StrictMath in the jdk repository. There are some other math library tests in the hotspot repo, but I don't know where >> they are offhand. >> >> A note on methodologies, when I've been writing test for my port I've tried to include test cases that exercise all the branches point in the code. Due to the large input space (~2^64 for a >> single-argument method), random sampling alone is an inefficient way to try to find differences in behavior. >>> For testing against JCK/TCK I'll need some help on that. >>> >> I believe the JCK/TCK does have additional testcases relevant here. >> >> HTH; thanks, >> >> -Joe >> > Thank you very much for the valuable comments. > > I'll send a webrev accordingly for review. > > I filed a bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > > Best regards, > Gustavo > From aph at redhat.com Tue Nov 22 09:57:17 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 22 Nov 2016 09:57:17 +0000 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5833943E.9010807@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833943E.9010807@linux.vnet.ibm.com> Message-ID: On 22/11/16 00:41, Gustavo Romero wrote: > Do you know if the gap between Math and StrictMath is also huge on aarch64? I'll try to have a look. Andrew. From magnus.ihse.bursie at oracle.com Tue Nov 22 09:58:28 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Nov 2016 10:58:28 +0100 Subject: RFR: JDK-8168037 using ZIP as a make variable conflicts with zip's use of ZIP as an environment variable Message-ID: Following the standard by other tools, we set ZIP to the path of the zip binary. However, ZIP is interpreted as a way to control options for the Info-Zip zip binary. The solution is to rename the variable ZIP to ZIPEXE. Bug: https://bugs.openjdk.java.net/browse/JDK-8168037 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Nov 22 10:23:51 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Nov 2016 11:23:51 +0100 Subject: RFR: JDK-8168037 using ZIP as a make variable conflicts with zip's use of ZIP as an environment variable In-Reply-To: References: Message-ID: <4d5a2100-637f-2b64-e12d-1f4ecd668662@oracle.com> Hello, In spec.gmk.in, shouldn't it be "ZIPEXE:=@ZIPEXE@"? /Erik On 2016-11-22 10:58, Magnus Ihse Bursie wrote: > Following the standard by other tools, we set ZIP to the path of the > zip binary. > > However, ZIP is interpreted as a way to control options for the > Info-Zip zip binary. > > The solution is to rename the variable ZIP to ZIPEXE. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168037 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Nov 22 11:19:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Nov 2016 12:19:19 +0100 Subject: RFR: JDK-8168037 using ZIP as a make variable conflicts with zip's use of ZIP as an environment variable In-Reply-To: <4d5a2100-637f-2b64-e12d-1f4ecd668662@oracle.com> References: <4d5a2100-637f-2b64-e12d-1f4ecd668662@oracle.com> Message-ID: <0939ab1d-5b84-0d61-44c5-fec6833cbc14@oracle.com> On 2016-11-22 11:23, Erik Joelsson wrote: > Hello, > > In spec.gmk.in, shouldn't it be "ZIPEXE:=@ZIPEXE@"? You are absolutely right. How could that ever have worked?! And I did run it through jprt... I'll fix and re-check. /Magnus > > /Erik > > > On 2016-11-22 10:58, Magnus Ihse Bursie wrote: >> Following the standard by other tools, we set ZIP to the path of the >> zip binary. >> >> However, ZIP is interpreted as a way to control options for the >> Info-Zip zip binary. >> >> The solution is to rename the variable ZIP to ZIPEXE. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8168037 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.01 >> >> /Magnus >> > From erik.joelsson at oracle.com Tue Nov 22 11:22:32 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Nov 2016 12:22:32 +0100 Subject: RFR: JDK-8170077 Properly parallelize javadoc generation In-Reply-To: References: Message-ID: Looks good to me. /Erik On 2016-11-21 10:25, Magnus Ihse Bursie wrote: > The current javadoc generation first creates the coredocs Javadoc, and > after that all the remaining javadoc instances. > > This dependency is not really needed, all that is required is that the > remaining javadoc instances gets a proper pointer to a package-list > file for coredocs. Fixing that will allow them to run in parallel with > the coredoc generation. > > In addition to this performance fix, I've also cleaned up the (now > unnecessary) logic of storing the javadoc command line in > .options/.packages files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170077 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8170077-parallelize-javadoc/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Tue Nov 22 13:40:03 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Nov 2016 14:40:03 +0100 Subject: RFR: JDK-8168037 using ZIP as a make variable conflicts with zip's use of ZIP as an environment variable In-Reply-To: <0939ab1d-5b84-0d61-44c5-fec6833cbc14@oracle.com> References: <4d5a2100-637f-2b64-e12d-1f4ecd668662@oracle.com> <0939ab1d-5b84-0d61-44c5-fec6833cbc14@oracle.com> Message-ID: <09571a3d-7d4f-cd63-24bd-a260706ace02@oracle.com> On 2016-11-22 12:19, Magnus Ihse Bursie wrote: > On 2016-11-22 11:23, Erik Joelsson wrote: >> Hello, >> >> In spec.gmk.in, shouldn't it be "ZIPEXE:=@ZIPEXE@"? > > You are absolutely right. > > How could that ever have worked?! And I did run it through jprt... > > I'll fix and re-check. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.02 Only change is @ZIP@ to @ZIPEXE at . Reason I didn't detect this before was I didn't regenerated configure. :-& Now it's properly tested. /Magnus > > /Magnus > >> >> /Erik >> >> >> On 2016-11-22 10:58, Magnus Ihse Bursie wrote: >>> Following the standard by other tools, we set ZIP to the path of the >>> zip binary. >>> >>> However, ZIP is interpreted as a way to control options for the >>> Info-Zip zip binary. >>> >>> The solution is to rename the variable ZIP to ZIPEXE. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168037 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.01 >>> >>> /Magnus >>> >> > From erik.joelsson at oracle.com Tue Nov 22 13:43:54 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Nov 2016 14:43:54 +0100 Subject: RFR: JDK-8168037 using ZIP as a make variable conflicts with zip's use of ZIP as an environment variable In-Reply-To: <09571a3d-7d4f-cd63-24bd-a260706ace02@oracle.com> References: <4d5a2100-637f-2b64-e12d-1f4ecd668662@oracle.com> <0939ab1d-5b84-0d61-44c5-fec6833cbc14@oracle.com> <09571a3d-7d4f-cd63-24bd-a260706ace02@oracle.com> Message-ID: Looks good. /Erik On 2016-11-22 14:40, Magnus Ihse Bursie wrote: > On 2016-11-22 12:19, Magnus Ihse Bursie wrote: >> On 2016-11-22 11:23, Erik Joelsson wrote: >>> Hello, >>> >>> In spec.gmk.in, shouldn't it be "ZIPEXE:=@ZIPEXE@"? >> >> You are absolutely right. >> >> How could that ever have worked?! And I did run it through jprt... >> >> I'll fix and re-check. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.02 > > Only change is @ZIP@ to @ZIPEXE at . > > Reason I didn't detect this before was I didn't regenerated configure. > :-& Now it's properly tested. > > /Magnus > > >> >> /Magnus >> >>> >>> /Erik >>> >>> >>> On 2016-11-22 10:58, Magnus Ihse Bursie wrote: >>>> Following the standard by other tools, we set ZIP to the path of >>>> the zip binary. >>>> >>>> However, ZIP is interpreted as a way to control options for the >>>> Info-Zip zip binary. >>>> >>>> The solution is to rename the variable ZIP to ZIPEXE. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8168037 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8168037-rename-ZIP-to-ZIPEXE/webrev.01 >>>> >>>> /Magnus >>>> >>> >> > From magnus.ihse.bursie at oracle.com Tue Nov 22 13:56:35 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 Nov 2016 14:56:35 +0100 Subject: RFR: JDK-8170184 Remove incorrect comments about generated jvmt.h Message-ID: <0b291c3e-b353-b722-b339-0ae8f8f5e672@oracle.com> The inclusion of the generated jvmti.h was fixed in JDK-8063154, however the comments still state that this does not work. Bug: https://bugs.openjdk.java.net/browse/JDK-8170184 Patch inline: diff --git a/make/gensrc/GensrcJvmti.gmk b/make/gensrc/GensrcJvmti.gmk --- a/make/gensrc/GensrcJvmti.gmk +++ b/make/gensrc/GensrcJvmti.gmk @@ -130,8 +130,6 @@ TARGETS += $(JVMTI_OUTPUTDIR)/jvmtiEnvRecommended.cpp ################################################################################ -# Disable copy of jvmti.h from hotspot until this has been cleared up. The file -# is currently being copied from the jdk repository. See JDK-8167078. # Copy jvmti.h to include dir # The file is the same regardless of jvm variant. Only let one do the copy. /Magnus From Alan.Bateman at oracle.com Tue Nov 22 13:58:09 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2016 13:58:09 +0000 Subject: RFR: JDK-8170184 Remove incorrect comments about generated jvmt.h In-Reply-To: <0b291c3e-b353-b722-b339-0ae8f8f5e672@oracle.com> References: <0b291c3e-b353-b722-b339-0ae8f8f5e672@oracle.com> Message-ID: On 22/11/2016 13:56, Magnus Ihse Bursie wrote: > The inclusion of the generated jvmti.h was fixed in JDK-8063154, > however the comments still state that this does not work. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170184 > Patch inline: > diff --git a/make/gensrc/GensrcJvmti.gmk b/make/gensrc/GensrcJvmti.gmk > --- a/make/gensrc/GensrcJvmti.gmk > +++ b/make/gensrc/GensrcJvmti.gmk > @@ -130,8 +130,6 @@ > TARGETS += $(JVMTI_OUTPUTDIR)/jvmtiEnvRecommended.cpp > > ################################################################################ > > -# Disable copy of jvmti.h from hotspot until this has been cleared > up. The file > -# is currently being copied from the jdk repository. See JDK-8167078. > # Copy jvmti.h to include dir Looks fine. From erik.joelsson at oracle.com Tue Nov 22 14:01:28 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 Nov 2016 15:01:28 +0100 Subject: RFR: JDK-8170184 Remove incorrect comments about generated jvmt.h In-Reply-To: <0b291c3e-b353-b722-b339-0ae8f8f5e672@oracle.com> References: <0b291c3e-b353-b722-b339-0ae8f8f5e672@oracle.com> Message-ID: <239b73d6-598f-e965-1f4e-bede1c52e22a@oracle.com> Looks good. /Erik On 2016-11-22 14:56, Magnus Ihse Bursie wrote: > The inclusion of the generated jvmti.h was fixed in JDK-8063154, > however the comments still state that this does not work. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170184 > Patch inline: > diff --git a/make/gensrc/GensrcJvmti.gmk b/make/gensrc/GensrcJvmti.gmk > --- a/make/gensrc/GensrcJvmti.gmk > +++ b/make/gensrc/GensrcJvmti.gmk > @@ -130,8 +130,6 @@ > TARGETS += $(JVMTI_OUTPUTDIR)/jvmtiEnvRecommended.cpp > > ################################################################################ > > -# Disable copy of jvmti.h from hotspot until this has been cleared > up. The file > -# is currently being copied from the jdk repository. See JDK-8167078. > # Copy jvmti.h to include dir > > # The file is the same regardless of jvm variant. Only let one do the > copy. > > /Magnus > From mandy.chung at oracle.com Tue Nov 22 21:07:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 22 Nov 2016 13:07:03 -0800 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory Message-ID: This patch moves src.zip and jrt-fs.jar from the top-level into the `lib` directory in the run-time image as we proposed [1]. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ thanks Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html From james.laskey at oracle.com Tue Nov 22 23:31:38 2016 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 22 Nov 2016 19:31:38 -0400 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: References: Message-ID: <1D6891E9-2D66-4972-8F45-3FB5C881F20A@oracle.com> +1 > On Nov 22, 2016, at 5:07 PM, Mandy Chung wrote: > > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ > > thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html From magnus.ihse.bursie at oracle.com Wed Nov 23 09:14:35 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Nov 2016 10:14:35 +0100 Subject: RFR: JDK-7164925 Change -KPIC to -xcode=pic32 on sparc Message-ID: <1dffed8a-4bd2-c53f-f3ca-889f928c3c02@oracle.com> The -KPIC flag was deprecated in Solaris Studio 12.3 for sparc code. It should be changed to -xcode=pic32. This is an old bug, originally deferred from jdk8, where we still used 12.1. Bug: https://bugs.openjdk.java.net/browse/JDK-7164925 WebRev: http://cr.openjdk.java.net/~ihse/JDK-7164925-solaris-KPIC-is-deprecated/webrev.01 /Magnus From erik.joelsson at oracle.com Wed Nov 23 10:14:42 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 11:14:42 +0100 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: References: Message-ID: <49ae59ea-53f8-0e48-90bd-782ca20d3422@oracle.com> Build changes look good. /Erik On 2016-11-22 22:07, Mandy Chung wrote: > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ > > thanks > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-November/010128.html From erik.joelsson at oracle.com Wed Nov 23 10:19:08 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 11:19:08 +0100 Subject: RFR: JDK-7164925 Change -KPIC to -xcode=pic32 on sparc In-Reply-To: <1dffed8a-4bd2-c53f-f3ca-889f928c3c02@oracle.com> References: <1dffed8a-4bd2-c53f-f3ca-889f928c3c02@oracle.com> Message-ID: <01876943-aa22-5f4b-b264-e3e115f7bd05@oracle.com> Looks good. /Erik On 2016-11-23 10:14, Magnus Ihse Bursie wrote: > The -KPIC flag was deprecated in Solaris Studio 12.3 for sparc code. > It should be changed to -xcode=pic32. This is an old bug, originally > deferred from jdk8, where we still used 12.1. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7164925 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-7164925-solaris-KPIC-is-deprecated/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Nov 23 12:29:30 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 13:29:30 +0100 Subject: RFR: JDK-8170279: Langtools test/Makefile ignores failed tests Message-ID: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> After JDK-8167354, when a test fails in jtreg, the langtools test/Makefile ignores the result and exits with 0. This causes (at least) JPRT jobs to not fail when langtools tests fail. The reason for this is the added "| tee" construct which overrides the exit value from jtreg. Bug: https://bugs.openjdk.java.net/browse/JDK-8170279 Webrev: http://cr.openjdk.java.net/~erikj/8170279/webrev.langtools.01/ /Erik From Alan.Bateman at oracle.com Wed Nov 23 12:33:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2016 12:33:05 +0000 Subject: RFR: JDK-8170279: Langtools test/Makefile ignores failed tests In-Reply-To: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> References: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> Message-ID: <952c722e-a86e-f2d7-7551-8851be52cf96@oracle.com> On 23/11/2016 12:29, Erik Joelsson wrote: > After JDK-8167354, when a test fails in jtreg, the langtools > test/Makefile ignores the result and exits with 0. This causes (at > least) JPRT jobs to not fail when langtools tests fail. The reason for > this is the added "| tee" construct which overrides the exit value > from jtreg. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170279 > > Webrev: http://cr.openjdk.java.net/~erikj/8170279/webrev.langtools.01/ This looks good, and a bit scary that this wasn't noticed until now. -Alan From volker.simonis at gmail.com Wed Nov 23 14:05:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 23 Nov 2016 15:05:33 +0100 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583394C5.3030206@linux.vnet.ibm.com> References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks a lot for tracking this down! The change looks good and I a can sponsor it once you get another review from the build group and the FC Extension Request was approved. In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK [2] as this contains quite a lot of additional conformance tests which can be quite valuable for changes like this. Regards, Volker [1] http://openjdk.java.net/legal/octla-java-se-8.pdf [2] http://openjdk.java.net/groups/conformance/JckAccess/ On Tue, Nov 22, 2016 at 1:43 AM, Gustavo Romero wrote: > Hi, > > Could the following change be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds up the > StrictMath methods (in some cases up to 3x) on that platform. > > On PPC64 fdlibm optimization can be done without precision issues if > floating-point expression contraction is disable, i.e. if the compiler does not > use floating-point multiply-add (FMA). For further details please refer to gcc > bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > No regression was observed on Math and StrictMath tests: > > Passed: java/lang/Math/AbsPositiveZero.java > Passed: java/lang/Math/Atan2Tests.java > Passed: java/lang/Math/CeilAndFloorTests.java > Passed: java/lang/Math/CubeRootTests.java > Passed: java/lang/Math/DivModTests.java > Passed: java/lang/Math/ExactArithTests.java > Passed: java/lang/Math/Expm1Tests.java > Passed: java/lang/Math/FusedMultiplyAddTests.java > Passed: java/lang/Math/HyperbolicTests.java > Passed: java/lang/Math/HypotTests.java > Passed: java/lang/Math/IeeeRecommendedTests.java > Passed: java/lang/Math/Log10Tests.java > Passed: java/lang/Math/Log1pTests.java > Passed: java/lang/Math/MinMax.java > Passed: java/lang/Math/MultiplicationTests.java > Passed: java/lang/Math/PowTests.java > Passed: java/lang/Math/Rint.java > Passed: java/lang/Math/RoundTests.java > Passed: java/lang/Math/SinCosCornerCasesTests.java > Passed: java/lang/Math/TanTests.java > Passed: java/lang/Math/WorstCaseTests.java > Test results: passed: 21 > > Passed: java/lang/StrictMath/CubeRootTests.java > Passed: java/lang/StrictMath/ExactArithTests.java > Passed: java/lang/StrictMath/Expm1Tests.java > Passed: java/lang/StrictMath/HyperbolicTests.java > Passed: java/lang/StrictMath/HypotTests.java > Passed: java/lang/StrictMath/Log10Tests.java > Passed: java/lang/StrictMath/Log1pTests.java > Passed: java/lang/StrictMath/PowTests.java > Test results: passed: 8 > > and also on the following hotspot tests: > > Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java > Passed: compiler/intrinsics/mathexact/AddExactICondTest.java > Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/CompareTest.java > Passed: compiler/intrinsics/mathexact/DecExactITest.java > Passed: compiler/intrinsics/mathexact/DecExactLTest.java > Passed: compiler/intrinsics/mathexact/GVNTest.java > Passed: compiler/intrinsics/mathexact/IncExactITest.java > Passed: compiler/intrinsics/mathexact/IncExactLTest.java > Passed: compiler/intrinsics/mathexact/MulExactICondTest.java > Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java > Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java > Passed: compiler/intrinsics/mathexact/SubExactICondTest.java > Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java > Test results: passed: 50 > > Thank you. > > > Regards, > Gustavo > From Alan.Bateman at oracle.com Wed Nov 23 14:05:37 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Nov 2016 14:05:37 +0000 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: References: Message-ID: <3c4bcffb-cb61-de97-ae5b-98022a988aed@oracle.com> On 22/11/2016 21:07, Mandy Chung wrote: > This patch moves src.zip and jrt-fs.jar from the top-level into > the `lib` directory in the run-time image as we proposed [1]. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ > > This looks good. A minor point in SystemImage.findHome is that it's probably an InternalError if we are somehow loaded from a jrt-fs.jar that is not in the lib directory. -Alan From erik.joelsson at oracle.com Wed Nov 23 14:25:49 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 15:25:49 +0100 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build Message-ID: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> For a long time, a lot of people have been wanting the JDK classes to be compiled with debug symbols enabled by default. I believe the reason we haven't so far is to keep footprint down for the JRE image. The usecase for debug information is mainly in the JDK image, which is used for development. The problem so far has then been that we don't want to compile everything twice, once with and once without debug symbols. With jlink, we now have the option of stripping debug information at link time. This adds a bit of time creating the images, but it's small compared to recompiling all classes. Because of this, I propose that we enable debug symbols for all java compilation in the build by default and add stripping to all images that are footprint sensitive. Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 /Erik From erik.joelsson at oracle.com Wed Nov 23 14:29:52 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 15:29:52 +0100 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583394C5.3030206@linux.vnet.ibm.com> References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> Build changes look ok. In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. /Erik On 2016-11-22 01:43, Gustavo Romero wrote: > Hi, > > Could the following change be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds up the > StrictMath methods (in some cases up to 3x) on that platform. > > On PPC64 fdlibm optimization can be done without precision issues if > floating-point expression contraction is disable, i.e. if the compiler does not > use floating-point multiply-add (FMA). For further details please refer to gcc > bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > No regression was observed on Math and StrictMath tests: > > Passed: java/lang/Math/AbsPositiveZero.java > Passed: java/lang/Math/Atan2Tests.java > Passed: java/lang/Math/CeilAndFloorTests.java > Passed: java/lang/Math/CubeRootTests.java > Passed: java/lang/Math/DivModTests.java > Passed: java/lang/Math/ExactArithTests.java > Passed: java/lang/Math/Expm1Tests.java > Passed: java/lang/Math/FusedMultiplyAddTests.java > Passed: java/lang/Math/HyperbolicTests.java > Passed: java/lang/Math/HypotTests.java > Passed: java/lang/Math/IeeeRecommendedTests.java > Passed: java/lang/Math/Log10Tests.java > Passed: java/lang/Math/Log1pTests.java > Passed: java/lang/Math/MinMax.java > Passed: java/lang/Math/MultiplicationTests.java > Passed: java/lang/Math/PowTests.java > Passed: java/lang/Math/Rint.java > Passed: java/lang/Math/RoundTests.java > Passed: java/lang/Math/SinCosCornerCasesTests.java > Passed: java/lang/Math/TanTests.java > Passed: java/lang/Math/WorstCaseTests.java > Test results: passed: 21 > > Passed: java/lang/StrictMath/CubeRootTests.java > Passed: java/lang/StrictMath/ExactArithTests.java > Passed: java/lang/StrictMath/Expm1Tests.java > Passed: java/lang/StrictMath/HyperbolicTests.java > Passed: java/lang/StrictMath/HypotTests.java > Passed: java/lang/StrictMath/Log10Tests.java > Passed: java/lang/StrictMath/Log1pTests.java > Passed: java/lang/StrictMath/PowTests.java > Test results: passed: 8 > > and also on the following hotspot tests: > > Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java > Passed: compiler/intrinsics/mathexact/AddExactICondTest.java > Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/CompareTest.java > Passed: compiler/intrinsics/mathexact/DecExactITest.java > Passed: compiler/intrinsics/mathexact/DecExactLTest.java > Passed: compiler/intrinsics/mathexact/GVNTest.java > Passed: compiler/intrinsics/mathexact/IncExactITest.java > Passed: compiler/intrinsics/mathexact/IncExactLTest.java > Passed: compiler/intrinsics/mathexact/MulExactICondTest.java > Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java > Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java > Passed: compiler/intrinsics/mathexact/SubExactICondTest.java > Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java > Test results: passed: 50 > > Thank you. > > > Regards, > Gustavo > From erik.joelsson at oracle.com Wed Nov 23 15:05:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 16:05:48 +0100 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level Message-ID: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> After the hotspot makefile rewrite and the elimination of the hotspot dist output directory, it's now time to create more fine granular top level make targets for building hotspot. This will enable better granularity in between hotspot build steps and the rest of the build. Building native libraries in the JDK will only need to wait for one libjvm to be built. Building docs will only require the gensrc step in hotspot to be built. Here is the full list of new targets proposed: hotspot-gensrc hotspot-libs hotspot- hotspot--gensrc hotspot--libs hotspot-jsig Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 /Erik From erik.joelsson at oracle.com Wed Nov 23 15:10:38 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 16:10:38 +0100 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: It was pointed out that the changes to Images.gmk could be made simpler. Here is a new webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.02 /Erik On 2016-11-23 15:25, Erik Joelsson wrote: > For a long time, a lot of people have been wanting the JDK classes to > be compiled with debug symbols enabled by default. I believe the > reason we haven't so far is to keep footprint down for the JRE image. > The usecase for debug information is mainly in the JDK image, which is > used for development. The problem so far has then been that we don't > want to compile everything twice, once with and once without debug > symbols. > > With jlink, we now have the option of stripping debug information at > link time. This adds a bit of time creating the images, but it's small > compared to recompiling all classes. Because of this, I propose that > we enable debug symbols for all java compilation in the build by > default and add stripping to all images that are footprint sensitive. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 > > Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 > > /Erik > From erik.joelsson at oracle.com Wed Nov 23 15:11:49 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 16:11:49 +0100 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: Similarly for the closed images, new webrev: http://javaweb.us.oracle.com/~ejoelsso/webrev/8170280/webrev.closed.02/ /Erik On 2016-11-23 15:25, Erik Joelsson wrote: > For a long time, a lot of people have been wanting the JDK classes to > be compiled with debug symbols enabled by default. I believe the > reason we haven't so far is to keep footprint down for the JRE image. > The usecase for debug information is mainly in the JDK image, which is > used for development. The problem so far has then been that we don't > want to compile everything twice, once with and once without debug > symbols. > > With jlink, we now have the option of stripping debug information at > link time. This adds a bit of time creating the images, but it's small > compared to recompiling all classes. Because of this, I propose that > we enable debug symbols for all java compilation in the build by > default and add stripping to all images that are footprint sensitive. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 > > Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 > > /Erik > From erik.joelsson at oracle.com Wed Nov 23 15:13:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 16:13:21 +0100 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: Please disregard this email, replied to the wrong one. /Erik On 2016-11-23 16:11, Erik Joelsson wrote: > Similarly for the closed images, new webrev: > > http://javaweb.us.oracle.com/~ejoelsso/webrev/8170280/webrev.closed.02/ > > /Erik > > On 2016-11-23 15:25, Erik Joelsson wrote: >> For a long time, a lot of people have been wanting the JDK classes to >> be compiled with debug symbols enabled by default. I believe the >> reason we haven't so far is to keep footprint down for the JRE image. >> The usecase for debug information is mainly in the JDK image, which >> is used for development. The problem so far has then been that we >> don't want to compile everything twice, once with and once without >> debug symbols. >> >> With jlink, we now have the option of stripping debug information at >> link time. This adds a bit of time creating the images, but it's >> small compared to recompiling all classes. Because of this, I propose >> that we enable debug symbols for all java compilation in the build by >> default and add stripping to all images that are footprint sensitive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 >> >> /Erik >> > From tim.bell at oracle.com Wed Nov 23 15:25:24 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 Nov 2016 07:25:24 -0800 Subject: RFR: JDK-8170279: Langtools test/Makefile ignores failed tests In-Reply-To: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> References: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> Message-ID: <8b68b238-324f-092d-16bd-36f67f31ee84@oracle.com> Erik: > After JDK-8167354, when a test fails in jtreg, the langtools > test/Makefile ignores the result and exits with 0. This causes (at > least) JPRT jobs to not fail when langtools tests fail. The reason for > this is the added "| tee" construct which overrides the exit value from > jtreg. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170279 > > Webrev: http://cr.openjdk.java.net/~erikj/8170279/webrev.langtools.01/ Good catch. Looks good to me. Tim From gromero at linux.vnet.ibm.com Wed Nov 23 15:28:05 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Nov 2016 13:28:05 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: <5835B585.5040807@linux.vnet.ibm.com> Hi Volker, On 23-11-2016 12:05, Volker Simonis wrote: > thanks a lot for tracking this down! Happy to contribute :) > The change looks good and I a can sponsor it once you get another > review from the build group and the FC Extension Request was approved. Thanks a lot for sponsoring it! > In general I'd advise to sign the OCTLA [1] to get access to the Java > SE TCK [2] as this contains quite a lot of additional conformance > tests which can be quite valuable for changes like this. > > Regards, > Volker > > [1] http://openjdk.java.net/legal/octla-java-se-8.pdf > [2] http://openjdk.java.net/groups/conformance/JckAccess/ Right. I'll check the documentation and find a way to get access to the TCK. Best regards, Gustavo From gromero at linux.vnet.ibm.com Wed Nov 23 15:29:51 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Nov 2016 13:29:51 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <8d52c2bcc0c0473e8e79d3f794ca81f3@dewdfe13de06.global.corp.sap> References: <583394C5.3030206@linux.vnet.ibm.com> <8d52c2bcc0c0473e8e79d3f794ca81f3@dewdfe13de06.global.corp.sap> Message-ID: <5835B5EF.7070006@linux.vnet.ibm.com> Hi Martin, On 23-11-2016 12:38, Doerr, Martin wrote: > Hi Gustavo, > > thanks for providing the webrevs. > > I have ran the StrictMath jck tests which fail when building with -O3 and without -ffp-contract=off: > FailedTests: > api/java_lang/StrictMath/desc.html#acos javasoft.sqe.tests.api.java.lang.StrictMath.acos_test > api/java_lang/StrictMath/desc.html#asin javasoft.sqe.tests.api.java.lang.StrictMath.asin_test > api/java_lang/StrictMath/desc.html#atan javasoft.sqe.tests.api.java.lang.StrictMath.atan_test > api/java_lang/StrictMath/desc.html#atan2 javasoft.sqe.tests.api.java.lang.StrictMath.atan2_test > api/java_lang/StrictMath/desc.html#cos javasoft.sqe.tests.api.java.lang.StrictMath.cos_test > api/java_lang/StrictMath/desc.html#exp javasoft.sqe.tests.api.java.lang.StrictMath.exp_test > api/java_lang/StrictMath/desc.html#log javasoft.sqe.tests.api.java.lang.StrictMath.log_test > api/java_lang/StrictMath/desc.html#sin javasoft.sqe.tests.api.java.lang.StrictMath.sin_test > api/java_lang/StrictMath/desc.html#tan javasoft.sqe.tests.api.java.lang.StrictMath.tan_test > api/java_lang/StrictMath/index.html#expm1 javasoft.sqe.tests.api.java.lang.StrictMath.expm1Tests -TestCaseID ALL > api/java_lang/StrictMath/index.html#log10 javasoft.sqe.tests.api.java.lang.StrictMath.log10Tests -TestCaseID ALL > api/java_lang/StrictMath/index.html#log1p javasoft.sqe.tests.api.java.lang.StrictMath.log1pTests -TestCaseID ALL > > All of them have passed when building with -O3 and -ffp-contract=off (on linuxppc64le). Thank you very much for running the additional StrictMath jck tests against the change! Best regards, Gustavo From martin.doerr at sap.com Wed Nov 23 14:38:09 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Nov 2016 14:38:09 +0000 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583394C5.3030206@linux.vnet.ibm.com> Message-ID: <8d52c2bcc0c0473e8e79d3f794ca81f3@dewdfe13de06.global.corp.sap> Hi Gustavo, thanks for providing the webrevs. I have ran the StrictMath jck tests which fail when building with -O3 and without -ffp-contract=off: FailedTests: api/java_lang/StrictMath/desc.html#acos javasoft.sqe.tests.api.java.lang.StrictMath.acos_test api/java_lang/StrictMath/desc.html#asin javasoft.sqe.tests.api.java.lang.StrictMath.asin_test api/java_lang/StrictMath/desc.html#atan javasoft.sqe.tests.api.java.lang.StrictMath.atan_test api/java_lang/StrictMath/desc.html#atan2 javasoft.sqe.tests.api.java.lang.StrictMath.atan2_test api/java_lang/StrictMath/desc.html#cos javasoft.sqe.tests.api.java.lang.StrictMath.cos_test api/java_lang/StrictMath/desc.html#exp javasoft.sqe.tests.api.java.lang.StrictMath.exp_test api/java_lang/StrictMath/desc.html#log javasoft.sqe.tests.api.java.lang.StrictMath.log_test api/java_lang/StrictMath/desc.html#sin javasoft.sqe.tests.api.java.lang.StrictMath.sin_test api/java_lang/StrictMath/desc.html#tan javasoft.sqe.tests.api.java.lang.StrictMath.tan_test api/java_lang/StrictMath/index.html#expm1 javasoft.sqe.tests.api.java.lang.StrictMath.expm1Tests -TestCaseID ALL api/java_lang/StrictMath/index.html#log10 javasoft.sqe.tests.api.java.lang.StrictMath.log10Tests -TestCaseID ALL api/java_lang/StrictMath/index.html#log1p javasoft.sqe.tests.api.java.lang.StrictMath.log1pTests -TestCaseID ALL All of them have passed when building with -O3 and -ffp-contract=off (on linuxppc64le). So thumbs up from my side. Thanks and best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Mittwoch, 23. November 2016 15:06 To: Gustavo Romero Cc: build-dev ; ppc-aix-port-dev at openjdk.java.net; Java Core Libs ; hotspot-dev at openjdk.java.net Subject: Re: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation Hi Gustavo, thanks a lot for tracking this down! The change looks good and I a can sponsor it once you get another review from the build group and the FC Extension Request was approved. In general I'd advise to sign the OCTLA [1] to get access to the Java SE TCK [2] as this contains quite a lot of additional conformance tests which can be quite valuable for changes like this. Regards, Volker [1] http://openjdk.java.net/legal/octla-java-se-8.pdf [2] http://openjdk.java.net/groups/conformance/JckAccess/ On Tue, Nov 22, 2016 at 1:43 AM, Gustavo Romero wrote: > Hi, > > Could the following change be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > It enables fdlibm optimization on Linux PPC64 LE & BE and hence speeds > up the StrictMath methods (in some cases up to 3x) on that platform. > > On PPC64 fdlibm optimization can be done without precision issues if > floating-point expression contraction is disable, i.e. if the compiler > does not use floating-point multiply-add (FMA). For further details > please refer to gcc > bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 > > No regression was observed on Math and StrictMath tests: > > Passed: java/lang/Math/AbsPositiveZero.java > Passed: java/lang/Math/Atan2Tests.java > Passed: java/lang/Math/CeilAndFloorTests.java > Passed: java/lang/Math/CubeRootTests.java > Passed: java/lang/Math/DivModTests.java > Passed: java/lang/Math/ExactArithTests.java > Passed: java/lang/Math/Expm1Tests.java > Passed: java/lang/Math/FusedMultiplyAddTests.java > Passed: java/lang/Math/HyperbolicTests.java > Passed: java/lang/Math/HypotTests.java > Passed: java/lang/Math/IeeeRecommendedTests.java > Passed: java/lang/Math/Log10Tests.java > Passed: java/lang/Math/Log1pTests.java > Passed: java/lang/Math/MinMax.java > Passed: java/lang/Math/MultiplicationTests.java > Passed: java/lang/Math/PowTests.java > Passed: java/lang/Math/Rint.java > Passed: java/lang/Math/RoundTests.java > Passed: java/lang/Math/SinCosCornerCasesTests.java > Passed: java/lang/Math/TanTests.java > Passed: java/lang/Math/WorstCaseTests.java > Test results: passed: 21 > > Passed: java/lang/StrictMath/CubeRootTests.java > Passed: java/lang/StrictMath/ExactArithTests.java > Passed: java/lang/StrictMath/Expm1Tests.java > Passed: java/lang/StrictMath/HyperbolicTests.java > Passed: java/lang/StrictMath/HypotTests.java > Passed: java/lang/StrictMath/Log10Tests.java > Passed: java/lang/StrictMath/Log1pTests.java > Passed: java/lang/StrictMath/PowTests.java > Test results: passed: 8 > > and also on the following hotspot tests: > > Passed: compiler/intrinsics/mathexact/sanity/AddExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/AddExactLongTest.java > Passed: > compiler/intrinsics/mathexact/sanity/DecrementExactIntTest.java > Passed: > compiler/intrinsics/mathexact/sanity/DecrementExactLongTest.java > Passed: > compiler/intrinsics/mathexact/sanity/IncrementExactIntTest.java > Passed: > compiler/intrinsics/mathexact/sanity/IncrementExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/MultiplyExactIntTest.java > Passed: > compiler/intrinsics/mathexact/sanity/MultiplyExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactIntTest.java > Passed: compiler/intrinsics/mathexact/sanity/NegateExactLongTest.java > Passed: compiler/intrinsics/mathexact/sanity/SubtractExactIntTest.java > Passed: > compiler/intrinsics/mathexact/sanity/SubtractExactLongTest.java > Passed: compiler/intrinsics/mathexact/AddExactICondTest.java > Passed: compiler/intrinsics/mathexact/AddExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoadTest.java > Passed: compiler/intrinsics/mathexact/AddExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/AddExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/AddExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/AddExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/CompareTest.java > Passed: compiler/intrinsics/mathexact/DecExactITest.java > Passed: compiler/intrinsics/mathexact/DecExactLTest.java > Passed: compiler/intrinsics/mathexact/GVNTest.java > Passed: compiler/intrinsics/mathexact/IncExactITest.java > Passed: compiler/intrinsics/mathexact/IncExactLTest.java > Passed: compiler/intrinsics/mathexact/MulExactICondTest.java > Passed: compiler/intrinsics/mathexact/MulExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoadTest.java > Passed: compiler/intrinsics/mathexact/MulExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/MulExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/MulExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/MulExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoadTest.java > Passed: compiler/intrinsics/mathexact/NegExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/NegExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/NegExactLNonConstantTest.java > Passed: compiler/intrinsics/mathexact/NestedMathExactTest.java > Passed: compiler/intrinsics/mathexact/SplitThruPhiTest.java > Passed: compiler/intrinsics/mathexact/SubExactICondTest.java > Passed: compiler/intrinsics/mathexact/SubExactIConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoadTest.java > Passed: compiler/intrinsics/mathexact/SubExactILoopDependentTest.java > Passed: compiler/intrinsics/mathexact/SubExactINonConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactIRepeatTest.java > Passed: compiler/intrinsics/mathexact/SubExactLConstantTest.java > Passed: compiler/intrinsics/mathexact/SubExactLNonConstantTest.java > Test results: passed: 50 > > Thank you. > > > Regards, > Gustavo > From gromero at linux.vnet.ibm.com Wed Nov 23 15:33:43 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Nov 2016 13:33:43 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> References: <583394C5.3030206@linux.vnet.ibm.com> <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> Message-ID: <5835B6D7.4020101@linux.vnet.ibm.com> Hi Erik, On 23-11-2016 12:29, Erik Joelsson wrote: > Build changes look ok. > > In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. Thanks a lot for reviewing the change. Regards, Gustavo From volker.simonis at gmail.com Wed Nov 23 15:46:50 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 23 Nov 2016 16:46:50 +0100 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: Hi Erik, the Java developers out there will love you for this change! And yet another feature where you catch up with the SAP JVM :) The change looks good, thumbs up from me. Regards, Volker On Wed, Nov 23, 2016 at 4:10 PM, Erik Joelsson wrote: > It was pointed out that the changes to Images.gmk could be made simpler. > Here is a new webrev: > > http://cr.openjdk.java.net/~erikj/8170280/webrev.top.02 > > /Erik > > > > On 2016-11-23 15:25, Erik Joelsson wrote: >> >> For a long time, a lot of people have been wanting the JDK classes to be >> compiled with debug symbols enabled by default. I believe the reason we >> haven't so far is to keep footprint down for the JRE image. The usecase for >> debug information is mainly in the JDK image, which is used for development. >> The problem so far has then been that we don't want to compile everything >> twice, once with and once without debug symbols. >> >> With jlink, we now have the option of stripping debug information at link >> time. This adds a bit of time creating the images, but it's small compared >> to recompiling all classes. Because of this, I propose that we enable debug >> symbols for all java compilation in the build by default and add stripping >> to all images that are footprint sensitive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 >> >> /Erik >> > From tim.bell at oracle.com Wed Nov 23 16:02:11 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 Nov 2016 08:02:11 -0800 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: <91699543-7bb7-a570-26d6-994ce64903d8@oracle.com> Erik: Looks good to me. /Tim On 11/23/16 07:10, Erik Joelsson wrote: > It was pointed out that the changes to Images.gmk could be made simpler. > Here is a new webrev: > > http://cr.openjdk.java.net/~erikj/8170280/webrev.top.02 > > /Erik > > > On 2016-11-23 15:25, Erik Joelsson wrote: >> For a long time, a lot of people have been wanting the JDK classes to >> be compiled with debug symbols enabled by default. I believe the >> reason we haven't so far is to keep footprint down for the JRE image. >> The usecase for debug information is mainly in the JDK image, which is >> used for development. The problem so far has then been that we don't >> want to compile everything twice, once with and once without debug >> symbols. >> >> With jlink, we now have the option of stripping debug information at >> link time. This adds a bit of time creating the images, but it's small >> compared to recompiling all classes. Because of this, I propose that >> we enable debug symbols for all java compilation in the build by >> default and add stripping to all images that are footprint sensitive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 >> >> /Erik >> > From tim.bell at oracle.com Wed Nov 23 16:24:20 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 Nov 2016 08:24:20 -0800 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> Message-ID: <93d8842b-c72f-060f-755b-1e9b9603a4b4@oracle.com> Erik: > After the hotspot makefile rewrite and the elimination of the hotspot > dist output directory, it's now time to create more fine granular top > level make targets for building hotspot. This will enable better > granularity in between hotspot build steps and the rest of the build. > Building native libraries in the JDK will only need to wait for one > libjvm to be built. Building docs will only require the gensrc step in > hotspot to be built. > > Here is the full list of new targets proposed: > hotspot-gensrc > hotspot-libs > hotspot- > hotspot--gensrc > hotspot--libs > hotspot-jsig > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 > > Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 Looks good. /Tim From erik.joelsson at oracle.com Wed Nov 23 16:28:03 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 Nov 2016 17:28:03 +0100 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> Message-ID: Discovered an issue with cross compiling configurations. In buildjdk-spec.gmk.in, need to also override the new variable JVM_VARIANTS_MAIN. New webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.02/ /Erik On 2016-11-23 16:05, Erik Joelsson wrote: > After the hotspot makefile rewrite and the elimination of the hotspot > dist output directory, it's now time to create more fine granular top > level make targets for building hotspot. This will enable better > granularity in between hotspot build steps and the rest of the build. > Building native libraries in the JDK will only need to wait for one > libjvm to be built. Building docs will only require the gensrc step in > hotspot to be built. > > Here is the full list of new targets proposed: > hotspot-gensrc > hotspot-libs > hotspot- > hotspot--gensrc > hotspot--libs > hotspot-jsig > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 > > Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 > > /Erik > From mandy.chung at oracle.com Wed Nov 23 16:37:50 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Nov 2016 08:37:50 -0800 Subject: RFR: JDK-8170279: Langtools test/Makefile ignores failed tests In-Reply-To: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> References: <441605b1-0209-9e60-7fc9-fa09d9d8aa1b@oracle.com> Message-ID: <656733E2-5855-40C5-A884-77779F237AF3@oracle.com> Looks good. Mandy > On Nov 23, 2016, at 4:29 AM, Erik Joelsson wrote: > > After JDK-8167354, when a test fails in jtreg, the langtools test/Makefile ignores the result and exits with 0. This causes (at least) JPRT jobs to not fail when langtools tests fail. The reason for this is the added "| tee" construct which overrides the exit value from jtreg. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170279 > > Webrev: http://cr.openjdk.java.net/~erikj/8170279/webrev.langtools.01/ > > /Erik > From mandy.chung at oracle.com Wed Nov 23 18:36:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Nov 2016 10:36:07 -0800 Subject: Review Request: JDK-8169816 Move src.zip and jrt-fs.jar under the lib directory In-Reply-To: <3c4bcffb-cb61-de97-ae5b-98022a988aed@oracle.com> References: <3c4bcffb-cb61-de97-ae5b-98022a988aed@oracle.com> Message-ID: <09BFA0C3-FFC8-4F2C-BE8F-C839EB2DAE17@oracle.com> > On Nov 23, 2016, at 6:05 AM, Alan Bateman wrote: > > > > On 22/11/2016 21:07, Mandy Chung wrote: >> This patch moves src.zip and jrt-fs.jar from the top-level into >> the `lib` directory in the run-time image as we proposed [1]. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8169816/webrev.00/ >> >> > This looks good. A minor point in SystemImage.findHome is that it's probably an InternalError if we are somehow loaded from a jrt-fs.jar that is not in the lib directory. Agree. The existing check if non ?file? URL should also throw InternalError instead. Fixed. @@ -113,12 +113,16 @@ if (cs == null) return System.getProperty("java.home"); - // assume loaded from $TARGETJDK/jrt-fs.jar + // assume loaded from $TARGETJDK/lib/jrt-fs.jar URL url = cs.getLocation(); if (!url.getProtocol().equalsIgnoreCase("file")) - throw new RuntimeException(url + " loaded in unexpected way"); + throw new InternalError(url + " loaded in unexpected way"); try { - return Paths.get(url.toURI()).getParent().toString(); + Path lib = Paths.get(url.toURI()).getParent(); + if (!lib.getFileName().toString().equals("lib")) + throw new InternalError(url + " unexpected path"); + + return lib.getParent().toString(); } catch (URISyntaxException e) { throw new InternalError(e); } Mandy From tim.bell at oracle.com Wed Nov 23 19:09:27 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 Nov 2016 11:09:27 -0800 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> Message-ID: Erik: Looks good. Tim > Discovered an issue with cross compiling configurations. In > buildjdk-spec.gmk.in, need to also override the new variable > JVM_VARIANTS_MAIN. New webrev: > > http://cr.openjdk.java.net/~erikj/8170284/webrev.02/ > > /Erik > > On 2016-11-23 16:05, Erik Joelsson wrote: >> After the hotspot makefile rewrite and the elimination of the hotspot >> dist output directory, it's now time to create more fine granular top >> level make targets for building hotspot. This will enable better >> granularity in between hotspot build steps and the rest of the build. >> Building native libraries in the JDK will only need to wait for one >> libjvm to be built. Building docs will only require the gensrc step in >> hotspot to be built. >> >> Here is the full list of new targets proposed: >> hotspot-gensrc >> hotspot-libs >> hotspot- >> hotspot--gensrc >> hotspot--libs >> hotspot-jsig >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 >> >> /Erik >> > From david.holmes at oracle.com Wed Nov 23 23:32:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2016 09:32:33 +1000 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: <99dc9734-1569-9dd5-aaed-4bd955c26871@oracle.com> On 24/11/2016 1:10 AM, Erik Joelsson wrote: > It was pointed out that the changes to Images.gmk could be made simpler. > Here is a new webrev: > > http://cr.openjdk.java.net/~erikj/8170280/webrev.top.02 Looks good! So JRE images (incl compact profiles) are stripped and JDK images has full debug! Thanks, David > /Erik > > > On 2016-11-23 15:25, Erik Joelsson wrote: >> For a long time, a lot of people have been wanting the JDK classes to >> be compiled with debug symbols enabled by default. I believe the >> reason we haven't so far is to keep footprint down for the JRE image. >> The usecase for debug information is mainly in the JDK image, which is >> used for development. The problem so far has then been that we don't >> want to compile everything twice, once with and once without debug >> symbols. >> >> With jlink, we now have the option of stripping debug information at >> link time. This adds a bit of time creating the images, but it's small >> compared to recompiling all classes. Because of this, I propose that >> we enable debug symbols for all java compilation in the build by >> default and add stripping to all images that are footprint sensitive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 >> >> /Erik >> > From david.holmes at oracle.com Wed Nov 23 23:54:56 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2016 09:54:56 +1000 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> Message-ID: <06862250-667d-055a-6d96-bee7b5a62e62@oracle.com> Hi Erik, On 24/11/2016 2:28 AM, Erik Joelsson wrote: > Discovered an issue with cross compiling configurations. In > buildjdk-spec.gmk.in, need to also override the new variable > JVM_VARIANTS_MAIN. New webrev: > > http://cr.openjdk.java.net/~erikj/8170284/webrev.02/ Seems reasonable but I don't understand these two targets: + $(info $(_) make hotspot- # Build just the specified jvm variant) + $(info $(_) make hotspot-libs # Build the native libraries for hotspot) Given that the JVM variant defines which libjvm to build, and that is the primary "hotspot native library", I don't see how these two can be distinct ?? Thanks, David > /Erik > > On 2016-11-23 16:05, Erik Joelsson wrote: >> After the hotspot makefile rewrite and the elimination of the hotspot >> dist output directory, it's now time to create more fine granular top >> level make targets for building hotspot. This will enable better >> granularity in between hotspot build steps and the rest of the build. >> Building native libraries in the JDK will only need to wait for one >> libjvm to be built. Building docs will only require the gensrc step in >> hotspot to be built. >> >> Here is the full list of new targets proposed: >> hotspot-gensrc >> hotspot-libs >> hotspot- >> hotspot--gensrc >> hotspot--libs >> hotspot-jsig >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 >> >> /Erik >> > From erik.joelsson at oracle.com Thu Nov 24 10:12:14 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Nov 2016 11:12:14 +0100 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: <06862250-667d-055a-6d96-bee7b5a62e62@oracle.com> References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> <06862250-667d-055a-6d96-bee7b5a62e62@oracle.com> Message-ID: On 2016-11-24 00:54, David Holmes wrote: > Hi Erik, > > On 24/11/2016 2:28 AM, Erik Joelsson wrote: >> Discovered an issue with cross compiling configurations. In >> buildjdk-spec.gmk.in, need to also override the new variable >> JVM_VARIANTS_MAIN. New webrev: >> >> http://cr.openjdk.java.net/~erikj/8170284/webrev.02/ > > Seems reasonable but I don't understand these two targets: > > + $(info $(_) make hotspot- # Build just the > specified jvm variant) > + $(info $(_) make hotspot-libs # Build the native > libraries for hotspot) > > Given that the JVM variant defines which libjvm to build, and that is > the primary "hotspot native library", I don't see how these two can be > distinct ?? > In the current build, "hotspot-libs" happens to be synonymous with just "hotspot" as it builds all the native libraries, and the hotspot build doesn't have any more targets in its pipeline. In theory, we could add additional build phases for hotspot in the future. I agree it's not very useful to document this target as it currently stands however. /Erik > Thanks, > David > >> /Erik >> >> On 2016-11-23 16:05, Erik Joelsson wrote: >>> After the hotspot makefile rewrite and the elimination of the hotspot >>> dist output directory, it's now time to create more fine granular top >>> level make targets for building hotspot. This will enable better >>> granularity in between hotspot build steps and the rest of the build. >>> Building native libraries in the JDK will only need to wait for one >>> libjvm to be built. Building docs will only require the gensrc step in >>> hotspot to be built. >>> >>> Here is the full list of new targets proposed: >>> hotspot-gensrc >>> hotspot-libs >>> hotspot- >>> hotspot--gensrc >>> hotspot--libs >>> hotspot-jsig >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 >>> >>> /Erik >>> >> From magnus.ihse.bursie at oracle.com Thu Nov 24 14:39:58 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Nov 2016 15:39:58 +0100 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> Message-ID: <1334fae1-9adb-b492-5aaf-bc08e1246af9@oracle.com> On 2016-11-23 16:05, Erik Joelsson wrote: > After the hotspot makefile rewrite and the elimination of the hotspot > dist output directory, it's now time to create more fine granular top > level make targets for building hotspot. This will enable better > granularity in between hotspot build steps and the rest of the build. > Building native libraries in the JDK will only need to wait for one > libjvm to be built. Building docs will only require the gensrc step in > hotspot to be built. > > Here is the full list of new targets proposed: > hotspot-gensrc > hotspot-libs > hotspot- > hotspot--gensrc > hotspot--libs > hotspot-jsig > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 > > Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 Looks good to me. You used to be very picky that we should have proper clean-* targets as well. :-) It was a bit annoying at times ;-) but I think it was good to have. Maybe you could complement with that in a follow-up patch? /Magnus From magnus.ihse.bursie at oracle.com Thu Nov 24 14:43:19 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Nov 2016 15:43:19 +0100 Subject: RFR: JDK-8170280: Enable -g for all java compilation in the build In-Reply-To: References: <7f1a82e1-6db3-5d60-935c-c3a25874828a@oracle.com> Message-ID: <9b79b30d-84aa-f908-709d-44c59a27768e@oracle.com> On 2016-11-23 16:10, Erik Joelsson wrote: > It was pointed out that the changes to Images.gmk could be made > simpler. Here is a new webrev: > > http://cr.openjdk.java.net/~erikj/8170280/webrev.top.02 Looks good, except for the new DEBUG_SYMBOLS. I'm not entirely sure it's needed (since there are no users of it) and I'm not too fond of coding for future vaguely anticipated needs. Also, there's a bug in this code. You should have been testing for $1_DEBUG_SYMBOLS. Which proves my point of not coding for the future. ;-) But, I can see the reason of having symmetry with NativeCompilation, and if you want to keep it, do so. Just fix the bug. /Magnus > > /Erik > > > On 2016-11-23 15:25, Erik Joelsson wrote: >> For a long time, a lot of people have been wanting the JDK classes to >> be compiled with debug symbols enabled by default. I believe the >> reason we haven't so far is to keep footprint down for the JRE image. >> The usecase for debug information is mainly in the JDK image, which >> is used for development. The problem so far has then been that we >> don't want to compile everything twice, once with and once without >> debug symbols. >> >> With jlink, we now have the option of stripping debug information at >> link time. This adds a bit of time creating the images, but it's >> small compared to recompiling all classes. Because of this, I propose >> that we enable debug symbols for all java compilation in the build by >> default and add stripping to all images that are footprint sensitive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170280 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170280/webrev.top.01 >> >> /Erik >> > From magnus.ihse.bursie at oracle.com Thu Nov 24 14:54:26 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 Nov 2016 15:54:26 +0100 Subject: RFR: JDK-8031567 Better model for storing source revision information Message-ID: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> We are currently using "hg tip" to create the "source_tips" file, and correspondingly for the closed bundles. But this is incorrect. It will show the latest committed version in the repo, not the actual workspace (i.e. the version we actually build). For this, we should use "hg id" instead. If we have a clean workspace updated to the tip, it will produce the same output. Otherwise it will show what we build, with a traliing "+" if there are local, non-committed changed. Also, we should not name the file "tip" in this case. And finally, we do not need to sprinkle these files all around in all repos. The entire handling should be more clearly abstracted. Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Nov 24 15:13:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 Nov 2016 16:13:35 +0100 Subject: RFR: JDK-8031567 Better model for storing source revision information In-Reply-To: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> References: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> Message-ID: Hello, SourceRevision.gmk:34: typo "recreate" 70-74: Seems unnecessary to conditionally update the intermediate files since they are only read in the same makefile anyway. The conditional update does make sense for CreateSourceRevisionFile however. 88: indentation looks weird 113, 123, 127: Use LogWarn instead of echo? /Erik On 2016-11-24 15:54, Magnus Ihse Bursie wrote: > We are currently using "hg tip" to create the "source_tips" file, and > correspondingly for the closed bundles. > > But this is incorrect. It will show the latest committed version in > the repo, not the actual workspace (i.e. the version we actually build). > > For this, we should use "hg id" instead. If we have a clean workspace > updated to the tip, it will produce the same output. Otherwise it will > show what we build, with a traliing "+" if there are local, > non-committed changed. > > Also, we should not name the file "tip" in this case. > > And finally, we do not need to sprinkle these files all around in all > repos. The entire handling should be more clearly abstracted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 > > /Magnus From david.holmes at oracle.com Thu Nov 24 23:27:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Nov 2016 09:27:47 +1000 Subject: RFR: JDK-8031567 Better model for storing source revision information In-Reply-To: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> References: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> Message-ID: <1d9eb504-38e6-0124-69b0-df9cc986de2a@oracle.com> Hi Magnus, On 25/11/2016 12:54 AM, Magnus Ihse Bursie wrote: > We are currently using "hg tip" to create the "source_tips" file, and > correspondingly for the closed bundles. > > But this is incorrect. It will show the latest committed version in the > repo, not the actual workspace (i.e. the version we actually build). > > For this, we should use "hg id" instead. If we have a clean workspace > updated to the tip, it will produce the same output. Otherwise it will > show what we build, with a traliing "+" if there are local, > non-committed changed. So hg id doesn't actually help in someone else recreating the same sources as a build, because they won't have access to the uncommitted changes. This is simply an indicator that this build has such uncommitted changes. Is that right? Thanks, David > Also, we should not name the file "tip" in this case. > > And finally, we do not need to sprinkle these files all around in all > repos. The entire handling should be more clearly abstracted. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 > > > /Magnus From david.holmes at oracle.com Thu Nov 24 23:30:45 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Nov 2016 09:30:45 +1000 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> <06862250-667d-055a-6d96-bee7b5a62e62@oracle.com> Message-ID: On 24/11/2016 8:12 PM, Erik Joelsson wrote: > On 2016-11-24 00:54, David Holmes wrote: >> Hi Erik, >> >> On 24/11/2016 2:28 AM, Erik Joelsson wrote: >>> Discovered an issue with cross compiling configurations. In >>> buildjdk-spec.gmk.in, need to also override the new variable >>> JVM_VARIANTS_MAIN. New webrev: >>> >>> http://cr.openjdk.java.net/~erikj/8170284/webrev.02/ >> >> Seems reasonable but I don't understand these two targets: >> >> + $(info $(_) make hotspot- # Build just the >> specified jvm variant) >> + $(info $(_) make hotspot-libs # Build the native >> libraries for hotspot) >> >> Given that the JVM variant defines which libjvm to build, and that is >> the primary "hotspot native library", I don't see how these two can be >> distinct ?? >> > In the current build, "hotspot-libs" happens to be synonymous with just > "hotspot" as it builds all the native libraries, and the hotspot build > doesn't have any more targets in its pipeline. In theory, we could add > additional build phases for hotspot in the future. I agree it's not very > useful to document this target as it currently stands however. So you got rid of the help doc but still kept the target ?? David > /Erik >> Thanks, >> David >> >>> /Erik >>> >>> On 2016-11-23 16:05, Erik Joelsson wrote: >>>> After the hotspot makefile rewrite and the elimination of the hotspot >>>> dist output directory, it's now time to create more fine granular top >>>> level make targets for building hotspot. This will enable better >>>> granularity in between hotspot build steps and the rest of the build. >>>> Building native libraries in the JDK will only need to wait for one >>>> libjvm to be built. Building docs will only require the gensrc step in >>>> hotspot to be built. >>>> >>>> Here is the full list of new targets proposed: >>>> hotspot-gensrc >>>> hotspot-libs >>>> hotspot- >>>> hotspot--gensrc >>>> hotspot--libs >>>> hotspot-jsig >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 >>>> >>>> /Erik >>>> >>> > From erik.joelsson at oracle.com Fri Nov 25 07:50:48 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Nov 2016 08:50:48 +0100 Subject: RFR: JDK-8031567 Better model for storing source revision information In-Reply-To: <1d9eb504-38e6-0124-69b0-df9cc986de2a@oracle.com> References: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> <1d9eb504-38e6-0124-69b0-df9cc986de2a@oracle.com> Message-ID: <75dacc77-c469-5940-fb73-ccaab2c1d9ef@oracle.com> On 2016-11-25 00:27, David Holmes wrote: > Hi Magnus, > > On 25/11/2016 12:54 AM, Magnus Ihse Bursie wrote: >> We are currently using "hg tip" to create the "source_tips" file, and >> correspondingly for the closed bundles. >> >> But this is incorrect. It will show the latest committed version in the >> repo, not the actual workspace (i.e. the version we actually build). >> >> For this, we should use "hg id" instead. If we have a clean workspace >> updated to the tip, it will produce the same output. Otherwise it will >> show what we build, with a traliing "+" if there are local, >> non-committed changed. > > So hg id doesn't actually help in someone else recreating the same > sources as a build, because they won't have access to the uncommitted > changes. This is simply an indicator that this build has such > uncommitted changes. Is that right? > That is correct, but at least you will know that there were uncommitted changes. /Erik > Thanks, > David > > >> Also, we should not name the file "tip" in this case. >> >> And finally, we do not need to sprinkle these files all around in all >> repos. The entire handling should be more clearly abstracted. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 >> >> >> >> /Magnus From david.holmes at oracle.com Fri Nov 25 07:51:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Nov 2016 17:51:52 +1000 Subject: RFR: JDK-8031567 Better model for storing source revision information In-Reply-To: <75dacc77-c469-5940-fb73-ccaab2c1d9ef@oracle.com> References: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> <1d9eb504-38e6-0124-69b0-df9cc986de2a@oracle.com> <75dacc77-c469-5940-fb73-ccaab2c1d9ef@oracle.com> Message-ID: <35de1e09-2281-e7fe-3bf2-c8cb14296e56@oracle.com> On 25/11/2016 5:50 PM, Erik Joelsson wrote: > On 2016-11-25 00:27, David Holmes wrote: >> Hi Magnus, >> >> On 25/11/2016 12:54 AM, Magnus Ihse Bursie wrote: >>> We are currently using "hg tip" to create the "source_tips" file, and >>> correspondingly for the closed bundles. >>> >>> But this is incorrect. It will show the latest committed version in the >>> repo, not the actual workspace (i.e. the version we actually build). >>> >>> For this, we should use "hg id" instead. If we have a clean workspace >>> updated to the tip, it will produce the same output. Otherwise it will >>> show what we build, with a traliing "+" if there are local, >>> non-committed changed. >> >> So hg id doesn't actually help in someone else recreating the same >> sources as a build, because they won't have access to the uncommitted >> changes. This is simply an indicator that this build has such >> uncommitted changes. Is that right? >> > That is correct, but at least you will know that there were uncommitted > changes. Yep that is a good thing! Thanks, David > /Erik >> Thanks, >> David >> >> >>> Also, we should not name the file "tip" in this case. >>> >>> And finally, we do not need to sprinkle these files all around in all >>> repos. The entire handling should be more clearly abstracted. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 >>> >>> >>> >>> /Magnus > From erik.joelsson at oracle.com Fri Nov 25 07:58:03 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Nov 2016 08:58:03 +0100 Subject: RFR: JDK-8170284: Move fine granular hotspot make targets to top level In-Reply-To: References: <5bbe3c50-fd80-131e-e2ab-6be3bf6d9cd9@oracle.com> <06862250-667d-055a-6d96-bee7b5a62e62@oracle.com> Message-ID: On 2016-11-25 00:30, David Holmes wrote: > On 24/11/2016 8:12 PM, Erik Joelsson wrote: >> On 2016-11-24 00:54, David Holmes wrote: >>> Hi Erik, >>> >>> On 24/11/2016 2:28 AM, Erik Joelsson wrote: >>>> Discovered an issue with cross compiling configurations. In >>>> buildjdk-spec.gmk.in, need to also override the new variable >>>> JVM_VARIANTS_MAIN. New webrev: >>>> >>>> http://cr.openjdk.java.net/~erikj/8170284/webrev.02/ >>> >>> Seems reasonable but I don't understand these two targets: >>> >>> + $(info $(_) make hotspot- # Build just the >>> specified jvm variant) >>> + $(info $(_) make hotspot-libs # Build the native >>> libraries for hotspot) >>> >>> Given that the JVM variant defines which libjvm to build, and that is >>> the primary "hotspot native library", I don't see how these two can be >>> distinct ?? >>> >> In the current build, "hotspot-libs" happens to be synonymous with just >> "hotspot" as it builds all the native libraries, and the hotspot build >> doesn't have any more targets in its pipeline. In theory, we could add >> additional build phases for hotspot in the future. I agree it's not very >> useful to document this target as it currently stands however. > > So you got rid of the help doc but still kept the target ?? > Yes, I think it makes sense to complete the pattern of hotspot-gensrc/hotspot-libs, hotspot--gensrc/hotspot--libs, but since it doesn't serve much of a practical purpose at this point, there is no need to encourage users to use it in the help text. /Erik > David > >> /Erik >>> Thanks, >>> David >>> >>>> /Erik >>>> >>>> On 2016-11-23 16:05, Erik Joelsson wrote: >>>>> After the hotspot makefile rewrite and the elimination of the hotspot >>>>> dist output directory, it's now time to create more fine granular top >>>>> level make targets for building hotspot. This will enable better >>>>> granularity in between hotspot build steps and the rest of the build. >>>>> Building native libraries in the JDK will only need to wait for one >>>>> libjvm to be built. Building docs will only require the gensrc >>>>> step in >>>>> hotspot to be built. >>>>> >>>>> Here is the full list of new targets proposed: >>>>> hotspot-gensrc >>>>> hotspot-libs >>>>> hotspot- >>>>> hotspot--gensrc >>>>> hotspot--libs >>>>> hotspot-jsig >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170284 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8170284/webrev.01 >>>>> >>>>> /Erik >>>>> >>>> >> From volker.simonis at gmail.com Fri Nov 25 13:32:37 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Nov 2016 14:32:37 +0100 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <5835B6D7.4020101@linux.vnet.ibm.com> References: <583394C5.3030206@linux.vnet.ibm.com> <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> <5835B6D7.4020101@linux.vnet.ibm.com> Message-ID: Hi Gustavo, we've realized that we have exactly the same problem on Linux/s390 so I hope you don't mind that I've updated the bug and the webrev to also include the fix for Linux/s390: http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/ http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.jdk/ https://bugs.openjdk.java.net/browse/JDK-8170153 The top-level change stays the same (I've only added the current reviewers) and for the jdk change I've just added Linux/s390 as another platform which can compile fdlibm with HIGH optimization. Thanks, Volker On Wed, Nov 23, 2016 at 4:33 PM, Gustavo Romero wrote: > Hi Erik, > > On 23-11-2016 12:29, Erik Joelsson wrote: >> Build changes look ok. >> >> In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. > > Thanks a lot for reviewing the change. > > > Regards, > Gustavo > From erik.joelsson at oracle.com Fri Nov 25 14:06:27 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Nov 2016 15:06:27 +0100 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583394C5.3030206@linux.vnet.ibm.com> <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> <5835B6D7.4020101@linux.vnet.ibm.com> Message-ID: <98b7942d-837e-0166-93de-9ea256bb1ecf@oracle.com> Looks good. /Erik On 2016-11-25 14:32, Volker Simonis wrote: > Hi Gustavo, > > we've realized that we have exactly the same problem on Linux/s390 so > I hope you don't mind that I've updated the bug and the webrev to also > include the fix for Linux/s390: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/ > http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.jdk/ > https://bugs.openjdk.java.net/browse/JDK-8170153 > > The top-level change stays the same (I've only added the current > reviewers) and for the jdk change I've just added Linux/s390 as > another platform which can compile fdlibm with HIGH optimization. > > Thanks, > Volker > > On Wed, Nov 23, 2016 at 4:33 PM, Gustavo Romero > wrote: >> Hi Erik, >> >> On 23-11-2016 12:29, Erik Joelsson wrote: >>> Build changes look ok. >>> >>> In CoreLibraries.gmk, I think it would have been ok to keep the conditional checking (OPENJDK_TARGET_CPU_ARCH, ppc), but this certainly works too. >> Thanks a lot for reviewing the change. >> >> >> Regards, >> Gustavo >> From magnus.ihse.bursie at oracle.com Fri Nov 25 14:36:46 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Nov 2016 15:36:46 +0100 Subject: RFR: JDK-8031567 Better model for storing source revision information In-Reply-To: References: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> Message-ID: <3d173ac8-d5dd-9fa0-0821-6ac2c566afc7@oracle.com> On 2016-11-24 16:13, Erik Joelsson wrote: > Hello, > > SourceRevision.gmk:34: typo "recreate" > > 70-74: Seems unnecessary to conditionally update the intermediate > files since they are only read in the same makefile anyway. The > conditional update does make sense for CreateSourceRevisionFile however. > > 88: indentation looks weird > > 113, 123, 127: Use LogWarn instead of echo? Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.02 /Magnus > > /Erik > > > On 2016-11-24 15:54, Magnus Ihse Bursie wrote: >> We are currently using "hg tip" to create the "source_tips" file, and >> correspondingly for the closed bundles. >> >> But this is incorrect. It will show the latest committed version in >> the repo, not the actual workspace (i.e. the version we actually build). >> >> For this, we should use "hg id" instead. If we have a clean workspace >> updated to the tip, it will produce the same output. Otherwise it >> will show what we build, with a traliing "+" if there are local, >> non-committed changed. >> >> Also, we should not name the file "tip" in this case. >> >> And finally, we do not need to sprinkle these files all around in all >> repos. The entire handling should be more clearly abstracted. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 >> >> /Magnus > From aph at redhat.com Fri Nov 25 14:51:35 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Nov 2016 14:51:35 +0000 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833943E.9010807@linux.vnet.ibm.com> Message-ID: On 22/11/16 09:57, Andrew Haley wrote: > On 22/11/16 00:41, Gustavo Romero wrote: >> Do you know if the gap between Math and StrictMath is also huge on aarch64? > > I'll try to have a look. The gap is just the same as PPC. Andrew. From erik.joelsson at oracle.com Fri Nov 25 15:56:42 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 Nov 2016 16:56:42 +0100 Subject: RFR: JDK-8031567 Better model for storing source revision information In-Reply-To: <3d173ac8-d5dd-9fa0-0821-6ac2c566afc7@oracle.com> References: <7f35a3ca-09e9-a785-112a-47ff3587bd2c@oracle.com> <3d173ac8-d5dd-9fa0-0821-6ac2c566afc7@oracle.com> Message-ID: <38fa0bf8-b006-9c3d-c947-96c0e4b715d6@oracle.com> Looks good. /Erik On 2016-11-25 15:36, Magnus Ihse Bursie wrote: > On 2016-11-24 16:13, Erik Joelsson wrote: >> Hello, >> >> SourceRevision.gmk:34: typo "recreate" >> >> 70-74: Seems unnecessary to conditionally update the intermediate >> files since they are only read in the same makefile anyway. The >> conditional update does make sense for CreateSourceRevisionFile however. >> >> 88: indentation looks weird >> >> 113, 123, 127: Use LogWarn instead of echo? > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.02 > > /Magnus > >> >> /Erik >> >> >> On 2016-11-24 15:54, Magnus Ihse Bursie wrote: >>> We are currently using "hg tip" to create the "source_tips" file, >>> and correspondingly for the closed bundles. >>> >>> But this is incorrect. It will show the latest committed version in >>> the repo, not the actual workspace (i.e. the version we actually >>> build). >>> >>> For this, we should use "hg id" instead. If we have a clean >>> workspace updated to the tip, it will produce the same output. >>> Otherwise it will show what we build, with a traliing "+" if there >>> are local, non-committed changed. >>> >>> Also, we should not name the file "tip" in this case. >>> >>> And finally, we do not need to sprinkle these files all around in >>> all repos. The entire handling should be more clearly abstracted. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8031567 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8031567-clean-up-source-revision-stamps/webrev.01 >>> >>> /Magnus >> > From volker.simonis at gmail.com Fri Nov 25 16:32:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 25 Nov 2016 17:32:04 +0100 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833943E.9010807@linux.vnet.ibm.com> Message-ID: On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: > On 22/11/16 09:57, Andrew Haley wrote: >> On 22/11/16 00:41, Gustavo Romero wrote: >>> Do you know if the gap between Math and StrictMath is also huge on aarch64? >> >> I'll try to have a look. > > The gap is just the same as PPC. > I've already extended the bug description and webrev for Linux/s390x. Please see my mail on the review thread for this issue: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025328.html If you want you're welcome to further extend it for aarch64 as well so we can push it all in one change. Regards, Volker > Andrew. > > From jwkozaczuk at gmail.com Sat Nov 26 14:51:48 2016 From: jwkozaczuk at gmail.com (Jola I Waldek) Date: Sat, 26 Nov 2016 09:51:48 -0500 Subject: Size difference of Java.base image between OSX and Linux References: <124A0C3B-28F0-4875-82EE-64F371918CF7@gmail.com> Message-ID: <8E7777F2-4103-4F24-A93C-8DA4CD953697@gmail.com> >> From: David Holmes >> Date: October 28, 2016 at 17:30:22 EDT >> To: Waldek Kozaczuk , jigsaw-dev at openjdk.java.net >> Subject: Re: Size difference of Java.base image between OSX and Linux >> >>> On 29/10/2016 3:32 AM, Waldek Kozaczuk wrote: >>> >>> I used jlink to create minimal custom JRE image on OSX and Linux and I noticed there is a significant difference in size. The Mac version takes 21M where the Linux one takes 30M which means Linux version is 50% bigger than Mac. >>> >>> Is it as you would have expected? Why is size difference so big? >>> >>> I noticed that lib/modules is similar in size (1M difference) but the biggest difference is between ./lib/server/libjvm.dylib (12 M) and ./lib/amd64/server/libjvm.so (21 M). So the linux version of the shared library object is almost twice as big on linux (both 64 bit). >> >> Nothing jlink related. This is a question for the build-dev and/or hotspot-dev folk. It seems that in 8u libjvm is <1MB larger on Linux than OSX. However in 9 the Linux version has steadily grown to ~21M while the OSX version has shrunk to ~12M. It may be related to the debugging/symbol info still present in the library. >> >> David >> >>> Here is the command I used to create the image: >>> jdk-9/bin/jlink --module-path jdk-9/jmods --add-modules java.base --output image_target --strip-debug --compress=2 >>> >>> Here is a detailed listing of files on Mac: >>> 68K ./bin/java 68K ./bin/keytool 8.0K ./conf/net.properties 4.0K ./conf/security/java.policy 40K ./conf/security/java.security 4.0K ./conf/security/policy/limited/default_local.policy 4.0K ./conf/security/policy/limited/default_US_export.policy 4.0K ./conf/security/policy/limited/exempt_local.policy 4.0K ./conf/security/policy/README.txt 4.0K ./conf/security/policy/unlimited/default_local.policy 4.0K ./conf/security/policy/unlimited/default_US_export.policy 20K ./include/classfile_constants.h 4.0K ./include/darwin/jni_md.h 76K ./include/jni.h 80K ./include/jvmti.h 4.0K ./include/jvmticmlr.h 68K ./lib/jli/libjli.dylib 16K ./lib/jspawnhelper 4.0K ./lib/jvm.cfg 204K ./lib/libjava.dylib 32K ./lib/libjimage.dylib 12K ./lib/libjsig.dylib 92K ./lib/libnet.dylib 68K ./lib/libnio.dylib 44K ./lib/libosxsecurity.dylib 48K ./lib/libverify.dylib 32K ./lib/libzip.dylib 7.2M ./lib/modules 4.0K ./lib/security/blacklist 4.0K ./lib/security/blacklisted.certs 112K ./lib/security/cacerts 8.0K ./lib/security/default.policy 0B ./lib/security/trusted.libraries 12K ./lib/server/libjsig.dylib 12M ./lib/server/libjvm.dylib 4.0K ./lib/server/Xusage.txt 104K ./lib/tzdb.dat 4.0K ./release >>> >>> Here is a detailed listing of files on Linux: >>> >>> 4.0K ./lib/security/blacklisted.certs >>> 8.0K ./lib/security/default.policy >>> 4.0K ./lib/security/blacklist >>> 0 ./lib/security/trusted.libraries >>> 104K ./lib/tzdb.dat >>> 12K ./lib/jexec >>> 4.0K ./lib/amd64/jvm.cfg >>> 108K ./lib/amd64/libnet.so >>> 72K ./lib/amd64/jli/libjli.so >>> 132K ./lib/amd64/libjimage.so >>> 220K ./lib/amd64/libjava.so >>> 36K ./lib/amd64/libzip.so >>> 21M ./lib/amd64/server/libjvm.so >>> 4.0K ./lib/amd64/server/Xusage.txt >>> 12K ./lib/amd64/server/libjsig.so >>> 88K ./lib/amd64/libnio.so >>> 12K ./lib/amd64/libjsig.so >>> 64K ./lib/amd64/libverify.so >>> 8.2M ./lib/modules >>> 4.0K ./release >>> 4.0K ./include/jvmticmlr.h >>> 4.0K ./include/linux/jni_md.h >>> 20K ./include/classfile_constants.h >>> 80K ./include/jvmti.h >>> 76K ./include/jni.h >>> 4.0K ./conf/security/policy/limited/default_local.policy >>> 4.0K ./conf/security/policy/limited/default_US_export.policy >>> 4.0K ./conf/security/policy/limited/exempt_local.policy >>> 4.0K ./conf/security/policy/README.txt >>> 4.0K ./conf/security/policy/unlimited/default_local.policy >>> 4.0K ./conf/security/policy/unlimited/default_US_export.policy >>> 40K ./conf/security/java.security >>> 4.0K ./conf/security/java.policy >>> 8.0K ./conf/net.properties >>> 12K ./bin/java >>> 12K ./bin/keytool >>> >>> Regards, >>> Waldek >>> >>> Sent from my iPhone >>> From magnus.ihse.bursie at oracle.com Mon Nov 28 09:11:44 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Nov 2016 10:11:44 +0100 Subject: RFR: JDK-8170385 JDK-8031567 broke source bundles Message-ID: <8e32fbf6-b705-9002-bbe9-6f098df43c67@oracle.com> Unfortunately, the fix for JDK-8031567 got some untested last-minute changes which broke it. :-( Bug: https://bugs.openjdk.java.net/browse/JDK-8170385 Patch inline: diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk --- a/make/SourceRevision.gmk +++ b/make/SourceRevision.gmk @@ -65,8 +65,8 @@ $1_FILENAME := $$(call MakeFilenameFromRepo, $1) $$(SUPPORT_OUTPUTDIR)/src-rev/$$($1_FILENAME): FRC - $(call MakeDir $$(@D)) - $(ECHO) $$(strip $1):`$(HG) id -i --repository $$($1_REPO_PATH)` > $$@ + $$(call MakeDir, $$(@D)) + $$(ECHO) $$(strip $1):`$$(HG) id -i --repository $$($1_REPO_PATH)` > $$@ REPO_REVISIONS += $$(SUPPORT_OUTPUTDIR)/src-rev/$$($1_FILENAME) endef @@ -81,7 +81,7 @@ # Param 1: The output file define CreateSourceRevisionFile $1: $$(REPO_REVISIONS) - $(call MakeDir $$(@D)) + $$(call MakeDir, $$(@D)) $$(ECHO) `$$(CAT) $$(REPO_REVISIONS)` > $$@.tmp if [ ! -f $$@ ] || [ "`$$(CAT) $$@`" != "`$$(CAT) $$@.tmp`" ]; then \ $$(MV) $$@.tmp $$@ ; \ /Magnus From erik.joelsson at oracle.com Mon Nov 28 09:13:15 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 10:13:15 +0100 Subject: RFR: JDK-8170385 JDK-8031567 broke source bundles In-Reply-To: <8e32fbf6-b705-9002-bbe9-6f098df43c67@oracle.com> References: <8e32fbf6-b705-9002-bbe9-6f098df43c67@oracle.com> Message-ID: <47b33719-5adc-b76a-848a-84740107baaa@oracle.com> Looks good. /Erik On 2016-11-28 10:11, Magnus Ihse Bursie wrote: > Unfortunately, the fix for JDK-8031567 > got some untested > last-minute changes which broke it. :-( > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170385 > Patch inline: > diff --git a/make/SourceRevision.gmk b/make/SourceRevision.gmk > --- a/make/SourceRevision.gmk > +++ b/make/SourceRevision.gmk > @@ -65,8 +65,8 @@ > $1_FILENAME := $$(call MakeFilenameFromRepo, $1) > > $$(SUPPORT_OUTPUTDIR)/src-rev/$$($1_FILENAME): FRC > - $(call MakeDir $$(@D)) > - $(ECHO) $$(strip $1):`$(HG) id -i --repository > $$($1_REPO_PATH)` > $$@ > + $$(call MakeDir, $$(@D)) > + $$(ECHO) $$(strip $1):`$$(HG) id -i --repository > $$($1_REPO_PATH)` > $$@ > > REPO_REVISIONS += $$(SUPPORT_OUTPUTDIR)/src-rev/$$($1_FILENAME) > endef > @@ -81,7 +81,7 @@ > # Param 1: The output file > define CreateSourceRevisionFile > $1: $$(REPO_REVISIONS) > - $(call MakeDir $$(@D)) > + $$(call MakeDir, $$(@D)) > $$(ECHO) `$$(CAT) $$(REPO_REVISIONS)` > $$@.tmp > if [ ! -f $$@ ] || [ "`$$(CAT) $$@`" != "`$$(CAT) $$@.tmp`" ]; > then \ > $$(MV) $$@.tmp $$@ ; \ > > /Magnus From erik.joelsson at oracle.com Mon Nov 28 09:37:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 10:37:21 +0100 Subject: Size difference of Java.base image between OSX and Linux In-Reply-To: <8E7777F2-4103-4F24-A93C-8DA4CD953697@gmail.com> References: <124A0C3B-28F0-4875-82EE-64F371918CF7@gmail.com> <8E7777F2-4103-4F24-A93C-8DA4CD953697@gmail.com> Message-ID: <54648000-1dd8-4864-839e-e4f06a58f889@oracle.com> Hello, In my build of OpenJDK 9 (updated from dev today), libjvm.so on linux x64 is 20902848B. It has been stripped using "strip -g" which means remove all debug symbols. It seems it can be reduced further to 17611752B using "strip --strip-unneeded", but I don't know if that is safe to do. By default we use static linking of libstdc++ for libjvm.so for maximum portability of the binaries. In the OpenJDK community it's common to configure dynamic linking. This slightly reduces size to 19908552B. Note that we build using GCC on Linux and Clang on macosx. I'm guessing that's the biggest source of size differences. /Erik On 2016-11-26 15:51, Jola I Waldek wrote: > >>> From: David Holmes >>> Date: October 28, 2016 at 17:30:22 EDT >>> To: Waldek Kozaczuk , jigsaw-dev at openjdk.java.net >>> Subject: Re: Size difference of Java.base image between OSX and Linux >>> >>>> On 29/10/2016 3:32 AM, Waldek Kozaczuk wrote: >>>> >>>> I used jlink to create minimal custom JRE image on OSX and Linux and I noticed there is a significant difference in size. The Mac version takes 21M where the Linux one takes 30M which means Linux version is 50% bigger than Mac. >>>> >>>> Is it as you would have expected? Why is size difference so big? >>>> >>>> I noticed that lib/modules is similar in size (1M difference) but the biggest difference is between ./lib/server/libjvm.dylib (12 M) and ./lib/amd64/server/libjvm.so (21 M). So the linux version of the shared library object is almost twice as big on linux (both 64 bit). >>> Nothing jlink related. This is a question for the build-dev and/or hotspot-dev folk. It seems that in 8u libjvm is <1MB larger on Linux than OSX. However in 9 the Linux version has steadily grown to ~21M while the OSX version has shrunk to ~12M. It may be related to the debugging/symbol info still present in the library. >>> >>> David >>> >>>> Here is the command I used to create the image: >>>> jdk-9/bin/jlink --module-path jdk-9/jmods --add-modules java.base --output image_target --strip-debug --compress=2 >>>> >>>> Here is a detailed listing of files on Mac: >>>> 68K ./bin/java 68K ./bin/keytool 8.0K ./conf/net.properties 4.0K ./conf/security/java.policy 40K ./conf/security/java.security 4.0K ./conf/security/policy/limited/default_local.policy 4.0K ./conf/security/policy/limited/default_US_export.policy 4.0K ./conf/security/policy/limited/exempt_local.policy 4.0K ./conf/security/policy/README.txt 4.0K ./conf/security/policy/unlimited/default_local.policy 4.0K ./conf/security/policy/unlimited/default_US_export.policy 20K ./include/classfile_constants.h 4.0K ./include/darwin/jni_md.h 76K ./include/jni.h 80K ./include/jvmti.h 4.0K ./include/jvmticmlr.h 68K ./lib/jli/libjli.dylib 16K ./lib/jspawnhelper 4.0K ./lib/jvm.cfg 204K ./lib/libjava.dylib 32K ./lib/libjimage.dylib 12K ./lib/libjsig.dylib 92K ./lib/libnet.dylib 68K ./lib/libnio.dylib 44K ./lib/libosxsecurity.dylib 48K ./lib/libverify.dylib 32K ./lib/libzip.dylib 7.2M ./lib/modules 4.0K ./lib/security/blacklist 4.0K ./lib/security/blacklisted.certs 112K ./lib/security/cacerts 8.0K ./lib/security/default.policy 0B ./lib/security/trusted.libraries 12K ./lib/server/libjsig.dylib 12M ./lib/server/libjvm.dylib 4.0K ./lib/server/Xusage.txt 104K ./lib/tzdb.dat 4.0K ./release >>>> >>>> Here is a detailed listing of files on Linux: >>>> >>>> 4.0K ./lib/security/blacklisted.certs >>>> 8.0K ./lib/security/default.policy >>>> 4.0K ./lib/security/blacklist >>>> 0 ./lib/security/trusted.libraries >>>> 104K ./lib/tzdb.dat >>>> 12K ./lib/jexec >>>> 4.0K ./lib/amd64/jvm.cfg >>>> 108K ./lib/amd64/libnet.so >>>> 72K ./lib/amd64/jli/libjli.so >>>> 132K ./lib/amd64/libjimage.so >>>> 220K ./lib/amd64/libjava.so >>>> 36K ./lib/amd64/libzip.so >>>> 21M ./lib/amd64/server/libjvm.so >>>> 4.0K ./lib/amd64/server/Xusage.txt >>>> 12K ./lib/amd64/server/libjsig.so >>>> 88K ./lib/amd64/libnio.so >>>> 12K ./lib/amd64/libjsig.so >>>> 64K ./lib/amd64/libverify.so >>>> 8.2M ./lib/modules >>>> 4.0K ./release >>>> 4.0K ./include/jvmticmlr.h >>>> 4.0K ./include/linux/jni_md.h >>>> 20K ./include/classfile_constants.h >>>> 80K ./include/jvmti.h >>>> 76K ./include/jni.h >>>> 4.0K ./conf/security/policy/limited/default_local.policy >>>> 4.0K ./conf/security/policy/limited/default_US_export.policy >>>> 4.0K ./conf/security/policy/limited/exempt_local.policy >>>> 4.0K ./conf/security/policy/README.txt >>>> 4.0K ./conf/security/policy/unlimited/default_local.policy >>>> 4.0K ./conf/security/policy/unlimited/default_US_export.policy >>>> 40K ./conf/security/java.security >>>> 4.0K ./conf/security/java.policy >>>> 8.0K ./conf/net.properties >>>> 12K ./bin/java >>>> 12K ./bin/keytool >>>> >>>> Regards, >>>> Waldek >>>> >>>> Sent from my iPhone >>>> From magnus.ihse.bursie at oracle.com Mon Nov 28 09:43:23 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Nov 2016 10:43:23 +0100 Subject: RFR: JDK-8072413 Configure should fail for VS2010 without SP1 since that cannot build Message-ID: When building with VS2010 without SP1, the build will fail with: LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt This creates frustration and support questions in the build mailing list from time to time. We should check for VS2010 without SP1 at configure time, and fail if this is detected. Bug: https://bugs.openjdk.java.net/browse/JDK-8072413 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072413-require-vs2010-sp1/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Mon Nov 28 09:47:37 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Nov 2016 10:47:37 +0100 Subject: RFR: JDK-8056215 AWT source dirs should only point to java2d, not below Message-ID: <022eee53-0e33-5f17-bc14-ebe6f2e45260@oracle.com> This is from a code review following the jigsaw source file restructuring: * The makefiles include too specific directories. Instead of including e.g. ./*/native/common/sun/java2d/opengl and ./*/native/common/sun/java2d/x11, we should just include ./*/native/common/sun/java2d. This level corresponds to a logical grouping of the source code, and not the directory structure in that grouping. Bug: https://bugs.openjdk.java.net/browse/JDK-8056215 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8056215-cleanup-awt-src-dirs/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Nov 28 09:56:13 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 10:56:13 +0100 Subject: RFR: JDK-8072413 Configure should fail for VS2010 without SP1 since that cannot build In-Reply-To: References: Message-ID: <76330134-a34d-41e3-58eb-fbe43f168c4b@oracle.com> Looks good. /Erik On 2016-11-28 10:43, Magnus Ihse Bursie wrote: > When building with VS2010 without SP1, the build will fail with: > LINK : fatal error LNK1123: failure during conversion to COFF: file > invalid or corrupt > > This creates frustration and support questions in the build mailing > list from time to time. > > We should check for VS2010 without SP1 at configure time, and fail if > this is detected. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072413 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8072413-require-vs2010-sp1/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Nov 28 10:01:33 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 11:01:33 +0100 Subject: RFR: JDK-8056215 AWT source dirs should only point to java2d, not below In-Reply-To: <022eee53-0e33-5f17-bc14-ebe6f2e45260@oracle.com> References: <022eee53-0e33-5f17-bc14-ebe6f2e45260@oracle.com> Message-ID: <990b6c7a-58ee-1ccb-3c33-60844fe2908b@oracle.com> It looks like this will result in the same files being built, but just to be sure, have you verified the result to be equal? /Erik On 2016-11-28 10:47, Magnus Ihse Bursie wrote: > This is from a code review following the jigsaw source file > restructuring: > > * The makefiles include too specific directories. Instead of including > e.g. ./*/native/common/sun/java2d/opengl and > ./*/native/common/sun/java2d/x11, we should just include > ./*/native/common/sun/java2d. This level corresponds to a logical > grouping of the source code, and not the directory structure in that > grouping. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8056215 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8056215-cleanup-awt-src-dirs/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Nov 28 12:41:32 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 13:41:32 +0100 Subject: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles Message-ID: <4f7e85c5-9a6e-7830-7118-c2a06f5c0a46@oracle.com> In JDK-8031567, the format for storing source revision information for use in builds from source bundles changed. The behavior when building without either mercurial or the stored revision information also changed. We used to silently ignore the lack of source revision information, but now the build fails. Since it's not an uncommon use case in our Oracle internal infrastructure (JPRT, Mach 5) to have builds without either mercurial or stored revision information, this needs to be downgraded this to at most a warning. Bug: https://bugs.openjdk.java.net/browse/JDK-8170392 Webrev: http://cr.openjdk.java.net/~erikj/8170392/webrev.01/ /Erik From staffan.larsen at oracle.com Mon Nov 28 12:49:52 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Nov 2016 13:49:52 +0100 Subject: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles In-Reply-To: <4f7e85c5-9a6e-7830-7118-c2a06f5c0a46@oracle.com> References: <4f7e85c5-9a6e-7830-7118-c2a06f5c0a46@oracle.com> Message-ID: <870F800C-3260-4E67-9070-5E356BCD9F21@oracle.com> Looks good to me! Thanks, /Staffan > On 28 Nov 2016, at 13:41, Erik Joelsson wrote: > > In JDK-8031567, the format for storing source revision information for use in builds from source bundles changed. The behavior when building without either mercurial or the stored revision information also changed. We used to silently ignore the lack of source revision information, but now the build fails. > > Since it's not an uncommon use case in our Oracle internal infrastructure (JPRT, Mach 5) to have builds without either mercurial or stored revision information, this needs to be downgraded this to at most a warning. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170392 > > Webrev: http://cr.openjdk.java.net/~erikj/8170392/webrev.01/ > > /Erik > From erik.joelsson at oracle.com Mon Nov 28 12:52:07 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 13:52:07 +0100 Subject: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles In-Reply-To: <870F800C-3260-4E67-9070-5E356BCD9F21@oracle.com> References: <4f7e85c5-9a6e-7830-7118-c2a06f5c0a46@oracle.com> <870F800C-3260-4E67-9070-5E356BCD9F21@oracle.com> Message-ID: <38a5538b-771f-741a-38bd-46d116052cf1@oracle.com> Thanks, but unfortunately, the build breaks again later. Updated webrev in place. /Erik On 2016-11-28 13:49, Staffan Larsen wrote: > Looks good to me! > > Thanks, > /Staffan > >> On 28 Nov 2016, at 13:41, Erik Joelsson wrote: >> >> In JDK-8031567, the format for storing source revision information for use in builds from source bundles changed. The behavior when building without either mercurial or the stored revision information also changed. We used to silently ignore the lack of source revision information, but now the build fails. >> >> Since it's not an uncommon use case in our Oracle internal infrastructure (JPRT, Mach 5) to have builds without either mercurial or stored revision information, this needs to be downgraded this to at most a warning. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170392 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170392/webrev.01/ >> >> /Erik >> From staffan.larsen at oracle.com Mon Nov 28 12:54:08 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 28 Nov 2016 13:54:08 +0100 Subject: RFR: JDK-8170392: JDK-8031567 broke builds from source bundles In-Reply-To: <38a5538b-771f-741a-38bd-46d116052cf1@oracle.com> References: <4f7e85c5-9a6e-7830-7118-c2a06f5c0a46@oracle.com> <870F800C-3260-4E67-9070-5E356BCD9F21@oracle.com> <38a5538b-771f-741a-38bd-46d116052cf1@oracle.com> Message-ID: <260AD3AC-A9AE-442B-8CD1-DB259DA067B3@oracle.com> Looks better to me! /Staffan > On 28 Nov 2016, at 13:52, Erik Joelsson wrote: > > Thanks, but unfortunately, the build breaks again later. Updated webrev in place. > > /Erik > > > On 2016-11-28 13:49, Staffan Larsen wrote: >> Looks good to me! >> >> Thanks, >> /Staffan >> >>> On 28 Nov 2016, at 13:41, Erik Joelsson wrote: >>> >>> In JDK-8031567, the format for storing source revision information for use in builds from source bundles changed. The behavior when building without either mercurial or the stored revision information also changed. We used to silently ignore the lack of source revision information, but now the build fails. >>> >>> Since it's not an uncommon use case in our Oracle internal infrastructure (JPRT, Mach 5) to have builds without either mercurial or stored revision information, this needs to be downgraded this to at most a warning. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170392 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8170392/webrev.01/ >>> >>> /Erik >>> > From gromero at linux.vnet.ibm.com Mon Nov 28 13:24:40 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 28 Nov 2016 11:24:40 -0200 Subject: RFR(s) 8170153: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583394C5.3030206@linux.vnet.ibm.com> <9327e543-f35b-b88f-2831-a51e265b6a30@oracle.com> <5835B6D7.4020101@linux.vnet.ibm.com> Message-ID: <583C3018.5080109@linux.vnet.ibm.com> Hi Volker, Sorry for not replying earlier, it was day-off on Friday here... On 25-11-2016 11:32, Volker Simonis wrote: > Hi Gustavo, > > we've realized that we have exactly the same problem on Linux/s390 so > I hope you don't mind that I've updated the bug and the webrev to also > include the fix for Linux/s390: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.top/ > http://cr.openjdk.java.net/~simonis/webrevs/2016/8170153.jdk/ > https://bugs.openjdk.java.net/browse/JDK-8170153 > > The top-level change stays the same (I've only added the current > reviewers) and for the jdk change I've just added Linux/s390 as > another platform which can compile fdlibm with HIGH optimization. Actually, it's really cool to know that an analysis on PPC64 contributed also to the s390 arch! :) Thanks for providing the updated webrevs. Regards, Gustavo From gromero at linux.vnet.ibm.com Mon Nov 28 13:34:03 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 28 Nov 2016 11:34:03 -0200 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833943E.9010807@linux.vnet.ibm.com> Message-ID: <583C324B.6030407@linux.vnet.ibm.com> Hi Volker, On 25-11-2016 14:32, Volker Simonis wrote: > On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: >> On 22/11/16 09:57, Andrew Haley wrote: >>> On 22/11/16 00:41, Gustavo Romero wrote: >>>> Do you know if the gap between Math and StrictMath is also huge on aarch64? >>> >>> I'll try to have a look. >> >> The gap is just the same as PPC. >> > > I've already extended the bug description and webrev for Linux/s390x. > Please see my mail on the review thread for this issue: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025328.html > > If you want you're welcome to further extend it for aarch64 as well so > we can push it all in one change. > > Regards, > Volker As Andrew extended the JBS to include aarch64, I just talked to him and he will check if the solution also applies to aarch64. If so and if you don't mind I'll update your webrev to include aarch64 as well. Should I also update the JBS ticket title to include aarch64 and resent a RFR on the same thread? Finally, once the review process is done, should I update FC Extenstion Request "Remaining work" from "to be reviewed" to "none" in order to proceed with the approval request? Thank you! Regards, Gustavo From volker.simonis at gmail.com Mon Nov 28 15:28:36 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Nov 2016 16:28:36 +0100 Subject: RFR: JDK-8072413 Configure should fail for VS2010 without SP1 since that cannot build In-Reply-To: <76330134-a34d-41e3-58eb-fbe43f168c4b@oracle.com> References: <76330134-a34d-41e3-58eb-fbe43f168c4b@oracle.com> Message-ID: On Mon, Nov 28, 2016 at 10:56 AM, Erik Joelsson wrote: > Looks good. > > /Erik > > > > On 2016-11-28 10:43, Magnus Ihse Bursie wrote: >> >> When building with VS2010 without SP1, the build will fail with: >> LINK : fatal error LNK1123: failure during conversion to COFF: file >> invalid or corrupt >> >> This creates frustration and support questions in the build mailing list >> from time to time. >> >> We should check for VS2010 without SP1 at configure time, and fail if this >> is detected. I don't think this is really an issue of VS2010 vs. VS2010 SP1. It is actually a problem of installation order. Please see my previous mail to build-dev (http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014775.html) and the corresponding stack overflow article: ... the COFF isue is a known problem with VS2010 after installing VS2012 or .NET 4.5.1. There exist various workarounds - just google for "LINK : fatal error LNK1123: failure during conversion to COFF: file invalid". The easiest and fastes solution is to remove the bad version of "cvtres.exe" which is causing the problem as explained in the second answer at the stackowerflow question http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval ... I'm still happily building with VS2010 and I don't see a reason why we should artificially prevent users from doing so. Regards, Volker >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072413 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8072413-require-vs2010-sp1/webrev.01 >> >> /Magnus > > From volker.simonis at gmail.com Mon Nov 28 15:43:06 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Nov 2016 16:43:06 +0100 Subject: PPC64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583C324B.6030407@linux.vnet.ibm.com> References: <582D0BCE.2030209@linux.vnet.ibm.com> <582DF764.70504@linux.vnet.ibm.com> <5a4a0e96-71b5-247b-60ea-5eb518d2162b@oracle.com> <5833943E.9010807@linux.vnet.ibm.com> <583C324B.6030407@linux.vnet.ibm.com> Message-ID: On Mon, Nov 28, 2016 at 2:34 PM, Gustavo Romero wrote: > Hi Volker, > > On 25-11-2016 14:32, Volker Simonis wrote: >> On Fri, Nov 25, 2016 at 3:51 PM, Andrew Haley wrote: >>> On 22/11/16 09:57, Andrew Haley wrote: >>>> On 22/11/16 00:41, Gustavo Romero wrote: >>>>> Do you know if the gap between Math and StrictMath is also huge on aarch64? >>>> >>>> I'll try to have a look. >>> >>> The gap is just the same as PPC. >>> >> >> I've already extended the bug description and webrev for Linux/s390x. >> Please see my mail on the review thread for this issue: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025328.html >> >> If you want you're welcome to further extend it for aarch64 as well so >> we can push it all in one change. >> >> Regards, >> Volker > > As Andrew extended the JBS to include aarch64, I just talked to him and he will > check if the solution also applies to aarch64. If so and if you don't mind I'll > update your webrev to include aarch64 as well. > Sure, please take my last webrev as template which already includes the part for s390x. > Should I also update the JBS ticket title to include aarch64 and resent a RFR on > the same thread? > Yes please. > Finally, once the review process is done, should I update FC Extenstion Request > "Remaining work" from "to be reviewed" to "none" in order to proceed with the > approval request? > Yes, please do so. Thanks a lot, Volker > Thank you! > > > Regards, > Gustavo > From erik.joelsson at oracle.com Mon Nov 28 16:06:12 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 17:06:12 +0100 Subject: RFR: JDK-8166737: default langtools make test settings result in no ouput Message-ID: The various test/Makefile in the forest do no all behave the same. The langtools/test/Makefile in particular has a different default verbosity setting compared to the rest. When running tests for the whole forest for CI, it would be more convenient if the verbosity was coherent. The other repositories sets the Jtreg verbosity to fail,error,time so I suggest we change langtools to match that. This will make running langtools tests through the makefile a lot noisier than today. Bug: https://bugs.openjdk.java.net/browse/JDK-8166737 Patch: diff -r 3dc39a1ffca4 test/Makefile --- a/test/Makefile +++ b/test/Makefile @@ -211,7 +211,7 @@ endif # Default verbosity setting for jtreg -JTREG_VERBOSE ?= fail,error,nopass +JTREG_VERBOSE ?= fail,error,time # Default verbosity setting for jck JCK_VERBOSE ?= non-pass /Erik From gromero at linux.vnet.ibm.com Mon Nov 28 16:28:00 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 28 Nov 2016 14:28:00 -0200 Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation Message-ID: <583C5B10.8040204@linux.vnet.ibm.com> Hi all, I'm re-sending due to JDK title update to include s390x and aarch64 archs. Could the following webrev be reviewed, please? webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ bug: https://bugs.openjdk.java.net/browse/JDK-8170153 Thank you. Regards, Gustavo From tim.bell at oracle.com Mon Nov 28 16:36:39 2016 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 28 Nov 2016 08:36:39 -0800 Subject: RFR: JDK-8166737: default langtools make test settings result in no ouput In-Reply-To: References: Message-ID: <57f81f0b-47a0-823b-8315-628eff4b3a48@oracle.com> Erik: > The various test/Makefile in the forest do no all behave the same. The > langtools/test/Makefile in particular has a different default verbosity > setting compared to the rest. When running tests for the whole forest > for CI, it would be more convenient if the verbosity was coherent. > > The other repositories sets the Jtreg verbosity to fail,error,time so I > suggest we change langtools to match that. This will make running > langtools tests through the makefile a lot noisier than today. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8166737 > > Patch: > > diff -r 3dc39a1ffca4 test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -211,7 +211,7 @@ > endif > > # Default verbosity setting for jtreg > -JTREG_VERBOSE ?= fail,error,nopass > +JTREG_VERBOSE ?= fail,error,time > > # Default verbosity setting for jck > JCK_VERBOSE ?= non-pass Looks good to me. Tim From erik.joelsson at oracle.com Mon Nov 28 16:55:00 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 28 Nov 2016 17:55:00 +0100 Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583C5B10.8040204@linux.vnet.ibm.com> References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: <1b332dd2-aa9f-e24b-faaf-b95eacd11dac@oracle.com> Looks good. /Erik On 2016-11-28 17:28, Gustavo Romero wrote: > Hi all, > > I'm re-sending due to JDK title update to include s390x and aarch64 archs. > > Could the following webrev be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > Thank you. > > > Regards, > Gustavo > From mandy.chung at oracle.com Tue Nov 29 01:03:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Nov 2016 17:03:24 -0800 Subject: Review Request: JDK-8170424 install build is broken due to the new location of src.zip Message-ID: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170424/webrev.00/ This back out the src.zip change in JDK-8169816 to give time to update the installer properly. Mandy From philip.race at oracle.com Tue Nov 29 01:23:33 2016 From: philip.race at oracle.com (Philip Race) Date: Mon, 28 Nov 2016 17:23:33 -0800 Subject: Review Request: JDK-8170424 install build is broken due to the new location of src.zip In-Reply-To: References: Message-ID: <583CD895.5010402@oracle.com> +1 -phil. On 11/28/16, 5:03 PM, Mandy Chung wrote: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170424/webrev.00/ > > This back out the src.zip change in JDK-8169816 to give time to update the installer properly. > > Mandy From volker.simonis at gmail.com Tue Nov 29 09:41:10 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Nov 2016 10:41:10 +0100 Subject: RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583C5B10.8040204@linux.vnet.ibm.com> References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: Thanks Gustavo, the change looks good. So now we're just waiting for another review from somebody of the aarch64 folks. Once we have that and the fc-request is approved I'll push the changes. Regards, Volker On Mon, Nov 28, 2016 at 5:28 PM, Gustavo Romero wrote: > Hi all, > > I'm re-sending due to JDK title update to include s390x and aarch64 archs. > > Could the following webrev be reviewed, please? > > webrev 1/2: http://cr.openjdk.java.net/~gromero/8170153/v2/ > webrev 2/2: http://cr.openjdk.java.net/~gromero/8170153/v2/jdk/ > bug: https://bugs.openjdk.java.net/browse/JDK-8170153 > > Thank you. > > > Regards, > Gustavo > From aph at redhat.com Tue Nov 29 15:35:16 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Nov 2016 15:35:16 +0000 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: On 29/11/16 09:41, Volker Simonis wrote: > Thanks Gustavo, > > the change looks good. > > So now we're just waiting for another review from somebody of the aarch64 folks. > Once we have that and the fc-request is approved I'll push the changes. One thing I don't understand: cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s Do you know what causes the lower digits to be different? Is it that Math and StrictMath use different algorithms, not just different optimization levels? Andrew. From gromero at linux.vnet.ibm.com Tue Nov 29 16:31:58 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 29 Nov 2016 14:31:58 -0200 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583C5B10.8040204@linux.vnet.ibm.com> Message-ID: <583DAD7E.7020807@linux.vnet.ibm.com> Hi Andrew, On 29-11-2016 13:35, Andrew Haley wrote: > On 29/11/16 09:41, Volker Simonis wrote: >> Thanks Gustavo, >> >> the change looks good. >> >> So now we're just waiting for another review from somebody of the aarch64 folks. >> Once we have that and the fc-request is approved I'll push the changes. > > One thing I don't understand: > > cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s > sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s > > Do you know what causes the lower digits to be different? Is > it that Math and StrictMath use different algorithms, not just > different optimization levels? I don't know exactly what's the root cause for that difference (in the result). The difference is not present on x64, however on PPC64 even with -O0 (as it is by now) that difference exists. Math methods are intrisified, but StricMath are not. But I understand that Math and StrictMath share the fdlibm code since I already changed some code in fdlibm that reflected both on Math and StrictMath, so it's not clear to me where the Math relaxation occurs on PPC64 (given that such a relaxation is allowed [1]). For sure others much more experienced than I can comment about difference. Regards, Gustavo [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html From volker.simonis at gmail.com Tue Nov 29 18:06:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 29 Nov 2016 19:06:05 +0100 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <583DAD7E.7020807@linux.vnet.ibm.com> References: <583C5B10.8040204@linux.vnet.ibm.com> <583DAD7E.7020807@linux.vnet.ibm.com> Message-ID: On Tue, Nov 29, 2016 at 5:31 PM, Gustavo Romero wrote: > Hi Andrew, > > On 29-11-2016 13:35, Andrew Haley wrote: >> On 29/11/16 09:41, Volker Simonis wrote: >>> Thanks Gustavo, >>> >>> the change looks good. >>> >>> So now we're just waiting for another review from somebody of the aarch64 folks. >>> Once we have that and the fc-request is approved I'll push the changes. >> >> One thing I don't understand: >> >> cos 0.17098435541865692 1m7.433s 0.1709843554185943 0m56.678s >> sin 1.7136493465700289 1m10.654s 1.7136493465700542 0m57.114s >> >> Do you know what causes the lower digits to be different? Is >> it that Math and StrictMath use different algorithms, not just >> different optimization levels? > > I don't know exactly what's the root cause for that difference (in the result). > The difference is not present on x64, however on PPC64 even with -O0 (as it is > by now) that difference exists. > > Math methods are intrisified, but StricMath are not. But I understand that Math > and StrictMath share the fdlibm code since I already changed some code in fdlibm > that reflected both on Math and StrictMath, so it's not clear to me where the > Math relaxation occurs on PPC64 (given that such a relaxation is allowed [1]). > I think the difference is because Math functions can be intrinsified (and optimized) while StricMath functions can not. HotSpot has different ways of intrinsifying the Math functions. If the CPU is supporting the corresponding function the VM generates special nodes for that. Otherwise, if there exist special optimized assembler stubs for a function (e.g. see "StubRoutines::_dsin = generate_libmSin()" in stubGenerator_x86_64.cpp) the VM makes use of them. Otherwise it still uses leaf-calls into HotSpots internal C++-Implementation of the functions (e.g. SharedRuntime::dsin() in sharedRuntimeTrig.cpp) which are faster than doing a native call into the fdlibm version. The implementation in SharedRuntime doesn't has to be "strict" so it probably uses fused multiplication and it is also build with full optimization without '-ffp-contract=off' (which is OK in this case). @Andrew: are you fine with Gustavos latest version of the change? > For sure others much more experienced than I can comment about difference. > > > Regards, > Gustavo > > [1] https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html > From aph at redhat.com Tue Nov 29 18:15:09 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Nov 2016 18:15:09 +0000 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: References: <583C5B10.8040204@linux.vnet.ibm.com> <583DAD7E.7020807@linux.vnet.ibm.com> Message-ID: <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com> On 29/11/16 18:06, Volker Simonis wrote: > @Andrew: are you fine with Gustavos latest version of the change? Sure. The StrictMath versions all seem to give the same results. Andrew. From gromero at linux.vnet.ibm.com Tue Nov 29 18:37:01 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 29 Nov 2016 16:37:01 -0200 Subject: [aarch64-port-dev ] RFR(s) PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation In-Reply-To: <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com> References: <583C5B10.8040204@linux.vnet.ibm.com> <583DAD7E.7020807@linux.vnet.ibm.com> <3c3aa7f0-01c7-46ae-ce8d-414d43213e4a@redhat.com> Message-ID: <583DCACD.3090803@linux.vnet.ibm.com> Hi Erik, Volker, Andrew On 29-11-2016 16:15, Andrew Haley wrote: > On 29/11/16 18:06, Volker Simonis wrote: >> @Andrew: are you fine with Gustavos latest version of the change? > > Sure. The StrictMath versions all seem to give the same results. > > Andrew. > Thanks for reviewing the change! I changed the "FC Extension Request" status to "reviewed". Regards, Gustavo From kumar.x.srinivasan at oracle.com Wed Nov 30 05:18:42 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 29 Nov 2016 21:18:42 -0800 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> Message-ID: <583E6132.7090103@oracle.com> Hi Volker et. al., Was a bug opened to track this ? I still see these files around http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli Would you like me to create a bug for you ? Thanks Kumar On 9/29/2016 9:59 AM, Volker Simonis wrote: > On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson wrote: >> >> On 2016-09-29 16:54, Alan Burlison wrote: >>> On 29/09/2016 08:03, Volker Simonis wrote: >>> >>>> Sorry, but that doesn't sound like a solution to me at all. I think we >>>> should keep the OpenJDK sources self-contained. I don't want to depend >>>> on yet another non-standard, third party library which doesn't even >>>> exist now. >>> >>> Unless I'm completely misunderstanding, that's not what is being proposed. >>> What is being proposed is refactoring code that's currently duplicated >>> across the JVM & JDK into a common library. Such a library would be a >>> standard Java component, not non-standard and not third-party. I can't see >>> what the problem is, to be honest. >>> >> Volker's comment above was directed at the suggestion of taking the >> problematic AIX specific code out of the OpenJDK repositories and create a >> separate library with a separate lifecycle somewhere else that OpenJDK for >> AIX would then need to depend on. Volker was instead proposing what you >> describe. >> > Thanks Erik, this is exactly what I meant :) > > And I think the solution you ssketched in your previous mail is the > right way to address this problem. > > Regards, > Volker > > >> /Erik From erik.joelsson at oracle.com Wed Nov 30 11:17:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Nov 2016 12:17:46 +0100 Subject: RFR: JDK-8170528: Race condition with release file creation Message-ID: <4595fb1b-eb7f-3167-85b6-dfc0290f6a39@oracle.com> The release file is part of all product images in the build. We used to generate it for each image individually, but a while back, we changed to generate it just for the exploded image, and then let jlink use the one as source for generating individually modified release files for each linked image. The problem is that the release file is still generated in Images.gmk, which is called multiple times. This means each call to this file may try to generate the release file at the same time, which may result in a corrupt release file. This patch moves the creation of the base release file to a separate build step. Bug: https://bugs.openjdk.java.net/browse/JDK-8170528 Webrev: http://cr.openjdk.java.net/~erikj/8170528/webrev.01 /Erik From david.holmes at oracle.com Wed Nov 30 12:26:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2016 22:26:52 +1000 Subject: RFR: JDK-8170528: Race condition with release file creation In-Reply-To: <4595fb1b-eb7f-3167-85b6-dfc0290f6a39@oracle.com> References: <4595fb1b-eb7f-3167-85b6-dfc0290f6a39@oracle.com> Message-ID: Hi Erik, Seems reasonable. Only query I have is defining BASE_RELEASE_FILE in two places ? Thanks, David On 30/11/2016 9:17 PM, Erik Joelsson wrote: > The release file is part of all product images in the build. We used to > generate it for each image individually, but a while back, we changed to > generate it just for the exploded image, and then let jlink use the one > as source for generating individually modified release files for each > linked image. > > The problem is that the release file is still generated in Images.gmk, > which is called multiple times. This means each call to this file may > try to generate the release file at the same time, which may result in a > corrupt release file. > > This patch moves the creation of the base release file to a separate > build step. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170528 > > Webrev: http://cr.openjdk.java.net/~erikj/8170528/webrev.01 > > /Erik > From magnus.ihse.bursie at oracle.com Wed Nov 30 12:36:22 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 30 Nov 2016 13:36:22 +0100 Subject: RFR: JDK-8170528: Race condition with release file creation In-Reply-To: References: <4595fb1b-eb7f-3167-85b6-dfc0290f6a39@oracle.com> Message-ID: <9d653f34-ccf0-be32-b758-e45bf6e30eec@oracle.com> On 2016-11-30 13:26, David Holmes wrote: > Hi Erik, > > Seems reasonable. Only query I have is defining BASE_RELEASE_FILE in > two places ? I reacted to that as well. Otoh, I really don't know where to define it otherwise. MakeBase.gmk, perhaps? I guess we could consider it to be a "well-known name" and assume that it is ok to define references to it locally in multiple places. Otherwise it looks good to me. /Magnus > > Thanks, > David > > On 30/11/2016 9:17 PM, Erik Joelsson wrote: >> The release file is part of all product images in the build. We used to >> generate it for each image individually, but a while back, we changed to >> generate it just for the exploded image, and then let jlink use the one >> as source for generating individually modified release files for each >> linked image. >> >> The problem is that the release file is still generated in Images.gmk, >> which is called multiple times. This means each call to this file may >> try to generate the release file at the same time, which may result in a >> corrupt release file. >> >> This patch moves the creation of the base release file to a separate >> build step. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170528 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170528/webrev.01 >> >> /Erik >> From erik.joelsson at oracle.com Wed Nov 30 12:45:35 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Nov 2016 13:45:35 +0100 Subject: RFR: JDK-8170528: Race condition with release file creation In-Reply-To: References: <4595fb1b-eb7f-3167-85b6-dfc0290f6a39@oracle.com> Message-ID: Hello, Thanks! Yes, the redefinition is a (minor) reason for concern. I just had a discussion with Magnus about it. In some cases I would have moved the definition to spec.gmk.in, which really is the only place to put common definitions. In this case I chose not to because the file is located in a rather well defined place (top of the exploded image which is where it would logically go) so it's far from arbitrary. I guess this sticks out because the same variable name is used in both makefiles. /Erik On 2016-11-30 13:26, David Holmes wrote: > Hi Erik, > > Seems reasonable. Only query I have is defining BASE_RELEASE_FILE in > two places ? > > Thanks, > David > > On 30/11/2016 9:17 PM, Erik Joelsson wrote: >> The release file is part of all product images in the build. We used to >> generate it for each image individually, but a while back, we changed to >> generate it just for the exploded image, and then let jlink use the one >> as source for generating individually modified release files for each >> linked image. >> >> The problem is that the release file is still generated in Images.gmk, >> which is called multiple times. This means each call to this file may >> try to generate the release file at the same time, which may result in a >> corrupt release file. >> >> This patch moves the creation of the base release file to a separate >> build step. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170528 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8170528/webrev.01 >> >> /Erik >> From erik.joelsson at oracle.com Wed Nov 30 14:18:51 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Nov 2016 15:18:51 +0100 Subject: RFR: JDK-8168924: Add jdk.unsupported to the compact profile builds Message-ID: This patch adds the jdk.unsupported module to the compact profile images. Bug: https://bugs.openjdk.java.net/browse/JDK-8168924 Patch: diff -r 2ba99326da3d make/Images.gmk --- a/make/Images.gmk +++ b/make/Images.gmk @@ -48,7 +48,8 @@ JDK_MODULES += $(ALL_MODULES) # Compact builds have additional modules -COMPACT1_EXTRA_MODULES := jdk.localedata jdk.crypto.pkcs11 jdk.crypto.ec +COMPACT1_EXTRA_MODULES := jdk.localedata jdk.crypto.pkcs11 jdk.crypto.ec \ + jdk.unsupported COMPACT2_EXTRA_MODULES := jdk.xml.dom jdk.httpserver COMPACT3_EXTRA_MODULES := java.smartcardio jdk.management \ jdk.naming.dns jdk.naming.rmi jdk.sctp jdk.security.auth /Erik From chris.hegarty at oracle.com Wed Nov 30 14:21:03 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 30 Nov 2016 14:21:03 +0000 Subject: RFR: JDK-8168924: Add jdk.unsupported to the compact profile builds In-Reply-To: References: Message-ID: <2ac564f6-705d-bf9f-5d9f-255273346c29@oracle.com> Looks good to me Erik. -Chris. On 30/11/16 14:18, Erik Joelsson wrote: > This patch adds the jdk.unsupported module to the compact profile images. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168924 > > Patch: > > diff -r 2ba99326da3d make/Images.gmk > --- a/make/Images.gmk > +++ b/make/Images.gmk > @@ -48,7 +48,8 @@ > JDK_MODULES += $(ALL_MODULES) > > # Compact builds have additional modules > -COMPACT1_EXTRA_MODULES := jdk.localedata jdk.crypto.pkcs11 jdk.crypto.ec > +COMPACT1_EXTRA_MODULES := jdk.localedata jdk.crypto.pkcs11 jdk.crypto.ec \ > + jdk.unsupported > COMPACT2_EXTRA_MODULES := jdk.xml.dom jdk.httpserver > COMPACT3_EXTRA_MODULES := java.smartcardio jdk.management \ > jdk.naming.dns jdk.naming.rmi jdk.sctp jdk.security.auth > > > /Erik > From erik.joelsson at oracle.com Wed Nov 30 14:30:32 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Nov 2016 15:30:32 +0100 Subject: RFR: JDK-8168607: langtools/test/Makefile should set -retain:fail,error by default Message-ID: <432cecad-691a-f3d0-b6b3-ef54df6a779b@oracle.com> This patch moves the langtools/test/Makefile one step closer being alignmened with the rest of the test/*/Makefiles by adding the -retain:fail,error jtreg option. Bug: https://bugs.openjdk.java.net/browse/JDK-8168607 Patch: diff -r ab39653a1e6d test/Makefile --- a/test/Makefile +++ b/test/Makefile @@ -161,6 +161,9 @@ JTREG_TESTVM_MEMORY_OPTION = -vmoption:-Xmx768m JTREG_OPTIONS += $(JTREG_TESTVM_MEMORY_OPTION) +# Retain all files for failing tests +JTREG_OPTIONS += -retain:fail,error + ifdef EXTRA_JTREG_OPTIONS JTREG_OPTIONS += $(EXTRA_JTREG_OPTIONS) endif /Erik From Alan.Bateman at oracle.com Wed Nov 30 14:53:04 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Nov 2016 14:53:04 +0000 Subject: RFR: JDK-8168924: Add jdk.unsupported to the compact profile builds In-Reply-To: References: Message-ID: <3b50cc7b-576e-82fc-4fcb-a0321e39cae1@oracle.com> On 30/11/2016 14:18, Erik Joelsson wrote: > This patch adds the jdk.unsupported module to the compact profile images. > Looks fine. From volker.simonis at gmail.com Wed Nov 30 15:21:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 30 Nov 2016 16:21:41 +0100 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: <583E6132.7090103@oracle.com> References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> <583E6132.7090103@oracle.com> Message-ID: On Wed, Nov 30, 2016 at 6:18 AM, Kumar Srinivasan wrote: > Hi Volker et. al., > > Was a bug opened to track this ? I still see these files around > http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli > Hi Kumar, no, as far as I know there's no bug for this issue until now. The current situation is not ideal, but it works and it doesn't impact any other platform except AIX. So there's no reason for us to address this with high priority and surely not within the jdk9 time frame. I think ideally, this could be addressed the next time we see a similar problem, otherwise it is probably always too much at the bottom of the priority list :) Thank you and best regards, Volker > Would you like me to create a bug for you ? > > Thanks > Kumar > > > On 9/29/2016 9:59 AM, Volker Simonis wrote: >> >> On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson >> wrote: >>> >>> >>> On 2016-09-29 16:54, Alan Burlison wrote: >>>> >>>> On 29/09/2016 08:03, Volker Simonis wrote: >>>> >>>>> Sorry, but that doesn't sound like a solution to me at all. I think we >>>>> should keep the OpenJDK sources self-contained. I don't want to depend >>>>> on yet another non-standard, third party library which doesn't even >>>>> exist now. >>>> >>>> >>>> Unless I'm completely misunderstanding, that's not what is being >>>> proposed. >>>> What is being proposed is refactoring code that's currently duplicated >>>> across the JVM & JDK into a common library. Such a library would be a >>>> standard Java component, not non-standard and not third-party. I can't >>>> see >>>> what the problem is, to be honest. >>>> >>> Volker's comment above was directed at the suggestion of taking the >>> problematic AIX specific code out of the OpenJDK repositories and create >>> a >>> separate library with a separate lifecycle somewhere else that OpenJDK >>> for >>> AIX would then need to depend on. Volker was instead proposing what you >>> describe. >>> >> Thanks Erik, this is exactly what I meant :) >> >> And I think the solution you ssketched in your previous mail is the >> right way to address this problem. >> >> Regards, >> Volker >> >> >>> /Erik > > From tim.bell at oracle.com Wed Nov 30 15:25:08 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 30 Nov 2016 07:25:08 -0800 Subject: RFR: JDK-8168607: langtools/test/Makefile should set -retain:fail,error by default In-Reply-To: <432cecad-691a-f3d0-b6b3-ef54df6a779b@oracle.com> References: <432cecad-691a-f3d0-b6b3-ef54df6a779b@oracle.com> Message-ID: Erik: > This patch moves the langtools/test/Makefile one step closer being > alignmened with the rest of the test/*/Makefiles by adding the > -retain:fail,error jtreg option. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168607 > > Patch: > > diff -r ab39653a1e6d test/Makefile > --- a/test/Makefile > +++ b/test/Makefile > @@ -161,6 +161,9 @@ > JTREG_TESTVM_MEMORY_OPTION = -vmoption:-Xmx768m > JTREG_OPTIONS += $(JTREG_TESTVM_MEMORY_OPTION) > > +# Retain all files for failing tests > +JTREG_OPTIONS += -retain:fail,error > + > ifdef EXTRA_JTREG_OPTIONS > JTREG_OPTIONS += $(EXTRA_JTREG_OPTIONS) > endif Thank you, Erik. Looks good. Tim From tim.bell at oracle.com Wed Nov 30 15:28:52 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 30 Nov 2016 07:28:52 -0800 Subject: RFR: JDK-8170528: Race condition with release file creation In-Reply-To: References: <4595fb1b-eb7f-3167-85b6-dfc0290f6a39@oracle.com> Message-ID: <0b3246aa-055e-241e-1d10-0e59a39b9384@oracle.com> Erik: Looks good to me as well. Tim > Hello, > > Thanks! > > Yes, the redefinition is a (minor) reason for concern. I just had a > discussion with Magnus about it. In some cases I would have moved the > definition to spec.gmk.in, which really is the only place to put common > definitions. In this case I chose not to because the file is located in > a rather well defined place (top of the exploded image which is where it > would logically go) so it's far from arbitrary. I guess this sticks out > because the same variable name is used in both makefiles. > > /Erik > > > On 2016-11-30 13:26, David Holmes wrote: >> Hi Erik, >> >> Seems reasonable. Only query I have is defining BASE_RELEASE_FILE in >> two places ? >> >> Thanks, >> David >> >> On 30/11/2016 9:17 PM, Erik Joelsson wrote: >>> The release file is part of all product images in the build. We used to >>> generate it for each image individually, but a while back, we changed to >>> generate it just for the exploded image, and then let jlink use the one >>> as source for generating individually modified release files for each >>> linked image. >>> >>> The problem is that the release file is still generated in Images.gmk, >>> which is called multiple times. This means each call to this file may >>> try to generate the release file at the same time, which may result in a >>> corrupt release file. >>> >>> This patch moves the creation of the base release file to a separate >>> build step. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170528 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8170528/webrev.01 >>> >>> /Erik >>> > From erik.joelsson at oracle.com Wed Nov 30 16:14:52 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 Nov 2016 17:14:52 +0100 Subject: RFR: JDK-8164304: JDK should build with Oracle Developer Studio Message-ID: This patch slightly adjusts the matching pattern which identifies the C/C++ compilers as Solaris Studio/Oracle Developer Studio so that the new output of 12.5 is also matched. Note that this only makes configure accept the new version as a valid compiler. The build dies almost immediately due to compilation errors. Bug: https://bugs.openjdk.java.net/browse/JDK-8164304 Patch: diff -r 059a089b973d common/autoconf/toolchain.m4 --- a/common/autoconf/toolchain.m4 Wed Nov 30 19:28:45 2016 +0530 +++ b/common/autoconf/toolchain.m4 Wed Nov 30 17:04:40 2016 +0100 @@ -333,9 +333,11 @@ if test "x$TOOLCHAIN_TYPE" = xsolstudio; then # cc -V output typically looks like # cc: Sun C 5.12 Linux_i386 2011/11/16 + # or + # cc: Studio 12.5 Sun C 5.14 SunOS_sparc 2016/05/31 COMPILER_VERSION_OUTPUT=`$COMPILER -V 2>&1` # Check that this is likely to be the Solaris Studio cc. - $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "^.*: Sun $COMPILER_NAME" > /dev/null + $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "^.* Sun $COMPILER_NAME" > /dev/null if test $? -ne 0; then ALT_VERSION_OUTPUT=`$COMPILER --version 2>&1` AC_MSG_NOTICE([The $COMPILER_NAME compiler (located as $COMPILER) does not seem to be the required $TOOLCHAIN_TYPE compiler.]) /Erik From mandy.chung at oracle.com Wed Nov 30 17:06:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 30 Nov 2016 09:06:03 -0800 Subject: RFR: JDK-8168924: Add jdk.unsupported to the compact profile builds In-Reply-To: References: Message-ID: +1 Mandy > On Nov 30, 2016, at 6:18 AM, Erik Joelsson wrote: > > This patch adds the jdk.unsupported module to the compact profile images. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168924 > > Patch: > > diff -r 2ba99326da3d make/Images.gmk > --- a/make/Images.gmk > +++ b/make/Images.gmk > @@ -48,7 +48,8 @@ > JDK_MODULES += $(ALL_MODULES) > > # Compact builds have additional modules > -COMPACT1_EXTRA_MODULES := jdk.localedata jdk.crypto.pkcs11 jdk.crypto.ec > +COMPACT1_EXTRA_MODULES := jdk.localedata jdk.crypto.pkcs11 jdk.crypto.ec \ > + jdk.unsupported > COMPACT2_EXTRA_MODULES := jdk.xml.dom jdk.httpserver > COMPACT3_EXTRA_MODULES := java.smartcardio jdk.management \ > jdk.naming.dns jdk.naming.rmi jdk.sctp jdk.security.auth > > > /Erik > From tim.bell at oracle.com Wed Nov 30 18:00:20 2016 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 30 Nov 2016 10:00:20 -0800 Subject: RFR: JDK-8164304: JDK should build with Oracle Developer Studio In-Reply-To: References: Message-ID: <866b51b1-fa04-2b60-c272-7c8aed3ed196@oracle.com> On 11/30/16 08:14, Erik Joelsson wrote: > This patch slightly adjusts the matching pattern which identifies the > C/C++ compilers as Solaris Studio/Oracle Developer Studio so that the > new output of 12.5 is also matched. Note that this only makes configure > accept the new version as a valid compiler. The build dies almost > immediately due to compilation errors. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164304 > > Patch: > > diff -r 059a089b973d common/autoconf/toolchain.m4 > --- a/common/autoconf/toolchain.m4 Wed Nov 30 19:28:45 2016 +0530 > +++ b/common/autoconf/toolchain.m4 Wed Nov 30 17:04:40 2016 +0100 > @@ -333,9 +333,11 @@ > if test "x$TOOLCHAIN_TYPE" = xsolstudio; then > # cc -V output typically looks like > # cc: Sun C 5.12 Linux_i386 2011/11/16 > + # or > + # cc: Studio 12.5 Sun C 5.14 SunOS_sparc 2016/05/31 > COMPILER_VERSION_OUTPUT=`$COMPILER -V 2>&1` > # Check that this is likely to be the Solaris Studio cc. > - $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "^.*: Sun $COMPILER_NAME" >> /dev/null > + $ECHO "$COMPILER_VERSION_OUTPUT" | $GREP "^.* Sun $COMPILER_NAME" > > /dev/null > if test $? -ne 0; then > ALT_VERSION_OUTPUT=`$COMPILER --version 2>&1` > AC_MSG_NOTICE([The $COMPILER_NAME compiler (located as $COMPILER) > does not seem to be the required $TOOLCHAIN_TYPE compiler.]) Looks good to me. /Tim From stanislav.smirnov at oracle.com Wed Nov 30 11:09:37 2016 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Wed, 30 Nov 2016 14:09:37 +0300 Subject: RFR(XXS): JDK-8170530: bash configure output contains a typo in a suggested library name Message-ID: <284C22BC-535B-444F-8153-55EECA80D2B8@oracle.com> Hi, please review this minor fix of a typo I have noticed in "bash configure? output when required X11 libraries are missing. JBS: https://bugs.openjdk.java.net/browse/JDK-8170530 webrev: http://cr.openjdk.java.net/~stsmirno/8170530/webrev.00 And I also need a sponsor for this change. Best regards, Stanislav Smirnov