From kim.barrett at oracle.com Mon Oct 1 03:21:30 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 30 Sep 2018 23:21:30 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> Message-ID: > On Sep 30, 2018, at 4:51 PM, David Holmes wrote: > > Hi Kim, Thanks for looking at this. >> (2) Remove call to _dyld_bind_fully_image_containing_address, which >> seems to have been deprecated since MacOSX 10.5. Instead use the >> recommended replacement "dlopen(RTLD_NOW)". However, it might be we >> don't need to do anything here anymore. I ran tier1-5 test without >> the dlopen without any problems. But I'm not familiar with the >> original problem, so not sure that's convincing. Perhaps another RFE >> to determine whether this code can be deleted? > > The use of _dyld_bind_fully_image_containing_address, as per the comment is a workaround to force full binding of symbols in the library. I don't know where the "callbacks" referred to in the comment come from or why they may be unaligned - this seems to be day 1 code for the OS X port from 2008: > > http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l75.4001 > > I've cc'd the macosx-port-dev mailing list in case someone still subscribed there might know the answer. Yes, I?d noticed it was day-1 OS X port code. Thanks for cc?ing the macosx-port-dev list; I?d not thought of that. > If you don't have unaligned symbols then the workaround is not needed. In that case the replacement dlopen is also not needed (and it isn't needed to actually dlopen anything as you are opening the current library!). So it is not surprising that removing the dlopen causes no problem. > > With the dlopen in place however the code looks very strange and there's no guarantee it actually engages the workaround of the original function. The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the deprecated function. The following dlclose is to decrement the refcount increment associated with that dlopen, and does nothing else since the library in question was already loaded and still has references. > So I'd say this either has to be removed completely or else left alone. The warning message is: _dyld_bind_fully_image_containing_address((const void *) &os::init); note: '_dyld_bind_fully_image_containing_address' has been explicitly marked deprecated here extern bool _dyld_bind_fully_image_containing_address(const void* address) __IOS_UNAVAILABLE __BRIDGEOS_UNAVAILABLE __OSX_DEPRECATED(10.1, 10.5, "dlopen(RTLD_NOW)"); The arguments in __OSX_DEPRECATED(10.1, 10.5. "dlopen(RTLD_NOW)") indicate it was introduced in 10.1, deprecated in 10.5, and the replacement to use instead. So I?m just using the recommended replacement (which was described in brief in the warning message, rather than working code). I?m reluctant to remove this completely without a better understanding of what it is there for and why it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive but not definitive. From david.holmes at oracle.com Mon Oct 1 06:27:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Oct 2018 16:27:32 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> Message-ID: <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> Hi Kim, On 1/10/2018 1:21 PM, Kim Barrett wrote: >> On Sep 30, 2018, at 4:51 PM, David Holmes wrote: >> >> Hi Kim, > > Thanks for looking at this. > >>> (2) Remove call to _dyld_bind_fully_image_containing_address, which >>> seems to have been deprecated since MacOSX 10.5. Instead use the >>> recommended replacement "dlopen(RTLD_NOW)". However, it might be we >>> don't need to do anything here anymore. I ran tier1-5 test without >>> the dlopen without any problems. But I'm not familiar with the >>> original problem, so not sure that's convincing. Perhaps another RFE >>> to determine whether this code can be deleted? >> >> The use of _dyld_bind_fully_image_containing_address, as per the comment is a workaround to force full binding of symbols in the library. I don't know where the "callbacks" referred to in the comment come from or why they may be unaligned - this seems to be day 1 code for the OS X port from 2008: >> >> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l75.4001 >> >> I've cc'd the macosx-port-dev mailing list in case someone still subscribed there might know the answer. > > Yes, I?d noticed it was day-1 OS X port code. Thanks for cc?ing the macosx-port-dev list; I?d not thought of that. > >> If you don't have unaligned symbols then the workaround is not needed. In that case the replacement dlopen is also not needed (and it isn't needed to actually dlopen anything as you are opening the current library!). So it is not surprising that removing the dlopen causes no problem. >> >> With the dlopen in place however the code looks very strange and there's no guarantee it actually engages the workaround of the original function. > > The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW > forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the > deprecated function. The current library is libjvm and it's already opened in the appropriate way: libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 > > The following dlclose is to decrement the refcount increment associated with that dlopen, and does nothing > else since the library in question was already loaded and still has references. > >> So I'd say this either has to be removed completely or else left alone. > > The warning message is: > > _dyld_bind_fully_image_containing_address((const void *) &os::init); > note: '_dyld_bind_fully_image_containing_address' has been explicitly marked deprecated here > extern bool _dyld_bind_fully_image_containing_address(const void* address) __IOS_UNAVAILABLE __BRIDGEOS_UNAVAILABLE __OSX_DEPRECATED(10.1, 10.5, "dlopen(RTLD_NOW)"); > > The arguments in __OSX_DEPRECATED(10.1, 10.5. "dlopen(RTLD_NOW)") > indicate it was introduced in 10.1, deprecated in 10.5, and the replacement to use instead. > So I?m just using the recommended replacement (which was described in brief in the > warning message, rather than working code). > > I?m reluctant to remove this completely without a better understanding of what it is there for and why > it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive > but not definitive. I'd be happier knowing the exact details here as well, but if the new code doesn't implement the workaround then it's no better than completely removing it. And as we seem to have been always already using the new code then ... Cheers, David From volker.simonis at gmail.com Mon Oct 1 07:39:48 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 1 Oct 2018 09:39:48 +0200 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> <37f0b889-3d9a-cba1-f51c-76ba56d7d4e2@redhat.com> Message-ID: Hi Lutz, the change looks good. Thanks for cleaning this up, Volker On Fri, Sep 28, 2018 at 12:30 PM Aleksey Shipilev wrote: > > On 09/27/2018 04:28 PM, Schmidt, Lutz wrote: > > re break vs. ShouldNotReachHere(), I tried to change semantics as little as possible. After > > discussion with colleagues, we concluded that ShouldNotReachHere() is the better choice. Code was > > modified accordingly. Your concerns re. coding style are reflected in the new webrev as well. It > > can be found here: http://cr.openjdk.java.net/~lucy/webrevs/8211145.02/ > > Looks good! Ship it. > > -Aleksey > From aph at redhat.com Mon Oct 1 10:13:59 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 1 Oct 2018 11:13:59 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> <68b52c1a-63c0-9966-2627-db4de08e7c46@samersoff.net> Message-ID: <0161d6e0-809b-c729-0bcb-b76890f63d6e@redhat.com> On 09/29/2018 11:01 AM, Pengfei Li (Arm Technology China) wrote: > Anyone can help push Andrew Haley's fix ASAP since current master cannot build? > http://cr.openjdk.java.net/~aph/8211207/ It's in. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From lutz.schmidt at sap.com Mon Oct 1 12:38:03 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 1 Oct 2018 12:38:03 +0000 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> <37f0b889-3d9a-cba1-f51c-76ba56d7d4e2@redhat.com> Message-ID: <20D28443-4DAC-45A9-BEDA-502627A0E605@sap.com> Thank you, Aleksey and Volker! Pushed. Regards, Lutz ?On 01.10.18, 09:39, "Volker Simonis" wrote: Hi Lutz, the change looks good. Thanks for cleaning this up, Volker On Fri, Sep 28, 2018 at 12:30 PM Aleksey Shipilev wrote: > > On 09/27/2018 04:28 PM, Schmidt, Lutz wrote: > > re break vs. ShouldNotReachHere(), I tried to change semantics as little as possible. After > > discussion with colleagues, we concluded that ShouldNotReachHere() is the better choice. Code was > > modified accordingly. Your concerns re. coding style are reflected in the new webrev as well. It > > can be found here: http://cr.openjdk.java.net/~lucy/webrevs/8211145.02/ > > Looks good! Ship it. > > -Aleksey > From philip.race at oracle.com Mon Oct 1 16:19:39 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Oct 2018 09:19:39 -0700 Subject: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt In-Reply-To: <57768c04-a994-46f8-8322-fa89058d58c9@default> References: <57768c04-a994-46f8-8322-fa89058d58c9@default> Message-ID: <5BB2491B.7000501@oracle.com> Hi, 1) Has this been built on all platforms ? 2) I can't find the list of warnings that you are seeing and fixing and they are all over the place. So adding 2d-dev and build-dev. For each of these changes, please show what was the warning that you received from the compiler This might sound like a lot of work, but it won't be disproportionate and I've made the same request for similar reviews and without it, it is hard to review the changes. For example (and I do mean just example) http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html why would that not be #ifdef instead ? 3) Testing .. did you run at least all our jtreg tests to make sure you didn't break some behaviour .. -phil. On 9/29/18, 8:18 PM, Krishna Addepalli wrote: > > Hi All, > > Please review a fix for JDK-8074824: > https://bugs.openjdk.java.net/browse/JDK-8074824 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ > > > Most of the warnings have been fixed for Linux, Mac and Windows. > > Thanks, > > Krishna > From philip.race at oracle.com Mon Oct 1 16:38:06 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Oct 2018 09:38:06 -0700 Subject: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt In-Reply-To: <5BB2491B.7000501@oracle.com> References: <57768c04-a994-46f8-8322-fa89058d58c9@default> <5BB2491B.7000501@oracle.com> Message-ID: <5BB24D6E.5020600@oracle.com> You really do need to explain *each* of the changes better. This one .. why not NULL ? http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html -phil On 10/1/18, 9:19 AM, Philip Race wrote: > Hi, > > 1) Has this been built on all platforms ? > 2) I can't find the list of warnings that you are seeing and fixing > and they are all over the place. > So adding 2d-dev and build-dev. > For each of these changes, please show what was the warning that you > received from the compiler > This might sound like a lot of work, but it won't be disproportionate > and I've made the same > request for similar reviews and without it, it is hard to review the > changes. > > For example (and I do mean just example) > http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html > > why would that not be #ifdef instead ? > > 3) Testing .. did you run at least all our jtreg tests to make sure > you didn't break > some behaviour .. > > -phil. > > On 9/29/18, 8:18 PM, Krishna Addepalli wrote: >> >> Hi All, >> >> Please review a fix for JDK-8074824: >> https://bugs.openjdk.java.net/browse/JDK-8074824 >> >> Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ >> >> >> Most of the warnings have been fixed for Linux, Mac and Windows. >> >> Thanks, >> >> Krishna >> From kim.barrett at oracle.com Mon Oct 1 18:35:10 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Oct 2018 14:35:10 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> Message-ID: > On Oct 1, 2018, at 2:27 AM, David Holmes wrote: > > On 1/10/2018 1:21 PM, Kim Barrett wrote: >> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >> deprecated function. > > The current library is libjvm and it's already opened in the appropriate way: > > libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); > > and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? > > http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 The current version of LoadJavaVM (for Mac) contains: #ifndef STATIC_BUILD libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); #else libjvm = dlopen(NULL, RTLD_FIRST); #endif where STATIC_BUILD is controlled by the --enable-static-builds configure option. The --enable-static-builds option was added in JDK 9 by 8136556: Add the ability to perform static builds of MacOSX x64 binaries. So it is possible for libjava to be opened without RTLD_NOW. I think the proposed change should work correctly in that case. The dladdr should find the current object, which we'll open by name (rather than using NULL, but that should be okay), using RTLD_NOW, forcing resolution of all symbols. I'm not sure there can be any relevant unresolved symbols on this path, but then, as said before, I don't understand the point of this workaround. >> I?m reluctant to remove this completely without a better understanding of what it is there for and why >> it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive >> but not definitive. > > I'd be happier knowing the exact details here as well, but if the new code doesn't implement the workaround then it's no better than completely removing it. And as we seem to have been always already using the new code then ? I thought this part of the change would be straight-forward. An alternative would be to leave the old deprecated call in place, locally disable the deprecation warning, and file an RFE for someone more knowledgable in this area and with Mac development to look at. From philip.race at oracle.com Mon Oct 1 22:09:32 2018 From: philip.race at oracle.com (Philip Race) Date: Mon, 01 Oct 2018 15:09:32 -0700 Subject: [12]RFR: [JDK-8074824]: Resolve disabled warnings for libawt_xawt In-Reply-To: <5BB24D6E.5020600@oracle.com> References: <57768c04-a994-46f8-8322-fa89058d58c9@default> <5BB2491B.7000501@oracle.com> <5BB24D6E.5020600@oracle.com> Message-ID: <5BB29B1C.3030601@oracle.com> I suspect I understand this one now .. the array is stack allocated so we don't want NULL but the compiler probably complained about possible uninitialised use of the values ? -phil. On 10/1/18, 9:38 AM, Philip Race wrote: > You really do need to explain *each* of the changes better. > This one .. why not NULL ? > http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/share/native/libawt/java2d/loops/ProcessPath.c.udiff.html > > -phil > > On 10/1/18, 9:19 AM, Philip Race wrote: >> Hi, >> >> 1) Has this been built on all platforms ? >> 2) I can't find the list of warnings that you are seeing and fixing >> and they are all over the place. >> So adding 2d-dev and build-dev. >> For each of these changes, please show what was the warning that you >> received from the compiler >> This might sound like a lot of work, but it won't be disproportionate >> and I've made the same >> request for similar reviews and without it, it is hard to review the >> changes. >> >> For example (and I do mean just example) >> http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/src/java.desktop/unix/native/common/awt/awt_Font.c.udiff.html >> >> why would that not be #ifdef instead ? >> >> 3) Testing .. did you run at least all our jtreg tests to make sure >> you didn't break >> some behaviour .. >> >> -phil. >> >> On 9/29/18, 8:18 PM, Krishna Addepalli wrote: >>> >>> Hi All, >>> >>> Please review a fix for JDK-8074824: >>> https://bugs.openjdk.java.net/browse/JDK-8074824 >>> >>> Webrev: http://cr.openjdk.java.net/~kaddepalli/8074824/webrev01/ >>> >>> >>> Most of the warnings have been fixed for Linux, Mac and Windows. >>> >>> Thanks, >>> >>> Krishna >>> From david.holmes at oracle.com Mon Oct 1 23:10:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Oct 2018 09:10:14 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> Message-ID: <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> On 2/10/2018 4:35 AM, Kim Barrett wrote: >> On Oct 1, 2018, at 2:27 AM, David Holmes wrote: >> >> On 1/10/2018 1:21 PM, Kim Barrett wrote: >>> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >>> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >>> deprecated function. >> >> The current library is libjvm and it's already opened in the appropriate way: >> >> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >> >> and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? >> >> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 > > The current version of LoadJavaVM (for Mac) contains: > > #ifndef STATIC_BUILD > libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); > #else > libjvm = dlopen(NULL, RTLD_FIRST); > #endif > > where STATIC_BUILD is controlled by the --enable-static-builds > configure option. The --enable-static-builds option was added in JDK 9 > by 8136556: Add the ability to perform static builds of MacOSX x64 > binaries. Which "current version" is this? It is not what is in jdk/jdk repo, which has no STATIC_BUILD support in this area. ?? Although we may have not used RTLD_NOW with static builds (does this discussions re symbol resolution even make sense with a static build?) in some version of the JDK, my point is that we have been using RTLD_NOW for as long as the workaround has been in place. That strongly suggests to me that use of RTLD_NOW is not a solution to the problem the workaround was introduced for. > So it is possible for libjava to be opened without RTLD_NOW. I think > the proposed change should work correctly in that case. The dladdr > should find the current object, which we'll open by name (rather than > using NULL, but that should be okay), using RTLD_NOW, forcing > resolution of all symbols. I'm not sure there can be any relevant > unresolved symbols on this path, but then, as said before, I don't > understand the point of this workaround. > >>> I?m reluctant to remove this completely without a better understanding of what it is there for and why >>> it is no longer needed, if indeed that?s the case. The lack of problems when running tests is suggestive >>> but not definitive. >> >> I'd be happier knowing the exact details here as well, but if the new code doesn't implement the workaround then it's no better than completely removing it. And as we seem to have been always already using the new code then ? > > I thought this part of the change would be straight-forward. An > alternative would be to leave the old deprecated call in place, > locally disable the deprecation warning, and file an RFE for someone > more knowledgable in this area and with Mac development to look at. Sorry for the obstructions on this but changing the code without knowing it even implements the same workaround is just wrong to me. I strongly suspect the code is not needed at all. Perhaps the old per-file flag setting can be restored. By all means file a RFE but I fear there is noone who would know the details of this any more. :( David From mikael.vidstedt at oracle.com Tue Oct 2 07:21:13 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 2 Oct 2018 00:21:13 -0700 Subject: RFR(S): 8211350: Remove jprt support Message-ID: Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. bug: https://bugs.openjdk.java.net/browse/JDK-8211350 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ * Background (from the issue) The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. * About the change The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: build-dev: make related files, jprt.* hotspot-dev: {src,test}/hotspot core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid Of course I?d welcome reviews across those mappings as well. * Testing tier1 (passed), tier2-3 still running (looking good so far). Cheers, Mikael From david.holmes at oracle.com Tue Oct 2 07:44:05 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Oct 2018 17:44:05 +1000 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: Hi Mikael, This all looks fine to me. Thanks for cleaning it up! David On 2/10/2018 5:21 PM, Mikael Vidstedt wrote: > > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > > * Background (from the issue) > > The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. > > > * About the change > > The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: > > build-dev: make related files, jprt.* > hotspot-dev: {src,test}/hotspot > core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid > > Of course I?d welcome reviews across those mappings as well. > > * Testing > > tier1 (passed), tier2-3 still running (looking good so far). > > Cheers, > Mikael > From Alan.Bateman at oracle.com Tue Oct 2 08:34:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Oct 2018 09:34:31 +0100 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: On 02/10/2018 08:21, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > Does the change to Helper.java and tests that use it break testing of exploded builds? I don't know why it has the comment "JPRT not yet ready" but whether $JAVA_HOME/jmods exists or not isn't connected to JPRT or any build or test system. -Alan From david.holmes at oracle.com Tue Oct 2 09:52:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Oct 2018 19:52:45 +1000 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <3b27a611-3a53-af1e-aa08-4bd81ecdceff@oracle.com> On 2/10/2018 6:34 PM, Alan Bateman wrote: > On 02/10/2018 08:21, Mikael Vidstedt wrote: >> Please review this change which removes support for, and references >> to, the (Oracle internal) JPRT system. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >> webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >> > Does the change to Helper.java and tests that use it break testing of > exploded builds? I don't know why it has the comment "JPRT not yet > ready" but whether $JAVA_HOME/jmods exists or not isn't connected to > JPRT or any build or test system. Yes it will break as now an exception will be thrown instead of just cleanly exiting with an error message. I think the Helper changes can be left as-is, just update the comment. David > -Alan From sgehwolf at redhat.com Tue Oct 2 10:33:46 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Oct 2018 12:33:46 +0200 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: Message-ID: Hi, Pinging PPC porters. Does this look reasonable to you? Thanks, Severin On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > Build changes look ok to me. > > /Erik > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this JDK 8 backport which fixes some > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > would report as "ppc64" via os.arch system property which breaks > > tooling such as maven in as much as if some dependency needs native > > libraries it would download BE binaries where it actually should > > download LE binaries. Example for os.arch/java.library.path: > > > > pre: > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > os.arch = ppc64 > > > > post: > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > os.arch = ppc64le > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > for JDK/hotspot changes. > > > > This backport should only have minor differences to the changes in JDK > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > Thanks, > > Severin > > > > From goetz.lindenmaier at sap.com Tue Oct 2 10:40:31 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Oct 2018 10:40:31 +0000 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: Message-ID: <666987d08f324a0c94208c6cca403214@sap.com> Hi, I'm fine with this. If I remember correctly, this was proposed before but never pushed in the end. Did you test this on ppc64 be, too? Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Severin Gehwolf > Sent: Dienstag, 2. Oktober 2018 12:34 > To: Erik Joelsson ; hotspot-dev dev at openjdk.java.net>; ppc-aix-port-dev dev at openjdk.java.net>; build-dev > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > os.arch value on ppc64le cause issues with Java tooling > > Hi, > > Pinging PPC porters. Does this look reasonable to you? > > Thanks, > Severin > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > Build changes look ok to me. > > > > /Erik > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > would report as "ppc64" via os.arch system property which breaks > > > tooling such as maven in as much as if some dependency needs native > > > libraries it would download BE binaries where it actually should > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > pre: > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > java.library.path = > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > os.arch = ppc64 > > > > > > post: > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > java.library.path = > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > os.arch = ppc64le > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8073139/jdk8/01/ > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > > for JDK/hotspot changes. > > > > > > This backport should only have minor differences to the changes in JDK > > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > > > Thanks, > > > Severin > > > > > > > From sgehwolf at redhat.com Tue Oct 2 11:09:15 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Oct 2018 13:09:15 +0200 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <666987d08f324a0c94208c6cca403214@sap.com> References: <666987d08f324a0c94208c6cca403214@sap.com> Message-ID: <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com> Hi Goetz, On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote: > Hi, > > I'm fine with this. Thanks for the review! > If I remember correctly, this was proposed before but > never pushed in the end. Interesting. > Did you test this on ppc64 be, too? I have not. Will do so, though. Thanks, Severin > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev On > > Behalf Of Severin Gehwolf > > Sent: Dienstag, 2. Oktober 2018 12:34 > > To: Erik Joelsson ; hotspot-dev > dev at openjdk.java.net>; ppc-aix-port-dev > dev at openjdk.java.net>; build-dev > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > > os.arch value on ppc64le cause issues with Java tooling > > > > Hi, > > > > Pinging PPC porters. Does this look reasonable to you? > > > > Thanks, > > Severin > > > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > > Build changes look ok to me. > > > > > > /Erik > > > > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > would report as "ppc64" via os.arch system property which breaks > > > > tooling such as maven in as much as if some dependency needs native > > > > libraries it would download BE binaries where it actually should > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > pre: > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > java.library.path = > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > os.arch = ppc64 > > > > > > > > post: > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > java.library.path = > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > os.arch = ppc64le > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > 8073139/jdk8/01/ > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > > > for JDK/hotspot changes. > > > > > > > > This backport should only have minor differences to the changes in JDK > > > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > From goetz.lindenmaier at sap.com Tue Oct 2 12:39:16 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Oct 2018 12:39:16 +0000 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com> References: <666987d08f324a0c94208c6cca403214@sap.com> <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com> Message-ID: <6d0a6a512b39469b8afd25ae587c99ba@sap.com> Hi Severin, here for example: http://mail.openjdk.java.net/pipermail/build-dev/2015-July/015370.html While the fix proposed there looks different and the downport was never finished. Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 2. Oktober 2018 13:09 > To: Lindenmaier, Goetz ; Erik Joelsson > ; hotspot-dev dev at openjdk.java.net>; ppc-aix-port-dev dev at openjdk.java.net>; build-dev > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > os.arch value on ppc64le cause issues with Java tooling > > Hi Goetz, > > On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote: > > Hi, > > > > I'm fine with this. > > Thanks for the review! > > > If I remember correctly, this was proposed before but > > never pushed in the end. > > Interesting. > > > Did you test this on ppc64 be, too? > > I have not. Will do so, though. > > Thanks, > Severin > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: ppc-aix-port-dev > On > > > Behalf Of Severin Gehwolf > > > Sent: Dienstag, 2. Oktober 2018 12:34 > > > To: Erik Joelsson ; hotspot-dev > > dev at openjdk.java.net>; ppc-aix-port-dev > > dev at openjdk.java.net>; build-dev > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory > and > > > os.arch value on ppc64le cause issues with Java tooling > > > > > > Hi, > > > > > > Pinging PPC porters. Does this look reasonable to you? > > > > > > Thanks, > > > Severin > > > > > > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > > > Build changes look ok to me. > > > > > > > > /Erik > > > > > > > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > > would report as "ppc64" via os.arch system property which breaks > > > > > tooling such as maven in as much as if some dependency needs > native > > > > > libraries it would download BE binaries where it actually should > > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > > > pre: > > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > > java.library.path = > > > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > > os.arch = ppc64 > > > > > > > > > > post: > > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > > java.library.path = > > > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > > os.arch = ppc64le > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > 8073139/jdk8/01/ > > > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port- > dev > > > > > for JDK/hotspot changes. > > > > > > > > > > This backport should only have minor differences to the changes in > JDK > > > > > 11. We have been using similar patches in Fedora for months. > Thoughts? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > > > From sgehwolf at redhat.com Tue Oct 2 12:59:39 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 02 Oct 2018 14:59:39 +0200 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <6d0a6a512b39469b8afd25ae587c99ba@sap.com> References: <666987d08f324a0c94208c6cca403214@sap.com> <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com> <6d0a6a512b39469b8afd25ae587c99ba@sap.com> Message-ID: <26f26253dd3bd909ae17e729b6286fce7c86f32c.camel@redhat.com> Hi Goetz, I'm a bit confused :-/ On Tue, 2018-10-02 at 12:39 +0000, Lindenmaier, Goetz wrote: > Hi Severin, > > here for example: http://mail.openjdk.java.net/pipermail/build-dev/2015-July/015370.html As far as I can see that was relating to the JDK-head fix which wasn't available at the time (July vs. pushed in Dec). The original review thread was here: http://mail.openjdk.java.net/pipermail/build-dev/2015-December/016103.html JDK-8073139 has been fixed in JDK 9+ since December 14, 2015. > While the fix proposed there looks different and the downport was never > finished. FWIW, this is a review request for the 8u backport :) Thanks, Severin > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Dienstag, 2. Oktober 2018 13:09 > > To: Lindenmaier, Goetz ; Erik Joelsson > > ; hotspot-dev > dev at openjdk.java.net>; ppc-aix-port-dev > dev at openjdk.java.net>; build-dev > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > > os.arch value on ppc64le cause issues with Java tooling > > > > Hi Goetz, > > > > On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote: > > > Hi, > > > > > > I'm fine with this. > > > > Thanks for the review! > > > > > If I remember correctly, this was proposed before but > > > never pushed in the end. > > > > Interesting. > > > > > Did you test this on ppc64 be, too? > > > > I have not. Will do so, though. > > > > Thanks, > > Severin > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: ppc-aix-port-dev > > > > On > > > > Behalf Of Severin Gehwolf > > > > Sent: Dienstag, 2. Oktober 2018 12:34 > > > > To: Erik Joelsson ; hotspot-dev > > > dev at openjdk.java.net>; ppc-aix-port-dev > > > dev at openjdk.java.net>; build-dev > > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory > > > > and > > > > os.arch value on ppc64le cause issues with Java tooling > > > > > > > > Hi, > > > > > > > > Pinging PPC porters. Does this look reasonable to you? > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > > > > Build changes look ok to me. > > > > > > > > > > /Erik > > > > > > > > > > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > > > would report as "ppc64" via os.arch system property which breaks > > > > > > tooling such as maven in as much as if some dependency needs > > > > native > > > > > > libraries it would download BE binaries where it actually should > > > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > > > > > pre: > > > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > > > java.library.path = > > > > > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > > > os.arch = ppc64 > > > > > > > > > > > > post: > > > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > > > java.library.path = > > > > > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > > > os.arch = ppc64le > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > > 8073139/jdk8/01/ > > > > > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port- > > > > dev > > > > > > for JDK/hotspot changes. > > > > > > > > > > > > This backport should only have minor differences to the changes in > > > > JDK > > > > > > 11. We have been using similar patches in Fedora for months. > > > > Thoughts? > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > From goetz.lindenmaier at sap.com Tue Oct 2 13:14:49 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 2 Oct 2018 13:14:49 +0000 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <26f26253dd3bd909ae17e729b6286fce7c86f32c.camel@redhat.com> References: <666987d08f324a0c94208c6cca403214@sap.com> <994203969d0375a2a53345aa392d30550c505d16.camel@redhat.com> <6d0a6a512b39469b8afd25ae587c99ba@sap.com> <26f26253dd3bd909ae17e729b6286fce7c86f32c.camel@redhat.com> Message-ID: <3c5196e76e1043ff820c55e61bed83a1@sap.com> yes, there was the backport review requeset, and there was another one before that, but both never got pushed to 8u. There also were webrevs for the backport, which didn't apply any more after a while. So it's good if someone drives this now, finally :) Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 2. Oktober 2018 15:00 > To: Lindenmaier, Goetz ; Erik Joelsson > ; hotspot-dev dev at openjdk.java.net>; ppc-aix-port-dev dev at openjdk.java.net>; build-dev > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > os.arch value on ppc64le cause issues with Java tooling > > Hi Goetz, > > I'm a bit confused :-/ > > On Tue, 2018-10-02 at 12:39 +0000, Lindenmaier, Goetz wrote: > > Hi Severin, > > > > here for example: http://mail.openjdk.java.net/pipermail/build-dev/2015- > July/015370.html > > As far as I can see that was relating to the JDK-head fix which wasn't > available at the time (July vs. pushed in Dec). The original review > thread was here: > http://mail.openjdk.java.net/pipermail/build-dev/2015- > December/016103.html > > JDK-8073139 has been fixed in JDK 9+ since December 14, 2015. > > > While the fix proposed there looks different and the downport was never > > finished. > > FWIW, this is a review request for the 8u backport :) > > Thanks, > Severin > > > Best regards, > > Goetz. > > > > > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Dienstag, 2. Oktober 2018 13:09 > > > To: Lindenmaier, Goetz ; Erik Joelsson > > > ; hotspot-dev > > dev at openjdk.java.net>; ppc-aix-port-dev > > dev at openjdk.java.net>; build-dev > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory > and > > > os.arch value on ppc64le cause issues with Java tooling > > > > > > Hi Goetz, > > > > > > On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote: > > > > Hi, > > > > > > > > I'm fine with this. > > > > > > Thanks for the review! > > > > > > > If I remember correctly, this was proposed before but > > > > never pushed in the end. > > > > > > Interesting. > > > > > > > Did you test this on ppc64 be, too? > > > > > > I have not. Will do so, though. > > > > > > Thanks, > > > Severin > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > -----Original Message----- > > > > > From: ppc-aix-port-dev bounces at openjdk.java.net> > > > > > > On > > > > > Behalf Of Severin Gehwolf > > > > > Sent: Dienstag, 2. Oktober 2018 12:34 > > > > > To: Erik Joelsson ; hotspot-dev > > > > dev at openjdk.java.net>; ppc-aix-port-dev > > > > dev at openjdk.java.net>; build-dev > > > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch > directory > > > > > > and > > > > > os.arch value on ppc64le cause issues with Java tooling > > > > > > > > > > Hi, > > > > > > > > > > Pinging PPC porters. Does this look reasonable to you? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > > > > > Build changes look ok to me. > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes > some > > > > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > > > > would report as "ppc64" via os.arch system property which breaks > > > > > > > tooling such as maven in as much as if some dependency needs > > > > > > native > > > > > > > libraries it would download BE binaries where it actually should > > > > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > > > > > > > pre: > > > > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > > > > java.library.path = > > > > > > > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > > > > os.arch = ppc64 > > > > > > > > > > > > > > post: > > > > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > > > > java.library.path = > > > > > > > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > > > > os.arch = ppc64le > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > > > > > 8073139/jdk8/01/ > > > > > > > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix- > port- > > > > > > dev > > > > > > > for JDK/hotspot changes. > > > > > > > > > > > > > > This backport should only have minor differences to the changes > in > > > > > > JDK > > > > > > > 11. We have been using similar patches in Fedora for months. > > > > > > Thoughts? > > > > > > > > > > > > > > Thanks, > > > > > > > Severin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From mandy.chung at oracle.com Tue Oct 2 15:40:35 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 08:40:35 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> On 10/2/18 12:21 AM, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). I think Helper class should continue to return null if jmods does not exist.? test/jdk/tools/jimage/JImageTest.java should also be reverted. Otherwise, the clean up looks good. Mandy From erik.joelsson at oracle.com Tue Oct 2 15:53:46 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Oct 2018 08:53:46 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <3971e8aa-c8f1-4676-8288-40828b172c90@oracle.com> Build changes look good to me. /Erik On 2018-10-02 00:21, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > > * Background (from the issue) > > The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. > > > * About the change > > The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: > > build-dev: make related files, jprt.* > hotspot-dev: {src,test}/hotspot > core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid > > Of course I?d welcome reviews across those mappings as well. > > * Testing > > tier1 (passed), tier2-3 still running (looking good so far). > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Tue Oct 2 18:17:18 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 2 Oct 2018 11:17:18 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. Cheers, Mikael > On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: > > > > On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >> Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >> > > test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). > > I think Helper class should continue to return null if jmods does not exist. test/jdk/tools/jimage/JImageTest.java should also be reverted. > > Otherwise, the clean up looks good. > > Mandy From mandy.chung at oracle.com Tue Oct 2 18:18:16 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 11:18:16 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: +1 Mandy On 10/2/18 11:17 AM, Mikael Vidstedt wrote: > > Thanks for the reviews. I?ve reverted the changes related to Helper > and ?just? adjusted the comments instead. > > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > > incremental (from webrev.00): > http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > > Btw, I notice that "Test not run, NO jmods directory? will be printed > twice when jmods is missing - once in Helper::newHelper and once in > the methods calling it. In general, the handling of a null return from > newHelper could use some clean up, but that is out of scope for this > change. > > Cheers, > Mikael From erik.joelsson at oracle.com Tue Oct 2 18:28:01 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Oct 2018 11:28:01 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: <7f163563-0c99-d496-95d9-3f0a2ff54ca9@oracle.com> Looks good to me. /Erik On 2018-10-02 11:17, Mikael Vidstedt wrote: > Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. > > Cheers, > Mikael > >> On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: >> >> >> >> On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >>> Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >>> >> test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). >> >> I think Helper class should continue to return null if jmods does not exist. test/jdk/tools/jimage/JImageTest.java should also be reverted. >> >> Otherwise, the clean up looks good. >> >> Mandy From Alan.Bateman at oracle.com Tue Oct 2 18:28:26 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Oct 2018 19:28:26 +0100 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: <5ce26e91-9ecc-3adf-e61a-b85eb4349beb@oracle.com> On 02/10/2018 19:17, Mikael Vidstedt wrote: > Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. > At some point I think the test for jlink will need to be cleaned up anyway but that is way outside of scope of what you are doing. The updated webrev looks okay to me. -Alan From david.holmes at oracle.com Tue Oct 2 20:06:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Oct 2018 06:06:23 +1000 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: Looks good. Ship it! David On 3/10/2018 4:17 AM, Mikael Vidstedt wrote: > > Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. > > Cheers, > Mikael > >> On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: >> >> >> >> On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >>> Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >>> >> >> test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). >> >> I think Helper class should continue to return null if jmods does not exist. test/jdk/tools/jimage/JImageTest.java should also be reverted. >> >> Otherwise, the clean up looks good. >> >> Mandy > From kim.barrett at oracle.com Tue Oct 2 20:51:40 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Oct 2018 16:51:40 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> Message-ID: <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> > On Oct 1, 2018, at 7:10 PM, David Holmes wrote: > > On 2/10/2018 4:35 AM, Kim Barrett wrote: >>> On Oct 1, 2018, at 2:27 AM, David Holmes wrote: >>> >>> On 1/10/2018 1:21 PM, Kim Barrett wrote: >>>> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >>>> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >>>> deprecated function. >>> >>> The current library is libjvm and it's already opened in the appropriate way: >>> >>> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >>> >>> and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? >>> >>> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 >> The current version of LoadJavaVM (for Mac) contains: >> #ifndef STATIC_BUILD >> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >> #else >> libjvm = dlopen(NULL, RTLD_FIRST); >> #endif >> where STATIC_BUILD is controlled by the --enable-static-builds >> configure option. The --enable-static-builds option was added in JDK 9 >> by 8136556: Add the ability to perform static builds of MacOSX x64 >> binaries. > > Which "current version" is this? It is not what is in jdk/jdk repo, which has no STATIC_BUILD support in this area. ?? I think the MacOSX version of LoadJavaVM is here: ./java.base/macosx/native/libjli/java_md_macosx.m (Note that this appears to be an Obj-C source file.) (And no, I have no idea what build magic goes on to make this work.) This has the STATIC_BUILD stuff. There are also definitions for other platforms. ./java.base/windows/native/libjli/java_md.c // Windows ./java.base/unix/native/libjli/java_md_solinux.c // Solaris/Linux/AIX (Note that java_md_solinux.c is excluded for macosx by the build system; see LIBJLI_EXCLUDE_FILES in CoreLibraries.gmk.) > Although we may have not used RTLD_NOW with static builds (does this discussions re symbol resolution even make sense with a static build?) I think symbol resolution can make sense with a static build, if there are other libraries that are not statically linked. I don't know whether that's the case here. I'm going to try doing a static build without this dlopen code and see what happens. > in some version of the JDK, my point is that we have been using RTLD_NOW for as long as the workaround has been in place. > That strongly suggests to me that use of RTLD_NOW is not a solution to the problem the workaround was introduced for. I think my replacement code is equivalent to the deprecated code. I think the sequence of events may have been something like: (1) dlopen java lib without RTLD_NOW (2) run into problems that led to workaround code (3) run into further problems that led to dlopen java lib with RTLD_NOW but didn't remove the now superfluous workaround (perhaps it was forgotten?) (4) merge >> I thought this part of the change would be straight-forward. An >> alternative would be to leave the old deprecated call in place, >> locally disable the deprecation warning, and file an RFE for someone >> more knowledgable in this area and with Mac development to look at. > > Sorry for the obstructions on this but changing the code without knowing it even implements the same workaround is just wrong to me. I strongly suspect the code is not needed at all. I agree that for the non-STATIC_BUILD case the workaround is superfluous. If a static build without any workaround code works then I think the workaround code should just be removed. Is that okay with you? From jonathan.gibbons at oracle.com Tue Oct 2 21:39:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Oct 2018 14:39:50 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <5BB3E5A6.8070401@oracle.com> *Chuckle* at the long-obsolete reference in test/langtools/Makefile 292 apt: JTREG_TESTDIRS = tools/apt Otherwise, apart from other overdue cleanup, test/langtools/Makefile looks OK. -- Jon On 10/02/2018 12:21 AM, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > > * Background (from the issue) > > The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. > > > * About the change > > The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: > > build-dev: make related files, jprt.* > hotspot-dev: {src,test}/hotspot > core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid > > Of course I?d welcome reviews across those mappings as well. > > * Testing > > tier1 (passed), tier2-3 still running (looking good so far). > > Cheers, > Mikael > From david.holmes at oracle.com Tue Oct 2 22:10:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Oct 2018 08:10:12 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> Message-ID: On 3/10/2018 6:51 AM, Kim Barrett wrote: >> On Oct 1, 2018, at 7:10 PM, David Holmes wrote: >> >> On 2/10/2018 4:35 AM, Kim Barrett wrote: >>>> On Oct 1, 2018, at 2:27 AM, David Holmes wrote: >>>> >>>> On 1/10/2018 1:21 PM, Kim Barrett wrote: >>>>> The current library may have been previously only dlopen?ed with RTLD_LAZY. Reopening with RTLD_NOW >>>>> forces resolution of all undefined symbols in that shared object, which appears to be the purpose of the >>>>> deprecated function. >>>> >>>> The current library is libjvm and it's already opened in the appropriate way: >>>> >>>> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >>>> >>>> and it seems to have always been opened this way. So I can't see how this can fix the problem the workaround purports to fix?? >>>> >>>> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l54.758 >>> The current version of LoadJavaVM (for Mac) contains: >>> #ifndef STATIC_BUILD >>> libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); >>> #else >>> libjvm = dlopen(NULL, RTLD_FIRST); >>> #endif >>> where STATIC_BUILD is controlled by the --enable-static-builds >>> configure option. The --enable-static-builds option was added in JDK 9 >>> by 8136556: Add the ability to perform static builds of MacOSX x64 >>> binaries. >> >> Which "current version" is this? It is not what is in jdk/jdk repo, which has no STATIC_BUILD support in this area. ?? > > I think the MacOSX version of LoadJavaVM is here: > ./java.base/macosx/native/libjli/java_md_macosx.m > (Note that this appears to be an Obj-C source file.) > (And no, I have no idea what build magic goes on to make this work.) > This has the STATIC_BUILD stuff. Hmmm okay. But I can't find that file in the original mac port, or in 7u at all. In 7u we have jdk/src/macosx/bin/java_md_macosx.c with libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); and that was created in 2012 when the launcher was refactored under JDK-7124089. The archaeology is getting too hard. :( > There are also definitions for other platforms. > ./java.base/windows/native/libjli/java_md.c // Windows > ./java.base/unix/native/libjli/java_md_solinux.c // Solaris/Linux/AIX > (Note that java_md_solinux.c is excluded for macosx by the build > system; see LIBJLI_EXCLUDE_FILES in CoreLibraries.gmk.) > >> Although we may have not used RTLD_NOW with static builds (does this discussions re symbol resolution even make sense with a static build?) > > I think symbol resolution can make sense with a static build, if there > are other libraries that are not statically linked. I don't know > whether that's the case here. I'm going to try doing a static build > without this dlopen code and see what happens. > >> in some version of the JDK, my point is that we have been using RTLD_NOW for as long as the workaround has been in place. >> That strongly suggests to me that use of RTLD_NOW is not a solution to the problem the workaround was introduced for. > > I think my replacement code is equivalent to the deprecated code. I > think the sequence of events may have been something like: > > (1) dlopen java lib without RTLD_NOW > (2) run into problems that led to workaround code > (3) run into further problems that led to dlopen java lib with RTLD_NOW > but didn't remove the now superfluous workaround (perhaps it was > forgotten?) > (4) merge Perhaps. No way to know. > >>> I thought this part of the change would be straight-forward. An >>> alternative would be to leave the old deprecated call in place, >>> locally disable the deprecation warning, and file an RFE for someone >>> more knowledgable in this area and with Mac development to look at. >> >> Sorry for the obstructions on this but changing the code without knowing it even implements the same workaround is just wrong to me. I strongly suspect the code is not needed at all. > > I agree that for the non-STATIC_BUILD case the workaround is > superfluous. If a static build without any workaround code works then > I think the workaround code should just be removed. Is that okay with > you? Yes but you will need to go through a full round of testing, not just tier 1-3, before being reasonably confident the workaround is not needed. I'd hate to see this break things "in the wild" just because we don't have adequate test coverage. Other opinions welcomed. David > From kim.barrett at oracle.com Tue Oct 2 22:18:38 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Oct 2018 18:18:38 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> <47ABAD88-9376-45D3-86DB-16A47B81F061@oracle.com> Message-ID: <55464073-BF13-4D30-9FA7-829778F698E8@oracle.com> > On Sep 29, 2018, at 1:36 PM, Magnus Ihse Bursie wrote: > > On 2018-09-28 23:22, Kim Barrett wrote: > >>> On Sep 24, 2018, at 4:31 PM, Magnus Ihse Bursie wrote: >>> The second warning about the copy constructor is, for what I can tell, a highly valid warning and the code it warned on was indeed broken. As far as I can tell, in a derived copy constructor you should always explicitly initialize the base class. >> I agree the copy constructor warnings are correct and indicate potentially serious bugs. >> These copy constructor changes look correct to me. >> >> The code that is being missed because of this bug is debug-only usage verification. I think >> bad things might happen if we C-heap allocated a ResourceObj and then copied that object. >> Maybe we fortuitously don?t ever do that? > If we had triggered problems we'd probably found out the issue by now, so its likely we're not doing anything that causes this to happen currently. But latent bugs like these are scary, and unnecessary, especially if we can get the compiler's help to avoid them. >> It?s unfortunate that the only way to get these warnings from gcc seems to be via -Wextra. > I agree, it's unfortunate. -Wextra in gcc actually means two things: a bunch of "extra" warnings, that you can turn on or off as a group only by enabling or disabling -Wextra, and a set of separate warnings that this option also turns on by default. The latter is more of a convenience to get a set of warnings that the gcc authors recommend for more in-depth warnings. Since they can be individually disabled, we don't need to care much about them. > > In regard to your previous mail, there has not been much change in the scope of -Wextra. Between gcc 4.8 and 7.3, no changes were made in the first part (the "extra" warnings), and only four more warnings were added to the second part (-Wcast-function-type, -Wimplicit-fallthrough=3, -Wredundant-move and -Wshift-negative-value), all of which can be turned off if we don't want them. > > In general, we try to make the product compile without warnings on common platforms, but as you say, unless you use one of the compilers that are regularly used (at Oracle or elsewhere), there's a risk of triggering new warnings. However, using configure --disable-warnings-as-errors makes the build pass anyway, and is already commonly in use by those building on more exotic platforms or compiler versions. > > I would have preferred to have individual warnings to enable, but gcc has not moved all warnings from -Wextra to individual warnings (new warnings, though, have all been given individual names). Since the warnings, as you agree, can find actual bugs, I think it's worth the hassle to enable -Wextra. (We already do that for all native code in OpenJDK, except hotspot, btw.) gcc8.2 adds -Wcast-function-type, which *might* cause us problems. We play some interesting games with function types in some places, and I don't know if they'll trigger this. We can turn it off explicitly if it is a problem (or perhaps preemptively). I went through all the associated warnings for gcc7.3 and categorized them. Some are just not interesting or relevant to us. I think these include -Wclobbered -Wignored-qualifiers -Wmissing-field-initializers -Wmissing-parameter-type -Wold-style-declaration -Woverride-init Ambiguous virtual bases. Subscripting an array that has been declared register Taking address of a variable declared register Some we are already using: -Wsign-compiler -Wtype-limits -Wuninitialized Some I think we should never enable (so need to explicitly disable if adding -Wextra): -Wempty-body -Wshift-negative-value -Wunused-parameter Perhaps provide some small benefit: -Wunused-but-set-parameter (but does nothing without -Wunused or -Wall) Relational compare of pointer against integer 0 -Wimplicit-fallthrough=3 requires a structured comment or C++17 feature to quiet the warning in code that is using the feature. Provides some benefit. I'm surprised there aren't any warnings from this. Intentional fall-through is a pretty common idiom. Enumerator and non-enumerator as results of conditional expression. Has a well-defined meaning, and used in a number of places. Some of those might be artifacts of some constants being defined using enum members rather than static const members. Problematic because of valid uses and can't be turned off. A base class is not initialized in the copy constructor of a derived class. Indicates a real bug, of which we have 3(?) occurrences, all of which should be fixed. But copy constructors are relatively rare in HotSpot, at least currently. Much of the benefit could be obtained by occasionally doing a build with this enabled and warnings-are-errors disabled and looking for these warnings. I think the benefit we get from detecting future occurrences of the copy constructor bug is not really worth the current cost of "fixing" the occurrences of conditional expressions with enumerators. I might feel differently if a pass were made through those to replace uses of enum with static const members. In summary, I think we shouldn't enable -Wextra. I think the current cost/benefit tradeoff is actually negative. One warning not individually controlled requires ugly workarounds or possibly non-trivial code changes to address, and I really dislike the ugly workarounds. If we do enable it, I think there are a number of specific warnings that ought to be explicitly disabled, either temporarily or permanently. From kim.barrett at oracle.com Tue Oct 2 23:30:45 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Oct 2018 19:30:45 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> Message-ID: <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> > On Oct 2, 2018, at 6:10 PM, David Holmes wrote: > The archaeology is getting too hard. :( No kidding! > Yes but you will need to go through a full round of testing, not just tier 1-3, before being reasonably confident the workaround is not needed. I'd hate to see this break things "in the wild" just because we don't have adequate test coverage. > > Other opinions welcomed. I was planning to hit it with tier1-8 and possibly other things if I can find them. JCK tests too; I saw some instructions for running those in mach5 recently. That all assumes that static build actually works at all; it doesn?t look like we test that configuration these days, so who knows what bit rot may have set in. From serguei.spitsyn at oracle.com Wed Oct 3 04:50:45 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 2 Oct 2018 21:50:45 -0700 Subject: [CAUTION] RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef In-Reply-To: <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com> References: <3667f01e602a47a59739dfb6b73dcd5c@sap.com> <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com> Message-ID: +1 (if you still need it) Thanks, Serguei On 9/26/18 4:41 AM, David Holmes wrote: > That all seems fine to me. > > Thanks for fixing. > > David > > On 26/09/2018 5:48 AM, Langer, Christoph wrote: >> Hi Matthias, >> >> looks good (and trivial). Ccing serviceability-dev because of change >> in libjdwp. >> >> Best regards >> >> Christoph >> >> *From:*nio-dev *On Behalf Of >> *Baesken, Matthias >> *Sent:* Mittwoch, 26. September 2018 11:25 >> *To:* 'build-dev at openjdk.java.net' ; >> net-dev ; nio-dev at openjdk.java.net >> *Cc:* Lindenmaier, Goetz ; Schmidt, Lutz >> >> *Subject:* [CAUTION] RFR : 8211146 : fix problematic elif-tests after >> recent gcc warning changes Werror=undef >> >> Hello, please review this small build fix . >> >> After the recent? changes? to ?the gcc compile flags?? with 8211029?? >> ??,? most of our? Linux builds stopped working . >> >> Error : >> >> === Output from failing command(s) repeated here === >> >> * For target support_native_java.base_libnet_DatagramPacket.o: >> >> In file included from >> /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/net_util.h:31:0, >> >> ?????????????????from >> /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/DatagramPacket.c:27: >> >> /OpenJDK/8210319/jdk/src/java.base/unix/native/libnet/net_util_md.h:50:7: >> error: "__solaris__" is not defined [-Werror=undef] >> >> #elif __solaris__ >> >> ??????? ^ >> >> After looking into it,? it seems? that? the >> jdk/src/java.base/unix/native/libnet/net_util_md.h??? compile error >> is only triggered on older Linux OS? (e.g. SLES11). >> >> Probably that?s why it was not seen at Oracle ?after? puhsing after >> 8211029?? . >> >> Some greps? showed me a number of similar problematic #elif-checks >> for OS, I adjusted them too . >> >> Bug / webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8211146 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8211146.0/ >> >> >> Thanks, Matthias >> From robin.westberg at oracle.com Wed Oct 3 18:09:55 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 3 Oct 2018 20:09:55 +0200 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> Message-ID: <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> Hi Magnus, Thanks for reviewing, sorry for taking a while to respond! > On 19 Sep 2018, at 13:02, Magnus Ihse Bursie wrote: > > 19 sep. 2018 kl. 09:51 skrev Magnus Ihse Bursie : > >>>>>> In Awt2dLibraries.gmk, I think lines 733 and 735 needs to be fixed as well. Using FindLib is generally a good idea for this. I suspect there may be more such instances sprinkled around the makefiles. >>>>> Only fixed the last one, I think the first one is ok as is? >>>> The first one is sort of OK, but it's a questionable construct as the $(BUILD_LIBAWT_XAWT) variable may contain additional targets. We used to do it that way but these days I prefer the more explicit and precise FindLib. In this particular case you get a non needed dependency added when running compile-commands with ENABLE_HEADLESS_ONLY=true, which will not really affect anything so it doesn't really matter. >>> Yeah I certainly agree, but a quick grep shows that there?s about 50 such constructs present right now. I wouldn?t mind cleaning those up, but perhaps that should be in a separate change? >> If that does not affect your patch, you do not need to clean up those constructs. >> >> I've now looked through your patch. Overall, it looks good. Some minor comments: >> >> * In make/CompileCommands.gmk, are you sure the find -exec + construct does not exceed command line limits on problematic platforms such as Solaris and Windows? It runs successfully on Windows and Solaris right now at least, and the filenames only include a relative path, so should not be sensitive to working directory location. But I have to admit I?m not sure how close to the limit it is right now.. Perhaps I can build something around ?xargs -s? instead if you think this is risky? >> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. Fixed. >> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. Fixed. >> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >> >> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >> >> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >> > > An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set > > $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) > and when compiling do this: > $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) > > That would get rid of the filter-out, keep duplication low but still be readable. > > This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. Sounds good, fixed. > /Magnus > >> Erik, what do you think? >> >> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >> >> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ Best regards, Robin >> >> /Magnus >> >>> >>>> Otherwise this looks good now. >>> Thanks, I?ll include the latest webrevs with a comment added: >>> >>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>> >>> Best regards, >>> Robin >>> >>>> /Erik >>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>> Testing: tier1, builds-tier5 >>>>> >>>>> Best regards, >>>>> Robin >>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>> >>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>> >>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>> Testing: tier1, builds-tier5 >>>>>>> >>>>>>> Best regards, >>>>>>> Robin >>>>>>> >>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html From erik.joelsson at oracle.com Wed Oct 3 18:51:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Oct 2018 11:51:24 -0700 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> Message-ID: <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> Hello Robin, make/CompileCommands.gmk: typo in comment: "prepened" On 2018-10-03 11:09, Robin Westberg wrote: > Hi Magnus, > > Thanks for reviewing, sorry for taking a while to respond! > >> On 19 Sep 2018, at 13:02, Magnus Ihse Bursie wrote: >> >> 19 sep. 2018 kl. 09:51 skrev Magnus Ihse Bursie : >> >>>>>>> In Awt2dLibraries.gmk, I think lines 733 and 735 needs to be fixed as well. Using FindLib is generally a good idea for this. I suspect there may be more such instances sprinkled around the makefiles. >>>>>> Only fixed the last one, I think the first one is ok as is? >>>>> The first one is sort of OK, but it's a questionable construct as the $(BUILD_LIBAWT_XAWT) variable may contain additional targets. We used to do it that way but these days I prefer the more explicit and precise FindLib. In this particular case you get a non needed dependency added when running compile-commands with ENABLE_HEADLESS_ONLY=true, which will not really affect anything so it doesn't really matter. >>>> Yeah I certainly agree, but a quick grep shows that there?s about 50 such constructs present right now. I wouldn?t mind cleaning those up, but perhaps that should be in a separate change? >>> If that does not affect your patch, you do not need to clean up those constructs. >>> >>> I've now looked through your patch. Overall, it looks good. Some minor comments: >>> >>> * In make/CompileCommands.gmk, are you sure the find -exec + construct does not exceed command line limits on problematic platforms such as Solaris and Windows? > It runs successfully on Windows and Solaris right now at least, and the filenames only include a relative path, so should not be sensitive to working directory location. But I have to admit I?m not sure how close to the limit it is right now.. Perhaps I can build something around ?xargs -s? instead if you think this is risky? I think it would be good to make sure the file list is split using xargs to avoid weird failures in the future. I also just realized it would be good to sort the file list to guarantee stable output. Otherwise I think this is good now. /Erik >>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? > What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. > > Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. > >>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. > Fixed. > >>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. > Fixed. > >>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>> >>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>> >>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>> >> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >> >> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >> and when compiling do this: >> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >> >> That would get rid of the filter-out, keep duplication low but still be readable. >> >> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. > Sounds good, fixed. > >> /Magnus >> >>> Erik, what do you think? >>> >>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. > Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. > >>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>> >>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? > What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). > > This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. > > Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ > Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ > > Best regards, > Robin > >>> /Magnus >>> >>>>> Otherwise this looks good now. >>>> Thanks, I?ll include the latest webrevs with a comment added: >>>> >>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>> >>>> Best regards, >>>> Robin >>>> >>>>> /Erik >>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>> Testing: tier1, builds-tier5 >>>>>> >>>>>> Best regards, >>>>>> Robin >>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>> >>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>> >>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>> >>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>> Testing: tier1, builds-tier5 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Robin >>>>>>>> >>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html From kim.barrett at oracle.com Wed Oct 3 19:13:15 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Oct 2018 15:13:15 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features Message-ID: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> I've submitted a JEP for (1) enabling the use of C++14 Language Features when building the JDK, (2) define a process for deciding and documenting which new features can be used or are forbidden in HotSpot code, (3) provide an initial list of permitted and forbidden new features. https://bugs.openjdk.java.net/browse/JDK-8208089 From erik.joelsson at oracle.com Wed Oct 3 22:51:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 3 Oct 2018 15:51:09 -0700 Subject: RFR: JDK-8211677: Java resource copy and clean should use MakeTargetDir macro Message-ID: <0363e3c8-3794-1cfa-30dd-1d0febc6d0d0@oracle.com> Since upgrading our Solaris build machines to 11.3, we have experienced intermittent build failures in the recipes copying java resource files. It's unclear why this started happening now after having worked fine for so long, but it seems it's a race caused by concurrent calls to "mkdir -p". In other recipes we have worked around this by using a macro "MakeDir" which reduces the likelihood of concurrent calls happening. Rewriting these copy and clean rules to use the current preferred macros seem to alleviate the problem for us on Solaris 11.3, and also makes the build a little bit more coherent. Bug: https://bugs.openjdk.java.net/browse/JDK-8211677 Webrev: http://cr.openjdk.java.net/~erikj/8211677/webrev.01/ /Erik From tim.bell at oracle.com Wed Oct 3 23:45:21 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 03 Oct 2018 23:45:21 +0000 Subject: RFR: JDK-8211677: Java resource copy and clean should use MakeTargetDir macro In-Reply-To: <0363e3c8-3794-1cfa-30dd-1d0febc6d0d0@oracle.com> References: <0363e3c8-3794-1cfa-30dd-1d0febc6d0d0@oracle.com> Message-ID: <5BB55491.20807@oracle.com> Erik: > Since upgrading our Solaris build machines to 11.3, we have experienced > intermittent build failures in the recipes copying java resource files. > It's unclear why this started happening now after having worked fine for > so long, but it seems it's a race caused by concurrent calls to "mkdir > -p". In other recipes we have worked around this by using a macro > "MakeDir" which reduces the likelihood of concurrent calls happening. > Rewriting these copy and clean rules to use the current preferred macros > seem to alleviate the problem for us on Solaris 11.3, and also makes the > build a little bit more coherent. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211677 > > Webrev: http://cr.openjdk.java.net/~erikj/8211677/webrev.01/ Looks good. Tim From mark.reinhold at oracle.com Wed Oct 3 23:55:37 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 03 Oct 2018 16:55:37 -0700 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <20181003165537.306971476@eggemoggin.niobe.net> 2018/10/3 12:13:15 -0700, kim.barrett at oracle.com: > ... > > https://bugs.openjdk.java.net/browse/JDK-8208089 Or, more readably: https://openjdk.java.net/jeps/8208089 - Mark From goetz.lindenmaier at sap.com Thu Oct 4 06:59:03 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 06:59:03 +0000 Subject: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <71fb517fba794dc28291cf51afb6e8b9@sap.com> Hi, I appreciate this is handled in a JEP and well communicated! XLc, the compiler we use for AIX, might be a bottleneck here. But we currently have no compiler-constraints by products on our aix port of jdk12 (for jdk11 we must stay with the current compiler xlc 12 which does not support C++11, and jdk11 even should be compilable with aCC by HP for which we won't get new versions!) We will update our compiler for jdk/jdk to the most recent Xlc as soon as possible. To my current knowledge, Xlc 14 was dropped, and xlc 16 is to be released early 2019. It is supposed to support C++ 11, and also some C++ 14 features. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Kim Barrett > Sent: Mittwoch, 3. Oktober 2018 21:13 > To: hotspot-dev developers > Cc: build-dev ; core-libs- > dev at openjdk.java.net > Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features > > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 From robin.westberg at oracle.com Thu Oct 4 08:33:21 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Thu, 4 Oct 2018 10:33:21 +0200 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> Message-ID: <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> Hi Erik, > On 3 Oct 2018, at 20:51, Erik Joelsson wrote: > > Hello Robin, > > make/CompileCommands.gmk: typo in comment: ?prepened" Fixed. (Couldn?t resist a slight rewording so the text has reflowed a bit, sorry!) > On 2018-10-03 11:09, Robin Westberg wrote: >> Hi Magnus, >> >> Thanks for reviewing, sorry for taking a while to respond! >> >>> On 19 Sep 2018, at 13:02, Magnus Ihse Bursie wrote: >>> >>> 19 sep. 2018 kl. 09:51 skrev Magnus Ihse Bursie : >>> >>>>>>>> In Awt2dLibraries.gmk, I think lines 733 and 735 needs to be fixed as well. Using FindLib is generally a good idea for this. I suspect there may be more such instances sprinkled around the makefiles. >>>>>>> Only fixed the last one, I think the first one is ok as is? >>>>>> The first one is sort of OK, but it's a questionable construct as the $(BUILD_LIBAWT_XAWT) variable may contain additional targets. We used to do it that way but these days I prefer the more explicit and precise FindLib. In this particular case you get a non needed dependency added when running compile-commands with ENABLE_HEADLESS_ONLY=true, which will not really affect anything so it doesn't really matter. >>>>> Yeah I certainly agree, but a quick grep shows that there?s about 50 such constructs present right now. I wouldn?t mind cleaning those up, but perhaps that should be in a separate change? >>>> If that does not affect your patch, you do not need to clean up those constructs. >>>> >>>> I've now looked through your patch. Overall, it looks good. Some minor comments: >>>> >>>> * In make/CompileCommands.gmk, are you sure the find -exec + construct does not exceed command line limits on problematic platforms such as Solaris and Windows? >> It runs successfully on Windows and Solaris right now at least, and the filenames only include a relative path, so should not be sensitive to working directory location. But I have to admit I?m not sure how close to the limit it is right now.. Perhaps I can build something around ?xargs -s? instead if you think this is risky? > I think it would be good to make sure the file list is split using xargs to avoid weird failures in the future. I also just realized it would be good to sort the file list to guarantee stable output. Makes sense, changed it to use sort and xargs. Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.04/ Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03-04/ Best regards, Robin > > Otherwise I think this is good now. > > /Erik >>>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? >> What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. >> >> Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >> >>>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. >> Fixed. >> >>>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. >> Fixed. >> >>>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>> >>>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>>> >>>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>>> >>> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >>> >>> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>> and when compiling do this: >>> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >>> >>> That would get rid of the filter-out, keep duplication low but still be readable. >>> >>> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. >> Sounds good, fixed. >> >>> /Magnus >>> >>>> Erik, what do you think? >>>> >>>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. >> Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >> >>>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>>> >>>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? >> What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). >> >> This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. >> >> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ >> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ >> >> Best regards, >> Robin >> >>>> /Magnus >>>> >>>>>> Otherwise this looks good now. >>>>> Thanks, I?ll include the latest webrevs with a comment added: >>>>> >>>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>>> >>>>> Best regards, >>>>> Robin >>>>> >>>>>> /Erik >>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>>> Testing: tier1, builds-tier5 >>>>>>> >>>>>>> Best regards, >>>>>>> Robin >>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>>> >>>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>>> >>>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>>> >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Robin >>>>>>>>> >>>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html From volker.simonis at gmail.com Thu Oct 4 08:35:06 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Oct 2018 11:35:06 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: Hi Tim, Jeff, Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) https://bugs.openjdk.java.net/browse/JDK-8208089 Could you please provide a summary of which of these features are already available since which version of xlC for AIX and potentially escalate the implementation of the missing features within IBM?s xlC on AIX team. Thank you and best regards, Volker Kim Barrett schrieb am Mi. 3. Okt. 2018 um 22:13: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > From martijnverburg at gmail.com Thu Oct 4 08:57:43 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 4 Oct 2018 09:57:43 +0100 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: Hi Kim, I like this initiative. I'm wondering if some of these rules can be easily codified or written into a jcheck style checker (ccheck?) so that Authors can adhere to the conventions and not rely on a Human review to pick out where that convention isn't met. Cheers, Martijn On Wed, 3 Oct 2018 at 20:13, Kim Barrett wrote: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > From magnus.ihse.bursie at oracle.com Thu Oct 4 11:38:59 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 13:38:59 +0200 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> Message-ID: <5EE9A9D0-6A94-4616-A2F6-14D46D95EFB6@oracle.com> > 4 okt. 2018 kl. 10:33 skrev Robin Westberg : > > Hi Erik, > >> On 3 Oct 2018, at 20:51, Erik Joelsson wrote: >> >> Hello Robin, >> >> make/CompileCommands.gmk: typo in comment: ?prepened" > > Fixed. (Couldn?t resist a slight rewording so the text has reflowed a bit, sorry!) Much better written, thank you! > >>> On 2018-10-03 11:09, Robin Westberg wrote: >>> Hi Magnus, >>> >>> Thanks for reviewing, sorry for taking a while to respond! >>> >>>> On 19 Sep 2018, at 13:02, Magnus Ihse Bursie wrote: >>>> >>>> 19 sep. 2018 kl. 09:51 skrev Magnus Ihse Bursie : >>>> >>>>>>>>> In Awt2dLibraries.gmk, I think lines 733 and 735 needs to be fixed as well. Using FindLib is generally a good idea for this. I suspect there may be more such instances sprinkled around the makefiles. >>>>>>>> Only fixed the last one, I think the first one is ok as is? >>>>>>> The first one is sort of OK, but it's a questionable construct as the $(BUILD_LIBAWT_XAWT) variable may contain additional targets. We used to do it that way but these days I prefer the more explicit and precise FindLib. In this particular case you get a non needed dependency added when running compile-commands with ENABLE_HEADLESS_ONLY=true, which will not really affect anything so it doesn't really matter. >>>>>> Yeah I certainly agree, but a quick grep shows that there?s about 50 such constructs present right now. I wouldn?t mind cleaning those up, but perhaps that should be in a separate change? >>>>> If that does not affect your patch, you do not need to clean up those constructs. >>>>> >>>>> I've now looked through your patch. Overall, it looks good. Some minor comments: >>>>> >>>>> * In make/CompileCommands.gmk, are you sure the find -exec + construct does not exceed command line limits on problematic platforms such as Solaris and Windows? >>> It runs successfully on Windows and Solaris right now at least, and the filenames only include a relative path, so should not be sensitive to working directory location. But I have to admit I?m not sure how close to the limit it is right now.. Perhaps I can build something around ?xargs -s? instead if you think this is risky? >> I think it would be good to make sure the file list is split using xargs to avoid weird failures in the future. I also just realized it would be good to sort the file list to guarantee stable output. > > Makes sense, changed it to use sort and xargs. Much better, thanks! > > Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.04/ I was about to say that this looks good, but then I discovered a weird thing. I'm the SED line, line 50, there is a weird C-like Unicode character instead of a quote, after -e. Looks really odd. Is it a "smart quote" gone wrong? Can you look into it and fix it? You don't need to respin the webrev for that. Otherwise, you're all good to go. /Magnus > Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03-04/ > > Best regards, > Robin > >> >> Otherwise I think this is good now. >> >> /Erik >>>>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? >>> What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. >>> >>> Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >>> >>>>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. >>> Fixed. >>> >>>>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. >>> Fixed. >>> >>>>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>>>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>>>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>> >>>>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>>>> >>>>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>>>> >>>> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >>>> >>>> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>> and when compiling do this: >>>> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >>>> >>>> That would get rid of the filter-out, keep duplication low but still be readable. >>>> >>>> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. >>> Sounds good, fixed. >>> >>>> /Magnus >>>> >>>>> Erik, what do you think? >>>>> >>>>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. >>> Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >>> >>>>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>>>> >>>>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? >>> What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). >>> >>> This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. >>> >>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ >>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ >>> >>> Best regards, >>> Robin >>> >>>>> /Magnus >>>>> >>>>>>> Otherwise this looks good now. >>>>>> Thanks, I?ll include the latest webrevs with a comment added: >>>>>> >>>>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>>>> >>>>>> Best regards, >>>>>> Robin >>>>>> >>>>>>> /Erik >>>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>>>> Testing: tier1, builds-tier5 >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Robin >>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>>>> >>>>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>>>> >>>>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>>>> >>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Robin >>>>>>>>>> >>>>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html > From magnus.ihse.bursie at oracle.com Thu Oct 4 11:47:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 13:47:28 +0200 Subject: RFR: JDK-8211677: Java resource copy and clean should use MakeTargetDir macro In-Reply-To: <0363e3c8-3794-1cfa-30dd-1d0febc6d0d0@oracle.com> References: <0363e3c8-3794-1cfa-30dd-1d0febc6d0d0@oracle.com> Message-ID: Looks good to me. Have you searched the code for more instances of mkdir -p? Also, maybe we should check if using AC_PROG_MKDIR_P would give us a better option on Solaris. (See https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Particular-Programs.html#Particular-Programs). It is supposed to give a non-race prone version of mkdir -p. Just to be clear: Even if we start using it for MKDIR_P, I still think it's a good idea to use our macro. /Magnus > 4 okt. 2018 kl. 00:51 skrev Erik Joelsson : > > Since upgrading our Solaris build machines to 11.3, we have experienced intermittent build failures in the recipes copying java resource files. It's unclear why this started happening now after having worked fine for so long, but it seems it's a race caused by concurrent calls to "mkdir -p". In other recipes we have worked around this by using a macro "MakeDir" which reduces the likelihood of concurrent calls happening. Rewriting these copy and clean rules to use the current preferred macros seem to alleviate the problem for us on Solaris 11.3, and also makes the build a little bit more coherent. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211677 > > Webrev: http://cr.openjdk.java.net/~erikj/8211677/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Thu Oct 4 12:31:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 14:31:43 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <940757E3-8781-4E7A-B5B9-1F0D3E944E0F@oracle.com> > 4 okt. 2018 kl. 10:57 skrev Martijn Verburg : > > Hi Kim, > > I like this initiative. I'm wondering if some of these rules can be easily > codified or written into a jcheck style checker (ccheck?) so that Authors > can adhere to the conventions and not rely on a Human review to pick out > where that convention isn't met. That's an interesting thought! I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.) I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code. Neither seem like an ideal solution. The Google tool is hard coded to support the Google rules. It's possible we can fork it and add our own, but it's not clear that this is even possible, much less so that it's a good way forward. Vera++, on the other hand, seems much more likely to be able to provide the tooling needed to write checks that enforce these rules. However, what we have is just a framework, and someone's got to write those rules (in TCL of all languages...). Then again, Vera++ is an old and quite popular tool, so its possible there is already a bunch of predefined rules that we can use as a starting point out there. (I didn't go that far in my analysis). Apart from these two, there appear to be no popular, well-encompassing, open source C++ checker out there, that could possibly be verifying rules like these. :( /Magnus [1] https://github.com/google/styleguide/tree/gh-pages/cpplint [2] https://google.github.io/styleguide/cppguide.html [3] https://bitbucket.org/verateam/vera/wiki/Introduction > > Cheers, > Martijn > > >> On Wed, 3 Oct 2018 at 20:13, Kim Barrett wrote: >> >> I've submitted a JEP for >> >> (1) enabling the use of C++14 Language Features when building the JDK, >> >> (2) define a process for deciding and documenting which new features >> can be used or are forbidden in HotSpot code, >> >> (3) provide an initial list of permitted and forbidden new features. >> >> https://bugs.openjdk.java.net/browse/JDK-8208089 >> >> From robin.westberg at oracle.com Thu Oct 4 13:03:23 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Thu, 4 Oct 2018 15:03:23 +0200 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: <5EE9A9D0-6A94-4616-A2F6-14D46D95EFB6@oracle.com> References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> <5EE9A9D0-6A94-4616-A2F6-14D46D95EFB6@oracle.com> Message-ID: Hi Magnus, Thanks again for reviewing! > On 4 Oct 2018, at 13:38, Magnus Ihse Bursie wrote: > >> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.04/ > > I was about to say that this looks good, but then I discovered a weird thing. I'm the SED line, line 50, there is a weird C-like Unicode character instead of a quote, after -e. Looks really odd. Is it a "smart quote" gone wrong? Can you look into it and fix it? You don't need to respin the webrev for that. Otherwise, you're all good to go. Ah indeed, nice catch! Fortunately it seems to be an issue with the ?git-webrev? tool, there?s a missing semicolon in the html?ized version: $(SED) -e Ƈs/^/[. (The ?raw? view for example is correct). I did notice one more thing that I was hoping to sneak into an in-place update: the raw ?cat? on line 47 should probably be $(CAT) as well, right? I?ll sanity check it with that change to be certain. Best regards, Robin > /Magnus > >> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03-04/ >> >> Best regards, >> Robin >> >>> >>> Otherwise I think this is good now. >>> >>> /Erik >>>>>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? >>>> What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. >>>> >>>> Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >>>> >>>>>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. >>>> Fixed. >>>> >>>>>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. >>>> Fixed. >>>> >>>>>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>>>>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>>>>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>> >>>>>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>>>>> >>>>>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>>>>> >>>>> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >>>>> >>>>> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>> and when compiling do this: >>>>> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >>>>> >>>>> That would get rid of the filter-out, keep duplication low but still be readable. >>>>> >>>>> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. >>>> Sounds good, fixed. >>>> >>>>> /Magnus >>>>> >>>>>> Erik, what do you think? >>>>>> >>>>>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. >>>> Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >>>> >>>>>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>>>>> >>>>>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? >>>> What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). >>>> >>>> This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. >>>> >>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ >>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ >>>> >>>> Best regards, >>>> Robin >>>> >>>>>> /Magnus >>>>>> >>>>>>>> Otherwise this looks good now. >>>>>>> Thanks, I?ll include the latest webrevs with a comment added: >>>>>>> >>>>>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>>>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>>>>> >>>>>>> Best regards, >>>>>>> Robin >>>>>>> >>>>>>>> /Erik >>>>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Robin >>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>>>>> >>>>>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>>>>> >>>>>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Robin >>>>>>>>>>> >>>>>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html From magnus.ihse.bursie at oracle.com Thu Oct 4 13:14:34 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 15:14:34 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <55464073-BF13-4D30-9FA7-829778F698E8@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> <47ABAD88-9376-45D3-86DB-16A47B81F061@oracle.com> <55464073-BF13-4D30-9FA7-829778F698E8@oracle.com> Message-ID: <1340C14C-265B-4DC7-A00E-0C3BD3B42AD0@oracle.com> Kim, Thank you for your detailed analysis! Comments inline... 3 okt. 2018 kl. 00:18 skrev Kim Barrett : >> On Sep 29, 2018, at 1:36 PM, Magnus Ihse Bursie wrote: >> >> On 2018-09-28 23:22, Kim Barrett wrote: >> >>>> On Sep 24, 2018, at 4:31 PM, Magnus Ihse Bursie wrote: >>>> The second warning about the copy constructor is, for what I can tell, a highly valid warning and the code it warned on was indeed broken. As far as I can tell, in a derived copy constructor you should always explicitly initialize the base class. >>> I agree the copy constructor warnings are correct and indicate potentially serious bugs. >>> These copy constructor changes look correct to me. >>> >>> The code that is being missed because of this bug is debug-only usage verification. I think >>> bad things might happen if we C-heap allocated a ResourceObj and then copied that object. >>> Maybe we fortuitously don?t ever do that? >> If we had triggered problems we'd probably found out the issue by now, so its likely we're not doing anything that causes this to happen currently. But latent bugs like these are scary, and unnecessary, especially if we can get the compiler's help to avoid them. >>> It?s unfortunate that the only way to get these warnings from gcc seems to be via -Wextra. >> I agree, it's unfortunate. -Wextra in gcc actually means two things: a bunch of "extra" warnings, that you can turn on or off as a group only by enabling or disabling -Wextra, and a set of separate warnings that this option also turns on by default. The latter is more of a convenience to get a set of warnings that the gcc authors recommend for more in-depth warnings. Since they can be individually disabled, we don't need to care much about them. >> >> In regard to your previous mail, there has not been much change in the scope of -Wextra. Between gcc 4.8 and 7.3, no changes were made in the first part (the "extra" warnings), and only four more warnings were added to the second part (-Wcast-function-type, -Wimplicit-fallthrough=3, -Wredundant-move and -Wshift-negative-value), all of which can be turned off if we don't want them. >> >> In general, we try to make the product compile without warnings on common platforms, but as you say, unless you use one of the compilers that are regularly used (at Oracle or elsewhere), there's a risk of triggering new warnings. However, using configure --disable-warnings-as-errors makes the build pass anyway, and is already commonly in use by those building on more exotic platforms or compiler versions. >> >> I would have preferred to have individual warnings to enable, but gcc has not moved all warnings from -Wextra to individual warnings (new warnings, though, have all been given individual names). Since the warnings, as you agree, can find actual bugs, I think it's worth the hassle to enable -Wextra. (We already do that for all native code in OpenJDK, except hotspot, btw.) > > gcc8.2 adds -Wcast-function-type, which *might* cause us problems. We > play some interesting games with function types in some places, and I > don't know if they'll trigger this. We can turn it off explicitly if > it is a problem (or perhaps preemptively). > > I went through all the associated warnings for gcc7.3 and categorized > them. Some are just not interesting or relevant to us. I think these > include > > -Wclobbered > -Wignored-qualifiers > -Wmissing-field-initializers > -Wmissing-parameter-type > -Wold-style-declaration > -Woverride-init > Ambiguous virtual bases. > Subscripting an array that has been declared register > Taking address of a variable declared register I agree that some, like clobbered, is not relevant (but I think that also only applies to C code..?). In general, it doesn't hurt though, to turn on warnings that are unlikely to be triggered. I realize it also helps little to nothing, but once again, if this is the price we have to pay for catching some real problems, it's a small price indeed. OTOH, I don't really agree that old-style-declaration is irrelevant. At least in the JDK libraries there are multiple places where non-prototype declarations are made, and apart from the style issue, it's a bug waiting to happen if the function change its signature. I don't remember if this is the case in Hotspot too, but it wouldn't surprise me, if we don't check for it. > Some we are already using: > -Wsign-compiler > -Wtype-limits > -Wuninitialized > > Some I think we should never enable (so need to explicitly disable if > adding -Wextra): > -Wempty-body > -Wshift-negative-value > -Wunused-parameter I agree that unused-parameter is worthless. I think we should disable it globally, if that's not already done. empty-body is mostly good at catching style issues, like double semicolons. It's not a big deal, but it also never hurts to keep up good code quality. I have not seen it make any false positives. shift-negative-values is a bit beyond me, but as I understand it, it warns about a behavior that has changed recently, or will be changed, in the standards, to become undefined. That sounds to me like something that it would be better to act preemptively on. But then again, I might have misunderstood things. If so, we can definitely turn it off. > > Perhaps provide some small benefit: > -Wunused-but-set-parameter (but does nothing without -Wunused or -Wall) > Relational compare of pointer against integer 0 > > -Wimplicit-fallthrough=3 requires a structured comment or C++17 > feature to quiet the warning in code that is using the feature. > Provides some benefit. I'm surprised there aren't any warnings from > this. Intentional fall-through is a pretty common idiom. At level 3, the "structured" comment is just something like a line like this: // fallthrough Most, maybe all, fallthroughs in the hotspot code already does that. I think it's a reasonable requirement to show that the fallthrough is intentional. If you think it's too strong, we can lower it to level 1, which just requires a comment, with whatever text (or even empty, I think). > > Enumerator and non-enumerator as results of conditional expression. > Has a well-defined meaning, and used in a number of places. Some of > those might be artifacts of some constants being defined using enum > members rather than static const members. Problematic because of > valid uses and can't be turned off. Agree, this is the Achilles heel really. It's too bad it can't be turned off. :( The remaining code changes in my patch (apart from the copy constructor) are all due to this. > > A base class is not initialized in the copy constructor of a derived > class. Indicates a real bug, of which we have 3(?) occurrences, all of > which should be fixed. But copy constructors are relatively rare in > HotSpot, at least currently. Much of the benefit could be obtained by > occasionally doing a build with this enabled and warnings-are-errors > disabled and looking for these warnings. Only this is never going to happen. :( In general, I really much prefer for issues that can be detected automatically to be detected automatically. One-shot checks are unlikely to happen, and if done seldom enough will only accumulate so much "cruft" that it's too much work and too boring work for anyone to bother doing. > I think the benefit we get from detecting future occurrences of the > copy constructor bug is not really worth the current cost of "fixing" > the occurrences of conditional expressions with enumerators. I might > feel differently if a pass were made through those to replace uses of > enum with static const members. So I think this is what it really boils down to. Just to summarize/repeat what you said, so I'm sure we understand each other correctly: There's an upside to enabling Wextra; we know already that it found some real bugs, but the real benefit is all future potential bugs it will prohibit, and that's hard to quantify. On the other hand, there's a downside; and that's the conditional enum warnings, whose fixes are ugly. But, if the code was cleaned up, so those enum fixes were no longer ugly, then it would be a net positive to turn on Wextra. I think that's a reasonable solution for now. If we agree on this, I'll open a new bug with just the copy constructor fixes, and a enhancement request for replacing the enums with static const, and making the current bug ("turn on Wextra") dependent on that. I just want to add a final remark about compiler warnings. When I started the current work of normalizing the set of warnings in the entire OpenJDK, I was amazed at what low level of warnings that was used for gcc/clang in hotspot. In all the JDK native libraries, -Wall and -Wextra were on by default. In hotspot, not even -Wall were turned on! I think what have sort of "saved" you is that Microsoft CL was running with /W3, which is roughly equivalent to -Wall -Wextra. So most of the shared code compiled fine when adding -Wall -Wextra, but there was a lot of new warnings in non-Windows code. Of course, /W3 and -Wall -Wextra does not cover exactly the same set of warnings, nor implement similar warning checks identically, hence the current open set of warnings in shared code. I made a long list of warnings that are disabled due to this, but I think it would be a good idea to tackle them one by one. By a quick glance, most of them (but surely not all) seemed to point to real problematic code; if not buggy so at least bad style. > > In summary, I think we shouldn't enable -Wextra. I think the current > cost/benefit tradeoff is actually negative. One warning not > individually controlled requires ugly workarounds or possibly > non-trivial code changes to address, and I really dislike the ugly > workarounds. > > If we do enable it, I think there are a number of specific warnings > that ought to be explicitly disabled, either temporarily or > permanently. Yes, definitely. Had Wextra been *only* a predefined set of other named warnings, we wouldn't have needed to have this discussion. But since it works the way it does, it means that when we turn it on, we have to turn off the included warnings that we do not want. /Magnus From aleksei.voitylov at bell-sw.com Thu Oct 4 13:17:21 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 4 Oct 2018 16:17:21 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> Kim, Thank you for posting this. It's an important step to make. I wanted to clarify a couple of points: 1. Since this is infrastructure JEP, is the version of JDK which will undergo such changes going to be some future version or does it apply to past versions as well? I'm concerned with how we can simplify security backports to 8u which (I currently assume) is not subject to this change. 2. Which versions of GCC do you tentatively consider at this point? Non-x86 ports may have a problem upgrading to a specific version of GCC which the shared code will use and may need additional lead time to adjust. Thanks, -Aleksei On 03/10/2018 22:13, Kim Barrett wrote: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > From magnus.ihse.bursie at oracle.com Thu Oct 4 13:27:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 15:27:43 +0200 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> Message-ID: 3 okt. 2018 kl. 01:30 skrev Kim Barrett : >> On Oct 2, 2018, at 6:10 PM, David Holmes wrote: >> The archaeology is getting too hard. :( > > No kidding! > >> Yes but you will need to go through a full round of testing, not just tier 1-3, before being reasonably confident the workaround is not needed. I'd hate to see this break things "in the wild" just because we don't have adequate test coverage. >> >> Other opinions welcomed. > > I was planning to hit it with tier1-8 and possibly other things if I can find them. > JCK tests too; I saw some instructions for running those in mach5 recently. > > That all assumes that static build actually works at all; it doesn?t look like we > test that configuration these days, so who knows what bit rot may have set in. > No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. /Magnus From magnus.ihse.bursie at oracle.com Thu Oct 4 13:31:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 15:31:21 +0200 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> <5EE9A9D0-6A94-4616-A2F6-14D46D95EFB6@oracle.com> Message-ID: <4B983400-2EA8-4AAE-8C82-6AF78FF9226E@oracle.com> > 4 okt. 2018 kl. 15:03 skrev Robin Westberg : > > Hi Magnus, > > Thanks again for reviewing! > >>> On 4 Oct 2018, at 13:38, Magnus Ihse Bursie wrote: >>> >>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.04/ >> >> I was about to say that this looks good, but then I discovered a weird thing. I'm the SED line, line 50, there is a weird C-like Unicode character instead of a quote, after -e. Looks really odd. Is it a "smart quote" gone wrong? Can you look into it and fix it? You don't need to respin the webrev for that. Otherwise, you're all good to go. > > Ah indeed, nice catch! Fortunately it seems to be an issue with the ?git-webrev? tool, there?s a missing semicolon in the html?ized version: $(SED) -e Ƈs/^/[. (The ?raw? view for example is correct). Good. > > I did notice one more thing that I was hoping to sneak into an in-place update: the raw ?cat? on line 47 should probably be $(CAT) as well, right? I?ll sanity check it with that change to be certain. Yeah, it should. Shame on me and Erik for not catching it. ;-) No need to respin. /Magnus > > Best regards, > Robin > >> /Magnus >> >>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03-04/ >>> >>> Best regards, >>> Robin >>> >>>> >>>> Otherwise I think this is good now. >>>> >>>> /Erik >>>>>>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? >>>>> What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. >>>>> >>>>> Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >>>>> >>>>>>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. >>>>> Fixed. >>>>> >>>>>>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. >>>>> Fixed. >>>>> >>>>>>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>>>>>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>>>>>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>>> >>>>>>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>>>>>> >>>>>>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>>>>>> >>>>>> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >>>>>> >>>>>> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>> and when compiling do this: >>>>>> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >>>>>> >>>>>> That would get rid of the filter-out, keep duplication low but still be readable. >>>>>> >>>>>> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. >>>>> Sounds good, fixed. >>>>> >>>>>> /Magnus >>>>>> >>>>>>> Erik, what do you think? >>>>>>> >>>>>>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. >>>>> Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >>>>> >>>>>>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>>>>>> >>>>>>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? >>>>> What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). >>>>> >>>>> This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. >>>>> >>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ >>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ >>>>> >>>>> Best regards, >>>>> Robin >>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>>> Otherwise this looks good now. >>>>>>>> Thanks, I?ll include the latest webrevs with a comment added: >>>>>>>> >>>>>>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>>>>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Robin >>>>>>>> >>>>>>>>> /Erik >>>>>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Robin >>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>>>>>> >>>>>>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>>>>>> >>>>>>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>>>>>> >>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Robin >>>>>>>>>>>> >>>>>>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html > From sgehwolf at redhat.com Thu Oct 4 14:40:01 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 04 Oct 2018 16:40:01 +0200 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <666987d08f324a0c94208c6cca403214@sap.com> References: <666987d08f324a0c94208c6cca403214@sap.com> Message-ID: Hi Goetz, On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote: [...] > Did you test this on ppc64 be, too? I've tested this patch on PPC64 BE Linux now too. There is no change (as expected): $ ./jdk8-ppc64be-after/bin/java TestProperty os.arch == ppc64 java.library.path == /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib $ ./jdk8-ppc64be-before/bin/java TestProperty os.arch == ppc64 java.library.path == /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib Thanks, Severin > Best regards, > Goetz. > > > -----Original Message----- > > From: ppc-aix-port-dev On > > Behalf Of Severin Gehwolf > > Sent: Dienstag, 2. Oktober 2018 12:34 > > To: Erik Joelsson ; hotspot-dev > dev at openjdk.java.net>; ppc-aix-port-dev > dev at openjdk.java.net>; build-dev > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > > os.arch value on ppc64le cause issues with Java tooling > > > > Hi, > > > > Pinging PPC porters. Does this look reasonable to you? > > > > Thanks, > > Severin > > > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > > Build changes look ok to me. > > > > > > /Erik > > > > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > would report as "ppc64" via os.arch system property which breaks > > > > tooling such as maven in as much as if some dependency needs native > > > > libraries it would download BE binaries where it actually should > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > pre: > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > java.library.path = > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > os.arch = ppc64 > > > > > > > > post: > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > java.library.path = > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > os.arch = ppc64le > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > 8073139/jdk8/01/ > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > > > for JDK/hotspot changes. > > > > > > > > This backport should only have minor differences to the changes in JDK > > > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > > > From goetz.lindenmaier at sap.com Thu Oct 4 14:47:47 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 14:47:47 +0000 Subject: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <666987d08f324a0c94208c6cca403214@sap.com> Message-ID: Thanks! I'm fine for this to go to 8. Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 4. Oktober 2018 16:40 > To: Lindenmaier, Goetz ; Erik Joelsson > ; hotspot-dev dev at openjdk.java.net>; ppc-aix-port-dev dev at openjdk.java.net>; build-dev > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory and > os.arch value on ppc64le cause issues with Java tooling > > Hi Goetz, > > On Tue, 2018-10-02 at 10:40 +0000, Lindenmaier, Goetz wrote: > [...] > > Did you test this on ppc64 be, too? > > I've tested this patch on PPC64 BE Linux now too. There is no change > (as expected): > > $ ./jdk8-ppc64be-after/bin/java TestProperty > os.arch == ppc64 > java.library.path == > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > $ ./jdk8-ppc64be-before/bin/java TestProperty > os.arch == ppc64 > java.library.path == > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > Thanks, > Severin > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: ppc-aix-port-dev > On > > > Behalf Of Severin Gehwolf > > > Sent: Dienstag, 2. Oktober 2018 12:34 > > > To: Erik Joelsson ; hotspot-dev > > dev at openjdk.java.net>; ppc-aix-port-dev > > dev at openjdk.java.net>; build-dev > > > Subject: Re: [PING] [8u] RFR: 8073139: PPC64: User-visible arch directory > and > > > os.arch value on ppc64le cause issues with Java tooling > > > > > > Hi, > > > > > > Pinging PPC porters. Does this look reasonable to you? > > > > > > Thanks, > > > Severin > > > > > > > > > On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > > > > Build changes look ok to me. > > > > > > > > /Erik > > > > > > > > > > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > > would report as "ppc64" via os.arch system property which breaks > > > > > tooling such as maven in as much as if some dependency needs > native > > > > > libraries it would download BE binaries where it actually should > > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > > > pre: > > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > > java.library.path = > > > > > > /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > > os.arch = ppc64 > > > > > > > > > > post: > > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > > java.library.path = > > > > > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > > os.arch = ppc64le > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > 8073139/jdk8/01/ > > > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port- > dev > > > > > for JDK/hotspot changes. > > > > > > > > > > This backport should only have minor differences to the changes in > JDK > > > > > 11. We have been using similar patches in Fedora for months. > Thoughts? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > > > > > From erik.joelsson at oracle.com Thu Oct 4 16:24:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Oct 2018 09:24:05 -0700 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: <4B983400-2EA8-4AAE-8C82-6AF78FF9226E@oracle.com> References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> <5EE9A9D0-6A94-4616-A2F6-14D46D95EFB6@oracle.com> <4B983400-2EA8-4AAE-8C82-6AF78FF9226E@oracle.com> Message-ID: Looks good. Minor style issue, the broken find line should be indented 4 spaces for continuation. Strictly speaking so should the awk program lines be in this case. No need for respin. /Erik On 2018-10-04 06:31, Magnus Ihse Bursie wrote: >> 4 okt. 2018 kl. 15:03 skrev Robin Westberg : >> >> Hi Magnus, >> >> Thanks again for reviewing! >> >>>> On 4 Oct 2018, at 13:38, Magnus Ihse Bursie wrote: >>>> >>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.04/ >>> I was about to say that this looks good, but then I discovered a weird thing. I'm the SED line, line 50, there is a weird C-like Unicode character instead of a quote, after -e. Looks really odd. Is it a "smart quote" gone wrong? Can you look into it and fix it? You don't need to respin the webrev for that. Otherwise, you're all good to go. >> Ah indeed, nice catch! Fortunately it seems to be an issue with the ?git-webrev? tool, there?s a missing semicolon in the html?ized version: $(SED) -e Ƈs/^/[. (The ?raw? view for example is correct). > Good. > >> I did notice one more thing that I was hoping to sneak into an in-place update: the raw ?cat? on line 47 should probably be $(CAT) as well, right? I?ll sanity check it with that change to be certain. > Yeah, it should. Shame on me and Erik for not catching it. ;-) > > No need to respin. > > /Magnus > >> Best regards, >> Robin >> >>> /Magnus >>> >>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03-04/ >>>> >>>> Best regards, >>>> Robin >>>> >>>>> Otherwise I think this is good now. >>>>> >>>>> /Erik >>>>>>>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? >>>>>> What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. >>>>>> >>>>>> Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >>>>>> >>>>>>>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. >>>>>> Fixed. >>>>>> >>>>>>>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. >>>>>> Fixed. >>>>>> >>>>>>>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>>>>>>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>>>>>>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>>>> >>>>>>>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>>>>>>> >>>>>>>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>>>>>>> >>>>>>> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >>>>>>> >>>>>>> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>>> and when compiling do this: >>>>>>> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >>>>>>> >>>>>>> That would get rid of the filter-out, keep duplication low but still be readable. >>>>>>> >>>>>>> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. >>>>>> Sounds good, fixed. >>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> Erik, what do you think? >>>>>>>> >>>>>>>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. >>>>>> Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >>>>>> >>>>>>>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>>>>>>> >>>>>>>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? >>>>>> What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). >>>>>> >>>>>> This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. >>>>>> >>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ >>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ >>>>>> >>>>>> Best regards, >>>>>> Robin >>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>>> Otherwise this looks good now. >>>>>>>>> Thanks, I?ll include the latest webrevs with a comment added: >>>>>>>>> >>>>>>>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>>>>>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Robin >>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Robin >>>>>>>>>>> >>>>>>>>>>>> /Erik >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>>>>>>> >>>>>>>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>>>>>>> >>>>>>>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>>>>>>> >>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Robin >>>>>>>>>>>>> >>>>>>>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html From erik.joelsson at oracle.com Thu Oct 4 16:42:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 4 Oct 2018 09:42:47 -0700 Subject: RFR: JDK-8211677: Java resource copy and clean should use MakeTargetDir macro In-Reply-To: References: <0363e3c8-3794-1cfa-30dd-1d0febc6d0d0@oracle.com> Message-ID: <1a9ac14c-9ffd-a3f2-5518-c489b1c1c451@oracle.com> Hello, On 2018-10-04 04:47, Magnus Ihse Bursie wrote: > Looks good to me. > > Have you searched the code for more instances of mkdir -p? > Just did, lots of places. I will create a followup issue for this. The current issue is failing too many builds in our CI to not be fixed fast. > Also, maybe we should check if using AC_PROG_MKDIR_P would give us a > better option on Solaris. (See > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Particular-Programs.html#Particular-Programs). > It is supposed to give a non-race prone version of mkdir -p. > > Just to be clear: Even if we start using it for MKDIR_P, I still think > it's a good idea to use our macro. > That's certainly interesting and should be investigated. I will add it to the followup issue. /Erik > /Magnus > > 4 okt. 2018 kl. 00:51 skrev Erik Joelsson >: > >> Since upgrading our Solaris build machines to 11.3, we have >> experienced intermittent build failures in the recipes copying java >> resource files. It's unclear why this started happening now after >> having worked fine for so long, but it seems it's a race caused by >> concurrent calls to "mkdir -p". In other recipes we have worked >> around this by using a macro "MakeDir" which reduces the likelihood >> of concurrent calls happening. Rewriting these copy and clean rules >> to use the current preferred macros seem to alleviate the problem for >> us on Solaris 11.3, and also makes the build a little bit more coherent. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211677 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8211677/webrev.01/ >> >> >> /Erik >> From kim.barrett at oracle.com Thu Oct 4 20:39:31 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 16:39:31 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <1340C14C-265B-4DC7-A00E-0C3BD3B42AD0@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> <47ABAD88-9376-45D3-86DB-16A47B81F061@oracle.com> <55464073-BF13-4D30-9FA7-829778F698E8@oracle.com> <1340C14C-265B-4DC7-A00E-0C3BD3B42AD0@oracle.com> Message-ID: > On Oct 4, 2018, at 9:14 AM, Magnus Ihse Bursie wrote: > > 3 okt. 2018 kl. 00:18 skrev Kim Barrett : > >> I went through all the associated warnings for gcc7.3 and categorized >> them. Some are just not interesting or relevant to us. I think these >> include >> >> [?] > > I agree that some, like clobbered, is not relevant (but I think that also only applies to C code..?). In general, it doesn't hurt though, to turn on warnings that are unlikely to be triggered. I realize it also helps little to nothing, but once again, if this is the price we have to pay for catching some real problems, it's a small price indeed. I made this list for completeness of discussion. I think these options should carry no weight and should just be ignored in the decision making process. > OTOH, I don't really agree that old-style-declaration is irrelevant. At least in the JDK libraries there are multiple places where non-prototype declarations are made, and apart from the style issue, it's a bug waiting to happen if the function change its signature. I don't remember if this is the case in Hotspot too, but it wouldn't surprise me, if we don't check for it. Regarding -Wold-style-declaration, remember that we're discussion a change to HotSpot, where this isn't relevant. > empty-body is mostly good at catching style issues, like double semicolons. It's not a big deal, but it also never hurts to keep up good code quality. I have not seen it make any false positives. -Wempty-body doesn't catch empty semi-colons (which are permitted in C++11 and later, and no compiler I know of complains about them in C++98 mode, because they arise too often with conditional compilation and macros and such). There is also a well-known macro idiom involving empty if bodies, e.g. if (!) {} else to avoid dangling else. Since you didn't run into any occurences of this warning, we're probably not using that idiom right now. But there's nothing wrong with it and I've used it myself in the past. It could have been used in some of the UL macros, but a different idiom was used there. (The two are semantically mostly equivalent, the differences being fairly subtle. If I'd written these macros they would probably be using the "if" style.) > shift-negative-values is a bit beyond me, but as I understand it, it warns about a behavior that has changed recently, or will be changed, in the standards, to become undefined. That sounds to me like something that it would be better to act preemptively on. But then again, I might have misunderstood things. If so, we can definitely turn it off. I mis-remembered the situation with -Wshift-negative-value; we probably do want that turned on once we've eliminated uses (and there are some). C89/C++98 didn't specify the behavior in that case. C99/C++11 clarified that it is explicitly UB. >> -Wimplicit-fallthrough=3 requires a structured comment or C++17 >> feature to quiet the warning in code that is using the feature. >> Provides some benefit. I'm surprised there aren't any warnings from >> this. Intentional fall-through is a pretty common idiom. > > At level 3, the "structured" comment is just something like a line like this: > > // fallthrough > > Most, maybe all, fallthroughs in the hotspot code already does that. I think it's a reasonable requirement to show that the fallthrough is intentional. If you think it's too strong, we can lower it to level 1, which just requires a comment, with whatever text (or even empty, I think). I'm concerned that other compilers / checkers might want other comments, and one might end up with a bit of a mess because of that. If Visual Studio (for example) has a similar warning option, we might want to turn that on too. >> I think the benefit we get from detecting future occurrences of the >> copy constructor bug is not really worth the current cost of "fixing" >> the occurrences of conditional expressions with enumerators. I might >> feel differently if a pass were made through those to replace uses of >> enum with static const members. > > So I think this is what it really boils down to. Just to summarize/repeat what you said, so I'm sure we understand each other correctly: > > There's an upside to enabling Wextra; we know already that it found some real bugs, but the real benefit is all future potential bugs it will prohibit, and that's hard to quantify. On the other hand, there's a downside; and that's the conditional enum warnings, whose fixes are ugly. But, if the code was cleaned up, so those enum fixes were no longer ugly, then it would be a net positive to turn on Wextra. > > I think that's a reasonable solution for now. If we agree on this, I'll open a new bug with just the copy constructor fixes, and a enhancement request for replacing the enums with static const, and making the current bug ("turn on Wextra") dependent on that. That seems like a good plan to me. > I just want to add a final remark about compiler warnings. When I started the current work of normalizing the set of warnings in the entire OpenJDK, I was amazed at what low level of warnings that was used for gcc/clang in hotspot. In all the JDK native libraries, -Wall and -Wextra were on by default. In hotspot, not even -Wall were turned on! I think what have sort of "saved" you is that Microsoft CL was running with /W3, which is roughly equivalent to -Wall -Wextra. So most of the shared code compiled fine when adding -Wall -Wextra, but there was a lot of new warnings in non-Windows code. Of course, /W3 and -Wall -Wextra does not cover exactly the same set of warnings, nor implement similar warning checks identically, hence the current open set of warnings in shared code. I mostly agree with this, though the version to version changes in the content of these umbrella warning sets is a concern. > I made a long list of warnings that are disabled due to this, but I think it would be a good idea to tackle them one by one. By a quick glance, most of them (but surely not all) seemed to point to real problematic code; if not buggy so at least bad style. Yes. For example, Mikael V has a patch set to enable -Wunused-variable. It?s unpleasantly large and in some parts intrusive. And there is https://bugs.openjdk.java.net/browse/JDK-8135181 Re-enable '-Wconversion' for GCC 4.3 and later which would also be huge and intrusive. From kim.barrett at oracle.com Thu Oct 4 21:01:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:01:03 -0400 Subject: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <71fb517fba794dc28291cf51afb6e8b9@sap.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <71fb517fba794dc28291cf51afb6e8b9@sap.com> Message-ID: <2DB05A59-EA8F-46FD-9ECF-CA47DA5E313E@oracle.com> > On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz wrote: > > Hi, > > I appreciate this is handled in a JEP and well communicated! > > XLc, the compiler we use for AIX, might be a bottleneck here. > > But we currently have no compiler-constraints by products on > our aix port of jdk12 (for jdk11 we must stay with the current > compiler xlc 12 which does not support C++11, and jdk11 even > should be compilable with aCC by HP for which we won't > get new versions!) > > We will update our compiler for jdk/jdk to the most recent Xlc > as soon as possible. > To my current knowledge, Xlc 14 was dropped, and xlc 16 > is to be released early 2019. It is supposed to support > C++ 11, and also some C++ 14 features. The information I've been able to find mostly discusses Linux support for XLC 16. Any information about "some C++14 features"? I haven't found any detail on that. I am working toward being able to target this for JDK 12, but realize that might not be reachable. Windows is already there, because of VS2017 support. There are a couple of minor patches needed for gcc and clang based builds; Linux-x64 and MacOSX-x64 have had a fair amount of ad hoc testing. We (Oracle) only switched over the Solaris/sparc builds to the necessary compiler version (Oracle Studio 12.6) very recently, and there are some issues still to be dealt with there. And the currently used XLC is just not up to the change. From kim.barrett at oracle.com Thu Oct 4 21:09:57 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:09:57 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> Message-ID: <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> > On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov wrote: > > Kim, > > Thank you for posting this. It's an important step to make. I wanted to clarify a couple of points: > > 1. Since this is infrastructure JEP, is the version of JDK which will undergo such changes going to be some future version or does it apply to past versions as well? I'm concerned with how we can simplify security backports to 8u which (I currently assume) is not subject to this change. Future version (perhaps as soon as JDK 12). I don't think there is any desire to backport this change. And yes, introducing the use of new language features will make backports even more interesting than they already are. That seems unavoidable if we're going to pursue this direction. > 2. Which versions of GCC do you tentatively consider at this point? Non-x86 ports may have a problem upgrading to a specific version of GCC which the shared code will use and may need additional lead time to adjust. I think our (ad hoc) testing has been limited to gcc 7.x. But looking at the gcc language conformance tables and release notes, gcc 5.x might be good enough, and gcc 6.x seems fairly likely sufficient. Of course, older versions are more likely to have bugs in some of these new features. Updating the minimum supported versions for gcc and clang are noted as TBD in the JEP. From kim.barrett at oracle.com Thu Oct 4 21:18:05 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:18:05 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> Message-ID: <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> > On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie wrote: >> That all assumes that static build actually works at all; it doesn?t look like we >> test that configuration these days, so who knows what bit rot may have set in. >> > > No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. > > This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. > > The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. > > The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. > > /Magnus The "static build" doesn't build anymore. We're all shocked that this untested configuration has bit-rotted. :) LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the workaround is superfluous in that case. Given that, I'm going to delete the workaround and file an RFE [1] to fix or remove the currently broken "static build" support, with a comment there referring to this workaround code as possibly being relevant to fixing the static build. [1] https://bugs.openjdk.java.net/browse/JDK-8211732 New webrev: http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ From mikael.vidstedt at oracle.com Thu Oct 4 21:25:06 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 4 Oct 2018 14:25:06 -0700 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> Message-ID: > On Oct 4, 2018, at 2:18 PM, Kim Barrett wrote: > >> On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie wrote: >>> That all assumes that static build actually works at all; it doesn?t look like we >>> test that configuration these days, so who knows what bit rot may have set in. >>> >> >> No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. >> >> This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. >> >> The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. >> >> The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. >> >> /Magnus > > The "static build" doesn't build anymore. We're all shocked that this > untested configuration has bit-rotted. :) > > LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the > workaround is superfluous in that case. Given that, I'm going to > delete the workaround and file an RFE [1] to fix or remove the > currently broken "static build" support, with a comment there > referring to this workaround code as possibly being relevant to fixing > the static build. I?m glad to see this gone. Looks good! Cheers, Mikael > > [1] https://bugs.openjdk.java.net/browse/JDK-8211732 > > New webrev: > http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ > From david.holmes at oracle.com Thu Oct 4 21:31:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Oct 2018 07:31:33 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> Message-ID: <2dad2275-684a-50f6-d4ef-f20e2c7241b1@oracle.com> Looks good! Thanks for your patience and perseverance! :) David On 5/10/2018 7:18 AM, Kim Barrett wrote: >> On Oct 4, 2018, at 9:27 AM, Magnus Ihse Bursie wrote: >>> That all assumes that static build actually works at all; it doesn?t look like we >>> test that configuration these days, so who knows what bit rot may have set in. >>> >> >> No, we don't test static build, and never have. I'd be surprised if it's still possible to build a static build. >> >> This was a feature developed for the mobile project. The static build part was merged, somewhat hastily, into mainline, but the rest of the mobile code is still lingering in the mobile project fork. >> >> The entire "static build" concept was somewhat artificially injected in some parts of the build code. It is for instance not possible to build all modules with a static build. At the very least you need to build without java.desktop, if I remember correctly. >> >> The motivation for the static build is that on iOS, apps are not allowed to load dynamic libraries (for some reason only Apple knows). So a developer that wants to build a Java app needs to have a static library version of the entire JDK to link with into a single executable Java launcher. So in this perspective, the entire use of dlopen in a static build smells funny, and might be just a left-over from static build being more of a hack than a properly supported build option. >> >> /Magnus > > The "static build" doesn't build anymore. We're all shocked that this > untested configuration has bit-rotted. :) > > LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the > workaround is superfluous in that case. Given that, I'm going to > delete the workaround and file an RFE [1] to fix or remove the > currently broken "static build" support, with a comment there > referring to this workaround code as possibly being relevant to fixing > the static build. > > [1] https://bugs.openjdk.java.net/browse/JDK-8211732 > > New webrev: > http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ > From kim.barrett at oracle.com Thu Oct 4 21:53:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:53:27 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <3C557F9A-82B7-4941-850B-EA2D0ED44EDA@oracle.com> > On Oct 4, 2018, at 4:35 AM, Volker Simonis wrote: > > Hi Tim, Jeff, > > Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) > > https://bugs.openjdk.java.net/browse/JDK-8208089 Note that this list is intended as a starting point. The JEP also describes a process for adding to the list of permitted features, and I anticipate that process will be used. There are several that I personally think would be good to add (perhaps with some limits or restrictions), but that I think may involve more detailed discussion. And other folks may have their favorite must have feature(s) that didn?t seem to me to be needed in this initial seed list. From kim.barrett at oracle.com Thu Oct 4 22:32:41 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 18:32:41 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> Message-ID: > On Oct 4, 2018, at 5:25 PM, Mikael Vidstedt wrote: >> The "static build" doesn't build anymore. We're all shocked that this >> untested configuration has bit-rotted. :) >> >> LoadJavaVM uses RTLD_NOW in the normal (non-"static build") case, the >> workaround is superfluous in that case. Given that, I'm going to >> delete the workaround and file an RFE [1] to fix or remove the >> currently broken "static build" support, with a comment there >> referring to this workaround code as possibly being relevant to fixing >> the static build. > > I?m glad to see this gone. Looks good! Thanks! > > Cheers, > Mikael > >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211732 >> >> New webrev: >> http://cr.openjdk.java.net/~kbarrett/8211296/open.01/ From kim.barrett at oracle.com Thu Oct 4 22:33:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 18:33:27 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <2dad2275-684a-50f6-d4ef-f20e2c7241b1@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> <4052541c-8f3a-f7e4-a094-11beadd6a60d@oracle.com> <0a2f01f4-608e-0a1c-dd4d-9d2c859524a9@oracle.com> <6BA6A076-FABB-40E4-9BBE-8F10A03A8A9A@oracle.com> <250FA229-7F95-4FB9-935D-7834A203072F@oracle.com> <39BB147B-089C-44D6-BD29-3F5B906D9EE9@oracle.com> <2dad2275-684a-50f6-d4ef-f20e2c7241b1@oracle.com> Message-ID: <724BAC82-812B-40F6-84F9-9327203101B3@oracle.com> > On Oct 4, 2018, at 5:31 PM, David Holmes wrote: > > Looks good! > > Thanks for your patience and perseverance! :) Thanks! And thanks for your patience and perseverance too! > > David From robin.westberg at oracle.com Fri Oct 5 07:19:00 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Fri, 5 Oct 2018 09:19:00 +0200 Subject: RFR: 8210459: Add support for generating compile_commands.json In-Reply-To: References: <122874D8-677B-4A8A-B245-01CFFAB14728@oracle.com> <4ffd81eb-cadd-ee7f-557c-eacd958d2c61@oracle.com> <5CEE1003-9137-456A-A2CD-6ED3AFEDED3A@oracle.com> <062a155d-3d71-a071-d704-3cc14ec8fb21@oracle.com> <82437FE0-D01E-4CB5-B7C7-132E76BFC5AF@oracle.com> <97107A5B-17B4-48F3-9D5D-CB03A8AAF0F3@oracle.com> <17d72bb8-e62c-b265-d872-7aad419f8f56@oracle.com> <1E76F3F8-AFA4-4E63-8F41-0F869F4A482B@oracle.com> <5EE9A9D0-6A94-4616-A2F6-14D46D95EFB6@oracle.com> <4B983400-2EA8-4AAE-8C82-6AF78FF9226E@oracle.com> Message-ID: <5D15C96E-7620-4636-A3C1-2D688B9D4ABE@oracle.com> Hi Erik & Magnus, Thanks for the final reviews, pushed it with the suggested changes. Best regards, Robin > On 4 Oct 2018, at 18:24, Erik Joelsson wrote: > > Looks good. > > Minor style issue, the broken find line should be indented 4 spaces for continuation. Strictly speaking so should the awk program lines be in this case. No need for respin. > > /Erik > > > On 2018-10-04 06:31, Magnus Ihse Bursie wrote: >>> 4 okt. 2018 kl. 15:03 skrev Robin Westberg : >>> >>> Hi Magnus, >>> >>> Thanks again for reviewing! >>> >>>>> On 4 Oct 2018, at 13:38, Magnus Ihse Bursie wrote: >>>>> >>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.04/ >>>> I was about to say that this looks good, but then I discovered a weird thing. I'm the SED line, line 50, there is a weird C-like Unicode character instead of a quote, after -e. Looks really odd. Is it a "smart quote" gone wrong? Can you look into it and fix it? You don't need to respin the webrev for that. Otherwise, you're all good to go. >>> Ah indeed, nice catch! Fortunately it seems to be an issue with the ?git-webrev? tool, there?s a missing semicolon in the html?ized version: $(SED) -e Ƈs/^/[. (The ?raw? view for example is correct). >> Good. >> >>> I did notice one more thing that I was hoping to sneak into an in-place update: the raw ?cat? on line 47 should probably be $(CAT) as well, right? I?ll sanity check it with that change to be certain. >> Yeah, it should. Shame on me and Erik for not catching it. ;-) >> >> No need to respin. >> >> /Magnus >> >>> Best regards, >>> Robin >>> >>>> /Magnus >>>> >>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03-04/ >>>>> >>>>> Best regards, >>>>> Robin >>>>> >>>>>> Otherwise I think this is good now. >>>>>> >>>>>> /Erik >>>>>>>>> The AWT constructs also confuses me. Maybe you can expand a bit on the comment, because it really is non-trivial. You are executing a cp for each tmpfile you find? But what if you find multiple tmpfiles? There could certainly be multiple commands using @ constructs? >>>>>>> What it does it actually to invoke fixpath on everything inside the final compile_commands.json file, but in order to make fixpath do that, it presents the compile_commands.json file as an @-argument. Fixpath will then translate that argument to a temporary filename containing corrected paths, and that?s the file we save (since it?s deleted when the invoked command terminates). I?ve updated the comment a bit, hopefully it?s more clear now. >>>>>>> >>>>>>> Another option would be to extend the fixpath utility itself to support some additional argument to just do inline path correction on a given file, but I felt that it would be a more risky change. >>>>>>> >>>>>>>>> * In make/Main.gmk, you can just do "($(CD) $(OUTPUTDIR) && $(RM) -r build*.log* compile_commands.json)" on a single line. >>>>>>> Fixed. >>>>>>> >>>>>>>>> * In make/common/MakeBase.gmk: I'd prefer if these functions were move to make/common/JdkNativeCompilation.gmk, close to the FindSrcDirsForLib etc definitions. >>>>>>> Fixed. >>>>>>> >>>>>>>>> * In make/common/NativeCompilation.gmk, I'm not entirely happy with the $1_OBJ_COMMON_OPTIONS_PRE/POST construct. I understand what you are trying to achieve, but I think this gets very hard to read. I don't have a perfect solution in mind. But perhaps something like this: >>>>>>>>> $1_DEPS_OPTIONS := $$($1_DEP_FLAG) $$($1_DEP).tmp >>>>>>>>> $1_COMPILE_COMMAND := $$($1_COMPILER) $$($1_FLAGS) $$($1_DEPS_OPTIONS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>>>>> >>>>>>>>> and for the compile commands, use $$(filter-out $$($1_DEPS_OPTIONS), $$($1_COMPILE_COMMAND)). >>>>>>>>> >>>>>>>>> Perhaps some unification with the Microsoft toolchain is possible by setting $1_DEPS_OPTIONS to -showIncludes. >>>>>>>>> >>>>>>>> An alternative, perhaps better, is to move the deps flag to the start. Then you could do something like the above, but set >>>>>>>> >>>>>>>> $1_COMPILE_OPTIONS := $$($1_FLAGS) $(CC_OUT_OPTION)$$($1_OBJ) $$($1_SRC_FILE)) >>>>>>>> and when compiling do this: >>>>>>>> $$($1_COMPILER) $$($1_DEPS_OPTIONS) $$($1_COMPILE_OPTIONS) >>>>>>>> >>>>>>>> That would get rid of the filter-out, keep duplication low but still be readable. >>>>>>>> >>>>>>>> This assumes that ordering for the deps option is irrelevant. I think it is but it would have to be tested. >>>>>>> Sounds good, fixed. >>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>> Erik, what do you think? >>>>>>>>> >>>>>>>>> * In make/lib/Lib-jdk.accessibility.gmk, this seems double incorrect. You are missing a libjawt path segment. And you wanted to use FindStaticLib. >>>>>>> Ah, good catch, I suspect it still works as the jawt.lib file in the modules_lib folder is dependent on jawt.lib in the native folder. Fixed. >>>>>>> >>>>>>>>> Overall, I believe we're misusing the "static lib" concept on Windows. The .lib files are not static libs, the way we mean it on unixes. Instead, the lib files is some kind of metadata on dll that are used when linking with those dlls. So we should introduce a better concept for these, and maybe something like FindLibDescriptor (or whatever). That should not really be part of this fix, though, so for the moment I'm going to accept that we call these "static libs" on Windows. >>>>>>>>> >>>>>>>>> This also makes me wonder how much testing this patch has recieved? I know a broken dependency in the worst case only shows up as a race, but have you verified it thoroughly even on Windows? And even without compile_commands? >>>>>>> What I?ve been doing, apart from making sure tier1 tests and tier5-builds for all platforms still work, is to ?diff? the .cmdline files from a build of ?make jdk? with and without the patch applied (and with --with-version-opt= set during configure to avoid the timestamp). The only difference so far is that the EXTRA_OBJECT_FILES change for the make/launcher/Launcher-jdk.pack.gmk moves the files from the command line to an @file, but the contents are the same. (Had to apply a bit of sed to perform this verification after reordering the dependency flags, but still looks correct). >>>>>>> >>>>>>> This obviously won?t catch any subtle dependency mistakes though, not sure if there?s much to be done about that though unfortunately. >>>>>>> >>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.03/ >>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02-03/ >>>>>>> >>>>>>> Best regards, >>>>>>> Robin >>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>>>> Otherwise this looks good now. >>>>>>>>>> Thanks, I?ll include the latest webrevs with a comment added: >>>>>>>>>> >>>>>>>>>> Incremental: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01-02/ >>>>>>>>>> Full: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.02/ >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> Robin >>>>>>>>>> >>>>>>>>>>> /Erik >>>>>>>>>>>> Webrev (incremental): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00-01/ >>>>>>>>>>>> Webrev (full): http://cr.openjdk.java.net/~rwestberg/8210459/webrev.01/ >>>>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>>>> >>>>>>>>>>>> Best regards, >>>>>>>>>>>> Robin >>>>>>>>>>>> >>>>>>>>>>>>> /Erik >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 2018-09-10 06:36, Robin Westberg wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please review the following change that adds support for generating compile_commands.json as a top-level make target. This is a popular format for describing how to compile object files for a project, and is defined in [1]. This file can be used directly by IDEs such as Visual Studio Code and CLion as well as "language servers" such as cquery [2] and rtags [3]. >>>>>>>>>>>>>> >>>>>>>>>>>>>> While it?s currently possible to generate this file as part of a full build (using tools such as Bear [4], or simply parsing .cmdline files), this change aims to make it possible to generate the compile commands data without actually compiling the object files. This means that it?s for example possible to start using an IDE fairly quickly on freshly cloned source, instead of having to wait for a full build to complete. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This was originally inspired by the work done in [5] by Mikael Gerdin and Erik Joelsson, but has been through a few revisions since then. Erik has also provided a lot of assistance with the current version, thanks Erik! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210459 >>>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~rwestberg/8210459/webrev.00/ >>>>>>>>>>>>>> Testing: tier1, builds-tier5 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>> Robin >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] https://clang.llvm.org/docs/JSONCompilationDatabase.html >>>>>>>>>>>>>> [2] https://github.com/cquery-project/cquery >>>>>>>>>>>>>> [3] https://github.com/Andersbakken/rtags >>>>>>>>>>>>>> [4] https://github.com/rizsotto/Bear >>>>>>>>>>>>>> [5] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-March/026354.html > From erik.helin at oracle.com Fri Oct 5 07:58:53 2018 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Oct 2018 09:58:53 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <940757E3-8781-4E7A-B5B9-1F0D3E944E0F@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <940757E3-8781-4E7A-B5B9-1F0D3E944E0F@oracle.com> Message-ID: <8a771c9d-0803-d8c7-20f2-675733d416c4@oracle.com> On 10/4/18 2:31 PM, Magnus Ihse Bursie wrote:>> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg : >> I like this initiative. I'm wondering if some of these rules can be easily >> codified or written into a jcheck style checker (ccheck?) so that Authors >> can adhere to the conventions and not rely on a Human review to pick out >> where that convention isn't met. > > That's an interesting thought! > > I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.) > > I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code. As usual there is of a third route, this one is "just a matter of programming" :) The (probably) easiest way to enforce usage of only a subset of C++ is to write custom clang-tidy checks [0]. We could most likely write a couple of ASTMatchers [1] to watch out for features we do not want. It used to be very hard to use the clang tooling with HotSpot, but thanks to Robin Westberg's compile-commands patch [2] that just went in, this is no longer an issue. Unfortunately I don't think requiring all contributors to install a custom version of clang-tidy with HotSpot checks is feasible, this is more something you would want to run in a CI setup. Thanks, Erik [0]: https://clang.llvm.org/extra/clang-tidy/#writing-a-clang-tidy-check [1]: http://clang.llvm.org/docs/LibASTMatchers.html [2]: http://hg.openjdk.java.net/jdk/jdk/rev/804792ce736f From goetz.lindenmaier at sap.com Fri Oct 5 08:13:21 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Oct 2018 08:13:21 +0000 Subject: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <2DB05A59-EA8F-46FD-9ECF-CA47DA5E313E@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <71fb517fba794dc28291cf51afb6e8b9@sap.com> <2DB05A59-EA8F-46FD-9ECF-CA47DA5E313E@oracle.com> Message-ID: <22d25e558b2d426f827d3322b9a56d3a@sap.com> Hi Kim, > for XLC 16. Any information about "some C++14 features"? I haven't > found any detail on that. we will user our internal connections to IBM to find out :) Best regards, Goetz. > -----Original Message----- > From: Kim Barrett > Sent: Donnerstag, 4. Oktober 2018 23:01 > To: Lindenmaier, Goetz > Cc: hotspot-dev developers ; build-dev > ; core-libs-dev at openjdk.java.net > Subject: Re: JEP JDK-8208089: Implement C++14 Language Features > > > On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > I appreciate this is handled in a JEP and well communicated! > > > > XLc, the compiler we use for AIX, might be a bottleneck here. > > > > But we currently have no compiler-constraints by products on > > our aix port of jdk12 (for jdk11 we must stay with the current > > compiler xlc 12 which does not support C++11, and jdk11 even > > should be compilable with aCC by HP for which we won't > > get new versions!) > > > > We will update our compiler for jdk/jdk to the most recent Xlc > > as soon as possible. > > To my current knowledge, Xlc 14 was dropped, and xlc 16 > > is to be released early 2019. It is supposed to support > > C++ 11, and also some C++ 14 features. > > The information I've been able to find mostly discusses Linux support > for XLC 16. Any information about "some C++14 features"? I haven't > found any detail on that. > > I am working toward being able to target this for JDK 12, but realize > that might not be reachable. Windows is already there, because of > VS2017 support. There are a couple of minor patches needed for gcc > and clang based builds; Linux-x64 and MacOSX-x64 have had a fair > amount of ad hoc testing. We (Oracle) only switched over the > Solaris/sparc builds to the necessary compiler version (Oracle Studio > 12.6) very recently, and there are some issues still to be dealt with > there. And the currently used XLC is just not up to the change. From jiangli.zhou at oracle.com Fri Oct 5 16:57:05 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 5 Oct 2018 09:57:05 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <0f79551e-5f0a-b7f4-cc72-eb84ed8baa14@oracle.com> References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> <0f79551e-5f0a-b7f4-cc72-eb84ed8baa14@oracle.com> Message-ID: <37b2f736-88dc-f523-1551-0a87c3fb1a4b@oracle.com> Dear all, JEP 341, Default CDS Archive has been targeted to JDK 12 (please see Mark's email from yesterday, Re: JEP proposed to target JDK 12: 341: Default CDS Archives). Code review, testing and performance runs are completed for the default CDS archive changes. I've started the final pre-integration test yesterday with all tier1 - tier8. So far most of the tiers have been completed. Just a heads up, I'm planning to integrate the change in the next few hour. Thanks everyone for contributing to this effort!!! Jiangli On 9/6/18 12:45 PM, Jiangli Zhou wrote: > Hi, > > The JEP (http://openjdk.java.net/jeps/341) for the default CDS > archives is now a candidate. Please see Mark's email, 'New candidate > JEP: 341: Default CDS Archives'. Please help test Erik's makefile > patch for your platform if it is not built/tested in openjdk mainline > to prevent any possible breakage on your side. Any comments/feedbacks > on the default CDS archive are highly appreciated! > > ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/ > > The above webrev is sync'ed with the lasted jdk/jdk repository today. > > Thanks! > > Jiangli > > On 8/30/18 11:26 AM, Jiangli Zhou wrote: >> Hi Magnus, >> >> Sounds good. Will update the message. >> >> Thanks! >> >> Jiangli >> >> >> On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote: >>> On 2018-08-29 17:45, Erik Joelsson wrote: >>>> >>>> Hello Magnus, >>>> >>>> As the author of the build changes I will answer this. >>>> >>>> On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >>>>> On 2018-08-28 18:25, Erik Joelsson wrote: >>>>>> Build changes look good to me (but should probably get review >>>>>> from someone else). >>>>> >>>>> I'm (as usually) not as happy as Erik. ;-) >>>>> >>>>> In Images.gmk, you have added this rule: >>>>> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >>>>> >>>>> It took me a while to grasp. You are relying on >>>>> $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only >>>>> incidentally so. This file is just picked arbitrarily to represent >>>>> when the entire image is done, for make. Please use >>>>> $(JRE_IMAGE_DIR)/bin/java instead. >>>>> >>>> I can agree with this part. That was a bit of a hack done in a hurry. >>>>> The logic in jdk-options.m4 is broken. If indeed it is not >>>>> possible to use cds archive with zero, then things will break >>>>> since it will still be built if using --enable-cds-archive! >>>>> >>>>> What you should do is to set default to true unless using cross >>>>> compilation or zero. If the user explicitly sets >>>>> --enable-cds-archive, and it's not possible, a fatal error should >>>>> be generated. >>>>> >>>> Here I'm not as sure. I deliberately let it be possible to override >>>> the default behavior for zero as someone might want to fix that at >>>> some point, you never know. For cross compilation it's just not >>>> possible ever so that's different. Maybe my reasoning is invalid. >>> >>> I see. I still think it would have made more sense, in that case, to >>> set the default to false if using zero, but allow override. But I'm >>> not going to insist on that. >>> >>> However, if the problem with zero is not that it's technically >>> impossible, just that it's not tested, I think the message should be >>> changed from "[no, not possible with JVM variant zero]" to just >>> "[no]" with a comment in the configure script that it's off by >>> default since it's not tested. >>> >>> Apart from that, Jiangli's latest webrev looks good. >>> >>> Jiangli: If you fix it like I suggested, you do not need to respin >>> the webrev. >>> >>> /Magnus >>> >>>> >>>> /Erik >>>>> Apart from this, I'm more on Erik's line. :-) >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>>>> Please review the implementation for JEP JDK-8204247 >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>>>> default CDS archive is generated using the default classlist >>>>>>> (resides in the lib/ directory) at JDK build time. Any >>>>>>> comments/suggestions are highly appreciated. >>>>>>> >>>>>>> All makefile changes in the webrev are contributed by Erik >>>>>>> Joelsson (many thanks!!). >>>>>>> >>>>>>> This is a combination of efforts from different teams and >>>>>>> individuals. Thanks to everyone who has been involved in the JEP >>>>>>> & implementation discussions, testing and bug fixing! >>>>>>> >>>>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>>>> >>>>>>> Two sanity test cases for the default CDS archive are included >>>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>>>> intended for in-depth CDS functional testing, which is already >>>>>>> covered by the existing cds/appcds tests and all tiered tests >>>>>>> executing with the default CDS archive enabled. >>>>>>> >>>>>>> As part of the webrev, >>>>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also >>>>>>> fixed to use larger java heap (JDK-8209739 >>>>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>>>> >>>>>>> Tests executed: >>>>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>>>> ?- JCK lang, api and vm tests via mach5 >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> Calvin, Ioi, Jiangli >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Fri Oct 5 21:31:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 Oct 2018 14:31:31 -0700 Subject: RFR: JDK-8211724: Change mkdir -p to MakeDir macro where possible Message-ID: <629b4278-d6c2-3722-37b6-49607eefc007@oracle.com> As a followup to JDK-8211677, here is an attempt at fixing most other instances of $(MKDIR) -p to instead of the MakeDir or MakeTargetDir macros. Since fixing the previous bug, we have hit the race in other recipes as well so this is really needed. There are some situations where the macro would not apply, so those have been skipped. I'm also pretty sure that those are race free. See bug comment for details. In addition to this I evaluated the AC_PROG_MKDIR_P macro. It didn't quite work out for us however. The fallback method if it cannot find a suitable mkdir binary is to use the build-aux/install.sh script. Our problem is that we have not included this script in our source (just a fake empty file) and to include it now would require a lot of legal work. What I've done instead is to simply add gmkdir first in the list of programs to look for when searching for mkdir. On Solaris, this is the program the macro found (and internally we have that installed on Solaris), so this will at least fix the immediate problem we are currently facing. Bug: https://bugs.openjdk.java.net/browse/JDK-8211724 Webrev: http://cr.openjdk.java.net/~erikj/8211724/webrev.01/index.html /Erik From aleksei.voitylov at bell-sw.com Sat Oct 6 15:07:52 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Sat, 6 Oct 2018 18:07:52 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> Kim, from an ARM port perspective, the stable GCC version is 4.9. The port compiles with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I agree on the overall direction and we'll commit resources to testing it further, but from an ARM port perspective it may happen JDK 12 is a little too optimistic. GCC x86 is a lot more stable than for ARM32 and AARCH64. -Aleksei On 05/10/2018 00:09, Kim Barrett wrote: >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov wrote: >> >> Kim, >> >> Thank you for posting this. It's an important step to make. I wanted to clarify a couple of points: >> >> 1. Since this is infrastructure JEP, is the version of JDK which will undergo such changes going to be some future version or does it apply to past versions as well? I'm concerned with how we can simplify security backports to 8u which (I currently assume) is not subject to this change. > Future version (perhaps as soon as JDK 12). I don't think there is > any desire to backport this change. And yes, introducing the use of > new language features will make backports even more interesting than > they already are. That seems unavoidable if we're going to pursue > this direction. > >> 2. Which versions of GCC do you tentatively consider at this point? Non-x86 ports may have a problem upgrading to a specific version of GCC which the shared code will use and may need additional lead time to adjust. > I think our (ad hoc) testing has been limited to gcc 7.x. But looking > at the gcc language conformance tables and release notes, gcc 5.x > might be good enough, and gcc 6.x seems fairly likely sufficient. Of > course, older versions are more likely to have bugs in some of these > new features. Updating the minimum supported versions for gcc and > clang are noted as TBD in the JEP. > From magnus.ihse.bursie at oracle.com Sun Oct 7 09:52:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 7 Oct 2018 11:52:21 +0200 Subject: RFR: JDK-8211724: Change mkdir -p to MakeDir macro where possible In-Reply-To: <629b4278-d6c2-3722-37b6-49607eefc007@oracle.com> References: <629b4278-d6c2-3722-37b6-49607eefc007@oracle.com> Message-ID: <056571F1-AA3C-4A8F-A658-24FD3FDA01FB@oracle.com> One problem with this is that you're replacing this pattern rm -r $DIR mkdir -p $DIR with this: mkdir -p $DIR rm -r $DIR/* However, they are not equivalent. :( The latter will not remove any hidden dot-files. I recommend that you create a new macro like MakeAndCleanDir, which does this, and that it either keeps the old behavior of always removing the dir recursively and then re-create it, or that your create it conditionally like now but fix so rm also handles dot-files. Or that it checks if any files are present by $(wildcard) and only calls rm if needed. This is likely most efficient, but care must be taken to be sure to check for dot files, but not for the . or .. dirs. /Magnus > 5 okt. 2018 kl. 23:31 skrev Erik Joelsson : > > As a followup to JDK-8211677, here is an attempt at fixing most other instances of $(MKDIR) -p to instead of the MakeDir or MakeTargetDir macros. Since fixing the previous bug, we have hit the race in other recipes as well so this is really needed. > > There are some situations where the macro would not apply, so those have been skipped. I'm also pretty sure that those are race free. See bug comment for details. > > In addition to this I evaluated the AC_PROG_MKDIR_P macro. It didn't quite work out for us however. The fallback method if it cannot find a suitable mkdir binary is to use the build-aux/install.sh script. Our problem is that we have not included this script in our source (just a fake empty file) and to include it now would require a lot of legal work. What I've done instead is to simply add gmkdir first in the list of programs to look for when searching for mkdir. On Solaris, this is the program the macro found (and internally we have that installed on Solaris), so this will at least fix the immediate problem we are currently facing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211724 > > Webrev: http://cr.openjdk.java.net/~erikj/8211724/webrev.01/index.html > > /Erik > From shade at redhat.com Mon Oct 8 07:54:27 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Oct 2018 09:54:27 +0200 Subject: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives) Message-ID: <234a1fc8-a33c-5a34-fbcb-99ca65b2d288@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8211838 Seems like Minimal VM has CDS disabled as VM feature, which means it would fail during CDS archive generation at the end of the build. It looks like the situation Zero is in, so the quick fix is: diff -r f697ba5b18d2 make/autoconf/jdk-options.m4 --- a/make/autoconf/jdk-options.m4 Mon Oct 08 13:25:39 2018 +0800 +++ b/make/autoconf/jdk-options.m4 Mon Oct 08 09:34:16 2018 +0200 @@ -609,10 +609,11 @@ ################################################################################ # # Disable the default CDS archive generation # cross compilation - disabled # zero - off by default (not a tested configuration) +# minimal - off by default (not a tested configuration) # AC_DEFUN([JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE], [ AC_ARG_ENABLE([cds-archive], [AS_HELP_STRING([--disable-cds-archive], [Set to disable generation of a default CDS archive in the product image @<:@enabled@:>@])]) @@ -625,10 +626,13 @@ AC_MSG_RESULT([yes, forced]) BUILD_CDS_ARCHIVE="true" elif HOTSPOT_CHECK_JVM_VARIANT(zero); then AC_MSG_RESULT([no]) BUILD_CDS_ARCHIVE="false" + elif HOTSPOT_CHECK_JVM_VARIANT(minimal); then + AC_MSG_RESULT([no]) + BUILD_CDS_ARCHIVE="false" elif test "x$enable_cds_archive" = "x"; then AC_MSG_RESULT([yes]) BUILD_CDS_ARCHIVE="true" elif test "x$enable_cds_archive" = "xno"; then AC_MSG_RESULT([no, forced]) I think a good follow-up would be actually checking for "cds" as feature, and disabling cds-archive based on that. I think --with-jvm-features=-cds fails the same way. Testing: x86_64 Minimal/Server builds Thanks, -Aleksey From volker.simonis at gmail.com Mon Oct 8 08:19:18 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 10:19:18 +0200 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS Message-ID: Hi, can I please have a review for the following trivial build fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ https://bugs.openjdk.java.net/browse/JDK-8211837 It makes no sense to try to create a default CDS archive on VMs which don't support CDS at all. We already have '--enable_cds' which defaults to 'true' on all platforms except AIX. The check for '--enable_cds_archive' should use the result of '--enable_cds' (which is saved in "ENABLE_CDS") and only enable default archive creation if CDS is enabled. Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). Thank you and best regards, Volker From volker.simonis at gmail.com Mon Oct 8 08:34:51 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 10:34:51 +0200 Subject: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives) In-Reply-To: <234a1fc8-a33c-5a34-fbcb-99ca65b2d288@redhat.com> References: <234a1fc8-a33c-5a34-fbcb-99ca65b2d288@redhat.com> Message-ID: Hi Aleksey, I've just posted a fix for this issue as well (the AIX build is broken as well). http://mail.openjdk.java.net/pipermail/build-dev/2018-October/023559.html Instead of checking the JVM_VARIANT, I check for ENABLE_CDS. But as far as I see, that still doesn't help for the 'minmal' variant. I think the right fix would be to set ENABLE_CDS to false for the minimal build. I could add that to my fix if you're all right with it? Regards, Volker On Mon, Oct 8, 2018 at 9:54 AM Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211838 > > Seems like Minimal VM has CDS disabled as VM feature, which means it would fail during CDS archive > generation at the end of the build. It looks like the situation Zero is in, so the quick fix is: > > diff -r f697ba5b18d2 make/autoconf/jdk-options.m4 > --- a/make/autoconf/jdk-options.m4 Mon Oct 08 13:25:39 2018 +0800 > +++ b/make/autoconf/jdk-options.m4 Mon Oct 08 09:34:16 2018 +0200 > @@ -609,10 +609,11 @@ > ################################################################################ > # > # Disable the default CDS archive generation > # cross compilation - disabled > # zero - off by default (not a tested configuration) > +# minimal - off by default (not a tested configuration) > # > AC_DEFUN([JDKOPT_ENABLE_DISABLE_CDS_ARCHIVE], > [ > AC_ARG_ENABLE([cds-archive], [AS_HELP_STRING([--disable-cds-archive], > [Set to disable generation of a default CDS archive in the product image @<:@enabled@:>@])]) > @@ -625,10 +626,13 @@ > AC_MSG_RESULT([yes, forced]) > BUILD_CDS_ARCHIVE="true" > elif HOTSPOT_CHECK_JVM_VARIANT(zero); then > AC_MSG_RESULT([no]) > BUILD_CDS_ARCHIVE="false" > + elif HOTSPOT_CHECK_JVM_VARIANT(minimal); then > + AC_MSG_RESULT([no]) > + BUILD_CDS_ARCHIVE="false" > elif test "x$enable_cds_archive" = "x"; then > AC_MSG_RESULT([yes]) > BUILD_CDS_ARCHIVE="true" > elif test "x$enable_cds_archive" = "xno"; then > AC_MSG_RESULT([no, forced]) > > I think a good follow-up would be actually checking for "cds" as feature, and disabling cds-archive > based on that. I think --with-jvm-features=-cds fails the same way. > > Testing: x86_64 Minimal/Server builds > > Thanks, > -Aleksey > From shade at redhat.com Mon Oct 8 08:38:21 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Oct 2018 10:38:21 +0200 Subject: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives) In-Reply-To: References: <234a1fc8-a33c-5a34-fbcb-99ca65b2d288@redhat.com> Message-ID: <534070dd-4747-1a7c-964d-190914af9924@redhat.com> On 10/08/2018 10:34 AM, Volker Simonis wrote: > Instead of checking the JVM_VARIANT, I check for ENABLE_CDS. But as > far as I see, that still doesn't help for the 'minmal' variant. I > think the right fix would be to set ENABLE_CDS to false for the > minimal build. I could add that to my fix if you're all right with it? Sure, I am okay with that, as long as it unbreaks the build. The other thing is --with-jvm-features=-cds. I can test Minimal/Zero once you post the patch. -Aleksey From goetz.lindenmaier at sap.com Mon Oct 8 09:07:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Oct 2018 09:07:19 +0000 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: Message-ID: Hi Volker, Aleksey, Voker, your change looks good. I also think CDS should be turned off on minimal VM, and also the case for zero a few lines below should be removed in a similar manner. But I'll leave to you whether you want to handle that in a separate fix. Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Volker Simonis > Sent: Montag, 8. Oktober 2018 10:19 > To: build-dev ; hotspot-runtime- > dev at openjdk.java.net runtime > Subject: RFR(XS): 8211837: Creation of the default CDS Archive should > depend on ENABLE_CDS > > Hi, > > can I please have a review for the following trivial build fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ > https://bugs.openjdk.java.net/browse/JDK-8211837 > > It makes no sense to try to create a default CDS archive on VMs which > don't support CDS at all. We already have '--enable_cds' which > defaults to 'true' on all platforms except AIX. > > The check for '--enable_cds_archive' should use the result of > '--enable_cds' (which is saved in "ENABLE_CDS") and only enable > default archive creation if CDS is enabled. > > Failure to do so currently breaks the AIX build (after JDK-)8202951 was > pushed). > > Thank you and best regards, > Volker From martin.doerr at sap.com Mon Oct 8 09:10:40 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 8 Oct 2018 09:10:40 +0000 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: Message-ID: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Hi Volker, looks good. Thanks for fixing. Of course, it would be great if this could be used to fix minimal/zero build, too. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of Volker Simonis Sent: Montag, 8. Oktober 2018 10:19 To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS Hi, can I please have a review for the following trivial build fix: http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ https://bugs.openjdk.java.net/browse/JDK-8211837 It makes no sense to try to create a default CDS archive on VMs which don't support CDS at all. We already have '--enable_cds' which defaults to 'true' on all platforms except AIX. The check for '--enable_cds_archive' should use the result of '--enable_cds' (which is saved in "ENABLE_CDS") and only enable default archive creation if CDS is enabled. Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). Thank you and best regards, Volker From volker.simonis at gmail.com Mon Oct 8 10:10:50 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 12:10:50 +0200 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: Hi Martin, Goetz, thanks for reviewing my patch! As Aleksey posted a similar patch for fixing the Zero build I've extended my patch to handle zero/minimal/core as well. In fact the patch now disables CDS on AIX, minimal, core and zero unless the user explicitly requests it with the help of `--with-jvm-features=cds`. The configuration variant with `--with-jvm-features=-cds` should now also be handled correctly (I hope caught all possible combinations :) If CDS is disabled, the creation of the default class list and default archive will now be disabled as well. @Aleksey Shipilev : can you please check if this new version of my patch also works for you? http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ Thank you and best regards, Volker On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin wrote: > > Hi Volker, > > looks good. Thanks for fixing. > Of course, it would be great if this could be used to fix minimal/zero build, too. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev On Behalf Of Volker Simonis > Sent: Montag, 8. Oktober 2018 10:19 > To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime > Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS > > Hi, > > can I please have a review for the following trivial build fix: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ > https://bugs.openjdk.java.net/browse/JDK-8211837 > > It makes no sense to try to create a default CDS archive on VMs which > don't support CDS at all. We already have '--enable_cds' which > defaults to 'true' on all platforms except AIX. > > The check for '--enable_cds_archive' should use the result of > '--enable_cds' (which is saved in "ENABLE_CDS") and only enable > default archive creation if CDS is enabled. > > Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). > > Thank you and best regards, > Volker From volker.simonis at gmail.com Mon Oct 8 10:12:12 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 12:12:12 +0200 Subject: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives) In-Reply-To: <534070dd-4747-1a7c-964d-190914af9924@redhat.com> References: <234a1fc8-a33c-5a34-fbcb-99ca65b2d288@redhat.com> <534070dd-4747-1a7c-964d-190914af9924@redhat.com> Message-ID: On Mon, Oct 8, 2018 at 10:38 AM Aleksey Shipilev wrote: > > On 10/08/2018 10:34 AM, Volker Simonis wrote: > > Instead of checking the JVM_VARIANT, I check for ENABLE_CDS. But as > > far as I see, that still doesn't help for the 'minmal' variant. I > > think the right fix would be to set ENABLE_CDS to false for the > > minimal build. I could add that to my fix if you're all right with it? > > Sure, I am okay with that, as long as it unbreaks the build. The other thing is > --with-jvm-features=-cds. I can test Minimal/Zero once you post the patch. > Cool, I've just posted a new webrev on the other thread. Can you please verify if it fixes your problems as well and reply on that thread? http://mail.openjdk.java.net/pipermail/build-dev/2018-October/023564.html Thanks, Volker > -Aleksey > From shade at redhat.com Mon Oct 8 10:35:16 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Oct 2018 12:35:16 +0200 Subject: RFR 8211838 (XS): Minimal VM build is broken after JDK-8202951 (Implementation of JEP 341: Default CDS Archives) In-Reply-To: References: <234a1fc8-a33c-5a34-fbcb-99ca65b2d288@redhat.com> <534070dd-4747-1a7c-964d-190914af9924@redhat.com> Message-ID: On 10/08/2018 12:12 PM, Volker Simonis wrote: > On Mon, Oct 8, 2018 at 10:38 AM Aleksey Shipilev wrote: >> >> On 10/08/2018 10:34 AM, Volker Simonis wrote: >>> Instead of checking the JVM_VARIANT, I check for ENABLE_CDS. But as >>> far as I see, that still doesn't help for the 'minmal' variant. I >>> think the right fix would be to set ENABLE_CDS to false for the >>> minimal build. I could add that to my fix if you're all right with it? >> >> Sure, I am okay with that, as long as it unbreaks the build. The other thing is >> --with-jvm-features=-cds. I can test Minimal/Zero once you post the patch. >> > > Cool, I've just posted a new webrev on the other thread. Can you > please verify if it fixes your problems as well and reply on that > thread? > > http://mail.openjdk.java.net/pipermail/build-dev/2018-October/023564.html Right. I withdraw this RFR. -Aleksey From goetz.lindenmaier at sap.com Mon Oct 8 10:36:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 8 Oct 2018 10:36:19 +0000 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: Still looks good (now touches much more scenarios, but we should get this straight.) Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Volker Simonis > Sent: Montag, 8. Oktober 2018 12:11 > To: Doerr, Martin > Cc: build-dev ; hotspot-runtime- > dev at openjdk.java.net runtime > Subject: Re: RFR(XS): 8211837: Creation of the default CDS Archive should > depend on ENABLE_CDS > > Hi Martin, Goetz, > > thanks for reviewing my patch! As Aleksey posted a similar patch for > fixing the Zero build I've extended my patch to handle > zero/minimal/core as well. > > In fact the patch now disables CDS on AIX, minimal, core and zero > unless the user explicitly requests it with the help of > `--with-jvm-features=cds`. The configuration variant with > `--with-jvm-features=-cds` should now also be handled correctly (I > hope caught all possible combinations :) > > If CDS is disabled, the creation of the default class list and default > archive will now be disabled as well. > > @Aleksey Shipilev : can you please check if this new version of my > patch also works for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > Thank you and best regards, > Volker > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin > wrote: > > > > Hi Volker, > > > > looks good. Thanks for fixing. > > Of course, it would be great if this could be used to fix minimal/zero build, > too. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Volker Simonis > > Sent: Montag, 8. Oktober 2018 10:19 > > To: build-dev ; hotspot-runtime- > dev at openjdk.java.net runtime > > Subject: RFR(XS): 8211837: Creation of the default CDS Archive should > depend on ENABLE_CDS > > > > Hi, > > > > can I please have a review for the following trivial build fix: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ > > https://bugs.openjdk.java.net/browse/JDK-8211837 > > > > It makes no sense to try to create a default CDS archive on VMs which > > don't support CDS at all. We already have '--enable_cds' which > > defaults to 'true' on all platforms except AIX. > > > > The check for '--enable_cds_archive' should use the result of > > '--enable_cds' (which is saved in "ENABLE_CDS") and only enable > > default archive creation if CDS is enabled. > > > > Failure to do so currently breaks the AIX build (after JDK-)8202951 was > pushed). > > > > Thank you and best regards, > > Volker From martin.doerr at sap.com Mon Oct 8 10:37:12 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 8 Oct 2018 10:37:12 +0000 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: <715dbaa4b1014c47a883994a1b9d3eb9@sap.com> +1 Thanks for improving the code. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 8. Oktober 2018 12:36 To: Volker Simonis ; Doerr, Martin Cc: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime Subject: RE: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS Still looks good (now touches much more scenarios, but we should get this straight.) Best regards, Goetz. > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Volker Simonis > Sent: Montag, 8. Oktober 2018 12:11 > To: Doerr, Martin > Cc: build-dev ; hotspot-runtime- > dev at openjdk.java.net runtime > Subject: Re: RFR(XS): 8211837: Creation of the default CDS Archive should > depend on ENABLE_CDS > > Hi Martin, Goetz, > > thanks for reviewing my patch! As Aleksey posted a similar patch for > fixing the Zero build I've extended my patch to handle > zero/minimal/core as well. > > In fact the patch now disables CDS on AIX, minimal, core and zero > unless the user explicitly requests it with the help of > `--with-jvm-features=cds`. The configuration variant with > `--with-jvm-features=-cds` should now also be handled correctly (I > hope caught all possible combinations :) > > If CDS is disabled, the creation of the default class list and default > archive will now be disabled as well. > > @Aleksey Shipilev : can you please check if this new version of my > patch also works for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > Thank you and best regards, > Volker > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin > wrote: > > > > Hi Volker, > > > > looks good. Thanks for fixing. > > Of course, it would be great if this could be used to fix minimal/zero build, > too. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of Volker Simonis > > Sent: Montag, 8. Oktober 2018 10:19 > > To: build-dev ; hotspot-runtime- > dev at openjdk.java.net runtime > > Subject: RFR(XS): 8211837: Creation of the default CDS Archive should > depend on ENABLE_CDS > > > > Hi, > > > > can I please have a review for the following trivial build fix: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ > > https://bugs.openjdk.java.net/browse/JDK-8211837 > > > > It makes no sense to try to create a default CDS archive on VMs which > > don't support CDS at all. We already have '--enable_cds' which > > defaults to 'true' on all platforms except AIX. > > > > The check for '--enable_cds_archive' should use the result of > > '--enable_cds' (which is saved in "ENABLE_CDS") and only enable > > default archive creation if CDS is enabled. > > > > Failure to do so currently breaks the AIX build (after JDK-)8202951 was > pushed). > > > > Thank you and best regards, > > Volker From thomas.stuefe at gmail.com Mon Oct 8 10:48:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 8 Oct 2018 12:48:57 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: Hi Kim, is this JEP only about C++14 features or shall we discuss older features too? The reason I am asking is that I would like us to officially endorse namespaces. Not inline namespaces, just plain old namespaces. HotSpot makes very limited use of namespaces. Not really true, we already use them. E.g. in metaspace coding, I used them to keep the global name space clean and to keep internals internal. This was met with positive reviews, and it works on all toolchains, so compiler support should not be a problem. Using namespaces, we could get slowly replace the "AllStatic" classes, which are namespaces in all but name. In contrast to classes, namespaces can be spread over multiple files and compilation units, and allow for cleaner separation of internal and external coding. It also would allow us to get rid the middle-of-header-platform-inclusions: For example, today we have: [os.hpp] class os: AllStatic { .... (platform independent, outward facing os:: functions) #include "os_linux.hpp" >> (Inner class "Linux" with platform specific os functions) ... } Not only is the inclusion in the middle of a class terrifying, it also means the shared, outward facing os:: namespace contains class Linux and lots of platform specific internals. With namespaces one could: [os.hpp] namespace os { .... (platform independent, outward facing os:: functions) .... } [os_linux.hpp] namespace os { namespace Linux { (linux specific os functions) } } I think this is way cleaner, and keeps platform specifics from including files which only care for the shared os interface. -- Note that I would prefer forbidding the "using" directive for callers of namespace functions, but rather force them to spell out the namespace: So, instead of this: using os; jlong m = available_memory(); I would prefer this, which is our current practice with AllStatic childs: jlong m = os::available_memory(); The latter form would keep the code grepable. Best Regards, Thomas On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett wrote: > > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > From shade at redhat.com Mon Oct 8 10:59:29 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 8 Oct 2018 12:59:29 +0200 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: <07301d22-ea7c-e783-a735-b33c8c0a52ac@redhat.com> On 10/08/2018 12:10 PM, Volker Simonis wrote: > @Aleksey Shipilev : can you please check if this new version of my > patch also works for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ Checked Linux x86_64 {server, minimal, zero}, all build fine with this patch! Closed my JDK-8211838 as duplicate of this bug. This comment is now obsolete: 613 # zero - off by default (not a tested configuration) Thanks, -Aleksey From volker.simonis at gmail.com Mon Oct 8 12:34:51 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 14:34:51 +0200 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: <07301d22-ea7c-e783-a735-b33c8c0a52ac@redhat.com> References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> <07301d22-ea7c-e783-a735-b33c8c0a52ac@redhat.com> Message-ID: On Mon, Oct 8, 2018 at 12:59 PM Aleksey Shipilev wrote: > > On 10/08/2018 12:10 PM, Volker Simonis wrote: > > @Aleksey Shipilev : can you please check if this new version of my > > patch also works for you? > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > Checked Linux x86_64 {server, minimal, zero}, all build fine with this patch! > Thanks for checking ! > Closed my JDK-8211838 as duplicate of this bug. > > This comment is now obsolete: > > 613 # zero - off by default (not a tested configuration) > I've removed that line from my local change. I'd appreciate if I could get one more review from a build-group member before pushing. Regards, Volker > Thanks, > -Aleksey > > From volker.simonis at gmail.com Mon Oct 8 12:43:53 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 14:43:53 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: On Mon, Oct 8, 2018 at 12:49 PM Thomas St?fe wrote: > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. > > HotSpot makes very limited use of namespaces. > > Not really true, we already use them. E.g. in metaspace coding, I used > them to keep the global name space clean and to keep internals > internal. This was met with positive reviews, and it works on all > toolchains, so compiler support should not be a problem. Using > namespaces, we could get slowly replace the "AllStatic" classes, which > are namespaces in all but name. In contrast to classes, namespaces can > be spread over multiple files and compilation units, and allow for > cleaner separation of internal and external coding. > > It also would allow us to get rid the middle-of-header-platform-inclusions: > That's overdue since a long time! It would allow us to finally get correct code navigation in IDEs. > For example, today we have: > > [os.hpp] > class os: AllStatic { > .... > (platform independent, outward facing os:: functions) > #include "os_linux.hpp" > >> (Inner class "Linux" with platform specific os functions) > ... > } > > Not only is the inclusion in the middle of a class terrifying, it also > means the shared, outward facing os:: namespace contains class Linux > and lots of platform specific internals. > > With namespaces one could: > > [os.hpp] > namespace os { > .... > (platform independent, outward facing os:: functions) > .... > } > > [os_linux.hpp] > namespace os { > namespace Linux { > (linux specific os functions) > } > } > > I think this is way cleaner, and keeps platform specifics from > including files which only care for the shared os interface. > > -- > > Note that I would prefer forbidding the "using" directive for callers > of namespace functions, but rather force them to spell out the > namespace: > As far as I saw, "using" directives are already on the "Exclude" list in Kim's proposal. > So, instead of this: > > using os; > jlong m = available_memory(); > > I would prefer this, which is our current practice with AllStatic childs: > > jlong m = os::available_memory(); > > The latter form would keep the code grepable. > > Best Regards, Thomas > On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett wrote: > > > > I've submitted a JEP for > > > > (1) enabling the use of C++14 Language Features when building the JDK, > > > > (2) define a process for deciding and documenting which new features > > can be used or are forbidden in HotSpot code, > > > > (3) provide an initial list of permitted and forbidden new features. > > > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > From ioi.lam at oracle.com Mon Oct 8 15:32:13 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 8 Oct 2018 08:32:13 -0700 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: <339ba32c-b1ac-c63e-b147-0d5a6fc2f6ce@oracle.com> Looks good. Thanks for fixing this! - Ioi On 10/8/18 3:10 AM, Volker Simonis wrote: > Hi Martin, Goetz, > > thanks for reviewing my patch! As Aleksey posted a similar patch for > fixing the Zero build I've extended my patch to handle > zero/minimal/core as well. > > In fact the patch now disables CDS on AIX, minimal, core and zero > unless the user explicitly requests it with the help of > `--with-jvm-features=cds`. The configuration variant with > `--with-jvm-features=-cds` should now also be handled correctly (I > hope caught all possible combinations :) > > If CDS is disabled, the creation of the default class list and default > archive will now be disabled as well. > > @Aleksey Shipilev : can you please check if this new version of my > patch also works for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > Thank you and best regards, > Volker > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin wrote: >> Hi Volker, >> >> looks good. Thanks for fixing. >> Of course, it would be great if this could be used to fix minimal/zero build, too. >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-runtime-dev On Behalf Of Volker Simonis >> Sent: Montag, 8. Oktober 2018 10:19 >> To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime >> Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS >> >> Hi, >> >> can I please have a review for the following trivial build fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ >> https://bugs.openjdk.java.net/browse/JDK-8211837 >> >> It makes no sense to try to create a default CDS archive on VMs which >> don't support CDS at all. We already have '--enable_cds' which >> defaults to 'true' on all platforms except AIX. >> >> The check for '--enable_cds_archive' should use the result of >> '--enable_cds' (which is saved in "ENABLE_CDS") and only enable >> default archive creation if CDS is enabled. >> >> Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). >> >> Thank you and best regards, >> Volker From erik.joelsson at oracle.com Mon Oct 8 16:30:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 8 Oct 2018 09:30:12 -0700 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: Hello, Looks good. My only minor nit is the rather long line in jdk-options.m4 that I would appreciate if it was broken up (no need for respin if you do). /Erik On 2018-10-08 03:10, Volker Simonis wrote: > Hi Martin, Goetz, > > thanks for reviewing my patch! As Aleksey posted a similar patch for > fixing the Zero build I've extended my patch to handle > zero/minimal/core as well. > > In fact the patch now disables CDS on AIX, minimal, core and zero > unless the user explicitly requests it with the help of > `--with-jvm-features=cds`. The configuration variant with > `--with-jvm-features=-cds` should now also be handled correctly (I > hope caught all possible combinations :) > > If CDS is disabled, the creation of the default class list and default > archive will now be disabled as well. > > @Aleksey Shipilev : can you please check if this new version of my > patch also works for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > Thank you and best regards, > Volker > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin wrote: >> Hi Volker, >> >> looks good. Thanks for fixing. >> Of course, it would be great if this could be used to fix minimal/zero build, too. >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-runtime-dev On Behalf Of Volker Simonis >> Sent: Montag, 8. Oktober 2018 10:19 >> To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime >> Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS >> >> Hi, >> >> can I please have a review for the following trivial build fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ >> https://bugs.openjdk.java.net/browse/JDK-8211837 >> >> It makes no sense to try to create a default CDS archive on VMs which >> don't support CDS at all. We already have '--enable_cds' which >> defaults to 'true' on all platforms except AIX. >> >> The check for '--enable_cds_archive' should use the result of >> '--enable_cds' (which is saved in "ENABLE_CDS") and only enable >> default archive creation if CDS is enabled. >> >> Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). >> >> Thank you and best regards, >> Volker From jiangli.zhou at oracle.com Mon Oct 8 18:06:56 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 8 Oct 2018 11:06:56 -0700 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: <8cc259fb-291e-32d6-9c7c-4dba89df3b7f@oracle.com> Hi Volker, Looks good. Thanks for fixing! It would be good to update the following comment in jdk-options.m4 to add AIX, minimal and core. ?609 ################################################################################ ?610 # ?611 # Disable the default CDS archive generation ?612 #?? cross compilation - disabled ?613 #?? zero????????????? - off by default (not a tested configuration) ?614 # Thanks! Jiangli On 10/8/18 3:10 AM, Volker Simonis wrote: > Hi Martin, Goetz, > > thanks for reviewing my patch! As Aleksey posted a similar patch for > fixing the Zero build I've extended my patch to handle > zero/minimal/core as well. > > In fact the patch now disables CDS on AIX, minimal, core and zero > unless the user explicitly requests it with the help of > `--with-jvm-features=cds`. The configuration variant with > `--with-jvm-features=-cds` should now also be handled correctly (I > hope caught all possible combinations :) > > If CDS is disabled, the creation of the default class list and default > archive will now be disabled as well. > > @Aleksey Shipilev : can you please check if this new version of my > patch also works for you? > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > Thank you and best regards, > Volker > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin wrote: >> Hi Volker, >> >> looks good. Thanks for fixing. >> Of course, it would be great if this could be used to fix minimal/zero build, too. >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-runtime-dev On Behalf Of Volker Simonis >> Sent: Montag, 8. Oktober 2018 10:19 >> To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime >> Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS >> >> Hi, >> >> can I please have a review for the following trivial build fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ >> https://bugs.openjdk.java.net/browse/JDK-8211837 >> >> It makes no sense to try to create a default CDS archive on VMs which >> don't support CDS at all. We already have '--enable_cds' which >> defaults to 'true' on all platforms except AIX. >> >> The check for '--enable_cds_archive' should use the result of >> '--enable_cds' (which is saved in "ENABLE_CDS") and only enable >> default archive creation if CDS is enabled. >> >> Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). >> >> Thank you and best regards, >> Volker From kim.barrett at oracle.com Mon Oct 8 18:32:02 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Oct 2018 14:32:02 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <2C15D9F7-6403-4FCA-806B-263FEF6F0DBA@oracle.com> > On Oct 8, 2018, at 6:48 AM, Thomas St?fe wrote: > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. I would like to keep this JEP focused on C++11/14 usage. However, it presently describes a process for recording and updating HotSpot usage. I think that process is pretty close to the de facto process, which is rarely used successfully because it's not written down anywhere. We could extract that part of the JEP out, formalize, discuss, agree, and record it. Then you could propose a change and there would be a process for dealing with the proposal, rather than having it slide into oblivion because we don't know how to proceed. And the JEP could be made a bit smaller because it could just refer to that process. From kim.barrett at oracle.com Mon Oct 8 19:34:04 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Oct 2018 15:34:04 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> Message-ID: <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> > On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov wrote: > > Kim, > > from an ARM port perspective, the stable GCC version is 4.9. The port compiles with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I agree on the overall direction and we'll commit resources to testing it further, but from an ARM port perspective it may happen JDK 12 is a little too optimistic. > > GCC x86 is a lot more stable than for ARM32 and AARCH64. It seems to me that JDK 11 being an LTS might provide an answer to this. JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat "experimental" in that it might require a more recent compiler version that hasn't received as much testing as was done for JDK 11. Similarly, the AIX/ppc platform might not be supported after JDK 11 until an improved version of the relevant compiler becomes available. I don't know if such an approach is acceptable to the community, nor do I know how such a decision might be made. But I think it would be unfortunate if such issues blocked progress in this area. From thomas.stuefe at gmail.com Mon Oct 8 19:42:47 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 8 Oct 2018 21:42:47 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <2C15D9F7-6403-4FCA-806B-263FEF6F0DBA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2C15D9F7-6403-4FCA-806B-263FEF6F0DBA@oracle.com> Message-ID: Hi Kim, On Mon, Oct 8, 2018 at 8:32 PM Kim Barrett wrote: > > > On Oct 8, 2018, at 6:48 AM, Thomas St?fe wrote: > > > > Hi Kim, > > > > is this JEP only about C++14 features or shall we discuss older > > features too? The reason I am asking is that I would like us to > > officially endorse namespaces. Not inline namespaces, just plain old > > namespaces. > > I would like to keep this JEP focused on C++11/14 usage. > > However, it presently describes a process for recording and updating > HotSpot usage. I think that process is pretty close to the de facto > process, which is rarely used successfully because it's not written > down anywhere. > > We could extract that part of the JEP out, formalize, discuss, agree, > and record it. Then you could propose a change and there would be a > process for dealing with the proposal, rather than having it slide > into oblivion because we don't know how to proceed. And the JEP could > be made a bit smaller because it could just refer to that process. > Yes, I would like that. It would be really good to have a process in place to preserve and actually live a consensus about what features we use. We have the Hotspot Style Guide, but we let it become woefully outdated in the face of new developments. I always smile when I read the "Be sparing with templates." remark - that ship has sailed long ago. --- A small remark to the text of your JEP: "As a rule of thumb, permitting features which simplify writing, and especially reading, code should be encouraged." I would like to add to that that simplifying build error analysis should also be a goal. That directly influences programmer productivity. We had some cases in the recent past where we spent a lot of time scratching our heads over walls of template related compiler errors. (not sure how to reach this goal though, since this seems to be a problem inherent in using C++ templates). Best Regards, Thomas From aleksei.voitylov at bell-sw.com Mon Oct 8 20:45:07 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 8 Oct 2018 23:45:07 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: Kim, Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. -Aleksei On 08/10/2018 22:34, Kim Barrett wrote: >> On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov wrote: >> >> Kim, >> >> from an ARM port perspective, the stable GCC version is 4.9. The port compiles with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I agree on the overall direction and we'll commit resources to testing it further, but from an ARM port perspective it may happen JDK 12 is a little too optimistic. >> >> GCC x86 is a lot more stable than for ARM32 and AARCH64. > It seems to me that JDK 11 being an LTS might provide an answer to this. > > JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat > "experimental" in that it might require a more recent compiler version > that hasn't received as much testing as was done for JDK 11. > > Similarly, the AIX/ppc platform might not be supported after JDK 11 > until an improved version of the relevant compiler becomes available. > > I don't know if such an approach is acceptable to the community, nor > do I know how such a decision might be made. But I think it would be > unfortunate if such issues blocked progress in this area. > From erik.joelsson at oracle.com Mon Oct 8 21:56:22 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 8 Oct 2018 14:56:22 -0700 Subject: RFR: JDK-8211724: Change mkdir -p to MakeDir macro where possible In-Reply-To: <056571F1-AA3C-4A8F-A658-24FD3FDA01FB@oracle.com> References: <629b4278-d6c2-3722-37b6-49607eefc007@oracle.com> <056571F1-AA3C-4A8F-A658-24FD3FDA01FB@oracle.com> Message-ID: <790f3f1c-203d-97ca-6a51-e0d0adee6e42@oracle.com> Hello, On 2018-10-07 02:52, Magnus Ihse Bursie wrote: > One problem with this is that you're replacing this pattern > rm -r $DIR > mkdir -p $DIR > with this: > mkdir -p $DIR > rm -r $DIR/* > > However, they are not equivalent. :( The latter will not remove any hidden dot-files. Not equivalent, but I very much doubt it matters in any of the changed locations. On the other hand, using the MakeDir macro in a recipe that is already deleting the target directory is pointless since the directory will never be reused anyway. That construct can also never work if there are concurrent mkdir lines for the same directory, so we know these are safe already. For these reasons, I reverted those changes. The rm -r followed by mkdir -p pattern is ok as it is. > I recommend that you create a new macro like MakeAndCleanDir, which does this, and that it either keeps the old behavior of always removing the dir recursively and then re-create it, or that your create it conditionally like now but fix so rm also handles dot-files. Or that it checks if any files are present by $(wildcard) and only calls rm if needed. This is likely most efficient, but care must be taken to be sure to check for dot files, but not for the . or .. dirs. This seems a bit excessive to me and unlikely to provide any real benefit. New webrev: http://cr.openjdk.java.net/~erikj/8211724/webrev.02/ /Erik > /Magnus > >> 5 okt. 2018 kl. 23:31 skrev Erik Joelsson : >> >> As a followup to JDK-8211677, here is an attempt at fixing most other instances of $(MKDIR) -p to instead of the MakeDir or MakeTargetDir macros. Since fixing the previous bug, we have hit the race in other recipes as well so this is really needed. >> >> There are some situations where the macro would not apply, so those have been skipped. I'm also pretty sure that those are race free. See bug comment for details. >> >> In addition to this I evaluated the AC_PROG_MKDIR_P macro. It didn't quite work out for us however. The fallback method if it cannot find a suitable mkdir binary is to use the build-aux/install.sh script. Our problem is that we have not included this script in our source (just a fake empty file) and to include it now would require a lot of legal work. What I've done instead is to simply add gmkdir first in the list of programs to look for when searching for mkdir. On Solaris, this is the program the macro found (and internally we have that installed on Solaris), so this will at least fix the immediate problem we are currently facing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211724 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8211724/webrev.01/index.html >> >> /Erik >> From volker.simonis at gmail.com Tue Oct 9 06:04:37 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Oct 2018 08:04:37 +0200 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> Message-ID: Hi Erik, thanks for reviewing and sorry but I've already pushed this yesterday evening before leaving because I wanted to fix our nightly builds. I agree that the long line in jdk-options.m4 is ugly and I put it on my TODO list. Taking into account the current cadence of AIX build fixes I think it wont take long until I'll have to revisit that file anyway :) Regards, Volker On Mon, Oct 8, 2018 at 6:30 PM Erik Joelsson wrote: > > Hello, > > Looks good. My only minor nit is the rather long line in jdk-options.m4 > that I would appreciate if it was broken up (no need for respin if you do). > > /Erik > > > On 2018-10-08 03:10, Volker Simonis wrote: > > Hi Martin, Goetz, > > > > thanks for reviewing my patch! As Aleksey posted a similar patch for > > fixing the Zero build I've extended my patch to handle > > zero/minimal/core as well. > > > > In fact the patch now disables CDS on AIX, minimal, core and zero > > unless the user explicitly requests it with the help of > > `--with-jvm-features=cds`. The configuration variant with > > `--with-jvm-features=-cds` should now also be handled correctly (I > > hope caught all possible combinations :) > > > > If CDS is disabled, the creation of the default class list and default > > archive will now be disabled as well. > > > > @Aleksey Shipilev : can you please check if this new version of my > > patch also works for you? > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > > > Thank you and best regards, > > Volker > > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin wrote: > >> Hi Volker, > >> > >> looks good. Thanks for fixing. > >> Of course, it would be great if this could be used to fix minimal/zero build, too. > >> > >> Best regards, > >> Martin > >> > >> > >> -----Original Message----- > >> From: hotspot-runtime-dev On Behalf Of Volker Simonis > >> Sent: Montag, 8. Oktober 2018 10:19 > >> To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime > >> Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS > >> > >> Hi, > >> > >> can I please have a review for the following trivial build fix: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ > >> https://bugs.openjdk.java.net/browse/JDK-8211837 > >> > >> It makes no sense to try to create a default CDS archive on VMs which > >> don't support CDS at all. We already have '--enable_cds' which > >> defaults to 'true' on all platforms except AIX. > >> > >> The check for '--enable_cds_archive' should use the result of > >> '--enable_cds' (which is saved in "ENABLE_CDS") and only enable > >> default archive creation if CDS is enabled. > >> > >> Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). > >> > >> Thank you and best regards, > >> Volker > From volker.simonis at gmail.com Tue Oct 9 06:17:53 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 9 Oct 2018 08:17:53 +0200 Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS In-Reply-To: <8cc259fb-291e-32d6-9c7c-4dba89df3b7f@oracle.com> References: <4e5a1b59f6ef44b09ad9d1a5cc50523c@sap.com> <8cc259fb-291e-32d6-9c7c-4dba89df3b7f@oracle.com> Message-ID: Hi Jiangli, thanks for looking at the change. Unfortunately I've already pushed it in order to fix our nightly builds. I think the comment should only mention the variants which are explicitly excluded by that function. All other cases are now handled by the "ENABLE_CDS" flag which seems more natural to me. But "ENABLE_CDS" is defined in hotspot.m4 where I put in some comments. Regards, Volker On Mon, Oct 8, 2018 at 8:06 PM Jiangli Zhou wrote: > > Hi Volker, > > Looks good. Thanks for fixing! It would be good to update the following > comment in jdk-options.m4 to add AIX, minimal and core. > > 609 > ################################################################################ > 610 # > 611 # Disable the default CDS archive generation > 612 # cross compilation - disabled > 613 # zero - off by default (not a tested configuration) > 614 # > > > Thanks! > > Jiangli > > > On 10/8/18 3:10 AM, Volker Simonis wrote: > > Hi Martin, Goetz, > > > > thanks for reviewing my patch! As Aleksey posted a similar patch for > > fixing the Zero build I've extended my patch to handle > > zero/minimal/core as well. > > > > In fact the patch now disables CDS on AIX, minimal, core and zero > > unless the user explicitly requests it with the help of > > `--with-jvm-features=cds`. The configuration variant with > > `--with-jvm-features=-cds` should now also be handled correctly (I > > hope caught all possible combinations :) > > > > If CDS is disabled, the creation of the default class list and default > > archive will now be disabled as well. > > > > @Aleksey Shipilev : can you please check if this new version of my > > patch also works for you? > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837.v1/ > > > > Thank you and best regards, > > Volker > > On Mon, Oct 8, 2018 at 11:10 AM Doerr, Martin wrote: > >> Hi Volker, > >> > >> looks good. Thanks for fixing. > >> Of course, it would be great if this could be used to fix minimal/zero build, too. > >> > >> Best regards, > >> Martin > >> > >> > >> -----Original Message----- > >> From: hotspot-runtime-dev On Behalf Of Volker Simonis > >> Sent: Montag, 8. Oktober 2018 10:19 > >> To: build-dev ; hotspot-runtime-dev at openjdk.java.net runtime > >> Subject: RFR(XS): 8211837: Creation of the default CDS Archive should depend on ENABLE_CDS > >> > >> Hi, > >> > >> can I please have a review for the following trivial build fix: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8211837/ > >> https://bugs.openjdk.java.net/browse/JDK-8211837 > >> > >> It makes no sense to try to create a default CDS archive on VMs which > >> don't support CDS at all. We already have '--enable_cds' which > >> defaults to 'true' on all platforms except AIX. > >> > >> The check for '--enable_cds_archive' should use the result of > >> '--enable_cds' (which is saved in "ENABLE_CDS") and only enable > >> default archive creation if CDS is enabled. > >> > >> Failure to do so currently breaks the AIX build (after JDK-)8202951 was pushed). > >> > >> Thank you and best regards, > >> Volker > From magnus.ihse.bursie at oracle.com Tue Oct 9 12:03:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Oct 2018 14:03:57 +0200 Subject: RFR: JDK-8211724: Change mkdir -p to MakeDir macro where possible In-Reply-To: <790f3f1c-203d-97ca-6a51-e0d0adee6e42@oracle.com> References: <629b4278-d6c2-3722-37b6-49607eefc007@oracle.com> <056571F1-AA3C-4A8F-A658-24FD3FDA01FB@oracle.com> <790f3f1c-203d-97ca-6a51-e0d0adee6e42@oracle.com> Message-ID: <0b50a11d-2b25-be36-d5c2-29be5aa77749@oracle.com> On 2018-10-08 23:56, Erik Joelsson wrote: > Hello, > > On 2018-10-07 02:52, Magnus Ihse Bursie wrote: >> One problem with this is that you're replacing this pattern >> rm -r $DIR >> mkdir -p $DIR >> with this: >> mkdir -p $DIR >> rm -r $DIR/* >> >> However, they are not equivalent. :( The latter will not remove any >> hidden dot-files. > Not equivalent, but I very much doubt it matters in any of the changed > locations. > > On the other hand, using the MakeDir macro in a recipe that is already > deleting the target directory is pointless since the directory will > never be reused anyway. That construct can also never work if there > are concurrent mkdir lines for the same directory, so we know these > are safe already. Or we have just been lucky to never run into such a disastrous race. ;-) > For these reasons, I reverted those changes. The rm -r followed by > mkdir -p pattern is ok as it is. Fair enough. >> I recommend that you create a new macro like MakeAndCleanDir, which >> does this, and that it either keeps the old behavior of always >> removing the dir recursively and then re-create it, or that your >> create it conditionally like now but fix so rm also handles >> dot-files. Or that it checks if any files are present by $(wildcard) >> and only calls rm if needed. This is likely most efficient, but care >> must be taken to be sure to check for dot files, but not for the . or >> .. dirs. > This seems a bit excessive to me and unlikely to provide any real > benefit. > > New webrev: http://cr.openjdk.java.net/~erikj/8211724/webrev.02/ Looks good to me. /Magnus > > /Erik >> /Magnus >> >>> 5 okt. 2018 kl. 23:31 skrev Erik Joelsson : >>> >>> As a followup to JDK-8211677, here is an attempt at fixing most >>> other instances of $(MKDIR) -p to instead of the MakeDir or >>> MakeTargetDir macros. Since fixing the previous bug, we have hit the >>> race in other recipes as well so this is really needed. >>> >>> There are some situations where the macro would not apply, so those >>> have been skipped. I'm also pretty sure that those are race free. >>> See bug comment for details. >>> >>> In addition to this I evaluated the AC_PROG_MKDIR_P macro. It didn't >>> quite work out for us however. The fallback method if it cannot find >>> a suitable mkdir binary is to use the build-aux/install.sh script. >>> Our problem is that we have not included this script in our source >>> (just a fake empty file) and to include it now would require a lot >>> of legal work. What I've done instead is to simply add gmkdir first >>> in the list of programs to look for when searching for mkdir. On >>> Solaris, this is the program the macro found (and internally we have >>> that installed on Solaris), so this will at least fix the immediate >>> problem we are currently facing. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211724 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8211724/webrev.01/index.html >>> >>> /Erik >>> > From claes.redestad at oracle.com Tue Oct 9 13:15:27 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Oct 2018 15:15:27 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks Message-ID: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Hi, please review the initial build support for JEP 230: Microbenchmark Suite[1]. Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 There are some added steps to be able to build the microbenchmark suite: export JMH_HOME=/path/to/jmh (mkdir -p $JMH_HOME; cd $JMH_HOME; bash make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) bash configure --with-jmh=$JMH_HOME make build-microbenchmark This produces the JMH benchmarks under build/$CONF_NAME/images/test/micro/microbenchmarks.jar There is also support woven into the make run-test target (thanks to Magnus), allowing for integrated build and test: make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi 2;RESULT_FORMAT=json" Remaining tasks before the JEP can be targetted is to write proper documentation and deciding which microbenchmarks to migrate from jmh-jdk-microbenchmarks[2]. Thanks! /Claes [1] http://openjdk.java.net/jeps/230 [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ From magnus.ihse.bursie at oracle.com Tue Oct 9 13:44:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 9 Oct 2018 15:44:40 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Message-ID: On 2018-10-09 15:15, Claes Redestad wrote: > Hi, > > please review the initial build support for JEP 230: Microbenchmark > Suite[1]. > > Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ The build changes look good. (But I can't really review them as I wrote most of them :-)) As you say, we also need to update documentation, especially doc/testing.md, with the new micro test suite for run-test. /Magnus > Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 > > There are some added steps to be able to build the microbenchmark suite: > > export JMH_HOME=/path/to/jmh > (mkdir -p $JMH_HOME; cd $JMH_HOME; bash > make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) > bash configure --with-jmh=$JMH_HOME > make build-microbenchmark > > This produces the JMH benchmarks under > build/$CONF_NAME/images/test/micro/microbenchmarks.jar > > There is also support woven into the make run-test target (thanks to > Magnus), allowing for integrated build and test: > > make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi > 2;RESULT_FORMAT=json" > > Remaining tasks before the JEP can be targetted is to write proper > documentation and deciding which microbenchmarks to migrate from > jmh-jdk-microbenchmarks[2]. > > Thanks! > > /Claes > > [1] http://openjdk.java.net/jeps/230 > [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ From erik.joelsson at oracle.com Tue Oct 9 16:50:27 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Oct 2018 09:50:27 -0700 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Message-ID: <25f85015-0835-7732-8711-04e4db71c432@oracle.com> Hello, In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir macros. If my patch goes in first, you will likely get a conflict there. It looks like BuildMicrobenchmarks.gmk is missing in the webrev. /Erik On 2018-10-09 06:44, Magnus Ihse Bursie wrote: > > > On 2018-10-09 15:15, Claes Redestad wrote: >> Hi, >> >> please review the initial build support for JEP 230: Microbenchmark >> Suite[1]. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ > The build changes look good. (But I can't really review them as I > wrote most of them :-)) > > As you say, we also need to update documentation, especially > doc/testing.md, with the new micro test suite for run-test. > > /Magnus >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 >> >> There are some added steps to be able to build the microbenchmark suite: >> >> export JMH_HOME=/path/to/jmh >> (mkdir -p $JMH_HOME; cd $JMH_HOME; bash >> make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) >> bash configure --with-jmh=$JMH_HOME >> make build-microbenchmark >> >> This produces the JMH benchmarks under >> build/$CONF_NAME/images/test/micro/microbenchmarks.jar >> >> There is also support woven into the make run-test target (thanks to >> Magnus), allowing for integrated build and test: >> >> make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi >> 2;RESULT_FORMAT=json" >> >> Remaining tasks before the JEP can be targetted is to write proper >> documentation and deciding which microbenchmarks to migrate from >> jmh-jdk-microbenchmarks[2]. >> >> Thanks! >> >> /Claes >> >> [1] http://openjdk.java.net/jeps/230 >> [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > From claes.redestad at oracle.com Tue Oct 9 17:02:32 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 9 Oct 2018 19:02:32 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <25f85015-0835-7732-8711-04e4db71c432@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <25f85015-0835-7732-8711-04e4db71c432@oracle.com> Message-ID: <407da004-74aa-a9c4-6de8-f4467a849980@oracle.com> Hi, On 2018-10-09 18:50, Erik Joelsson wrote: > Hello, > > In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir > macros. If my patch goes in first, you will likely get a conflict there. none of this will go in until the JEP is targetted, so feel free to move ahead and we'll follow suit. > > It looks like BuildMicrobenchmarks.gmk is missing in the webrev. Oops, all added files were missing. Updated in place with all files included. /Claes From erik.joelsson at oracle.com Tue Oct 9 21:30:58 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 9 Oct 2018 14:30:58 -0700 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <407da004-74aa-a9c4-6de8-f4467a849980@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <25f85015-0835-7732-8711-04e4db71c432@oracle.com> <407da004-74aa-a9c4-6de8-f4467a849980@oracle.com> Message-ID: The new files look good. /Erik On 2018-10-09 10:02, Claes Redestad wrote: > Hi, > > On 2018-10-09 18:50, Erik Joelsson wrote: >> Hello, >> >> In JarArchive.gmk, I would suggest using the MakeTargetDir/MakeDir >> macros. If my patch goes in first, you will likely get a conflict there. > > none of this will go in until the JEP is targetted, so feel free to > move ahead and we'll follow suit. > >> >> It looks like BuildMicrobenchmarks.gmk is missing in the webrev. > > Oops, all added files were missing. Updated in place with all files > included. > > /Claes From matthias.baesken at sap.com Wed Oct 10 13:14:34 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 10 Oct 2018 13:14:34 +0000 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz Message-ID: Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also on linux ppc64) I run into this build error : /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-Werror=format-truncation=] len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation->value)); ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes cc1plus: all warnings being treated as errors (build is a product - build) Setting ?disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . Fixing in the harfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . Do you think we could disable the specific warning for the library compilation ? Any other great suggestions ? ? Thanks, Matthias From robin.westberg at oracle.com Wed Oct 10 14:02:35 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Wed, 10 Oct 2018 16:02:35 +0200 Subject: RFR: 8212004: Optional compile_commands.json field not compatible with older libclang Message-ID: <76B27716-CDFA-4F72-8A02-7018B188261C@oracle.com> Hi all, Please review this small change to remove the ?output? field from the compile_commands.json file generated by ?make compile-commands?. As it turns out, this optional field is incompatible with tooling built on libclang versions older than 4.0. As this field provides no real benefit for us, it can simply be dropped from the output. Issue: https://bugs.openjdk.java.net/browse/JDK-8212004 Webrev: https://cr.openjdk.java.net/~rwestberg/8212004/webrev.00/ Testing: tier1, builds-tier5 Best regards, Robin From erik.joelsson at oracle.com Wed Oct 10 15:33:13 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Oct 2018 08:33:13 -0700 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz In-Reply-To: References: Message-ID: <70e447ee-d3d5-be47-4d62-c18853af13fc@oracle.com> In this case, disabling the warning seems like the right thing to do. /Erik On 2018-10-10 06:14, Baesken, Matthias wrote: > Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also on linux ppc64) I run into this build error : > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-Werror=format-truncation=] > len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation->value)); > ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes > cc1plus: all warnings being treated as errors > > (build is a product - build) > > Setting ?disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . > > Fixing in the harfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . > Do you think we could disable the specific warning for the library compilation ? > > Any other great suggestions ? ? > > > Thanks, Matthias From erik.joelsson at oracle.com Wed Oct 10 15:34:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Oct 2018 08:34:17 -0700 Subject: RFR: 8212004: Optional compile_commands.json field not compatible with older libclang In-Reply-To: <76B27716-CDFA-4F72-8A02-7018B188261C@oracle.com> References: <76B27716-CDFA-4F72-8A02-7018B188261C@oracle.com> Message-ID: <0e47ccb6-e289-ed92-a7a1-f311fe26b417@oracle.com> Looks good. /Erik On 2018-10-10 07:02, Robin Westberg wrote: > Hi all, > > Please review this small change to remove the ?output? field from the compile_commands.json file generated by ?make compile-commands?. As it turns out, this optional field is incompatible with tooling built on libclang versions older than 4.0. As this field provides no real benefit for us, it can simply be dropped from the output. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8212004 > Webrev: https://cr.openjdk.java.net/~rwestberg/8212004/webrev.00/ > Testing: tier1, builds-tier5 > > Best regards, > Robin From christian.tornqvist at oracle.com Wed Oct 10 15:47:50 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 10 Oct 2018 08:47:50 -0700 Subject: RFR: 8212008: Use of TREAT_EXIT_CODE_1_AS_0 hide problems with jtreg Java Message-ID: Hi, When running JDK and Hotspot jtreg tests through make, TREAT_EXIT_CODE_1_AS_0 is set to true. Any issue with the Java installation used to run jtreg won?t be reflected in the exit code. This has been seen a bunch of times in our internal CI system where we thought we ran tests but instead no tests were run at all because the jtreg Java installation had been deleted/corrupted. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212008/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212008 Thanks, Christian From erik.joelsson at oracle.com Wed Oct 10 16:01:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Oct 2018 09:01:09 -0700 Subject: RFR: 8212008: Use of TREAT_EXIT_CODE_1_AS_0 hide problems with jtreg Java In-Reply-To: References: Message-ID: <71f1fbf0-1126-8569-9c92-e78d24b3414b@oracle.com> Looks good. A side effect of this is that if no tests are found (also returns 1), make will fail. In our CI system, this will be interpreted as NOT_RUN "no tests found", which is actually an improvement from PASSED "total 0, passed 0, failed 0" as it will be more visible. /Erik On 2018-10-10 08:47, Christian Tornqvist wrote: > Hi, > > When running JDK and Hotspot jtreg tests through make, TREAT_EXIT_CODE_1_AS_0 is set to true. Any issue with the Java installation used to run jtreg won?t be reflected in the exit code. This has been seen a bunch of times in our internal CI system where we thought we ran tests but instead no tests were run at all because the jtreg Java installation had been deleted/corrupted. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8212008/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212008 > > Thanks, > Christian From matthias.baesken at sap.com Wed Oct 10 16:02:23 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 10 Oct 2018 16:02:23 +0000 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz In-Reply-To: <70e447ee-d3d5-be47-4d62-c18853af13fc@oracle.com> References: <70e447ee-d3d5-be47-4d62-c18853af13fc@oracle.com> Message-ID: Hi Erik, so I think I could disable the warning here : Awt2dLibraries.gmk --------------------------------- $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ NAME := fontmanager, \ .... WARNINGS_AS_ERRORS_xlc := false, \ DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-pointer-cast \ type-limits missing-field-initializers implicit-fallthrough \ strict-aliasing undef unused-function, \ DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete-non-virtual-dtor strict-overflow \ maybe-uninitialized, \ ... (add format-truncation for gcc in the warning-disabling section). However this would disable it also for other versions of gcc where the issue never showed up . Do you think this is fine (and safe for older gcc) ? Best regards, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Mittwoch, 10. Oktober 2018 17:33 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz > > In this case, disabling the warning seems like the right thing to do. > > /Erik > > > On 2018-10-10 06:14, Baesken, Matthias wrote: > > Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also > on linux ppc64) I run into this build error : > > > > > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > er/harfbuzz/hb-common.cc: In function 'void > hb_variation_to_string(hb_variation_t*, char*, unsigned int)': > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 > and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [- > Werror=format-truncation=] > > len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation- > >value)); > > > ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~ > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of > 2147488582 bytes > > cc1plus: all warnings being treated as errors > > > > (build is a product - build) > > > > Setting ?disable-warnings-as-errors works as a workaround , but of > course this is not really what we want to do . > > > > Fixing in the harfbuzz sources in OpenJDk might be also not so nice > because it would clash with imports of new versions of harfbuzz . > > Do you think we could disable the specific warning for the library > compilation ? > > > > Any other great suggestions ? ? > > > > > > Thanks, Matthias From erik.joelsson at oracle.com Wed Oct 10 16:07:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Oct 2018 09:07:59 -0700 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz In-Reply-To: References: <70e447ee-d3d5-be47-4d62-c18853af13fc@oracle.com> Message-ID: <13eb0f90-2c0a-e309-a494-c2425eed7ed9@oracle.com> I think that's fine. This is the granularity we have. /Erik On 2018-10-10 09:02, Baesken, Matthias wrote: > Hi Erik, so I think I could disable the warning here : > > > Awt2dLibraries.gmk > --------------------------------- > > $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ > NAME := fontmanager, \ > .... > WARNINGS_AS_ERRORS_xlc := false, \ > DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to-pointer-cast \ > type-limits missing-field-initializers implicit-fallthrough \ > strict-aliasing undef unused-function, \ > DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete-non-virtual-dtor strict-overflow \ > maybe-uninitialized, \ > ... > > (add format-truncation for gcc in the warning-disabling section). > However this would disable it also for other versions of gcc where the issue never showed up . > > Do you think this is fine (and safe for older gcc) ? > > > Best regards, Matthias > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Mittwoch, 10. Oktober 2018 17:33 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz >> >> In this case, disabling the warning seems like the right thing to do. >> >> /Erik >> >> >> On 2018-10-10 06:14, Baesken, Matthias wrote: >>> Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also >> on linux ppc64) I run into this build error : >>> >>> >> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag >> er/harfbuzz/hb-common.cc: In function 'void >> hb_variation_to_string(hb_variation_t*, char*, unsigned int)': >> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag >> er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 >> and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [- >> Werror=format-truncation=] >>> len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation- >>> value)); >>> >> ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ~~~~~~~~ >> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag >> er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of >> 2147488582 bytes >>> cc1plus: all warnings being treated as errors >>> >>> (build is a product - build) >>> >>> Setting ?disable-warnings-as-errors works as a workaround , but of >> course this is not really what we want to do . >>> Fixing in the harfbuzz sources in OpenJDk might be also not so nice >> because it would clash with imports of new versions of harfbuzz . >>> Do you think we could disable the specific warning for the library >> compilation ? >>> Any other great suggestions ? ? >>> >>> >>> Thanks, Matthias From matthias.baesken at sap.com Wed Oct 10 16:10:57 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 10 Oct 2018 16:10:57 +0000 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz In-Reply-To: <13eb0f90-2c0a-e309-a494-c2425eed7ed9@oracle.com> References: <70e447ee-d3d5-be47-4d62-c18853af13fc@oracle.com> <13eb0f90-2c0a-e309-a494-c2425eed7ed9@oracle.com> Message-ID: Thanks. I am a bit worried that DISABLED_WARNINGS_gcc := format-truncation DISABLED_WARNINGS_CXX_gcc := format-truncation Could bring errors on older gcc versions , any ideas about this ? (will test with gcc 4.8 of course as well ) Best regards, Matthias > -----Original Message----- > From: Erik Joelsson > Sent: Mittwoch, 10. Oktober 2018 18:08 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz > > I think that's fine. This is the granularity we have. > > /Erik > > > On 2018-10-10 09:02, Baesken, Matthias wrote: > > Hi Erik, so I think I could disable the warning here : > > > > > > Awt2dLibraries.gmk > > --------------------------------- > > > > $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ > > NAME := fontmanager, \ > > .... > > WARNINGS_AS_ERRORS_xlc := false, \ > > DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to- > pointer-cast \ > > type-limits missing-field-initializers implicit-fallthrough \ > > strict-aliasing undef unused-function, \ > > DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete- > non-virtual-dtor strict-overflow \ > > maybe-uninitialized, \ > > ... > > > > (add format-truncation for gcc in the warning-disabling section). > > However this would disable it also for other versions of gcc where the > issue never showed up . > > > > Do you think this is fine (and safe for older gcc) ? > > > > > > Best regards, Matthias > > > >> -----Original Message----- > >> From: Erik Joelsson > >> Sent: Mittwoch, 10. Oktober 2018 17:33 > >> To: Baesken, Matthias ; 'build- > >> dev at openjdk.java.net' > >> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz > >> > >> In this case, disabling the warning seems like the right thing to do. > >> > >> /Erik > >> > >> > >> On 2018-10-10 06:14, Baesken, Matthias wrote: > >>> Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also > >> on linux ppc64) I run into this build error : > >>> > >>> > >> > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > >> er/harfbuzz/hb-common.cc: In function 'void > >> hb_variation_to_string(hb_variation_t*, char*, unsigned int)': > >> > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > >> er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between > 1 > >> and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' > [- > >> Werror=format-truncation=] > >>> len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", > variation- > >>> value)); > >>> > >> > ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> ~~~~~~~~ > >> > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag > >> er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of > >> 2147488582 bytes > >>> cc1plus: all warnings being treated as errors > >>> > >>> (build is a product - build) > >>> > >>> Setting ?disable-warnings-as-errors works as a workaround , but of > >> course this is not really what we want to do . > >>> Fixing in the harfbuzz sources in OpenJDk might be also not so nice > >> because it would clash with imports of new versions of harfbuzz . > >>> Do you think we could disable the specific warning for the library > >> compilation ? > >>> Any other great suggestions ? ? > >>> > >>> > >>> Thanks, Matthias From erik.joelsson at oracle.com Wed Oct 10 16:15:45 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Oct 2018 09:15:45 -0700 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz In-Reply-To: References: <70e447ee-d3d5-be47-4d62-c18853af13fc@oracle.com> <13eb0f90-2c0a-e309-a494-c2425eed7ed9@oracle.com> Message-ID: <8803be29-2ccd-c62c-d62a-682487eae548@oracle.com> GCC (since some version older than we support now) ignores disabling of unknown warning labels. This is a feature we depend on for these constructs. Without that it wouldn't be possible to list all the labels like this. (We used to check for this feature in GCC in configure and only use the warning disabling flags if GCC properly ignored unknowns, but since we require a newer version than that now, we no longer need to) /Erik On 2018-10-10 09:10, Baesken, Matthias wrote: > Thanks. > I am a bit worried that > > DISABLED_WARNINGS_gcc := format-truncation > DISABLED_WARNINGS_CXX_gcc := format-truncation > > > Could bring errors on older gcc versions , any ideas about this ? > (will test with gcc 4.8 of course as well ) > > Best regards, Matthias > > > >> -----Original Message----- >> From: Erik Joelsson >> Sent: Mittwoch, 10. Oktober 2018 18:08 >> To: Baesken, Matthias ; 'build- >> dev at openjdk.java.net' >> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz >> >> I think that's fine. This is the granularity we have. >> >> /Erik >> >> >> On 2018-10-10 09:02, Baesken, Matthias wrote: >>> Hi Erik, so I think I could disable the warning here : >>> >>> >>> Awt2dLibraries.gmk >>> --------------------------------- >>> >>> $(eval $(call SetupJdkLibrary, BUILD_LIBFONTMANAGER, \ >>> NAME := fontmanager, \ >>> .... >>> WARNINGS_AS_ERRORS_xlc := false, \ >>> DISABLED_WARNINGS_gcc := format-truncation sign-compare int-to- >> pointer-cast \ >>> type-limits missing-field-initializers implicit-fallthrough \ >>> strict-aliasing undef unused-function, \ >>> DISABLED_WARNINGS_CXX_gcc := format-truncation reorder delete- >> non-virtual-dtor strict-overflow \ >>> maybe-uninitialized, \ >>> ... >>> >>> (add format-truncation for gcc in the warning-disabling section). >>> However this would disable it also for other versions of gcc where the >> issue never showed up . >>> Do you think this is fine (and safe for older gcc) ? >>> >>> >>> Best regards, Matthias >>> >>>> -----Original Message----- >>>> From: Erik Joelsson >>>> Sent: Mittwoch, 10. Oktober 2018 17:33 >>>> To: Baesken, Matthias ; 'build- >>>> dev at openjdk.java.net' >>>> Subject: Re: gcc 7.3.1 build - warnings as errors in harfbuzz >>>> >>>> In this case, disabling the warning seems like the right thing to do. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-10-10 06:14, Baesken, Matthias wrote: >>>>> Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also >>>> on linux ppc64) I run into this build error : >>>>> >> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag >>>> er/harfbuzz/hb-common.cc: In function 'void >>>> hb_variation_to_string(hb_variation_t*, char*, unsigned int)': >>>> >> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag >>>> er/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between >> 1 >>>> and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' >> [- >>>> Werror=format-truncation=] >>>>> len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", >> variation- >>>>> value)); >>>>> >> ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> ~~~~~~~~ >>>> >> /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanag >>>> er/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of >>>> 2147488582 bytes >>>>> cc1plus: all warnings being treated as errors >>>>> >>>>> (build is a product - build) >>>>> >>>>> Setting ?disable-warnings-as-errors works as a workaround , but of >>>> course this is not really what we want to do . >>>>> Fixing in the harfbuzz sources in OpenJDk might be also not so nice >>>> because it would clash with imports of new versions of harfbuzz . >>>>> Do you think we could disable the specific warning for the library >>>> compilation ? >>>>> Any other great suggestions ? ? >>>>> >>>>> >>>>> Thanks, Matthias From volker.simonis at gmail.com Wed Oct 10 17:26:33 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Oct 2018 19:26:33 +0200 Subject: gcc 7.3.1 build - warnings as errors in harfbuzz In-Reply-To: References: Message-ID: Hi Matthias, I've looked a little at this error and it is quite strange. First of all, I can't reproduce it with a default gcc 7.3.0 and there doesn't exist an official version of gcc 7.3.1 (at least I couldn't find it). Also, I can't see the real error in the objected code. The values the warning prints ("assuming directive output of 2147488582 bytes" and "output 2 or more bytes (assuming 2147488583) into a destination of size 127") seem to be excessively large. Every other reference for this warning I could google reports much small numbers and I don't see how a double could potentially use 2147488583 characters in the output buffer. Could this be a problem with the compiler you've used? Could you also ask the people who compiled and patched it? I did found the GCC bug "[7 Regression] -Wformat-overflow false positive exceeding INT_MAX in glibc sysdeps/posix/tempname.c" [1] which seem to resemble to the output you see, but that should have been fixed already in the 7.0 release. Regards, Volker [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79275 On Wed, Oct 10, 2018 at 3:14 PM Baesken, Matthias wrote: > > Hello , when compiling jdk/jdk with gcc 7.3.1 on linux x86_64 (or also on linux ppc64) I run into this build error : > > > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc: In function 'void hb_variation_to_string(hb_variation_t*, char*, unsigned int)': > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: error: '%g' directive output between 1 and 18446744073709551615 bytes may cause result to exceed 'INT_MAX' [-Werror=format-truncation=] > len += MAX (0, snprintf (s + len, ARRAY_LENGTH (s) - len, "%g", variation->value)); > ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /open_jdk/jdk_just_clone/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-common.cc:1066:27: note: assuming directive output of 2147488582 bytes > cc1plus: all warnings being treated as errors > > (build is a product - build) > > Setting ?disable-warnings-as-errors works as a workaround , but of course this is not really what we want to do . > > Fixing in the harfbuzz sources in OpenJDk might be also not so nice because it would clash with imports of new versions of harfbuzz . > Do you think we could disable the specific warning for the library compilation ? > > Any other great suggestions ? > > > Thanks, Matthias From robin.westberg at oracle.com Thu Oct 11 11:00:37 2018 From: robin.westberg at oracle.com (Robin Westberg) Date: Thu, 11 Oct 2018 13:00:37 +0200 Subject: RFR: 8212004: Optional compile_commands.json field not compatible with older libclang In-Reply-To: <0e47ccb6-e289-ed92-a7a1-f311fe26b417@oracle.com> References: <76B27716-CDFA-4F72-8A02-7018B188261C@oracle.com> <0e47ccb6-e289-ed92-a7a1-f311fe26b417@oracle.com> Message-ID: <0D3FB931-4C07-4392-A410-278DCD50C561@oracle.com> Hi Erik, Thanks for reviewing! Best regards, Robin > On 10 Oct 2018, at 17:34, Erik Joelsson wrote: > > Looks good. > > /Erik > > > On 2018-10-10 07:02, Robin Westberg wrote: >> Hi all, >> >> Please review this small change to remove the ?output? field from the compile_commands.json file generated by ?make compile-commands?. As it turns out, this optional field is incompatible with tooling built on libclang versions older than 4.0. As this field provides no real benefit for us, it can simply be dropped from the output. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8212004 >> Webrev: https://cr.openjdk.java.net/~rwestberg/8212004/webrev.00/ >> Testing: tier1, builds-tier5 >> >> Best regards, >> Robin > From kim.barrett at oracle.com Thu Oct 11 19:23:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Oct 2018 15:23:03 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: > On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov wrote: > > Kim, > > Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. My impression is that most of these were not toolchain issues per se. Rather, they were broken or incomplete changes in platform-dependent code that weren't tested on these "alternative" platforms before being pushed. Oracle has provided dev-submit so that non-Oracle folks can do some minimal testing on all the platforms that Oracle supports. I know that I would sometimes like to have similarly "easy" testing for various platforms not supported by Oracle. I didn't suggest "no testing" if there is a compiler version that supports the new language standards but has not yet been fully product-qualified by the people who are using it. I think gcc on arm may be in that category. But I think it would be very disappointing if the complete lack of a usable version of some compiler were to completely block us in this area. (Unfortunately, such a lack appears to be the situation for XLC compiler used for the AIX/ppc port.) The proposal is not very aggressive. > We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. I'm understand that it takes time and effort to do a toolchain upgrade. And turning on support for new language version without changing the toolchain version isn't really all that different. This proposal didn't suddenly appear out of nowhere. There has been wistful discussion about using new language features for a long time, with an understanding that going anywhere with that was difficult because of some popular toolchain deficiencies (notably MSVC++) and the need to upgrade others. There have been ongoing efforts in this direction, e.g. various changes to support building with C++11/14 support enabled. Oracle made toolchain upgrades in JDK 11, in part to support the language standard change. (Unfortunately, the relevant toolchain upgrade JEP was labelled "Confidential", even though a lot of the work was in the open, and some of it was explicitly about dealing with differences arising from turning on C++11/14.) I think JDK 12 for this JEP is reasonable goal at this stage. Of course, that goal might not be achieved, for a variety of reasons. That's why it is not yet in the Targeted state and why there is a formal process for moving to that state; there's still work to be done, and we'll have to see how that work proceeds. > With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. From erik.joelsson at oracle.com Thu Oct 11 22:29:38 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Oct 2018 15:29:38 -0700 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 Message-ID: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Hello, (adding serviceability-dev and hotspot-dev for test changes) Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From ihse-runtestprebuilt-branch in jdk-sandbox) In order to fully adopt the new run-test framework, we need to switch over the automated and distributed testing system at Oracle to the new framework. To get this to work, there are number of issues that needed to be fixed. Here follows a brief explanation, see bug for more details. For RunTest.gmk and related makefiles there are a number of minor tweaks to support all the necessary control variables that are currently used for the old test makefiles, as well as correcting some test setup settings. In addition to that, some tests also needed to be modified: Timeouts The current default timeoutFactor in the makefiles is 4. However, the old Mach5 executor overrides that to 10. I don't think it should dabble with such things and leave it to the makefiles, the user, or a specific job definition, so with the new run-test executor, it no longer does. This means many tests now have a much shorter effective timeout. Because of this, we need to increase the timeout on some that are now prone to timing out. I have run tier1-5 a few times to try and find these and added /timeout=300 (which will result in the same effective timeout as before) when specific tests seemed problematic. test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java This test spawns a child process and tries to locate it using the attach api, by looking for a unique token in the command line string of the spawned JVM. The problem is that the command line string it gets from the attach api is truncated and the token is last on the command line. This normally works well, but the arguments before it are 3 files, with full absolute paths inside the jtreg work directory. With Mach5 we have pretty deep work directories, and with run-test, we make them even deeper. This unfortunately trips the limit and the test fails. I have fixed this by reordering the arguments to the child process. /Erik From david.holmes at oracle.com Thu Oct 11 22:40:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Oct 2018 08:40:34 +1000 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Message-ID: Hi Erik, On 12/10/2018 8:29 AM, Erik Joelsson wrote: > Hello, > > (adding serviceability-dev and hotspot-dev for test changes) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > > Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html > (From ihse-runtestprebuilt-branch in jdk-sandbox) > > In order to fully adopt the new run-test framework, we need to switch > over the automated and distributed testing system at Oracle to the new > framework. To get this to work, there are number of issues that needed > to be fixed. Here follows a brief explanation, see bug for more details. > > For RunTest.gmk and related makefiles there are a number of minor tweaks > to support all the necessary control variables that are currently used > for the old test makefiles, as well as correcting some test setup settings. > > In addition to that, some tests also needed to be modified: > > Timeouts > The current default timeoutFactor in the makefiles is 4. However, the > old Mach5 executor overrides that to 10. I don't think it should dabble > with such things and leave it to the makefiles, the user, or a specific > job definition, so with the new run-test executor, it no longer does. > This means many tests now have a much shorter effective timeout. Because > of this, we need to increase the timeout on some that are now prone to > timing out. I have run tier1-5 a few times to try and find these and > added /timeout=300 (which will result in the same effective timeout as > before) when specific tests seemed problematic. This should be fixed in the tier job definitions not the individual tests. We have moved away from putting explicit timeouts on individual tests and instead rely on the framework timeout being set appropriately. David ----- > test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java > This test spawns a child process and tries to locate it using the attach > api, by looking for a unique token in the command line string of the > spawned JVM. The problem is that the command line string it gets from > the attach api is truncated and the token is last on the command line. > This normally works well, but the arguments before it are 3 files, with > full absolute paths inside the jtreg work directory. With Mach5 we have > pretty deep work directories, and with run-test, we make them even > deeper. This unfortunately trips the limit and the test fails. I have > fixed this by reordering the arguments to the child process. > > /Erik > From jonathan.gibbons at oracle.com Fri Oct 12 01:58:30 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Oct 2018 18:58:30 -0700 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Message-ID: <26b774ef-2091-cbc2-b40d-6b22575a3d4b@oracle.com> On 10/11/18 3:40 PM, David Holmes wrote: > Hi Erik, > > On 12/10/2018 8:29 AM, Erik Joelsson wrote: >> Hello, >> >> (adding serviceability-dev and hotspot-dev for test changes) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 >> >> Webrev: >> http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From >> ihse-runtestprebuilt-branch in jdk-sandbox) >> >> In order to fully adopt the new run-test framework, we need to switch >> over the automated and distributed testing system at Oracle to the >> new framework. To get this to work, there are number of issues that >> needed to be fixed. Here follows a brief explanation, see bug for >> more details. >> >> For RunTest.gmk and related makefiles there are a number of minor >> tweaks to support all the necessary control variables that are >> currently used for the old test makefiles, as well as correcting some >> test setup settings. >> >> In addition to that, some tests also needed to be modified: >> >> Timeouts >> The current default timeoutFactor in the makefiles is 4. However, the >> old Mach5 executor overrides that to 10. I don't think it should >> dabble with such things and leave it to the makefiles, the user, or a >> specific job definition, so with the new run-test executor, it no >> longer does. This means many tests now have a much shorter effective >> timeout. Because of this, we need to increase the timeout on some >> that are now prone to timing out. I have run tier1-5 a few times to >> try and find these and added /timeout=300 (which will result in the >> same effective timeout as before) when specific tests seemed >> problematic. > > This should be fixed in the tier job definitions not the individual > tests. We have moved away from putting explicit timeouts on individual > tests and instead rely on the framework timeout being set appropriately. > > David > ----- David, That's a suboptimal policy. because it means you're relying on the framework handling the worst case test. As far as jtreg goes, the default timeout for each step is 2 mins, which is intended to be enough for the test to reliably run within that time on a reasonably modern developer-class machine.? A test which always times out on a good machine should use a test-specific increased timeout. Where the framework can help is, if tests are being run on an old or slow machine, or if test run args are provided that will cause the test to run significantly slower than usual, then the framework can/should start scaling up the timeout factor. -- Jon > >> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java >> This test spawns a child process and tries to locate it using the >> attach api, by looking for a unique token in the command line string >> of the spawned JVM. The problem is that the command line string it >> gets from the attach api is truncated and the token is last on the >> command line. This normally works well, but the arguments before it >> are 3 files, with full absolute paths inside the jtreg work >> directory. With Mach5 we have pretty deep work directories, and with >> run-test, we make them even deeper. This unfortunately trips the >> limit and the test fails. I have fixed this by reordering the >> arguments to the child process. >> >> /Erik >> From david.holmes at oracle.com Fri Oct 12 04:29:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Oct 2018 14:29:12 +1000 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <26b774ef-2091-cbc2-b40d-6b22575a3d4b@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> <26b774ef-2091-cbc2-b40d-6b22575a3d4b@oracle.com> Message-ID: <19352b0a-7862-464e-f4a8-b66c96a7e470@oracle.com> Hi Jon, On 12/10/2018 11:58 AM, Jonathan Gibbons wrote: > > > On 10/11/18 3:40 PM, David Holmes wrote: >> Hi Erik, >> >> On 12/10/2018 8:29 AM, Erik Joelsson wrote: >>> Hello, >>> >>> (adding serviceability-dev and hotspot-dev for test changes) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From >>> ihse-runtestprebuilt-branch in jdk-sandbox) >>> >>> In order to fully adopt the new run-test framework, we need to switch >>> over the automated and distributed testing system at Oracle to the >>> new framework. To get this to work, there are number of issues that >>> needed to be fixed. Here follows a brief explanation, see bug for >>> more details. >>> >>> For RunTest.gmk and related makefiles there are a number of minor >>> tweaks to support all the necessary control variables that are >>> currently used for the old test makefiles, as well as correcting some >>> test setup settings. >>> >>> In addition to that, some tests also needed to be modified: >>> >>> Timeouts >>> The current default timeoutFactor in the makefiles is 4. However, the >>> old Mach5 executor overrides that to 10. I don't think it should >>> dabble with such things and leave it to the makefiles, the user, or a >>> specific job definition, so with the new run-test executor, it no >>> longer does. This means many tests now have a much shorter effective >>> timeout. Because of this, we need to increase the timeout on some >>> that are now prone to timing out. I have run tier1-5 a few times to >>> try and find these and added /timeout=300 (which will result in the >>> same effective timeout as before) when specific tests seemed >>> problematic. >> >> This should be fixed in the tier job definitions not the individual >> tests. We have moved away from putting explicit timeouts on individual >> tests and instead rely on the framework timeout being set appropriately. >> >> David >> ----- > > David, > > That's a suboptimal policy. because it means you're relying on the > framework handling the worst case test. Yes. Given we have such a huge range of tests running on a range of platforms, on machines with a range of capabilities, using a range of VM flags and using a range of loads on the test machines, this has to be punted to the framework - otherwise you have to update every test to add an explicit timeout for the worst case (as experienced by some runner of the tests). There's no holy-grail answer here. My understanding of current approach was to set the framework timeout so that the majority of tests running under a given "normal" execution context pass. Then add multipliers for specific test configurations or platforms known to take longer (-Xcomp or sparc, for example). Then tests that don't fit within that chosen timeout get either their own timeout set, or moved to a tier with a different multiplier. This change basically lowers the bar that had been set such that more tests now need explicit timeouts. I'm not sure why that was necessary, nor do I think it necessarily a good thing. But after some internal discussions the test folk seem to be okay with this, so having said my piece I'll let it drop. > As far as jtreg goes, the default timeout for each step is 2 mins, which > is intended to be enough for the test to reliably run within that time > on a reasonably modern developer-class machine.? A test which always > times out on a good machine should use a test-specific increased timeout. Agreed. > Where the framework can help is, if tests are being run on an old or > slow machine, or if test run args are provided that will cause the test > to run significantly slower than usual, then the framework can/should > start scaling up the timeout factor. Again agreed. Cheers, David > -- Jon >> >>> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java >>> This test spawns a child process and tries to locate it using the >>> attach api, by looking for a unique token in the command line string >>> of the spawned JVM. The problem is that the command line string it >>> gets from the attach api is truncated and the token is last on the >>> command line. This normally works well, but the arguments before it >>> are 3 files, with full absolute paths inside the jtreg work >>> directory. With Mach5 we have pretty deep work directories, and with >>> run-test, we make them even deeper. This unfortunately trips the >>> limit and the test fails. I have fixed this by reordering the >>> arguments to the child process. >>> >>> /Erik >>> > From magnus.ihse.bursie at oracle.com Fri Oct 12 08:37:07 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Oct 2018 10:37:07 +0200 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Message-ID: <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> Hi Erik, Thank you for preserving through this, so we finally can move to 100% run-test! On 2018-10-12 00:29, Erik Joelsson wrote: > Hello, > > (adding serviceability-dev and hotspot-dev for test changes) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > > Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html > (From ihse-runtestprebuilt-branch in jdk-sandbox) Build changes look good. And I agree with the solution to add longer timeout to individual tests. > > In order to fully adopt the new run-test framework, we need to switch > over the automated and distributed testing system at Oracle to the new > framework. To get this to work, there are number of issues that needed > to be fixed. Here follows a brief explanation, see bug for more details. > > For RunTest.gmk and related makefiles there are a number of minor > tweaks to support all the necessary control variables that are > currently used for the old test makefiles, as well as correcting some > test setup settings. > > In addition to that, some tests also needed to be modified: > > Timeouts > The current default timeoutFactor in the makefiles is 4. However, the > old Mach5 executor overrides that to 10. I don't think it should > dabble with such things and leave it to the makefiles, the user, or a > specific job definition, so with the new run-test executor, it no > longer does. This means many tests now have a much shorter effective > timeout. Because of this, we need to increase the timeout on some that > are now prone to timing out. I have run tier1-5 a few times to try and > find these and added /timeout=300 (which will result in the same > effective timeout as before) when specific tests seemed problematic. > > test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java > This test spawns a child process and tries to locate it using the > attach api, by looking for a unique token in the command line string > of the spawned JVM. The problem is that the command line string it > gets from the attach api is truncated and the token is last on the > command line. This normally works well, but the arguments before it > are 3 files, with full absolute paths inside the jtreg work directory. > With Mach5 we have pretty deep work directories, and with run-test, we > make them even deeper. This unfortunately trips the limit and the test > fails. I have fixed this by reordering the arguments to the child > process. ... but I'm not sure I understand this. Is it a command-line length we're hitting? If so, how can reordering the arguments solve anything? I understand why this can preserve the token, but will not one of the paths be cut of instead? /Magnus > > /Erik > From sgehwolf at redhat.com Fri Oct 12 09:20:03 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Oct 2018 11:20:03 +0200 Subject: RFR: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 Message-ID: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> Hi, Please review this fix for a build failure of saproc.dll on Windows 32 bit. For 32 bit Windows builds flag -RTC1 gets added unconditionally. Yet, as per compiler doc[1] it should only be added for development builds. This causes a build failure post JDK-8210647 as in release/fastdebug variant builds of the JDK saproc.dll will get optimization flags producing an incompatible set of flags. This used to work prior JDK-8210647, because saproc.dll was never optimized (not even in release/fastdebug variants). The proposed fix is to only add the flag for slowdebug builds, which corresponds to development builds in OpenJDK. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8212110 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8212110/webrev.01/ Unfortunately, I don't have a system to actually test this on. So will rely on Martin or Matthias to test whether this fixes the build failure [2] they are seeing. AFAIK, Oracle no longer builds on Windows 32 bit either. Thanks, Severin [1] https://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-October/000213.html From martin.doerr at sap.com Fri Oct 12 10:52:40 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 12 Oct 2018 10:52:40 +0000 Subject: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 In-Reply-To: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> References: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> Message-ID: <4beaea2498bf410a8eba477f09f433f7@sap.com> Hi Severin, thank you for providing this fix so quickly. It looks good to me. I was able to build jdk11u with this patch. Just for information: I'm using Visual Studio 2013 and configure with --disable-warnings-as-errors. (Otherwise I got Creating support/modules_cmds/jdk.hotspot.agent/jhsdb.exe from 1 file(s) jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(773) : error C2220: warning treated as error - no 'object' file generated jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(773) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTKEY', possible loss of data jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(773) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTPROV', possible loss of data jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(967) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTKEY', possible loss of data jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(967) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTPROV', possible loss of data ) But that's unrelated to your fix. It works fine. Best regards, Martin -----Original Message----- From: Severin Gehwolf Sent: Freitag, 12. Oktober 2018 11:20 To: build-dev Cc: Doerr, Martin ; Baesken, Matthias Subject: RFR: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 Hi, Please review this fix for a build failure of saproc.dll on Windows 32 bit. For 32 bit Windows builds flag -RTC1 gets added unconditionally. Yet, as per compiler doc[1] it should only be added for development builds. This causes a build failure post JDK-8210647 as in release/fastdebug variant builds of the JDK saproc.dll will get optimization flags producing an incompatible set of flags. This used to work prior JDK-8210647, because saproc.dll was never optimized (not even in release/fastdebug variants). The proposed fix is to only add the flag for slowdebug builds, which corresponds to development builds in OpenJDK. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8212110 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8212110/webrev.01/ Unfortunately, I don't have a system to actually test this on. So will rely on Martin or Matthias to test whether this fixes the build failure [2] they are seeing. AFAIK, Oracle no longer builds on Windows 32 bit either. Thanks, Severin [1] https://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-October/000213.html From sgehwolf at redhat.com Fri Oct 12 11:49:05 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Oct 2018 13:49:05 +0200 Subject: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 In-Reply-To: <4beaea2498bf410a8eba477f09f433f7@sap.com> References: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> <4beaea2498bf410a8eba477f09f433f7@sap.com> Message-ID: Hi Martin, On Fri, 2018-10-12 at 10:52 +0000, Doerr, Martin wrote: > Hi Severin, > > thank you for providing this fix so quickly. It looks good to me. Thanks for testing and the review. > I was able to build jdk11u with this patch. > > Just for information: > I'm using Visual Studio 2013 and configure with --disable-warnings-as-errors. > (Otherwise I got > Creating support/modules_cmds/jdk.hotspot.agent/jhsdb.exe from 1 file(s) > jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(773) : error C2220: warning treated as error - no 'object' file generated > jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(773) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTKEY', possible loss of data > jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(773) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTPROV', possible loss of data > jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(967) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTKEY', possible loss of data > jdk11u/src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp(967) : warning C4244: 'argument' : conversion from 'jlong' to 'HCRYPTPROV', possible loss of data > ) > > But that's unrelated to your fix. It works fine. OK. I'll wait for some build people to review this too and then push. Thanks, Severin > Best regards, > Martin > > > -----Original Message----- > From: Severin Gehwolf > Sent: Freitag, 12. Oktober 2018 11:20 > To: build-dev > Cc: Doerr, Martin ; Baesken, Matthias > Subject: RFR: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 > > Hi, > > Please review this fix for a build failure of saproc.dll on Windows 32 > bit. For 32 bit Windows builds flag -RTC1 gets added unconditionally. > Yet, as per compiler doc[1] it should only be added for development > builds. This causes a build failure post JDK-8210647 as in > release/fastdebug variant builds of the JDK saproc.dll will get > optimization flags producing an incompatible set of flags. This used to > work prior JDK-8210647, because saproc.dll was never optimized (not > even in release/fastdebug variants). > > The proposed fix is to only add the flag for slowdebug builds, which > corresponds to development builds in OpenJDK. Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212110 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8212110/webrev.01/ > > Unfortunately, I don't have a system to actually test this on. So will > rely on Martin or Matthias to test whether this fixes the build failure > [2] they are seeing. AFAIK, Oracle no longer builds on Windows 32 bit > either. > > Thanks, > Severin > > [1] https://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-October/000213.html > From erik.joelsson at oracle.com Fri Oct 12 16:09:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Oct 2018 09:09:24 -0700 Subject: RFR: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 In-Reply-To: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> References: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> Message-ID: <43e33883-bb64-e825-ecec-609fa9688ca2@oracle.com> Looks good to me. I wonder why only this library has that flag. Perhaps something that should be applied more generally or not at all? (In a followup of course) /Erik On 2018-10-12 02:20, Severin Gehwolf wrote: > Hi, > > Please review this fix for a build failure of saproc.dll on Windows 32 > bit. For 32 bit Windows builds flag -RTC1 gets added unconditionally. > Yet, as per compiler doc[1] it should only be added for development > builds. This causes a build failure post JDK-8210647 as in > release/fastdebug variant builds of the JDK saproc.dll will get > optimization flags producing an incompatible set of flags. This used to > work prior JDK-8210647, because saproc.dll was never optimized (not > even in release/fastdebug variants). > > The proposed fix is to only add the flag for slowdebug builds, which > corresponds to development builds in OpenJDK. Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212110 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8212110/webrev.01/ > > Unfortunately, I don't have a system to actually test this on. So will > rely on Martin or Matthias to test whether this fixes the build failure > [2] they are seeing. AFAIK, Oracle no longer builds on Windows 32 bit > either. > > Thanks, > Severin > > [1] https://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx > [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-October/000213.html > From erik.joelsson at oracle.com Fri Oct 12 16:16:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Oct 2018 09:16:43 -0700 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> Message-ID: <02afe047-2c6d-e902-68b4-595ca85cbad4@oracle.com> On 2018-10-12 01:37, Magnus Ihse Bursie wrote: > Hi Erik, > > Thank you for preserving through this, so we finally can move to 100% > run-test! > > On 2018-10-12 00:29, Erik Joelsson wrote: > >> Hello, >> >> (adding serviceability-dev and hotspot-dev for test changes) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 >> >> Webrev: >> http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From >> ihse-runtestprebuilt-branch in jdk-sandbox) > Build changes look good. And I agree with the solution to add longer > timeout to individual tests. Thanks! >> >> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java >> This test spawns a child process and tries to locate it using the >> attach api, by looking for a unique token in the command line string >> of the spawned JVM. The problem is that the command line string it >> gets from the attach api is truncated and the token is last on the >> command line. This normally works well, but the arguments before it >> are 3 files, with full absolute paths inside the jtreg work >> directory. With Mach5 we have pretty deep work directories, and with >> run-test, we make them even deeper. This unfortunately trips the >> limit and the test fails. I have fixed this by reordering the >> arguments to the child process. > ... but I'm not sure I understand this. Is it a command-line length > we're hitting? If so, how can reordering the arguments solve anything? > I understand why this can preserve the token, but will not one of the > paths be cut of instead? > I will try to be clearer. The command line is fine for running the child process. The truncation happens when the attach api is used to try to find the child process. It basically calls something that lists all JVMs on system, iterates through them and looks at the "description" field. This field happens to contain the first X characters of the command line so the test looks for the unique token it knows it put there. (I don't know the exact value of X, but could find out). Until now, X was big enough to fit the whole command line, but with the 3 absolute path files in there now growing long enough, the last argument is pushed out of the description field. This means the test process is unable to locate the child process in the list of JVMs. What then happens is the test keeps on looking, taking new snapshots of all JVMs on the system until the test finally times out. By reordering the arguments, the token is less likely to be cut out of the description field. /Erik From sgehwolf at redhat.com Fri Oct 12 16:19:17 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Oct 2018 18:19:17 +0200 Subject: RFR: 8212110: Build of saproc.dll broken on Windows 32 bit after JDK-8210647 In-Reply-To: <43e33883-bb64-e825-ecec-609fa9688ca2@oracle.com> References: <0116762a5638c3190d3c0313c2bee9f2c38dfc73.camel@redhat.com> <43e33883-bb64-e825-ecec-609fa9688ca2@oracle.com> Message-ID: Hi Erik, On Fri, 2018-10-12 at 09:09 -0700, Erik Joelsson wrote: > Looks good to me. > > I wonder why only this library has that flag. Perhaps something that > should be applied more generally or not at all? (In a followup of > course) Thanks for the review! I suppose the original intention was to help find coding problems (useful for devel builds). Cheers, Severin > /Erik > > > On 2018-10-12 02:20, Severin Gehwolf wrote: > > Hi, > > > > Please review this fix for a build failure of saproc.dll on Windows > > 32 > > bit. For 32 bit Windows builds flag -RTC1 gets added > > unconditionally. > > Yet, as per compiler doc[1] it should only be added for development > > builds. This causes a build failure post JDK-8210647 as in > > release/fastdebug variant builds of the JDK saproc.dll will get > > optimization flags producing an incompatible set of flags. This > > used to > > work prior JDK-8210647, because saproc.dll was never optimized (not > > even in release/fastdebug variants). > > > > The proposed fix is to only add the flag for slowdebug builds, > > which > > corresponds to development builds in OpenJDK. Thoughts? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212110 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8212110/webrev.01/ > > > > Unfortunately, I don't have a system to actually test this on. So > > will > > rely on Martin or Matthias to test whether this fixes the build > > failure > > [2] they are seeing. AFAIK, Oracle no longer builds on Windows 32 > > bit > > either. > > > > Thanks, > > Severin > > > > [1] https://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx > > [2] > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-October/000213.html > > > > From magnus.ihse.bursie at oracle.com Fri Oct 12 17:07:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Oct 2018 19:07:08 +0200 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <02afe047-2c6d-e902-68b4-595ca85cbad4@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> <02afe047-2c6d-e902-68b4-595ca85cbad4@oracle.com> Message-ID: <84B6AC75-0A3E-489B-B7AF-D60C285AA408@oracle.com> > 12 okt. 2018 kl. 18:16 skrev Erik Joelsson : > > >> On 2018-10-12 01:37, Magnus Ihse Bursie wrote: >> Hi Erik, >> >> Thank you for preserving through this, so we finally can move to 100% run-test! >> >>> On 2018-10-12 00:29, Erik Joelsson wrote: >>> >>> Hello, >>> >>> (adding serviceability-dev and hotspot-dev for test changes) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From ihse-runtestprebuilt-branch in jdk-sandbox) >> Build changes look good. And I agree with the solution to add longer timeout to individual tests. > Thanks! >>> >>> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java >>> This test spawns a child process and tries to locate it using the attach api, by looking for a unique token in the command line string of the spawned JVM. The problem is that the command line string it gets from the attach api is truncated and the token is last on the command line. This normally works well, but the arguments before it are 3 files, with full absolute paths inside the jtreg work directory. With Mach5 we have pretty deep work directories, and with run-test, we make them even deeper. This unfortunately trips the limit and the test fails. I have fixed this by reordering the arguments to the child process. >> ... but I'm not sure I understand this. Is it a command-line length we're hitting? If so, how can reordering the arguments solve anything? I understand why this can preserve the token, but will not one of the paths be cut of instead? > I will try to be clearer. The command line is fine for running the child process. The truncation happens when the attach api is used to try to find the child process. It basically calls something that lists all JVMs on system, iterates through them and looks at the "description" field. This field happens to contain the first X characters of the command line so the test looks for the unique token it knows it put there. (I don't know the exact value of X, but could find out). Until now, X was big enough to fit the whole command line, but with the 3 absolute path files in there now growing long enough, the last argument is pushed out of the description field. This means the test process is unable to locate the child process in the list of JVMs. What then happens is the test keeps on looking, taking new snapshots of all JVMs on the system until the test finally times out. By reordering the arguments, the token is less likely to be cut out of the description field. > I see. Then your fix makes totally sense. /Magnus > /Erik > From jonathan.gibbons at oracle.com Thu Oct 11 19:31:32 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Oct 2018 12:31:32 -0700 Subject: RFR: 8212008: Use of TREAT_EXIT_CODE_1_AS_0 hide problems with jtreg Java In-Reply-To: <71f1fbf0-1126-8569-9c92-e78d24b3414b@oracle.com> References: <71f1fbf0-1126-8569-9c92-e78d24b3414b@oracle.com> Message-ID: <22dce184-b036-41f8-efc3-ad024b4a1e1f@oracle.com> Unrelated to the proposed change, the test/hotspot/jtreg/Makefile contains this line: 30 31 USE_JTREG_VERSION := 4.1 That would appear to be somewhat out of date, or (more likely) not used. -- Jon On 10/10/2018 09:01 AM, Erik Joelsson wrote: > Looks good. > > A side effect of this is that if no tests are found (also returns 1), > make will fail. In our CI system, this will be interpreted as NOT_RUN > "no tests found", which is actually an improvement from PASSED "total > 0, passed 0, failed 0" as it will be more visible. > > /Erik > > > On 2018-10-10 08:47, Christian Tornqvist wrote: >> Hi, >> >> When running JDK and Hotspot jtreg tests through make, >> TREAT_EXIT_CODE_1_AS_0 is set to true. Any issue with the Java >> installation used to run jtreg won?t be reflected in the exit code. >> This has been seen a bunch of times in our internal CI system where >> we thought we ran tests but instead no tests were run at all because >> the jtreg Java installation had been deleted/corrupted. >> >> Webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8212008/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212008 >> >> >> Thanks, >> Christian > From aleksei.voitylov at bell-sw.com Mon Oct 15 11:51:24 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 15 Oct 2018 14:51:24 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: Kim, If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. -Aleksei On 11/10/2018 22:23, Kim Barrett wrote: >> On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov wrote: >> >> Kim, >> >> Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. > My impression is that most of these were not toolchain issues per se. > Rather, they were broken or incomplete changes in platform-dependent > code that weren't tested on these "alternative" platforms before being > pushed. Oracle has provided dev-submit so that non-Oracle folks can > do some minimal testing on all the platforms that Oracle supports. I > know that I would sometimes like to have similarly "easy" testing for > various platforms not supported by Oracle. > > I didn't suggest "no testing" if there is a compiler version that > supports the new language standards but has not yet been fully > product-qualified by the people who are using it. I think gcc on arm > may be in that category. But I think it would be very disappointing > if the complete lack of a usable version of some compiler were to > completely block us in this area. (Unfortunately, such a lack appears > to be the situation for XLC compiler used for the AIX/ppc port.) The > proposal is not very aggressive. > >> We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. > I'm understand that it takes time and effort to do a toolchain > upgrade. And turning on support for new language version without > changing the toolchain version isn't really all that different. > > This proposal didn't suddenly appear out of nowhere. There has been > wistful discussion about using new language features for a long time, > with an understanding that going anywhere with that was difficult > because of some popular toolchain deficiencies (notably MSVC++) and > the need to upgrade others. There have been ongoing efforts in this > direction, e.g. various changes to support building with C++11/14 > support enabled. Oracle made toolchain upgrades in JDK 11, in part to > support the language standard change. (Unfortunately, the relevant > toolchain upgrade JEP was labelled "Confidential", even though a lot > of the work was in the open, and some of it was explicitly about > dealing with differences arising from turning on C++11/14.) > > I think JDK 12 for this JEP is reasonable goal at this stage. Of > course, that goal might not be achieved, for a variety of reasons. > That's why it is not yet in the Targeted state and why there is a > formal process for moving to that state; there's still work to be > done, and we'll have to see how that work proceeds. > >> With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. > From claes.redestad at oracle.com Mon Oct 15 19:10:53 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 15 Oct 2018 21:10:53 +0200 Subject: RFR: 8212201: Classlist build tool should be built with new javac Message-ID: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> Hi, please review this patch to build HelloClasslist / classlist.jar targetting the latest bytecode version, to ensure the classlist generation uses all recent features, e.g., indified string concat (as intended) Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 Thanks! /Claes From erik.joelsson at oracle.com Mon Oct 15 20:43:58 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Oct 2018 13:43:58 -0700 Subject: RFR: 8212201: Classlist build tool should be built with new javac In-Reply-To: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> References: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> Message-ID: <36ecb07c-0c1e-0bcc-13e5-c569ea488bdd@oracle.com> Looks good. /Erik On 2018-10-15 12:10, Claes Redestad wrote: > Hi, > > please review this patch to build HelloClasslist / classlist.jar > targetting the latest bytecode version, to ensure the classlist > generation uses all recent features, e.g., indified string concat (as > intended) > > Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Oct 15 22:18:59 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 16 Oct 2018 00:18:59 +0200 Subject: RFR: 8212201: Classlist build tool should be built with new javac In-Reply-To: <36ecb07c-0c1e-0bcc-13e5-c569ea488bdd@oracle.com> References: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> <36ecb07c-0c1e-0bcc-13e5-c569ea488bdd@oracle.com> Message-ID: <5bffec30-b4cf-902e-cd77-4c3f4871214a@oracle.com> Thanks! /Claes On 2018-10-15 22:43, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2018-10-15 12:10, Claes Redestad wrote: >> Hi, >> >> please review this patch to build HelloClasslist / classlist.jar >> targetting the latest bytecode version, to ensure the classlist >> generation uses all recent features, e.g., indified string concat (as >> intended) >> >> Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 >> >> Thanks! >> >> /Claes > From kim.barrett at oracle.com Mon Oct 15 23:25:47 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Oct 2018 19:25:47 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: > On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov wrote: > > Kim, > > If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. What is "sufficient lead time"? I'm not proposing an answer, just suggesting that 3 months (approx time between JEP publication and JDK 12 fork) might be sufficient, and a worthy goal. That's a decision that ought to be made as part of the Targeting discussion for this JEP. Right now, it's not even a Candidate, since there's still work to be done. > Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. That's good news, though pretty much what I expected. I'm more worried about Solaris. Having a goal of JDK 12 may help move things along. From magnus.ihse.bursie at oracle.com Wed Oct 17 10:29:31 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 Oct 2018 12:29:31 +0200 Subject: RFR: JDK-8212587 equals in MakeBase does not handle empty strings correctly Message-ID: <92cb6d05-e2b6-a057-14cf-69dc8e0ce75b@oracle.com> The macro equals in MakeBase.gmk does not handle empty strings correctly. Comparing two empty strings returns as non-equal, even though they should be equal. This had the result that DependOnVariable caused eternal redoing of a target if the variable in question happened to be empty, since when the new empty value was compared to the old empty value, it was deemed different, and thus a remake of the target was initiated. The solution was tricky, even by Make syntax standards. I guarantee you, every single space in this construct must be the way it is. :-& Bug: https://bugs.openjdk.java.net/browse/JDK-8212587 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8212587-equals-handle-empty-strings/webrev.01 /Magnus From claes.redestad at oracle.com Wed Oct 17 11:55:15 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 17 Oct 2018 13:55:15 +0200 Subject: RFR: 8212201: Classlist build tool should be built with new javac In-Reply-To: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> References: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> Message-ID: <9acd7872-3fae-b952-5ab9-46e9725b672c@oracle.com> Hi again, stumbled on some failures in pre-integration testing (but not locally, initially) due to having the wrong include: http://cr.openjdk.java.net/~redestad/8212201/jdk.01 Thanks Magnus for pointing out the very peculiar ways make is silent about missing definitions, leading to weird errors down the line instead of failing fast.. /Claes On 2018-10-15 21:10, Claes Redestad wrote: > Hi, > > please review this patch to build HelloClasslist / classlist.jar > targetting the latest bytecode version, to ensure the classlist > generation uses all recent features, e.g., indified string concat (as > intended) > > Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 > > Thanks! > > /Claes From magnus.ihse.bursie at oracle.com Wed Oct 17 11:57:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 Oct 2018 13:57:08 +0200 Subject: RFR: 8212201: Classlist build tool should be built with new javac In-Reply-To: <9acd7872-3fae-b952-5ab9-46e9725b672c@oracle.com> References: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> <9acd7872-3fae-b952-5ab9-46e9725b672c@oracle.com> Message-ID: <4243601a-1dc0-e587-ec5c-b1584be16618@oracle.com> Looks good to me. /Magnus On 2018-10-17 13:55, Claes Redestad wrote: > Hi again, > > stumbled on some failures in pre-integration testing (but not locally, > initially) due to having the wrong include: > > http://cr.openjdk.java.net/~redestad/8212201/jdk.01 > > Thanks Magnus for pointing out the very peculiar ways make is silent > about missing definitions, leading to weird errors down the line > instead of failing fast.. > > /Claes > > On 2018-10-15 21:10, Claes Redestad wrote: >> Hi, >> >> please review this patch to build HelloClasslist / classlist.jar >> targetting the latest bytecode version, to ensure the classlist >> generation uses all recent features, e.g., indified string concat (as >> intended) >> >> Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 >> >> Thanks! >> >> /Claes > From erik.joelsson at oracle.com Wed Oct 17 16:28:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Oct 2018 09:28:05 -0700 Subject: RFR: JDK-8212587 equals in MakeBase does not handle empty strings correctly In-Reply-To: <92cb6d05-e2b6-a057-14cf-69dc8e0ce75b@oracle.com> References: <92cb6d05-e2b6-a057-14cf-69dc8e0ce75b@oracle.com> Message-ID: <3fc103c9-7e2e-45fe-2b0e-88b54d23280e@oracle.com> Looks good! /Erik On 2018-10-17 03:29, Magnus Ihse Bursie wrote: > The macro equals in MakeBase.gmk does not handle empty strings > correctly. Comparing two empty strings returns as non-equal, even > though they should be equal. > > This had the result that DependOnVariable caused eternal redoing of a > target if the variable in question happened to be empty, since when > the new empty value was compared to the old empty value, it was deemed > different, and thus a remake of the target was initiated. > > The solution was tricky, even by Make syntax standards. I guarantee > you, every single space in this construct must be the way it is. :-& > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212587 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8212587-equals-handle-empty-strings/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Wed Oct 17 16:28:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Oct 2018 09:28:57 -0700 Subject: RFR: 8212201: Classlist build tool should be built with new javac In-Reply-To: <9acd7872-3fae-b952-5ab9-46e9725b672c@oracle.com> References: <17cf6803-68c7-c663-2fb7-3cb08550adc5@oracle.com> <9acd7872-3fae-b952-5ab9-46e9725b672c@oracle.com> Message-ID: <94162c82-1508-9219-3cd0-de778efd35fa@oracle.com> Looks good. /Erik On 2018-10-17 04:55, Claes Redestad wrote: > Hi again, > > stumbled on some failures in pre-integration testing (but not locally, > initially) due to having the wrong include: > > http://cr.openjdk.java.net/~redestad/8212201/jdk.01 > > Thanks Magnus for pointing out the very peculiar ways make is silent > about missing definitions, leading to weird errors down the line > instead of failing fast.. > > /Claes > > On 2018-10-15 21:10, Claes Redestad wrote: >> Hi, >> >> please review this patch to build HelloClasslist / classlist.jar >> targetting the latest bytecode version, to ensure the classlist >> generation uses all recent features, e.g., indified string concat (as >> intended) >> >> Webrev: http://cr.openjdk.java.net/~redestad/8212201/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212201 >> >> Thanks! >> >> /Claes > From aleksei.voitylov at bell-sw.com Wed Oct 17 20:50:30 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 17 Oct 2018 23:50:30 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: <32419fac-84fe-c247-b91d-e8a5ead67cf2@bell-sw.com> On 16/10/2018 02:25, Kim Barrett wrote: >> On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov wrote: >> >> Kim, >> >> If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. > What is "sufficient lead time"? I'm not proposing an answer, just > suggesting that 3 months (approx time between JEP publication and JDK > 12 fork) might be sufficient, and a worthy goal. That's a decision > that ought to be made as part of the Targeting discussion for this > JEP. Right now, it's not even a Candidate, since there's still work > to be done. I'm fine with that, and you probably can assume to document this goal in the JEP if noone speaks up. > >> Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. > That's good news, though pretty much what I expected. > > I'm more worried about Solaris. Having a goal of JDK 12 may help move > things along. > From Sergey.Bylokhov at oracle.com Wed Oct 17 20:52:37 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 17 Oct 2018 13:52:37 -0700 Subject: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13 Message-ID: Hello. Please review the fix for jdk 12. Bug: https://bugs.openjdk.java.net/browse/JDK-8211992 Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00 This change updates the fix for JDK-8210705[1] and adds one more JNIEXPORT which is requires for splashscreen logic. [1] http://hg.openjdk.java.net/jdk/jdk/rev/8bbb5cbac92c -- Best regards, Sergey. From philip.race at oracle.com Wed Oct 17 20:59:17 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Oct 2018 13:59:17 -0700 Subject: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13 In-Reply-To: References: Message-ID: <03ff40b3-7573-dfe7-919f-b82f06f5975d@oracle.com> Everything in here - except the subject line - points to a completely unrelated bug + fix. I believe you meant : https://bugs.openjdk.java.net/browse/JDK-8212213 http://cr.openjdk.java.net/~serb/8212213/webrev.00/ -phil. On 10/17/2018 01:52 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211992 > Webrev: http://cr.openjdk.java.net/~serb/8211992/webrev.00 > > This change updates the fix for JDK-8210705[1] and adds one more > JNIEXPORT which is requires for splashscreen logic. > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/8bbb5cbac92c > From claes.redestad at oracle.com Wed Oct 17 22:08:40 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 18 Oct 2018 00:08:40 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> Message-ID: <4439b78a-f70c-5fa0-11a4-6cbb14395b98@oracle.com> Hi, added documentation of the new build targets, and synced up with recent changes (thanks Erik for help dealing with some tricky merge conflicts): http://cr.openjdk.java.net/~redestad/8061281/jdk.01/ Thanks! /Claes On 2018-10-09 15:15, Claes Redestad wrote: > Hi, > > please review the initial build support for JEP 230: Microbenchmark > Suite[1]. > > Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 > > There are some added steps to be able to build the microbenchmark suite: > > export JMH_HOME=/path/to/jmh > (mkdir -p $JMH_HOME; cd $JMH_HOME; bash > make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) > bash configure --with-jmh=$JMH_HOME > make build-microbenchmark > > This produces the JMH benchmarks under > build/$CONF_NAME/images/test/micro/microbenchmarks.jar > > There is also support woven into the make run-test target (thanks to > Magnus), allowing for integrated build and test: > > make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi > 2;RESULT_FORMAT=json" > > Remaining tasks before the JEP can be targetted is to write proper > documentation and deciding which microbenchmarks to migrate from > jmh-jdk-microbenchmarks[2]. > > Thanks! > > /Claes > > [1] http://openjdk.java.net/jeps/230 > [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ From Sergey.Bylokhov at oracle.com Wed Oct 17 23:02:09 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 17 Oct 2018 16:02:09 -0700 Subject: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13 In-Reply-To: <03ff40b3-7573-dfe7-919f-b82f06f5975d@oracle.com> References: <03ff40b3-7573-dfe7-919f-b82f06f5975d@oracle.com> Message-ID: <09f6cbfb-45b3-6fc0-313a-5b827c9f7aba@oracle.com> On 17/10/2018 13:59, Phil Race wrote: > Everything in here - except the subject line - points to a completely unrelated bug + fix. > > I believe you meant : > https://bugs.openjdk.java.net/browse/JDK-8212213 > http://cr.openjdk.java.net/~serb/8212213/webrev.00/ O_o.... Right, Thank you for correction! -- Best regards, Sergey. From ekaterina.pavlova at oracle.com Thu Oct 18 06:29:21 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 17 Oct 2018 23:29:21 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing Message-ID: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> Hi All, Please review the changes which add support to build AOTed jdk modules and then use them during the testing. Note, building of AOTed libraries needs to be done at the same machine the testing is going to be started. So, this could not be done at jdk build time. Updated files: - make/RunTests.gmk, make/RunTestsPrebuilt.gmk, make/RunTestsPrebuiltSpec.gmk Main changes which add make procedures and targets to build AOT-ed libraries. New environment variable TEST_OPTS_AOT_MODULES is introduced to specify list of modules to build AOT-ed libraries for. Ex: TEST_OPTS_AOT_MODULES=java.base java.logging - make/conf/jib-profiles.js Added Devkit installation on all platforms required to properly build AOTed libraries. - test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt test/hotspot/jtreg/compiler/aot/scripts/jdk.internal.vm.compiler-list.txt These lists were updated based on latest jaotc errors satus. JBS: https://bugs.openjdk.java.net/browse/JDK-8152988 webrev: http://cr.openjdk.java.net/~epavlova//8152988/webrev.01/ testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler with "make run-test" and in Mach5. thanks, -katya p.s. Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) to new one (make/RunTests*). From shade at redhat.com Thu Oct 18 08:08:56 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Oct 2018 10:08:56 +0200 Subject: Build niceness Message-ID: <3265cff5-88df-c29d-0919-6c4cb1ec0f24@redhat.com> Hi, Is there any specific user story behind "nice"-ing the compilation jobs from within the build system? It unfortunately clashes with priority budgeting. For example, my build server is used by me doing adhoc builds, automatic builds and some background tasks. The automatic build user has priority 10 set in /etc/security/limits.conf. The background user has priority 20 set in limits.conf. In theory, it sounds good: it would get all the CPU ad-hoc builds want, then give CPU to automatic build jobs, then to background jobs. But then the build nice-s the compilation jobs, which drops its priority down to the priority of background jobs: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25966 backgro+ 39 19 808872 460772 2440 R 97.0 1.4 4181:54 R 25968 backgro+ 39 19 808872 460588 2340 R 97.0 1.4 4181:17 R 25965 backgro+ 39 19 808872 460864 2680 R 93.4 1.4 4180:29 R 30998 buildbot 39 19 6688224 1.050g 20000 S 64.8 3.4 4:58.52 java 27518 buildbot 39 19 2915828 110884 21740 S 47.0 0.3 0:02.57 javac 26802 buildbot 39 19 290900 264792 17392 R 38.2 0.8 0:05.48 cc1plus 27486 buildbot 39 19 200296 171792 18440 R 30.6 0.5 0:01.96 cc1plus ...which wrecks up this story. Maybe the better solution in build system is to avoid nice-ing at all, and require users who need it to invoke "nice -n ... make ..."? Or maybe at least have the knob that disables automatic niceness? Thanks, -Aleksey From priya.lakshmi.muthuswamy at oracle.com Thu Oct 18 10:25:19 2018 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Thu, 18 Oct 2018 15:55:19 +0530 Subject: RFR: 8211879 : Broken links in API overview Message-ID: <54f5611b-314a-7c9b-35e2-7eab83683bf2@oracle.com> Hi, Kindly review the fix for https://bugs.openjdk.java.net/browse/JDK-8211879 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8211879/webrev.00/ Thanks, Priya From jonathan.gibbons at oracle.com Thu Oct 18 14:28:42 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 18 Oct 2018 07:28:42 -0700 Subject: RFR: 8211879 : Broken links in API overview In-Reply-To: <54f5611b-314a-7c9b-35e2-7eab83683bf2@oracle.com> References: <54f5611b-314a-7c9b-35e2-7eab83683bf2@oracle.com> Message-ID: <4daff236-41f6-b50d-81fd-368b31e2c952@oracle.com> Looks OK to me. -- Jon On 10/18/18 3:25 AM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review the fix for > https://bugs.openjdk.java.net/browse/JDK-8211879 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8211879/webrev.00/ > > Thanks, > Priya From erik.joelsson at oracle.com Thu Oct 18 15:58:21 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Oct 2018 08:58:21 -0700 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <4439b78a-f70c-5fa0-11a4-6cbb14395b98@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <4439b78a-f70c-5fa0-11a4-6cbb14395b98@oracle.com> Message-ID: <57295928-c109-b47d-df34-117094c1eccd@oracle.com> Looks good to me. /Erik On 2018-10-17 15:08, Claes Redestad wrote: > Hi, > > added documentation of the new build targets, and synced up with > recent changes (thanks Erik for help dealing with some tricky merge > conflicts): > > http://cr.openjdk.java.net/~redestad/8061281/jdk.01/ > > Thanks! > > /Claes > > On 2018-10-09 15:15, Claes Redestad wrote: >> Hi, >> >> please review the initial build support for JEP 230: Microbenchmark >> Suite[1]. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 >> >> There are some added steps to be able to build the microbenchmark suite: >> >> export JMH_HOME=/path/to/jmh >> (mkdir -p $JMH_HOME; cd $JMH_HOME; bash >> make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) >> bash configure --with-jmh=$JMH_HOME >> make build-microbenchmark >> >> This produces the JMH benchmarks under >> build/$CONF_NAME/images/test/micro/microbenchmarks.jar >> >> There is also support woven into the make run-test target (thanks to >> Magnus), allowing for integrated build and test: >> >> make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi >> 2;RESULT_FORMAT=json" >> >> Remaining tasks before the JEP can be targetted is to write proper >> documentation and deciding which microbenchmarks to migrate from >> jmh-jdk-microbenchmarks[2]. >> >> Thanks! >> >> /Claes >> >> [1] http://openjdk.java.net/jeps/230 >> [2] http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ > From erik.joelsson at oracle.com Thu Oct 18 16:02:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Oct 2018 09:02:17 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> Message-ID: Hello, I think this looks good, but since I made most of the makefile changes, I would prefer if Magnus had a look through it too. /Erik On 2018-10-17 23:29, Ekaterina Pavlova wrote: > Hi All, > > Please review the changes which add support to build AOTed jdk modules > and then use them during the testing. > Note, building of AOTed libraries needs to be done at the same machine > the testing is going to be started. > So, this could not be done at jdk build time. > > Updated files: > - make/RunTests.gmk, make/RunTestsPrebuilt.gmk, > make/RunTestsPrebuiltSpec.gmk > > ? Main changes which add make procedures and targets to build AOT-ed > libraries. > ? New environment variable TEST_OPTS_AOT_MODULES is introduced to > specify list of modules to build AOT-ed libraries for. > ? Ex: TEST_OPTS_AOT_MODULES=java.base java.logging > > - make/conf/jib-profiles.js > ? Added Devkit installation on all platforms required to properly > build AOTed libraries. > > - test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt > test/hotspot/jtreg/compiler/aot/scripts/jdk.internal.vm.compiler-list.txt > ? These lists were updated based on latest jaotc errors satus. > > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8152988 > ?webrev: http://cr.openjdk.java.net/~epavlova//8152988/webrev.01/ > testing: Tested by running subset of hotspot, jdk and jck tests with > TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler > ???????? with "make run-test" and in Mach5. > > thanks, > -katya > > p.s. > ?Thanks a lot Erik for huge help with porting original patch done in > old testing framework (test/TestCommon.gmk) > ?to new one (make/RunTests*). > > From erik.joelsson at oracle.com Thu Oct 18 16:03:22 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Oct 2018 09:03:22 -0700 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: <57295928-c109-b47d-df34-117094c1eccd@oracle.com> References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <4439b78a-f70c-5fa0-11a4-6cbb14395b98@oracle.com> <57295928-c109-b47d-df34-117094c1eccd@oracle.com> Message-ID: Note that if the AOT support goes in first, we probably want to extend that support to running micros as well. /Erik On 2018-10-18 08:58, Erik Joelsson wrote: > Looks good to me. > > /Erik > > > On 2018-10-17 15:08, Claes Redestad wrote: >> Hi, >> >> added documentation of the new build targets, and synced up with >> recent changes (thanks Erik for help dealing with some tricky merge >> conflicts): >> >> http://cr.openjdk.java.net/~redestad/8061281/jdk.01/ >> >> Thanks! >> >> /Claes >> >> On 2018-10-09 15:15, Claes Redestad wrote: >>> Hi, >>> >>> please review the initial build support for JEP 230: Microbenchmark >>> Suite[1]. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8061281/jdk.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061281 >>> >>> There are some added steps to be able to build the microbenchmark >>> suite: >>> >>> export JMH_HOME=/path/to/jmh >>> (mkdir -p $JMH_HOME; cd $JMH_HOME; bash >>> make/devkit/createJMHBundle.sh; tar -zxvf jmh-1.21.tar.gz) >>> bash configure --with-jmh=$JMH_HOME >>> make build-microbenchmark >>> >>> This produces the JMH benchmarks under >>> build/$CONF_NAME/images/test/micro/microbenchmarks.jar >>> >>> There is also support woven into the make run-test target (thanks to >>> Magnus), allowing for integrated build and test: >>> >>> make run-test TEST="micro:java.lang.reflect" MICRO="OPTIONS=-f 1 -wi >>> 2;RESULT_FORMAT=json" >>> >>> Remaining tasks before the JEP can be targetted is to write proper >>> documentation and deciding which microbenchmarks to migrate from >>> jmh-jdk-microbenchmarks[2]. >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] http://openjdk.java.net/jeps/230 >>> [2] >>> http://openjdk.java.net/projects/code-tools/jmh-jdk-microbenchmarks/ >> > From erik.joelsson at oracle.com Thu Oct 18 16:08:26 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Oct 2018 09:08:26 -0700 Subject: Build niceness In-Reply-To: <3265cff5-88df-c29d-0919-6c4cb1ec0f24@redhat.com> References: <3265cff5-88df-c29d-0919-6c4cb1ec0f24@redhat.com> Message-ID: <6371582e-5163-3232-c77c-f16f71f72f1d@oracle.com> Hello Aleksey, We very deliberately added the automatic niceness for a better general user experience. This was back when build-infra was new and we started pushing the parallelism of the build to where the UIs of our development systems became annoyingly slow and sluggish when building. So, I would be very against removing it completely, but I certainly think it should be possible to opt out. We should never force such a behavior on an unwilling user. My only defense is that this was done so early so we probably didn't think about it. If you would like to provide a patch adding a configure arg for disabling it, it would certainly be welcome. /Erik On 2018-10-18 01:08, Aleksey Shipilev wrote: > Hi, > > Is there any specific user story behind "nice"-ing the compilation jobs from within the build system? > > It unfortunately clashes with priority budgeting. For example, my build server is used by me doing > adhoc builds, automatic builds and some background tasks. The automatic build user has priority 10 > set in /etc/security/limits.conf. The background user has priority 20 set in limits.conf. In theory, > it sounds good: it would get all the CPU ad-hoc builds want, then give CPU to automatic build jobs, > then to background jobs. > > But then the build nice-s the compilation jobs, which drops its priority down to the priority of > background jobs: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > > 25966 backgro+ 39 19 808872 460772 2440 R 97.0 1.4 4181:54 R > > > 25968 backgro+ 39 19 808872 460588 2340 R 97.0 1.4 4181:17 R > > > 25965 backgro+ 39 19 808872 460864 2680 R 93.4 1.4 4180:29 R > > > 30998 buildbot 39 19 6688224 1.050g 20000 S 64.8 3.4 4:58.52 java > > > 27518 buildbot 39 19 2915828 110884 21740 S 47.0 0.3 0:02.57 javac > > > 26802 buildbot 39 19 290900 264792 17392 R 38.2 0.8 0:05.48 cc1plus > > > 27486 buildbot 39 19 200296 171792 18440 R 30.6 0.5 0:01.96 cc1plus > > ...which wrecks up this story. Maybe the better solution in build system is to avoid nice-ing at > all, and require users who need it to invoke "nice -n ... make ..."? Or maybe at least have the knob > that disables automatic niceness? > > Thanks, > -Aleksey > From erik.joelsson at oracle.com Thu Oct 18 16:09:24 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Oct 2018 09:09:24 -0700 Subject: RFR: 8211879 : Broken links in API overview In-Reply-To: <54f5611b-314a-7c9b-35e2-7eab83683bf2@oracle.com> References: <54f5611b-314a-7c9b-35e2-7eab83683bf2@oracle.com> Message-ID: Looks good. /Erik On 2018-10-18 03:25, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review the fix for > https://bugs.openjdk.java.net/browse/JDK-8211879 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8211879/webrev.00/ > > Thanks, > Priya From magnus.ihse.bursie at oracle.com Thu Oct 18 20:30:40 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 18 Oct 2018 22:30:40 +0200 Subject: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13 In-Reply-To: <09f6cbfb-45b3-6fc0-313a-5b827c9f7aba@oracle.com> References: <03ff40b3-7573-dfe7-919f-b82f06f5975d@oracle.com> <09f6cbfb-45b3-6fc0-313a-5b827c9f7aba@oracle.com> Message-ID: > 18 okt. 2018 kl. 01:02 skrev Sergey Bylokhov : > >> On 17/10/2018 13:59, Phil Race wrote: >> Everything in here - except the subject line - points to a completely unrelated bug + fix. >> I believe you meant : >> https://bugs.openjdk.java.net/browse/JDK-8212213 >> http://cr.openjdk.java.net/~serb/8212213/webrev.00/ LGTM. /Magnus > > O_o.... > > Right, Thank you for correction! > > > > -- > Best regards, Sergey. From philip.race at oracle.com Thu Oct 18 20:57:20 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 18 Oct 2018 13:57:20 -0700 Subject: [12] Review Request: 8212213 All tests for splashscreen stopped worked in jdk12b13 In-Reply-To: References: <03ff40b3-7573-dfe7-919f-b82f06f5975d@oracle.com> <09f6cbfb-45b3-6fc0-313a-5b827c9f7aba@oracle.com> Message-ID: <71a8ff12-88b8-8172-9254-2d3926d818f2@oracle.com> And +1 from me too. -phil. On 10/18/2018 01:30 PM, Magnus Ihse Bursie wrote: >> 18 okt. 2018 kl. 01:02 skrev Sergey Bylokhov : >> >>> On 17/10/2018 13:59, Phil Race wrote: >>> Everything in here - except the subject line - points to a completely unrelated bug + fix. >>> I believe you meant : >>> https://bugs.openjdk.java.net/browse/JDK-8212213 >>> http://cr.openjdk.java.net/~serb/8212213/webrev.00/ > LGTM. > > /Magnus > >> O_o.... >> >> Right, Thank you for correction! >> >> >> >> -- >> Best regards, Sergey. From magnus.ihse.bursie at oracle.com Fri Oct 19 07:21:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Oct 2018 09:21:48 +0200 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> Message-ID: <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> On 2018-10-18 08:29, Ekaterina Pavlova wrote: > Hi All, > > Please review the changes which add support to build AOTed jdk modules > and then use them during the testing. > Note, building of AOTed libraries needs to be done at the same machine > the testing is going to be started. > So, this could not be done at jdk build time. > > Updated files: > - make/RunTests.gmk, make/RunTestsPrebuilt.gmk, > make/RunTestsPrebuiltSpec.gmk > > Main changes which add make procedures and targets to build AOT-ed > libraries. > New environment variable TEST_OPTS_AOT_MODULES is introduced to > specify list of modules to build AOT-ed libraries for. > Ex: TEST_OPTS_AOT_MODULES=java.base java.logging > > - make/conf/jib-profiles.js > Added Devkit installation on all platforms required to properly > build AOTed libraries. > > - test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt > test/hotspot/jtreg/compiler/aot/scripts/jdk.internal.vm.compiler-list.txt > These lists were updated based on latest jaotc errors satus. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8152988 > webrev: http://cr.openjdk.java.net/~epavlova//8152988/webrev.01/ In RunTests.gmk, the following line is repeated: # Note, this could not be done during JDK build time. In the options: $1_JAOTC_OPTS := \ -J-Xmx4g --info \ -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines with too little free memory. Will AOT fail to work with less memory? There's an extra space before the comma here: $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a convenient way to just add "--compile-commands " if it exists? I was a bit confounded at first since normally we only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST to ever be more than one item. About this: # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ $$($1_JVM_OPTIONS) \ -XX:+PrintAOT -XX:AOTLibrary=$$@ -version First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a lot of "java -version" being printed at the time when running tests. Perhaps the output should be redirected? (Assuming that java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this would help otherwise.) Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to be different. E.g: $$(call ExecuteWithLog, $$@_verify, \ $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ ... Further, SetupAot = $(NamedParamsMacroTemplate) define SetupAotBody ifneq ($$($1_MODULES), ) ... If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally called, but does nothing if AOT is not used. I think that looks odd. And here, - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) Finally: + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ I'm not really comfortable with this use of addprefix. I think a construct like: ifneq ($$($1_AOT_OPTIONS), ) $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) endif would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but that's not as important. The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) /Magnus > testing: Tested by running subset of hotspot, jdk and jck tests with > TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler > with "make run-test" and in Mach5. > > thanks, > -katya > > p.s. > Thanks a lot Erik for huge help with porting original patch done in > old testing framework (test/TestCommon.gmk) > to new one (make/RunTests*). > > From claes.redestad at oracle.com Fri Oct 19 11:57:19 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 19 Oct 2018 13:57:19 +0200 Subject: RFR: 8061281: Microbenchmark suite build support, directory layout and sample benchmarks In-Reply-To: References: <205ebfc0-8eca-9a6b-9f47-47bd45e054ed@oracle.com> <4439b78a-f70c-5fa0-11a4-6cbb14395b98@oracle.com> <57295928-c109-b47d-df34-117094c1eccd@oracle.com> Message-ID: <1e7d94db-3b4e-1034-5a59-e616abd4b1bc@oracle.com> On 2018-10-18 18:03, Erik Joelsson wrote: > Note that if the AOT support goes in first, we probably want to extend > that support to running micros as well. We can do that as a follow up, depending on how much work it is. In the meantime, I updated the patch to use JAVA rather than JAVA_SMALL for compilation (JAVA_SMALL cause OOMEs when adding more micros) and by request updated the license of the microbenchmarks to use a plain GPLv2 license. http://cr.openjdk.java.net/~redestad/8061281/jdk.02/ Thanks! /Claes From magnus.ihse.bursie at oracle.com Fri Oct 19 12:32:53 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 19 Oct 2018 14:32:53 +0200 Subject: RFR: JDK-8210958 Rename "make run-test" to "make test" In-Reply-To: <52043217-40a9-9508-8cdf-7ac7ad4178a3@oracle.com> References: <52043217-40a9-9508-8cdf-7ac7ad4178a3@oracle.com> Message-ID: <411fd7f7-fa61-f827-c898-a5a4929abedf@oracle.com> Now that JDK-8212028 is pushed, it's time to revisit this. In the meantime, the compile-command test had been added, which caused me to realize some better handling of the make tests were needed. These fixes are also included. Now "make test-make" will run all build system tests with proper dependencies. I also fixed a test in TestMakeBase.gmk which became broken with JDK-8212028. Updated webrev: http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.02 /Magnus On 2018-09-20 12:47, Magnus Ihse Bursie wrote: > The time has come to start phasing out the old test running framework > ("cd test && make"). This patch will change the behavior of "make > test" to use the new run-test framework, instead of the old. > > The old framework is still available as of now by using "cd test && > make". > > The "run-test" target (and variants like exploded-run-test or > run-test-tier1) are kept as aliases. > > Using "cd test && make" will result in a warning being printed that it > is recommended to stop using this way of running tests. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210958 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Fri Oct 19 16:04:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 19 Oct 2018 09:04:25 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> Message-ID: <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> Hello, I will answer the parts I'm responsible for. On 2018-10-19 00:21, Magnus Ihse Bursie wrote: > > In RunTests.gmk, the following line is repeated: > # Note, this could not be done during JDK build time. > > In the options: > $1_JAOTC_OPTS := \ > -J-Xmx4g --info \ > -Xmx4g is huge, much larger than what we typically use. Is this > intentional? This will risk crashing at machines with too little free > memory. Will AOT fail to work with less memory? > > > There's an extra space before the comma here: > $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ > Question (to Erik, I presume): the idea of addprefix here is that > AOT_CCLIST can be empty, and this was a convenient way to just add > "--compile-commands " if it exists? I was a bit > confounded at first since normally we only use it for distributing a > prefix over multiple items, and I could see no way for AOT_CCLIST to > ever be more than one item. > Yes, that was the intention. I often use addprefix that way and find it convenient that it seamlessly handles 0-N number of elements in the argument without the need for cumbersome conditionals. The extra space is needed in this case but should perhaps be explicit using $(SPACE). > > About this: > # Note, ExecuteWithLog doesn't play well with with two calls in the > same recipe. > $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT > -XX:AOTLibrary=$$@ -version) > $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ > $$($1_JVM_OPTIONS) \ > -XX:+PrintAOT -XX:AOTLibrary=$$@ -version > First, what is the purpose of this? Is it to verify that the generated > AOT library works? This will result in a lot of "java -version" being > printed at the time when running tests. Perhaps the output should be > redirected? (Assuming that java exists with a non-zero exit value if > things fail, but if it does not, I'm not sure how this would help > otherwise.) > My guess is that they want diagnostics saved in case tests fail. > Second, there's no problem to use multiple ExecuteWithLog in the same > recipe, however, the base variable needs to be different. E.g: > $$(call ExecuteWithLog, $$@_verify, \ > $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ > ... > The issue I'm referring to is that the $(info) line in ExecuteWithLog will print the commands first, then execute the first line of the recipe. This makes the output confusing since both of those commands print (what I'm assuming is) relevant diagnostics information. This is simply a consequence of using $(info) for printing the command line. Make will evaluate all the recipe lines first, then execute them one by one. To be clear, it ends up like this: Executing [jaotc ...] Executing [java ...] > > Further, > SetupAot = $(NamedParamsMacroTemplate) > define SetupAotBody > ifneq ($$($1_MODULES), ) > ... > If think it would be clearer if the if-test is on the call site for > SetupAot instead. Now it's unconditionally called, but does nothing if > AOT is not used. I think that looks odd. > My goal was to minimize the repeated code at each call site. While developing this, I had a lot more duplication at first, and it was a hassle to update each location every time I needed to change something. Other than that I don't feel strongly for either construct. > > And here, > - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) > + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) > I don't think you can just remove TEST_PREREQS like that..? (The same > goes for the other run-test-$1 instance.) > I added the TEST_PREREQS variable to support the CDS archive generation, which was recently removed. With the way SetupAot turned out to need separate calls from each SetupTestRun, the global TEST_PREREQS wasn't suitable. I don't know of any current need for a general TEST_PREREQS. > > Finally: > + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ > I'm not really comfortable with this use of addprefix. I think a > construct like: > ifneq ($$($1_AOT_OPTIONS), ) > $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) > endif > would be much clearar. Ideally, I'd like to see the same construct in > the SetupAotModule function as well, but that's not as important. > I agree. /Erik > > The rest of the build changes look good. (I can't say anything about > the test/**/*-list.txt files.) > > /Magnus > >> testing: Tested by running subset of hotspot, jdk and jck tests with >> TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler >> ???????? with "make run-test" and in Mach5. >> >> thanks, >> -katya >> >> p.s. >> ?Thanks a lot Erik for huge help with porting original patch done in >> old testing framework (test/TestCommon.gmk) >> ?to new one (make/RunTests*). >> >> > From erik.joelsson at oracle.com Fri Oct 19 16:11:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 19 Oct 2018 09:11:36 -0700 Subject: RFR: JDK-8210958 Rename "make run-test" to "make test" In-Reply-To: <411fd7f7-fa61-f827-c898-a5a4929abedf@oracle.com> References: <52043217-40a9-9508-8cdf-7ac7ad4178a3@oracle.com> <411fd7f7-fa61-f827-c898-a5a4929abedf@oracle.com> Message-ID: Looks good, and thanks for fixing test-make. I found the same issue today. Could you also change the make target we call for run-test/run-test-prebuilt profiles in jib-profiles.js? /Erik On 2018-10-19 05:32, Magnus Ihse Bursie wrote: > Now that JDK-8212028 is pushed, it's time to revisit this. > > In the meantime, the compile-command test had been added, which caused > me to realize some better handling of the make tests were needed. > These fixes are also included. Now "make test-make" will run all build > system tests with proper dependencies. > > I also fixed a test in TestMakeBase.gmk which became broken with > JDK-8212028. > > Updated webrev: > http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.02 > > > /Magnus > > > On 2018-09-20 12:47, Magnus Ihse Bursie wrote: >> The time has come to start phasing out the old test running framework >> ("cd test && make"). This patch will change the behavior of "make >> test" to use the new run-test framework, instead of the old. >> >> The old framework is still available as of now by using "cd test && >> make". >> >> The "run-test" target (and variants like exploded-run-test or >> run-test-tier1) are kept as aliases. >> >> Using "cd test && make" will result in a warning being printed that >> it is recommended to stop using this way of running tests. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210958 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.01 >> >> /Magnus >> > From vladimir.kozlov at oracle.com Fri Oct 19 17:40:19 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 19 Oct 2018 10:40:19 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> Message-ID: <9679369c-e159-feef-ccc7-f2f72ff5b1d7@oracle.com> I share concern about output of -XX:+PrintAOT - it prints all AOT classes and methods. For AOTed java.base the output will be almost the same for all tests (depends which are java.base classes are used). I would suggest instead to use -XX:+UseAOTStrictLoading which exit(1) VM if it can't load AOT library for some reason (mismatched configuration - different GCs). Also -Xlog:aot+class+fingerprint=trace to trace cases of mismatching class fingerprint. Also -Xlog:aot+class+load=trace -to trace AOT class loading or skipping them if they are not matching. And I agree to redirect this into file. Thanks, Vladimir On 10/19/18 9:04 AM, Erik Joelsson wrote: > Hello, > > I will answer the parts I'm responsible for. > > On 2018-10-19 00:21, Magnus Ihse Bursie wrote: >> >> In RunTests.gmk, the following line is repeated: >> # Note, this could not be done during JDK build time. >> >> In the options: >> $1_JAOTC_OPTS := \ >> -J-Xmx4g --info \ >> -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines with >> too little free memory. Will AOT fail to work with less memory? >> >> >> There's an extra space before the comma here: >> $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ >> Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a convenient >> way to just add "--compile-commands " if it exists? I was a bit confounded at first since normally we >> only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST to ever be more than >> one item. >> > Yes, that was the intention. I often use addprefix that way and find it convenient that it seamlessly handles 0-N number > of elements in the argument without the need for cumbersome conditionals. The extra space is needed in this case but > should perhaps be explicit using $(SPACE). >> >> About this: >> # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. >> $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) >> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >> $$($1_JVM_OPTIONS) \ >> -XX:+PrintAOT -XX:AOTLibrary=$$@ -version >> First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a lot of >> "java -version" being printed at the time when running tests. Perhaps the output should be redirected? (Assuming that >> java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this would help otherwise.) >> > My guess is that they want diagnostics saved in case tests fail. >> Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to be >> different. E.g: >> $$(call ExecuteWithLog, $$@_verify, \ >> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >> ... >> > The issue I'm referring to is that the $(info) line in ExecuteWithLog will print the commands first, then execute the > first line of the recipe. This makes the output confusing since both of those commands print (what I'm assuming is) > relevant diagnostics information. This is simply a consequence of using $(info) for printing the command line. Make will > evaluate all the recipe lines first, then execute them one by one. To be clear, it ends up like this: > > Executing [jaotc ...] > Executing [java ...] > > >> >> Further, >> SetupAot = $(NamedParamsMacroTemplate) >> define SetupAotBody >> ifneq ($$($1_MODULES), ) >> ... >> If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally called, >> but does nothing if AOT is not used. I think that looks odd. >> > My goal was to minimize the repeated code at each call site. While developing this, I had a lot more duplication at > first, and it was a hassle to update each location every time I needed to change something. Other than that I don't feel > strongly for either construct. >> >> And here, >> - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) >> + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) >> I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) >> > I added the TEST_PREREQS variable to support the CDS archive generation, which was recently removed. With the way > SetupAot turned out to need separate calls from each SetupTestRun, the global TEST_PREREQS wasn't suitable. I don't know > of any current need for a general TEST_PREREQS. >> >> Finally: >> + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ >> I'm not really comfortable with this use of addprefix. I think a construct like: >> ifneq ($$($1_AOT_OPTIONS), ) >> $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) >> endif >> would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but that's >> not as important. >> > I agree. > > /Erik >> >> The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) >> >> /Magnus >> >>> testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base >>> jdk.internal.vm.compiler >>> ???????? with "make run-test" and in Mach5. >>> >>> thanks, >>> -katya >>> >>> p.s. >>> ?Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) >>> ?to new one (make/RunTests*). >>> >>> >> > From ekaterina.pavlova at oracle.com Mon Oct 22 16:36:04 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 22 Oct 2018 09:36:04 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <9679369c-e159-feef-ccc7-f2f72ff5b1d7@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> <9679369c-e159-feef-ccc7-f2f72ff5b1d7@oracle.com> Message-ID: Vladimir, thanks a lot for the review. "-XX:+PrintAOT" was only passed to "java -version" which is done before the testing to verify that AOTed libraries work. It also perhaps could be useful debug info in case some tests starts fail. But I can change -XX:+PrintAOT to -XX:+UseAOTStrictLoading if you think it is more than enough. Do you suggest to add "-Xlog:aot+class+fingerprint=trace -Xlog:aot+class+load=trace" to "java -version" only or to java flags used during tests execution as well? -katya On 10/19/18 10:40 AM, Vladimir Kozlov wrote: > I share concern about output of -XX:+PrintAOT - it prints all AOT classes and methods. For AOTed java.base the output will be almost the same for all tests (depends which are java.base classes are used). > > I would suggest instead to use -XX:+UseAOTStrictLoading which exit(1) VM if it can't load AOT library for some reason (mismatched configuration - different GCs). > > Also -Xlog:aot+class+fingerprint=trace? to trace cases of mismatching class fingerprint. > Also -Xlog:aot+class+load=trace -to trace AOT class loading or skipping them if they are not matching. > > And I agree to redirect this into file. > > Thanks, > Vladimir > > On 10/19/18 9:04 AM, Erik Joelsson wrote: >> Hello, >> >> I will answer the parts I'm responsible for. >> >> On 2018-10-19 00:21, Magnus Ihse Bursie wrote: >>> >>> In RunTests.gmk, the following line is repeated: >>> # Note, this could not be done during JDK build time. >>> >>> In the options: >>> $1_JAOTC_OPTS := \ >>> -J-Xmx4g --info \ >>> -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines with too little free memory. Will AOT fail to work with less memory? >>> >>> >>> There's an extra space before the comma here: >>> $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ >>> Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a convenient way to just add "--compile-commands " if it exists? I was a bit confounded at first since normally we only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST to ever be more than one item. >>> >> Yes, that was the intention. I often use addprefix that way and find it convenient that it seamlessly handles 0-N number of elements in the argument without the need for cumbersome conditionals. The extra space is needed in this case but should perhaps be explicit using $(SPACE). >>> >>> About this: >>> # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. >>> $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) >>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>> $$($1_JVM_OPTIONS) \ >>> -XX:+PrintAOT -XX:AOTLibrary=$$@ -version >>> First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a lot of "java -version" being printed at the time when running tests. Perhaps the output should be redirected? (Assuming that java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this would help otherwise.) >>> >> My guess is that they want diagnostics saved in case tests fail. >>> Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to be different. E.g: >>> $$(call ExecuteWithLog, $$@_verify, \ >>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>> ??????? ... >>> >> The issue I'm referring to is that the $(info) line in ExecuteWithLog will print the commands first, then execute the first line of the recipe. This makes the output confusing since both of those commands print (what I'm assuming is) relevant diagnostics information. This is simply a consequence of using $(info) for printing the command line. Make will evaluate all the recipe lines first, then execute them one by one. To be clear, it ends up like this: >> >> Executing [jaotc ...] >> Executing [java ...] >> >> >>> >>> Further, >>> SetupAot = $(NamedParamsMacroTemplate) >>> define SetupAotBody >>> ifneq ($$($1_MODULES), ) >>> ... >>> If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally called, but does nothing if AOT is not used. I think that looks odd. >>> >> My goal was to minimize the repeated code at each call site. While developing this, I had a lot more duplication at first, and it was a hassle to update each location every time I needed to change something. Other than that I don't feel strongly for either construct. >>> >>> And here, >>> - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) >>> + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) >>> I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) >>> >> I added the TEST_PREREQS variable to support the CDS archive generation, which was recently removed. With the way SetupAot turned out to need separate calls from each SetupTestRun, the global TEST_PREREQS wasn't suitable. I don't know of any current need for a general TEST_PREREQS. >>> >>> Finally: >>> + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ >>> I'm not really comfortable with this use of addprefix. I think a construct like: >>> ifneq ($$($1_AOT_OPTIONS), ) >>> ?? $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) >>> endif >>> would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but that's not as important. >>> >> I agree. >> >> /Erik >>> >>> The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) >>> >>> /Magnus >>> >>>> testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler >>>> ???????? with "make run-test" and in Mach5. >>>> >>>> thanks, >>>> -katya >>>> >>>> p.s. >>>> ?Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) >>>> ?to new one (make/RunTests*). >>>> >>>> >>> >> From ekaterina.pavlova at oracle.com Mon Oct 22 16:41:48 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 22 Oct 2018 09:41:48 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> Message-ID: Magnus, thanks a lot for your review. Regarding "-J-Xmx4g --info". This is done intentionally. AOT requires more heap usage and could fail with OOM otherwise. I specify "mem.total" in AOT jobs definitions so AOT testing is done only on machines which has at least 4gb. -katya On 10/19/18 12:21 AM, Magnus Ihse Bursie wrote: > On 2018-10-18 08:29, Ekaterina Pavlova wrote: > >> Hi All, >> >> Please review the changes which add support to build AOTed jdk modules and then use them during the testing. >> Note, building of AOTed libraries needs to be done at the same machine the testing is going to be started. >> So, this could not be done at jdk build time. >> >> Updated files: >> - make/RunTests.gmk, make/RunTestsPrebuilt.gmk, make/RunTestsPrebuiltSpec.gmk >> >> ? Main changes which add make procedures and targets to build AOT-ed libraries. >> ? New environment variable TEST_OPTS_AOT_MODULES is introduced to specify list of modules to build AOT-ed libraries for. >> ? Ex: TEST_OPTS_AOT_MODULES=java.base java.logging >> >> - make/conf/jib-profiles.js >> ? Added Devkit installation on all platforms required to properly build AOTed libraries. >> >> - test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt >> test/hotspot/jtreg/compiler/aot/scripts/jdk.internal.vm.compiler-list.txt >> ? These lists were updated based on latest jaotc errors satus. >> >> >> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8152988 >> ?webrev: http://cr.openjdk.java.net/~epavlova//8152988/webrev.01/ > > In RunTests.gmk, the following line is repeated: > > # Note, this could not be done during JDK build time. > > > In the options: > > $1_JAOTC_OPTS := \ > -J-Xmx4g --info \ > > -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines with too little free memory. Will AOT fail to work with less memory? > > > There's an extra space before the comma here: > > $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ > > Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a convenient way to just add "--compile-commands " if it exists? I was a bit confounded at first since normally we only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST to ever be more than one item. > > > About this: > > # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. > $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) > $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ > $$($1_JVM_OPTIONS) \ > -XX:+PrintAOT -XX:AOTLibrary=$$@ -version > > First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a lot of "java -version" being printed at the time when running tests. Perhaps the output should be redirected? (Assuming that java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this would help otherwise.) > > Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to be different. E.g: > > $$(call ExecuteWithLog, $$@_verify, \ > $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ > ... > > > > Further, > > SetupAot = $(NamedParamsMacroTemplate) > define SetupAotBody > ifneq ($$($1_MODULES), ) > ... > > If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally called, but does nothing if AOT is not used. I think that looks odd. > > > And here, > > - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) > + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) > > I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) > > > Finally: > > + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ > > I'm not really comfortable with this use of addprefix. I think a construct like: > > ifneq ($$($1_AOT_OPTIONS), ) > $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) > endif > > would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but that's not as important. > > > The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) > > /Magnus > >> testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler >> ???????? with "make run-test" and in Mach5. >> >> thanks, >> -katya >> >> p.s. >> ?Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) >> ?to new one (make/RunTests*). >> >> > From magnus.ihse.bursie at oracle.com Tue Oct 23 08:45:27 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 23 Oct 2018 10:45:27 +0200 Subject: RFR: JDK-8210958 Rename "make run-test" to "make test" In-Reply-To: References: <52043217-40a9-9508-8cdf-7ac7ad4178a3@oracle.com> <411fd7f7-fa61-f827-c898-a5a4929abedf@oracle.com> Message-ID: <5585e05f-d68b-69d6-36a3-75448c030434@oracle.com> On 2018-10-19 18:11, Erik Joelsson wrote: > Looks good, and thanks for fixing test-make. I found the same issue > today. > > Could you also change the make target we call for > run-test/run-test-prebuilt profiles in jib-profiles.js? There's no target for run-test in jib-profiles.js; only for run-test-prebuilt (as far as I can understand, at least). I've updated this, and I also renamed all references to "run-test" to just "test". Maybe this was going too far. Let me know if you want me to revert that part. Updated webrev (only jib-profiles.js has changed): http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.03 /Magnus > > /Erik > > > On 2018-10-19 05:32, Magnus Ihse Bursie wrote: >> Now that JDK-8212028 is pushed, it's time to revisit this. >> >> In the meantime, the compile-command test had been added, which >> caused me to realize some better handling of the make tests were >> needed. These fixes are also included. Now "make test-make" will run >> all build system tests with proper dependencies. >> >> I also fixed a test in TestMakeBase.gmk which became broken with >> JDK-8212028. >> >> Updated webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.02 >> >> >> /Magnus >> >> >> On 2018-09-20 12:47, Magnus Ihse Bursie wrote: >>> The time has come to start phasing out the old test running >>> framework ("cd test && make"). This patch will change the behavior >>> of "make test" to use the new run-test framework, instead of the old. >>> >>> The old framework is still available as of now by using "cd test && >>> make". >>> >>> The "run-test" target (and variants like exploded-run-test or >>> run-test-tier1) are kept as aliases. >>> >>> Using "cd test && make" will result in a warning being printed that >>> it is recommended to stop using this way of running tests. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210958 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.01 >>> >>> /Magnus >>> >> > From ekaterina.pavlova at oracle.com Tue Oct 23 20:33:06 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 23 Oct 2018 13:33:06 -0700 Subject: RFR(XXS) 8212877: Restore JTREG_VERBOSE value for mach5 testing Message-ID: <1b9d9025-25a6-e696-3454-f63880a839b7@oracle.com> Hi All, Please review this extra small change which restores JTREG_VERBOSE value for mach5 testing. Default JTREG_VERBOSE value was changed from "fail,error,time" to "fail,error,summary" after switching to run-test framework (JDK-8212028). Having compact tests output is good for local users while mach5 testing will benefits from providing more test execution information. Specially having test time execution data helps to analyze any tests/jobs slowness. JBS: https://bugs.openjdk.java.net/browse/JDK-8212877 webrev: http://cr.openjdk.java.net/~epavlova//8212877/webrev.00/index.html testing: tested by launching jobs in Mach5 thanks, -katya From david.holmes at oracle.com Tue Oct 23 22:04:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Oct 2018 08:04:12 +1000 Subject: RFR(XXS) 8212877: Restore JTREG_VERBOSE value for mach5 testing In-Reply-To: <1b9d9025-25a6-e696-3454-f63880a839b7@oracle.com> References: <1b9d9025-25a6-e696-3454-f63880a839b7@oracle.com> Message-ID: <8b4adc83-0dc1-cccc-a30e-4cc3fa40f997@oracle.com> LGTM. Thanks, David On 24/10/2018 6:33 AM, Ekaterina Pavlova wrote: > Hi All, > > Please review this extra small change which restores JTREG_VERBOSE value > for mach5 testing. > > Default JTREG_VERBOSE value was changed from "fail,error,time" to > "fail,error,summary" after switching to run-test framework (JDK-8212028). > Having compact tests output is good for local users while mach5 testing > will benefits from providing more test execution information. > Specially having test time execution data helps to analyze any > tests/jobs slowness. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8212877 > ?webrev: > http://cr.openjdk.java.net/~epavlova//8212877/webrev.00/index.html > testing: tested by launching jobs in Mach5 > > thanks, > -katya From jonathan.gibbons at oracle.com Tue Oct 23 22:14:17 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 23 Oct 2018 15:14:17 -0700 Subject: RFR(XXS) 8212877: Restore JTREG_VERBOSE value for mach5 testing In-Reply-To: <1b9d9025-25a6-e696-3454-f63880a839b7@oracle.com> References: <1b9d9025-25a6-e696-3454-f63880a839b7@oracle.com> Message-ID: Without commenting on the merits of this proposed change, I note that the test execution time is always available in the .jtr files, which is probably a better place to get the info than scraping the log output. -- Jon On 10/23/18 1:33 PM, Ekaterina Pavlova wrote: > Hi All, > > Please review this extra small change which restores JTREG_VERBOSE > value for mach5 testing. > > Default JTREG_VERBOSE value was changed from "fail,error,time" to > "fail,error,summary" after switching to run-test framework (JDK-8212028). > Having compact tests output is good for local users while mach5 > testing will benefits from providing more test execution information. > Specially having test time execution data helps to analyze any > tests/jobs slowness. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8212877 > ?webrev: > http://cr.openjdk.java.net/~epavlova//8212877/webrev.00/index.html > testing: tested by launching jobs in Mach5 > > thanks, > -katya From vladimir.kozlov at oracle.com Tue Oct 23 23:40:39 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 23 Oct 2018 16:40:39 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> <9679369c-e159-feef-ccc7-f2f72ff5b1d7@oracle.com> Message-ID: <62df0d36-014a-0d4e-fd1b-b014736452a9@oracle.com> On 10/22/18 9:36 AM, Ekaterina Pavlova wrote: > Vladimir, > > thanks a lot for the review. > "-XX:+PrintAOT" was only passed to "java -version" which is done before the testing to verify that AOTed libraries work. If it is only for -version then using -XX:+PrintAOT is okay. > It also perhaps could be useful debug info in case some tests starts fail. > But I can change -XX:+PrintAOT to -XX:+UseAOTStrictLoading if you think it is more than enough. -XX:+UseAOTStrictLoading is more important for tests which have different flags specified and may invalidate AOTLibrary configuration. We would want to catch tests which will not use AOT libraries. At least when we test these your changes. > > Do you suggest to add "-Xlog:aot+class+fingerprint=trace -Xlog:aot+class+load=trace" to "java -version" only > or to java flags used during tests execution as well? These options are next step after -XX:+UseAOTStrictLoading. We were asked before how we can guarantee that AOTed methods are used by tests. One way is PrintAOT which should show published AOT methods. An other way is Xlogs flags which have less output but provide at least some level of information that AOTed classes are used and not skipped. Thanks, Vladimir > > > -katya > > On 10/19/18 10:40 AM, Vladimir Kozlov wrote: >> I share concern about output of -XX:+PrintAOT - it prints all AOT classes and methods. For AOTed java.base the output >> will be almost the same for all tests (depends which are java.base classes are used). >> >> I would suggest instead to use -XX:+UseAOTStrictLoading which exit(1) VM if it can't load AOT library for some reason >> (mismatched configuration - different GCs). >> >> Also -Xlog:aot+class+fingerprint=trace? to trace cases of mismatching class fingerprint. >> Also -Xlog:aot+class+load=trace -to trace AOT class loading or skipping them if they are not matching. >> >> And I agree to redirect this into file. >> >> Thanks, >> Vladimir >> >> On 10/19/18 9:04 AM, Erik Joelsson wrote: >>> Hello, >>> >>> I will answer the parts I'm responsible for. >>> >>> On 2018-10-19 00:21, Magnus Ihse Bursie wrote: >>>> >>>> In RunTests.gmk, the following line is repeated: >>>> # Note, this could not be done during JDK build time. >>>> >>>> In the options: >>>> $1_JAOTC_OPTS := \ >>>> -J-Xmx4g --info \ >>>> -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines >>>> with too little free memory. Will AOT fail to work with less memory? >>>> >>>> >>>> There's an extra space before the comma here: >>>> $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ >>>> Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a convenient >>>> way to just add "--compile-commands " if it exists? I was a bit confounded at first since normally we >>>> only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST to ever be more >>>> than one item. >>>> >>> Yes, that was the intention. I often use addprefix that way and find it convenient that it seamlessly handles 0-N >>> number of elements in the argument without the need for cumbersome conditionals. The extra space is needed in this >>> case but should perhaps be explicit using $(SPACE). >>>> >>>> About this: >>>> # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. >>>> $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) >>>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>>> $$($1_JVM_OPTIONS) \ >>>> -XX:+PrintAOT -XX:AOTLibrary=$$@ -version >>>> First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a lot >>>> of "java -version" being printed at the time when running tests. Perhaps the output should be redirected? (Assuming >>>> that java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this would help >>>> otherwise.) >>>> >>> My guess is that they want diagnostics saved in case tests fail. >>>> Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to be >>>> different. E.g: >>>> $$(call ExecuteWithLog, $$@_verify, \ >>>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>>> ??????? ... >>>> >>> The issue I'm referring to is that the $(info) line in ExecuteWithLog will print the commands first, then execute the >>> first line of the recipe. This makes the output confusing since both of those commands print (what I'm assuming is) >>> relevant diagnostics information. This is simply a consequence of using $(info) for printing the command line. Make >>> will evaluate all the recipe lines first, then execute them one by one. To be clear, it ends up like this: >>> >>> Executing [jaotc ...] >>> Executing [java ...] >>> >>> >>>> >>>> Further, >>>> SetupAot = $(NamedParamsMacroTemplate) >>>> define SetupAotBody >>>> ifneq ($$($1_MODULES), ) >>>> ... >>>> If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally >>>> called, but does nothing if AOT is not used. I think that looks odd. >>>> >>> My goal was to minimize the repeated code at each call site. While developing this, I had a lot more duplication at >>> first, and it was a hassle to update each location every time I needed to change something. Other than that I don't >>> feel strongly for either construct. >>>> >>>> And here, >>>> - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) >>>> + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) >>>> I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) >>>> >>> I added the TEST_PREREQS variable to support the CDS archive generation, which was recently removed. With the way >>> SetupAot turned out to need separate calls from each SetupTestRun, the global TEST_PREREQS wasn't suitable. I don't >>> know of any current need for a general TEST_PREREQS. >>>> >>>> Finally: >>>> + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ >>>> I'm not really comfortable with this use of addprefix. I think a construct like: >>>> ifneq ($$($1_AOT_OPTIONS), ) >>>> ?? $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) >>>> endif >>>> would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but >>>> that's not as important. >>>> >>> I agree. >>> >>> /Erik >>>> >>>> The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) >>>> >>>> /Magnus >>>> >>>>> testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base >>>>> jdk.internal.vm.compiler >>>>> ???????? with "make run-test" and in Mach5. >>>>> >>>>> thanks, >>>>> -katya >>>>> >>>>> p.s. >>>>> ?Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) >>>>> ?to new one (make/RunTests*). >>>>> >>>>> >>>> >>> > From Alan.Bateman at oracle.com Wed Oct 24 14:22:55 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Oct 2018 15:22:55 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: On 23/10/2018 16:49, Andy Herrick wrote: > This patch implements the Java Packager Tool (jpackager) as described > in JEP 343: Packaging Tool > > > jpackager is a simple packaging tool, based on the JavaFX > |javapackager| tool, that: > > ?* Supports native packaging formats to give the end user a natural > ?? installation experience. These formats include |msi| and |exe| on > ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. > ?* Allows launch-time parameters to be specified at packaging time. > ?* Can be invoked directly, from the command line, or programmatically, > ?? via the |ToolProvider| API. > > Webrev: > > http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ > cc'ing build-dev as it's important to get it reviewed there. What is the plan for tests to go with this tool? I see there is one test in the webrev to do some argument validation but I don't see anything else right now. What is the status of the JNLPConverter tool? I see it is included as a "demo" but maybe it would be better to host somewhere else as this is for developers migrating Java Web Start applications. Would it be possible to update the JEP with all the CLI options? That would be useful for review and also useful for those invoking it with the ToolProvider API. If I read the webrev correctly then it adds two modules, one with the jpackager tool and the other with an API. It would be useful to get a bit more information on the split. Also I think the name of the API module and the package that it exports needs discussion to make sure that the right names are chosen. -Alan From erik.joelsson at oracle.com Wed Oct 24 17:18:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 24 Oct 2018 10:18:41 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: <756780e6-78ab-5759-7f7a-63f00f1e3feb@oracle.com> Hello, Nice to see this finally happening! Are we actually adding a new demo? I thought we were working towards getting rid of the demos completely. CompileJavaModules.gmk: The jdk.packager_CLEAN_FILES could be replaced with a simple "jdk.packager_CLEAN := .properties" unless you actually need to add all the platform specific files to builds for all platforms (which I doubt?). To clarify, the current patch will add all linux, windows and mac properties to builds of all OSes. Is that intended? Modules.gmk: I would rather have the filter be conditional on an inclusive list of platforms. Other OpenJDK contributors are building for other OSes like AIX and we don't want to have to keep track of all those. The list of OSes that jpackager supports is well defined, so better check for those explicitly. src/jdk.jlink/share/classes/module-info.java: I believe the qualified export needs to be put in a module-info.java.extra file since we filter out the target module on unsupported platforms. Launcher-jdk.packager.gmk: * Please use $$(call FindExecutableDirForModule, $$(MODULE)) for the DEST dir in the copy. * Please adjust the indentation of the big windows/else blocks. We indent everything with 2 spaces in conditional blocks. * A minor style nit on the copy-and-chmod macro, since it's meant to be used as a recipe, we usually indent those with tabs to indicate that they are recipe lines, in this case, one tab is enough even though the surrounding define should be indented with 2 spaces (don't combine tab and spaces here). * The (new) SetupJdkExecutable macro handles VERSIONINFO_RESOURCE automatically for you unless you have specific needs. This looks like the defaults should be fine. * Since this is just for windows, the TOOLCHAIN_LINK_CXX should not make any difference. (It's only needed for GCC to force linking with g++ instead of gcc) So please remove. * You could consider using FindSrcDirsForComponent for the src dir. Lib-jdk.packager.gmk: * The native source files are not organized according to the standards introduced with JEP 201. If they were, most of these SetupJdkLibrary calls would automatically find the correct sources. I realize there is a special case for the windows papplauncherc executable as it's built from the same sources as papplauncher, so that will need a special case. Building of the executables should be moved to Launcher-jdk.packager.gmk however. * Why are you changing the build output dir and copying debuginfo files around? We have a standard way of building and places where files are put. If that is not working for you, we need to fix it on a global level. Having each native library being built differently is not good for maintainability. * VERSIONINFO_RESOURCE is handled automatically so does not need to be specified. * Please indent the full contents of logic blocks with 2 spaces. Not having proper indents makes it much harder to read the code. * Several lines are too long for future side by side comparisons, please break them up. You can use the # lines as a soft guidance. /Erik On 2018-10-24 07:22, Alan Bateman wrote: > On 23/10/2018 16:49, Andy Herrick wrote: >> This patch implements the Java Packager Tool (jpackager) as described >> in JEP 343: Packaging Tool >> >> >> jpackager is a simple packaging tool, based on the JavaFX >> |javapackager| tool, that: >> >> ?* Supports native packaging formats to give the end user a natural >> ?? installation experience. These formats include |msi| and |exe| on >> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >> ?* Allows launch-time parameters to be specified at packaging time. >> ?* Can be invoked directly, from the command line, or programmatically, >> ?? via the |ToolProvider| API. >> >> Webrev: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >> > cc'ing build-dev as it's important to get it reviewed there. > > What is the plan for tests to go with this tool? I see there is one > test in the webrev to do some argument validation but I don't see > anything else right now. > > What is the status of the JNLPConverter tool? I see it is included as > a "demo" but maybe it would be better to host somewhere else as this > is for developers migrating Java Web Start applications. > > Would it be possible to update the JEP with all the CLI options? That > would be useful for review and also useful for those invoking it with > the ToolProvider API. > > If I read the webrev correctly then it adds two modules, one with the > jpackager tool and the other with an API. It would be useful to get a > bit more information on the split. Also I think the name of the API > module and the package that it exports needs discussion to make sure > that the right names are chosen. > > -Alan From ekaterina.pavlova at oracle.com Wed Oct 24 18:24:32 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 24 Oct 2018 11:24:32 -0700 Subject: RFR(XXS) 8212877: Restore JTREG_VERBOSE value for mach5 testing In-Reply-To: <8b4adc83-0dc1-cccc-a30e-4cc3fa40f997@oracle.com> References: <1b9d9025-25a6-e696-3454-f63880a839b7@oracle.com> <8b4adc83-0dc1-cccc-a30e-4cc3fa40f997@oracle.com> Message-ID: <661adc74-79af-e383-891b-60b6cfdc779d@oracle.com> Thanks David. -katya On 10/23/18 3:04 PM, David Holmes wrote: > LGTM. > > Thanks, > David > > On 24/10/2018 6:33 AM, Ekaterina Pavlova wrote: >> Hi All, >> >> Please review this extra small change which restores JTREG_VERBOSE value for mach5 testing. >> >> Default JTREG_VERBOSE value was changed from "fail,error,time" to "fail,error,summary" after switching to run-test framework (JDK-8212028). >> Having compact tests output is good for local users while mach5 testing will benefits from providing more test execution information. >> Specially having test time execution data helps to analyze any tests/jobs slowness. >> >> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8212877 >> ??webrev: http://cr.openjdk.java.net/~epavlova//8212877/webrev.00/index.html >> testing: tested by launching jobs in Mach5 >> >> thanks, >> -katya From kevin.walls at oracle.com Wed Oct 24 23:16:04 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 25 Oct 2018 00:16:04 +0100 Subject: RFR(8u): 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 Message-ID: Hi, I'd like to get a review of an 8u change: 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 https://bugs.openjdk.java.net/browse/JDK-8211933 webrev: http://cr.openjdk.java.net/~kevinw/8211933/webrev.00/ Essentially adds -static-libstdc++ for linking adlc during an 8u build. This is needed e.g. when we build with gcc7.x using our devkit bundle and we won't necessarily find a correct version of that library on the system. (Things are still very different in 9+ compared to 8u, despite all our changes this year...) I find that changing the definition of STATIC_STDCXX = -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic ...in gcc.make is a problem, the linked VM fails to load with "undefined symbol: __cxa_pure_virtual" If using STATIC_STDCXX as it's already defined, to build adlc, then adlc doesn't statically link again libcstd and it gives the symbol version not found error.? So defining a separate STATIC... var for adlc keeps everyone happy. Many thanks Kevin bash-4.2$ cd jdk8u-dev/hotspot bash-4.2$ hg diff diff -r 992120803410 make/linux/makefiles/adlc.make --- a/make/linux/makefiles/adlc.make??? Mon Oct 22 05:26:38 2018 -0400 +++ b/make/linux/makefiles/adlc.make??? Wed Oct 24 16:15:07 2018 -0700 @@ -105,9 +105,15 @@ ?all: $(EXEC) +ADLC_LD_FLAGS= +ifeq ($(STATIC_CXX), true) +? ADLC_LD_FLAGS = $(STATIC_LIBGCC) $(ADLC_STATIC_STDCXX) +endif + + ?$(EXEC) : $(OBJECTS) ??????? @echo Making adlc -?????? $(QUIETLY) $(filter-out $(ARCHFLAG),$(HOST.LINK_NOPROF.CXX)) -o $(EXEC) $(OBJECTS) +?????? $(QUIETLY) $(filter-out $(ARCHFLAG),$(HOST.LINK_NOPROF.CXX)) $(ADLC_LD_FLAGS) -o $(EXEC) $(OBJECTS) ?# Random dependencies: ?$(OBJECTS): opcodes.hpp classes.hpp adlc.hpp adlcVMDeps.hpp adlparse.hpp archDesc.hpp arena.hpp dict2.hpp filebuff.hpp forms.hpp formsopt.hpp formssel.hpp diff -r 992120803410 make/linux/makefiles/gcc.make --- a/make/linux/makefiles/gcc.make???? Mon Oct 22 05:26:38 2018 -0400 +++ b/make/linux/makefiles/gcc.make???? Wed Oct 24 16:15:07 2018 -0700 @@ -277,6 +277,8 @@ ?# statically link libstdc++.so, work with gcc but ignored by g++ ?STATIC_STDCXX = -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic +# While the VM needs the above line, adlc needs a separate setting: +ADLC_STATIC_STDCXX = -static-libstdc++ ?ifeq ($(USE_CLANG),) ?? # statically link libgcc and/or libgcc_s, libgcc does not exist before gcc-3.x. bash-4.2$ From erik.joelsson at oracle.com Wed Oct 24 23:26:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 24 Oct 2018 16:26:40 -0700 Subject: RFR(8u): 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for gcc7.3 In-Reply-To: References: Message-ID: <6aa50a2a-104c-eff2-b9c6-52b99d50230d@oracle.com> Looks good to me. /Erik On 2018-10-24 16:16, Kevin Walls wrote: > Hi, > > I'd like to get a review of an 8u change: > > 8211933: [8u] hotspot adlc needs to link statically with libstdc++ for > gcc7.3 > https://bugs.openjdk.java.net/browse/JDK-8211933 > > webrev: > http://cr.openjdk.java.net/~kevinw/8211933/webrev.00/ > > Essentially adds -static-libstdc++ for linking adlc during an 8u > build. This is needed e.g. when we build with gcc7.x using our devkit > bundle and we won't necessarily find a correct version of that library > on the system. > > (Things are still very different in 9+ compared to 8u, despite all our > changes this year...) > I find that changing the definition of > > STATIC_STDCXX = -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic > > ...in gcc.make is a problem, the linked VM fails to load with > "undefined symbol: __cxa_pure_virtual" > > If using STATIC_STDCXX as it's already defined, to build adlc, then > adlc doesn't statically link again libcstd and it gives the symbol > version not found error.? So defining a separate STATIC... var for > adlc keeps everyone happy. > > Many thanks > Kevin > > > bash-4.2$ cd jdk8u-dev/hotspot > bash-4.2$ hg diff > diff -r 992120803410 make/linux/makefiles/adlc.make > --- a/make/linux/makefiles/adlc.make??? Mon Oct 22 05:26:38 2018 -0400 > +++ b/make/linux/makefiles/adlc.make??? Wed Oct 24 16:15:07 2018 -0700 > @@ -105,9 +105,15 @@ > > ?all: $(EXEC) > > +ADLC_LD_FLAGS= > +ifeq ($(STATIC_CXX), true) > +? ADLC_LD_FLAGS = $(STATIC_LIBGCC) $(ADLC_STATIC_STDCXX) > +endif > + > + > ?$(EXEC) : $(OBJECTS) > ??????? @echo Making adlc > -?????? $(QUIETLY) $(filter-out $(ARCHFLAG),$(HOST.LINK_NOPROF.CXX)) > -o $(EXEC) $(OBJECTS) > +?????? $(QUIETLY) $(filter-out $(ARCHFLAG),$(HOST.LINK_NOPROF.CXX)) > $(ADLC_LD_FLAGS) -o $(EXEC) $(OBJECTS) > > ?# Random dependencies: > ?$(OBJECTS): opcodes.hpp classes.hpp adlc.hpp adlcVMDeps.hpp > adlparse.hpp archDesc.hpp arena.hpp dict2.hpp filebuff.hpp forms.hpp > formsopt.hpp formssel.hpp > diff -r 992120803410 make/linux/makefiles/gcc.make > --- a/make/linux/makefiles/gcc.make???? Mon Oct 22 05:26:38 2018 -0400 > +++ b/make/linux/makefiles/gcc.make???? Wed Oct 24 16:15:07 2018 -0700 > @@ -277,6 +277,8 @@ > > ?# statically link libstdc++.so, work with gcc but ignored by g++ > ?STATIC_STDCXX = -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic > +# While the VM needs the above line, adlc needs a separate setting: > +ADLC_STATIC_STDCXX = -static-libstdc++ > > ?ifeq ($(USE_CLANG),) > ?? # statically link libgcc and/or libgcc_s, libgcc does not exist > before gcc-3.x. > bash-4.2$ > From yiji at apache.org Thu Oct 25 04:06:20 2018 From: yiji at apache.org (Zonghai Shang) Date: Thu, 25 Oct 2018 12:06:20 +0800 Subject: build openjdk8 on ubuntu18.04.1 Message-ID: Hi Building OpenJDK for target 'all' in configuration 'linux-x86_64-normal-server-fastdebug' ## Starting langtools Compiling 2 files for BUILD_TOOLS Compiling 32 properties into resource bundles Compiling 782 files for BUILD_BOOTSTRAP_LANGTOOLS Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Creating langtools/dist/bootstrap/lib/javac.jar Updating langtools/dist/lib/src.zip Compiling 785 files for BUILD_FULL_JAVAC Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. Creating langtools/dist/lib/classes.jar ## Finished langtools (build time 00:00:31) ## Starting hotspot make[2]: warning: -jN forced in submake: disabling jobserver mode. INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 Creating Makefile ... Creating directory list ../shared_dirs.lst Creating flags.make ... Creating flags_vm.make ... Creating vm.make ... Creating adlc.make ... Creating jvmti.make ... Creating trace.make ... Creating sa.make ... INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 Creating Makefile ... Creating flags.make ... Creating flags_vm.make ... Creating vm.make ... Creating adlc.make ... Creating jvmti.make ... Creating trace.make ... Creating sa.make ... INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 Creating Makefile ... Creating flags.make ... Creating flags_vm.make ... Creating vm.make ... Creating adlc.make ... Creating jvmti.make ... Creating trace.make ... Creating sa.make ... INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 Creating Makefile ... Creating flags.make ... Creating flags_vm.make ... Creating vm.make ... Creating adlc.make ... Creating jvmti.make ... Creating trace.make ... Creating sa.make ... Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/archDesc.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/adlparse.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/arena.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/dfa.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/dict2.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/filebuff.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/forms.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/formsopt.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/formssel.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/main.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/opto/opcodes.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/output_c.cpp Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/output_h.cpp Making adlc warning: [options] bootstrap class path not set in conjunction with -source 1.6 warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnv.hpp Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnter.cpp 1 warning Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnterTrace.cpp Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnvRecommended.cpp Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmti.h Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceEventClasses.hpp Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceEventIds.hpp Generating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceTypes.hpp INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 Making /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/sa-jdi.jar warning: [options] bootstrap class path not set in conjunction with -source 1.6 Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. 1 warning INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 INFO: ALT_OBJCOPY=/usr/bin/objcopy INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. INFO: STRIP_POLICY=min_strip INFO: ZIP_DEBUGINFO_FILES=1 Generating precompiled header precompiled.hpp.gch g++: error: yes: No such file or directory /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/vm.make:309: recipe for target 'precompiled.hpp.gch' failed make[6]: *** [precompiled.hpp.gch] Error 1 /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/top.make:119: recipe for target 'the_vm' failed make[5]: *** [the_vm] Error 2 /home/yiji/jvm/jdk8u/hotspot/make/linux/Makefile:297: recipe for target 'fastdebug' failed make[4]: *** [fastdebug] Error 2 make[3]: *** [generic_build2] Error 2 Makefile:230: recipe for target 'generic_build2' failed Makefile:177: recipe for target 'fastdebug' failed make[2]: *** [fastdebug] Error 2 HotspotWrapper.gmk:44: recipe for target '/home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp' failed make[1]: *** [/home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp] Error 2 /home/yiji/jvm/jdk8u//make/Main.gmk:109: recipe for target 'hotspot-only' failed make: *** [hotspot-only] Error 2 I am getting an error when compiling openjdk8 in ubuntu18.04.1: Generating precompiled header precompiled.hpp.gch g++: error: yes: No such file or directory /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/vm.make:309: recipe for target 'precompiled.hpp.gch? failed How can I solve it? thanks. yiji From denusdv at gmail.com Sat Oct 20 12:21:46 2018 From: denusdv at gmail.com (denusdv) Date: Sat, 20 Oct 2018 05:21:46 -0700 (MST) Subject: Building Portola JDK11 for AMR64 arch Message-ID: <1540038106268-0.post@n7.nabble.com> Hi all My purpose it to build JDK 11 Portola for ARM64 arch, I'm using x86 as a build arch, 1. The boot SDK is built from the same source. 2. The cross compile toolchain is gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu 3. The build is done in Alpine OS with glibc on it. My configure command looks ./configure --openjdk-target=aarch64-oe-linux --with-boot-jdk=/work/jdk11/build/linux-x86_64-normal-server-release/jdk --with-devkit=/tools/aarch64-toolchain/gcc-linaro-7.3.1-2 018.05-x86_64_aarch64-linux-gnu --disable-warnings-as-errors --disable-sjavac The configure output has only one warning *WARNING: using cross tools not prefixed with host triplet* which I can't resolve. now when I try to run the make command I'm getting the following error /Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR Compiling 188 files for BUILD_jdk.rmic.interim Compiling 162 files for BUILD_TOOLS_JDK /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp: Assembler messages: /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:116: Error: no such instruction: `prfm pldl1strm,[%rdi,' /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:118: Error: no such instruction: `adr %rax,0f' /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:118: Error: number of operands mismatch for `add' /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:125: Error: no such instruction: `prfm pldl1strm,[%rdi,' /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:127: Error: no such instruction: `adr %rax,0f' /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:127: Error: number of operands mismatch for `add' make[3]: *** [lib/CompileJvm.gmk:156: /work/jdk11/build/linux-aarch64-normal-server-release/hotspot/variant-server/libjvm/objs/accessBackend.o] Error 1 make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 make[2]: *** Waiting for unfinished jobs.... / I know it's related to the cross compile process, pls help me to fix it. -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Build-Infrastructure-f75522.html From yiji at apache.org Thu Oct 25 05:03:54 2018 From: yiji at apache.org (Zonghai Shang) Date: Thu, 25 Oct 2018 13:03:54 +0800 Subject: build openjdk8 on ubuntu18.04.1 In-Reply-To: References: Message-ID: Here is my config: Running generated-configure.sh configure: Configuration created at Thu Oct 25 11:35:50 HKT 2018. configure: configure script generated at timestamp 1539613812. checking for basename... /usr/bin/basename checking for bash... /bin/bash checking for cat... /bin/cat checking for chmod... /bin/chmod checking for cmp... /usr/bin/cmp checking for comm... /usr/bin/comm checking for cp... /bin/cp checking for cut... /usr/bin/cut checking for date... /bin/date checking for gdiff... no checking for diff... /usr/bin/diff checking for dirname... /usr/bin/dirname checking for echo... /bin/echo checking for expr... /usr/bin/expr checking for file... /usr/bin/file checking for find... /usr/bin/find checking for head... /usr/bin/head checking for ln... /bin/ln checking for ls... /bin/ls checking for mkdir... /bin/mkdir checking for mktemp... /bin/mktemp checking for mv... /bin/mv checking for nawk... /usr/bin/nawk checking for printf... /usr/bin/printf checking for rm... /bin/rm checking for sh... /bin/sh checking for sort... /usr/bin/sort checking for tail... /usr/bin/tail checking for tar... /bin/tar checking for tee... /usr/bin/tee checking for touch... /usr/bin/touch checking for tr... /usr/bin/tr checking for uname... /bin/uname checking for uniq... /usr/bin/uniq checking for wc... /usr/bin/wc checking for which... /usr/bin/which checking for xargs... /usr/bin/xargs checking for gawk... no checking for mawk... mawk checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for fgrep... /bin/grep -F checking for a sed that does not truncate output... /bin/sed checking for cygpath... no checking for greadlink... no checking for readlink... /bin/readlink checking for df... /bin/df checking for SetFile... no checking for cpio... /bin/cpio checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking openjdk-build os-cpu... linux-x86_64 checking openjdk-target os-cpu... linux-x86_64 checking compilation type... native checking for top-level directory... /home/yiji/jvm/jdk8u checking for presence of closed sources... no checking if closed source is suppressed (openjdk-only)... no checking which variant of the JDK to build... normal checking which interpreter of the JVM to build... template checking which variants of the JVM to build... server checking which debug level to use... fastdebug checking for sysroot... checking for toolchain path... checking for extra path... checking where to store configuration... in default location checking what configuration name to use... linux-x86_64-normal-server-fastdebug checking for apt-get... apt-get checking for gmake... no checking for make... /usr/bin/make configure: Testing potential make at /usr/bin/make, found using make in PATH configure: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU Make 4.1) checking if find supports -delete... yes checking for unzip... /usr/bin/unzip checking for zip... /usr/bin/zip checking for ldd... /usr/bin/ldd checking for readelf... /usr/bin/readelf checking for hg... /usr/bin/hg checking for stat... /usr/bin/stat checking for time... /usr/bin/time checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for 7z... no checking for unzip... unzip checking for wget... wget checking headful support... include support for both headful and headless configure: Found potential Boot JDK using JAVA_HOME checking for Boot JDK... /home/yiji/jvm/jdk1.7.0_80 checking Boot JDK version... java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode) checking for java in Boot JDK... ok checking for javac in Boot JDK... ok checking for javah in Boot JDK... ok checking for javap in Boot JDK... ok checking for jar in Boot JDK... ok checking for rmic in Boot JDK... ok checking for native2ascii in Boot JDK... ok checking if Boot JDK is 32 or 64 bits... 64 checking flags for boot jdk java command ... checking flags for boot jdk java command for big workloads... -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:PermSize=32m -XX:MaxPermSize=160m checking flags for boot jdk java command for small workloads... -XX:+UseSerialGC -Xms32M -Xmx512M configure: Using default toolchain gcc (GNU Compiler Collection) checking for gcc... /usr/bin/gcc checking resolved symbolic links for CC... /usr/bin/x86_64-linux-gnu-gcc-7 checking if CC is disguised ccache... no, keeping CC configure: Using gcc C compiler version 7.3.0 [gcc (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0] checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking for g++... /usr/bin/g++ checking resolved symbolic links for CXX... /usr/bin/x86_64-linux-gnu-g++-7 checking if CXX is disguised ccache... no, keeping CXX configure: Using gcc C++ compiler version 7.3.0 [g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0] checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++ accepts -g... yes checking how to run the C preprocessor... /usr/bin/gcc -E checking how to run the C++ preprocessor... /usr/bin/g++ -E checking for ar... ar configure: Rewriting AR to "/usr/bin/ar" checking for strip... strip configure: Rewriting STRIP to "/usr/bin/strip" checking for otool... no checking for nm... nm configure: Rewriting NM to "/usr/bin/nm" checking for gobjcopy... no checking for objcopy... objcopy configure: Rewriting OBJCOPY to "/usr/bin/objcopy" checking for gobjdump... no checking for objdump... objdump configure: Rewriting OBJDUMP to "/usr/bin/objdump" checking for broken SuSE 'ld' which only understands anonymous version tags in executables... no checking for jtreg... no checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking stdio.h usability... yes checking stdio.h presence... yes checking for stdio.h... yes checking size of int *... 8 checking for target address size... 64 bits checking whether byte ordering is bigendian... no checking if the C++ compiler supports "-std=gnu++98 -Werror"... yes configure: WARNING: Ignoring CFLAGS(-Wno-error) found in environment. Use --with-extra-cflags configure: WARNING: Ignoring CXXFLAGS(-Wno-error) found in environment. Use --with-extra-cxxflags checking if the C compiler supports "-fno-delete-null-pointer-checks -Werror"... yes checking if the C++ compiler supports "-fno-delete-null-pointer-checks -Werror"... yes checking if both compilers support "-fno-delete-null-pointer-checks -Werror"... yes checking if the C compiler supports "-fno-lifetime-dse -Werror"... yes checking if the C++ compiler supports "-fno-lifetime-dse -Werror"... yes checking if both compilers support "-fno-lifetime-dse -Werror"... yes checking if the C compiler supports "-m64"... yes checking if the C++ compiler supports "-m64"... yes checking if both compilers support "-m64"... yes checking if the C compiler supports "-m64"... yes checking if the C++ compiler supports "-m64"... yes checking if both compilers support "-m64"... yes checking if we should generate debug symbols... true checking if we should zip debug-info files... yes checking what type of native debug symbols to use (this will override previous settings)... not specified configure: --with-native-debug-symbols not specified. Using values from --disable-debug-symbols and --disable-zip-debug-info checking what is not needed on Linux?... pulse checking for X... libraries , headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for X11/extensions/shape.h... yes checking for X11/extensions/Xrender.h... yes checking for X11/extensions/XTest.h... yes checking for X11/Intrinsic.h... yes checking cups/cups.h usability... yes checking cups/cups.h presence... yes checking for cups/cups.h... yes checking cups/ppd.h usability... yes checking cups/ppd.h presence... yes checking for cups/ppd.h... yes checking for FREETYPE... yes checking for freetype... yes (using pkg-config) checking if we can compile and link with freetype... yes checking if we should bundle freetype... no checking for ALSA... yes checking for main in -ljpeg... yes checking for which giflib to use... bundled checking for compress in -lz... yes checking for which zlib to use... bundled checking for cos in -lm... yes checking for dlopen in -ldl... yes checking if dynamic link of stdc++ is possible... yes checking if static link of stdc++ is possible... yes checking how to link with libstdc++... static checking if elliptic curve crypto implementation is present... yes checking for number of cores... 4 checking for memory size... 3921 MB checking for appropriate number of jobs to run in parallel... 3 checking whether to use sjavac... no checking that precompiled headers work... yes checking is ccache enabled... no checking if build directory is on local disk... yes configure: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/config.status config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/spec.gmk config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot-spec.gmk config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/bootcycle-spec.gmk config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/compare.sh config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/spec.sh config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/Makefile config.status: creating /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/config.h ==================================================== A new configuration has been successfully created in /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug using configure arguments '--enable-debug --with-extra-cflags --with-extra-cxxflags'. Configuration summary: * Debug level: fastdebug * JDK variant: normal * JVM variants: server * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 Tools summary: * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode) (at /home/yiji/jvm/jdk1.7.0_80) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 7.3.0 (at /usr/bin/gcc) * C++ Compiler: Version 7.3.0 (at /usr/bin/g++) Build performance summary: * Cores to use: 3 * Memory limit: 3921 MB yiji Zonghai Shang ?2018?10?25??? ??12:06??? > Hi > > > Building OpenJDK for target 'all' in configuration > 'linux-x86_64-normal-server-fastdebug' > > ## Starting langtools > Compiling 2 files for BUILD_TOOLS > Compiling 32 properties into resource bundles > Compiling 782 files for BUILD_BOOTSTRAP_LANGTOOLS > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Creating langtools/dist/bootstrap/lib/javac.jar > Updating langtools/dist/lib/src.zip > Compiling 785 files for BUILD_FULL_JAVAC > Note: Some input files use or override a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Creating langtools/dist/lib/classes.jar > ## Finished langtools (build time 00:00:31) > > ## Starting hotspot > make[2]: warning: -jN forced in submake: disabling jobserver mode. > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Creating Makefile ... > Creating directory list ../shared_dirs.lst > Creating flags.make ... > Creating flags_vm.make ... > Creating vm.make ... > Creating adlc.make ... > Creating jvmti.make ... > Creating trace.make ... > Creating sa.make ... > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Creating Makefile ... > Creating flags.make ... > Creating flags_vm.make ... > Creating vm.make ... > Creating adlc.make ... > Creating jvmti.make ... > Creating trace.make ... > Creating sa.make ... > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Creating Makefile ... > Creating flags.make ... > Creating flags_vm.make ... > Creating vm.make ... > Creating adlc.make ... > Creating jvmti.make ... > Creating trace.make ... > Creating sa.make ... > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Creating Makefile ... > Creating flags.make ... > Creating flags_vm.make ... > Creating vm.make ... > Creating adlc.make ... > Creating jvmti.make ... > Creating trace.make ... > Creating sa.make ... > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/archDesc.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/adlparse.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/arena.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/dfa.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/dict2.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/filebuff.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/forms.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/formsopt.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/formssel.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/main.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/opto/opcodes.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/output_c.cpp > Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/output_h.cpp > Making adlc > warning: [options] bootstrap class path not set in conjunction with > -source 1.6 > warning: [options] bootstrap class path not set in conjunction with > -source 1.6 > 1 warning > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnv.hpp > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnter.cpp > 1 warning > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnterTrace.cpp > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnvRecommended.cpp > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmti.h > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceEventClasses.hpp > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceEventIds.hpp > Generating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceTypes.hpp > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Making > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/sa-jdi.jar > warning: [options] bootstrap class path not set in conjunction with > -source 1.6 > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 1 warning > INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 > INFO: ALT_OBJCOPY=/usr/bin/objcopy > INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. > INFO: STRIP_POLICY=min_strip > INFO: ZIP_DEBUGINFO_FILES=1 > Generating precompiled header precompiled.hpp.gch > g++: error: yes: No such file or directory > /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/vm.make:309: recipe for > target 'precompiled.hpp.gch' failed > make[6]: *** [precompiled.hpp.gch] Error 1 > /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/top.make:119: recipe for > target 'the_vm' failed > make[5]: *** [the_vm] Error 2 > /home/yiji/jvm/jdk8u/hotspot/make/linux/Makefile:297: recipe for target > 'fastdebug' failed > make[4]: *** [fastdebug] Error 2 > make[3]: *** [generic_build2] Error 2 > Makefile:230: recipe for target 'generic_build2' failed > Makefile:177: recipe for target 'fastdebug' failed > make[2]: *** [fastdebug] Error 2 > HotspotWrapper.gmk:44: recipe for target > '/home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp' > failed > make[1]: *** > [/home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp] > Error 2 > /home/yiji/jvm/jdk8u//make/Main.gmk:109: recipe for target 'hotspot-only' > failed > make: *** [hotspot-only] Error 2 > > I am getting an error when compiling openjdk8 in ubuntu18.04.1: > > Generating precompiled header precompiled.hpp.gch > g++: error: yes: No such file or directory > /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/vm.make:309: recipe for > target 'precompiled.hpp.gch? failed > > How can I solve it? thanks. > > yiji > From turikhay at gmail.com Thu Oct 25 05:44:02 2018 From: turikhay at gmail.com (Artur Khusainov) Date: Thu, 25 Oct 2018 10:44:02 +0500 Subject: Cannot compile OpenJDK 11 (visual studio fail) In-Reply-To: References: Message-ID: I also reported this earlier. You should install English (US) language pack for Visual Studio. And maybe uninstall your current language pack. ??, 25 ???. 2018 ?., 9:26 Franco Gast?n Pellegrini < francogpellegrini at gmail.com>: > Hello, I'm trying to compile OpenJDK 11 from hg sources, but when I use: > > bash ./configure --enable-debug --with-target-bits=32 > --with-toolchain-version=2017 --with-jvm-variants=client > > --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/"; > > it fail, because: > > checking for cl... /cygdrive/c/Program Files (x86)/Microsoft Visual Studio > 14.0/VC/BIN/cl > configure: Rewriting CC to "/cygdrive/c/progra~3/micros~1.0/vc/bin/cl" > checking resolved symbolic links for CC... no symlink > configure: The C compiler (located as > /cygdrive/c/progra~3/micros~1.0/vc/bin/cl) does not seem to be the required > microsoft compiler. > configure: The result from running it was: "Compilador de optimizaci?n de > C/C++ de Microsoft (R) versi?n 19.00.24234.1 para x86" > configure: error: A microsoft compiler is required. Try setting > --with-tools-dir. > configure exiting with result code 1 > > I already tried installing visual studio 2013, 2015, and 2017 (using the > corresponding --with-toolchain-version), but all of them fail too. 2013 > version fail in other way at the end, at compiling come security features. > > I'm using windows 7 32 bits (I need a 32 bits version for some specific old > PCs). > > what should I do? > > -- > Franco Pellegrini > From glaubitz at physik.fu-berlin.de Thu Oct 25 07:41:50 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 25 Oct 2018 09:41:50 +0200 Subject: build openjdk8 on ubuntu18.04.1 In-Reply-To: References: Message-ID: <11C131F0-F34A-4628-9253-912142E4BE2C@physik.fu-berlin.de> Hi! Please run: apt build-dep openjdk-8 as root before you continue. If that doesn?t help, try with ?openjdk-9?, ?openjdk-10? or ?openjdk-11?. Cheers, Adrian > On Oct 25, 2018, at 7:03 AM, Zonghai Shang wrote: > > Here is my config: > > Running generated-configure.sh > configure: Configuration created at Thu Oct 25 11:35:50 HKT 2018. > configure: configure script generated at timestamp 1539613812. > checking for basename... /usr/bin/basename > checking for bash... /bin/bash > checking for cat... /bin/cat > checking for chmod... /bin/chmod > checking for cmp... /usr/bin/cmp > checking for comm... /usr/bin/comm > checking for cp... /bin/cp > checking for cut... /usr/bin/cut > checking for date... /bin/date > checking for gdiff... no > checking for diff... /usr/bin/diff > checking for dirname... /usr/bin/dirname > checking for echo... /bin/echo > checking for expr... /usr/bin/expr > checking for file... /usr/bin/file > checking for find... /usr/bin/find > checking for head... /usr/bin/head > checking for ln... /bin/ln > checking for ls... /bin/ls > checking for mkdir... /bin/mkdir > checking for mktemp... /bin/mktemp > checking for mv... /bin/mv > checking for nawk... /usr/bin/nawk > checking for printf... /usr/bin/printf > checking for rm... /bin/rm > checking for sh... /bin/sh > checking for sort... /usr/bin/sort > checking for tail... /usr/bin/tail > checking for tar... /bin/tar > checking for tee... /usr/bin/tee > checking for touch... /usr/bin/touch > checking for tr... /usr/bin/tr > checking for uname... /bin/uname > checking for uniq... /usr/bin/uniq > checking for wc... /usr/bin/wc > checking for which... /usr/bin/which > checking for xargs... /usr/bin/xargs > checking for gawk... no > checking for mawk... mawk > checking for grep that handles long lines and -e... /bin/grep > checking for egrep... /bin/grep -E > checking for fgrep... /bin/grep -F > checking for a sed that does not truncate output... /bin/sed > checking for cygpath... no > checking for greadlink... no > checking for readlink... /bin/readlink > checking for df... /bin/df > checking for SetFile... no > checking for cpio... /bin/cpio > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking target system type... x86_64-unknown-linux-gnu > checking openjdk-build os-cpu... linux-x86_64 > checking openjdk-target os-cpu... linux-x86_64 > checking compilation type... native > checking for top-level directory... /home/yiji/jvm/jdk8u > checking for presence of closed sources... no > checking if closed source is suppressed (openjdk-only)... no > checking which variant of the JDK to build... normal > checking which interpreter of the JVM to build... template > checking which variants of the JVM to build... server > checking which debug level to use... fastdebug > checking for sysroot... > checking for toolchain path... > checking for extra path... > checking where to store configuration... in default location > checking what configuration name to use... > linux-x86_64-normal-server-fastdebug > checking for apt-get... apt-get > checking for gmake... no > checking for make... /usr/bin/make > configure: Testing potential make at /usr/bin/make, found using make in PATH > configure: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU > Make 4.1) > checking if find supports -delete... yes > checking for unzip... /usr/bin/unzip > checking for zip... /usr/bin/zip > checking for ldd... /usr/bin/ldd > checking for readelf... /usr/bin/readelf > checking for hg... /usr/bin/hg > checking for stat... /usr/bin/stat > checking for time... /usr/bin/time > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for 7z... no > checking for unzip... unzip > checking for wget... wget > checking headful support... include support for both headful and headless > configure: Found potential Boot JDK using JAVA_HOME > checking for Boot JDK... /home/yiji/jvm/jdk1.7.0_80 > checking Boot JDK version... java version "1.7.0_80" Java(TM) SE Runtime > Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build > 24.80-b11, mixed mode) > checking for java in Boot JDK... ok > checking for javac in Boot JDK... ok > checking for javah in Boot JDK... ok > checking for javap in Boot JDK... ok > checking for jar in Boot JDK... ok > checking for rmic in Boot JDK... ok > checking for native2ascii in Boot JDK... ok > checking if Boot JDK is 32 or 64 bits... 64 > checking flags for boot jdk java command ... > checking flags for boot jdk java command for big workloads... -Xms64M > -Xmx1600M -XX:ThreadStackSize=1536 -XX:PermSize=32m -XX:MaxPermSize=160m > checking flags for boot jdk java command for small workloads... > -XX:+UseSerialGC -Xms32M -Xmx512M > configure: Using default toolchain gcc (GNU Compiler Collection) > checking for gcc... /usr/bin/gcc > checking resolved symbolic links for CC... /usr/bin/x86_64-linux-gnu-gcc-7 > checking if CC is disguised ccache... no, keeping CC > configure: Using gcc C compiler version 7.3.0 [gcc (Ubuntu > 7.3.0-27ubuntu1~18.04) 7.3.0] > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether /usr/bin/gcc accepts -g... yes > checking for /usr/bin/gcc option to accept ISO C89... none needed > checking for g++... /usr/bin/g++ > checking resolved symbolic links for CXX... /usr/bin/x86_64-linux-gnu-g++-7 > checking if CXX is disguised ccache... no, keeping CXX > configure: Using gcc C++ compiler version 7.3.0 [g++ (Ubuntu > 7.3.0-27ubuntu1~18.04) 7.3.0] > checking whether we are using the GNU C++ compiler... yes > checking whether /usr/bin/g++ accepts -g... yes > checking how to run the C preprocessor... /usr/bin/gcc -E > checking how to run the C++ preprocessor... /usr/bin/g++ -E > checking for ar... ar > configure: Rewriting AR to "/usr/bin/ar" > checking for strip... strip > configure: Rewriting STRIP to "/usr/bin/strip" > checking for otool... no > checking for nm... nm > configure: Rewriting NM to "/usr/bin/nm" > checking for gobjcopy... no > checking for objcopy... objcopy > configure: Rewriting OBJCOPY to "/usr/bin/objcopy" > checking for gobjdump... no > checking for objdump... objdump > configure: Rewriting OBJDUMP to "/usr/bin/objdump" > checking for broken SuSE 'ld' which only understands anonymous version tags > in executables... no > checking for jtreg... no > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking stdio.h usability... yes > checking stdio.h presence... yes > checking for stdio.h... yes > checking size of int *... 8 > checking for target address size... 64 bits > checking whether byte ordering is bigendian... no > checking if the C++ compiler supports "-std=gnu++98 -Werror"... yes > configure: WARNING: Ignoring CFLAGS(-Wno-error) found in environment. Use > --with-extra-cflags > configure: WARNING: Ignoring CXXFLAGS(-Wno-error) found in environment. Use > --with-extra-cxxflags > checking if the C compiler supports "-fno-delete-null-pointer-checks > -Werror"... yes > checking if the C++ compiler supports "-fno-delete-null-pointer-checks > -Werror"... yes > checking if both compilers support "-fno-delete-null-pointer-checks > -Werror"... yes > checking if the C compiler supports "-fno-lifetime-dse -Werror"... yes > checking if the C++ compiler supports "-fno-lifetime-dse -Werror"... yes > checking if both compilers support "-fno-lifetime-dse -Werror"... yes > checking if the C compiler supports "-m64"... yes > checking if the C++ compiler supports "-m64"... yes > checking if both compilers support "-m64"... yes > checking if the C compiler supports "-m64"... yes > checking if the C++ compiler supports "-m64"... yes > checking if both compilers support "-m64"... yes > checking if we should generate debug symbols... true > checking if we should zip debug-info files... yes > checking what type of native debug symbols to use (this will override > previous settings)... not specified > configure: --with-native-debug-symbols not specified. Using values from > --disable-debug-symbols and --disable-zip-debug-info > checking what is not needed on Linux?... pulse > checking for X... libraries , headers > checking for gethostbyname... yes > checking for connect... yes > checking for remove... yes > checking for shmat... yes > checking for IceConnectionNumber in -lICE... yes > checking for X11/extensions/shape.h... yes > checking for X11/extensions/Xrender.h... yes > checking for X11/extensions/XTest.h... yes > checking for X11/Intrinsic.h... yes > checking cups/cups.h usability... yes > checking cups/cups.h presence... yes > checking for cups/cups.h... yes > checking cups/ppd.h usability... yes > checking cups/ppd.h presence... yes > checking for cups/ppd.h... yes > checking for FREETYPE... yes > checking for freetype... yes (using pkg-config) > checking if we can compile and link with freetype... yes > checking if we should bundle freetype... no > checking for ALSA... yes > checking for main in -ljpeg... yes > checking for which giflib to use... bundled > checking for compress in -lz... yes > checking for which zlib to use... bundled > checking for cos in -lm... yes > checking for dlopen in -ldl... yes > checking if dynamic link of stdc++ is possible... yes > checking if static link of stdc++ is possible... yes > checking how to link with libstdc++... static > checking if elliptic curve crypto implementation is present... yes > checking for number of cores... 4 > checking for memory size... 3921 MB > checking for appropriate number of jobs to run in parallel... 3 > checking whether to use sjavac... no > checking that precompiled headers work... yes > checking is ccache enabled... no > checking if build directory is on local disk... yes > configure: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/config.status > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/spec.gmk > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot-spec.gmk > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/bootcycle-spec.gmk > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/compare.sh > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/spec.sh > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/Makefile > config.status: creating > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/config.h > > ==================================================== > A new configuration has been successfully created in > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug > using configure arguments '--enable-debug --with-extra-cflags > --with-extra-cxxflags'. > > Configuration summary: > * Debug level: fastdebug > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: linux, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment > (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, > mixed mode) (at /home/yiji/jvm/jdk1.7.0_80) > * Toolchain: gcc (GNU Compiler Collection) > * C Compiler: Version 7.3.0 (at /usr/bin/gcc) > * C++ Compiler: Version 7.3.0 (at /usr/bin/g++) > > Build performance summary: > * Cores to use: 3 > * Memory limit: 3921 MB > > yiji > > Zonghai Shang ?2018?10?25??? ??12:06??? > >> Hi >> >> >> Building OpenJDK for target 'all' in configuration >> 'linux-x86_64-normal-server-fastdebug' >> >> ## Starting langtools >> Compiling 2 files for BUILD_TOOLS >> Compiling 32 properties into resource bundles >> Compiling 782 files for BUILD_BOOTSTRAP_LANGTOOLS >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Creating langtools/dist/bootstrap/lib/javac.jar >> Updating langtools/dist/lib/src.zip >> Compiling 785 files for BUILD_FULL_JAVAC >> Note: Some input files use or override a deprecated API. >> Note: Recompile with -Xlint:deprecation for details. >> Creating langtools/dist/lib/classes.jar >> ## Finished langtools (build time 00:00:31) >> >> ## Starting hotspot >> make[2]: warning: -jN forced in submake: disabling jobserver mode. >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Creating Makefile ... >> Creating directory list ../shared_dirs.lst >> Creating flags.make ... >> Creating flags_vm.make ... >> Creating vm.make ... >> Creating adlc.make ... >> Creating jvmti.make ... >> Creating trace.make ... >> Creating sa.make ... >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Creating Makefile ... >> Creating flags.make ... >> Creating flags_vm.make ... >> Creating vm.make ... >> Creating adlc.make ... >> Creating jvmti.make ... >> Creating trace.make ... >> Creating sa.make ... >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Creating Makefile ... >> Creating flags.make ... >> Creating flags_vm.make ... >> Creating vm.make ... >> Creating adlc.make ... >> Creating jvmti.make ... >> Creating trace.make ... >> Creating sa.make ... >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Creating Makefile ... >> Creating flags.make ... >> Creating flags_vm.make ... >> Creating vm.make ... >> Creating adlc.make ... >> Creating jvmti.make ... >> Creating trace.make ... >> Creating sa.make ... >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/archDesc.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/adlparse.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/arena.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/dfa.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/dict2.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/filebuff.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/forms.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/formsopt.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/formssel.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/main.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/opto/opcodes.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/output_c.cpp >> Compiling /home/yiji/jvm/jdk8u/hotspot/src/share/vm/adlc/output_h.cpp >> Making adlc >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> 1 warning >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnv.hpp >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnter.cpp >> 1 warning >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnterTrace.cpp >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmtiEnvRecommended.cpp >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/jvmtifiles/jvmti.h >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceEventClasses.hpp >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceEventIds.hpp >> Generating >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/tracefiles/traceTypes.hpp >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Making >> /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/linux_amd64_compiler2/fastdebug/../generated/sa-jdi.jar >> warning: [options] bootstrap class path not set in conjunction with >> -source 1.6 >> Note: Some input files use unchecked or unsafe operations. >> Note: Recompile with -Xlint:unchecked for details. >> 1 warning >> INFO: ENABLE_FULL_DEBUG_SYMBOLS=1 >> INFO: ALT_OBJCOPY=/usr/bin/objcopy >> INFO: /usr/bin/objcopy cmd found so will create .debuginfo files. >> INFO: STRIP_POLICY=min_strip >> INFO: ZIP_DEBUGINFO_FILES=1 >> Generating precompiled header precompiled.hpp.gch >> g++: error: yes: No such file or directory >> /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/vm.make:309: recipe for >> target 'precompiled.hpp.gch' failed >> make[6]: *** [precompiled.hpp.gch] Error 1 >> /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/top.make:119: recipe for >> target 'the_vm' failed >> make[5]: *** [the_vm] Error 2 >> /home/yiji/jvm/jdk8u/hotspot/make/linux/Makefile:297: recipe for target >> 'fastdebug' failed >> make[4]: *** [fastdebug] Error 2 >> make[3]: *** [generic_build2] Error 2 >> Makefile:230: recipe for target 'generic_build2' failed >> Makefile:177: recipe for target 'fastdebug' failed >> make[2]: *** [fastdebug] Error 2 >> HotspotWrapper.gmk:44: recipe for target >> '/home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp' >> failed >> make[1]: *** >> [/home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug/hotspot/_hotspot.timestamp] >> Error 2 >> /home/yiji/jvm/jdk8u//make/Main.gmk:109: recipe for target 'hotspot-only' >> failed >> make: *** [hotspot-only] Error 2 >> >> I am getting an error when compiling openjdk8 in ubuntu18.04.1: >> >> Generating precompiled header precompiled.hpp.gch >> g++: error: yes: No such file or directory >> /home/yiji/jvm/jdk8u/hotspot/make/linux/makefiles/vm.make:309: recipe for >> target 'precompiled.hpp.gch? failed >> >> How can I solve it? thanks. >> >> yiji >> From kevin.rushforth at oracle.com Thu Oct 25 13:09:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Oct 2018 06:09:09 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: Andy added the a comment [1] to the JEP with the command line options. I'll format it and add it to the JEP itself soon, but until then you can see it in the comments to help you review it. The tests will come shortly (Andy can comment on the state of this). They will be a mix of automated tests and (especially for the installers) manual tests. The module with the API is meant to be a small runtime module that would be jlinked in with the application (whereas the tool itself typically wouldn't be). The working name is jdk.packager.services (inherited from javapacakger). An alternative name we had considered was jdk.packager.runtime? Or maybe jdk.packager.support? Do you have any suggestions? The exported package is named jdk.packager.services.singleton, since the singleton app feature is the only one that currently needs runtime support. The intention would be to add other packages as new features that require runtime support are added in the future (e.g., daemon services or JRE argument support). We haven't given any thought to alternative names, other than if we change the module name to something like jdk.packager.runtime, we would likely want to use that to inform the name of the package. Do you have any recommendations? Perhaps we can discuss the JNLPConverter demo in a separate thread, since I see Erik raised a similar question? Andy can reply to anything I missed or to clarify further. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758?focusedCommentId=14217780&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14217780 On 10/24/2018 7:22 AM, Alan Bateman wrote: > On 23/10/2018 16:49, Andy Herrick wrote: >> This patch implements the Java Packager Tool (jpackager) as described >> in JEP 343: Packaging Tool >> >> >> jpackager is a simple packaging tool, based on the JavaFX >> |javapackager| tool, that: >> >> ?* Supports native packaging formats to give the end user a natural >> ?? installation experience. These formats include |msi| and |exe| on >> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >> ?* Allows launch-time parameters to be specified at packaging time. >> ?* Can be invoked directly, from the command line, or programmatically, >> ?? via the |ToolProvider| API. >> >> Webrev: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >> > cc'ing build-dev as it's important to get it reviewed there. > > What is the plan for tests to go with this tool? I see there is one > test in the webrev to do some argument validation but I don't see > anything else right now. > > What is the status of the JNLPConverter tool? I see it is included as > a "demo" but maybe it would be better to host somewhere else as this > is for developers migrating Java Web Start applications. > > Would it be possible to update the JEP with all the CLI options? That > would be useful for review and also useful for those invoking it with > the ToolProvider API. > > If I read the webrev correctly then it adds two modules, one with the > jpackager tool and the other with an API. It would be useful to get a > bit more information on the split. Also I think the name of the API > module and the package that it exports needs discussion to make sure > that the right names are chosen. > > -Alan From shade at redhat.com Thu Oct 25 13:41:16 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 25 Oct 2018 15:41:16 +0200 Subject: build openjdk8 on ubuntu18.04.1 In-Reply-To: References: Message-ID: On 10/25/2018 07:03 AM, Zonghai Shang wrote: > A new configuration has been successfully created in > /home/yiji/jvm/jdk8u/build/linux-x86_64-normal-server-fastdebug > using configure arguments '--enable-debug --with-extra-cflags > --with-extra-cxxflags'. This looks tad suspicious. Why there are no values in extra cflags? What is your full configure line? -Aleksey From erik.joelsson at oracle.com Thu Oct 25 16:30:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Oct 2018 09:30:33 -0700 Subject: Cannot compile OpenJDK 11 (visual studio fail) In-Reply-To: References: Message-ID: I think we need to make this check less strict to allow for different languages. /Erik On 2018-10-24 22:44, Artur Khusainov wrote: > I also reported this earlier. > > You should install English (US) language pack for Visual Studio. And maybe > uninstall your current language pack. > > ??, 25 ???. 2018 ?., 9:26 Franco Gast?n Pellegrini < > francogpellegrini at gmail.com>: > >> Hello, I'm trying to compile OpenJDK 11 from hg sources, but when I use: >> >> bash ./configure --enable-debug --with-target-bits=32 >> --with-toolchain-version=2017 --with-jvm-variants=client >> >> --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/"; >> >> it fail, because: >> >> checking for cl... /cygdrive/c/Program Files (x86)/Microsoft Visual Studio >> 14.0/VC/BIN/cl >> configure: Rewriting CC to "/cygdrive/c/progra~3/micros~1.0/vc/bin/cl" >> checking resolved symbolic links for CC... no symlink >> configure: The C compiler (located as >> /cygdrive/c/progra~3/micros~1.0/vc/bin/cl) does not seem to be the required >> microsoft compiler. >> configure: The result from running it was: "Compilador de optimizaci?n de >> C/C++ de Microsoft (R) versi?n 19.00.24234.1 para x86" >> configure: error: A microsoft compiler is required. Try setting >> --with-tools-dir. >> configure exiting with result code 1 >> >> I already tried installing visual studio 2013, 2015, and 2017 (using the >> corresponding --with-toolchain-version), but all of them fail too. 2013 >> version fail in other way at the end, at compiling come security features. >> >> I'm using windows 7 32 bits (I need a 32 bits version for some specific old >> PCs). >> >> what should I do? >> >> -- >> Franco Pellegrini >> From erik.joelsson at oracle.com Thu Oct 25 16:34:45 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Oct 2018 09:34:45 -0700 Subject: Cannot compile OpenJDK 11 (visual studio fail) In-Reply-To: References: Message-ID: <465c1640-6e07-23e1-68fb-181ce9244433@oracle.com> Filed https://bugs.openjdk.java.net/browse/JDK-8212986 /Erik On 2018-10-25 09:30, Erik Joelsson wrote: > I think we need to make this check less strict to allow for different > languages. > > /Erik > > > On 2018-10-24 22:44, Artur Khusainov wrote: >> I also reported this earlier. >> >> You should install English (US) language pack for Visual Studio. And >> maybe >> uninstall your current language pack. >> >> ??, 25 ???. 2018 ?., 9:26 Franco Gast?n Pellegrini < >> francogpellegrini at gmail.com>: >> >>> Hello, I'm trying to compile OpenJDK 11 from hg sources, but when I >>> use: >>> >>> bash ./configure --enable-debug --with-target-bits=32 >>> --with-toolchain-version=2017 --with-jvm-variants=client >>> >>> --with-boot-jdk="/home/Franco/Java/jdk10/build/windows-x86-normal-client-fastdebug/jdk/"; >>> >>> >>> it fail, because: >>> >>> checking for cl... /cygdrive/c/Program Files (x86)/Microsoft Visual >>> Studio >>> 14.0/VC/BIN/cl >>> configure: Rewriting CC to "/cygdrive/c/progra~3/micros~1.0/vc/bin/cl" >>> checking resolved symbolic links for CC... no symlink >>> configure: The C compiler (located as >>> /cygdrive/c/progra~3/micros~1.0/vc/bin/cl) does not seem to be the >>> required >>> microsoft compiler. >>> configure: The result from running it was: "Compilador de >>> optimizaci?n de >>> C/C++ de Microsoft (R) versi?n 19.00.24234.1 para x86" >>> configure: error: A microsoft compiler is required. Try setting >>> --with-tools-dir. >>> configure exiting with result code 1 >>> >>> I already tried installing visual studio 2013, 2015, and 2017 (using >>> the >>> corresponding? --with-toolchain-version), but all of them fail too. >>> 2013 >>> version fail in other way at the end, at compiling come security >>> features. >>> >>> I'm using windows 7 32 bits (I need a 32 bits version for some >>> specific old >>> PCs). >>> >>> what should I do? >>> >>> -- >>> Franco Pellegrini >>> > From iris.clark at oracle.com Thu Oct 25 20:33:10 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 25 Oct 2018 13:33:10 -0700 (PDT) Subject: RFR(XS): 8212994: Links to Oracle websites should use "https:" Message-ID: Hi. Please review changes to use "https" instead of "http" for links in the generated JavaDoc API pages: 8212994: Links to Oracle websites should use "https:" bug: https://bugs.openjdk.java.net/browse/JDK-8212994 webrev: https://cr.openjdk.java.net/~iris/8212994/webrev/ I did a full "make docs" build and verified that the old links are no longer in the created image. Thanks, iris $ pwd /u/iris/se/full-jdk/build/images $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/redist-137594.html" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/redist-137594.html" | wc -l 20312 ## link in banner and footer $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l 40624 $ find . -name "*.html" -print | xargs grep "http://bugreport.java.com/bugreport/" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://bugreport.java.com/bugreport/" | wc -l 20312 $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l 20312 From erik.joelsson at oracle.com Thu Oct 25 20:43:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Oct 2018 13:43:15 -0700 Subject: RFR(XS): 8212994: Links to Oracle websites should use "https:" In-Reply-To: References: Message-ID: <86f4ea66-f710-2e59-6dd2-e77d5fe1ce9e@oracle.com> Looks good. /Erik On 2018-10-25 13:33, Iris Clark wrote: > Hi. > > Please review changes to use "https" instead of "http" for links in the > generated JavaDoc API pages: > > 8212994: Links to Oracle websites should use "https:" > bug: https://bugs.openjdk.java.net/browse/JDK-8212994 > webrev: https://cr.openjdk.java.net/~iris/8212994/webrev/ > > I did a full "make docs" build and verified that the old links are > no longer in the created image. > > Thanks, > iris > > $ pwd > /u/iris/se/full-jdk/build/images > > $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/redist-137594.html" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/redist-137594.html" | wc -l > 20312 > > ## link in banner and footer > $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l > 40624 > > $ find . -name "*.html" -print | xargs grep "http://bugreport.java.com/bugreport/" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://bugreport.java.com/bugreport/" | wc -l > 20312 > > $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l > 20312 From lance.andersen at oracle.com Thu Oct 25 20:48:28 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 25 Oct 2018 16:48:28 -0400 Subject: RFR(XS): 8212994: Links to Oracle websites should use "https:" In-Reply-To: References: Message-ID: +1 > On Oct 25, 2018, at 4:33 PM, Iris Clark wrote: > > Hi. > > Please review changes to use "https" instead of "http" for links in the > generated JavaDoc API pages: > > 8212994: Links to Oracle websites should use "https:" > bug: https://bugs.openjdk.java.net/browse/JDK-8212994 > webrev: https://cr.openjdk.java.net/~iris/8212994/webrev/ > > I did a full "make docs" build and verified that the old links are > no longer in the created image. > > Thanks, > iris > > $ pwd > /u/iris/se/full-jdk/build/images > > $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/redist-137594.html" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/redist-137594.html" | wc -l > 20312 > > ## link in banner and footer > $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l > 40624 > > $ find . -name "*.html" -print | xargs grep "http://bugreport.java.com/bugreport/" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://bugreport.java.com/bugreport/" | wc -l > 20312 > > $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l > 0 > $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l > 20312 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From erik.joelsson at oracle.com Thu Oct 25 23:27:00 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Oct 2018 16:27:00 -0700 Subject: RFR: JDK-8213005: Missing symbols in hs_err files on Windows after JDK-8212028 Message-ID: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> When running tests through the new RunTest makefile framework in Mach5, we are now missing symbol information in hs_err files on Windows. This is caused by the new run-test-prebuilt target not properly setting up _NT_SYMBOL_PATH which in turn is caused by the variable CYGPATH not being set. This patch sets CYGPATH in RunTestPrebuiltSpec.gmk. I also modified some cosmetics in the _NT_SYMBOLS_PATH setup to make it easier to understand, at least for me. Verfied by running "run-test-prebuilt" with a fastdebug build and setting JTREG=JAVA_OPTIONS=-XX:ErrorHandlerTest=14. With the fix, the generated hs_err*.log contains symbols in the stacktrace. Bug: https://bugs.openjdk.java.net/browse/JDK-8213005 Webrev: http://cr.openjdk.java.net/~erikj/8213005/webrev.01/make/RunTests.gmk.sdiff.html /Erik From christian.tornqvist at oracle.com Thu Oct 25 23:48:07 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 25 Oct 2018 16:48:07 -0700 Subject: RFR: JDK-8213005: Missing symbols in hs_err files on Windows after JDK-8212028 In-Reply-To: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> References: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> Message-ID: Hi Erik, This looks good, thanks for fixing this! Thanks, Christian > On Oct 25, 2018, at 4:27 PM, Erik Joelsson wrote: > > When running tests through the new RunTest makefile framework in Mach5, we are now missing symbol information in hs_err files on Windows. This is caused by the new run-test-prebuilt target not properly setting up _NT_SYMBOL_PATH which in turn is caused by the variable CYGPATH not being set. > > This patch sets CYGPATH in RunTestPrebuiltSpec.gmk. I also modified some cosmetics in the _NT_SYMBOLS_PATH setup to make it easier to understand, at least for me. > > Verfied by running "run-test-prebuilt" with a fastdebug build and setting JTREG=JAVA_OPTIONS=-XX:ErrorHandlerTest=14. With the fix, the generated hs_err*.log contains symbols in the stacktrace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213005 > > Webrev: http://cr.openjdk.java.net/~erikj/8213005/webrev.01/make/RunTests.gmk.sdiff.html > > /Erik > From david.holmes at oracle.com Fri Oct 26 00:03:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Oct 2018 10:03:55 +1000 Subject: RFR: JDK-8213005: Missing symbols in hs_err files on Windows after JDK-8212028 In-Reply-To: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> References: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> Message-ID: Hi Erik, Thanks for jumping on this promptly and fixing it! On 26/10/2018 9:27 AM, Erik Joelsson wrote: > When running tests through the new RunTest makefile framework in Mach5, > we are now missing symbol information in hs_err files on Windows. This > is caused by the new run-test-prebuilt target not properly setting up > _NT_SYMBOL_PATH which in turn is caused by the variable CYGPATH not > being set. > > This patch sets CYGPATH in RunTestPrebuiltSpec.gmk. Looks good! > I also modified some > cosmetics in the _NT_SYMBOLS_PATH setup to make it easier to understand, > at least for me. Looks as indecipherable to me as it did before :) Thanks, David > Verfied by running "run-test-prebuilt" with a fastdebug build and > setting JTREG=JAVA_OPTIONS=-XX:ErrorHandlerTest=14. With the fix, the > generated hs_err*.log contains symbols in the stacktrace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213005 > > Webrev: > http://cr.openjdk.java.net/~erikj/8213005/webrev.01/make/RunTests.gmk.sdiff.html > > > /Erik > From iris.clark at oracle.com Fri Oct 26 00:07:54 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 25 Oct 2018 17:07:54 -0700 (PDT) Subject: RFR(XS): 8212994: Links to Oracle websites should use "https:" In-Reply-To: References: Message-ID: <26281880-eb66-4a3f-b0d1-ae070d130c3f@default> Hi, Lance and Erik. Thanks for the super-speedy reviews. Pushed. iris From: Lance Andersen Sent: Thursday, October 25, 2018 1:48 PM To: Iris Clark Cc: build-dev at openjdk.java.net; Jonathan Gibbons Subject: Re: RFR(XS): 8212994: Links to Oracle websites should use "https:" +1 On Oct 25, 2018, at 4:33 PM, Iris Clark wrote: Hi. Please review changes to use "https" instead of "http" for links in the generated JavaDoc API pages: 8212994: Links to Oracle websites should use "https:" bug: https://bugs.openjdk.java.net/browse/JDK-8212994 webrev: https://cr.openjdk.java.net/~iris/8212994/webrev/ I did a full "make docs" build and verified that the old links are no longer in the created image. Thanks, iris $ pwd /u/iris/se/full-jdk/build/images $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/redist-137594.html" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/redist-137594.html" | wc -l 20312 ## link in banner and footer $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/technetwork/java/javase/terms/license/java12speclicense.html" | wc -l 40624 $ find . -name "*.html" -print | xargs grep "http://bugreport.java.com/bugreport/" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://bugreport.java.com/bugreport/" | wc -l 20312 $ find . -name "*.html" -print | xargs grep "http://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l 0 $ find . -name "*.html" -print | xargs grep "https://www.oracle.com/pls/topic/lookup?ctx=javase12\&\;id=homepage" | wc -l 20312 http://oracle.com/us/design/oracle-email-sig-198324.gif HYPERLINK "http://oracle.com/us/design/oracle-email-sig-198324.gif" Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 HYPERLINK "mailto:Lance.Andersen at oracle.com"Lance.Andersen at oracle.com From mikael.vidstedt at oracle.com Fri Oct 26 08:00:13 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 26 Oct 2018 01:00:13 -0700 Subject: Building Portola JDK11 for AMR64 arch In-Reply-To: <1540038106268-0.post@n7.nabble.com> References: <1540038106268-0.post@n7.nabble.com> Message-ID: <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> It looks like the compiler doesn?t recognize the aarch64 instruction set, so configure probably picked up the wrong compiler. You?d have to double check what configure says it?s going to use. However, even if you address that it?s unlikely to work. As you probably know Alpine uses the musl C library, so your cross compiler/devkit needs to be able to produce binaries for musl. The ?-gnu? in your devkit path is a sign that it?s likely a devkit for the GNU C library. You?ll need to grab or create one for aarch64-linux-musl instead. For completeness I?ll mention that I have not tried the musl port on anything other than linux_x64, but I can?t think of anything that wouldn?t work on linux_aarch64. Cheers, Mikael > On Oct 20, 2018, at 5:21 AM, denusdv wrote: > > Hi all > > My purpose it to build JDK 11 Portola for ARM64 arch, I'm using x86 as a > build arch, > > 1. The boot SDK is built from the same source. > 2. The cross compile toolchain is > gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu > 3. The build is done in Alpine OS with glibc on it. > > My configure command looks > > ./configure --openjdk-target=aarch64-oe-linux > --with-boot-jdk=/work/jdk11/build/linux-x86_64-normal-server-release/jdk > --with-devkit=/tools/aarch64-toolchain/gcc-linaro-7.3.1-2 > 018.05-x86_64_aarch64-linux-gnu --disable-warnings-as-errors > --disable-sjavac > > The configure output has only one warning > > *WARNING: using cross tools not prefixed with host triplet* > > which I can't resolve. > > now when I try to run the make command > > I'm getting the following error > > /Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR > Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR > Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR > Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR > Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR > Compiling 188 files for BUILD_jdk.rmic.interim > Compiling 162 files for BUILD_TOOLS_JDK > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp: > Assembler messages: > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:116: > Error: no such instruction: `prfm pldl1strm,[%rdi,' > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:118: > Error: no such instruction: `adr %rax,0f' > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:118: > Error: number of operands mismatch for `add' > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:125: > Error: no such instruction: `prfm pldl1strm,[%rdi,' > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:127: > Error: no such instruction: `adr %rax,0f' > /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:127: > Error: number of operands mismatch for `add' > make[3]: *** [lib/CompileJvm.gmk:156: > /work/jdk11/build/linux-aarch64-normal-server-release/hotspot/variant-server/libjvm/objs/accessBackend.o] > Error 1 > make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 > make[2]: *** Waiting for unfinished jobs.... > / > > I know it's related to the cross compile process, pls help me to fix it. > > > > -- > Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Build-Infrastructure-f75522.html From mikael.vidstedt at oracle.com Fri Oct 26 08:20:38 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 26 Oct 2018 01:20:38 -0700 Subject: Building Portola JDK11 for AMR64 arch In-Reply-To: <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> References: <1540038106268-0.post@n7.nabble.com> <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> Message-ID: <314C8651-F97F-4B1B-8512-FA0C2013B115@oracle.com> > On Oct 26, 2018, at 1:00 AM, Mikael Vidstedt wrote: > > > > It looks like the compiler doesn?t recognize the aarch64 instruction set, so configure probably picked up the wrong compiler. You?d have to double check what configure says it?s going to use. > > However, even if you address that it?s unlikely to work. As you probably know Alpine uses the musl C library, so your cross compiler/devkit needs to be able to produce binaries for musl. The ?-gnu? in your devkit path is a sign that it?s likely a devkit for the GNU C library. You?ll need to grab or create one for aarch64-linux-musl instead. Sorry, this is wrong. I should have gone to sleep instead. The -gnu is of course for the build platform where the compiler is running, so given that you have glibc installed on your build machine that should work just fine. You do still need to make sure is that the cross compiler creates binaries for musl though. I?m not sure how the linaro devkit you?re using handles that. There may be some argument to gcc/g++ you need to specify if it doesn?t happen automatically. If some explicit argument is needed it would be nice to have the (portola) autoconf/make files do so automatically. Cheers, Mikael > > For completeness I?ll mention that I have not tried the musl port on anything other than linux_x64, but I can?t think of anything that wouldn?t work on linux_aarch64. > > Cheers, > Mikael > >> On Oct 20, 2018, at 5:21 AM, denusdv wrote: >> >> Hi all >> >> My purpose it to build JDK 11 Portola for ARM64 arch, I'm using x86 as a >> build arch, >> >> 1. The boot SDK is built from the same source. >> 2. The cross compile toolchain is >> gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu >> 3. The build is done in Alpine OS with glibc on it. >> >> My configure command looks >> >> ./configure --openjdk-target=aarch64-oe-linux >> --with-boot-jdk=/work/jdk11/build/linux-x86_64-normal-server-release/jdk >> --with-devkit=/tools/aarch64-toolchain/gcc-linaro-7.3.1-2 >> 018.05-x86_64_aarch64-linux-gnu --disable-warnings-as-errors >> --disable-sjavac >> >> The configure output has only one warning >> >> *WARNING: using cross tools not prefixed with host triplet* >> >> which I can't resolve. >> >> now when I try to run the make command >> >> I'm getting the following error >> >> /Compiling 3 files for BUILD_VM_COMPILER_MATCH_PROCESSOR >> Compiling 5 files for BUILD_VM_COMPILER_NODEINFO_PROCESSOR >> Compiling 3 files for BUILD_VM_COMPILER_OPTIONS_PROCESSOR >> Compiling 14 files for BUILD_VM_COMPILER_REPLACEMENTS_PROCESSOR >> Compiling 3 files for BUILD_VM_COMPILER_SERVICEPROVIDER_PROCESSOR >> Compiling 188 files for BUILD_jdk.rmic.interim >> Compiling 162 files for BUILD_TOOLS_JDK >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp: >> Assembler messages: >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:116: >> Error: no such instruction: `prfm pldl1strm,[%rdi,' >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:118: >> Error: no such instruction: `adr %rax,0f' >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:118: >> Error: number of operands mismatch for `add' >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:125: >> Error: no such instruction: `prfm pldl1strm,[%rdi,' >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:127: >> Error: no such instruction: `adr %rax,0f' >> /work/jdk11/src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.inline.hpp:127: >> Error: number of operands mismatch for `add' >> make[3]: *** [lib/CompileJvm.gmk:156: >> /work/jdk11/build/linux-aarch64-normal-server-release/hotspot/variant-server/libjvm/objs/accessBackend.o] >> Error 1 >> make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> / >> >> I know it's related to the cross compile process, pls help me to fix it. >> >> >> >> -- >> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Build-Infrastructure-f75522.html > From aph at redhat.com Fri Oct 26 08:36:33 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Oct 2018 09:36:33 +0100 Subject: Building Portola JDK11 for AMR64 arch In-Reply-To: <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> References: <1540038106268-0.post@n7.nabble.com> <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> Message-ID: <0c1bb9d7-2071-aead-a8a1-7b7592144774@redhat.com> On 10/26/2018 09:00 AM, Mikael Vidstedt wrote: > ./configure --openjdk-target=aarch64-oe-linux > --with-boot-jdk=/work/jdk11/build/linux-x86_64-normal-server-release/jdk > --with-devkit=/tools/aarch64-toolchain/gcc-linaro-7.3.1-2 > 018.05-x86_64_aarch64-linux-gnu --disable-warnings-as-errors > --disable-sjavac You need a sysroot in order to cross compile. It should be populated with the target libraries and headers. You need to set --target=TARGET . -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Fri Oct 26 10:29:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 26 Oct 2018 12:29:39 +0200 Subject: RFR: JDK-8213005: Missing symbols in hs_err files on Windows after JDK-8212028 In-Reply-To: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> References: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> Message-ID: I see that you've already pushed this fix. It looks good to me, I was just wondering about this: $(info _NT_SYMBOL_PATH=$(_NT_SYMBOL_PATH)) This was not added by your fix, but should we print this always? Looks like it should be guarded that the log level is info or below. /Magnus On 2018-10-26 01:27, Erik Joelsson wrote: > When running tests through the new RunTest makefile framework in > Mach5, we are now missing symbol information in hs_err files on > Windows. This is caused by the new run-test-prebuilt target not > properly setting up _NT_SYMBOL_PATH which in turn is caused by the > variable CYGPATH not being set. > > This patch sets CYGPATH in RunTestPrebuiltSpec.gmk. I also modified > some cosmetics in the _NT_SYMBOLS_PATH setup to make it easier to > understand, at least for me. > > Verfied by running "run-test-prebuilt" with a fastdebug build and > setting JTREG=JAVA_OPTIONS=-XX:ErrorHandlerTest=14. With the fix, the > generated hs_err*.log contains symbols in the stacktrace. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213005 > > Webrev: > http://cr.openjdk.java.net/~erikj/8213005/webrev.01/make/RunTests.gmk.sdiff.html > > /Erik > From shade at redhat.com Fri Oct 26 10:47:05 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Oct 2018 12:47:05 +0200 Subject: Building Portola JDK11 for AMR64 arch In-Reply-To: <0c1bb9d7-2071-aead-a8a1-7b7592144774@redhat.com> References: <1540038106268-0.post@n7.nabble.com> <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> <0c1bb9d7-2071-aead-a8a1-7b7592144774@redhat.com> Message-ID: <36966904-ee1f-5916-628a-2c3c0b792ff5@redhat.com> On 10/26/2018 10:36 AM, Andrew Haley wrote: > On 10/26/2018 09:00 AM, Mikael Vidstedt wrote: >> ./configure --openjdk-target=aarch64-oe-linux >> --with-boot-jdk=/work/jdk11/build/linux-x86_64-normal-server-release/jdk >> --with-devkit=/tools/aarch64-toolchain/gcc-linaro-7.3.1-2 >> 018.05-x86_64_aarch64-linux-gnu --disable-warnings-as-errors >> --disable-sjavac > > You need a sysroot in order to cross compile. It should be populated with the > target libraries and headers. Portola is definitely cross-compilable from x86_64: https://builds.shipilev.net/openjdk-portola/openjdk-portola-b4-jdk-12+15-linux-aarch64-fastdebug.configure.log https://builds.shipilev.net/openjdk-portola/openjdk-portola-b4-jdk-12+15-linux-aarch64-fastdebug.build.log It uses sysroot generated as per instruction: http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html#creating-and-using-sysroots-with-qemu-deboostrap -Aleksey From erik.joelsson at oracle.com Fri Oct 26 16:09:49 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Oct 2018 09:09:49 -0700 Subject: RFR: JDK-8213005: Missing symbols in hs_err files on Windows after JDK-8212028 In-Reply-To: References: <09771505-102f-6836-dd03-8d37efa6156c@oracle.com> Message-ID: <1093d4fa-8e24-980d-c4aa-ada7888b2294@oracle.com> On 2018-10-26 03:29, Magnus Ihse Bursie wrote: > > I see that you've already pushed this fix. It looks good to me, I was > just wondering about this: > > $(info _NT_SYMBOL_PATH=$(_NT_SYMBOL_PATH)) > This was not added by your fix, but should we print this always? Looks > like it should be guarded that the log level is info or below. > At this point you are right, it's not that interesting so we shouldn't always print it. /Erik > /Magnus > > On 2018-10-26 01:27, Erik Joelsson wrote: >> When running tests through the new RunTest makefile framework in >> Mach5, we are now missing symbol information in hs_err files on >> Windows. This is caused by the new run-test-prebuilt target not >> properly setting up _NT_SYMBOL_PATH which in turn is caused by the >> variable CYGPATH not being set. >> >> This patch sets CYGPATH in RunTestPrebuiltSpec.gmk. I also modified >> some cosmetics in the _NT_SYMBOLS_PATH setup to make it easier to >> understand, at least for me. >> >> Verfied by running "run-test-prebuilt" with a fastdebug build and >> setting JTREG=JAVA_OPTIONS=-XX:ErrorHandlerTest=14. With the fix, the >> generated hs_err*.log contains symbols in the stacktrace. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213005 >> >> Webrev: >> http://cr.openjdk.java.net/~erikj/8213005/webrev.01/make/RunTests.gmk.sdiff.html >> >> /Erik >> > From mikael.vidstedt at oracle.com Fri Oct 26 18:21:26 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 26 Oct 2018 11:21:26 -0700 Subject: Building Portola JDK11 for AMR64 arch In-Reply-To: <36966904-ee1f-5916-628a-2c3c0b792ff5@redhat.com> References: <1540038106268-0.post@n7.nabble.com> <96A6511E-9F16-45B2-9C93-669765F2A782@oracle.com> <0c1bb9d7-2071-aead-a8a1-7b7592144774@redhat.com> <36966904-ee1f-5916-628a-2c3c0b792ff5@redhat.com> Message-ID: <7975D922-8B04-4AB8-A407-3A5BEC29AA9F@oracle.com> > On Oct 26, 2018, at 3:47 AM, Aleksey Shipilev wrote: > > On 10/26/2018 10:36 AM, Andrew Haley wrote: >> On 10/26/2018 09:00 AM, Mikael Vidstedt wrote: >>> ./configure --openjdk-target=aarch64-oe-linux >>> --with-boot-jdk=/work/jdk11/build/linux-x86_64-normal-server-release/jdk >>> --with-devkit=/tools/aarch64-toolchain/gcc-linaro-7.3.1-2 >>> 018.05-x86_64_aarch64-linux-gnu --disable-warnings-as-errors >>> --disable-sjavac >> >> You need a sysroot in order to cross compile. It should be populated with the >> target libraries and headers. > > Portola is definitely cross-compilable from x86_64: > > https://builds.shipilev.net/openjdk-portola/openjdk-portola-b4-jdk-12+15-linux-aarch64-fastdebug.configure.log > > https://builds.shipilev.net/openjdk-portola/openjdk-portola-b4-jdk-12+15-linux-aarch64-fastdebug.build.log > > It uses sysroot generated as per instruction: > > http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html#creating-and-using-sysroots-with-qemu-deboostrap Thanks for confirming, Aleksey! Cheers, Mikael From jonathan.gibbons at oracle.com Mon Oct 29 18:57:38 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 29 Oct 2018 11:57:38 -0700 Subject: RFR: XXS: JDK-8213102: Oracle Unilinks are [301 Moved Permanently] to https://docs.oracle.com Message-ID: Please review the following simple fix to change the host for Oracle Unilinks from www.oracle.com to docs.oracle.com to avoid unnecessary redirects. JBS: https://bugs.openjdk.java.net/browse/JDK-8213102 The fix was done with the following command: grep -rl oracle.com/pls open/make | xargs sed --in-place 's|www.oracle.com/pls|docs.oracle.com/pls|g' -- Jon Patch inline: $ hg diff -R open diff -r 3152b928769d make/Docs.gmk --- a/make/Docs.gmk???? Mon Oct 29 11:05:45 2018 -0700 +++ b/make/Docs.gmk???? Mon Oct 29 11:45:11 2018 -0700 @@ -61,7 +61,7 @@ ???? $(SUPPORT_OUTPUTDIR)/rmic/* $(TOPDIR)/src/*/share/doc/stub) ?# URLs -JAVADOC_BASE_URL := https://www.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage +JAVADOC_BASE_URL := https://docs.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage ?BUG_SUBMIT_URL := https://bugreport.java.com/bugreport/ ?COPYRIGHT_URL := {@docroot}/../legal/copyright.html ?LICENSE_URL := https://www.oracle.com/technetwork/java/javase/terms/license/java$(VERSION_NUMBER)speclicense.html diff -r 3152b928769d make/jdk/src/classes/build/tools/taglet/ExtLink.java --- a/make/jdk/src/classes/build/tools/taglet/ExtLink.java????? Mon Oct 29 11:05:45 2018 -0700 +++ b/make/jdk/src/classes/build/tools/taglet/ExtLink.java????? Mon Oct 29 11:45:11 2018 -0700 @@ -48,7 +48,7 @@ ? * will produce the following html ? *

? * {@code - * Please see a spectacular sight. + * Please see a spectacular sight. ? * } ? */ ?public class ExtLink implements Taglet { @@ -63,7 +63,7 @@ ???? static final String TAG_NAME = "extLink"; -??? static final String URL = "https://www.oracle.com/pls/topic/lookup?ctx=javase" + +??? static final String URL = "https://docs.oracle.com/pls/topic/lookup?ctx=javase" + ???????? SPEC_VERSION + "&id="; ???? static final Pattern TAG_PATTERN = Pattern.compile("(?s)(\\s*)(?\\w+)(\\s+)(?.*)$"); From lance.andersen at oracle.com Mon Oct 29 19:03:45 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 29 Oct 2018 15:03:45 -0400 Subject: RFR: XXS: JDK-8213102: Oracle Unilinks are [301 Moved Permanently] to https://docs.oracle.com In-Reply-To: References: Message-ID: <337818DC-4ED7-495C-AEE2-2988DD82AE80@oracle.com> looks fine jon > On Oct 29, 2018, at 2:57 PM, Jonathan Gibbons wrote: > > Please review the following simple fix to change the host for Oracle Unilinks from www.oracle.com to docs.oracle.com to avoid unnecessary redirects. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213102 > > The fix was done with the following command: > > grep -rl oracle.com/pls open/make | xargs sed --in-place 's|www.oracle.com/pls|docs.oracle.com/pls|g' > > -- Jon > > > Patch inline: > > $ hg diff -R open > diff -r 3152b928769d make/Docs.gmk > --- a/make/Docs.gmk Mon Oct 29 11:05:45 2018 -0700 > +++ b/make/Docs.gmk Mon Oct 29 11:45:11 2018 -0700 > @@ -61,7 +61,7 @@ > $(SUPPORT_OUTPUTDIR)/rmic/* $(TOPDIR)/src/*/share/doc/stub) > > # URLs > -JAVADOC_BASE_URL := https://www.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage > +JAVADOC_BASE_URL := https://docs.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage > BUG_SUBMIT_URL := https://bugreport.java.com/bugreport/ > COPYRIGHT_URL := {@docroot}/../legal/copyright.html > LICENSE_URL := https://www.oracle.com/technetwork/java/javase/terms/license/java$(VERSION_NUMBER)speclicense.html > diff -r 3152b928769d make/jdk/src/classes/build/tools/taglet/ExtLink.java > --- a/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29 11:05:45 2018 -0700 > +++ b/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29 11:45:11 2018 -0700 > @@ -48,7 +48,7 @@ > * will produce the following html > *

> * {@code > - * Please see a spectacular sight. > + * Please see a spectacular sight. > * } > */ > public class ExtLink implements Taglet { > @@ -63,7 +63,7 @@ > > static final String TAG_NAME = "extLink"; > > - static final String URL = "https://www.oracle.com/pls/topic/lookup?ctx=javase" + > + static final String URL = "https://docs.oracle.com/pls/topic/lookup?ctx=javase" + > SPEC_VERSION + "&id="; > > static final Pattern TAG_PATTERN = Pattern.compile("(?s)(\\s*)(?\\w+)(\\s+)(?.*)$"); > 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 mandy.chung at oracle.com Mon Oct 29 19:24:14 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Oct 2018 12:24:14 -0700 Subject: RFR: XXS: JDK-8213102: Oracle Unilinks are [301 Moved Permanently] to https://docs.oracle.com In-Reply-To: References: Message-ID: <5cc4e639-4583-e1fd-3d5f-d818eda02e06@oracle.com> +1 Mandy On 10/29/18 11:57 AM, Jonathan Gibbons wrote: > Please review the following simple fix to change the host for Oracle > Unilinks from www.oracle.com to docs.oracle.com to avoid unnecessary > redirects. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213102 > > The fix was done with the following command: > > grep -rl oracle.com/pls open/make | xargs sed --in-place > 's|www.oracle.com/pls|docs.oracle.com/pls|g' > > -- Jon > > > Patch inline: > > $ hg diff -R open > diff -r 3152b928769d make/Docs.gmk > --- a/make/Docs.gmk???? Mon Oct 29 11:05:45 2018 -0700 > +++ b/make/Docs.gmk???? Mon Oct 29 11:45:11 2018 -0700 > @@ -61,7 +61,7 @@ > ???? $(SUPPORT_OUTPUTDIR)/rmic/* $(TOPDIR)/src/*/share/doc/stub) > > ?# URLs > -JAVADOC_BASE_URL := > https://www.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage > +JAVADOC_BASE_URL := > https://docs.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage > ?BUG_SUBMIT_URL := https://bugreport.java.com/bugreport/ > ?COPYRIGHT_URL := {@docroot}/../legal/copyright.html > ?LICENSE_URL := > https://www.oracle.com/technetwork/java/javase/terms/license/java$(VERSION_NUMBER)speclicense.html > diff -r 3152b928769d make/jdk/src/classes/build/tools/taglet/ExtLink.java > --- a/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29 > 11:05:45 2018 -0700 > +++ b/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29 > 11:45:11 2018 -0700 > @@ -48,7 +48,7 @@ > ? * will produce the following html > ? *

> ? * {@code > - * Please see href="https://www.oracle.com/pls/topic/lookup?ctx=javase10&id=Borealis">a > spectacular sight. > + * Please see href="https://docs.oracle.com/pls/topic/lookup?ctx=javase10&id=Borealis">a > spectacular sight. > ? * } > ? */ > ?public class ExtLink implements Taglet { > @@ -63,7 +63,7 @@ > > ???? static final String TAG_NAME = "extLink"; > > -??? static final String URL = > "https://www.oracle.com/pls/topic/lookup?ctx=javase" + > +??? static final String URL = > "https://docs.oracle.com/pls/topic/lookup?ctx=javase" + > ???????? SPEC_VERSION + "&id="; > > ???? static final Pattern TAG_PATTERN = > Pattern.compile("(?s)(\\s*)(?\\w+)(\\s+)(?.*)$"); > From erik.joelsson at oracle.com Mon Oct 29 20:05:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Oct 2018 13:05:17 -0700 Subject: RFR: XXS: JDK-8213102: Oracle Unilinks are [301 Moved Permanently] to https://docs.oracle.com In-Reply-To: References: Message-ID: <0507daf1-1015-047a-8617-f39a33ee95be@oracle.com> Looks good. /Erik On 2018-10-29 11:57, Jonathan Gibbons wrote: > Please review the following simple fix to change the host for Oracle > Unilinks from www.oracle.com to docs.oracle.com to avoid unnecessary > redirects. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213102 > > The fix was done with the following command: > > grep -rl oracle.com/pls open/make | xargs sed --in-place > 's|www.oracle.com/pls|docs.oracle.com/pls|g' > > -- Jon > > > Patch inline: > > $ hg diff -R open > diff -r 3152b928769d make/Docs.gmk > --- a/make/Docs.gmk???? Mon Oct 29 11:05:45 2018 -0700 > +++ b/make/Docs.gmk???? Mon Oct 29 11:45:11 2018 -0700 > @@ -61,7 +61,7 @@ > ???? $(SUPPORT_OUTPUTDIR)/rmic/* $(TOPDIR)/src/*/share/doc/stub) > > ?# URLs > -JAVADOC_BASE_URL := > https://www.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage > +JAVADOC_BASE_URL := > https://docs.oracle.com/pls/topic/lookup?ctx=javase$(VERSION_NUMBER)&id=homepage > ?BUG_SUBMIT_URL := https://bugreport.java.com/bugreport/ > ?COPYRIGHT_URL := {@docroot}/../legal/copyright.html > ?LICENSE_URL := > https://www.oracle.com/technetwork/java/javase/terms/license/java$(VERSION_NUMBER)speclicense.html > diff -r 3152b928769d make/jdk/src/classes/build/tools/taglet/ExtLink.java > --- a/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29 > 11:05:45 2018 -0700 > +++ b/make/jdk/src/classes/build/tools/taglet/ExtLink.java Mon Oct 29 > 11:45:11 2018 -0700 > @@ -48,7 +48,7 @@ > ? * will produce the following html > ? *

> ? * {@code > - * Please see href="https://www.oracle.com/pls/topic/lookup?ctx=javase10&id=Borealis">a > spectacular sight. > + * Please see href="https://docs.oracle.com/pls/topic/lookup?ctx=javase10&id=Borealis">a > spectacular sight. > ? * } > ? */ > ?public class ExtLink implements Taglet { > @@ -63,7 +63,7 @@ > > ???? static final String TAG_NAME = "extLink"; > > -??? static final String URL = > "https://www.oracle.com/pls/topic/lookup?ctx=javase" + > +??? static final String URL = > "https://docs.oracle.com/pls/topic/lookup?ctx=javase" + > ???????? SPEC_VERSION + "&id="; > > ???? static final Pattern TAG_PATTERN = > Pattern.compile("(?s)(\\s*)(?\\w+)(\\s+)(?.*)$"); > From ekaterina.pavlova at oracle.com Mon Oct 29 20:24:06 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Mon, 29 Oct 2018 13:24:06 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: <62df0d36-014a-0d4e-fd1b-b014736452a9@oracle.com> References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> <9679369c-e159-feef-ccc7-f2f72ff5b1d7@oracle.com> <62df0d36-014a-0d4e-fd1b-b014736452a9@oracle.com> Message-ID: Vladimir, I added "-XX:+UseAOTStrictLoading" to "java -version", see make/RunTests.gmk. Also added "--compile-with-assertion" to jaotc flags in case "-ea" flag was present in vm options (otherwise AOTed library will warn that it does not have java assertions in compiled code). I will add -XX:+UseAOTStrictLoading and "-Xlog:aot+class+fingerprint=trace -Xlog:aot+class+load=trace" directly to AOT testing tasks in mach5 jobs. Magnus, I changed "$$(addprefix -vmoption:, $$($1_AOT_OPTIONS))" to + ifneq ($$($1_AOT_OPTIONS), ) + $1_JTREG_BASIC_OPTIONS += -vmoptions:"$$($1_AOT_OPTIONS)" + endif Please review updated webrev: http://cr.openjdk.java.net/~epavlova//8152988/webrev.01/ thanks, -katya On 10/23/18 4:40 PM, Vladimir Kozlov wrote: > On 10/22/18 9:36 AM, Ekaterina Pavlova wrote: >> Vladimir, >> >> thanks a lot for the review. >> "-XX:+PrintAOT" was only passed to "java -version" which is done before the testing to verify that AOTed libraries work. > > If it is only for -version then using? -XX:+PrintAOT is okay. > >> It also perhaps could be useful debug info in case some tests starts fail. >> But I can change -XX:+PrintAOT to -XX:+UseAOTStrictLoading if you think it is more than enough. > > -XX:+UseAOTStrictLoading is more important for tests which have different flags specified and may invalidate AOTLibrary configuration. We would want to catch tests which will not use AOT libraries. At least when we test these your changes. > >> >> Do you suggest to add "-Xlog:aot+class+fingerprint=trace -Xlog:aot+class+load=trace" to "java -version" only >> or to java flags used during tests execution as well? > > These options are next step after -XX:+UseAOTStrictLoading. We were asked before how we can guarantee that AOTed methods are used by tests. One way is PrintAOT which should show published AOT methods. An other way is Xlogs flags which have less output but provide at least some level of information that AOTed classes are used and not skipped. > > Thanks, > Vladimir > >> >> >> -katya >> >> On 10/19/18 10:40 AM, Vladimir Kozlov wrote: >>> I share concern about output of -XX:+PrintAOT - it prints all AOT classes and methods. For AOTed java.base the output will be almost the same for all tests (depends which are java.base classes are used). >>> >>> I would suggest instead to use -XX:+UseAOTStrictLoading which exit(1) VM if it can't load AOT library for some reason (mismatched configuration - different GCs). >>> >>> Also -Xlog:aot+class+fingerprint=trace? to trace cases of mismatching class fingerprint. >>> Also -Xlog:aot+class+load=trace -to trace AOT class loading or skipping them if they are not matching. >>> >>> And I agree to redirect this into file. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/19/18 9:04 AM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I will answer the parts I'm responsible for. >>>> >>>> On 2018-10-19 00:21, Magnus Ihse Bursie wrote: >>>>> >>>>> In RunTests.gmk, the following line is repeated: >>>>> # Note, this could not be done during JDK build time. >>>>> >>>>> In the options: >>>>> $1_JAOTC_OPTS := \ >>>>> -J-Xmx4g --info \ >>>>> -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines with too little free memory. Will AOT fail to work with less memory? >>>>> >>>>> >>>>> There's an extra space before the comma here: >>>>> $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ >>>>> Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a convenient way to just add "--compile-commands " if it exists? I was a bit confounded at first since normally we only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST to ever be more than one item. >>>>> >>>> Yes, that was the intention. I often use addprefix that way and find it convenient that it seamlessly handles 0-N number of elements in the argument without the need for cumbersome conditionals. The extra space is needed in this case but should perhaps be explicit using $(SPACE). >>>>> >>>>> About this: >>>>> # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. >>>>> $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) >>>>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>>>> $$($1_JVM_OPTIONS) \ >>>>> -XX:+PrintAOT -XX:AOTLibrary=$$@ -version >>>>> First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a lot of "java -version" being printed at the time when running tests. Perhaps the output should be redirected? (Assuming that java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this would help otherwise.) >>>>> >>>> My guess is that they want diagnostics saved in case tests fail. >>>>> Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to be different. E.g: >>>>> $$(call ExecuteWithLog, $$@_verify, \ >>>>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>>>> ??????? ... >>>>> >>>> The issue I'm referring to is that the $(info) line in ExecuteWithLog will print the commands first, then execute the first line of the recipe. This makes the output confusing since both of those commands print (what I'm assuming is) relevant diagnostics information. This is simply a consequence of using $(info) for printing the command line. Make will evaluate all the recipe lines first, then execute them one by one. To be clear, it ends up like this: >>>> >>>> Executing [jaotc ...] >>>> Executing [java ...] >>>> >>>> >>>>> >>>>> Further, >>>>> SetupAot = $(NamedParamsMacroTemplate) >>>>> define SetupAotBody >>>>> ifneq ($$($1_MODULES), ) >>>>> ... >>>>> If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally called, but does nothing if AOT is not used. I think that looks odd. >>>>> >>>> My goal was to minimize the repeated code at each call site. While developing this, I had a lot more duplication at first, and it was a hassle to update each location every time I needed to change something. Other than that I don't feel strongly for either construct. >>>>> >>>>> And here, >>>>> - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) >>>>> + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) >>>>> I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) >>>>> >>>> I added the TEST_PREREQS variable to support the CDS archive generation, which was recently removed. With the way SetupAot turned out to need separate calls from each SetupTestRun, the global TEST_PREREQS wasn't suitable. I don't know of any current need for a general TEST_PREREQS. >>>>> >>>>> Finally: >>>>> + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ >>>>> I'm not really comfortable with this use of addprefix. I think a construct like: >>>>> ifneq ($$($1_AOT_OPTIONS), ) >>>>> ?? $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) >>>>> endif >>>>> would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but that's not as important. >>>>> >>>> I agree. >>>> >>>> /Erik >>>>> >>>>> The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) >>>>> >>>>> /Magnus >>>>> >>>>>> testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base jdk.internal.vm.compiler >>>>>> ???????? with "make run-test" and in Mach5. >>>>>> >>>>>> thanks, >>>>>> -katya >>>>>> >>>>>> p.s. >>>>>> ?Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) >>>>>> ?to new one (make/RunTests*). >>>>>> >>>>>> >>>>> >>>> >> From vladimir.kozlov at oracle.com Mon Oct 29 21:15:11 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 29 Oct 2018 14:15:11 -0700 Subject: RFR(M) 8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing In-Reply-To: References: <39a601df-d637-b37e-ca39-c2173527aafe@oracle.com> <5d6d1e81-5c5a-e4b3-b0c9-08c278db7477@oracle.com> <9d22aea4-88ec-ca50-6ed5-cf92da4d5920@oracle.com> <9679369c-e159-feef-ccc7-f2f72ff5b1d7@oracle.com> <62df0d36-014a-0d4e-fd1b-b014736452a9@oracle.com> Message-ID: <52333435-e3f2-9beb-e4de-b0a2f614e966@oracle.com> Looks good to me. thanks, Vladimir On 10/29/18 1:24 PM, Ekaterina Pavlova wrote: > Vladimir, > I added "-XX:+UseAOTStrictLoading" to "java -version", see make/RunTests.gmk. > Also added "--compile-with-assertion" to jaotc flags in case "-ea" flag was present in vm options > (otherwise AOTed library will warn that it does not have java assertions in compiled code). > > I will add -XX:+UseAOTStrictLoading and "-Xlog:aot+class+fingerprint=trace -Xlog:aot+class+load=trace" > directly to AOT testing tasks in mach5 jobs. > > Magnus, > I changed > ?"$$(addprefix -vmoption:, $$($1_AOT_OPTIONS))" > to > +? ifneq ($$($1_AOT_OPTIONS), ) > +??? $1_JTREG_BASIC_OPTIONS += -vmoptions:"$$($1_AOT_OPTIONS)" > +? endif > > Please review updated webrev: > ?http://cr.openjdk.java.net/~epavlova//8152988/webrev.01/ > > thanks, > -katya > > > On 10/23/18 4:40 PM, Vladimir Kozlov wrote: >> On 10/22/18 9:36 AM, Ekaterina Pavlova wrote: >>> Vladimir, >>> >>> thanks a lot for the review. >>> "-XX:+PrintAOT" was only passed to "java -version" which is done before the testing to verify that AOTed libraries work. >> >> If it is only for -version then using? -XX:+PrintAOT is okay. >> >>> It also perhaps could be useful debug info in case some tests starts fail. >>> But I can change -XX:+PrintAOT to -XX:+UseAOTStrictLoading if you think it is more than enough. >> >> -XX:+UseAOTStrictLoading is more important for tests which have different flags specified and may invalidate >> AOTLibrary configuration. We would want to catch tests which will not use AOT libraries. At least when we test these >> your changes. >> >>> >>> Do you suggest to add "-Xlog:aot+class+fingerprint=trace -Xlog:aot+class+load=trace" to "java -version" only >>> or to java flags used during tests execution as well? >> >> These options are next step after -XX:+UseAOTStrictLoading. We were asked before how we can guarantee that AOTed >> methods are used by tests. One way is PrintAOT which should show published AOT methods. An other way is Xlogs flags >> which have less output but provide at least some level of information that AOTed classes are used and not skipped. >> >> Thanks, >> Vladimir >> >>> >>> >>> -katya >>> >>> On 10/19/18 10:40 AM, Vladimir Kozlov wrote: >>>> I share concern about output of -XX:+PrintAOT - it prints all AOT classes and methods. For AOTed java.base the >>>> output will be almost the same for all tests (depends which are java.base classes are used). >>>> >>>> I would suggest instead to use -XX:+UseAOTStrictLoading which exit(1) VM if it can't load AOT library for some >>>> reason (mismatched configuration - different GCs). >>>> >>>> Also -Xlog:aot+class+fingerprint=trace? to trace cases of mismatching class fingerprint. >>>> Also -Xlog:aot+class+load=trace -to trace AOT class loading or skipping them if they are not matching. >>>> >>>> And I agree to redirect this into file. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/19/18 9:04 AM, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> I will answer the parts I'm responsible for. >>>>> >>>>> On 2018-10-19 00:21, Magnus Ihse Bursie wrote: >>>>>> >>>>>> In RunTests.gmk, the following line is repeated: >>>>>> # Note, this could not be done during JDK build time. >>>>>> >>>>>> In the options: >>>>>> $1_JAOTC_OPTS := \ >>>>>> -J-Xmx4g --info \ >>>>>> -Xmx4g is huge, much larger than what we typically use. Is this intentional? This will risk crashing at machines >>>>>> with too little free memory. Will AOT fail to work with less memory? >>>>>> >>>>>> >>>>>> There's an extra space before the comma here: >>>>>> $$(addprefix --compile-commands , $$($1_AOT_CCLIST)) \ >>>>>> Question (to Erik, I presume): the idea of addprefix here is that AOT_CCLIST can be empty, and this was a >>>>>> convenient way to just add "--compile-commands " if it exists? I was a bit confounded at first >>>>>> since normally we only use it for distributing a prefix over multiple items, and I could see no way for AOT_CCLIST >>>>>> to ever be more than one item. >>>>>> >>>>> Yes, that was the intention. I often use addprefix that way and find it convenient that it seamlessly handles 0-N >>>>> number of elements in the argument without the need for cumbersome conditionals. The extra space is needed in this >>>>> case but should perhaps be explicit using $(SPACE). >>>>>> >>>>>> About this: >>>>>> # Note, ExecuteWithLog doesn't play well with with two calls in the same recipe. >>>>>> $$(info $$(JDK_IMAGE_DIR)/bin/java $$($1_JVM_OPTIONS) -XX:+PrintAOT -XX:AOTLibrary=$$@ -version) >>>>>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>>>>> $$($1_JVM_OPTIONS) \ >>>>>> -XX:+PrintAOT -XX:AOTLibrary=$$@ -version >>>>>> First, what is the purpose of this? Is it to verify that the generated AOT library works? This will result in a >>>>>> lot of "java -version" being printed at the time when running tests. Perhaps the output should be redirected? >>>>>> (Assuming that java exists with a non-zero exit value if things fail, but if it does not, I'm not sure how this >>>>>> would help otherwise.) >>>>>> >>>>> My guess is that they want diagnostics saved in case tests fail. >>>>>> Second, there's no problem to use multiple ExecuteWithLog in the same recipe, however, the base variable needs to >>>>>> be different. E.g: >>>>>> $$(call ExecuteWithLog, $$@_verify, \ >>>>>> $$(FIXPATH) $$(JDK_IMAGE_DIR)/bin/java \ >>>>>> ??????? ... >>>>>> >>>>> The issue I'm referring to is that the $(info) line in ExecuteWithLog will print the commands first, then execute >>>>> the first line of the recipe. This makes the output confusing since both of those commands print (what I'm assuming >>>>> is) relevant diagnostics information. This is simply a consequence of using $(info) for printing the command line. >>>>> Make will evaluate all the recipe lines first, then execute them one by one. To be clear, it ends up like this: >>>>> >>>>> Executing [jaotc ...] >>>>> Executing [java ...] >>>>> >>>>> >>>>>> >>>>>> Further, >>>>>> SetupAot = $(NamedParamsMacroTemplate) >>>>>> define SetupAotBody >>>>>> ifneq ($$($1_MODULES), ) >>>>>> ... >>>>>> If think it would be clearer if the if-test is on the call site for SetupAot instead. Now it's unconditionally >>>>>> called, but does nothing if AOT is not used. I think that looks odd. >>>>>> >>>>> My goal was to minimize the repeated code at each call site. While developing this, I had a lot more duplication at >>>>> first, and it was a hassle to update each location every time I needed to change something. Other than that I don't >>>>> feel strongly for either construct. >>>>>> >>>>>> And here, >>>>>> - run-test-$1: clean-workdir-$1 $(TEST_PREREQS) >>>>>> + run-test-$1: clean-workdir-$1 $$($1_AOT_TARGETS) >>>>>> I don't think you can just remove TEST_PREREQS like that..? (The same goes for the other run-test-$1 instance.) >>>>>> >>>>> I added the TEST_PREREQS variable to support the CDS archive generation, which was recently removed. With the way >>>>> SetupAot turned out to need separate calls from each SetupTestRun, the global TEST_PREREQS wasn't suitable. I don't >>>>> know of any current need for a general TEST_PREREQS. >>>>>> >>>>>> Finally: >>>>>> + $$(addprefix -vmoption:, $$($1_AOT_OPTIONS)) \ >>>>>> I'm not really comfortable with this use of addprefix. I think a construct like: >>>>>> ifneq ($$($1_AOT_OPTIONS), ) >>>>>> ?? $1_JTREG_BASIC_OPTIONS += -vmoption:$$($1_AOT_OPTIONS) >>>>>> endif >>>>>> would be much clearar. Ideally, I'd like to see the same construct in the SetupAotModule function as well, but >>>>>> that's not as important. >>>>>> >>>>> I agree. >>>>> >>>>> /Erik >>>>>> >>>>>> The rest of the build changes look good. (I can't say anything about the test/**/*-list.txt files.) >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> testing: Tested by running subset of hotspot, jdk and jck tests with TEST_OPTS_AOT_MODULES=java.base >>>>>>> jdk.internal.vm.compiler >>>>>>> ???????? with "make run-test" and in Mach5. >>>>>>> >>>>>>> thanks, >>>>>>> -katya >>>>>>> >>>>>>> p.s. >>>>>>> ?Thanks a lot Erik for huge help with porting original patch done in old testing framework (test/TestCommon.gmk) >>>>>>> ?to new one (make/RunTests*). >>>>>>> >>>>>>> >>>>>> >>>>> >>> > From magnus.ihse.bursie at oracle.com Tue Oct 30 07:41:14 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 30 Oct 2018 08:41:14 +0100 Subject: RFR: JDK-8210958 Rename "make run-test" to "make test" In-Reply-To: <5585e05f-d68b-69d6-36a3-75448c030434@oracle.com> References: <52043217-40a9-9508-8cdf-7ac7ad4178a3@oracle.com> <411fd7f7-fa61-f827-c898-a5a4929abedf@oracle.com> <5585e05f-d68b-69d6-36a3-75448c030434@oracle.com> Message-ID: On 2018-10-23 10:45, Magnus Ihse Bursie wrote: > On 2018-10-19 18:11, Erik Joelsson wrote: > >> Looks good, and thanks for fixing test-make. I found the same issue >> today. >> >> Could you also change the make target we call for >> run-test/run-test-prebuilt profiles in jib-profiles.js? > > There's no target for run-test in jib-profiles.js; only for > run-test-prebuilt (as far as I can understand, at least). I've updated > this, and I also renamed all references to "run-test" to just "test". > Maybe this was going too far. Let me know if you want me to revert > that part. > > Updated webrev (only jib-profiles.js has changed): > > http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.03 > By way of private discussion, I learned that this had a bit too much repercussions. I've reverted the change to jib-profiles.js, and only changed the name of the target. New webrev: http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.04 (only change is in jib-profiles.js) /Magnus > > /Magnus >> >> /Erik >> >> >> On 2018-10-19 05:32, Magnus Ihse Bursie wrote: >>> Now that JDK-8212028 is pushed, it's time to revisit this. >>> >>> In the meantime, the compile-command test had been added, which >>> caused me to realize some better handling of the make tests were >>> needed. These fixes are also included. Now "make test-make" will run >>> all build system tests with proper dependencies. >>> >>> I also fixed a test in TestMakeBase.gmk which became broken with >>> JDK-8212028. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.02 >>> >>> >>> /Magnus >>> >>> >>> On 2018-09-20 12:47, Magnus Ihse Bursie wrote: >>>> The time has come to start phasing out the old test running >>>> framework ("cd test && make"). This patch will change the behavior >>>> of "make test" to use the new run-test framework, instead of the old. >>>> >>>> The old framework is still available as of now by using "cd test && >>>> make". >>>> >>>> The "run-test" target (and variants like exploded-run-test or >>>> run-test-tier1) are kept as aliases. >>>> >>>> Using "cd test && make" will result in a warning being printed that >>>> it is recommended to stop using this way of running tests. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210958 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.01 >>>> >>>> /Magnus >>>> >>> >> > From bob.vandette at oracle.com Tue Oct 30 14:56:36 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 30 Oct 2018 10:56:36 -0400 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> <5BA38920.8020203@cjnash.com> Message-ID: <43E51870-3583-42A1-B1A3-CFD86CF975A0@oracle.com> This JEP is now targeted to JDK 12. I?ve merged up to the latest sources and will be integrating these changes in the next day or two. Here?s the latest webrev post merge in the event anyone spots any last minute issues. http://cr.openjdk.java.net/~bobv/8209093/webrev.02 Bob,. From andy.herrick at oracle.com Tue Oct 30 14:11:36 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 30 Oct 2018 10:11:36 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> On 10/24/2018 10:22 AM, Alan Bateman wrote: > On 23/10/2018 16:49, Andy Herrick wrote: >> This patch implements the Java Packager Tool (jpackager) as described >> in JEP 343: Packaging Tool >> >> >> jpackager is a simple packaging tool, based on the JavaFX >> |javapackager| tool, that: >> >> ?* Supports native packaging formats to give the end user a natural >> ?? installation experience. These formats include |msi| and |exe| on >> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >> ?* Allows launch-time parameters to be specified at packaging time. >> ?* Can be invoked directly, from the command line, or programmatically, >> ?? via the |ToolProvider| API. >> >> Webrev: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >> > cc'ing build-dev as it's important to get it reviewed there. > > What is the plan for tests to go with this tool? I see there is one > test in the webrev to do some argument validation but I don't see > anything else right now. We plan to incorporate the initial feedback from this review, and include an initial set of automated tests in a refresh sometime next week. We will continue to develop and automate tests for future updates. > > What is the status of the JNLPConverter tool? I see it is included as > a "demo" but maybe it would be better to host somewhere else as this > is for developers migrating Java Web Start applications. Our current plan is to deliver it only as a demo. > > Would it be possible to update the JEP with all the CLI options? That > would be useful for review and also useful for those invoking it with > the ToolProvider API. Done. > > If I read the webrev correctly then it adds two modules, one with the > jpackager tool and the other with an API. It would be useful to get a > bit more information on the split. Also I think the name of the API > module and the package that it exports needs discussion to make sure > that the right names are chosen. Yes - though we are currently using jdk.packager.services, we are open to other suggestions as the name for these. "jdk.packager.runtime" has also been suggested. > > -Alan /Andy From erik.joelsson at oracle.com Tue Oct 30 15:30:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Oct 2018 08:30:25 -0700 Subject: RFR: JDK-8210958 Rename "make run-test" to "make test" In-Reply-To: References: <52043217-40a9-9508-8cdf-7ac7ad4178a3@oracle.com> <411fd7f7-fa61-f827-c898-a5a4929abedf@oracle.com> <5585e05f-d68b-69d6-36a3-75448c030434@oracle.com> Message-ID: Looks good. /Erik On 2018-10-30 00:41, Magnus Ihse Bursie wrote: > On 2018-10-23 10:45, Magnus Ihse Bursie wrote: > >> On 2018-10-19 18:11, Erik Joelsson wrote: >> >>> Looks good, and thanks for fixing test-make. I found the same issue >>> today. >>> >>> Could you also change the make target we call for >>> run-test/run-test-prebuilt profiles in jib-profiles.js? >> >> There's no target for run-test in jib-profiles.js; only for >> run-test-prebuilt (as far as I can understand, at least). I've >> updated this, and I also renamed all references to "run-test" to just >> "test". Maybe this was going too far. Let me know if you want me to >> revert that part. >> >> Updated webrev (only jib-profiles.js has changed): >> >> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.03 >> > By way of private discussion, I learned that this had a bit too much > repercussions. I've reverted the change to jib-profiles.js, and only > changed the name of the target. > > New webrev: > http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.04 > > > (only change is in jib-profiles.js) > > /Magnus > >> >> /Magnus >>> >>> /Erik >>> >>> >>> On 2018-10-19 05:32, Magnus Ihse Bursie wrote: >>>> Now that JDK-8212028 is pushed, it's time to revisit this. >>>> >>>> In the meantime, the compile-command test had been added, which >>>> caused me to realize some better handling of the make tests were >>>> needed. These fixes are also included. Now "make test-make" will >>>> run all build system tests with proper dependencies. >>>> >>>> I also fixed a test in TestMakeBase.gmk which became broken with >>>> JDK-8212028. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.02 >>>> >>>> >>>> /Magnus >>>> >>>> >>>> On 2018-09-20 12:47, Magnus Ihse Bursie wrote: >>>>> The time has come to start phasing out the old test running >>>>> framework ("cd test && make"). This patch will change the behavior >>>>> of "make test" to use the new run-test framework, instead of the old. >>>>> >>>>> The old framework is still available as of now by using "cd test >>>>> && make". >>>>> >>>>> The "run-test" target (and variants like exploded-run-test or >>>>> run-test-tier1) are kept as aliases. >>>>> >>>>> Using "cd test && make" will result in a warning being printed >>>>> that it is recommended to stop using this way of running tests. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210958 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8210958-rename-run-test-to-test/webrev.01 >>>>> >>>>> /Magnus >>>>> >>>> >>> >> > From Alan.Bateman at oracle.com Tue Oct 30 16:09:25 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Oct 2018 16:09:25 +0000 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> Message-ID: <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> On 30/10/2018 14:11, Andy Herrick wrote: > : >> >> What is the status of the JNLPConverter tool? I see it is included as >> a "demo" but maybe it would be better to host somewhere else as this >> is for developers migrating Java Web Start applications. > Our current plan is to deliver it only as a demo. This looks like a migration tool rather than a demo so not clear to me that this is the right approach. Also as the tool is for migration from Java Web Start when maybe it should be a tool hosted with the Oracle JDK download rather than something to put into the JDK. > : >> >> If I read the webrev correctly then it adds two modules, one with the >> jpackager tool and the other with an API. It would be useful to get a >> bit more information on the split. Also I think the name of the API >> module and the package that it exports needs discussion to make sure >> that the right names are chosen. > Yes - though we are currently using jdk.packager.services, we are open > to other suggestions as the name for these. "jdk.packager.runtime" has > also been suggested. Alex has suggested jdk.jpackager to avoid giving the impression that it's the "JDK packager". Also several existing tool modules have the tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). Is the API to ensure that only one instance of the application is running really tied to the jpackager tool? Could it be used by applications that aren't packaged in with this tool? I'm asking in case there is a better name for this API module. -Alan From kevin.rushforth at oracle.com Tue Oct 30 16:29:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Oct 2018 09:29:55 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> Message-ID: inline On 10/30/2018 9:09 AM, Alan Bateman wrote: > On 30/10/2018 14:11, Andy Herrick wrote: > >> : >>> >>> If I read the webrev correctly then it adds two modules, one with >>> the jpackager tool and the other with an API. It would be useful to >>> get a bit more information on the split. Also I think the name of >>> the API module and the package that it exports needs discussion to >>> make sure that the right names are chosen. >> Yes - though we are currently using jdk.packager.services, we are >> open to other suggestions as the name for these. >> "jdk.packager.runtime" has also been suggested. > Alex has suggested jdk.jpackager to avoid giving the impression that > it's the "JDK packager". Also several existing tool modules have the > tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). Yes, I think jdk.jpackager is a fine name for this module. > Is the API to ensure that only one instance of the application is > running really tied to the jpackager tool? Could it be used by > applications that aren't packaged in with this tool? I'm asking in > case there is a better name for this API module. In its current form it is tied to jpackager. Andy might be able to comment on how tightly-coupled it is, and what it would take to generalize it, but that wasn't a goal to make it usable for apps that aren't packaged using jpackager. Other things that will likely go into this runtime support module in the future: * Service daemon support * User JVM args support -- Kevin From ioi.lam at oracle.com Tue Oct 30 17:26:09 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 30 Oct 2018 10:26:09 -0700 Subject: Stop using precompiled headers for Linux? Message-ID: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> Is there any advantage of using precompiled headers on Linux? It's on by default and we keep having breakage where someone would forget to add #include. The latest instance is JDK-8213148. I just turn on precompiled headers explicitly in all my builds. I don't see any difference in build time (at least not significant enough for me to bother). Should we disable it by default on Linux? Thanks - Ioi From rkennke at redhat.com Tue Oct 30 18:37:35 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 30 Oct 2018 19:37:35 +0100 Subject: Stop using precompiled headers for Linux? In-Reply-To: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> References: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> Message-ID: <70db162b-e815-ebce-c139-48e00fa0bffb@redhat.com> I'd be in favour of disabling by default. Roman > Is there any advantage of using precompiled headers on Linux? It's on by > default and we keep having breakage where someone would forget to add > #include. The latest instance is JDK-8213148. > > I just turn on precompiled headers explicitly in all my builds. I don't > see any difference in build time (at least not significant enough for me > to bother). > > Should we disable it by default on Linux? > > Thanks > > - Ioi > > From thomas.stuefe at gmail.com Tue Oct 30 19:11:37 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 30 Oct 2018 20:11:37 +0100 Subject: Stop using precompiled headers for Linux? In-Reply-To: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> References: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> Message-ID: It would help already if Oracle would disable precompiled headers for the submit test builds. ..Thomas On Tue, Oct 30, 2018 at 6:26 PM Ioi Lam wrote: > > Is there any advantage of using precompiled headers on Linux? It's on by > default and we keep having breakage where someone would forget to add > #include. The latest instance is JDK-8213148. > > I just turn on precompiled headers explicitly in all my builds. I don't > see any difference in build time (at least not significant enough for me > to bother). > > Should we disable it by default on Linux? > > Thanks > > - Ioi > > From erik.joelsson at oracle.com Tue Oct 30 19:21:22 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Oct 2018 12:21:22 -0700 Subject: Stop using precompiled headers for Linux? In-Reply-To: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> References: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> Message-ID: Last I checked, it did provide significant build speed improvements when building just hotspot, but that could need revisiting. We do have verification of --disable-precompiled-headers (in slowdebug) in builds-tier2 so we normally get notified if this fails. However, Mach5 has not been running since Friday so this particular bug wasn't detected automatically. Looking at the bug, it also failed on Solaris, which would have been caught by tier1 builds. /Erik On 2018-10-30 10:26, Ioi Lam wrote: > Is there any advantage of using precompiled headers on Linux? It's on > by default and we keep having breakage where someone would forget to > add #include. The latest instance is JDK-8213148. > > I just turn on precompiled headers explicitly in all my builds. I > don't see any difference in build time (at least not significant > enough for me to bother). > > Should we disable it by default on Linux? > > Thanks > > - Ioi > > From shade at redhat.com Tue Oct 30 20:17:14 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Oct 2018 21:17:14 +0100 Subject: Stop using precompiled headers for Linux? In-Reply-To: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> References: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> Message-ID: On 10/30/2018 06:26 PM, Ioi Lam wrote: > Is there any advantage of using precompiled headers on Linux? I have measured it recently on shenandoah repositories, and fastdebug/release build times have not improved with or without PCH. Actually, it gets worse when you touch a single header that is in PCH list, and you end up recompiling the entire Hotspot. I would be in favor of disabling it by default. > It's on by default and we keep having > breakage where someone would forget to add #include. The latest instance is JDK-8213148. Yes, we catch most of these breakages in CIs. Which tells me adding it to jdk-submit would cover most of the breakage during pre-integration testing. -Aleksey From andy.herrick at oracle.com Tue Oct 30 20:54:53 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 30 Oct 2018 16:54:53 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> Message-ID: <3d793b6f-bd8d-3780-8a51-03e18e7f3307@oracle.com> On 10/30/2018 10:11 AM, Andy Herrick wrote: > > > On 10/24/2018 10:22 AM, Alan Bateman wrote: >> On 23/10/2018 16:49, Andy Herrick wrote: >>> This patch implements the Java Packager Tool (jpackager) as >>> described in JEP 343: Packaging Tool >>> >>> >>> jpackager is a simple packaging tool, based on the JavaFX >>> |javapackager| tool, that: >>> >>> ?* Supports native packaging formats to give the end user a natural >>> ?? installation experience. These formats include |msi| and |exe| on >>> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >>> ?* Allows launch-time parameters to be specified at packaging time. >>> ?* Can be invoked directly, from the command line, or programmatically, >>> ?? via the |ToolProvider| API. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >>> >> cc'ing build-dev as it's important to get it reviewed there. >> >> What is the plan for tests to go with this tool? I see there is one >> test in the webrev to do some argument validation but I don't see >> anything else right now. > We plan to incorporate the initial feedback from this review, and > include an initial set of automated tests in a refresh sometime next > week. > We will continue to develop and automate tests for future updates. >> >> What is the status of the JNLPConverter tool? I see it is included as >> a "demo" but maybe it would be better to host somewhere else as this >> is for developers migrating Java Web Start applications. > Our current plan is to deliver it only as a demo. After further discussion, we have decided to remove the JNLPConversion tool , and find another home for it. /Andy >> >> Would it be possible to update the JEP with all the CLI options? That >> would be useful for review and also useful for those invoking it with >> the ToolProvider API. > Done. >> >> If I read the webrev correctly then it adds two modules, one with the >> jpackager tool and the other with an API. It would be useful to get a >> bit more information on the split. Also I think the name of the API >> module and the package that it exports needs discussion to make sure >> that the right names are chosen. > Yes - though we are currently using jdk.packager.services, we are open > to other suggestions as the name for these. "jdk.packager.runtime" has > also been suggested. >> >> -Alan > /Andy From erik.joelsson at oracle.com Tue Oct 30 21:00:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Oct 2018 14:00:36 -0700 Subject: Stop using precompiled headers for Linux? In-Reply-To: References: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> Message-ID: <7c14ffa8-24cf-083f-e4d3-d0ffd737908e@oracle.com> Hello, On 2018-10-30 13:17, Aleksey Shipilev wrote: > On 10/30/2018 06:26 PM, Ioi Lam wrote: >> Is there any advantage of using precompiled headers on Linux? > I have measured it recently on shenandoah repositories, and fastdebug/release build times have not > improved with or without PCH. Actually, it gets worse when you touch a single header that is in PCH > list, and you end up recompiling the entire Hotspot. I would be in favor of disabling it by default. I just did a measurement on my local workstation (2x8 cores x2 ht Ubuntu 18.04 using Oracle devkit GCC 7.3.0). I ran "time make hotspot" with clean build directories. linux-x64: real??? 4m6.657s user??? 61m23.090s sys??? 6m24.477s linux-x64-npch real??? 3m41.130s user??? 66m11.824s sys??? 4m19.224s linux-x64-debug real??? 4m47.117s user??? 75m53.740s sys??? 8m21.408s linux-x64-debug-npch real??? 4m42.877s user??? 84m30.764s sys??? 4m54.666s linux-x64-slowdebug real??? 3m54.564s user??? 44m2.828s sys??? 6m22.785s linux-x64-slowdebug-npch real??? 3m23.092s user??? 55m3.142s sys??? 4m10.172s These numbers support your claim. Wall clock time is actually increased with PCH enabled, but total user time is decreased. Does not seem worth it to me. >> It's on by default and we keep having >> breakage where someone would forget to add #include. The latest instance is JDK-8213148. > Yes, we catch most of these breakages in CIs. Which tells me adding it to jdk-submit would cover > most of the breakage during pre-integration testing. jdk-submit is currently running what we call "tier1". We do have builds of Linux slowdebug with precompiled headers disabled in tier2. We also build solaris-sparcv9 in tier1 which does not support precompiled headers at all, so to not be caught in jdk-submit you would have to be in Linux specific code. The example bug does not seem to be that. Mach5/jdk-submit was down over the weekend and yesterday so my suspicion is the offending code in this case was never tested. That said, given that we get practically no benefit from PCH on Linux/GCC, we should probably just turn it off by default for Linux and/or GCC. I think we need to investigate Macos as well here. /Erik > -Aleksey > From erik.joelsson at oracle.com Tue Oct 30 23:54:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Oct 2018 16:54:32 -0700 Subject: Stop using precompiled headers for Linux? In-Reply-To: <7c14ffa8-24cf-083f-e4d3-d0ffd737908e@oracle.com> References: <77cd744f-7dec-f0ec-37af-89d72e75264f@oracle.com> <7c14ffa8-24cf-083f-e4d3-d0ffd737908e@oracle.com> Message-ID: Below are the corresponding numbers from a Mac, (Mac Pro (Late 2013), 3.7 GHz, Quad-Core Intel Xeon E5, 16 GB). To be clear, the -npch is without precompiled headers. Here we see a slight degradation when disabling on both user time and wall clock time. My guess is that the user time increase is about the same, but because of a lower cpu count, the extra load is not as easily covered. These tests were run with just building hotspot. This means that the precompiled header is generated alone on one core while nothing else is happening, which would explain this degradation in build speed. If we were instead building the whole product, we would see a better correlation between user and real time. Given the very small benefit here, it could make sense to disable precompiled headers by default for Linux and Mac, just as we did with ccache. I do know that the benefit is huge on Windows though, so we cannot remove the feature completely. Any other comments? /Erik macosx-x64 real??? ?4m13.658s user??? ?27m17.595s sys??? ?2m11.306s macosx-x64-npch real??? ?4m27.823s user??? ?30m0.434s sys??? ?2m18.669s macosx-x64-debug real??? ?5m21.032s user??? ?35m57.347s sys??? ?2m20.588s macosx-x64-debug-npch real??? ?5m33.728s user??? ?38m10.311s sys??? ?2m27.587s macosx-x64-slowdebug real??? ?3m54.439s user??? ?25m32.197s sys??? ?2m8.750s macosx-x64-slowdebug-npch real??? ?4m11.987s user??? ?27m59.857s sys??? ?2m18.093s On 2018-10-30 14:00, Erik Joelsson wrote: > Hello, > > On 2018-10-30 13:17, Aleksey Shipilev wrote: >> On 10/30/2018 06:26 PM, Ioi Lam wrote: >>> Is there any advantage of using precompiled headers on Linux? >> I have measured it recently on shenandoah repositories, and >> fastdebug/release build times have not >> improved with or without PCH. Actually, it gets worse when you touch >> a single header that is in PCH >> list, and you end up recompiling the entire Hotspot. I would be in >> favor of disabling it by default. > I just did a measurement on my local workstation (2x8 cores x2 ht > Ubuntu 18.04 using Oracle devkit GCC 7.3.0). I ran "time make hotspot" > with clean build directories. > > linux-x64: > real??? 4m6.657s > user??? 61m23.090s > sys??? 6m24.477s > > linux-x64-npch > real??? 3m41.130s > user??? 66m11.824s > sys??? 4m19.224s > > linux-x64-debug > real??? 4m47.117s > user??? 75m53.740s > sys??? 8m21.408s > > linux-x64-debug-npch > real??? 4m42.877s > user??? 84m30.764s > sys??? 4m54.666s > > linux-x64-slowdebug > real??? 3m54.564s > user??? 44m2.828s > sys??? 6m22.785s > > linux-x64-slowdebug-npch > real??? 3m23.092s > user??? 55m3.142s > sys??? 4m10.172s > > These numbers support your claim. Wall clock time is actually > increased with PCH enabled, but total user time is decreased. Does not > seem worth it to me. >>> It's on by default and we keep having >>> breakage where someone would forget to add #include. The latest >>> instance is JDK-8213148. >> Yes, we catch most of these breakages in CIs. Which tells me adding >> it to jdk-submit would cover >> most of the breakage during pre-integration testing. > jdk-submit is currently running what we call "tier1". We do have > builds of Linux slowdebug with precompiled headers disabled in tier2. > We also build solaris-sparcv9 in tier1 which does not support > precompiled headers at all, so to not be caught in jdk-submit you > would have to be in Linux specific code. The example bug does not seem > to be that. Mach5/jdk-submit was down over the weekend and yesterday > so my suspicion is the offending code in this case was never tested. > > That said, given that we get practically no benefit from PCH on > Linux/GCC, we should probably just turn it off by default for Linux > and/or GCC. I think we need to investigate Macos as well here. > > /Erik >> -Aleksey >> > From magnus.ihse.bursie at oracle.com Wed Oct 31 10:33:21 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 31 Oct 2018 11:33:21 +0100 Subject: [urgent] RFR: JDK-8213184 Revert change in jib-profiles.js from run-test-prebuilt to test-prebuilt Message-ID: <32129ba8-e801-35aa-a9bd-cec42883dec9@oracle.com> In JDK-8210958, I changed the make target for the run-test-prebuilt profile to be "test-prebuilt". Unfortunately, I missed to update the run-test-prebuilt target in Help.gmk. Since this is blocking our automated testing, the first step is to revert the faulting change. I'll file a follow-up bug to actually fix the target in Help.gmk. Bug: https://bugs.openjdk.java.net/browse/JDK-8213184 Patch inline: diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js --- a/make/conf/jib-profiles.js +++ b/make/conf/jib-profiles.js @@ -759,7 +759,7 @@ ???????????????? testedProfile + ".test" ???????????? ], ???????????? src: "src.conf", -??????????? make_args: [ "test-prebuilt", "LOG_CMDLINES=true", "JTREG_VERBOSE=fail,error,time" ], +??????????? make_args: [ "run-test-prebuilt", "LOG_CMDLINES=true", "JTREG_VERBOSE=fail,error,time" ], ???????????? environment: { ???????????????? "BOOT_JDK": common.boot_jdk_home, ???????????????? "JDK_IMAGE_DIR": input.get(testedProfile + ".jdk", "home_path"), /Magnus From david.holmes at oracle.com Wed Oct 31 10:36:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 31 Oct 2018 20:36:32 +1000 Subject: [urgent] RFR: JDK-8213184 Revert change in jib-profiles.js from run-test-prebuilt to test-prebuilt In-Reply-To: <32129ba8-e801-35aa-a9bd-cec42883dec9@oracle.com> References: <32129ba8-e801-35aa-a9bd-cec42883dec9@oracle.com> Message-ID: Looks good! Thanks for jumping on this. David On 31/10/2018 8:33 PM, Magnus Ihse Bursie wrote: > In JDK-8210958, I changed the make target for the run-test-prebuilt > profile to be "test-prebuilt". Unfortunately, I missed to update the > run-test-prebuilt target in Help.gmk. > > Since this is blocking our automated testing, the first step is to > revert the faulting change. I'll file a follow-up bug to actually fix > the target in Help.gmk. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213184 > Patch inline: > diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js > --- a/make/conf/jib-profiles.js > +++ b/make/conf/jib-profiles.js > @@ -759,7 +759,7 @@ > ???????????????? testedProfile + ".test" > ???????????? ], > ???????????? src: "src.conf", > -??????????? make_args: [ "test-prebuilt", "LOG_CMDLINES=true", > "JTREG_VERBOSE=fail,error,time" ], > +??????????? make_args: [ "run-test-prebuilt", "LOG_CMDLINES=true", > "JTREG_VERBOSE=fail,error,time" ], > ???????????? environment: { > ???????????????? "BOOT_JDK": common.boot_jdk_home, > ???????????????? "JDK_IMAGE_DIR": input.get(testedProfile + ".jdk", > "home_path"), > > /Magnus From matthias.baesken at sap.com Wed Oct 31 15:40:25 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 31 Oct 2018 15:40:25 +0000 Subject: minimal gcc version for jdk/jdk and usage of -Wno-int-in-bool-context flag in HS build Message-ID: Hello, I noticed that we currently set flags for gcc to disable warnings. See https://hg.openjdk.java.net/jdk/jdk/file/896e80158d35/make/hotspot/lib/CompileJvm.gmk DISABLED_WARNINGS_gcc := extra parentheses comment unknown-pragmas address \ delete-non-virtual-dtor char-subscripts array-bounds int-in-bool-context \ ignored-qualifiers missing-field-initializers implicit-fallthrough \ empty-body strict-overflow sequence-point maybe-uninitialized \ misleading-indentation However int-in-bool-context ( -Wnoint-in-bool-context ) seems to be available only in gcc 7 + . Example call with gcc 6 leads to a warning : /gcc-6/bin/gcc sizeof.c -Wall -Wextra -Wno-int-in-bool-context -o sizeof sizeof.c: At top level: cc1: warning: unrecognized command line option '-Wno-int-in-bool-context' Should we force all users to gcc 7 and higher (otherwise we could maybe check CC_VERSION_NUMBER in the makefile) ? Before we internally switched our OpenJDK builds from gcc 4.8 to gcc 7 we had a patch in our build-queue that disabled the -Wnoint-in-bool-context . Best regards, Matthias From shade at redhat.com Wed Oct 31 15:49:05 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Oct 2018 16:49:05 +0100 Subject: minimal gcc version for jdk/jdk and usage of -Wno-int-in-bool-context flag in HS build In-Reply-To: References: Message-ID: <9a027a4e-3a66-e2ec-0c3e-383162b9e68b@redhat.com> On 10/31/2018 04:40 PM, Baesken, Matthias wrote: > https://hg.openjdk.java.net/jdk/jdk/file/896e80158d35/make/hotspot/lib/CompileJvm.gmk > > DISABLED_WARNINGS_gcc := extra parentheses comment unknown-pragmas address \ > delete-non-virtual-dtor char-subscripts array-bounds int-in-bool-context \ > ignored-qualifiers missing-field-initializers implicit-fallthrough \ > empty-body strict-overflow sequence-point maybe-uninitialized \ > misleading-indentation > > > However int-in-bool-context ( -Wnoint-in-bool-context ) seems to be available only in gcc 7 + . > Example call with gcc 6 leads to a warning : Current jdk/jdk build works fine with 6.3.0 for me: https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-b441-20181029-jdk-12+17-linux-x86_64-fastdebug.configure.log https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-b441-20181029-jdk-12+17-linux-x86_64-fastdebug.build.log Is this the indication that build system actually probes the warnings before trying warning options? The troubles start when you supply additional options, apparently: https://bugs.openjdk.java.net/browse/JDK-8211088 -Aleksey From erik.joelsson at oracle.com Wed Oct 31 16:04:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 Oct 2018 09:04:51 -0700 Subject: minimal gcc version for jdk/jdk and usage of -Wno-int-in-bool-context flag in HS build In-Reply-To: References: Message-ID: <15a77e59-f769-b0a2-be35-815c4835b88f@oracle.com> Hello Matthias, It's our experience that GCC ignores unknown warning tags, so we regard it as safe to disable warnings only present in later versions of GCC. If another error is triggered, it will however print a message like you describe for any unknown tags. This is what happened in the issue Aleksey linked and I suspect is also happening for you. /Erik On 2018-10-31 08:40, Baesken, Matthias wrote: > Hello, I noticed that we currently set flags for gcc to disable warnings. > > See > > https://hg.openjdk.java.net/jdk/jdk/file/896e80158d35/make/hotspot/lib/CompileJvm.gmk > > DISABLED_WARNINGS_gcc := extra parentheses comment unknown-pragmas address \ > delete-non-virtual-dtor char-subscripts array-bounds int-in-bool-context \ > ignored-qualifiers missing-field-initializers implicit-fallthrough \ > empty-body strict-overflow sequence-point maybe-uninitialized \ > misleading-indentation > > > However int-in-bool-context ( -Wnoint-in-bool-context ) seems to be available only in gcc 7 + . > Example call with gcc 6 leads to a warning : > > /gcc-6/bin/gcc sizeof.c -Wall -Wextra -Wno-int-in-bool-context -o sizeof > > sizeof.c: At top level: > cc1: warning: unrecognized command line option '-Wno-int-in-bool-context' > > > > Should we force all users to gcc 7 and higher (otherwise we could maybe check CC_VERSION_NUMBER in the makefile) ? > Before we internally switched our OpenJDK builds from gcc 4.8 to gcc 7 we had a patch in our build-queue that disabled the -Wnoint-in-bool-context . > > > Best regards, Matthias > > From matthias.baesken at sap.com Wed Oct 31 16:17:20 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 31 Oct 2018 16:17:20 +0000 Subject: minimal gcc version for jdk/jdk and usage of -Wno-int-in-bool-context flag in HS build In-Reply-To: <9a027a4e-3a66-e2ec-0c3e-383162b9e68b@redhat.com> References: <9a027a4e-3a66-e2ec-0c3e-383162b9e68b@redhat.com> Message-ID: Hi Aleksey , I tried with gcc 6.2 not 6.3 maybe this makes a difference . Unfortunately I cannot see your exact gcc/g++ compile calls from the logfile . Do you have "-Wall" set which seems to be necessary to enable the additional flag ? https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html -Wint-in-bool-context Warn for suspicious use of integer values where boolean values are expected, such as conditional expressions (?:) using non-boolean integer constants in boolean context, like if (a <= b ? 2 : 3). Or left shifting of signed integers in boolean context, like for (a = 0; 1 << a; a++);. Likewise for all kinds of multiplications regardless of the data type. This warning is enabled by -Wall. The configure flag --with-extra-cflags is not used by us . Best regards, Matthias > -----Original Message----- > From: Aleksey Shipilev > Sent: Mittwoch, 31. Oktober 2018 16:49 > To: Baesken, Matthias ; 'build- > dev at openjdk.java.net' > Subject: Re: minimal gcc version for jdk/jdk and usage of -Wno-int-in-bool- > context flag in HS build > > On 10/31/2018 04:40 PM, Baesken, Matthias wrote: > > > https://hg.openjdk.java.net/jdk/jdk/file/896e80158d35/make/hotspot/lib/C > ompileJvm.gmk > > > > DISABLED_WARNINGS_gcc := extra parentheses comment unknown- > pragmas address \ > > delete-non-virtual-dtor char-subscripts array-bounds int-in-bool-context > \ > > ignored-qualifiers missing-field-initializers implicit-fallthrough \ > > empty-body strict-overflow sequence-point maybe-uninitialized \ > > misleading-indentation > > > > > > However int-in-bool-context ( -Wnoint-in-bool-context ) seems to be > available only in gcc 7 + . > > Example call with gcc 6 leads to a warning : > > Current jdk/jdk build works fine with 6.3.0 for me: > > https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-b441-20181029-jdk- > 12+17-linux-x86_64-fastdebug.configure.log > > https://builds.shipilev.net/openjdk-jdk/openjdk-jdk-b441-20181029-jdk- > 12+17-linux-x86_64-fastdebug.build.log > > Is this the indication that build system actually probes the warnings before > trying warning options? > > The troubles start when you supply additional options, apparently: > https://bugs.openjdk.java.net/browse/JDK-8211088 > > -Aleksey From erik.joelsson at oracle.com Wed Oct 31 20:05:34 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 Oct 2018 13:05:34 -0700 Subject: RFR: JDK-8210837: Add libXrandr-devel to the Linux devkits Message-ID: <7b649e7e-2429-a85c-218b-940609f0e3c2@oracle.com> Hello, Please review this small change to the devkit generator scripts for Linux, adding libXrandr-devel to the sysroot. I'm also bumping the devkit version used at Oracle to a version built using this change. Bug: https://bugs.openjdk.java.net/browse/JDK-8210837 Webrev: http://cr.openjdk.java.net/~erikj/8210837/webrev.01/index.html /Erik From philip.race at oracle.com Wed Oct 31 20:10:27 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Oct 2018 13:10:27 -0700 Subject: RFR: JDK-8210837: Add libXrandr-devel to the Linux devkits In-Reply-To: <7b649e7e-2429-a85c-218b-940609f0e3c2@oracle.com> References: <7b649e7e-2429-a85c-218b-940609f0e3c2@oracle.com> Message-ID: Since I tested this out and it worked fine, it gets my "+1". -phil. On 10/31/18 1:05 PM, Erik Joelsson wrote: > Hello, > > Please review this small change to the devkit generator scripts for > Linux, adding libXrandr-devel to the sysroot. I'm also bumping the > devkit version used at Oracle to a version built using this change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210837 > > Webrev: http://cr.openjdk.java.net/~erikj/8210837/webrev.01/index.html > > /Erik > From mikael.vidstedt at oracle.com Wed Oct 31 20:11:51 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 31 Oct 2018 13:11:51 -0700 Subject: RFR: JDK-8210837: Add libXrandr-devel to the Linux devkits In-Reply-To: <7b649e7e-2429-a85c-218b-940609f0e3c2@oracle.com> References: <7b649e7e-2429-a85c-218b-940609f0e3c2@oracle.com> Message-ID: Looks good. (We should drop the ?E? in OEL at some point, it?s just OL nowadays) Cheers, Mikael > On Oct 31, 2018, at 1:05 PM, Erik Joelsson wrote: > > Hello, > > Please review this small change to the devkit generator scripts for Linux, adding libXrandr-devel to the sysroot. I'm also bumping the devkit version used at Oracle to a version built using this change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210837 > > Webrev: http://cr.openjdk.java.net/~erikj/8210837/webrev.01/index.html > > /Erik >