From glaubitz at physik.fu-berlin.de Sun Sep 3 12:37:27 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sun, 3 Sep 2017 14:37:27 +0200 Subject: [RFR]: 8186786: Name collisions with autoconf definitions on alpha and sh In-Reply-To: References: <789316d4-ad47-1cab-7b65-13e1a4d0b5b7@physik.fu-berlin.de> Message-ID: <4babee7c-e00e-1539-9851-e001ce06b930@physik.fu-berlin.de> Hi Magnus! On 08/31/2017 03:44 PM, Magnus Ihse Bursie wrote: >> Updated webrev in [1]. Removed the quotes around alpha and sh in >> the comments to make it more consistent with the rest of the comments. > > Looks good to me. > > I'll sponsor the patch for you, and regenerate the generated-configure.sh. This was merged in the jdk10/jdk10 tree [1] but not in the jdk10/hs tree [2] which I am using for development. Any chance this gets merged back into [2]? Adrian > [1] http://hg.openjdk.java.net/jdk10/jdk10/ > [2] http://hg.openjdk.java.net/jdk10/hs/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sun Sep 3 21:39:01 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Sep 2017 07:39:01 +1000 Subject: [RFR]: 8186786: Name collisions with autoconf definitions on alpha and sh In-Reply-To: <4babee7c-e00e-1539-9851-e001ce06b930@physik.fu-berlin.de> References: <789316d4-ad47-1cab-7b65-13e1a4d0b5b7@physik.fu-berlin.de> <4babee7c-e00e-1539-9851-e001ce06b930@physik.fu-berlin.de> Message-ID: <9350b4f5-d1d2-4c4b-8347-07e98aad546d@oracle.com> On 3/09/2017 10:37 PM, John Paul Adrian Glaubitz wrote: > Hi Magnus! > > On 08/31/2017 03:44 PM, Magnus Ihse Bursie wrote: >>> Updated webrev in [1]. Removed the quotes around alpha and sh in >>> the comments to make it more consistent with the rest of the comments. >> >> Looks good to me. >> >> I'll sponsor the patch for you, and regenerate the generated-configure.sh. > > This was merged in the jdk10/jdk10 tree [1] but not in the jdk10/hs tree [2] > which I am using for development. Any chance this gets merged back into [2]? It would normally happen every couple of days, but given the repo state due to consolidation I don't know if/when this will now happen. [1] You may as well just import the changeset to your local hs forest as once consolidation is done you will need to re-clone the new repo and start over with any patches in progress. [2] David [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028194.html [2] http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000455.html > Adrian > >> [1] http://hg.openjdk.java.net/jdk10/jdk10/ >> [2] http://hg.openjdk.java.net/jdk10/hs/ > From david.holmes at oracle.com Sun Sep 3 21:40:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Sep 2017 07:40:46 +1000 Subject: [RFR]: 8186786: Name collisions with autoconf definitions on alpha and sh In-Reply-To: <9350b4f5-d1d2-4c4b-8347-07e98aad546d@oracle.com> References: <789316d4-ad47-1cab-7b65-13e1a4d0b5b7@physik.fu-berlin.de> <4babee7c-e00e-1539-9851-e001ce06b930@physik.fu-berlin.de> <9350b4f5-d1d2-4c4b-8347-07e98aad546d@oracle.com> Message-ID: <634b86ed-0bdd-b1b2-fc8a-14646f1b8c38@oracle.com> Never mind the sync down has already happened. David On 4/09/2017 7:39 AM, David Holmes wrote: > On 3/09/2017 10:37 PM, John Paul Adrian Glaubitz wrote: >> Hi Magnus! >> >> On 08/31/2017 03:44 PM, Magnus Ihse Bursie wrote: >>>> Updated webrev in [1]. Removed the quotes around alpha and sh in >>>> the comments to make it more consistent with the rest of the comments. >>> >>> Looks good to me. >>> >>> I'll sponsor the patch for you, and regenerate the >>> generated-configure.sh. >> >> This was merged in the jdk10/jdk10 tree [1] but not in the jdk10/hs >> tree [2] >> which I am using for development. Any chance this gets merged back >> into [2]? > > It would normally happen every couple of days, but given the repo state > due to consolidation I don't know if/when this will now happen. [1] You > may as well just import the changeset to your local hs forest as once > consolidation is done you will need to re-clone the new repo and start > over with any patches in progress. [2] > > David > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028194.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000455.html > >> Adrian >> >>> [1] http://hg.openjdk.java.net/jdk10/jdk10/ >>> [2] http://hg.openjdk.java.net/jdk10/hs/ >> From magnus.ihse.bursie at oracle.com Mon Sep 4 08:42:27 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Sep 2017 10:42:27 +0200 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: References: Message-ID: <0dbf4e19-988c-3257-58df-474a51373ed4@oracle.com> Hi Goetz, Since this is mostly a build change, it need to be reviewed on build-dev. However, it looks good to me from a build perspective. I have not reviewed the hotspot test files. /Magnus On 2017-09-01 15:05, Lindenmaier, Goetz wrote: > Hi, > > I found that not all libraries are linked with -z,noexecstack. > This lead to errors with our linuxppc64 build. The linker omitted > the flag altogether, which is interpreted as a lib with execstack. > > This change contains a small test that scans all libraries in the tested VM > to have the noexecstack flag set. It utilizes the elf parser in the VM for this. > Further -z,noexecstack is now passed to all libraries. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.01/ > http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.01-hs/ > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Mon Sep 4 09:47:19 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Sep 2017 09:47:19 +0000 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: <0dbf4e19-988c-3257-58df-474a51373ed4@oracle.com> References: <0dbf4e19-988c-3257-58df-474a51373ed4@oracle.com> Message-ID: <07c3435bc97e4119a0a358a0bfc81fe9@sap.com> Hi Magnus, thanks for looking at my change. Thanks for forwarding to the proper list. I'm often not sure what's the right one, and sometimes it's ambiguous anyways. Like this one, which concerns stack overflow handling. The same problem exists with all the categories of the Jira bugs. Best regards, Goetz. > -----Original Message----- > From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > Sent: Montag, 4. September 2017 10:42 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; build-dev > Subject: Re: RFR(M): 8187045: [linux] Not all libraries in the VM are linked > with -z,noexecstack > > Hi Goetz, > > Since this is mostly a build change, it need to be reviewed on build-dev. > > However, it looks good to me from a build perspective. I have not > reviewed the hotspot test files. > > /Magnus > > On 2017-09-01 15:05, Lindenmaier, Goetz wrote: > > Hi, > > > > I found that not all libraries are linked with -z,noexecstack. > > This lead to errors with our linuxppc64 build. The linker omitted > > the flag altogether, which is interpreted as a lib with execstack. > > > > This change contains a small test that scans all libraries in the tested VM > > to have the noexecstack flag set. It utilizes the elf parser in the VM for this. > > Further -z,noexecstack is now passed to all libraries. > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr17/8187045- > execstackLink/webrev.01/ > > http://cr.openjdk.java.net/~goetz/wr17/8187045- > execstackLink/webrev.01-hs/ > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Mon Sep 4 09:51:40 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 4 Sep 2017 09:51:40 +0000 Subject: RFR(M): 8186978: Introduce configure argument enable-cds In-Reply-To: References: <7cbe5b02e52e4a2e99512306d79800f3@sap.com> <08f05d7b-14fd-a51a-41e3-2c6d09201cd5@oracle.com> <0cf2865e-bfc0-826f-8c6f-350a70b87ba7@oracle.com> <0de4b0ee7c804280a29b76a6000f95e7@sap.com> Message-ID: <8cade291816042a2b5de899391b99bb3@sap.com> Hi David, thanks for sponsoring the change! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 31. August 2017 23:15 > To: Lindenmaier, Goetz ; 'Magnus Ihse Bursie' > ; hotspot-runtime- > dev at openjdk.java.net; build-dev (build-dev at openjdk.java.net) dev at openjdk.java.net> > Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds > > Hi Goetz, > > I will sponsor this. > > Thanks, > David > > On 1/09/2017 12:49 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > thanks for reviewing everybody! > > Yes, works fine without that assignment. New webrev: > > http://cr.openjdk.java.net/~goetz/wr17/8186978-disableCDS/webrev.02/ > > > > Could someone please sponsor? I think autogen.sh needs to be run > > before submitting. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > >> Sent: Thursday, August 31, 2017 3:35 PM > >> To: David Holmes ; Lindenmaier, Goetz > >> ; hotspot-runtime-dev at openjdk.java.net; > >> build-dev (build-dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8186978: Introduce configure argument enable-cds > >> > >> > >> > >> On 2017-08-31 14:47, David Holmes wrote: > >>> Hi Goetz, > >>> > >>> On 31/08/2017 10:29 PM, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> Tests for class data sharing (cds) are enabled if @requires vm.cds is > >>>> true. > >>>> The property vm.cds depends on the preprocessor macro > ENABLE_CDS. > >> ... but you mean INCLUDE_CDS. :-) > >> > >>>> This can not yet be switched by configure. It's only disabled > >>>> automatically > >>>> for the minimal build. > >>>> > >>>> This change introduces enable-cds with default true, which only takes > >>>> effect > >>>> in the non-minimal build. If disabled, generate-classlist is > >>>> disabled, too. > >>>> > >>>> Please review this change. I please need a sponsor. > >>>> http://cr.openjdk.java.net/~goetz/wr17/8186978- > >> disableCDS/webrev.01/index.html > >>>> > >>> > >>> I'll let the build guys comment in detail, but the structure for this > >>> doesn't quite look right to me. I don't understand why you have in > >>> spec.gmk.in: > >>> > >>> + ENABLE_CDS:=@ENABLE_CDS@ > >>> > >>> when in the hotspot build CDS is controlled via the feature setting: > >>> > >>> ifneq ($(call check-jvm-feature, cds), true) > >>> > >>> which you are already handling. ?? > >> > >> Agree, the ENABLE_CDS variable is only used internally in the configure > >> script and need not/should not be exported in spec.gmk.in. As David > >> says, the test ($(call check-jvm-feature, cds), true) is enough to > >> determine if to send the -DINCLUDE_CDS to the compiler. > >> > >> Just remove the changes to spec.gmk.in, and I'm ok with the patch. > >> > >> /Magnus > >> > >> > >>> > >>> Thanks, > >>> David > >>> > >>> > >>>> Best regards, > >>>> Goetz. > >>>> > > From magnus.ihse.bursie at oracle.com Mon Sep 4 09:58:51 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Sep 2017 11:58:51 +0200 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: <07c3435bc97e4119a0a358a0bfc81fe9@sap.com> References: <0dbf4e19-988c-3257-58df-474a51373ed4@oracle.com> <07c3435bc97e4119a0a358a0bfc81fe9@sap.com> Message-ID: On 2017-09-04 11:47, Lindenmaier, Goetz wrote: > Hi Magnus, > > thanks for looking at my change. > > Thanks for forwarding to the proper list. I'm often not sure what's the right one, > and sometimes it's ambiguous anyways. Like this one, which concerns stack overflow > handling. The same problem exists with all the categories of the Jira bugs. The rule of thumb is: Does the patch touch files in the make or autoconf directories? If so, cc build-dev. (For really trivial changes you can skip this, but then you must be *certain* that the change is trivial -- not always easy to say when dealing with makefiles) The good thing with mailing lists, as opposted to categories in Jira, is that you can cc multiple lists. /Magnus > > Best regards, > Goetz. > >> -----Original Message----- >> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >> Sent: Montag, 4. September 2017 10:42 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; build-dev >> Subject: Re: RFR(M): 8187045: [linux] Not all libraries in the VM are linked >> with -z,noexecstack >> >> Hi Goetz, >> >> Since this is mostly a build change, it need to be reviewed on build-dev. >> >> However, it looks good to me from a build perspective. I have not >> reviewed the hotspot test files. >> >> /Magnus >> >> On 2017-09-01 15:05, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> I found that not all libraries are linked with -z,noexecstack. >>> This lead to errors with our linuxppc64 build. The linker omitted >>> the flag altogether, which is interpreted as a lib with execstack. >>> >>> This change contains a small test that scans all libraries in the tested VM >>> to have the noexecstack flag set. It utilizes the elf parser in the VM for this. >>> Further -z,noexecstack is now passed to all libraries. >>> >>> Please review this change. I please need a sponsor. >>> http://cr.openjdk.java.net/~goetz/wr17/8187045- >> execstackLink/webrev.01/ >>> http://cr.openjdk.java.net/~goetz/wr17/8187045- >> execstackLink/webrev.01-hs/ >>> Best regards, >>> Goetz. From magnus.ihse.bursie at oracle.com Mon Sep 4 10:09:11 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Sep 2017 12:09:11 +0200 Subject: windows: sporadic configure errors in cygwin In-Reply-To: References: Message-ID: <877a2485-a9ed-9fcd-1594-cd71da3f1d3a@oracle.com> On 2017-08-11 13:00, Thomas St?fe wrote: > Hi all, > > when building OpenJDK 10/hs on Windows, I get sporadic configure errors. > Usually one of two things, either: > > configure: The tested number of bits in the target (0) differs from the > number of bits expected to be found in the target (32). > > or the endianness test failing. > > Most of the time, just retrying the configure run works. > > I have the feeling this happens mostly when running several builds in > parallel. I am currently using 32bit cygwin. You cannot/should not run multiple "configure" in parallel in the same directory. This is due to a limitation of the autoconf framework that we are using -- they test features (like word size) by creating a file in the current directory (conf.c I believe it's called), compiling and running it. So if you run multiple configure calls in parallel, these tests can interfere with each other. Once the configure step is done, you can build multiple configurations using "make" at the same time. /Magnus > > Does anyone see similar errors or maybe have a solution? > > Best Regards, Thomas From magnus.ihse.bursie at oracle.com Mon Sep 4 12:15:41 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Sep 2017 14:15:41 +0200 Subject: How to suppress verbosity when settting _JAVA_OPTIONS? In-Reply-To: <4f21fbf9-9802-6f39-e90c-fda58c09bf72@physik.fu-berlin.de> References: <4f21fbf9-9802-6f39-e90c-fda58c09bf72@physik.fu-berlin.de> Message-ID: On 2017-09-04 13:18, John Paul Adrian Glaubitz wrote: > Hello! > > I'm currently testing Zero builds on Linux Alpha, in my particular > case on > QEMU in a Debian unstable alpha chroot, using OpenJDK 8 for > bootstrapping. > > For some reason, OpenJDK 8 from Debian's openjdk8 assumes a heap size > which > is too small and refuses to start: > > (sid-alpha-sbuild)root at nofan:/# java -version > Error occurred during initialization of VM > Too small initial heap > (sid-alpha-sbuild)root at nofan:/# > > This can be fixed by overriding the heap settings with _JAVA_OPTIONS: > > (sid-alpha-sbuild)root at nofan:/# export _JAVA_OPTIONS="-Xmx1024m -Xms256m" > (sid-alpha-sbuild)root at nofan:/# java -version > Picked up _JAVA_OPTIONS: -Xmx1024m -Xms256m > openjdk version "1.8.0_141" > OpenJDK Runtime Environment (build 1.8.0_141-8u141-b15-3-b15) > OpenJDK 64-Bit Zero VM (build 25.141-b15, interpreted mode) > (sid-alpha-sbuild)root at nofan:/# > > As you can see, this has the side effect that the JVM becomes very > chatty about the fact that _JAVA_OPTIONS were set. > > While this doesn't seem to be a problem at first sight, it becomes > a problem when trying to run configure for JDK10 which will fail > because of the unexpected output when trying to determine the version > of the boot JDK: > > configure: Found potential Boot JDK using configure arguments > configure: Potential Boot JDK found at > /usr/lib/jvm/java-8-openjdk-alpha/ is incorrect JDK version (Picked up > _JAVA_OPTIONS: -Xmx1024m -Xms256m); ignoring > configure: (Your Boot JDK must be version 8 or 9) > configure: error: The path given by --with-boot-jdk does not contain a > valid Boot JDK > configure exiting with result code 1 > > Is there any way to silence the JVM regarding "_JAVA_OPTIONS"? If no, > we should probably patch the JVM to do that by default. Ouch! Lots of small, idiotic issues. For the build identification part: are both the _JAVA_OPTIONS and the version outputted to stdout? Or can you separate them by separating stdout/stderr? Otherwise, this patch would solve the issue in your case. I'm not sure how it would affect all other java instances we try to detect, so I'm a bit reluctant to take it in. diff --git a/common/autoconf/boot-jdk.m4 b/common/autoconf/boot-jdk.m4 --- a/common/autoconf/boot-jdk.m4 +++ b/common/autoconf/boot-jdk.m4 @@ -74,7 +74,7 @@ BOOT_JDK_FOUND=no else # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD -n 1` + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP version | $HEAD -n 1` # Extra M4 quote needed to protect [] in grep expression. [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION | $EGREP '\"9([\.+-].*)?\"|(1\.[89]\.)'`] But the main problem here seems to be the Debian openjdk8 instance that crashes on "java -version". Seems like a good and simple test to add to your test matrix. ;-) /Magnus > > Adrian > From thomas.stuefe at gmail.com Mon Sep 4 12:34:33 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 4 Sep 2017 14:34:33 +0200 Subject: windows: sporadic configure errors in cygwin In-Reply-To: <877a2485-a9ed-9fcd-1594-cd71da3f1d3a@oracle.com> References: <877a2485-a9ed-9fcd-1594-cd71da3f1d3a@oracle.com> Message-ID: Hi Magnus, On Mon, Sep 4, 2017 at 12:09 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2017-08-11 13:00, Thomas St?fe wrote: > >> Hi all, >> >> when building OpenJDK 10/hs on Windows, I get sporadic configure errors. >> Usually one of two things, either: >> >> configure: The tested number of bits in the target (0) differs from the >> number of bits expected to be found in the target (32). >> >> or the endianness test failing. >> >> Most of the time, just retrying the configure run works. >> >> I have the feeling this happens mostly when running several builds in >> parallel. I am currently using 32bit cygwin. >> > You cannot/should not run multiple "configure" in parallel in the same > directory. This is due to a limitation of the autoconf framework that we > are using -- they test features (like word size) by creating a file in the > current directory (conf.c I believe it's called), compiling and running it. > So if you run multiple configure calls in parallel, these tests can > interfere with each other. > > Thanks for looking into this. Not sure I understand you: I call configure script from different build output directories ("output-slowdebug", "output-release" etc), one directory per build. But all builds reference the same source tree. Would that be the problem you describe? ..Thomas Once the configure step is done, you can build multiple configurations > using "make" at the same time. > > /Magnus > > > >> Does anyone see similar errors or maybe have a solution? >> >> Best Regards, Thomas >> > > From magnus.ihse.bursie at oracle.com Mon Sep 4 13:15:25 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Sep 2017 15:15:25 +0200 Subject: windows: sporadic configure errors in cygwin In-Reply-To: References: <877a2485-a9ed-9fcd-1594-cd71da3f1d3a@oracle.com> Message-ID: <2fb0eefd-d859-6876-fa65-e7d2210823e2@oracle.com> On 2017-09-04 14:34, Thomas St?fe wrote: > Hi Magnus, > > On Mon, Sep 4, 2017 at 12:09 PM, Magnus Ihse Bursie > > > wrote: > > > On 2017-08-11 13:00, Thomas St?fe wrote: > > Hi all, > > when building OpenJDK 10/hs on Windows, I get sporadic > configure errors. > Usually one of two things, either: > > configure: The tested number of bits in the target (0) differs > from the > number of bits expected to be found in the target (32). > > or the endianness test failing. > > Most of the time, just retrying the configure run works. > > I have the feeling this happens mostly when running several > builds in > parallel. I am currently using 32bit cygwin. > > You cannot/should not run multiple "configure" in parallel in the > same directory. This is due to a limitation of the autoconf > framework that we are using -- they test features (like word size) > by creating a file in the current directory (conf.c I believe it's > called), compiling and running it. So if you run multiple > configure calls in parallel, these tests can interfere with each > other. > > > Thanks for looking into this. > > Not sure I understand you: I call configure script from different > build output directories ("output-slowdebug", "output-release" etc), > one directory per build. But all builds reference the same source > tree. Would that be the problem you describe? If you do cd jdk10 mkdir -P build/output-slowdebug cd build/output-slowdebug bash ../../configure (and similarly for output-release) then it should work, afaik. If you do cd jdk10 bash configure --with-conf-name=output-slowdebug (and similarly for output-release) then the configure scripts run in the same directory, and it can fail. So if you do the first option, and it still fails intermittently, then there is something else at play. /Magnus > > ..Thomas > > Once the configure step is done, you can build multiple > configurations using "make" at the same time. > > > /Magnus > > > > Does anyone see similar errors or maybe have a solution? > > Best Regards, Thomas > > > From magnus.ihse.bursie at oracle.com Mon Sep 4 13:46:48 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 4 Sep 2017 15:46:48 +0200 Subject: Building SPARC CPU code for Zero In-Reply-To: <51d89bce-c0fc-e936-9bf4-d78ad93dd8d1@physik.fu-berlin.de> References: <97d2649b-facb-e0fb-e2de-a7dbae90f264@physik.fu-berlin.de> <3d4fd7c9-450d-6e42-036d-83cd5150cd87@oracle.com> <51d89bce-c0fc-e936-9bf4-d78ad93dd8d1@physik.fu-berlin.de> Message-ID: Here's a (not very elegant) patch that includes this file when compiling zero on sparc: diff --git a/make/lib/JvmFeatures.gmk b/make/lib/JvmFeatures.gmk --- a/make/lib/JvmFeatures.gmk +++ b/make/lib/JvmFeatures.gmk @@ -47,6 +47,9 @@ ifeq ($(call check-jvm-feature, zero), true) JVM_CFLAGS_FEATURES += -DZERO -DCC_INTERP -DZERO_LIBARCH='"$(OPENJDK_TARGET_CPU_LEGACY_LIB)"' $(LIBFFI_CFLAGS) JVM_LIBS_FEATURES += $(LIBFFI_LIBS) + ifeq ($(OPENJDK_TARGET_CPU), sparcv9) + BUILD_LIBJVM_EXTRA_FILES := $(HOTSPOT_TOPDIR)/src/cpu/sparc/vm/memset_with_concurrent_readers_sparc.cpp + endif endif ifeq ($(call check-jvm-feature, shark), true) I think it solves your immediate problem. I would be (reluctantly) willing to accept this patch (but I'd like to hear Erik's objections too, first). If this is the only file that will need to be included like this, fine, but if this pattern is starting to grow to include more and more platform-specific files in zero, I won't like it. I'm still looking at a better way to solve the relationship between zero and the platform-specific parts overall, but that's likely to a much bigger change, so don't hold your breath. /Magnus On 2017-08-30 15:33, John Paul Adrian Glaubitz wrote: > On 08/30/2017 03:25 PM, Magnus Ihse Bursie wrote: >> Would it be painful to duplicate the function in cpu/zero? I realize >> this >> is not elegant, but we don't have a good story for sharing >> platform-specific >> functionality with zero. :( > > But then we could also just move it into src/share/vm/gc/shared/, > couldn't we? > > Adrian > From glaubitz at physik.fu-berlin.de Mon Sep 4 13:49:49 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 4 Sep 2017 15:49:49 +0200 Subject: Building SPARC CPU code for Zero In-Reply-To: References: <97d2649b-facb-e0fb-e2de-a7dbae90f264@physik.fu-berlin.de> <3d4fd7c9-450d-6e42-036d-83cd5150cd87@oracle.com> <51d89bce-c0fc-e936-9bf4-d78ad93dd8d1@physik.fu-berlin.de> Message-ID: <397da236-47c2-3f5d-cf60-f88063737536@physik.fu-berlin.de> Hi Magnus! On 09/04/2017 03:46 PM, Magnus Ihse Bursie wrote: > Here's a (not very elegant) patch that includes this file when compiling zero on sparc: Thanks for the patch. I was looking for something like that. > I think it solves your immediate problem. I would be (reluctantly) willing to accept this > patch (but I'd like to hear Erik's objections too, first). If this is the only file that > will need to be included like this, fine, but if this pattern is starting to grow to > include more and more platform-specific files in zero, I won't like it. I will definitely add it to the Debian package for the time being. > I'm still looking at a better way to solve the relationship between zero and the > platform-specific parts overall, but that's likely to a much bigger change, > so don't hold your breath. I suggest merging it, but adding a comment that it's just a temporary workaround. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Mon Sep 4 14:15:16 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 4 Sep 2017 16:15:16 +0200 Subject: windows: sporadic configure errors in cygwin In-Reply-To: <2fb0eefd-d859-6876-fa65-e7d2210823e2@oracle.com> References: <877a2485-a9ed-9fcd-1594-cd71da3f1d3a@oracle.com> <2fb0eefd-d859-6876-fa65-e7d2210823e2@oracle.com> Message-ID: On Mon, Sep 4, 2017 at 3:15 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2017-09-04 14:34, Thomas St?fe wrote: > > Hi Magnus, > > On Mon, Sep 4, 2017 at 12:09 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> >> On 2017-08-11 13:00, Thomas St?fe wrote: >> >>> Hi all, >>> >>> when building OpenJDK 10/hs on Windows, I get sporadic configure errors. >>> Usually one of two things, either: >>> >>> configure: The tested number of bits in the target (0) differs from the >>> number of bits expected to be found in the target (32). >>> >>> or the endianness test failing. >>> >>> Most of the time, just retrying the configure run works. >>> >>> I have the feeling this happens mostly when running several builds in >>> parallel. I am currently using 32bit cygwin. >>> >> You cannot/should not run multiple "configure" in parallel in the same >> directory. This is due to a limitation of the autoconf framework that we >> are using -- they test features (like word size) by creating a file in the >> current directory (conf.c I believe it's called), compiling and running it. >> So if you run multiple configure calls in parallel, these tests can >> interfere with each other. >> >> > Thanks for looking into this. > > Not sure I understand you: I call configure script from different build > output directories ("output-slowdebug", "output-release" etc), one > directory per build. But all builds reference the same source tree. Would > that be the problem you describe? > > > If you do > > cd jdk10 > mkdir -P build/output-slowdebug > cd build/output-slowdebug > bash ../../configure > > (and similarly for output-release) then it should work, afaik. If you do > > cd jdk10 > bash configure --with-conf-name=output-slowdebug > > (and similarly for output-release) then the configure scripts run in the > same directory, and it can fail. > > So if you do the first option, and it still fails intermittently, then > there is something else at play. > > It is the first option. My build directories are not even under the source, but beside them: cd output bash ../source/configure But right now, the errors seem to have disappeared, so I am good for now. Should the errors come back I'll investigate more. Thank you! ..Thomas > /Magnus > > > ..Thomas > > Once the configure step is done, you can build multiple configurations >> using "make" at the same time. >> >> > /Magnus >> >> >> >>> Does anyone see similar errors or maybe have a solution? >>> >>> Best Regards, Thomas >>> >> >> > > From david.holmes at oracle.com Tue Sep 5 04:27:46 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Sep 2017 14:27:46 +1000 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: References: Message-ID: Hi Goetz, On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote: > Hi, > > I found that not all libraries are linked with -z,noexecstack. > This lead to errors with our linuxppc64 build. The linker omitted > the flag altogether, which is interpreted as a lib with execstack. > > This change contains a small test that scans all libraries in the tested VM > to have the noexecstack flag set. It utilizes the elf parser in the VM for this. > Further -z,noexecstack is now passed to all libraries. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.01/ So IIUC presently we only set noexecstack for gcc on linux when building libjvm - via the JVM_LDFLAGS settings. With this change we also set it for building JDK libraries via the LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited to gcc and linux ?? In addition we want to build libjsig with noexecstack, and we do that by exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in CompileLibjsig.gmk. I don't have an issue with the use of noexecstack but I think it could just have been hard-wired for linux just as the bulk of the flags set in that file are. Granted you copied what is done for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important that the same hash style be used throughout. Anyway minor stylistic nit which may be moot soon as once we have the consolidated repo I think libjsig could be handled the same as others libs? > http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.01-hs/ Test changes look okay to me. Thanks, David > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Tue Sep 5 08:04:57 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 5 Sep 2017 08:04:57 +0000 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: References: Message-ID: <0559eb3655cc42bb8b6cb37fb4370da8@sap.com> Hi David, thanks for looking at my change! > Hi Goetz, > > On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I found that not all libraries are linked with -z,noexecstack. > > This lead to errors with our linuxppc64 build. The linker omitted > > the flag altogether, which is interpreted as a lib with execstack. > > > > This change contains a small test that scans all libraries in the tested VM > > to have the noexecstack flag set. It utilizes the elf parser in the VM for this. > > Further -z,noexecstack is now passed to all libraries. > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr17/8187045- > execstackLink/webrev.01/ > > So IIUC presently we only set noexecstack for gcc on linux when building > libjvm - via the JVM_LDFLAGS settings. Yes. > With this change we also set it for building JDK libraries via the > LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited > to gcc and linux ?? LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on linux, on other platforms its empty. > In addition we want to build libjsig with noexecstack, and we do that by > exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in > CompileLibjsig.gmk. I don't have an issue with the use of noexecstack > but I think it could just have been hard-wired for linux just as the > bulk of the flags set in that file are. Granted you copied what is done > for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important > that the same hash style be used throughout. Anyway minor stylistic nit > which may be moot soon as once we have the consolidated repo I think > libjsig could be handled the same as others libs? I had hoped to find a location where flags that should be used in all linking steps are assembled. Noexecstack should really be set in any lib we build. But I didn't find that, so I implemented it as with the HASH_STYLE. I don't really like it this way because if a new lib is added it might be forgotten to add the noexecstack. But I assume after the repo consolidation the build will be reshaped, so now is not the right time to seek for optimal setups. Best regards, Goetz. > > > http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.01- > hs/ > > Test changes look okay to me. > > Thanks, > David > > > Best regards, > > Goetz. > > From weijun.wang at oracle.com Wed Sep 6 04:17:33 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 6 Sep 2017 12:17:33 +0800 Subject: RFR 8148371: Remove policytool In-Reply-To: References: Message-ID: <76E698F8-551B-4DD8-9D42-3DA2764786EB@oracle.com> Hi All Please review the change, which spans to root, jdk and langtools repos. http://cr.openjdk.java.net/~weijun/8148371/ I've searched for the "policytool" word in the whole jdk10/jdk10 forests, removed all files having the word inside the path name, and remove almost all occurrences of the word in other places. The exceptions are: 1. Two files with the jdk8 word in file name. I assume I should not touch them. Please advise me. jdk/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat: 1288 sun.security.tools.jarsigner 1289 sun.security.tools.keytool 1290: sun.security.tools.policytool 1291 sun.security.util 1292 sun.security.validator langtools/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdk8_internals.txt: 977 sun.security.tools.jarsigner 978 sun.security.tools.keytool 979: sun.security.tools.policytool 980 sun.security.util 981 sun.security.validator 2. A swing test containing a full JDK 1.4.2 README text. Keep unchanged. jdk/test/javax/swing/JTextArea/4697612/bug4697612.txt: 122 bin/ktab and jre/bin/ktab 123 Kerberos key table manager 124: bin/policytool and jre/bin/policytool 125 Policy File Creation and Management Tool 126 bin/orbd and jre/bin/orbd 3. A manual test on what resource string are used. It is based on the pre-module source layout and needs to be updated anyway. Keep unchanged this time. https://bugs.openjdk.java.net/browse/JDK-8187265 filed. jdk/test/sun/security/util/Resources/NewResourcesNames.java: 62 "sun/security/tools/jarsigner/Resources.java", 63 "sun/security/tools/keytool/Resources.java", 64: "sun/security/tools/policytool/Resources.java", 65 "sun/security/util/Resources.java", 66 "sun/security/util/AuthResources.java", .. 103 // 104 // which is mismatch. There are only two such special cases list above. 105: // For KeyTool, there are 3 calls for showing help. For PolicyTool, 3 106 // for name prefixed with POLICY. They are covered in the two special 107 // cases above. There are some Japanese man pages containing the word. I've filed another bug (https://bugs.openjdk.java.net/browse/JDK-8187262) on it. Thanks Max From glewis at eyesbeyond.com Wed Sep 6 04:39:34 2017 From: glewis at eyesbeyond.com (Greg Lewis) Date: Tue, 5 Sep 2017 21:39:34 -0700 Subject: [RFR]: 8187004: No valid toolchains defined for BSD In-Reply-To: References: <550da30a-2e50-1589-62a2-e22bdf33edd2@physik.fu-berlin.de> <772e82a3-5314-5ae9-fc16-dd13dcfb6306@oracle.com> <897f432c-9457-1af9-688f-5f21c7b83d2c@oracle.com> Message-ID: <20170906043934.GB78629@misty.eyesbeyond.com> On Thu, Aug 31, 2017 at 12:14:10PM +0200, dalibor topic wrote: > (CC:ing bsd-port-dev, where this conversation should have moved to a > while ago ...) > > On 31.08.2017 10:53, John Paul Adrian Glaubitz wrote: > > There is an active community maintaining OpenJDK on BSD. The problem is > > just that they are doing it downstream instead of working together with > > upstream due to lack of communication. I think that is a problem that can > > be fixed though. > > > > I will try to get these people join the upstream mailing list. > > As far as I know, most of the people who actively maintain the BSD ports > in various BSD distributions are already Committers on the BSD port Project: > > Per http://openjdk.java.net/census#bsd-port > > Greg Lewis (Project Lead, FreeBSD) & Jung-uk Kim (FreeBSD) > Christos Zoulas (NetBSD) > Kurt Miller (OpenBSD) > > The FreeBSD Foundation is an OCTLA signatory: > http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html > > Unfortunately, no one has produced a build of the OpenJDK BSD port that > passes the JCK yet, as far as I know. This is accurate. We haven't attempted to pass the JCK for any port more recent than Java 5 IIRC. At that point we did get a port that had passed, but that required a lot of work which was sponsored at the time by the FreeBSD Foundation. I'm not aware of anyone attempting it since. > The challenge in the past has been that the time the individual BSD Port > developers have generously been able to spend on keeping the BSD port up > and running (Greg just updated the JDK 8 forest with latest changes, > while Kurt fixed a set of compilation issues this month - thanks!) [0] > was not sufficient to simultaneously let them make enough progress on > integrating their port into mainline JDK. Maybe the BSD porters are > interested in having more individuals help with the various tasks around > that - but it's also worth keeping in mind that the set of individuals > who speak up wanting to help out with the port on bsd-port-dev is less > than a handful per year. > > One of the conditions for getting a port into JDK mainline has been that > it should actually pass the JCK for the current version. I think that's > a low enough bar that should remain in place for JDK 9 and beyond. FWIW, I agree that is a completely reasonable bar to meet. Unfortunately with the lack of time of the people involved it has been difficult to meet this. I expect this will again require a funded effort to again have someone be able to devote enough time to actually meet this bar. The points below only serve to reinforce that. In "funded effort" I'm including making it part of somebodies paid job to get the port passing the JCK and ensure it continues to do so as needed. That said, if there are people with lots of time to volunteer to do this I'd love to hear from you. Until then, we're happy to accept patches into the bsd-port repo from registered contributors. > Here's a slightly updated version of what I wrote about getting BSD > ports into mainline back in 2014 as part of a conversation with Greg > about it: > > In general, ports should come in through the 'next release' project, > i.e. JDK9/10 currently, as that is where most of the development > happens, and so that's the best place to review and integrate the > changes going forward. Well, JDK 10, really, at this stage of JDK 9 > development. > > * At this point in time, I'd be very pessimistic about adding new ports > further back to the JDK 8 Updates Project or earlier, as they are more > focused on bug fixes and stability, rather than adding features. > > * For a port to get into mainline, it needs to have a JEP, and the JEP > needs to be funded. Basically, someone needs to sign up to do all the > necessary work. > > See http://openjdk.java.net/jeps/175 for the JEP for the PowerPC64 > AIX/Linux port JEP, for an example, of what a JEP for a port should look > like. See http://openjdk.java.net/jeps/1 for details, > and http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html for the revision > of the JEP process. > > * All source code changes need to be reviewed by the respective > reviewers for mainline, as usual. This typically implies for a port's > integration that it's a non-trivial effort on the side of Reviewers from > Oracle and other port maintainers to ensure that changes proposed for > review actually get timely reviews. Depending on how much there is to > review, you'd want to get a plan in place that lets everyone plan their > involvement in the review process accordingly, rather than just posting > a bunch of patches for review on several mailing lists and hoping for > the best. > > * Each port is slightly different - some touch only a few files, others > bring in new subsystems for graphics, native code, programming > languages, CPUs, core libraries, etc. > > So while in some cases integrating a port can be rather straightforward, > because it touches only a limited set of files, in other cases it can be > a complicated undertaking that requires several synchronization points, > planning, and efficient execution from many parties to pull it off in > time for a JDK release feature freeze. I.e. if you want to get a new > port into mainline you'd need to get started early in a JDK release cycle. > > * Testing is very important - a port should not introduce regressions, > for example. It should also pass the JCK for the current release. The > JDK mainline has rather strict rules about reviews, and processes to > follow, which makes it an inconvenient place to finish off an unfinished > port - that's what the porting projects are for. > > * Once a port get into the mainline JDK project, it's expected to be > kept up to date by its maintainers - which means keeping up with the > regular stream of changes - for example, the integration of Jigsaw into > JDK 9 resulted in some build system changes (because of modules), and it > would be up to each port's maintainers to make sure that they keep their > port in sync in tree. > > cheers, > dalibor topic > > [0] > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2017-August/thread.html > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > -- Greg Lewis Email : glewis at eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis at FreeBSD.org From erik.joelsson at oracle.com Wed Sep 6 08:53:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 6 Sep 2017 10:53:27 +0200 Subject: RFR 8148371: Remove policytool In-Reply-To: <76E698F8-551B-4DD8-9D42-3DA2764786EB@oracle.com> References: <76E698F8-551B-4DD8-9D42-3DA2764786EB@oracle.com> Message-ID: From a build point of view this looks good. /Erik On 2017-09-06 06:17, Weijun Wang wrote: > Hi All > > Please review the change, which spans to root, jdk and langtools repos. > > http://cr.openjdk.java.net/~weijun/8148371/ > > I've searched for the "policytool" word in the whole jdk10/jdk10 forests, removed all files having the word inside the path name, and remove almost all occurrences of the word in other places. > > The exceptions are: > > 1. Two files with the jdk8 word in file name. I assume I should not touch them. Please advise me. > > jdk/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat: > 1288 sun.security.tools.jarsigner > 1289 sun.security.tools.keytool > 1290: sun.security.tools.policytool > 1291 sun.security.util > 1292 sun.security.validator > > langtools/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdk8_internals.txt: > 977 sun.security.tools.jarsigner > 978 sun.security.tools.keytool > 979: sun.security.tools.policytool > 980 sun.security.util > 981 sun.security.validator > > 2. A swing test containing a full JDK 1.4.2 README text. Keep unchanged. > > jdk/test/javax/swing/JTextArea/4697612/bug4697612.txt: > 122 bin/ktab and jre/bin/ktab > 123 Kerberos key table manager > 124: bin/policytool and jre/bin/policytool > 125 Policy File Creation and Management Tool > 126 bin/orbd and jre/bin/orbd > > 3. A manual test on what resource string are used. It is based on the pre-module source layout and needs to be updated anyway. Keep unchanged this time. https://bugs.openjdk.java.net/browse/JDK-8187265 filed. > > jdk/test/sun/security/util/Resources/NewResourcesNames.java: > 62 "sun/security/tools/jarsigner/Resources.java", > 63 "sun/security/tools/keytool/Resources.java", > 64: "sun/security/tools/policytool/Resources.java", > 65 "sun/security/util/Resources.java", > 66 "sun/security/util/AuthResources.java", > .. > 103 // > 104 // which is mismatch. There are only two such special cases list above. > 105: // For KeyTool, there are 3 calls for showing help. For PolicyTool, 3 > 106 // for name prefixed with POLICY. They are covered in the two special > 107 // cases above. > > There are some Japanese man pages containing the word. I've filed another bug (https://bugs.openjdk.java.net/browse/JDK-8187262) on it. > > Thanks > Max > From Alan.Bateman at oracle.com Wed Sep 6 09:24:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 Sep 2017 10:24:22 +0100 Subject: RFR 8148371: Remove policytool In-Reply-To: <76E698F8-551B-4DD8-9D42-3DA2764786EB@oracle.com> References: <76E698F8-551B-4DD8-9D42-3DA2764786EB@oracle.com> Message-ID: On 06/09/2017 05:17, Weijun Wang wrote: > Hi All > > Please review the change, which spans to root, jdk and langtools repos. > > http://cr.openjdk.java.net/~weijun/8148371/ > > I've searched for the "policytool" word in the whole jdk10/jdk10 forests, removed all files having the word inside the path name, and remove almost all occurrences of the word in other places. > This looks good, the only change that I'm not sure about is the change to ct.properties as it may be used when compiling to older releases. Someone on compiler-dev should be able to help you on that. -Alan From magnus.ihse.bursie at oracle.com Wed Sep 6 12:01:10 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Sep 2017 14:01:10 +0200 Subject: CompileJavaModule.gmk overrides values from a custom extension gmk In-Reply-To: References: <6e46f4d2-82fc-5fc3-1880-0419b15f7204@oracle.com> <56ce80cd-851c-73fe-e226-8f9d6ff6124c@oracle.com> <5833f194-3591-ee7b-326f-0a551d469096@oracle.com> <72423803-c716-3456-021d-a3d179d054d6@oracle.com> <59A6D03E.7090406@oracle.com> <62617b3b-b594-9a88-71f5-c0aa35f52780@oracle.com> Message-ID: <2be61371-b198-d0a5-0351-4498998272e1@oracle.com> On 2017-08-31 09:43, Erik Joelsson wrote: > Updated webrev with the below corrected: > > http://cr.openjdk.java.net/~erikj/8186983/webrev.02/ Looks good to me. Thanks Jason and Erik! /Magnus > > /Erik > > > On 2017-08-30 16:57, Erik Joelsson wrote: >> Hello, >> >> >> On 2017-08-30 16:48, Gary Adams wrote: >>> Is the expectation that all of the := will be changed to += for >>> these variables? >>> >>> 468 jdk.internal.vm.ci_ADD_JAVAC_FLAGS := -parameters >>> -Xlint:-exports -XDstringConcat=inline >>> >> Good catch! I missed that when just reviewing the patch file. >>> Do the closed makefiles also need to be updated? >> No, they should be fine as they are. >> >> /Erik >>> >>> On 8/30/17, 10:36 AM, Erik Joelsson wrote: >>>> Hello Jason, >>>> >>>> I took the liberty of creating an issue for this: >>>> https://bugs.openjdk.java.net/browse/JDK-8186983 >>>> >>>> The mailing list server removes attachments. This makes it >>>> difficult for new people to send in their patches until they have >>>> an openjdk user so they can upload to cr.openjdk.java.net. Since >>>> you addressed the mail directly to me as well, I received the >>>> attachment and have created a webrev from it here: >>>> >>>> http://cr.openjdk.java.net/~erikj/8186983/webrev.01/ >>>> >>>> I think the patch looks good now, but will leave it here until >>>> tomorrow to give other reviewers a chance to look at. >>>> >>>> /Erik >>>> >>>> >>>> On 2017-08-30 16:20, Jason Yong wrote: >>>>> Hi Eric, >>>>> >>>>> I've removed the SETUP changes as requested... >>>>> >>>>> >>>>> >>>>> On a side note, I noticed that the attachment got stripped out in >>>>> the post >>>>> to the mailing list. Should I actually be copying and pasting the >>>>> entire >>>>> diff in the message? Its a couple of hundred lines... or is >>>>> somewhere to >>>>> put the attachment? >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Jason Yong >>>>> CEng MEng MIET >>>>> Software Engineer, IBM Runtimes Technology >>>>> IBM Hybrid Cloud >>>>> >>>>> >>>>> Phone: 44-1962-815256 >>>>> E-mail: yongja at uk.ibm.com >>>>> Find me on: and within IBM on: >>>>> >>>>> >>>>> Hursley Park >>>>> Hursley, SO212JN >>>>> United Kingdom >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: Erik Joelsson >>>>> To: Jason Yong >>>>> Cc: build-dev at openjdk.java.net >>>>> Date: 30/08/2017 14:43 >>>>> Subject: Re: CompileJavaModule.gmk overrides values from a >>>>> custom >>>>> extension gmk >>>>> >>>>> >>>>> >>>>> Hello, >>>>> >>>>> Changing the assignment on COPY, CLEAN and FLAGS variables makes >>>>> sense, >>>>> but please revert the SETUP variables as those are not lists but >>>>> single >>>>> value types. >>>>> >>>>> Otherwise this looks good to me. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-08-30 15:37, Jason Yong wrote: >>>>>> Hi Eric, >>>>>> >>>>>> With regards to the OCA I believe IBM has signed a contributors >>>>> agreement >>>>>> which should cover me for that. >>>>>> >>>>>> >>>>>> So here's the mercurial export of the CompileJavaModule.java with my >>>>>> changes in >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> Jason Yong >>>>>> >>>>>> CEng MEng MIET >>>>>> Software Engineer, IBM Runtimes Technology >>>>>> IBM Hybrid Cloud >>>>>> >>>>>> >>>>>> Phone: 44-1962-815256 >>>>>> E-mail: yongja at uk.ibm.com >>>>>> Find me on: and within IBM on: >>>>>> >>>>>> >>>>>> Hursley Park >>>>>> Hursley, SO212JN >>>>>> United Kingdom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Erik Joelsson >>>>>> To: Jason Yong >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Date: 30/08/2017 13:47 >>>>>> Subject: Re: CompileJavaModule.gmk overrides values from a >>>>>> custom >>>>>> extension gmk >>>>>> >>>>>> >>>>>> >>>>>> If you have signed the OCA, you can post your proposed change >>>>>> here and I >>>>>> or someone else will sponsor it once we agree that it looks good. >>>>>> /Erik >>>>>> >>>>>> On 2017-08-30 14:27, Jason Yong wrote: >>>>>> Thanks Eric, >>>>>> >>>>>> Is the next step is to get a sponsor for the change or should I >>>>>> post my >>>>>> proposed change first? >>>>>> >>>>>> Jason >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jason Yong >>>>>> CEng MEng MIET >>>>>> Software Engineer, IBM Runtimes Technology >>>>>> IBM Hybrid Cloud >>>>>> >>>>>> >>>>>> Phone: 44-1962-815256 >>>>>> E-mail: yongja at uk.ibm.com >>>>>> Find me on: and within IBM on: >>>>>> >>>>>> >>>>>> Hursley Park >>>>>> Hursley, SO212JN >>>>>> United Kingdom >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Erik Joelsson >>>>>> To: Jason Yong , >>>>> build-dev at openjdk.java.net >>>>>> Date: 29/08/2017 12:55 >>>>>> Subject: Re: CompileJavaModule.gmk overrides values from a >>>>>> custom >>>>>> extension gmk >>>>>> >>>>>> >>>>>> >>>>>> Hello Jason, >>>>>> >>>>>> Your suggestion makes sense. The only reason these variables have := >>>>>> today is that we (at Oracle) haven't had a need for appending to >>>>>> those >>>>>> particular variables (yet). >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2017-08-29 11:31, Jason Yong wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I've had an issue where I've had a custom extension to >>>>>> CompileJavaModules.gmk with the variable java.base_COPY set to files >>>>> that >>>>>> I wanted to be copied across but its value was overwritten by >>>>>> CompileJavaModules.gmk. >>>>>>> I would like to propose changes that would allow a custom >>>>>>> extensions to >>>>>> update variables listed in CompileJavaModules.gmk. This issue is >>>>>> similar >>>>>> to bug JDK-8064372 ( >>>>>> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8064372&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_pd0JudnAMtzyOP3NkOCP7ozDRbZ9ukki8lLmogKLJI&m=qG_YEjgXnzBfNvN5ztSbjIVP3nZ5SaZCibl7SHJjTfc&s=2mMmeC6jKTJu1OgK0Lssib1LKQvOFX3BwzIcJAebSeU&e= >>>>> >>>>> >>>>>> ) but affects all the other variables such as: >>>>>>> java.activation_SETUP >>>>>>> java.base_ADD_JAVAC_FLAGS >>>>>>> java.base_COPY >>>>>>> java.base_CLEAN >>>>>>> etc >>>>>>> >>>>>>> The fix is also similar, changing := to += allowing the custom >>>>> extension >>>>>> to append to the variable if already set and create it if its not. >>>>>>> I would appreciate any feedback and help on what the next steps >>>>>>> would >>>>>> be. >>>>>>> Thanks >>>>>>> >>>>>>> Jason >>>>>>> >>>>>>> >>>>>>> Jason Yong >>>>>>> CEng MEng MIET >>>>>>> Software Engineer, IBM Runtime Technologies >>>>>>> IBM Hybrid Cloud >>>>>>> Phone: 44-1962-815256 >>>>>>> E-mail: yongja at uk.ibm.com >>>>>>> Find me on: and within IBM on: >>>>>>> Unless stated otherwise above: >>>>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>> number >>>>>> 741598. >>>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, >>>>>>> Hampshire PO6 >>>>>> 3AU >>>>>> >>>>>> >>>>>> >>>>>> Unless stated otherwise above: >>>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>>> number >>>>>> 741598. >>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, >>>>>> Hampshire PO6 >>>>> 3AU >>>>>> >>>>>> >>>>>> Unless stated otherwise above: >>>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>>> number >>>>>> 741598. >>>>>> Registered office: PO Box 41, North Harbour, Portsmouth, >>>>>> Hampshire PO6 >>>>> 3AU >>>>> >>>>> >>>>> >>>>> >>>>> Unless stated otherwise above: >>>>> IBM United Kingdom Limited - Registered in England and Wales with >>>>> number >>>>> 741598. >>>>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >>>>> PO6 3AU >>>> >>> >> > From thomas.stuefe at gmail.com Thu Sep 7 08:23:17 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Sep 2017 10:23:17 +0200 Subject: Re-using shared object in another unrelated test? Message-ID: Hi all, I'd am writing a jtreg test which loads a native shared library. I do not actually need to do anything with the shared library, so loading and unloading again. I do not plan on resolving any exports, it just needs to be there and be valid, on all platforms. There are a number of shared objects which would be a fit, e.g. JniVersion. Would it be okay to use this in a jtreg test or would this be considered bad form? Thank you, Thomas From david.holmes at oracle.com Thu Sep 7 08:29:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Sep 2017 18:29:10 +1000 Subject: Re-using shared object in another unrelated test? In-Reply-To: References: Message-ID: <7141e7b3-f480-5ce6-65e0-43b98477be2f@oracle.com> Hi Thomas, On 7/09/2017 6:23 PM, Thomas St?fe wrote: > Hi all, > > I'd am writing a jtreg test which loads a native shared library. I do > not actually need to do anything with the shared library, so loading and > unloading again. I do not plan on resolving any exports, it just needs > to be there and be valid, on all platforms. > > There are a number of shared objects which would be a fit, e.g. > JniVersion. Would it be okay to use this in a jtreg test or would this > be considered bad form? Given the convention used to get the native parts of jtreg tests built (when building test-image) I would think it simpler, and cleaner to just define a trivial .c file and build the library from it. Thanks, David > Thank you, Thomas From thomas.stuefe at gmail.com Thu Sep 7 09:33:58 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Sep 2017 11:33:58 +0200 Subject: Re-using shared object in another unrelated test? In-Reply-To: <7141e7b3-f480-5ce6-65e0-43b98477be2f@oracle.com> References: <7141e7b3-f480-5ce6-65e0-43b98477be2f@oracle.com> Message-ID: On Thu, Sep 7, 2017 at 10:29 AM, David Holmes wrote: > Hi Thomas, > > On 7/09/2017 6:23 PM, Thomas St?fe wrote: > >> Hi all, >> >> I'd am writing a jtreg test which loads a native shared library. I do not >> actually need to do anything with the shared library, so loading and >> unloading again. I do not plan on resolving any exports, it just needs to >> be there and be valid, on all platforms. >> >> There are a number of shared objects which would be a fit, e.g. >> JniVersion. Would it be okay to use this in a jtreg test or would this be >> considered bad form? >> > > Given the convention used to get the native parts of jtreg tests built > (when building test-image) I would think it simpler, and cleaner to just > define a trivial .c file and build the library from it. > > Thanks, > David > > Thanks, David, I will do that. ..Thomas > Thank you, Thomas >> > From thomas.stuefe at gmail.com Thu Sep 7 10:01:48 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Sep 2017 12:01:48 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default Message-ID: Hi all, may I please have a review for the following AIX-only patch. Issue: https://bugs.openjdk.java.net/browse/JDK-8187228 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data -segment-page-size-64K-by-default/webrev.00/webrev/ It changes the default page size for the data segment (C-heap and Posix Thread Stacks) to 64K. For completeness and simplicity sake, it also changes default page size for text segment and primordial thread stacl to 64K, but that does not matter much. For more details, please see the issue description. Thank you, Thomas From volker.simonis at gmail.com Thu Sep 7 10:23:56 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Sep 2017 12:23:56 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: Yes, I can also confirm Thomas' numbers. Tried from home on my 25Mbps line with both company/private PC and couldn't get more than 350KB download speed during cloning. I've also tested a traditional repository with the get_source.sh script. By default the script uses a concurrency of two (i.e. it always processes two repositories of the forest in parallel). This obviously starts two hg processes at a time and it seems that both of them can use up to 350KB during downloading. This gets the cloning time down to 12m (compared to 38m for the new, fat consolidated repository). The concurrency of get_source.sh can be increased by setting HGFOREST_CONCURRENCY. If I set this to 8 the cloning time only drops down to 11 minutes because it is bound by the time it takes to clone the jdk repository which is by far the biggest one. So it really seems that the hg.openjdk.java.net limits the download speed per connection. Before, with the forest, this was not so much of an issue, because cloning was done in parallel for each forest, but now, with the new, single, fat, consolidated repository, this becomes a real bottleneck. Can somebody from Oracle and/or the hg.openjdk.java.net operations team please comment on this and ideally fix it? Thank you and best regards, Volker On Thu, Sep 7, 2017 at 10:07 AM, Doug Simon wrote: > >> On 7 Sep 2017, at 07:06, Thomas St?fe wrote: >> >> On Wed, Sep 6, 2017 at 5:35 PM, Volker Simonis >> wrote: >> >>> On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe >>> wrote: >>>> Erik, Volker, >>>> >>>> On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 2017-09-05 11:38, Volker Simonis wrote: >>>>>> >>>>>> Hi Joe, >>>>>> >>>>>> generally looks good! >>>>>> >>>>>> I don't know if this has discussed before, but in my opinion the >>>>>> top-level src/ directory looks a little overloaded. Wouldn't it make >>>>>> sense to place all the modules into their own 'src/modules/' >>>>>> subdirectory? >>>>> >>>>> I see what you mean, but it's no more overloaded than the jdk/src dir >>> used >>>>> to be. Also, the bsd, linux, solaris, demo and sample directories are >>> all >>>>> going away at some point in the (hopefully near) future. Left are >>> hotspot >>>>> and utils which I don't think warrant another directory level. >>>>>> >>>>>> Should jdk10/consol-proto build out of t he box or are there any known >>>>>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >>>>>> are any known, generic problems I'll wait until they get fixed. >>>>> >>>>> Yes, please try it. I have put a lot of work into maintaining a set of >>>>> patches and scripts to keep the generated consolidated repo working and >>>>> (near) equivalent with the current forest. You can review those changes >>> in >>>>> the prototype forest if you like. >>>>> >>>> >>>> I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. >>> Build >>>> runs fine. >>>> >>> >>> Hi Thomas, >>> >>> thanks for checking the AIX build. >>> >>>> However, I found cloning the repository painfully slow. >>>> >>>> On my Linux box clone took ~90 minutes. On Windows, I could not >>> successfully >>>> clone, as cygwin mercurial did hit timeouts. I really hope this is only >>>> temporary and will improve? >>>> >>> >>> I think you should ask your company and/or Internet provider :) >>> >>> The new, consolidated repository is about 1.6GB in size (i.e. the size >>> of .hg) and the cloning speed is actually pretty much proportional to >>> the time you need to download this amount of data. >>> >>> When using our http-proxy I measured a download speed of about 350 >>> KB/s. The calculation is quite simple: >>> >>> 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( >>> >>> The actual cloning speed was slightly faster: >>> >>> $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto >>> jdk10-cons-proto >>> requesting all changes >>> adding changesets >>> adding manifests >>> adding file changes >>> added 46937 changesets with 397578 changes to 162338 files >>> updating to branch default >>> 57067 files updated, 0 files merged, 0 files removed, 0 files >>> unresolved >>> >>> real 38m37.424s >>> user 5m46.620s >>> sys 0m33.976s >>> >>> which is probably because the 1.6 GB from the .hg repo may be >>> compressed for the transport. >>> >>> Without proxy (i.e. 'transparent proxy') the average download speed is >>> about 150 KB/s. I think this pretty much explains the ~90 minutes. >>> >>> I doubt that these poor download speeds are caused by >>> hg.openjdk.java.net because then it would be the same for the proxy >>> vs. non-proxy case. Nevertheless it would be interesting to see what >>> amount of data hg.openjdk.java.net can actually serve to Europe. So if >>> somebody with a decent Internet connection can share his experience, >>> that would be interesting. >>> >>> >> I'm on cable, with a download speed of 128Mbit. Cloning the new repo still >> took 39min. That was on Linux, with SSDs. > > I'm in Switzerland, get 85Mbps according to fast.com and it took 42min to clone the new repo. > > -Doug > >> >> Best Regards, Thomas >> >> >>> Regards, >>> Volker >>> >>>> Kind Regards, Thomas >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy >>> wrote: >>>>>>> >>>>>>> On 8/25/2017 1:52 PM, joe darcy wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>>>>>> consolidation >>>>>>>> efforts, September 2017 is almost upon us and that month remains the >>>>>>>> target >>>>>>>> to implement the repo consolidation. >>>>>>>> >>>>>>>> First, a third generation prototype having tags from both JDK 9 and >>> JDK >>>>>>>> 10 >>>>>>>> will be published in the near future. >>>>>>>> >>>>>>> [snip] >>>>>>> >>>>>>> Third generation prototype with tags from JDK 9 and JDK 10 available >>> for >>>>>>> browsing at: >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>>>>>> >>>>>>> Please sent comments by Wednesday, September 6. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Joe > From erik.joelsson at oracle.com Thu Sep 7 11:07:08 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 7 Sep 2017 13:07:08 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: References: Message-ID: <41b5244f-b3f9-44e1-6c8e-dc7287bdaf3c@oracle.com> Looks good. /Erik On 2017-09-07 12:01, Thomas St?fe wrote: > Hi all, > > may I please have a review for the following AIX-only patch. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8187228 > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data > -segment-page-size-64K-by-default/webrev.00/webrev/ > > It changes the default page size for the data segment (C-heap and Posix > Thread Stacks) to 64K. > > For completeness and simplicity sake, it also changes default page size for > text segment and primordial thread stacl to 64K, but that does not matter > much. > > For more details, please see the issue description. > > Thank you, Thomas From thomas.stuefe at gmail.com Thu Sep 7 11:44:40 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Sep 2017 13:44:40 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: <41b5244f-b3f9-44e1-6c8e-dc7287bdaf3c@oracle.com> References: <41b5244f-b3f9-44e1-6c8e-dc7287bdaf3c@oracle.com> Message-ID: Thank you Eric! On Thu, Sep 7, 2017 at 1:07 PM, Erik Joelsson wrote: > Looks good. > > /Erik > > > > On 2017-09-07 12:01, Thomas St?fe wrote: > >> Hi all, >> >> may I please have a review for the following AIX-only patch. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8187228 >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data >> -segment-page-size-64K-by-default/webrev.00/webrev/ >> >> It changes the default page size for the data segment (C-heap and Posix >> Thread Stacks) to 64K. >> >> For completeness and simplicity sake, it also changes default page size >> for >> text segment and primordial thread stacl to 64K, but that does not matter >> much. >> >> For more details, please see the issue description. >> >> Thank you, Thomas >> > > From goetz.lindenmaier at sap.com Thu Sep 7 12:18:48 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 7 Sep 2017 12:18:48 +0000 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: References: Message-ID: Hi Thomas, Looks good. Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > Sent: Donnerstag, 7. September 2017 12:02 > To: ppc-aix-port-dev at openjdk.java.net; build-dev dev at openjdk.java.net> > Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default > > Hi all, > > may I please have a review for the following AIX-only patch. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8187228 > > > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data-segment- > page-size-64K-by-default/webrev.00/webrev/ > segment-page-size-64K-by-default/webrev.00/webrev/> > > > It changes the default page size for the data segment (C-heap and Posix > Thread Stacks) to 64K. > > > For completeness and simplicity sake, it also changes default page size for > text segment and primordial thread stacl to 64K, but that does not matter > much. > > For more details, please see the issue description. > > Thank you, Thomas From thomas.stuefe at gmail.com Thu Sep 7 12:33:55 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 Sep 2017 14:33:55 +0200 Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by default In-Reply-To: References: Message-ID: Thank you Goetz! On Thu, Sep 7, 2017 at 2:18 PM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Thomas, > > Looks good. > > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Thomas St?fe > > Sent: Donnerstag, 7. September 2017 12:02 > > To: ppc-aix-port-dev at openjdk.java.net; build-dev > dev at openjdk.java.net> > > Subject: RFR(xs): 8187228: [aix] make data segment page size 64K by > default > > > > Hi all, > > > > may I please have a review for the following AIX-only patch. > > > > Issue: > > https://bugs.openjdk.java.net/browse/JDK-8187228 > > > > > > > > webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8187228-make-data-segment- > > page-size-64K-by-default/webrev.00/webrev/ > > > segment-page-size-64K-by-default/webrev.00/webrev/> > > > > > > It changes the default page size for the data segment (C-heap and Posix > > Thread Stacks) to 64K. > > > > > > For completeness and simplicity sake, it also changes default page size > for > > text segment and primordial thread stacl to 64K, but that does not matter > > much. > > > > For more details, please see the issue description. > > > > Thank you, Thomas > From weijun.wang at oracle.com Fri Sep 8 01:51:07 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 Sep 2017 09:51:07 +0800 Subject: RFR 8148371: Remove policytool In-Reply-To: References: <76E698F8-551B-4DD8-9D42-3DA2764786EB@oracle.com> Message-ID: <7FD840F2-15D3-40F1-B2A1-9F816E4A8BD0@oracle.com> > On Sep 6, 2017, at 5:24 PM, Alan Bateman wrote: > > > > On 06/09/2017 05:17, Weijun Wang wrote: >> Hi All >> >> Please review the change, which spans to root, jdk and langtools repos. >> >> http://cr.openjdk.java.net/~weijun/8148371/ >> >> I've searched for the "policytool" word in the whole jdk10/jdk10 forests, removed all files having the word inside the path name, and remove almost all occurrences of the word in other places. >> > This looks good, the only change that I'm not sure about is the change to ct.properties as it may be used when compiling to older releases. Someone on compiler-dev should be able to help you on that. Jon suggested reverting this change, offline. --Max > > -Alan From magnus.ihse.bursie at oracle.com Fri Sep 8 11:43:34 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Sep 2017 13:43:34 +0200 Subject: Update on JDK 10 repo consolidation; third generation prototype published at http://hg.openjdk.java.net/jdk10/consol-proto In-Reply-To: References: <6ed232d7-7b84-b1b9-93e0-971678251563@oracle.com> <1f3fc74a-cc37-fdf0-91e5-20a3394f981e@oracle.com> Message-ID: <9ce3e813-9954-f68d-ba92-e2e45ac3ebd3@oracle.com> As a comparison, FWIW, I tested with my computer at home (nominally 250 Mbit/s). I cloned the consolidated repo in ~33 minutes, which corresponds to an average speed of 800 kB/s or rougly 6 Mbit/s), given that all that time was spent transmitting data (and that I've done the calculations right). That sounds like a transfer rate that's close to what I'd expect of an arbitrary, non-speed-optimized, service on the Internet in general. (On the other hand, one might argue that one would expect more of a service like hg.openjdk.java.net.) /Magnus On 2017-09-07 12:23, Volker Simonis wrote: > Yes, I can also confirm Thomas' numbers. Tried from home on my 25Mbps > line with both company/private PC and couldn't get more than 350KB > download speed during cloning. > > I've also tested a traditional repository with the get_source.sh > script. By default the script uses a concurrency of two (i.e. it > always processes two repositories of the forest in parallel). This > obviously starts two hg processes at a time and it seems that both of > them can use up to 350KB during downloading. This gets the cloning > time down to 12m (compared to 38m for the new, fat consolidated > repository). > > The concurrency of get_source.sh can be increased by setting > HGFOREST_CONCURRENCY. If I set this to 8 the cloning time only drops > down to 11 minutes because it is bound by the time it takes to clone > the jdk repository which is by far the biggest one. > > So it really seems that the hg.openjdk.java.net limits the download > speed per connection. Before, with the forest, this was not so much of > an issue, because cloning was done in parallel for each forest, but > now, with the new, single, fat, consolidated repository, this becomes > a real bottleneck. > > Can somebody from Oracle and/or the hg.openjdk.java.net operations > team please comment on this and ideally fix it? > > Thank you and best regards, > Volker > > > On Thu, Sep 7, 2017 at 10:07 AM, Doug Simon wrote: >>> On 7 Sep 2017, at 07:06, Thomas St?fe wrote: >>> >>> On Wed, Sep 6, 2017 at 5:35 PM, Volker Simonis >>> wrote: >>> >>>> On Wed, Sep 6, 2017 at 2:30 PM, Thomas St?fe >>>> wrote: >>>>> Erik, Volker, >>>>> >>>>> On Tue, Sep 5, 2017 at 7:31 PM, Erik Joelsson >>>>> wrote: >>>>>> >>>>>> >>>>>> On 2017-09-05 11:38, Volker Simonis wrote: >>>>>>> Hi Joe, >>>>>>> >>>>>>> generally looks good! >>>>>>> >>>>>>> I don't know if this has discussed before, but in my opinion the >>>>>>> top-level src/ directory looks a little overloaded. Wouldn't it make >>>>>>> sense to place all the modules into their own 'src/modules/' >>>>>>> subdirectory? >>>>>> I see what you mean, but it's no more overloaded than the jdk/src dir >>>> used >>>>>> to be. Also, the bsd, linux, solaris, demo and sample directories are >>>> all >>>>>> going away at some point in the (hopefully near) future. Left are >>>> hotspot >>>>>> and utils which I don't think warrant another directory level. >>>>>>> Should jdk10/consol-proto build out of t he box or are there any known >>>>>>> issues? I'd like to give it a tray on AIX and Linux/ppc64 but if there >>>>>>> are any known, generic problems I'll wait until they get fixed. >>>>>> Yes, please try it. I have put a lot of work into maintaining a set of >>>>>> patches and scripts to keep the generated consolidated repo working and >>>>>> (near) equivalent with the current forest. You can review those changes >>>> in >>>>>> the prototype forest if you like. >>>>>> >>>>> I cloned http://hg.openjdk.java.net/jdk10/consol-proto and built AIX. >>>> Build >>>>> runs fine. >>>>> >>>> Hi Thomas, >>>> >>>> thanks for checking the AIX build. >>>> >>>>> However, I found cloning the repository painfully slow. >>>>> >>>>> On my Linux box clone took ~90 minutes. On Windows, I could not >>>> successfully >>>>> clone, as cygwin mercurial did hit timeouts. I really hope this is only >>>>> temporary and will improve? >>>>> >>>> I think you should ask your company and/or Internet provider :) >>>> >>>> The new, consolidated repository is about 1.6GB in size (i.e. the size >>>> of .hg) and the cloning speed is actually pretty much proportional to >>>> the time you need to download this amount of data. >>>> >>>> When using our http-proxy I measured a download speed of about 350 >>>> KB/s. The calculation is quite simple: >>>> >>>> 1600000 KB / 350 KB/s = 4571 s / 60 = 76 min :( >>>> >>>> The actual cloning speed was slightly faster: >>>> >>>> $ time hg clone http://hg.openjdk.java.net/jdk10/consol-proto >>>> jdk10-cons-proto >>>> requesting all changes >>>> adding changesets >>>> adding manifests >>>> adding file changes >>>> added 46937 changesets with 397578 changes to 162338 files >>>> updating to branch default >>>> 57067 files updated, 0 files merged, 0 files removed, 0 files >>>> unresolved >>>> >>>> real 38m37.424s >>>> user 5m46.620s >>>> sys 0m33.976s >>>> >>>> which is probably because the 1.6 GB from the .hg repo may be >>>> compressed for the transport. >>>> >>>> Without proxy (i.e. 'transparent proxy') the average download speed is >>>> about 150 KB/s. I think this pretty much explains the ~90 minutes. >>>> >>>> I doubt that these poor download speeds are caused by >>>> hg.openjdk.java.net because then it would be the same for the proxy >>>> vs. non-proxy case. Nevertheless it would be interesting to see what >>>> amount of data hg.openjdk.java.net can actually serve to Europe. So if >>>> somebody with a decent Internet connection can share his experience, >>>> that would be interesting. >>>> >>>> >>> I'm on cable, with a download speed of 128Mbit. Cloning the new repo still >>> took 39min. That was on Linux, with SSDs. >> I'm in Switzerland, get 85Mbps according to fast.com and it took 42min to clone the new repo. >> >> -Doug >> >>> Best Regards, Thomas >>> >>> >>>> Regards, >>>> Volker >>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>>> /Erik >>>>>> >>>>>>> Thank you and best regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Fri, Sep 1, 2017 at 8:36 PM, joe darcy >>>> wrote: >>>>>>>> On 8/25/2017 1:52 PM, joe darcy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> A follow-up to the most recent update [1] on the JDK 10 repo >>>>>>>>> consolidation >>>>>>>>> efforts, September 2017 is almost upon us and that month remains the >>>>>>>>> target >>>>>>>>> to implement the repo consolidation. >>>>>>>>> >>>>>>>>> First, a third generation prototype having tags from both JDK 9 and >>>> JDK >>>>>>>>> 10 >>>>>>>>> will be published in the near future. >>>>>>>>> >>>>>>>> [snip] >>>>>>>> >>>>>>>> Third generation prototype with tags from JDK 9 and JDK 10 available >>>> for >>>>>>>> browsing at: >>>>>>>> >>>>>>>> http://hg.openjdk.java.net/jdk10/consol-proto/tags >>>>>>>> >>>>>>>> Please sent comments by Wednesday, September 6. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> -Joe From dalibor.topic at oracle.com Tue Sep 12 10:04:59 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 12 Sep 2017 12:04:59 +0200 Subject: [RFR]: 8187004: No valid toolchains defined for BSD In-Reply-To: <20170906043934.GB78629@misty.eyesbeyond.com> References: <550da30a-2e50-1589-62a2-e22bdf33edd2@physik.fu-berlin.de> <772e82a3-5314-5ae9-fc16-dd13dcfb6306@oracle.com> <897f432c-9457-1af9-688f-5f21c7b83d2c@oracle.com> <20170906043934.GB78629@misty.eyesbeyond.com> Message-ID: On 06.09.2017 06:39, Greg Lewis wrote: > This is accurate. We haven't attempted to pass the JCK for any port more > recent than Java 5 IIRC. At that point we did get a port that had passed, > but that required a lot of work which was sponsored at the time by the > FreeBSD Foundation. I'm not aware of anyone attempting it since. [snip] >> One of the conditions for getting a port into JDK mainline has been that >> it should actually pass the JCK for the current version. I think that's >> a low enough bar that should remain in place for JDK 9 and beyond. > > FWIW, I agree that is a completely reasonable bar to meet. Unfortunately > with the lack of time of the people involved it has been difficult to meet > this. I expect this will again require a funded effort to again have > someone be able to devote enough time to actually meet this bar. The > points below only serve to reinforce that. In "funded effort" I'm > including making it part of somebodies paid job to get the port passing > the JCK and ensure it continues to do so as needed. Thanks, Greg. I hope that you'll be able to either find an organization willing to sponsor/fund the effort or suitable volunteers, or, ideally, both. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From david.holmes at oracle.com Wed Sep 13 09:33:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Sep 2017 19:33:18 +1000 Subject: Maximum number of warnings allowed? Message-ID: I'm building with --disable-warnings-as-errors but the build still fails: 1 error 100 warnings CompileJavaModules.gmk:623: recipe for target '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' failed make[3]: *** [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] Error 1 make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed make[2]: *** [java.datatransfer-java] Error 1 Is there a maximum number of warnings allowed before it's considered an error? Could this be coming from (s)javac? (The warnings are Java related). Thanks, David From david.holmes at oracle.com Wed Sep 13 10:30:18 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Sep 2017 20:30:18 +1000 Subject: Maximum number of warnings allowed? In-Reply-To: References: Message-ID: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> On 13/09/2017 7:33 PM, David Holmes wrote: > I'm building with --disable-warnings-as-errors but the build still fails: > > 1 error > 100 warnings > CompileJavaModules.gmk:623: recipe for target > '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' > failed > make[3]: *** > [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] > Error 1 > make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed > make[2]: *** [java.datatransfer-java] Error 1 > > Is there a maximum number of warnings allowed before it's considered an > error? Could this be coming from (s)javac? (The warnings are Java related). I was told about -Xmaxwarns for javac and I bumped it to 1000 but it didn't help much: 1 error 138 warnings ... I finally spotted this in the log: error: warnings found and -Werror specified From the make-support/failure-log I see -Werror in the javac command line. Obviously it isn't adhering to --disable-warnings-as-errors! :( David > Thanks, > David From maurizio.cimadamore at oracle.com Wed Sep 13 11:48:09 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 13 Sep 2017 12:48:09 +0100 Subject: Maximum number of warnings allowed? In-Reply-To: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> References: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> Message-ID: Hi David, -Xmaxwarns controls how many warnings can be emitted - the default is 100, which means after 100 warnings the warning output will be omitted. There are similar options to limit errors and notes. That said, changing these limits does not affect the 'treat the warning as errors' policy - which is controlled by a separate flag, namely -Werror. In 'make/common/SetupJavaCmpilers.gmk' there are these lines: # If warnings needs to be non-fatal for testing purposes use a command like: # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" JAVAC_WARNINGS := -Xlint:all -Werror So, the Werror flag doesn't seem controlled by the configuration-wide 'disable-warnings-as-errors' - which means you probably have to edit that makefile and remove the Werror flag. Cheers Maurizio On 13/09/17 11:30, David Holmes wrote: > On 13/09/2017 7:33 PM, David Holmes wrote: >> I'm building with --disable-warnings-as-errors but the build still >> fails: >> >> 1 error >> 100 warnings >> CompileJavaModules.gmk:623: recipe for target >> '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' >> failed >> make[3]: *** >> [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] >> Error 1 >> make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed >> make[2]: *** [java.datatransfer-java] Error 1 >> >> Is there a maximum number of warnings allowed before it's considered >> an error? Could this be coming from (s)javac? (The warnings are Java >> related). > > I was told about -Xmaxwarns for javac and I bumped it to 1000 but it > didn't help much: > > 1 error > 138 warnings > ... > > I finally spotted this in the log: > > error: warnings found and -Werror specified > > From the make-support/failure-log I see -Werror in the javac command > line. Obviously it isn't adhering to --disable-warnings-as-errors! :( > > David > >> Thanks, >> David From david.holmes at oracle.com Wed Sep 13 12:24:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Sep 2017 22:24:51 +1000 Subject: Maximum number of warnings allowed? In-Reply-To: References: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> Message-ID: <684a0f31-7cc7-568f-0f33-2e3127b7af8f@oracle.com> Hi Maurizio, On 13/09/2017 9:48 PM, Maurizio Cimadamore wrote: > Hi David, > -Xmaxwarns controls how many warnings can be emitted - the default is > 100, which means after 100 warnings the warning output will be omitted. > There are similar options to limit errors and notes. > > That said, changing these limits does not affect the 'treat the warning > as errors' policy - which is controlled by a separate flag, namely -Werror. > > In 'make/common/SetupJavaCmpilers.gmk' there are these lines: > > # If warnings needs to be non-fatal for testing purposes use a command > like: > # make JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000" > JAVAC_WARNINGS := -Xlint:all -Werror > > > So, the Werror flag doesn't seem controlled by the configuration-wide > 'disable-warnings-as-errors' - which means you probably have to edit > that makefile and remove the Werror flag. Yeah just found that too :) At least I can now do "make images JAVAC_WARNINGS="-Xlint:all" to kill the -Werror. Thanks, David > Cheers > Maurizio > > > On 13/09/17 11:30, David Holmes wrote: >> On 13/09/2017 7:33 PM, David Holmes wrote: >>> I'm building with --disable-warnings-as-errors but the build still >>> fails: >>> >>> 1 error >>> 100 warnings >>> CompileJavaModules.gmk:623: recipe for target >>> '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' >>> failed >>> make[3]: *** >>> [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] >>> Error 1 >>> make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed >>> make[2]: *** [java.datatransfer-java] Error 1 >>> >>> Is there a maximum number of warnings allowed before it's considered >>> an error? Could this be coming from (s)javac? (The warnings are Java >>> related). >> >> I was told about -Xmaxwarns for javac and I bumped it to 1000 but it >> didn't help much: >> >> 1 error >> 138 warnings >> ... >> >> I finally spotted this in the log: >> >> error: warnings found and -Werror specified >> >> From the make-support/failure-log I see -Werror in the javac command >> line. Obviously it isn't adhering to --disable-warnings-as-errors! :( >> >> David >> >>> Thanks, >>> David > From magnus.ihse.bursie at oracle.com Wed Sep 13 13:41:24 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 13 Sep 2017 15:41:24 +0200 Subject: Maximum number of warnings allowed? In-Reply-To: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> References: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> Message-ID: <4fade3f4-4631-0d07-4f4d-3f0f014f4661@oracle.com> On 2017-09-13 12:30, David Holmes wrote: > On 13/09/2017 7:33 PM, David Holmes wrote: >> I'm building with --disable-warnings-as-errors but the build still >> fails: >> >> 1 error >> 100 warnings >> CompileJavaModules.gmk:623: recipe for target >> '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' >> failed >> make[3]: *** >> [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] >> Error 1 >> make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed >> make[2]: *** [java.datatransfer-java] Error 1 >> >> Is there a maximum number of warnings allowed before it's considered >> an error? Could this be coming from (s)javac? (The warnings are Java >> related). > > I was told about -Xmaxwarns for javac and I bumped it to 1000 but it > didn't help much: > > 1 error > 138 warnings > ... > > I finally spotted this in the log: > > error: warnings found and -Werror specified > > From the make-support/failure-log I see -Werror in the javac command > line. Obviously it isn't adhering to --disable-warnings-as-errors! :( We've stumbled across this before. It's obviously not what one would expect. Could you open a bug for it? /Magnus From david.holmes at oracle.com Wed Sep 13 21:49:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Sep 2017 07:49:43 +1000 Subject: Maximum number of warnings allowed? In-Reply-To: <4fade3f4-4631-0d07-4f4d-3f0f014f4661@oracle.com> References: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> <4fade3f4-4631-0d07-4f4d-3f0f014f4661@oracle.com> Message-ID: <03217ac2-e5e2-3818-9e2f-0a3f95e6cfb5@oracle.com> On 13/09/2017 11:41 PM, Magnus Ihse Bursie wrote: > On 2017-09-13 12:30, David Holmes wrote: >> On 13/09/2017 7:33 PM, David Holmes wrote: >>> I'm building with --disable-warnings-as-errors but the build still >>> fails: >>> >>> 1 error >>> 100 warnings >>> CompileJavaModules.gmk:623: recipe for target >>> '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' >>> failed >>> make[3]: *** >>> [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] >>> Error 1 >>> make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed >>> make[2]: *** [java.datatransfer-java] Error 1 >>> >>> Is there a maximum number of warnings allowed before it's considered >>> an error? Could this be coming from (s)javac? (The warnings are Java >>> related). >> >> I was told about -Xmaxwarns for javac and I bumped it to 1000 but it >> didn't help much: >> >> 1 error >> 138 warnings >> ... >> >> I finally spotted this in the log: >> >> error: warnings found and -Werror specified >> >> From the make-support/failure-log I see -Werror in the javac command >> line. Obviously it isn't adhering to --disable-warnings-as-errors! :( > We've stumbled across this before. It's obviously not what one would > expect. Could you open a bug for it? https://bugs.openjdk.java.net/browse/JDK-8187520 Cheers, David > /Magnus > From magnus.ihse.bursie at oracle.com Thu Sep 14 07:44:39 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Sep 2017 09:44:39 +0200 Subject: Maximum number of warnings allowed? In-Reply-To: <03217ac2-e5e2-3818-9e2f-0a3f95e6cfb5@oracle.com> References: <66fd45c0-9c8c-7b2f-4956-6a80f8f90a8f@oracle.com> <4fade3f4-4631-0d07-4f4d-3f0f014f4661@oracle.com> <03217ac2-e5e2-3818-9e2f-0a3f95e6cfb5@oracle.com> Message-ID: On 2017-09-13 23:49, David Holmes wrote: > On 13/09/2017 11:41 PM, Magnus Ihse Bursie wrote: >> On 2017-09-13 12:30, David Holmes wrote:On 13/09/2017 7:33 PM, David >> Holmes wrote: >>>> I'm building with --disable-warnings-as-errors but the build still >>>> fails: >>>> >>>> 1 error >>>> 100 warnings >>>> CompileJavaModules.gmk:623: recipe for target >>>> '/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch' >>>> failed >>>> make[3]: *** >>>> [/export/users/dh198349/valhalla/valhalla-nestmates/build/linux-x64-open-debug/jdk/modules/java.datatransfer/_the.java.datatransfer_batch] >>>> Error 1 >>>> make/Main.gmk:198: recipe for target 'java.datatransfer-java' failed >>>> make[2]: *** [java.datatransfer-java] Error 1 >>>> >>>> Is there a maximum number of warnings allowed before it's >>>> considered an error? Could this be coming from (s)javac? (The >>>> warnings are Java related). >>> >>> I was told about -Xmaxwarns for javac and I bumped it to 1000 but it >>> didn't help much: >>> >>> 1 error >>> 138 warnings >>> ... >>> >>> I finally spotted this in the log: >>> >>> error: warnings found and -Werror specified >>> >>> From the make-support/failure-log I see -Werror in the javac command >>> line. Obviously it isn't adhering to --disable-warnings-as-errors! :( >> We've stumbled across this before. It's obviously not what one would >> expect. Could you open a bug for it? > > https://bugs.openjdk.java.net/browse/JDK-8187520 Thank you! /Magnus > > Cheers, > David > >> /Magnus >> From magnus.ihse.bursie at oracle.com Thu Sep 14 12:25:27 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Sep 2017 14:25:27 +0200 Subject: JDK-8187542 Remove superfluous *_TOPDIR variables Message-ID: After the forest consolidation, the makefiles contains a number of _TOPDIR variables, that are no longer used. They should be cleaned out. The intention is to push this to the consolidated forest, once it opens. Bug: https://bugs.openjdk.java.net/browse/JDK-8187542 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8187542-remove-extra-TOPDIR-variables/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Sep 14 16:05:14 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Sep 2017 09:05:14 -0700 Subject: JDK-8187542 Remove superfluous *_TOPDIR variables In-Reply-To: References: Message-ID: Looks good! /Erik On 2017-09-14 05:25, Magnus Ihse Bursie wrote: > After the forest consolidation, the makefiles contains a number of > _TOPDIR variables, that are no longer used. They should be > cleaned out. > > The intention is to push this to the consolidated forest, once it opens. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187542 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8187542-remove-extra-TOPDIR-variables/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Thu Sep 14 20:44:31 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Sep 2017 22:44:31 +0200 Subject: RFR: JDK-8187543 Replace SRC_ROOT with TOPDIR Message-ID: <486928c8-49cd-dcc6-213b-1dad9b900f20@oracle.com> Due to historical reasons, we have had an "alias" SRC_ROOT that contains the same value as TOPDIR. We should remove the former and replace it with the latter. The intention is to push this to the consolidated forest, once it opens. Bug: https://bugs.openjdk.java.net/browse/JDK-8187543 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8187543-replace-SRC_ROOT-with-TOPDIR/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Thu Sep 14 21:14:33 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Sep 2017 23:14:33 +0200 Subject: RFR: JDK-8187544 Replace BUILD_OUTPUT and OUTPUT_ROOT with OUTPUTDIR. Message-ID: <2346df1b-2f85-7b5a-d420-29bad8887ff6@oracle.com> Due to historical reasons, we have had two variables that points to the output directory (e.g. "$topdir/build/linux-x64"), one named BUILD_OUTPUT and one named OUTPUT_ROOT. First of all, these two should be unified into one. Second, it should be renamed OUTPUTDIR to better align with other variables such as TOPDIR, and the various *_OUTPUTDIR variables we already have. The only non-trivial part of this patch was the handling in bootcycle-spec.gmk.in. I've verified that I can still build bootcycle-images. Bug: https://bugs.openjdk.java.net/browse/JDK-8187544 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8187544-introduce-OUTPUTDIR/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Sep 14 21:18:11 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Sep 2017 14:18:11 -0700 Subject: RFR: JDK-8187543 Replace SRC_ROOT with TOPDIR In-Reply-To: <486928c8-49cd-dcc6-213b-1dad9b900f20@oracle.com> References: <486928c8-49cd-dcc6-213b-1dad9b900f20@oracle.com> Message-ID: <890deed7-0eb7-ae48-5bd4-7225d91332d7@oracle.com> Looks good, nice cleanup. /Erik On 2017-09-14 13:44, Magnus Ihse Bursie wrote: > Due to historical reasons, we have had an "alias" SRC_ROOT that > contains the same value as TOPDIR. We should remove the former and > replace it with the latter. > > The intention is to push this to the consolidated forest, once it opens. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187543 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8187543-replace-SRC_ROOT-with-TOPDIR/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Thu Sep 14 22:25:14 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 14 Sep 2017 15:25:14 -0700 Subject: RFR: JDK-8187544 Replace BUILD_OUTPUT and OUTPUT_ROOT with OUTPUTDIR. In-Reply-To: <2346df1b-2f85-7b5a-d420-29bad8887ff6@oracle.com> References: <2346df1b-2f85-7b5a-d420-29bad8887ff6@oracle.com> Message-ID: <20db72c7-ed58-ccec-7af6-e83d4679c419@oracle.com> Also a good cleanup. In flags.m4, perhaps replace with SUPPORT_OUTPUTDIR? /Erik On 2017-09-14 14:14, Magnus Ihse Bursie wrote: > Due to historical reasons, we have had two variables that points to > the output directory (e.g. "$topdir/build/linux-x64"), one named > BUILD_OUTPUT and one named OUTPUT_ROOT. > > First of all, these two should be unified into one. > > Second, it should be renamed OUTPUTDIR to better align with other > variables such as TOPDIR, and the various *_OUTPUTDIR variables we > already have. > > The only non-trivial part of this patch was the handling in > bootcycle-spec.gmk.in. I've verified that I can still build > bootcycle-images. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187544 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8187544-introduce-OUTPUTDIR/webrev.01 > > /Magnus > From magnus.ihse.bursie at oracle.com Fri Sep 15 11:35:18 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Sep 2017 13:35:18 +0200 Subject: RFR: JDK-8187544 Replace BUILD_OUTPUT and OUTPUT_ROOT with OUTPUTDIR. In-Reply-To: <20db72c7-ed58-ccec-7af6-e83d4679c419@oracle.com> References: <2346df1b-2f85-7b5a-d420-29bad8887ff6@oracle.com> <20db72c7-ed58-ccec-7af6-e83d4679c419@oracle.com> Message-ID: <4651fab2-c048-76c0-73e6-45074d243610@oracle.com> On 2017-09-15 00:25, Erik Joelsson wrote: > Also a good cleanup. > > In flags.m4, perhaps replace with SUPPORT_OUTPUTDIR? Sure, I'll fix. (Not posting new webrev.) /Magnus > > /Erik > > > On 2017-09-14 14:14, Magnus Ihse Bursie wrote: >> Due to historical reasons, we have had two variables that points to >> the output directory (e.g. "$topdir/build/linux-x64"), one named >> BUILD_OUTPUT and one named OUTPUT_ROOT. >> >> First of all, these two should be unified into one. >> >> Second, it should be renamed OUTPUTDIR to better align with other >> variables such as TOPDIR, and the various *_OUTPUTDIR variables we >> already have. >> >> The only non-trivial part of this patch was the handling in >> bootcycle-spec.gmk.in. I've verified that I can still build >> bootcycle-images. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187544 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8187544-introduce-OUTPUTDIR/webrev.01 >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Sep 15 12:20:01 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Sep 2017 14:20:01 +0200 Subject: RFR: JDK-8176099 --with-build-jdk and --with-boot-jdk not working with JDK 10 Message-ID: The code in configure that validates build and boot JDK does not accept the JDK 10 version string. For build JDK, the version string must exactly match 10 (if built automatically, it will match the current source exactly). For boot JDK I just added JDK 10 as an additional allowed version, but did not (at this point) block usage of JDK 8. While it is recommended to use version N-1 to build JDK version N, I don't see a good reason at this time to block, at configure time, the use of JDK 8 to build JDK 10. The intention is to push this once the consolidated forest is open. Bug: https://bugs.openjdk.java.net/browse/JDK-8176099 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8176099-fix-boot-build-jdk-for-jdk10/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Sep 15 12:39:25 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Sep 2017 14:39:25 +0200 Subject: RFR: JDK-8176467 --with-cacerts-file should fail during configure if file does not exist Message-ID: <0bf9ea5b-9fa0-130b-491a-284aa5daf9e3@oracle.com> Running bash configure --with-cacerts-file=non-existing-file currently gets past configure but fails during build. Configure should tighten the check. The intention is to push this once the consolidated repo opens. Bug: https://bugs.openjdk.java.net/browse/JDK-8176467 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8176467-check-with-cacerts-file-argument/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Sep 15 12:59:17 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 15 Sep 2017 14:59:17 +0200 Subject: RFR: JDK-8180897 Explicit --with-jtreg path not expanded Message-ID: From the bug report: When configuring with --with-jtreg=, the provided path doesn't appear to be expanded. Thus, my use of --with-jtreg=~/devtools/jtreg fails and reports "~/devtools/jtreg" doesn't exist. The intention is to push this once the consolidated forest opens. Bug: https://bugs.openjdk.java.net/browse/JDK-8180897-handle-relative-jtreg-path Patch inline: diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4 --- a/make/autoconf/toolchain.m4 +++ b/make/autoconf/toolchain.m4 @@ -935,6 +935,7 @@ elif test "x$with_jtreg" != xyes && test "x$with_jtreg" != x; then # An explicit path is specified, use it. JT_HOME="$with_jtreg" + BASIC_FIXUP_PATH([JT_HOME]) if test ! -d "$JT_HOME"; then AC_MSG_ERROR([jtreg home directory from --with-jtreg=$with_jtreg does not exist]) fi /Magnus From erik.joelsson at oracle.com Fri Sep 15 15:06:36 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Sep 2017 08:06:36 -0700 Subject: RFR: JDK-8176099 --with-build-jdk and --with-boot-jdk not working with JDK 10 In-Reply-To: References: Message-ID: <8b41ed2a-926f-1ac1-f1e3-71ba70c6c4b2@oracle.com> Looks good! /Erik On 2017-09-15 05:20, Magnus Ihse Bursie wrote: > The code in configure that validates build and boot JDK does not > accept the JDK 10 version string. > > For build JDK, the version string must exactly match 10 (if built > automatically, it will match the current source exactly). For boot JDK > I just added JDK 10 as an additional allowed version, but did not (at > this point) block usage of JDK 8. While it is recommended to use > version N-1 to build JDK version N, I don't see a good reason at this > time to block, at configure time, the use of JDK 8 to build JDK 10. > > The intention is to push this once the consolidated forest is open. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176099 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8176099-fix-boot-build-jdk-for-jdk10/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Fri Sep 15 15:07:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Sep 2017 08:07:22 -0700 Subject: RFR: JDK-8176467 --with-cacerts-file should fail during configure if file does not exist In-Reply-To: <0bf9ea5b-9fa0-130b-491a-284aa5daf9e3@oracle.com> References: <0bf9ea5b-9fa0-130b-491a-284aa5daf9e3@oracle.com> Message-ID: <397f9e91-f077-57ad-e306-113c5c4f3e06@oracle.com> Looks good. /Erik On 2017-09-15 05:39, Magnus Ihse Bursie wrote: > Running bash configure --with-cacerts-file=non-existing-file currently > gets past configure but fails during build. Configure should tighten > the check. > > The intention is to push this once the consolidated repo opens. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176467 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8176467-check-with-cacerts-file-argument/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Sep 15 15:07:45 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 15 Sep 2017 08:07:45 -0700 Subject: RFR: JDK-8180897 Explicit --with-jtreg path not expanded In-Reply-To: References: Message-ID: <9554894f-d338-cc82-fc06-f118aad6175c@oracle.com> Looks good. /Erik On 2017-09-15 05:59, Magnus Ihse Bursie wrote: > From the bug report: > > When configuring with --with-jtreg=, the provided path doesn't > appear to be expanded. Thus, my use of --with-jtreg=~/devtools/jtreg > fails and reports "~/devtools/jtreg" doesn't exist. > > The intention is to push this once the consolidated forest opens. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8180897-handle-relative-jtreg-path > Patch inline: > diff --git a/make/autoconf/toolchain.m4 b/make/autoconf/toolchain.m4 > --- a/make/autoconf/toolchain.m4 > +++ b/make/autoconf/toolchain.m4 > @@ -935,6 +935,7 @@ > ?? elif test "x$with_jtreg" != xyes && test "x$with_jtreg" != x; then > ???? # An explicit path is specified, use it. > ???? JT_HOME="$with_jtreg" > +??? BASIC_FIXUP_PATH([JT_HOME]) > ???? if test ! -d "$JT_HOME"; then > ?????? AC_MSG_ERROR([jtreg home directory from > --with-jtreg=$with_jtreg does not exist]) > ???? fi > > /Magnus From erik.joelsson at oracle.com Tue Sep 19 00:53:34 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 18 Sep 2017 17:53:34 -0700 Subject: RFR: JDK-8187642: The consolidated repo test makefile disables CONCURRENCY setting to jtreg Message-ID: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> When invoking the test/Makefile using the jtreg_tests target in the consolidated repo, the CONCURRENCY variable gets overridden with an empty value. This was introduced with my changes to handle the new test roots. I believe the proper fix is to surround the override of CONCURRENCY with a conditional. Bug: https://bugs.openjdk.java.net/browse/JDK-8187642 Webrev: http://cr.openjdk.java.net/~erikj/8187642/webrev.01/ /Erik From joe.darcy at oracle.com Tue Sep 19 01:02:48 2017 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 18 Sep 2017 18:02:48 -0700 Subject: RFR: JDK-8187642: The consolidated repo test makefile disables CONCURRENCY setting to jtreg In-Reply-To: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> References: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> Message-ID: Looks fine Erik; thanks, -Joe On 9/18/2017 5:53 PM, Erik Joelsson wrote: > When invoking the test/Makefile using the jtreg_tests target in the > consolidated repo, the CONCURRENCY variable gets overridden with an > empty value. This was introduced with my changes to handle the new > test roots. I believe the proper fix is to surround the override of > CONCURRENCY with a conditional. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187642 > > Webrev: http://cr.openjdk.java.net/~erikj/8187642/webrev.01/ > > /Erik > From david.holmes at oracle.com Tue Sep 19 01:05:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Sep 2017 11:05:15 +1000 Subject: RFR: JDK-8187642: The consolidated repo test makefile disables CONCURRENCY setting to jtreg In-Reply-To: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> References: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> Message-ID: Hi Erik, On 19/09/2017 10:53 AM, Erik Joelsson wrote: > When invoking the test/Makefile using the jtreg_tests target in the > consolidated repo, the CONCURRENCY variable gets overridden with an > empty value. This was introduced with my changes to handle the new test > roots. I believe the proper fix is to surround the override of > CONCURRENCY with a conditional. Why isn't this handled by the preceding block: 51 ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) 52 # JTReg cannot handle more than 50 in concurrency 53 JDK_TEST_JOBS=50 54 else 55 JDK_TEST_JOBS=$(JOBS) 56 endif 57 else 58 JDK_TEST_JOBS=$(TEST_JOBS) 59 endif David > Bug: https://bugs.openjdk.java.net/browse/JDK-8187642 > > Webrev: http://cr.openjdk.java.net/~erikj/8187642/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Tue Sep 19 10:33:22 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Sep 2017 12:33:22 +0200 Subject: RFR: JDK-8187642: The consolidated repo test makefile disables CONCURRENCY setting to jtreg In-Reply-To: References: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> Message-ID: <54a02db6-e033-c9ed-0b1e-bba7e8a120d9@oracle.com> On 2017-09-19 03:05, David Holmes wrote: > Hi Erik, > > On 19/09/2017 10:53 AM, Erik Joelsson wrote: >> When invoking the test/Makefile using the jtreg_tests target in the >> consolidated repo, the CONCURRENCY variable gets overridden with an >> empty value. This was introduced with my changes to handle the new >> test roots. I believe the proper fix is to surround the override of >> CONCURRENCY with a conditional. > > Why isn't this handled by the preceding block: > > 51 ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) > 52 # JTReg cannot handle more than 50 in concurrency > 53 JDK_TEST_JOBS=50 > 54 else > 55 JDK_TEST_JOBS=$(JOBS) > 56 endif > 57 else > 58 JDK_TEST_JOBS=$(TEST_JOBS) > 59 endif > At this point, it's probably not worth the effort to clean up the logic in test/Makefile. /Magnus > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187642 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8187642/webrev.01/ >> >> /Erik >> From magnus.ihse.bursie at oracle.com Tue Sep 19 12:24:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 19 Sep 2017 14:24:38 +0200 Subject: RFR: JDK-8187672 RunTest displays broken output if jtreg fails completely Message-ID: If jtreg fails to run completely, and does not even create a text/stats.txt file, then the parsing in RunTests.gmk breaks down. This will be pushed to jdk10 once the combined forest opens up. Bug: https://bugs.openjdk.java.net/browse/JDK-8187672 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8187672-fix-parsing-for-jtreg-without-stats-file/webrev.01 /Magnus From erik.helin at oracle.com Tue Sep 19 13:37:59 2017 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 19 Sep 2017 15:37:59 +0200 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files Message-ID: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> Hi all, with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the potential usage of maybe uninitialized memory in src/hotspot/cpu/x86/assembler_x86.cpp and in src/hotspot/cpu/x86/interp_masm_x86.cpp. The problems arises from the class RelocationHolder in src/hotspot/share/code/relocInfo.hpp which has the private fields: enum { _relocbuf_size = 5 }; void* _relocbuf[ _relocbuf_size ]; and the default constructor for RelocationHolder does not initialize the elements of _relocbuf. I _think_ this is an optimization, RelocationHolder is used *a lot* and setting the elements of RelocationHolder::_relocbuf to NULL (or some other value) in the default constructor might result in a performance penalty. Have a look in build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles and you will see that RelocationHolder is used all over the place :) AFAICS all users of RelocationHolder::_relocbuf take care to not use uninitialized memory, which means that this warning is wrong, so I suggest we disable the warning -Wmaybe-uninitialized for src/hotspot/cpu/x86/assembler_x86.cpp. The problem continues because the class Address in src/hotspot/cpu/x86/assembler_x86.hpp has a private field, `RelocationHolder _rspec;` and the default constructor for Address does not initialize _rspec._relocbuf (most likely for performance reasons). The class Address also has a default copy constructor, which will copy all the elements of _rspec._relocbuf, which will result in a read of uninitialized memory. However, this is a benign usage of uninitialized memory, since we take no action based on the content of the uninitialized memory (it is just copied byte for byte). So, in this case too, I suggest we disable the warning -Wuninitialized for src/hotspot/cpu/x86/assembler_x86.hpp. What do you think? Patch: http://cr.openjdk.java.net/~ehelin/8187676/00/ --- old/make/hotspot/lib/JvmOverrideFiles.gmk 2017-09-19 15:11:45.036108983 +0200 +++ new/make/hotspot/lib/JvmOverrideFiles.gmk 2017-09-19 15:11:44.692107277 +0200 @@ -32,6 +32,8 @@ ifeq ($(TOOLCHAIN_TYPE), gcc) BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments + BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized + BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized endif ifeq ($(OPENJDK_TARGET_OS), linux) Issue: https://bugs.openjdk.java.net/browse/JDK-8187676 Testing: - Compiles with: - gcc 7.1.1 and glibc 2.25 on Fedora 26 - gcc 4.9.2 and glibc 2.12 on OEL 6.4 - JPRT Thanks, Erik From kim.barrett at oracle.com Tue Sep 19 13:55:59 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 19 Sep 2017 09:55:59 -0400 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> Message-ID: <0C253EA0-47D4-492E-B453-50E187D3EB82@oracle.com> > On Sep 19, 2017, at 9:37 AM, Erik Helin wrote: > > Hi all, > > with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the potential usage of maybe uninitialized memory in src/hotspot/cpu/x86/assembler_x86.cpp and in src/hotspot/cpu/x86/interp_masm_x86.cpp. > > The problems arises from the class RelocationHolder in src/hotspot/share/code/relocInfo.hpp which has the private fields: > enum { _relocbuf_size = 5 }; > void* _relocbuf[ _relocbuf_size ]; > > and the default constructor for RelocationHolder does not initialize the elements of _relocbuf. I _think_ this is an optimization, RelocationHolder is used *a lot* and setting the elements of RelocationHolder::_relocbuf to NULL (or some other value) in the default constructor might result in a performance penalty. Have a look in build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles and you will see that RelocationHolder is used all over the place :) > > AFAICS all users of RelocationHolder::_relocbuf take care to not use uninitialized memory, which means that this warning is wrong, so I suggest we disable the warning -Wmaybe-uninitialized for src/hotspot/cpu/x86/assembler_x86.cpp. Rahul Raghavan is working on a fix for JDK-8160404 that is likely relevant. I have a patch from him for preliminary review. From erik.helin at oracle.com Tue Sep 19 14:46:44 2017 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 19 Sep 2017 16:46:44 +0200 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <0C253EA0-47D4-492E-B453-50E187D3EB82@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> <0C253EA0-47D4-492E-B453-50E187D3EB82@oracle.com> Message-ID: On 09/19/2017 03:55 PM, Kim Barrett wrote: >> On Sep 19, 2017, at 9:37 AM, Erik Helin wrote: >> >> Hi all, >> >> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the potential usage of maybe uninitialized memory in src/hotspot/cpu/x86/assembler_x86.cpp and in src/hotspot/cpu/x86/interp_masm_x86.cpp. >> >> The problems arises from the class RelocationHolder in src/hotspot/share/code/relocInfo.hpp which has the private fields: >> enum { _relocbuf_size = 5 }; >> void* _relocbuf[ _relocbuf_size ]; >> >> and the default constructor for RelocationHolder does not initialize the elements of _relocbuf. I _think_ this is an optimization, RelocationHolder is used *a lot* and setting the elements of RelocationHolder::_relocbuf to NULL (or some other value) in the default constructor might result in a performance penalty. Have a look in build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles and you will see that RelocationHolder is used all over the place :) >> >> AFAICS all users of RelocationHolder::_relocbuf take care to not use uninitialized memory, which means that this warning is wrong, so I suggest we disable the warning -Wmaybe-uninitialized for src/hotspot/cpu/x86/assembler_x86.cpp. > > Rahul Raghavan is working on a fix for JDK-8160404 that is likely relevant. > I have a patch from him for preliminary review. I had a look at https://bugs.openjdk.java.net/browse/JDK-8160404 and I'm not sure that the patch ensures that the elements of _relocbuf are initialized (could very well be, I'm not particularly familiar with this code). Since JDK-8160404 seems to be under development, maybe we should take in this patch that disables the warnings and then the patch for JDK-8160404 can enable the warnings again (if possible)? Thanks, Erik From erik.joelsson at oracle.com Tue Sep 19 15:31:01 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Sep 2017 08:31:01 -0700 Subject: RFR: JDK-8187642: The consolidated repo test makefile disables CONCURRENCY setting to jtreg In-Reply-To: <54a02db6-e033-c9ed-0b1e-bba7e8a120d9@oracle.com> References: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> <54a02db6-e033-c9ed-0b1e-bba7e8a120d9@oracle.com> Message-ID: <5ff50768-b8cc-63dd-02c9-13d9473258e3@oracle.com> Hello, On 2017-09-19 03:33, Magnus Ihse Bursie wrote: > On 2017-09-19 03:05, David Holmes wrote: >> Hi Erik, >> >> On 19/09/2017 10:53 AM, Erik Joelsson wrote: >>> When invoking the test/Makefile using the jtreg_tests target in the >>> consolidated repo, the CONCURRENCY variable gets overridden with an >>> empty value. This was introduced with my changes to handle the new >>> test roots. I believe the proper fix is to surround the override of >>> CONCURRENCY with a conditional. >> >> Why isn't this handled by the preceding block: >> >> ? 51?? ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) >> ? 52???? # JTReg cannot handle more than 50 in concurrency >> ? 53???? JDK_TEST_JOBS=50 >> ? 54?? else >> ? 55???? JDK_TEST_JOBS=$(JOBS) >> ? 56?? endif >> ? 57 else >> ? 58?? JDK_TEST_JOBS=$(TEST_JOBS) >> ? 59 endif >> > > At this point, it's probably not worth the effort to clean up the > logic in test/Makefile. > We were in quite a hurry getting this fix in before the first post consolidation promotion so I missed your comment before pushing, David. I agree in principle that the conditional should be made once instead of inlined in four places, but since Magnus is working actively to replace these makefiles in JDK 10, I don't think it's worth spending time trying to clean up minor details when the whole thing is in such a messy state. /Erik > /Magnus > >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8187642 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8187642/webrev.01/ >>> >>> /Erik >>> > From erik.joelsson at oracle.com Tue Sep 19 15:56:57 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 19 Sep 2017 08:56:57 -0700 Subject: RFR: JDK-8187672 RunTest displays broken output if jtreg fails completely In-Reply-To: References: Message-ID: Looks good! /Erik On 2017-09-19 05:24, Magnus Ihse Bursie wrote: > If jtreg fails to run completely, and does not even create a > text/stats.txt file, then the parsing in RunTests.gmk breaks down. > > This will be pushed to jdk10 once the combined forest opens up. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187672 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8187672-fix-parsing-for-jtreg-without-stats-file/webrev.01 > > /Magnus > From tim.bell at oracle.com Tue Sep 19 16:06:17 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 19 Sep 2017 09:06:17 -0700 Subject: RFR: JDK-8187672 RunTest displays broken output if jtreg fails completely In-Reply-To: References: Message-ID: <59C14079.4080007@oracle.com> Magnus Looks good to me as well. Tim On 09/19/17 08:56, Erik Joelsson wrote: > Looks good! > > /Erik > > > On 2017-09-19 05:24, Magnus Ihse Bursie wrote: >> If jtreg fails to run completely, and does not even create a >> text/stats.txt file, then the parsing in RunTests.gmk breaks down. >> >> This will be pushed to jdk10 once the combined forest opens up. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187672 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8187672-fix-parsing-for-jtreg-without-stats-file/webrev.01 >> >> >> /Magnus From vladimir.kozlov at oracle.com Tue Sep 19 16:25:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Sep 2017 09:25:20 -0700 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> Message-ID: <4f5b0427-54bf-2b85-0a94-bb41049d2676@oracle.com> I would prefer to have general solution Rahul is working on because code is general - not only x86 is affected. Thanks, Vladimir On 9/19/17 7:59 AM, Rahul Raghavan wrote: > Hi Erik, > > Please note that this 8187676 seems to be related to 8160404. > ?? https://bugs.openjdk.java.net/browse/JDK-8160404 > ?? (RelocationHolder constructors have bugs) > > As per the latest notes comments added for 8160404-jbs, I will submit > webrev/RFR soon and will request help confirm similar issues with latest > gcc7 gets solved. > > Thanks, > Rahul > > On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote: >> Hi all, >> >> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the >> potential usage of maybe uninitialized memory in >> src/hotspot/cpu/x86/assembler_x86.cpp and in >> src/hotspot/cpu/x86/interp_masm_x86.cpp. >> >> The problems arises from the class RelocationHolder in >> src/hotspot/share/code/relocInfo.hpp which has the private fields: >> ?? enum { _relocbuf_size = 5 }; >> ?? void* _relocbuf[ _relocbuf_size ]; >> >> and the default constructor for RelocationHolder does not initialize >> the elements of _relocbuf. I _think_ this is an optimization, >> RelocationHolder is used *a lot* and setting the elements of >> RelocationHolder::_relocbuf to NULL (or some other value) in the >> default constructor might result in a performance penalty. Have a look >> in >> build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles >> and you will see that RelocationHolder is used all over the place :) >> >> AFAICS all users of RelocationHolder::_relocbuf take care to not use >> uninitialized memory, which means that this warning is wrong, so I >> suggest we disable the warning -Wmaybe-uninitialized for >> src/hotspot/cpu/x86/assembler_x86.cpp. >> >> The problem continues because the class Address in >> src/hotspot/cpu/x86/assembler_x86.hpp has a private field, >> `RelocationHolder _rspec;` and the default constructor for Address >> does not initialize _rspec._relocbuf (most likely for performance >> reasons). The class Address also has a default copy constructor, which >> will copy all the elements of _rspec._relocbuf, which will result in a >> read of uninitialized memory. However, this is a benign usage of >> uninitialized memory, since we take no action based on the content of >> the uninitialized memory (it is just copied byte for byte). >> >> So, in this case too, I suggest we disable the warning -Wuninitialized >> for src/hotspot/cpu/x86/assembler_x86.hpp. >> >> What do you think? >> >> Patch: >> http://cr.openjdk.java.net/~ehelin/8187676/00/ >> >> --- old/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >> 15:11:45.036108983 +0200 >> +++ new/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >> 15:11:44.692107277 +0200 >> @@ -32,6 +32,8 @@ >> ? ifeq ($(TOOLCHAIN_TYPE), gcc) >> ??? BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := >> -fno-var-tracking-assignments -O0 >> ??? BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := >> -fno-var-tracking-assignments >> +? BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >> +? BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized >> ? endif >> >> ? ifeq ($(OPENJDK_TARGET_OS), linux) >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8187676 >> >> Testing: >> - Compiles with: >> ?? - gcc 7.1.1 and glibc 2.25 on Fedora 26 >> ?? - gcc 4.9.2 and glibc 2.12 on OEL 6.4 >> - JPRT >> >> Thanks, >> Erik From jonathan.gibbons at oracle.com Tue Sep 19 18:14:03 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 19 Sep 2017 11:14:03 -0700 Subject: RFR: JDK-8187642: The consolidated repo test makefile disables CONCURRENCY setting to jtreg In-Reply-To: References: <2b160b55-8277-d9ab-d017-76089a7c3261@oracle.com> Message-ID: <30fa56ae-5cb4-61cf-d0d2-d7efc97ae852@oracle.com> The 50 limit was raised to 256 a long time back. -- Jon On 9/18/17 6:05 PM, David Holmes wrote: > > 51 ifeq ($(shell $(EXPR) $(JOBS) \> 50), 1) > 52 # JTReg cannot handle more than 50 in concurrency > 53 JDK_TEST_JOBS=50 > 54 else From rahul.v.raghavan at oracle.com Tue Sep 19 14:59:50 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 19 Sep 2017 20:29:50 +0530 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> Message-ID: <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> Hi Erik, Please note that this 8187676 seems to be related to 8160404. https://bugs.openjdk.java.net/browse/JDK-8160404 (RelocationHolder constructors have bugs) As per the latest notes comments added for 8160404-jbs, I will submit webrev/RFR soon and will request help confirm similar issues with latest gcc7 gets solved. Thanks, Rahul On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote: > Hi all, > > with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the > potential usage of maybe uninitialized memory in > src/hotspot/cpu/x86/assembler_x86.cpp and in > src/hotspot/cpu/x86/interp_masm_x86.cpp. > > The problems arises from the class RelocationHolder in > src/hotspot/share/code/relocInfo.hpp which has the private fields: > enum { _relocbuf_size = 5 }; > void* _relocbuf[ _relocbuf_size ]; > > and the default constructor for RelocationHolder does not initialize the > elements of _relocbuf. I _think_ this is an optimization, > RelocationHolder is used *a lot* and setting the elements of > RelocationHolder::_relocbuf to NULL (or some other value) in the default > constructor might result in a performance penalty. Have a look in > build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles > and you will see that RelocationHolder is used all over the place :) > > AFAICS all users of RelocationHolder::_relocbuf take care to not use > uninitialized memory, which means that this warning is wrong, so I > suggest we disable the warning -Wmaybe-uninitialized for > src/hotspot/cpu/x86/assembler_x86.cpp. > > The problem continues because the class Address in > src/hotspot/cpu/x86/assembler_x86.hpp has a private field, > `RelocationHolder _rspec;` and the default constructor for Address does > not initialize _rspec._relocbuf (most likely for performance reasons). > The class Address also has a default copy constructor, which will copy > all the elements of _rspec._relocbuf, which will result in a read of > uninitialized memory. However, this is a benign usage of uninitialized > memory, since we take no action based on the content of the > uninitialized memory (it is just copied byte for byte). > > So, in this case too, I suggest we disable the warning -Wuninitialized > for src/hotspot/cpu/x86/assembler_x86.hpp. > > What do you think? > > Patch: > http://cr.openjdk.java.net/~ehelin/8187676/00/ > > --- old/make/hotspot/lib/JvmOverrideFiles.gmk 2017-09-19 > 15:11:45.036108983 +0200 > +++ new/make/hotspot/lib/JvmOverrideFiles.gmk 2017-09-19 > 15:11:44.692107277 +0200 > @@ -32,6 +32,8 @@ > ifeq ($(TOOLCHAIN_TYPE), gcc) > BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments > -O0 > BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := > -fno-var-tracking-assignments > + BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized > + BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized > endif > > ifeq ($(OPENJDK_TARGET_OS), linux) > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8187676 > > Testing: > - Compiles with: > - gcc 7.1.1 and glibc 2.25 on Fedora 26 > - gcc 4.9.2 and glibc 2.12 on OEL 6.4 > - JPRT > > Thanks, > Erik From erik.joelsson at oracle.com Wed Sep 20 21:24:17 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 20 Sep 2017 14:24:17 -0700 Subject: build jdk9 from source on mac failed In-Reply-To: <0522625B-FB46-4F89-BB4D-8BB90DE992D8@linaro.org> References: <0522625B-FB46-4F89-BB4D-8BB90DE992D8@linaro.org> Message-ID: Hello Wei, Sorry for the late reply but this mail just showed up in my mail client. This error indicates that you haven't cloned all the repositories. Please try running "sh get_source.sh" in the root directory of the top repository. /Erik On 2017-08-27 06:02, wei wrote: > Hi, > I tried to build jdk9 from source code on Mac OS 10.10, and got following issue at beginning. The dependent Xcode and JDK have been installed. > I really appreciate if anyone can share the experience on building jdk9 on Mac. > > Building target 'default (exploded-image)' in configuration 'macosx-x86_64-normal-server-release' > make[2]: *** No rule to make target `java.base-gensrc-hotspot', needed by `java.base-copy-hotspot'. Stop. > make[2]: *** Waiting for unfinished jobs.... > make[3]: BuildHotspot.gmk: No such file or directory > make[3]: *** No rule to make target `BuildHotspot.gmk'. Stop. > make[2]: *** [hotspot] Error 2 > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > > > Regards! > wei From glaubitz at physik.fu-berlin.de Wed Sep 20 21:28:16 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 20 Sep 2017 23:28:16 +0200 Subject: build jdk9 from source on mac failed In-Reply-To: References: <0522625B-FB46-4F89-BB4D-8BB90DE992D8@linaro.org> Message-ID: <83f7c161-c088-acc1-6648-33da0c36df73@physik.fu-berlin.de> On 09/20/2017 11:24 PM, Erik Joelsson wrote: > Sorry for the late reply but this mail just showed up in my mail client. It also just showed up here. Looks like it just got stuck somewhere on Oracle's mail servers from what I can see in the message header. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.helin at oracle.com Thu Sep 21 09:02:06 2017 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 21 Sep 2017 11:02:06 +0200 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <4f5b0427-54bf-2b85-0a94-bb41049d2676@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> <4f5b0427-54bf-2b85-0a94-bb41049d2676@oracle.com> Message-ID: <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> Ok, lets wait for Rahul's patches. Rahul, when you post your patches, CC me and I can check if gcc 7.1.1 still complains :) Thanks, Erik On 09/19/2017 06:25 PM, Vladimir Kozlov wrote: > I would prefer to have general solution Rahul is working on because code > is general - not only x86 is affected. > > Thanks, > Vladimir > > On 9/19/17 7:59 AM, Rahul Raghavan wrote: >> Hi Erik, >> >> Please note that this 8187676 seems to be related to 8160404. >> ??? https://bugs.openjdk.java.net/browse/JDK-8160404 >> ??? (RelocationHolder constructors have bugs) >> >> As per the latest notes comments added for 8160404-jbs, I will submit >> webrev/RFR soon and will request help confirm similar issues with >> latest gcc7 gets solved. >> >> Thanks, >> Rahul >> >> On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote: >>> Hi all, >>> >>> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the >>> potential usage of maybe uninitialized memory in >>> src/hotspot/cpu/x86/assembler_x86.cpp and in >>> src/hotspot/cpu/x86/interp_masm_x86.cpp. >>> >>> The problems arises from the class RelocationHolder in >>> src/hotspot/share/code/relocInfo.hpp which has the private fields: >>> ?? enum { _relocbuf_size = 5 }; >>> ?? void* _relocbuf[ _relocbuf_size ]; >>> >>> and the default constructor for RelocationHolder does not initialize >>> the elements of _relocbuf. I _think_ this is an optimization, >>> RelocationHolder is used *a lot* and setting the elements of >>> RelocationHolder::_relocbuf to NULL (or some other value) in the >>> default constructor might result in a performance penalty. Have a >>> look in >>> build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles >>> and you will see that RelocationHolder is used all over the place :) >>> >>> AFAICS all users of RelocationHolder::_relocbuf take care to not use >>> uninitialized memory, which means that this warning is wrong, so I >>> suggest we disable the warning -Wmaybe-uninitialized for >>> src/hotspot/cpu/x86/assembler_x86.cpp. >>> >>> The problem continues because the class Address in >>> src/hotspot/cpu/x86/assembler_x86.hpp has a private field, >>> `RelocationHolder _rspec;` and the default constructor for Address >>> does not initialize _rspec._relocbuf (most likely for performance >>> reasons). The class Address also has a default copy constructor, >>> which will copy all the elements of _rspec._relocbuf, which will >>> result in a read of uninitialized memory. However, this is a benign >>> usage of uninitialized memory, since we take no action based on the >>> content of the uninitialized memory (it is just copied byte for byte). >>> >>> So, in this case too, I suggest we disable the warning >>> -Wuninitialized for src/hotspot/cpu/x86/assembler_x86.hpp. >>> >>> What do you think? >>> >>> Patch: >>> http://cr.openjdk.java.net/~ehelin/8187676/00/ >>> >>> --- old/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>> 15:11:45.036108983 +0200 >>> +++ new/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>> 15:11:44.692107277 +0200 >>> @@ -32,6 +32,8 @@ >>> ? ifeq ($(TOOLCHAIN_TYPE), gcc) >>> ??? BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := >>> -fno-var-tracking-assignments -O0 >>> ??? BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := >>> -fno-var-tracking-assignments >>> +? BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>> +? BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized >>> ? endif >>> >>> ? ifeq ($(OPENJDK_TARGET_OS), linux) >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8187676 >>> >>> Testing: >>> - Compiles with: >>> ?? - gcc 7.1.1 and glibc 2.25 on Fedora 26 >>> ?? - gcc 4.9.2 and glibc 2.12 on OEL 6.4 >>> - JPRT >>> >>> Thanks, >>> Erik From erik.joelsson at oracle.com Thu Sep 21 21:03:12 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 21 Sep 2017 14:03:12 -0700 Subject: RFR: JDK-8187790: generated-configure out of sync Message-ID: <9c4a1470-b984-ec8b-2925-1495d0e124e0@oracle.com> The generated configure is currently out of sync in jdk10/master. This was caused by me forgetting to generate before pushingJDK-8187542 . Bug: https://bugs.openjdk.java.net/browse/JDK-8187790 Webrev: http://cr.openjdk.java.net/~erikj/8187790/webrev.01/ /Erik From mandy.chung at oracle.com Thu Sep 21 21:03:59 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 21 Sep 2017 14:03:59 -0700 Subject: RFR: JDK-8187790: generated-configure out of sync In-Reply-To: <9c4a1470-b984-ec8b-2925-1495d0e124e0@oracle.com> References: <9c4a1470-b984-ec8b-2925-1495d0e124e0@oracle.com> Message-ID: <930c3b67-4cee-2646-eaae-d6d4c5b6fcda@oracle.com> +1 Mandy On 9/21/17 2:03 PM, Erik Joelsson wrote: > The generated configure is currently out of sync in jdk10/master. This > was caused by me forgetting to generate before pushingJDK-8187542 > . > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187790 > > Webrev: http://cr.openjdk.java.net/~erikj/8187790/webrev.01/ > > /Erik > From tim.bell at oracle.com Thu Sep 21 21:08:52 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 21 Sep 2017 14:08:52 -0700 Subject: RFR: JDK-8187790: generated-configure out of sync In-Reply-To: <930c3b67-4cee-2646-eaae-d6d4c5b6fcda@oracle.com> References: <9c4a1470-b984-ec8b-2925-1495d0e124e0@oracle.com> <930c3b67-4cee-2646-eaae-d6d4c5b6fcda@oracle.com> Message-ID: <59C42A64.5010001@oracle.com> Erik- Looks good to me as well. Tim On 09/21/17 14:03, mandy chung wrote: > +1 > > Mandy > > On 9/21/17 2:03 PM, Erik Joelsson wrote: >> The generated configure is currently out of sync in jdk10/master. This >> was caused by me forgetting to generate before pushingJDK-8187542 >> . >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187790 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8187790/webrev.01/ >> >> /Erik >> > From goetz.lindenmaier at sap.com Fri Sep 22 13:00:59 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Sep 2017 13:00:59 +0000 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: <0559eb3655cc42bb8b6cb37fb4370da8@sap.com> References: <0559eb3655cc42bb8b6cb37fb4370da8@sap.com> Message-ID: Hi, I updated my webrev to the directory structure: http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.02/ I also ran it through our tests again. Could someone please sponsor this change? Thanks, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 5. September 2017 10:05 > To: David Holmes ; hotspot-runtime- > dev at openjdk.java.net; build-dev > Subject: RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked > with -z,noexecstack > > Hi David, > > thanks for looking at my change! > > Hi Goetz, > > > > On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > I found that not all libraries are linked with -z,noexecstack. > > > This lead to errors with our linuxppc64 build. The linker omitted > > > the flag altogether, which is interpreted as a lib with execstack. > > > > > > This change contains a small test that scans all libraries in the tested VM > > > to have the noexecstack flag set. It utilizes the elf parser in the VM for > this. > > > Further -z,noexecstack is now passed to all libraries. > > > > > > Please review this change. I please need a sponsor. > > > http://cr.openjdk.java.net/~goetz/wr17/8187045- > > execstackLink/webrev.01/ > > > > So IIUC presently we only set noexecstack for gcc on linux when building > > libjvm - via the JVM_LDFLAGS settings. > Yes. > > > With this change we also set it for building JDK libraries via the > > LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited > > to gcc and linux ?? > LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on linux, > on other platforms its empty. > > > In addition we want to build libjsig with noexecstack, and we do that by > > exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in > > CompileLibjsig.gmk. I don't have an issue with the use of noexecstack > > but I think it could just have been hard-wired for linux just as the > > bulk of the flags set in that file are. Granted you copied what is done > > for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important > > that the same hash style be used throughout. Anyway minor stylistic nit > > which may be moot soon as once we have the consolidated repo I think > > libjsig could be handled the same as others libs? > I had hoped to find a location where flags that should be used in all linking > steps are assembled. Noexecstack should really be set in any lib we build. > But I didn't find that, so I implemented it as with the HASH_STYLE. I don't > really like it this way because if a new lib is added it might be forgotten > to add the noexecstack. > But I assume after the repo consolidation the build will be reshaped, > so now is not the right time to seek for optimal setups. > > Best regards, > Goetz. > > > > > > http://cr.openjdk.java.net/~goetz/wr17/8187045- > execstackLink/webrev.01- > > hs/ > > > > Test changes look okay to me. > > > > Thanks, > > David > > > > > Best regards, > > > Goetz. > > > From lance.andersen at oracle.com Sun Sep 24 14:29:47 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 24 Sep 2017 10:29:47 -0400 Subject: JIB build failures JDK 10 full repro of install Message-ID: Hi, Trying to use JIB for the 1st time to build the full JDK 10 and seeing errors such as the following from jib make ????????? In file included from /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-full/closed/install/src/settings/macosx/MacSettings.cpp:6: In file included from /Users/ljanders/Documents/hg-workspaces/openjdk10/jdk10-full/closed/install/src/settings/share/Misc.h:10: /Users/ljanders/Documents/hg-workspaces/openjdk-tools/jib-artifacts/install/jpg/infra/builddeps/devkit-macosx_x64/Xcode6.3-MacOSX10.9+1.0/devkit-macosx_x64-Xcode6.3-MacOSX10.9+1.0.tar.gz/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cctype:39:10: fatal error: 'ctype.h' file not found #include ????????????? I did not see anything obvious WRT errors in the configure.log from running jib configure It looks like the images were build though ?????????? ./build/*/images/jdk/bin/java -version java version "10-internal" Java(TM) SE Runtime Environment (build 10-internal+0-2017-09-23-2007047.ljanders.jdk10-full) Java HotSpot(TM) 64-Bit Server VM (build 10-internal+0-2017-09-23-2007047.ljanders.jdk10-full, mixed mode) ??????????????? Also, am i correct that ~/.config/jib/jib.conf needs to be created manually as I did not see that after running jib configure I have installed the bootstrap launcher as well 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 From maurizio.cimadamore at oracle.com Mon Sep 25 11:33:00 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Sep 2017 12:33:00 +0100 Subject: running tests from make causes spurious repo changes Message-ID: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> Hi, if I try to run tests from make, after the test run an 'hg status' reveal the following 'changes': M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/linux-i586/libLauncher.so M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparcv9/libLauncher.so M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll What's up? Shouldn't this stuff end up in build folder? Cheers Maurizio From erik.joelsson at oracle.com Mon Sep 25 11:53:08 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 25 Sep 2017 13:53:08 +0200 Subject: running tests from make causes spurious repo changes In-Reply-To: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> Message-ID: <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> I couldn't agree with you more, but AFAIK, this behavior is in the tests themselves and not something the build is doing. /Erik On 2017-09-25 13:33, Maurizio Cimadamore wrote: > Hi, > if I try to run tests from make, after the test run an 'hg status' > reveal the following 'changes': > > M > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/linux-i586/libLauncher.so > M > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so > M > test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparcv9/libLauncher.so > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll > M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll > > What's up? Shouldn't this stuff end up in build folder? > > Cheers > Maurizio > From maurizio.cimadamore at oracle.com Mon Sep 25 11:54:16 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Sep 2017 12:54:16 +0100 Subject: running tests from make causes spurious repo changes In-Reply-To: <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> Message-ID: <401ce908-7320-0d36-9082-c0b5424ed9aa@oracle.com> On 25/09/17 12:53, Erik Joelsson wrote: > I couldn't agree with you more, but AFAIK, this behavior is in the > tests themselves and not something the build is doing. I see - for the records, I got this when running the test group jdk_lang Maurizio > > /Erik > > > On 2017-09-25 13:33, Maurizio Cimadamore wrote: >> Hi, >> if I try to run tests from make, after the test run an 'hg status' >> reveal the following 'changes': >> >> M >> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/linux-i586/libLauncher.so >> M >> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so >> M >> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparcv9/libLauncher.so >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll >> >> What's up? Shouldn't this stuff end up in build folder? >> >> Cheers >> Maurizio >> > From martinrb at google.com Mon Sep 25 18:47:56 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 Sep 2017 11:47:56 -0700 Subject: running tests from make causes spurious repo changes In-Reply-To: <401ce908-7320-0d36-9082-c0b5424ed9aa@oracle.com> References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <401ce908-7320-0d36-9082-c0b5424ed9aa@oracle.com> Message-ID: It should be standard practice for whoever does systematic jtreg testing to do it occasionally with the jdk sources mounted in a read-only file system, and ensure all the tests still pass. On Mon, Sep 25, 2017 at 4:54 AM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > > On 25/09/17 12:53, Erik Joelsson wrote: > >> I couldn't agree with you more, but AFAIK, this behavior is in the tests >> themselves and not something the build is doing. >> > I see - for the records, I got this when running the test group jdk_lang > > Maurizio > > >> /Erik >> >> >> On 2017-09-25 13:33, Maurizio Cimadamore wrote: >> >>> Hi, >>> if I try to run tests from make, after the test run an 'hg status' >>> reveal the following 'changes': >>> >>> M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedCha >>> nnel/lib/linux-i586/libLauncher.so >>> M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedCha >>> nnel/lib/solaris-amd64/libLauncher.so >>> M test/jdk/java/nio/channels/spi/SelectorProvider/inheritedCha >>> nnel/lib/solaris-sparcv9/libLauncher.so >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll >>> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll >>> >>> What's up? Shouldn't this stuff end up in build folder? >>> >>> Cheers >>> Maurizio >>> >>> >> > From jonathan.gibbons at oracle.com Mon Sep 25 19:11:48 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 25 Sep 2017 12:11:48 -0700 Subject: running tests from make causes spurious repo changes In-Reply-To: <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> Message-ID: Erik, It could be a feature of the build (i.e. test makefiles) to verify that no source-controlled files were modified in the course of a test run. A related, secondary feature could be to make sure that no new files were written in directories containing source-controlled files (i.e. src, make, test, etc). Together, these checks could be combined by comparing the output of "hg status" before and after the test run. Martin's suggestion to run on a read-only filesystem is also a good one, but maybe harder for most people to set up (e.g. on a laptop or Dev machine), so makefile checks would be nice. -- Jon On 9/25/17 4:53 AM, Erik Joelsson wrote: > I couldn't agree with you more, but AFAIK, this behavior is in the > tests themselves and not something the build is doing. > > /Erik > > > On 2017-09-25 13:33, Maurizio Cimadamore wrote: >> Hi, >> if I try to run tests from make, after the test run an 'hg status' >> reveal the following 'changes': >> >> M >> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/linux-i586/libLauncher.so >> M >> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so >> M >> test/jdk/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparcv9/libLauncher.so >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/freebl3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nspr4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nss3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssckbi.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssdbm3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/nssutil3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plc4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/plds4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/softokn3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/sqlite3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-amd64/ssl3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/freebl3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nspr4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssdbm3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/nssutil3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plc4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/plds4.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/sqlite3.dll >> M test/jdk/sun/security/pkcs11/nss/lib/windows-i586/ssl3.dll >> >> What's up? Shouldn't this stuff end up in build folder? >> >> Cheers >> Maurizio >> > From Alan.Bateman at oracle.com Mon Sep 25 19:58:22 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Sep 2017 20:58:22 +0100 Subject: running tests from make causes spurious repo changes In-Reply-To: References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> Message-ID: <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> On 25/09/2017 20:11, Jonathan Gibbons wrote: > Erik, > > It could be a feature of the build (i.e. test makefiles) to verify > that no source-controlled files were modified in the course of a test > run. Something fishy in this thread as these tests have historically not changed the permissions of these libraries. So I'm curious how they were run, I wonder in case they were changed by a make file instead. -Alan From maurizio.cimadamore at oracle.com Mon Sep 25 20:35:35 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 Sep 2017 21:35:35 +0100 Subject: running tests from make causes spurious repo changes In-Reply-To: <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> Message-ID: On 25/09/17 20:58, Alan Bateman wrote: > > > On 25/09/2017 20:11, Jonathan Gibbons wrote: >> Erik, >> >> It could be a feature of the build (i.e. test makefiles) to verify >> that no source-controlled files were modified in the course of a test >> run. > Something fishy in this thread as these tests have historically not > changed the permissions of these libraries. So I'm curious how they > were run, I wonder in case they were changed by a make file instead. make test TEST=jdk_lang AFAIK, this should be the correct way of invoking tests from make? Maurizio > > -Alan From david.holmes at oracle.com Tue Sep 26 03:28:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 Sep 2017 13:28:34 +1000 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: References: <0559eb3655cc42bb8b6cb37fb4370da8@sap.com> Message-ID: <66f399c1-66b2-bb9a-2eb1-103a804d9d17@oracle.com> Hi Goetz, I'll sponsor this for you. David On 22/09/2017 11:00 PM, Lindenmaier, Goetz wrote: > Hi, > > I updated my webrev to the directory structure: > http://cr.openjdk.java.net/~goetz/wr17/8187045-execstackLink/webrev.02/ > I also ran it through our tests again. > > Could someone please sponsor this change? > > Thanks, > Goetz. > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 5. September 2017 10:05 >> To: David Holmes ; hotspot-runtime- >> dev at openjdk.java.net; build-dev >> Subject: RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked >> with -z,noexecstack >> >> Hi David, >> >> thanks for looking at my change! >>> Hi Goetz, >>> >>> On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> I found that not all libraries are linked with -z,noexecstack. >>>> This lead to errors with our linuxppc64 build. The linker omitted >>>> the flag altogether, which is interpreted as a lib with execstack. >>>> >>>> This change contains a small test that scans all libraries in the tested VM >>>> to have the noexecstack flag set. It utilizes the elf parser in the VM for >> this. >>>> Further -z,noexecstack is now passed to all libraries. >>>> >>>> Please review this change. I please need a sponsor. >>>> http://cr.openjdk.java.net/~goetz/wr17/8187045- >>> execstackLink/webrev.01/ >>> >>> So IIUC presently we only set noexecstack for gcc on linux when building >>> libjvm - via the JVM_LDFLAGS settings. >> Yes. >> >>> With this change we also set it for building JDK libraries via the >>> LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited >>> to gcc and linux ?? >> LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on linux, >> on other platforms its empty. >> >>> In addition we want to build libjsig with noexecstack, and we do that by >>> exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in >>> CompileLibjsig.gmk. I don't have an issue with the use of noexecstack >>> but I think it could just have been hard-wired for linux just as the >>> bulk of the flags set in that file are. Granted you copied what is done >>> for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important >>> that the same hash style be used throughout. Anyway minor stylistic nit >>> which may be moot soon as once we have the consolidated repo I think >>> libjsig could be handled the same as others libs? >> I had hoped to find a location where flags that should be used in all linking >> steps are assembled. Noexecstack should really be set in any lib we build. >> But I didn't find that, so I implemented it as with the HASH_STYLE. I don't >> really like it this way because if a new lib is added it might be forgotten >> to add the noexecstack. >> But I assume after the repo consolidation the build will be reshaped, >> so now is not the right time to seek for optimal setups. >> >> Best regards, >> Goetz. >> >>> > >>> http://cr.openjdk.java.net/~goetz/wr17/8187045- >> execstackLink/webrev.01- >>> hs/ >>> >>> Test changes look okay to me. >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> Goetz. >>>> From Alan.Bateman at oracle.com Tue Sep 26 06:13:58 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Sep 2017 07:13:58 +0100 Subject: running tests from make causes spurious repo changes In-Reply-To: References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> Message-ID: On 25/09/2017 21:35, Maurizio Cimadamore wrote: > > > On 25/09/17 20:58, Alan Bateman wrote: >> >> >> On 25/09/2017 20:11, Jonathan Gibbons wrote: >>> Erik, >>> >>> It could be a feature of the build (i.e. test makefiles) to verify >>> that no source-controlled files were modified in the course of a >>> test run. >> Something fishy in this thread as these tests have historically not >> changed the permissions of these libraries. So I'm curious how they >> were run, I wonder in case they were changed by a make file instead. > make test TEST=jdk_lang > > AFAIK, this should be the correct way of invoking tests from make? I assume this make file must be running chmod, not the tests themselves as otherwise this issue would have been noticed a long time ago. I suspect many people run jtreg directly in their local environment rather than the make file. In any case, these older tests predate build test support for compiling native code and probably should be migrated anyway. -Alan From goetz.lindenmaier at sap.com Tue Sep 26 07:34:44 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Sep 2017 07:34:44 +0000 Subject: RFR(M): 8187045: [linux] Not all libraries in the VM are linked with -z,noexecstack In-Reply-To: <66f399c1-66b2-bb9a-2eb1-103a804d9d17@oracle.com> References: <0559eb3655cc42bb8b6cb37fb4370da8@sap.com> <66f399c1-66b2-bb9a-2eb1-103a804d9d17@oracle.com> Message-ID: <593089e8e3fb4d75a6da598106722ead@sap.com> Hi David, thanks a lot! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Dienstag, 26. September 2017 05:29 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; build-dev > Subject: Re: RFR(M): 8187045: [linux] Not all libraries in the VM are linked > with -z,noexecstack > > Hi Goetz, > > I'll sponsor this for you. > > David > > On 22/09/2017 11:00 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > I updated my webrev to the directory structure: > > http://cr.openjdk.java.net/~goetz/wr17/8187045- > execstackLink/webrev.02/ > > I also ran it through our tests again. > > > > Could someone please sponsor this change? > > > > Thanks, > > Goetz. > > > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Dienstag, 5. September 2017 10:05 > >> To: David Holmes ; hotspot-runtime- > >> dev at openjdk.java.net; build-dev > >> Subject: RE: RFR(M): 8187045: [linux] Not all libraries in the VM are linked > >> with -z,noexecstack > >> > >> Hi David, > >> > >> thanks for looking at my change! > >>> Hi Goetz, > >>> > >>> On 1/09/2017 11:05 PM, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> I found that not all libraries are linked with -z,noexecstack. > >>>> This lead to errors with our linuxppc64 build. The linker omitted > >>>> the flag altogether, which is interpreted as a lib with execstack. > >>>> > >>>> This change contains a small test that scans all libraries in the tested VM > >>>> to have the noexecstack flag set. It utilizes the elf parser in the VM for > >> this. > >>>> Further -z,noexecstack is now passed to all libraries. > >>>> > >>>> Please review this change. I please need a sponsor. > >>>> http://cr.openjdk.java.net/~goetz/wr17/8187045- > >>> execstackLink/webrev.01/ > >>> > >>> So IIUC presently we only set noexecstack for gcc on linux when building > >>> libjvm - via the JVM_LDFLAGS settings. > >> Yes. > >> > >>> With this change we also set it for building JDK libraries via the > >>> LDFLAGS_JDKLIB setting. But this seems to be unconditional, not limited > >>> to gcc and linux ?? > >> LDFLAGS_NO_EXEC_STACK="-Wl,-z,noexecstack" is only assigned on > linux, > >> on other platforms its empty. > >> > >>> In addition we want to build libjsig with noexecstack, and we do that by > >>> exposing LDFLAGS_NO_EXEC_STACK in spec.gmk, and using it in > >>> CompileLibjsig.gmk. I don't have an issue with the use of noexecstack > >>> but I think it could just have been hard-wired for linux just as the > >>> bulk of the flags set in that file are. Granted you copied what is done > >>> for LDFLAGS_HASH_STYLE - but in that case I'm assuming it is important > >>> that the same hash style be used throughout. Anyway minor stylistic nit > >>> which may be moot soon as once we have the consolidated repo I think > >>> libjsig could be handled the same as others libs? > >> I had hoped to find a location where flags that should be used in all linking > >> steps are assembled. Noexecstack should really be set in any lib we build. > >> But I didn't find that, so I implemented it as with the HASH_STYLE. I don't > >> really like it this way because if a new lib is added it might be forgotten > >> to add the noexecstack. > >> But I assume after the repo consolidation the build will be reshaped, > >> so now is not the right time to seek for optimal setups. > >> > >> Best regards, > >> Goetz. > >> > >>> > > >>> http://cr.openjdk.java.net/~goetz/wr17/8187045- > >> execstackLink/webrev.01- > >>> hs/ > >>> > >>> Test changes look okay to me. > >>> > >>> Thanks, > >>> David > >>> > >>>> Best regards, > >>>> Goetz. > >>>> From maurizio.cimadamore at oracle.com Tue Sep 26 11:10:14 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 Sep 2017 12:10:14 +0100 Subject: running tests from make causes spurious repo changes In-Reply-To: References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> Message-ID: On 26/09/17 07:13, Alan Bateman wrote: > > > On 25/09/2017 21:35, Maurizio Cimadamore wrote: >> >> >> On 25/09/17 20:58, Alan Bateman wrote: >>> >>> >>> On 25/09/2017 20:11, Jonathan Gibbons wrote: >>>> Erik, >>>> >>>> It could be a feature of the build (i.e. test makefiles) to verify >>>> that no source-controlled files were modified in the course of a >>>> test run. >>> Something fishy in this thread as these tests have historically not >>> changed the permissions of these libraries. So I'm curious how they >>> were run, I wonder in case they were changed by a make file instead. >> make test TEST=jdk_lang >> >> AFAIK, this should be the correct way of invoking tests from make? > I assume this make file must be running chmod, not the tests > themselves as otherwise this issue would have been noticed a long time > ago. I suspect many people run jtreg directly in their local > environment rather than the make file. Note that I've been running tests this way over the last 2-3 years, and this only started to happen after the move to consolidated repo. That's why I correlated the two things. Maurizio > > In any case, these older tests predate build test support for > compiling native code and probably should be migrated anyway. > > -Alan From magnus.ihse.bursie at oracle.com Wed Sep 27 08:30:57 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 10:30:57 +0200 Subject: RFR: JDK-8188012 Nashorn build targets version 9 source Message-ID: The nashorn java code requires a somewhat convoluted compilation. As a result, we use a special java compiler setup, GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target 9, which generates this warning: warning: [options] bootstrap class path not set in conjunction with -source 1.9 when building in jdk10. I assume this is just a mistake, and that it should really target 10. (Or, to always be in sync, perhaps even $(VERSION_MAJOR)). Bug: https://bugs.openjdk.java.net/browse/JDK-8188012 Patch inline: diff --git a/make/BuildNashorn.gmk b/make/BuildNashorn.gmk --- a/make/BuildNashorn.gmk +++ b/make/BuildNashorn.gmk @@ -41,7 +41,7 @@ ?$(eval $(call SetupJavaCompiler, GENERATE_NEWBYTECODE_DEBUG, \ ???? JVM := $(JAVA_JAVAC), \ ???? JAVAC := $(NEW_JAVAC), \ -??? FLAGS := -g -source 9 -target 9 --upgrade-module-path "$(JDK_OUTPUTDIR)/modules/" \ +??? FLAGS := -g -source 10 -target 10 --upgrade-module-path "$(JDK_OUTPUTDIR)/modules/" \ ????????? --system none --module-source-path $(call GetModuleSrcPath), \ ???? SERVER_DIR := $(SJAVAC_SERVER_DIR), \ ???? SERVER_JVM := $(SJAVAC_SERVER_JAVA))) /Magnus From erik.joelsson at oracle.com Wed Sep 27 08:45:52 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Sep 2017 10:45:52 +0200 Subject: RFR: JDK-8188012 Nashorn build targets version 9 source In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-09-27 10:30, Magnus Ihse Bursie wrote: > > The nashorn java code requires a somewhat convoluted compilation. As a > result, we use a special java compiler setup, > GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target 9, > which generates this warning: > > warning: [options] bootstrap class path not set in conjunction with > -source 1.9 > > when building in jdk10. I assume this is just a mistake, and that it > should really target 10. (Or, to always be in sync, perhaps even > $(VERSION_MAJOR)). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188012 > Patch inline: > diff --git a/make/BuildNashorn.gmk b/make/BuildNashorn.gmk > --- a/make/BuildNashorn.gmk > +++ b/make/BuildNashorn.gmk > @@ -41,7 +41,7 @@ > $(eval $(call SetupJavaCompiler, GENERATE_NEWBYTECODE_DEBUG, \ > JVM := $(JAVA_JAVAC), \ > JAVAC := $(NEW_JAVAC), \ > - FLAGS := -g -source 9 -target 9 --upgrade-module-path > "$(JDK_OUTPUTDIR)/modules/" \ > + FLAGS := -g -source 10 -target 10 --upgrade-module-path > "$(JDK_OUTPUTDIR)/modules/" \ > --system none --module-source-path $(call GetModuleSrcPath), \ > SERVER_DIR := $(SJAVAC_SERVER_DIR), \ > SERVER_JVM := $(SJAVAC_SERVER_JAVA))) > > /Magnus From david.holmes at oracle.com Wed Sep 27 08:55:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 18:55:41 +1000 Subject: RFR: JDK-8188012 Nashorn build targets version 9 source In-Reply-To: References: Message-ID: On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote: > > The nashorn java code requires a somewhat convoluted compilation. As a > result, we use a special java compiler setup, > GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target 9, > which generates this warning: > > warning: [options] bootstrap class path not set in conjunction with > -source 1.9 > > when building in jdk10. I assume this is just a mistake, and that it > should really target 10. (Or, to always be in sync, perhaps even > $(VERSION_MAJOR)). Seems like a reasonable assumption. Though one has to wonder why we even set the source/target? That would only be necessary if we needed to force building to an older level. I think these could just be removed. Cheers, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8188012 > Patch inline: > diff --git a/make/BuildNashorn.gmk b/make/BuildNashorn.gmk > --- a/make/BuildNashorn.gmk > +++ b/make/BuildNashorn.gmk > @@ -41,7 +41,7 @@ > ?$(eval $(call SetupJavaCompiler, GENERATE_NEWBYTECODE_DEBUG, \ > ???? JVM := $(JAVA_JAVAC), \ > ???? JAVAC := $(NEW_JAVAC), \ > -??? FLAGS := -g -source 9 -target 9 --upgrade-module-path > "$(JDK_OUTPUTDIR)/modules/" \ > +??? FLAGS := -g -source 10 -target 10 --upgrade-module-path > "$(JDK_OUTPUTDIR)/modules/" \ > ????????? --system none --module-source-path $(call GetModuleSrcPath), \ > ???? SERVER_DIR := $(SJAVAC_SERVER_DIR), \ > ???? SERVER_JVM := $(SJAVAC_SERVER_JAVA))) > > /Magnus From magnus.ihse.bursie at oracle.com Wed Sep 27 09:26:03 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 11:26:03 +0200 Subject: RFR: JDK-8188012 Nashorn build targets version 9 source In-Reply-To: References: Message-ID: <1b7a7b4e-e296-d4fe-85b0-2428d688bba4@oracle.com> On 2017-09-27 10:55, David Holmes wrote: > On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote: >> >> The nashorn java code requires a somewhat convoluted compilation. As >> a result, we use a special java compiler setup, >> GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target >> 9, which generates this warning: >> >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.9 >> >> when building in jdk10. I assume this is just a mistake, and that it >> should really target 10. (Or, to always be in sync, perhaps even >> $(VERSION_MAJOR)). > > Seems like a reasonable assumption. Though one has to wonder why we > even set the source/target? That would only be necessary if we needed > to force building to an older level. I think these could just be removed. Historically, we have told javac explicitly which source/target version to use, instead of relying on the default. (This is not the only place we have this hard-coded in.) We should change this behavior. I've created https://bugs.openjdk.java.net/browse/JDK-8188015 to track this. /Magnus > > Cheers, > David > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188012 >> Patch inline: >> diff --git a/make/BuildNashorn.gmk b/make/BuildNashorn.gmk >> --- a/make/BuildNashorn.gmk >> +++ b/make/BuildNashorn.gmk >> @@ -41,7 +41,7 @@ >> ??$(eval $(call SetupJavaCompiler, GENERATE_NEWBYTECODE_DEBUG, \ >> ????? JVM := $(JAVA_JAVAC), \ >> ????? JAVAC := $(NEW_JAVAC), \ >> -??? FLAGS := -g -source 9 -target 9 --upgrade-module-path >> "$(JDK_OUTPUTDIR)/modules/" \ >> +??? FLAGS := -g -source 10 -target 10 --upgrade-module-path >> "$(JDK_OUTPUTDIR)/modules/" \ >> ?????????? --system none --module-source-path $(call >> GetModuleSrcPath), \ >> ????? SERVER_DIR := $(SJAVAC_SERVER_DIR), \ >> ????? SERVER_JVM := $(SJAVAC_SERVER_JAVA))) >> >> /Magnus From sundararajan.athijegannathan at oracle.com Wed Sep 27 09:32:54 2017 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 27 Sep 2017 15:02:54 +0530 Subject: RFR: JDK-8188012 Nashorn build targets version 9 source In-Reply-To: References: Message-ID: <59CB7046.9010400@oracle.com> We run nasgen tool on the generated nashorn .class files to post-process. nasgen used to run on boot JDK in the past (if I recall right). I'm fine with current change is okay - so long as nasgen works fine & nashorn tests run fine. Please note that nashorn tests are run with "ant". cd $jdk10/make/nashorn export JAVA_HOME= ant clean test -Sundar On 27/09/17, 2:25 PM, David Holmes wrote: > On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote: >> >> The nashorn java code requires a somewhat convoluted compilation. As >> a result, we use a special java compiler setup, >> GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target >> 9, which generates this warning: >> >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.9 >> >> when building in jdk10. I assume this is just a mistake, and that it >> should really target 10. (Or, to always be in sync, perhaps even >> $(VERSION_MAJOR)). > > Seems like a reasonable assumption. Though one has to wonder why we > even set the source/target? That would only be necessary if we needed > to force building to an older level. I think these could just be removed. > > Cheers, > David > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188012 >> Patch inline: >> diff --git a/make/BuildNashorn.gmk b/make/BuildNashorn.gmk >> --- a/make/BuildNashorn.gmk >> +++ b/make/BuildNashorn.gmk >> @@ -41,7 +41,7 @@ >> $(eval $(call SetupJavaCompiler, GENERATE_NEWBYTECODE_DEBUG, \ >> JVM := $(JAVA_JAVAC), \ >> JAVAC := $(NEW_JAVAC), \ >> - FLAGS := -g -source 9 -target 9 --upgrade-module-path >> "$(JDK_OUTPUTDIR)/modules/" \ >> + FLAGS := -g -source 10 -target 10 --upgrade-module-path >> "$(JDK_OUTPUTDIR)/modules/" \ >> --system none --module-source-path $(call >> GetModuleSrcPath), \ >> SERVER_DIR := $(SJAVAC_SERVER_DIR), \ >> SERVER_JVM := $(SJAVAC_SERVER_JAVA))) >> >> /Magnus From maurizio.cimadamore at oracle.com Wed Sep 27 09:28:35 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Sep 2017 10:28:35 +0100 Subject: running tests from make causes spurious repo changes In-Reply-To: References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> Message-ID: I did a bit of digging on this one, I found out that the permissions are indeed changed by make - see test/TestCommon.gmk: # Prep for output # Change execute permissions on shared library files. # Files in repositories should never have execute permissions, but # there are some tests that have pre-built shared libraries, and these # windows dll files must have execute permission. Adding execute # permission may happen automatically on windows when using certain # versions of mercurial but it cannot be guaranteed. And blindly # adding execute permission might be seen as a mercurial 'change', so # we avoid adding execute permission to repository files. But testing # from a plain source tree needs the chmod a+rx. Applying the chmod to # all shared libraries not just dll files. And with CYGWIN and sshd # service, you may need CYGWIN=ntsec for this to work. prep: ??? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) ??? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` ??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; then?????????????????????????????????? \ ??? ? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name \*.so \)? \ ??? ??????? -exec $(CHMOD) a+rx {} \; ;?????????????????????????????????????? \ ??? fi This part seems to be responsible for changing the permissions on the said lib files. That said, TestCommon.gmk is essentially the same as? it was in jdk10 unconsolidated, but yet the problem cannot be reporoduced in the latest unconsolidated jdk10 repo. So, I believe something is up. More specifically, this test: if [ ! -d $(TEST_ROOT)/../.hg ] ; then?????????????????????????????????? \ was probably failing before, causing the permission changing branch not to be taken? Maurizio On 26/09/17 12:10, Maurizio Cimadamore wrote: > > > On 26/09/17 07:13, Alan Bateman wrote: >> >> >> On 25/09/2017 21:35, Maurizio Cimadamore wrote: >>> >>> >>> On 25/09/17 20:58, Alan Bateman wrote: >>>> >>>> >>>> On 25/09/2017 20:11, Jonathan Gibbons wrote: >>>>> Erik, >>>>> >>>>> It could be a feature of the build (i.e. test makefiles) to verify >>>>> that no source-controlled files were modified in the course of a >>>>> test run. >>>> Something fishy in this thread as these tests have historically not >>>> changed the permissions of these libraries. So I'm curious how they >>>> were run, I wonder in case they were changed by a make file instead. >>> make test TEST=jdk_lang >>> >>> AFAIK, this should be the correct way of invoking tests from make? >> I assume this make file must be running chmod, not the tests >> themselves as otherwise this issue would have been noticed a long >> time ago. I suspect many people run jtreg directly in their local >> environment rather than the make file. > Note that I've been running tests this way over the last 2-3 years, > and this only started to happen after the move to consolidated repo. > That's why I correlated the two things. > > Maurizio >> >> In any case, these older tests predate build test support for >> compiling native code and probably should be migrated anyway. >> >> -Alan > From magnus.ihse.bursie at oracle.com Wed Sep 27 09:29:43 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 11:29:43 +0200 Subject: RFR: JDK-8188013 symbolgenerator targets jdk 9 source Message-ID: <55492e65-3161-ad86-a0ab-b875f697ca79@oracle.com> In make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java, javac gets called with a fixed command line. This includes the arguments "-source 9 -target 9". While this was fine for jdk9, in jdk10 this results in the following warning: warning: [options] bootstrap class path not set in conjunction with -source 1.9 I presume it is a mistake that this was not updated to -source 10 -target 10 for jdk10. I have verified that the contents of ct.sym has not changed due to this patch. I have kept the -source/-target arguments for now, and postponed the discussion to remove them to JDK-8188015. Bug: https://bugs.openjdk.java.net/browse/JDK-8188013 Patch inline: diff --git a/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java b/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java --- a/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java +++ b/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java @@ -57,8 +57,8 @@ ???????? } ???????? JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); -??????? List options = Arrays.asList("-source", "9", -???????????????????????????????????????????? "-target", "9", +??????? List options = Arrays.asList("-source", "10", +???????????????????????????????????????????? "-target", "10", ????????????????????????????????????????????? "-proc:only", ????????????????????????????????????????????? "--system", "none", "--module-source-path", args[0], /Magnus From erik.joelsson at oracle.com Wed Sep 27 09:32:36 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Sep 2017 11:32:36 +0200 Subject: RFR: JDK-8188013 symbolgenerator targets jdk 9 source In-Reply-To: <55492e65-3161-ad86-a0ab-b875f697ca79@oracle.com> References: <55492e65-3161-ad86-a0ab-b875f697ca79@oracle.com> Message-ID: <6a85ceec-2c37-2da4-f997-69e21da5e2e2@oracle.com> Looks good to me. /Erik On 2017-09-27 11:29, Magnus Ihse Bursie wrote: > In > make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java, > javac gets called with a fixed command line. This includes the > arguments "-source 9 -target 9". While this was fine for > jdk9, in jdk10 this results in the following warning: > > warning: [options] bootstrap class path not set in conjunction with > -source 1.9 > > I presume it is a mistake that this was not updated to -source 10 > -target 10 for jdk10. > > I have verified that the contents of ct.sym has not changed due to > this patch. > > I have kept the -source/-target arguments for now, and postponed the > discussion to remove them to JDK-8188015. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188013 > Patch inline: > diff --git > a/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > b/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > > --- > a/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > +++ > b/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > @@ -57,8 +57,8 @@ > } > > JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); > - List options = Arrays.asList("-source", "9", > - "-target", "9", > + List options = Arrays.asList("-source", "10", > + "-target", "10", > "-proc:only", > "--system", "none", > "--module-source-path", args[0], > > > /Magnus > From erik.joelsson at oracle.com Wed Sep 27 09:36:10 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Sep 2017 11:36:10 +0200 Subject: running tests from make causes spurious repo changes In-Reply-To: References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> Message-ID: <77cf79c0-e4cc-fc24-ddb8-2465c5783c19@oracle.com> Ah good find and I stand corrected. That relative path check does need to change for this to continue working as before. What I don't understand is why the chmod is needed and why it's only done when not running from a hg repo. We don't allow executable files in the repository so if +x was required, then the tests would fail if run from an hg repo. /Erik On 2017-09-27 11:28, Maurizio Cimadamore wrote: > I did a bit of digging on this one, I found out that the permissions > are indeed changed by make - see test/TestCommon.gmk: > > # Prep for output > # Change execute permissions on shared library files. > # Files in repositories should never have execute permissions, but > # there are some tests that have pre-built shared libraries, and these > # windows dll files must have execute permission. Adding execute > # permission may happen automatically on windows when using certain > # versions of mercurial but it cannot be guaranteed. And blindly > # adding execute permission might be seen as a mercurial 'change', so > # we avoid adding execute permission to repository files. But testing > # from a plain source tree needs the chmod a+rx. Applying the chmod to > # all shared libraries not just dll files. And with CYGWIN and sshd > # service, you may need CYGWIN=ntsec for this to work. > prep: > @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) > @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` > @if [ ! -d $(TEST_ROOT)/../.hg ] ; > then \ > $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name > \*.so \) \ > -exec $(CHMOD) a+rx {} \; > ; \ > fi > > > This part seems to be responsible for changing the permissions on the > said lib files. That said, TestCommon.gmk is essentially the same as > it was in jdk10 unconsolidated, but yet the problem cannot be > reporoduced in the latest unconsolidated jdk10 repo. So, I believe > something is up. More specifically, this test: > > if [ ! -d $(TEST_ROOT)/../.hg ] ; > then \ > > was probably failing before, causing the permission changing branch > not to be taken? > > Maurizio > > > On 26/09/17 12:10, Maurizio Cimadamore wrote: >> >> >> On 26/09/17 07:13, Alan Bateman wrote: >>> >>> >>> On 25/09/2017 21:35, Maurizio Cimadamore wrote: >>>> >>>> >>>> On 25/09/17 20:58, Alan Bateman wrote: >>>>> >>>>> >>>>> On 25/09/2017 20:11, Jonathan Gibbons wrote: >>>>>> Erik, >>>>>> >>>>>> It could be a feature of the build (i.e. test makefiles) to >>>>>> verify that no source-controlled files were modified in the >>>>>> course of a test run. >>>>> Something fishy in this thread as these tests have historically >>>>> not changed the permissions of these libraries. So I'm curious how >>>>> they were run, I wonder in case they were changed by a make file >>>>> instead. >>>> make test TEST=jdk_lang >>>> >>>> AFAIK, this should be the correct way of invoking tests from make? >>> I assume this make file must be running chmod, not the tests >>> themselves as otherwise this issue would have been noticed a long >>> time ago. I suspect many people run jtreg directly in their local >>> environment rather than the make file. >> Note that I've been running tests this way over the last 2-3 years, >> and this only started to happen after the move to consolidated repo. >> That's why I correlated the two things. >> >> Maurizio >>> >>> In any case, these older tests predate build test support for >>> compiling native code and probably should be migrated anyway. >>> >>> -Alan >> > From erik.joelsson at oracle.com Wed Sep 27 09:37:37 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Sep 2017 11:37:37 +0200 Subject: running tests from make causes spurious repo changes In-Reply-To: <77cf79c0-e4cc-fc24-ddb8-2465c5783c19@oracle.com> References: <49e59b19-8082-f145-f805-d6cbd6e41cca@oracle.com> <09964b0b-c148-db55-bbaf-35b05b9672b4@oracle.com> <4a3017d5-994c-7849-1889-df9185538cb6@oracle.com> <77cf79c0-e4cc-fc24-ddb8-2465c5783c19@oracle.com> Message-ID: <955153fe-2546-50f6-5172-25c298e3cf6f@oracle.com> On 2017-09-27 11:36, Erik Joelsson wrote: > Ah good find and I stand corrected. That relative path check does need > to change for this to continue working as before. > > What I don't understand is why the chmod is needed and why it's only > done when not running from a hg repo. We don't allow executable files > in the repository so if +x was required, then the tests would fail if > run from an hg repo. > I realize this was explained in the comment as I was sending this. /Erik > /Erik > > > On 2017-09-27 11:28, Maurizio Cimadamore wrote: >> I did a bit of digging on this one, I found out that the permissions >> are indeed changed by make - see test/TestCommon.gmk: >> >> # Prep for output >> # Change execute permissions on shared library files. >> # Files in repositories should never have execute permissions, but >> # there are some tests that have pre-built shared libraries, and these >> # windows dll files must have execute permission. Adding execute >> # permission may happen automatically on windows when using certain >> # versions of mercurial but it cannot be guaranteed. And blindly >> # adding execute permission might be seen as a mercurial 'change', so >> # we avoid adding execute permission to repository files. But testing >> # from a plain source tree needs the chmod a+rx. Applying the chmod to >> # all shared libraries not just dll files. And with CYGWIN and sshd >> # service, you may need CYGWIN=ntsec for this to work. >> prep: >> @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >> @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >> @if [ ! -d $(TEST_ROOT)/../.hg ] ; >> then \ >> $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name >> \*.so \) \ >> -exec $(CHMOD) a+rx {} \; >> ; \ >> fi >> >> >> This part seems to be responsible for changing the permissions on the >> said lib files. That said, TestCommon.gmk is essentially the same as >> it was in jdk10 unconsolidated, but yet the problem cannot be >> reporoduced in the latest unconsolidated jdk10 repo. So, I believe >> something is up. More specifically, this test: >> >> if [ ! -d $(TEST_ROOT)/../.hg ] ; >> then \ >> >> was probably failing before, causing the permission changing branch >> not to be taken? >> >> Maurizio >> >> >> On 26/09/17 12:10, Maurizio Cimadamore wrote: >>> >>> >>> On 26/09/17 07:13, Alan Bateman wrote: >>>> >>>> >>>> On 25/09/2017 21:35, Maurizio Cimadamore wrote: >>>>> >>>>> >>>>> On 25/09/17 20:58, Alan Bateman wrote: >>>>>> >>>>>> >>>>>> On 25/09/2017 20:11, Jonathan Gibbons wrote: >>>>>>> Erik, >>>>>>> >>>>>>> It could be a feature of the build (i.e. test makefiles) to >>>>>>> verify that no source-controlled files were modified in the >>>>>>> course of a test run. >>>>>> Something fishy in this thread as these tests have historically >>>>>> not changed the permissions of these libraries. So I'm curious >>>>>> how they were run, I wonder in case they were changed by a make >>>>>> file instead. >>>>> make test TEST=jdk_lang >>>>> >>>>> AFAIK, this should be the correct way of invoking tests from make? >>>> I assume this make file must be running chmod, not the tests >>>> themselves as otherwise this issue would have been noticed a long >>>> time ago. I suspect many people run jtreg directly in their local >>>> environment rather than the make file. >>> Note that I've been running tests this way over the last 2-3 years, >>> and this only started to happen after the move to consolidated repo. >>> That's why I correlated the two things. >>> >>> Maurizio >>>> >>>> In any case, these older tests predate build test support for >>>> compiling native code and probably should be migrated anyway. >>>> >>>> -Alan >>> >> > From david.holmes at oracle.com Wed Sep 27 09:38:58 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 19:38:58 +1000 Subject: RFR: JDK-8188012 Nashorn build targets version 9 source In-Reply-To: <1b7a7b4e-e296-d4fe-85b0-2428d688bba4@oracle.com> References: <1b7a7b4e-e296-d4fe-85b0-2428d688bba4@oracle.com> Message-ID: <5060f9a5-4451-ec6b-e212-51dc17ad2d6e@oracle.com> On 27/09/2017 7:26 PM, Magnus Ihse Bursie wrote: > On 2017-09-27 10:55, David Holmes wrote: >> On 27/09/2017 6:30 PM, Magnus Ihse Bursie wrote: >>> >>> The nashorn java code requires a somewhat convoluted compilation. As >>> a result, we use a special java compiler setup, >>> GENERATE_NEWBYTECODE_DEBUG. This explicitly lists -source 9 -target >>> 9, which generates this warning: >>> >>> warning: [options] bootstrap class path not set in conjunction with >>> -source 1.9 >>> >>> when building in jdk10. I assume this is just a mistake, and that it >>> should really target 10. (Or, to always be in sync, perhaps even >>> $(VERSION_MAJOR)). >> >> Seems like a reasonable assumption. Though one has to wonder why we >> even set the source/target? That would only be necessary if we needed >> to force building to an older level. I think these could just be removed. > > Historically, we have told javac explicitly which source/target version > to use, instead of relying on the default. (This is not the only place > we have this hard-coded in.) > > We should change this behavior. I've created > https://bugs.openjdk.java.net/browse/JDK-8188015 to track this. Okay. Thanks, David > /Magnus > > > >> >> Cheers, >> David >> >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188012 >>> Patch inline: >>> diff --git a/make/BuildNashorn.gmk b/make/BuildNashorn.gmk >>> --- a/make/BuildNashorn.gmk >>> +++ b/make/BuildNashorn.gmk >>> @@ -41,7 +41,7 @@ >>> ??$(eval $(call SetupJavaCompiler, GENERATE_NEWBYTECODE_DEBUG, \ >>> ????? JVM := $(JAVA_JAVAC), \ >>> ????? JAVAC := $(NEW_JAVAC), \ >>> -??? FLAGS := -g -source 9 -target 9 --upgrade-module-path >>> "$(JDK_OUTPUTDIR)/modules/" \ >>> +??? FLAGS := -g -source 10 -target 10 --upgrade-module-path >>> "$(JDK_OUTPUTDIR)/modules/" \ >>> ?????????? --system none --module-source-path $(call >>> GetModuleSrcPath), \ >>> ????? SERVER_DIR := $(SJAVAC_SERVER_DIR), \ >>> ????? SERVER_JVM := $(SJAVAC_SERVER_JAVA))) >>> >>> /Magnus > From maurizio.cimadamore at oracle.com Wed Sep 27 09:46:53 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Sep 2017 10:46:53 +0100 Subject: permission issues when running make Message-ID: Hi, I sometimes encounter this (consolidated repo only): $ make /usr/bin/tee: /bin/mkdir: /build.logcannot create directory ?/make-support?: Permission denied: Permission denied /usr/bin/tee: /build.log: Permission denied Building target 'default (exploded-image)' in configuration 'linux-x86_64-normal-server-release' /w/lt/amber/dev/make/Init.gmk:291: recipe for target 'main' failed make[1]: *** [main] Error 1 This goes away if I do a full configure. Why is the build attempting to create folders into '/' ? Maurizio From david.holmes at oracle.com Wed Sep 27 09:51:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 19:51:00 +1000 Subject: permission issues when running make In-Reply-To: References: Message-ID: On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: > Hi, > I sometimes encounter this (consolidated repo only): > > $ make > /usr/bin/tee: /bin/mkdir: /build.logcannot create directory > ?/make-support?: Permission denied: Permission denied > > /usr/bin/tee: /build.log: Permission denied > Building target 'default (exploded-image)' in configuration > 'linux-x86_64-normal-server-release' > /w/lt/amber/dev/make/Init.gmk:291: recipe for target 'main' failed > make[1]: *** [main] Error 1 > > > This goes away if I do a full configure. > > Why is the build attempting to create folders into '/' ? That suggests an empty variable is being found. Where are you running make from? David > Maurizio > From jan.lahoda at oracle.com Wed Sep 27 10:01:13 2017 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 27 Sep 2017 12:01:13 +0200 Subject: RFR: JDK-8188013 symbolgenerator targets jdk 9 source In-Reply-To: <55492e65-3161-ad86-a0ab-b875f697ca79@oracle.com> References: <55492e65-3161-ad86-a0ab-b875f697ca79@oracle.com> Message-ID: <59CB76E9.2010406@oracle.com> Looks good. Jan On 27.9.2017 11:29, Magnus Ihse Bursie wrote: > In > make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java, > javac gets called with a fixed command line. This includes the arguments > "-source 9 -target 9". While this was fine for jdk9, in jdk10 > this results in the following warning: > > warning: [options] bootstrap class path not set in conjunction with > -source 1.9 > > I presume it is a mistake that this was not updated to -source 10 > -target 10 for jdk10. > > I have verified that the contents of ct.sym has not changed due to this > patch. > > I have kept the -source/-target arguments for now, and postponed the > discussion to remove them to JDK-8188015. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188013 > Patch inline: > diff --git > a/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > b/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > --- > a/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > +++ > b/make/langtools/src/classes/build/tools/symbolgenerator/TransitiveDependencies.java > @@ -57,8 +57,8 @@ > } > > JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); > - List options = Arrays.asList("-source", "9", > - "-target", "9", > + List options = Arrays.asList("-source", "10", > + "-target", "10", > "-proc:only", > "--system", "none", > "--module-source-path", args[0], > > > /Magnus > From maurizio.cimadamore at oracle.com Wed Sep 27 10:19:22 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Sep 2017 11:19:22 +0100 Subject: permission issues when running make In-Reply-To: References: Message-ID: On 27/09/17 10:51, David Holmes wrote: > On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: >> Hi, >> I sometimes encounter this (consolidated repo only): >> >> $ make >> /usr/bin/tee: /bin/mkdir: /build.logcannot create directory >> ?/make-support?: Permission denied: Permission denied >> >> /usr/bin/tee: /build.log: Permission denied >> Building target 'default (exploded-image)' in configuration >> 'linux-x86_64-normal-server-release' >> /w/lt/amber/dev/make/Init.gmk:291: recipe for target 'main' failed >> make[1]: *** [main] Error 1 >> >> >> This goes away if I do a full configure. >> >> Why is the build attempting to create folders into '/' ? > > That suggests an empty variable is being found. > > Where are you running make from? jdk toplevel folder. After running sh configure ... and repeating same command, the issue goes away. The last time I got this I brought the repo over (rsaync) form another machine (which I used to do all the time even before, but never caused such issues). Maurizio > > David > >> Maurizio >> From david.holmes at oracle.com Wed Sep 27 10:24:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Sep 2017 20:24:27 +1000 Subject: permission issues when running make In-Reply-To: References: Message-ID: <1ac0f7cc-8f70-30a8-c4c2-7b70709709da@oracle.com> On 27/09/2017 8:19 PM, Maurizio Cimadamore wrote: > On 27/09/17 10:51, David Holmes wrote: >> On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: >>> Hi, >>> I sometimes encounter this (consolidated repo only): >>> >>> $ make >>> /usr/bin/tee: /bin/mkdir: /build.logcannot create directory >>> ?/make-support?: Permission denied: Permission denied >>> >>> /usr/bin/tee: /build.log: Permission denied >>> Building target 'default (exploded-image)' in configuration >>> 'linux-x86_64-normal-server-release' >>> /w/lt/amber/dev/make/Init.gmk:291: recipe for target 'main' failed >>> make[1]: *** [main] Error 1 >>> >>> >>> This goes away if I do a full configure. >>> >>> Why is the build attempting to create folders into '/' ? >> >> That suggests an empty variable is being found. >> >> Where are you running make from? > jdk toplevel folder. As in a repo top-level folder I assume? > After running > > sh configure ... > > and repeating same command, the issue goes away. > > The last time I got this I brought the repo over (rsaync) form another > machine (which I used to do all the time even before, but never caused > such issues). Did a configuration exist when you ran it? The output seems odd. If I run with a config present the first thing I see is: Building target 'default (product-bundles test-bundles docs-bundles)' in configuration 'linux-x64-open-debug' and if no config then: Error: No configurations found for /export/users/dh198349/valhalla-master. Please run 'bash configure' to create a configuration. Anything odd set in your environment? David > Maurizio >> >> David >> >>> Maurizio >>> > From maurizio.cimadamore at oracle.com Wed Sep 27 10:45:20 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Sep 2017 11:45:20 +0100 Subject: permission issues when running make In-Reply-To: <1ac0f7cc-8f70-30a8-c4c2-7b70709709da@oracle.com> References: <1ac0f7cc-8f70-30a8-c4c2-7b70709709da@oracle.com> Message-ID: On a problematic repo I tried to compare the spec.gmk before/after the configure run - there's a difference which seems to be causing this issue: The buggy spec.gmk (which causes the permission issues) has this: BUILD_OUTPUT:=/w/master/build/linux-x86_64-normal-server-release # Colon left out to be able to override IMAGES_OUTPUTDIR for bootcycle-images SUPPORT_OUTPUTDIR=$(BUILD_OUTPUT)/support BUILDTOOLS_OUTPUTDIR=$(BUILD_OUTPUT)/buildtools HOTSPOT_OUTPUTDIR=$(BUILD_OUTPUT)/hotspot JDK_OUTPUTDIR=$(BUILD_OUTPUT)/jdk IMAGES_OUTPUTDIR=$(BUILD_OUTPUT)/images BUNDLES_OUTPUTDIR=$(BUILD_OUTPUT)/bundles TESTMAKE_OUTPUTDIR=$(BUILD_OUTPUT)/test-make MAKESUPPORT_OUTPUTDIR=$(BUILD_OUTPUT)/make-support while the new one has this: OUTPUTDIR := /w/master/build/linux-x86_64-normal-server-release # Colon left out to be able to override IMAGES_OUTPUTDIR for bootcycle-images SUPPORT_OUTPUTDIR=$(OUTPUTDIR)/support BUILDTOOLS_OUTPUTDIR=$(OUTPUTDIR)/buildtools HOTSPOT_OUTPUTDIR=$(OUTPUTDIR)/hotspot JDK_OUTPUTDIR=$(OUTPUTDIR)/jdk IMAGES_OUTPUTDIR=$(OUTPUTDIR)/images BUNDLES_OUTPUTDIR=$(OUTPUTDIR)/bundles TESTMAKE_OUTPUTDIR=$(OUTPUTDIR)/test-make MAKESUPPORT_OUTPUTDIR=$(OUTPUTDIR)/make-support Seems like BUILD_OUTPUT was renamed into OUTPUTDIR ? Still, not 100% what's up. Maurizio On 27/09/17 11:24, David Holmes wrote: > On 27/09/2017 8:19 PM, Maurizio Cimadamore wrote: >> On 27/09/17 10:51, David Holmes wrote: >>> On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: >>>> Hi, >>>> I sometimes encounter this (consolidated repo only): >>>> >>>> $ make >>>> /usr/bin/tee: /bin/mkdir: /build.logcannot create directory >>>> ?/make-support?: Permission denied: Permission denied >>>> >>>> /usr/bin/tee: /build.log: Permission denied >>>> Building target 'default (exploded-image)' in configuration >>>> 'linux-x86_64-normal-server-release' >>>> /w/lt/amber/dev/make/Init.gmk:291: recipe for target 'main' failed >>>> make[1]: *** [main] Error 1 >>>> >>>> >>>> This goes away if I do a full configure. >>>> >>>> Why is the build attempting to create folders into '/' ? >>> >>> That suggests an empty variable is being found. >>> >>> Where are you running make from? >> jdk toplevel folder. > > As in a repo top-level folder I assume? > >> After running >> >> sh configure ... >> >> and repeating same command, the issue goes away. >> >> The last time I got this I brought the repo over (rsaync) form >> another machine (which I used to do all the time even before, but >> never caused such issues). > > Did a configuration exist when you ran it? The output seems odd. If I > run with a config present the first thing I see is: > > Building target 'default (product-bundles test-bundles docs-bundles)' > in configuration 'linux-x64-open-debug' > > and if no config then: > > Error: No configurations found for > /export/users/dh198349/valhalla-master. > Please run 'bash configure' to create a configuration. > > Anything odd set in your environment? > > David > >> Maurizio >>> >>> David >>> >>>> Maurizio >>>> >> From maurizio.cimadamore at oracle.com Wed Sep 27 10:53:27 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 27 Sep 2017 11:53:27 +0100 Subject: permission issues when running make In-Reply-To: References: <1ac0f7cc-8f70-30a8-c4c2-7b70709709da@oracle.com> Message-ID: <2d834f3f-832e-9fc1-d501-682522509949@oracle.com> ah - got it the script I use for rsyncing was excluding all stuff in build/** - meaning that I ended up with an inconsistent spec.gmk. Apparently, the name of this variable changed: http://hg.openjdk.java.net/jdk10/master/rev/92fd0e04e0e1 And so my sync setup flaw was exposed. Sorry for the noise. Maurizio On 27/09/17 11:45, Maurizio Cimadamore wrote: > On a problematic repo I tried to compare the spec.gmk before/after the > configure run - there's a difference which seems to be causing this > issue: > > The buggy spec.gmk (which causes the permission issues) has this: > > BUILD_OUTPUT:=/w/master/build/linux-x86_64-normal-server-release > # Colon left out to be able to override IMAGES_OUTPUTDIR for > bootcycle-images > SUPPORT_OUTPUTDIR=$(BUILD_OUTPUT)/support > BUILDTOOLS_OUTPUTDIR=$(BUILD_OUTPUT)/buildtools > > HOTSPOT_OUTPUTDIR=$(BUILD_OUTPUT)/hotspot > JDK_OUTPUTDIR=$(BUILD_OUTPUT)/jdk > IMAGES_OUTPUTDIR=$(BUILD_OUTPUT)/images > BUNDLES_OUTPUTDIR=$(BUILD_OUTPUT)/bundles > TESTMAKE_OUTPUTDIR=$(BUILD_OUTPUT)/test-make > MAKESUPPORT_OUTPUTDIR=$(BUILD_OUTPUT)/make-support > > while the new one has this: > > OUTPUTDIR := /w/master/build/linux-x86_64-normal-server-release > # Colon left out to be able to override IMAGES_OUTPUTDIR for > bootcycle-images > SUPPORT_OUTPUTDIR=$(OUTPUTDIR)/support > BUILDTOOLS_OUTPUTDIR=$(OUTPUTDIR)/buildtools > > HOTSPOT_OUTPUTDIR=$(OUTPUTDIR)/hotspot > JDK_OUTPUTDIR=$(OUTPUTDIR)/jdk > IMAGES_OUTPUTDIR=$(OUTPUTDIR)/images > BUNDLES_OUTPUTDIR=$(OUTPUTDIR)/bundles > TESTMAKE_OUTPUTDIR=$(OUTPUTDIR)/test-make > MAKESUPPORT_OUTPUTDIR=$(OUTPUTDIR)/make-support > > > Seems like BUILD_OUTPUT was renamed into OUTPUTDIR ? > > Still, not 100% what's up. > > Maurizio > > > On 27/09/17 11:24, David Holmes wrote: >> On 27/09/2017 8:19 PM, Maurizio Cimadamore wrote: >>> On 27/09/17 10:51, David Holmes wrote: >>>> On 27/09/2017 7:46 PM, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> I sometimes encounter this (consolidated repo only): >>>>> >>>>> $ make >>>>> /usr/bin/tee: /bin/mkdir: /build.logcannot create directory >>>>> ?/make-support?: Permission denied: Permission denied >>>>> >>>>> /usr/bin/tee: /build.log: Permission denied >>>>> Building target 'default (exploded-image)' in configuration >>>>> 'linux-x86_64-normal-server-release' >>>>> /w/lt/amber/dev/make/Init.gmk:291: recipe for target 'main' failed >>>>> make[1]: *** [main] Error 1 >>>>> >>>>> >>>>> This goes away if I do a full configure. >>>>> >>>>> Why is the build attempting to create folders into '/' ? >>>> >>>> That suggests an empty variable is being found. >>>> >>>> Where are you running make from? >>> jdk toplevel folder. >> >> As in a repo top-level folder I assume? >> >>> After running >>> >>> sh configure ... >>> >>> and repeating same command, the issue goes away. >>> >>> The last time I got this I brought the repo over (rsaync) form >>> another machine (which I used to do all the time even before, but >>> never caused such issues). >> >> Did a configuration exist when you ran it? The output seems odd. If I >> run with a config present the first thing I see is: >> >> Building target 'default (product-bundles test-bundles docs-bundles)' >> in configuration 'linux-x64-open-debug' >> >> and if no config then: >> >> Error: No configurations found for >> /export/users/dh198349/valhalla-master. >> Please run 'bash configure' to create a configuration. >> >> Anything odd set in your environment? >> >> David >> >>> Maurizio >>>> >>>> David >>>> >>>>> Maurizio >>>>> >>> > From magnus.ihse.bursie at oracle.com Wed Sep 27 13:41:19 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 15:41:19 +0200 Subject: RFR: JDK-8188034 InitSupport does not properly include closed file Message-ID: <3b556c55-75d0-f911-7ab7-517549fdbd43@oracle.com> After the forest consolidation, InitSupport.gmk does not properly include the closed file, since it's not using the normal inclusion mechanism (due to the SPEC not being available yet). Bug: https://bugs.openjdk.java.net/browse/JDK-8188034 Patch inline: diff --git a/make/InitSupport.gmk b/make/InitSupport.gmk --- a/make/InitSupport.gmk +++ b/make/InitSupport.gmk @@ -36,7 +36,7 @@ ?? # Include the corresponding closed file, if present. ?? # Normal hook mechanism cannot be used since we have no SPEC. -? -include $(topdir)/closed/make/InitSupport.gmk +? -include $(topdir)/../closed/make/InitSupport.gmk ############################################################################## ?? # Helper functions for the initial part of Init.gmk, before the spec file is /Magnus From tim.bell at oracle.com Wed Sep 27 14:05:25 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 27 Sep 2017 07:05:25 -0700 Subject: RFR: JDK-8188034 InitSupport does not properly include closed file In-Reply-To: <3b556c55-75d0-f911-7ab7-517549fdbd43@oracle.com> References: <3b556c55-75d0-f911-7ab7-517549fdbd43@oracle.com> Message-ID: <59CBB025.3060101@oracle.com> Magnus: > After the forest consolidation, InitSupport.gmk does not properly > include the closed file, since it's not using the normal inclusion > mechanism (due to the SPEC not being available yet). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188034 > Patch inline: > diff --git a/make/InitSupport.gmk b/make/InitSupport.gmk > --- a/make/InitSupport.gmk > +++ b/make/InitSupport.gmk > @@ -36,7 +36,7 @@ > > # Include the corresponding closed file, if present. > # Normal hook mechanism cannot be used since we have no SPEC. > - -include $(topdir)/closed/make/InitSupport.gmk > + -include $(topdir)/../closed/make/InitSupport.gmk > > ############################################################################## > > # Helper functions for the initial part of Init.gmk, before the spec > file is > > /Magnus Looks good. /Tim From erik.joelsson at oracle.com Wed Sep 27 14:12:59 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 27 Sep 2017 16:12:59 +0200 Subject: RFR: JDK-8188034 InitSupport does not properly include closed file In-Reply-To: <3b556c55-75d0-f911-7ab7-517549fdbd43@oracle.com> References: <3b556c55-75d0-f911-7ab7-517549fdbd43@oracle.com> Message-ID: <2de43dea-6c9c-e47c-01e0-cfc1cf9952fd@oracle.com> Ouch, looks good. /Erik On 2017-09-27 15:41, Magnus Ihse Bursie wrote: > After the forest consolidation, InitSupport.gmk does not properly > include the closed file, since it's not using the normal inclusion > mechanism (due to the SPEC not being available yet). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188034 > Patch inline: > diff --git a/make/InitSupport.gmk b/make/InitSupport.gmk > --- a/make/InitSupport.gmk > +++ b/make/InitSupport.gmk > @@ -36,7 +36,7 @@ > > # Include the corresponding closed file, if present. > # Normal hook mechanism cannot be used since we have no SPEC. > - -include $(topdir)/closed/make/InitSupport.gmk > + -include $(topdir)/../closed/make/InitSupport.gmk > > ############################################################################## > > # Helper functions for the initial part of Init.gmk, before the > spec file is > > /Magnus > From glaubitz at physik.fu-berlin.de Wed Sep 27 16:40:38 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 27 Sep 2017 18:40:38 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code Message-ID: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> Hello! Zero currently fails to build on linux-sparc since there are two instances where SPARC-specific defines conflict with the Zero code. One instance is src/hotspot/share/compiler/oopMap.cpp where a header is uncondtionally included for SPARC which is not available for Zero. It turns out that this header, vmreg_sparc.inline.hpp, does actually not need to be included here. So, easiest part is just to remove the inclusion of this header: @@ -38,13 +38,10 @@ #include "c1/c1_Defs.hpp" #endif #ifdef COMPILER2 #include "opto/optoreg.hpp" #endif -#ifdef SPARC -#include "vmreg_sparc.inline.hpp" -#endif The second instance is src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp which is not included in the build for Zero. However, we always need to include it because of the particular implementation of memset() on SPARC which does not work well with concurrent readers which is why memset_with_concurrent_readers.hpp looks like this: #ifdef SPARC // SPARC requires special handling. See SPARC-specific definition. #else // All others just use memset. inline void memset_with_concurrent_readers(void* to, int value, size_t size) { ::memset(to, value, size); } #endif // End of target dispatch. The webrev to fix the Zero build on SPARC includes both changes and can be found in [1]. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.02/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Wed Sep 27 16:46:11 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 17:46:11 +0100 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> Message-ID: <8b8012ae-a7bf-1c8a-c498-0630168dd2c4@redhat.com> On 27/09/17 17:40, John Paul Adrian Glaubitz wrote: > The webrev to fix the Zero build on SPARC includes both changes and can be found > in [1]. That looks right, but I think the release JDK 9 is done. We'll have to stage the fix for the JDK 9 updates project. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Wed Sep 27 16:47:58 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 27 Sep 2017 18:47:58 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <8b8012ae-a7bf-1c8a-c498-0630168dd2c4@redhat.com> References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> <8b8012ae-a7bf-1c8a-c498-0630168dd2c4@redhat.com> Message-ID: On 09/27/2017 06:46 PM, Andrew Haley wrote: > On 27/09/17 17:40, John Paul Adrian Glaubitz wrote: >> The webrev to fix the Zero build on SPARC includes both changes and can be found >> in [1]. > > That looks right, but I think the release JDK 9 is done. We'll have > to stage the fix for the JDK 9 updates project. That was supposed to go into JDK10. Isn't that still open? -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Wed Sep 27 16:52:53 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Sep 2017 17:52:53 +0100 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> <8b8012ae-a7bf-1c8a-c498-0630168dd2c4@redhat.com> Message-ID: <2f4723ca-cfdd-5721-1417-2080c8753dc7@redhat.com> On 27/09/17 17:47, John Paul Adrian Glaubitz wrote: > On 09/27/2017 06:46 PM, Andrew Haley wrote: >> On 27/09/17 17:40, John Paul Adrian Glaubitz wrote: >>> The webrev to fix the Zero build on SPARC includes both changes and can be found >>> in [1]. >> >> That looks right, but I think the release JDK 9 is done. We'll have >> to stage the fix for the JDK 9 updates project. > > That was supposed to go into JDK10. Isn't that still open? Ah, OK. It is now, yes. jdk10-hs reopened a couple of days ago. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Wed Sep 27 18:51:20 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 27 Sep 2017 14:51:20 -0400 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> Message-ID: <474BDE59-253E-4C34-8D40-626EADBF84FC@oracle.com> > On Sep 27, 2017, at 12:40 PM, John Paul Adrian Glaubitz wrote: > > Hello! > > Zero currently fails to build on linux-sparc since there are two instances where > SPARC-specific defines conflict with the Zero code. > > [?] > The webrev to fix the Zero build on SPARC includes both changes and can be found > in [1]. > > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.02/ > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Looks good. Please update the copyright in oopMap.cpp. From magnus.ihse.bursie at oracle.com Wed Sep 27 19:47:39 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 27 Sep 2017 21:47:39 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> Message-ID: <1c0bea33-bcc5-ce78-874b-e3d277de5dae@oracle.com> Build change looks good. /Magnus On 2017-09-27 18:40, John Paul Adrian Glaubitz wrote: > Hello! > > Zero currently fails to build on linux-sparc since there are two > instances where > SPARC-specific defines conflict with the Zero code. > > One instance is src/hotspot/share/compiler/oopMap.cpp where a header > is uncondtionally > included for SPARC which is not available for Zero. It turns out that > this header, > vmreg_sparc.inline.hpp, does actually not need to be included here. > So, easiest > part is just to remove the inclusion of this header: > > @@ -38,13 +38,10 @@ > ?#include "c1/c1_Defs.hpp" > ?#endif > ?#ifdef COMPILER2 > ?#include "opto/optoreg.hpp" > ?#endif > -#ifdef SPARC > -#include "vmreg_sparc.inline.hpp" > -#endif > > The second instance is > src/hotspot/cpu/sparc/memset_with_concurrent_readers_sparc.cpp > which is not included in the build for Zero. However, we always need > to include it > because of the particular implementation of memset() on SPARC which > does not work > well with concurrent readers which is why > memset_with_concurrent_readers.hpp looks > like this: > > #ifdef SPARC > > // SPARC requires special handling.? See SPARC-specific definition. > > #else > // All others just use memset. > > inline void memset_with_concurrent_readers(void* to, int value, size_t > size) { > ? ::memset(to, value, size); > } > > #endif // End of target dispatch. > > The webrev to fix the Zero build on SPARC includes both changes and > can be found > in [1]. > > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.02/ > From glaubitz at physik.fu-berlin.de Wed Sep 27 19:57:53 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 27 Sep 2017 21:57:53 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <474BDE59-253E-4C34-8D40-626EADBF84FC@oracle.com> References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> <474BDE59-253E-4C34-8D40-626EADBF84FC@oracle.com> Message-ID: <32e954b6-b544-43e4-b565-01a787371a7e@physik.fu-berlin.de> Hi Kim! On 09/27/2017 08:51 PM, Kim Barrett wrote: > Looks good. > > Please update the copyright in oopMap.cpp. Done [1]. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8186578/webrev.03/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Sep 27 20:11:53 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 27 Sep 2017 22:11:53 +0200 Subject: [RFR]: 8186578: Zero fails to build on linux-sparc due to sparc-specific code In-Reply-To: <32e954b6-b544-43e4-b565-01a787371a7e@physik.fu-berlin.de> References: <1655822b-bebb-44bb-a45e-56b115fe8490@physik.fu-berlin.de> <474BDE59-253E-4C34-8D40-626EADBF84FC@oracle.com> <32e954b6-b544-43e4-b565-01a787371a7e@physik.fu-berlin.de> Message-ID: On 09/27/2017 09:57 PM, John Paul Adrian Glaubitz wrote:> On 09/27/2017 08:51 PM, Kim Barrett wrote: >> Looks good. >> >> Please update the copyright in oopMap.cpp. > > Done [1]. Just a second, please. I just ran into build errors. Please don't merge as is. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From maurizio.cimadamore at oracle.com Thu Sep 28 08:49:36 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Sep 2017 09:49:36 +0100 Subject: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes Message-ID: Hi, this fixes the problem of the build changing permissions on some library files when executing tests [1, 2]. The issue is that a relative path in TestCommon is bogus - jdk tests are now executed in the folder test/jdk, so there's no longer hg repo under ../ Patch inline below: diff -r 355349babaf4 test/TestCommon.gmk --- a/test/TestCommon.gmk??? Wed Sep 27 16:47:07 2017 -0700 +++ b/test/TestCommon.gmk??? Thu Sep 28 09:44:09 2017 +0100 @@ -273,7 +273,7 @@ ?prep: ???? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) ???? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` -??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; then?????????????????????????????????? \ +??? @if [ ! -d $(TEST_ROOT)/../../.hg ] ; then?????????????????????????????????? \ ???? ? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name \*.so \)? \ ???? ??????? -exec $(CHMOD) a+rx {} \; ;?????????????????????????????????????? \ ???? fi Cheers Maurizio [1] - http://mail.openjdk.java.net/pipermail/build-dev/2017-September/019796.html [2] - https://bugs.openjdk.java.net/browse/JDK-8188090 From erik.joelsson at oracle.com Thu Sep 28 09:25:08 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Sep 2017 11:25:08 +0200 Subject: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes In-Reply-To: References: Message-ID: <85fd1f2f-825f-2a2a-e717-853f0e5a33e9@oracle.com> I think you need to also check for "../../../.hg" as the relative path from the hotspot test root is one level deeper than the other repositories. The hotspot tests are probably free of such binaries, but even so we should avoid running this when not needed. /Erik On 2017-09-28 10:49, Maurizio Cimadamore wrote: > Hi, > this fixes the problem of the build changing permissions on some > library files when executing tests [1, 2]. > > The issue is that a relative path in TestCommon is bogus - jdk tests > are now executed in the folder test/jdk, so there's no longer hg repo > under ../ > > Patch inline below: > > diff -r 355349babaf4 test/TestCommon.gmk > --- a/test/TestCommon.gmk Wed Sep 27 16:47:07 2017 -0700 > +++ b/test/TestCommon.gmk Thu Sep 28 09:44:09 2017 +0100 > @@ -273,7 +273,7 @@ > prep: > @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) > @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` > - @if [ ! -d $(TEST_ROOT)/../.hg ] ; > then \ > + @if [ ! -d $(TEST_ROOT)/../../.hg ] ; > then \ > $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name > \*.so \) \ > -exec $(CHMOD) a+rx {} \; > ; \ > fi > > > Cheers > Maurizio > > > [1] - > http://mail.openjdk.java.net/pipermail/build-dev/2017-September/019796.html > [2] - https://bugs.openjdk.java.net/browse/JDK-8188090 > From maurizio.cimadamore at oracle.com Thu Sep 28 09:27:17 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Sep 2017 10:27:17 +0100 Subject: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes In-Reply-To: <85fd1f2f-825f-2a2a-e717-853f0e5a33e9@oracle.com> References: <85fd1f2f-825f-2a2a-e717-853f0e5a33e9@oracle.com> Message-ID: On 28/09/17 10:25, Erik Joelsson wrote: > I think you need to also check for "../../../.hg" as the relative path > from the hotspot test root is one level deeper than the other > repositories. The hotspot tests are probably free of such binaries, > but even so we should avoid running this when not needed. Isn't that too fragile? What if I'm running jdk tests but my repo is nested inside some other repo? Maurizio > > /Erik > > > On 2017-09-28 10:49, Maurizio Cimadamore wrote: >> Hi, >> this fixes the problem of the build changing permissions on some >> library files when executing tests [1, 2]. >> >> The issue is that a relative path in TestCommon is bogus - jdk tests >> are now executed in the folder test/jdk, so there's no longer hg repo >> under ../ >> >> Patch inline below: >> >> diff -r 355349babaf4 test/TestCommon.gmk >> --- a/test/TestCommon.gmk??? Wed Sep 27 16:47:07 2017 -0700 >> +++ b/test/TestCommon.gmk??? Thu Sep 28 09:44:09 2017 +0100 >> @@ -273,7 +273,7 @@ >> ?prep: >> ???? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >> ???? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >> -??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; >> then?????????????????????????????????? \ >> +??? @if [ ! -d $(TEST_ROOT)/../../.hg ] ; >> then?????????????????????????????????? \ >> ?????? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name >> \*.so \)? \ >> ???????????? -exec $(CHMOD) a+rx {} \; >> ;?????????????????????????????????????? \ >> ???? fi >> >> >> Cheers >> Maurizio >> >> >> [1] - >> http://mail.openjdk.java.net/pipermail/build-dev/2017-September/019796.html >> [2] - https://bugs.openjdk.java.net/browse/JDK-8188090 >> > From maurizio.cimadamore at oracle.com Thu Sep 28 09:49:36 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Sep 2017 10:49:36 +0100 Subject: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes In-Reply-To: References: <85fd1f2f-825f-2a2a-e717-853f0e5a33e9@oracle.com> Message-ID: <08906a13-63f0-8208-a007-403785fd3851@oracle.com> This is a modified patch that takes into account hotspot tests: diff -r 355349babaf4 test/TestCommon.gmk --- a/test/TestCommon.gmk??? Wed Sep 27 16:47:07 2017 -0700 +++ b/test/TestCommon.gmk??? Thu Sep 28 10:47:00 2017 +0100 @@ -273,7 +273,7 @@ ?prep: ???? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) ???? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` -??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; then?????????????????????????????????? \ +??? @if [ ! -d $(TEST_ROOT)/../../.hg ] && [ ! -d $(TEST_ROOT)/../../../.hg ]; then? \ ???? ? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name \*.so \)? \ ???? ??????? -exec $(CHMOD) a+rx {} \; ;?????????????????????????????????????? \ ???? fi I've run a find for all test roots and got this: test/langtools/TEST.ROOT test/failure_handler/test/TEST.ROOT test/jaxp/TEST.ROOT test/nashorn/TEST.ROOT test/hotspot/jtreg/TEST.ROOT test/jdk/TEST.ROOT So, it seems like we should cover all cases with the test above (albeit still a bit uncomfortable with the idea that this patch would potentially peek outside the repo). Maurizio On 28/09/17 10:27, Maurizio Cimadamore wrote: > > > On 28/09/17 10:25, Erik Joelsson wrote: >> I think you need to also check for "../../../.hg" as the relative >> path from the hotspot test root is one level deeper than the other >> repositories. The hotspot tests are probably free of such binaries, >> but even so we should avoid running this when not needed. > Isn't that too fragile? What if I'm running jdk tests but my repo is > nested inside some other repo? > > Maurizio >> >> /Erik >> >> >> On 2017-09-28 10:49, Maurizio Cimadamore wrote: >>> Hi, >>> this fixes the problem of the build changing permissions on some >>> library files when executing tests [1, 2]. >>> >>> The issue is that a relative path in TestCommon is bogus - jdk tests >>> are now executed in the folder test/jdk, so there's no longer hg >>> repo under ../ >>> >>> Patch inline below: >>> >>> diff -r 355349babaf4 test/TestCommon.gmk >>> --- a/test/TestCommon.gmk??? Wed Sep 27 16:47:07 2017 -0700 >>> +++ b/test/TestCommon.gmk??? Thu Sep 28 09:44:09 2017 +0100 >>> @@ -273,7 +273,7 @@ >>> ?prep: >>> ???? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >>> ???? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >>> -??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; >>> then?????????????????????????????????? \ >>> +??? @if [ ! -d $(TEST_ROOT)/../../.hg ] ; >>> then?????????????????????????????????? \ >>> ?????? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name >>> \*.so \)? \ >>> ???????????? -exec $(CHMOD) a+rx {} \; >>> ;?????????????????????????????????????? \ >>> ???? fi >>> >>> >>> Cheers >>> Maurizio >>> >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/build-dev/2017-September/019796.html >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8188090 >>> >> > From erik.joelsson at oracle.com Thu Sep 28 10:14:52 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Sep 2017 12:14:52 +0200 Subject: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes In-Reply-To: <08906a13-63f0-8208-a007-403785fd3851@oracle.com> References: <85fd1f2f-825f-2a2a-e717-853f0e5a33e9@oracle.com> <08906a13-63f0-8208-a007-403785fd3851@oracle.com> Message-ID: <76d39cef-f066-7a41-eeb1-ef68ffc1dec0@oracle.com> Looks good enough to me. The long term plan is to migrate to the new run-test framework for running tests so I'm fine with this being a bit crude. /Erik On 2017-09-28 11:49, Maurizio Cimadamore wrote: > This is a modified patch that takes into account hotspot tests: > > diff -r 355349babaf4 test/TestCommon.gmk > --- a/test/TestCommon.gmk Wed Sep 27 16:47:07 2017 -0700 > +++ b/test/TestCommon.gmk Thu Sep 28 10:47:00 2017 +0100 > @@ -273,7 +273,7 @@ > prep: > @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) > @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` > - @if [ ! -d $(TEST_ROOT)/../.hg ] ; > then \ > + @if [ ! -d $(TEST_ROOT)/../../.hg ] && [ ! -d > $(TEST_ROOT)/../../../.hg ]; then \ > $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name > \*.so \) \ > -exec $(CHMOD) a+rx {} \; > ; \ > fi > > > I've run a find for all test roots and got this: > > test/langtools/TEST.ROOT > test/failure_handler/test/TEST.ROOT > test/jaxp/TEST.ROOT > test/nashorn/TEST.ROOT > test/hotspot/jtreg/TEST.ROOT > test/jdk/TEST.ROOT > > So, it seems like we should cover all cases with the test above > (albeit still a bit uncomfortable with the idea that this patch would > potentially peek outside the repo). > > Maurizio > > > On 28/09/17 10:27, Maurizio Cimadamore wrote: >> >> >> On 28/09/17 10:25, Erik Joelsson wrote: >>> I think you need to also check for "../../../.hg" as the relative >>> path from the hotspot test root is one level deeper than the other >>> repositories. The hotspot tests are probably free of such binaries, >>> but even so we should avoid running this when not needed. >> Isn't that too fragile? What if I'm running jdk tests but my repo is >> nested inside some other repo? >> >> Maurizio >>> >>> /Erik >>> >>> >>> On 2017-09-28 10:49, Maurizio Cimadamore wrote: >>>> Hi, >>>> this fixes the problem of the build changing permissions on some >>>> library files when executing tests [1, 2]. >>>> >>>> The issue is that a relative path in TestCommon is bogus - jdk >>>> tests are now executed in the folder test/jdk, so there's no longer >>>> hg repo under ../ >>>> >>>> Patch inline below: >>>> >>>> diff -r 355349babaf4 test/TestCommon.gmk >>>> --- a/test/TestCommon.gmk Wed Sep 27 16:47:07 2017 -0700 >>>> +++ b/test/TestCommon.gmk Thu Sep 28 09:44:09 2017 +0100 >>>> @@ -273,7 +273,7 @@ >>>> prep: >>>> @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >>>> @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >>>> - @if [ ! -d $(TEST_ROOT)/../.hg ] ; >>>> then \ >>>> + @if [ ! -d $(TEST_ROOT)/../../.hg ] ; >>>> then \ >>>> $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o >>>> -name \*.so \) \ >>>> -exec $(CHMOD) a+rx {} \; >>>> ; \ >>>> fi >>>> >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> [1] - >>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-September/019796.html >>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8188090 >>>> >>> >> > From maurizio.cimadamore at oracle.com Thu Sep 28 10:21:32 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 Sep 2017 11:21:32 +0100 Subject: RFR: JDK-8188090 Running tests from make causes spurious mercurial changes In-Reply-To: <76d39cef-f066-7a41-eeb1-ef68ffc1dec0@oracle.com> References: <85fd1f2f-825f-2a2a-e717-853f0e5a33e9@oracle.com> <08906a13-63f0-8208-a007-403785fd3851@oracle.com> <76d39cef-f066-7a41-eeb1-ef68ffc1dec0@oracle.com> Message-ID: <6e5b9fd5-0ef0-fd2e-74f9-7f9e4c03fff2@oracle.com> Pushed - thx. One alternate way to handle this would be to use 'hg locate' to see if the lib file is tracked in a more path-independent way. Maurizio On 28/09/17 11:14, Erik Joelsson wrote: > Looks good enough to me. The long term plan is to migrate to the new > run-test framework for running tests so I'm fine with this being a bit > crude. > > /Erik > > > On 2017-09-28 11:49, Maurizio Cimadamore wrote: >> This is a modified patch that takes into account hotspot tests: >> >> diff -r 355349babaf4 test/TestCommon.gmk >> --- a/test/TestCommon.gmk??? Wed Sep 27 16:47:07 2017 -0700 >> +++ b/test/TestCommon.gmk??? Thu Sep 28 10:47:00 2017 +0100 >> @@ -273,7 +273,7 @@ >> ?prep: >> ???? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >> ???? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >> -??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; >> then?????????????????????????????????? \ >> +??? @if [ ! -d $(TEST_ROOT)/../../.hg ] && [ ! -d >> $(TEST_ROOT)/../../../.hg ]; then? \ >> ?????? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o -name >> \*.so \)? \ >> ???????????? -exec $(CHMOD) a+rx {} \; >> ;?????????????????????????????????????? \ >> ???? fi >> >> >> I've run a find for all test roots and got this: >> >> test/langtools/TEST.ROOT >> test/failure_handler/test/TEST.ROOT >> test/jaxp/TEST.ROOT >> test/nashorn/TEST.ROOT >> test/hotspot/jtreg/TEST.ROOT >> test/jdk/TEST.ROOT >> >> So, it seems like we should cover all cases with the test above >> (albeit still a bit uncomfortable with the idea that this patch would >> potentially peek outside the repo). >> >> Maurizio >> >> >> On 28/09/17 10:27, Maurizio Cimadamore wrote: >>> >>> >>> On 28/09/17 10:25, Erik Joelsson wrote: >>>> I think you need to also check for "../../../.hg" as the relative >>>> path from the hotspot test root is one level deeper than the other >>>> repositories. The hotspot tests are probably free of such binaries, >>>> but even so we should avoid running this when not needed. >>> Isn't that too fragile? What if I'm running jdk tests but my repo is >>> nested inside some other repo? >>> >>> Maurizio >>>> >>>> /Erik >>>> >>>> >>>> On 2017-09-28 10:49, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> this fixes the problem of the build changing permissions on some >>>>> library files when executing tests [1, 2]. >>>>> >>>>> The issue is that a relative path in TestCommon is bogus - jdk >>>>> tests are now executed in the folder test/jdk, so there's no >>>>> longer hg repo under ../ >>>>> >>>>> Patch inline below: >>>>> >>>>> diff -r 355349babaf4 test/TestCommon.gmk >>>>> --- a/test/TestCommon.gmk??? Wed Sep 27 16:47:07 2017 -0700 >>>>> +++ b/test/TestCommon.gmk??? Thu Sep 28 09:44:09 2017 +0100 >>>>> @@ -273,7 +273,7 @@ >>>>> ?prep: >>>>> ???? @$(MKDIR) -p $(ABS_TEST_OUTPUT_DIR) >>>>> ???? @$(MKDIR) -p `$(DIRNAME) $(ARCHIVE_BUNDLE)` >>>>> -??? @if [ ! -d $(TEST_ROOT)/../.hg ] ; >>>>> then?????????????????????????????????? \ >>>>> +??? @if [ ! -d $(TEST_ROOT)/../../.hg ] ; >>>>> then?????????????????????????????????? \ >>>>> ?????? $(FIND) $(TEST_ROOT) \( -name \*.dll -o -name \*.DLL -o >>>>> -name \*.so \)? \ >>>>> ???????????? -exec $(CHMOD) a+rx {} \; >>>>> ;?????????????????????????????????????? \ >>>>> ???? fi >>>>> >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>>> >>>>> [1] - >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2017-September/019796.html >>>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8188090 >>>>> >>>> >>> >> > From christian.tornqvist at oracle.com Thu Sep 28 12:41:37 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 28 Sep 2017 08:41:37 -0400 Subject: RFR: 8188038 - Add Windows-x64-open bundles to jib-profiles.js Message-ID: Please review this small change that adds the bundle names for the Windows-x64-open and ri builds to jib-profiles. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8188038/webrev.00/ Thanks, Christian From erik.joelsson at oracle.com Thu Sep 28 13:36:18 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 28 Sep 2017 15:36:18 +0200 Subject: RFR: 8188038 - Add Windows-x64-open bundles to jib-profiles.js In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-09-28 14:41, Christian Tornqvist wrote: > Please review this small change that adds the bundle names for the Windows-x64-open and ri builds to jib-profiles. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8188038/webrev.00/ > > Thanks, > Christian > From erik.joelsson at oracle.com Fri Sep 29 08:45:37 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 Sep 2017 10:45:37 +0200 Subject: RFR: JDK-8188136: jib configure requires --src-dir for out of tree builds Message-ID: <01d60a2b-e87d-6087-68f6-47878071a4fb@oracle.com> This patch makes it possible to run "bash /jib.sh configure" from an out of tree directory, without specifying --src-dir to jib. The framework used for the Jib CLI automatically defines env variables that may provide defaults for each parameter. In this case I use the JIB_SRC_DIR env variable to provide a default for the src dir from the jib launcher script. While in there I noticed that some relative paths were wrong after the consolidation and I fixed those too which also covers JDK-8188123. Webrev: http://cr.openjdk.java.net/~erikj/8188136/webrev.01/ Bugs: https://bugs.openjdk.java.net/browse/JDK-8188136 https://bugs.openjdk.java.net/browse/JDK-8188123 /Erik From david.holmes at oracle.com Fri Sep 29 09:42:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Sep 2017 19:42:34 +1000 Subject: RFR: JDK-8188136: jib configure requires --src-dir for out of tree builds In-Reply-To: <01d60a2b-e87d-6087-68f6-47878071a4fb@oracle.com> References: <01d60a2b-e87d-6087-68f6-47878071a4fb@oracle.com> Message-ID: Looks good Erik. I hadn't spotted the .jib created above my repo tree!! Thanks, David On 29/09/2017 6:45 PM, Erik Joelsson wrote: > This patch makes it possible to run "bash /jib.sh configure" > from an out of tree directory, without specifying --src-dir to jib. The > framework used for the Jib CLI automatically defines env variables that > may provide defaults for each parameter. In this case I use the > JIB_SRC_DIR env variable to provide a default for the src dir from the > jib launcher script. > > While in there I noticed that some relative paths were wrong after the > consolidation and I fixed those too which also covers JDK-8188123. > > Webrev: http://cr.openjdk.java.net/~erikj/8188136/webrev.01/ > Bugs: > https://bugs.openjdk.java.net/browse/JDK-8188136 > https://bugs.openjdk.java.net/browse/JDK-8188123 > > /Erik From tim.bell at oracle.com Fri Sep 29 13:14:39 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 29 Sep 2017 06:14:39 -0700 Subject: RFR: JDK-8188136: jib configure requires --src-dir for out of tree builds In-Reply-To: References: <01d60a2b-e87d-6087-68f6-47878071a4fb@oracle.com> Message-ID: <59CE473F.8080805@oracle.com> Erik- Looks good to me as well. /Tim On 09/29/17 02:42, David Holmes wrote: > Looks good Erik. I hadn't spotted the .jib created above my repo tree!! > > Thanks, > David > > On 29/09/2017 6:45 PM, Erik Joelsson wrote: >> This patch makes it possible to run "bash /jib.sh configure" >> from an out of tree directory, without specifying --src-dir to jib. >> The framework used for the Jib CLI automatically defines env variables >> that may provide defaults for each parameter. In this case I use the >> JIB_SRC_DIR env variable to provide a default for the src dir from the >> jib launcher script. >> >> While in there I noticed that some relative paths were wrong after the >> consolidation and I fixed those too which also covers JDK-8188123. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8188136/webrev.01/ >> Bugs: >> https://bugs.openjdk.java.net/browse/JDK-8188136 >> https://bugs.openjdk.java.net/browse/JDK-8188123 >> >> /Erik From david.holmes at oracle.com Sat Sep 30 02:33:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 30 Sep 2017 12:33:49 +1000 Subject: RFR: JDK-8188136: jib configure requires --src-dir for out of tree builds In-Reply-To: <59CE473F.8080805@oracle.com> References: <01d60a2b-e87d-6087-68f6-47878071a4fb@oracle.com> <59CE473F.8080805@oracle.com> Message-ID: Unfortunately it has broken JPRT Windows builds. David On 29/09/2017 11:14 PM, Tim Bell wrote: > Erik- > > Looks good to me as well. > > /Tim > > On 09/29/17 02:42, David Holmes wrote: >> Looks good Erik. I hadn't spotted the .jib created above my repo tree!! >> >> Thanks, >> David >> >> On 29/09/2017 6:45 PM, Erik Joelsson wrote: >>> This patch makes it possible to run "bash /jib.sh configure" >>> from an out of tree directory, without specifying --src-dir to jib. >>> The framework used for the Jib CLI automatically defines env variables >>> that may provide defaults for each parameter. In this case I use the >>> JIB_SRC_DIR env variable to provide a default for the src dir from the >>> jib launcher script. >>> >>> While in there I noticed that some relative paths were wrong after the >>> consolidation and I fixed those too which also covers JDK-8188123. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8188136/webrev.01/ >>> Bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8188136 >>> https://bugs.openjdk.java.net/browse/JDK-8188123 >>> >>> /Erik > From tim.bell at oracle.com Sat Sep 30 07:28:29 2017 From: tim.bell at oracle.com (Tim Bell) Date: Sat, 30 Sep 2017 00:28:29 -0700 Subject: RFR: JDK-8188136: jib configure requires --src-dir for out of tree builds In-Reply-To: References: <01d60a2b-e87d-6087-68f6-47878071a4fb@oracle.com> <59CE473F.8080805@oracle.com> Message-ID: <59CF479D.6020107@oracle.com> I filed JDK-8188185 "Windows build fails in configure after fixes for JDK-8188123, JDK-8188136": https://bugs.openjdk.java.net/browse/JDK-8188185 For this issue. Tim On 09/29/17 19:33, David Holmes wrote: > Unfortunately it has broken JPRT Windows builds. > > David > > On 29/09/2017 11:14 PM, Tim Bell wrote: >> Erik- >> >> Looks good to me as well. >> >> /Tim >> >> On 09/29/17 02:42, David Holmes wrote: >>> Looks good Erik. I hadn't spotted the .jib created above my repo tree!! >>> >>> Thanks, >>> David >>> >>> On 29/09/2017 6:45 PM, Erik Joelsson wrote: >>>> This patch makes it possible to run "bash /jib.sh configure" >>>> from an out of tree directory, without specifying --src-dir to jib. >>>> The framework used for the Jib CLI automatically defines env variables >>>> that may provide defaults for each parameter. In this case I use the >>>> JIB_SRC_DIR env variable to provide a default for the src dir from the >>>> jib launcher script. >>>> >>>> While in there I noticed that some relative paths were wrong after the >>>> consolidation and I fixed those too which also covers JDK-8188123. >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8188136/webrev.01/ >>>> Bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-8188136 >>>> https://bugs.openjdk.java.net/browse/JDK-8188123 >>>> >>>> /Erik >>