From kim.barrett at oracle.com Tue May 1 00:42:40 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 30 Apr 2018 20:42:40 -0400 Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 In-Reply-To: <4df85ebd-aca1-46fe-8104-5c6f50517256@oracle.com> References: <5AE1FFD0.1090803@oracle.com> <5ED019CA-50CB-4AAB-A22A-E7BC6FE0157D@oracle.com> <43683acb-7f30-e79a-42dc-0d4693e2ac21@oracle.com> <4df85ebd-aca1-46fe-8104-5c6f50517256@oracle.com> Message-ID: > On Apr 27, 2018, at 7:25 PM, David Holmes wrote: > > We discussed this offline and Gary pointed out that, at least in the VMError case the attempt to SEGV by dereferencing zero is one of a specific number of crash inducing cases, others of which include trying to trigger SEGV at non-zero address and explicit signal raising. So changing the code to raise the signal directly is not really appropriate - and the code in VMError knows the attempt may not result in a crash. > > So I am okay with just disabling the compilation warnings for these two cases. I feel pretty uncomfortable with code that is intentionally invoking undefined behavior and expecting anything at all useful to come from that. I think in the frame::oops_do_internal case, the code used when CrashGCForDumpingJavaThread should use os::signal_raise, as suggested by David. Except there is the problem that David diagnosed in JDK-8139300, that OSX raise sends a signal to the main thread instead of the current thread. I wonder if that is still true with our new minimum supported OSX version? Man pages on my Mac say raise sends the signal to the current thread. (And I'm surprised that bug was fixed that way, rather than using os::signal_raise and making sure that worked properly.) In VMError::controlled_crash, not only is there no guarantee the write will crash, there's also no guarantee the break will do anything either. Since executing the write clearly invokes UB, the subsequent break can be assumed to be unreachable, or demons may fly out your nose. But since both of these are !PRODUCT, I guess I'm okay with suppressing the warning for now, as a way to move forward with the compiler upgrade. However, I'd like the scope of that warning suppression narrowed if possible, such as by moving it down to inside the #ifndef PRODUCT protecting the test code. We don't need the suppression for the entire file. For the frame case, does Solaris support any sort of push/pop diagnostic control? And it looks like there is further cleanup needed in these areas. From Alan.Bateman at oracle.com Tue May 1 06:32:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 1 May 2018 07:32:31 +0100 Subject: RFR: JDK-8196113: Remove the Compact Profile builds In-Reply-To: References: Message-ID: On 30/04/2018 21:19, Erik Joelsson wrote: > Compact profiles were added in JDK 8, and superceded by modules in JDK > 9. The build logic for compact profiles was left in place in 9, but as > we head into 11 it is time to remove this. This patch removes all the > build logic related to that. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196113 > > Webrev: http://cr.openjdk.java.net/~erikj/8196113/webrev.01/index.html > This looks good. Anyone that wants the equivalent of the Compact Profiles can use jlink so no need for support in the build now. -Alan From kim.barrett at oracle.com Tue May 1 17:59:01 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 May 2018 13:59:01 -0400 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> Message-ID: > On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: >>> For now, proposed patch looks like this: >>> >>> --- old/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.498343185 +0200 >>> +++ new/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.214342670 +0200 >>> @@ -98,26 +98,8 @@ >>> >>> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) >>> { >>> -// readdir_r has been deprecated since glibc 2.24. >>> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details. >>> -#pragma GCC diagnostic push >>> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations" >>> - >>> - dirent* p; >>> - int status; >>> assert(dirp != NULL, "just checking"); >>> - >>> - // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX >>> - // version. Here is the doc for this function: >>> - // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html >>> - >>> - if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { >>> - errno = status; >>> - return NULL; >>> - } else >>> - return p; >>> - >>> -#pragma GCC diagnostic pop >>> + return ::readdir(dirp); >>> } >>> >>> inline int os::closedir(DIR *dirp) { >> This looks good. > > Thanks! > Someone to sponsor this please? Do you have a sponsor yet? If not, I?ll do it. From kim.barrett at oracle.com Tue May 1 22:02:34 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 May 2018 18:02:34 -0400 Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 In-Reply-To: References: <5AE1FFD0.1090803@oracle.com> <5ED019CA-50CB-4AAB-A22A-E7BC6FE0157D@oracle.com> <43683acb-7f30-e79a-42dc-0d4693e2ac21@oracle.com> <4df85ebd-aca1-46fe-8104-5c6f50517256@oracle.com> Message-ID: > On Apr 30, 2018, at 8:42 PM, Kim Barrett wrote: > And it looks like there is further cleanup needed in these areas. I?ve created these followups: https://bugs.openjdk.java.net/browse/JDK-8202508 https://bugs.openjdk.java.net/browse/JDK-8202509 From igor.ignatyev at oracle.com Wed May 2 02:10:34 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 1 May 2018 19:10:34 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests Message-ID: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html > 41276 lines changed: 41274 ins; 1 del; 1 mod; Hi all, could you please review the patch which open sources monitoring tests from vm testbase? The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html testing: vmTestbase_nsk_monitoring test group Thanks, -- Igor From vladimir.kozlov at oracle.com Wed May 2 02:54:43 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 1 May 2018 19:54:43 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> Message-ID: Igor, Why you need to list each test in TEST.groups and not just directory as we do in other cases? Thanks, Vladimir On 5/1/18 7:10 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >> 41276 lines changed: 41274 ins; 1 del; 1 mod; > > Hi all, > > could you please review the patch which open sources monitoring tests from vm testbase? > > The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 > webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html > testing: vmTestbase_nsk_monitoring test group > > Thanks, > -- Igor > From gnu.andrew at redhat.com Wed May 2 04:25:02 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 May 2018 05:25:02 +0100 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> Message-ID: On 26 April 2018 at 23:55, Kim Barrett wrote: snip... > > I disagree, and still think the perfMemory_linux.cpp change should be > removed. > > (1) The change to perfMemory_linux.cpp is entirely unnecessary to > address the problem this bug is about. > > (2) It violates the (implied) protocol for os::readdir. If > Linux-specific code wants to invoke Linux-specific behavior, it should > do so by calling a Linux-specific API, not abuse an intended to be > portable API. > > (3) It minorly interferes with some desirable future work. If there > were some significant benefit to doing so, I wouldn't give this much > weight, but I don't see a significant benefit. > > (4) The only benefit is saving some rare short-term memory > allocations. I don't think that's worth the above costs. > > Note that the Windows version of os::readdir also ignores the second > argument, but all callers provide it anyway. > > I've opened a new CR for general os::readdir cleanup. > https://bugs.openjdk.java.net/browse/JDK-8202353 > Ok, I see your points and don't feel particularly strongly either way. The original version of this patch I wrote didn't include those changes either. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From igor.ignatyev at oracle.com Wed May 2 04:39:09 2018 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Tue, 1 May 2018 21:39:09 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> Message-ID: <395AD9F0-DBBF-4FCC-A01F-9C0D42B83BBD@oracle.com> Vladimir, Tests are listed only in _quick test group b/c it doesn?t include all tests from the directory. We use this group in some of our test configurations, and :vmTestbase_nsk_monitoring in others. vmTestbase_nsk_monitoring is defined by the directory as other groups. Thanks, ? Igor > On May 1, 2018, at 7:54 PM, Vladimir Kozlov wrote: > > Igor, > > Why you need to list each test in TEST.groups and not just directory as we do in other cases? > > Thanks, > Vladimir > >> On 5/1/18 7:10 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >>> 41276 lines changed: 41274 ins; 1 del; 1 mod; >> Hi all, >> could you please review the patch which open sources monitoring tests from vm testbase? >> The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 >> webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html >> testing: vmTestbase_nsk_monitoring test group >> Thanks, >> -- Igor From magnus.ihse.bursie at oracle.com Wed May 2 06:58:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 May 2018 08:58:52 +0200 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> Message-ID: Build changes look fine. /Magnus > 2 maj 2018 kl. 04:10 skrev Igor Ignatyev : > > http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >> 41276 lines changed: 41274 ins; 1 del; 1 mod; > > Hi all, > > could you please review the patch which open sources monitoring tests from vm testbase? > > The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 > webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html > testing: vmTestbase_nsk_monitoring test group > > Thanks, > -- Igor From magnus.ihse.bursie at oracle.com Wed May 2 06:58:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 May 2018 08:58:00 +0200 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com> Message-ID: <2BAFC298-0401-4B7D-B304-4D496CD62B11@oracle.com> Looks good to me. /Magnus > 30 apr. 2018 kl. 17:34 skrev Erik Joelsson : > > Hello, > > I'm re-starting this review with the original proposed patch. This changes the required boot-JDK in configure from the set "9 10 or 11" to "10 or 11". It also changes what Oracle uses in its automated build environment setup from 9 GA to 10 GA. > > I do this based on the proposal [1] to retain the historical N - 1 boot-JDK policy, which has not met any objections yet. > > http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ > > /Erik > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html > >> On 2018-03-21 14:51, Erik Joelsson wrote: >> Now that JDK 10 has been officially released we can update the boot jdk requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of this rather disruptive change. >> >> This patch changes the requirement on boot jdk version in configure (and updates the configuration that controls what JDK to use as boot in Oracle's internal build system). >> >> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >> >> /Erik > From mvala at redhat.com Wed May 2 09:10:20 2018 From: mvala at redhat.com (Michal Vala) Date: Wed, 2 May 2018 11:10:20 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> Message-ID: <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> On 05/01/2018 07:59 PM, Kim Barrett wrote: >> On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: >>>> For now, proposed patch looks like this: >>>> >>>> --- old/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.498343185 +0200 >>>> +++ new/src/hotspot/os/linux/os_linux.inline.hpp 2018-04-20 09:16:34.214342670 +0200 >>>> @@ -98,26 +98,8 @@ >>>> >>>> inline struct dirent* os::readdir(DIR* dirp, dirent *dbuf) >>>> { >>>> -// readdir_r has been deprecated since glibc 2.24. >>>> -// See https://sourceware.org/bugzilla/show_bug.cgi?id=19056 for more details. >>>> -#pragma GCC diagnostic push >>>> -#pragma GCC diagnostic ignored "-Wdeprecated-declarations" >>>> - >>>> - dirent* p; >>>> - int status; >>>> assert(dirp != NULL, "just checking"); >>>> - >>>> - // NOTE: Linux readdir_r (on RH 6.2 and 7.2 at least) is NOT like the POSIX >>>> - // version. Here is the doc for this function: >>>> - // http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_262.html >>>> - >>>> - if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { >>>> - errno = status; >>>> - return NULL; >>>> - } else >>>> - return p; >>>> - >>>> -#pragma GCC diagnostic pop >>>> + return ::readdir(dirp); >>>> } >>>> >>>> inline int os::closedir(DIR *dirp) { >>> This looks good. >> >> Thanks! >> Someone to sponsor this please? > > Do you have a sponsor yet? If not, I?ll do it. > No, I don't. I'd really appreciate if you sponsor it. -- Michal Vala OpenJDK QE Red Hat Czech From alexey.ivanov at oracle.com Wed May 2 09:52:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 2 May 2018 10:52:12 +0100 Subject: [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows Message-ID: Hi, Could you please review the following fix for jdk11? bug: https://bugs.openjdk.java.net/browse/JDK-8202476 webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ This is a follow-up fix for JDK-8201226 which enabled building JDK for 32 bit Windows, its code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html I found this issue: http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html This fix removes JNICALL modifiers from exported functions in medialib. After the fix, the failing tests in test/jdk/java/awt/image pass. Thank you in advance. Regards, Alexey From matthias.baesken at sap.com Wed May 2 10:09:36 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 May 2018 10:09:36 +0000 Subject: [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: References: Message-ID: Hi Alexey, looks good to me (not a Reviewer however). Thanks, Matthias > -----Original Message----- > From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > Sent: Mittwoch, 2. Mai 2018 11:52 > To: 2d-dev <2d-dev at openjdk.java.net> > Cc: build-dev ; Baesken, Matthias > > Subject: [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows > > Hi, > > Could you please review the following fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202476 > webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ > > This is a follow-up fix for JDK-8201226 which enabled building JDK for > 32 bit Windows, its code review: > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html > > I found this issue: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html > > > This fix removes JNICALL modifiers from exported functions in medialib. > After the fix, the failing tests in test/jdk/java/awt/image pass. > > > Thank you in advance. > > Regards, > Alexey From alexey.ivanov at oracle.com Wed May 2 11:52:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 2 May 2018 12:52:12 +0100 Subject: [11] RFR for JDK-8202544: Hide unused exports in libzip Message-ID: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> Hi, Could you please review the following fix for jdk11? bug: https://bugs.openjdk.java.net/browse/JDK-8202544 webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ The following exported functions in libzip are not used: ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read I removed JNIEXPORT modifiers from these functions. With the fix, they're not exported on Windows; on Linux they're listed as Local rather than Global. I ran tests, no failures. Thank you in advance. Regards, Alexey From magnus.ihse.bursie at oracle.com Wed May 2 12:02:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 May 2018 14:02:22 +0200 Subject: [11] RFR for JDK-8202544: Hide unused exports in libzip In-Reply-To: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> References: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> Message-ID: Looks good to me, FWIW. /Magnus > 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : > > Hi, > > Could you please review the following fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202544 > webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ > > The following exported functions in libzip are not used: > ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read > > I removed JNIEXPORT modifiers from these functions. With the fix, they're not exported on Windows; on Linux they're listed as Local rather than Global. > > I ran tests, no failures. > > > Thank you in advance. > > Regards, > Alexey From magnus.ihse.bursie at oracle.com Wed May 2 12:03:48 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 May 2018 14:03:48 +0200 Subject: [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: References: Message-ID: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> Looks good to me, but you should have a reviewer from the client team as well. /Magnus > 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : > > Hi, > > Could you please review the following fix for jdk11? > > bug: https://bugs.openjdk.java.net/browse/JDK-8202476 > webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ > > This is a follow-up fix for JDK-8201226 which enabled building JDK for 32 bit Windows, its code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html > > I found this issue: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html > > > This fix removes JNICALL modifiers from exported functions in medialib. > After the fix, the failing tests in test/jdk/java/awt/image pass. > > > Thank you in advance. > > Regards, > Alexey From sgehwolf at redhat.com Wed May 2 12:43:57 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 May 2018 14:43:57 +0200 Subject: [8u] RFR: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390 Message-ID: <1525265037.4303.26.camel@redhat.com> Hi, Could I please get a review for a fix which went into JDK 11 already. It reduces the maximum heap requirement for 32bit builds, which breaks s390 (31 bit) builds: + /usr/lib/jvm/java-openjdk/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=768 -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/dist/bootstrap/lib/javac.jar -classpath /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/btclasses genstubs.GenStubs -s /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/tmpstubs -sourcepath /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/jdk/src/share/classes java.util.function.Predicate Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. gmake[1]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/langtools/make' gmake[1]: *** No rule to make target `all', needed by `default'. Stop. make: *** [langtools-only] Error 2 The patch for JDK 11 does not apply cleanly since the build system got changed. The JDK 8 patch is here: webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.jdk8/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201495 JDK 11 review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021754.html Once this has been reviewed, I'll ask for approval on the jdk8u-dev list before it gets pushed to JDK 8u. Thanks, Severin From stefan.karlsson at oracle.com Wed May 2 14:37:38 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 May 2018 16:37:38 +0200 Subject: RFR: 8200729: Conditional compilation of GCs Message-ID: Hi all, Please review these patches to allow for conditional compilation of the GCs in HotSpot. Full patch: http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ (See below for a more fine-grained division into smaller patches) Today Parallel, G1, and CMS, are all guarded by INCLUDE_ALL_GCS. INCLUDE_ALL_GCS becomes defined to 1 for our server (--with-jvm-variants=server) builds, and is defined to 0 for the minimal (--with-jvm-variants=minimal) builds. There are also ways to forcefully remove these GCs from the compilation by configuring with, for example, --with-jvm-features=all-gcs. The proposed patch removes INCLUDE_ALL_GCS (and all-gcs) and replaces it with INCLUDE_CMSGC, INCLUDE_G1GC, and INCLUDE_PARALLELGC. In addition to that, INCLUDE_SERIALGC has been added to guard the Serial GC code. Future GCs should adopt this scheme before they get incorporated into the code base. Note, that there will be some files in gc/shared that are going to have to know about all GCs, but the goal is to have very few of these INCLUDE_ checks in the non-GC parts of HotSpot. With this patch, it's also going to be easier to stop compiling CMS when the time as come for it to move from deprecated to removed. Note, that even though this adds great flexibility, and allows for easy inclusion / exclusion of GCs, there's no guarantee that a specific combination of GCs is going to be maintained in the future. Just like not all combinations of the different Runtime features (CDS, NMT, JFR) and Compiler features (AOT, COMPILER1, COMPILER2) are guaranteed to compile and be supported. I've sanity checked the different GC configurations build locally, but I've only fully tested the "server" variant, and "minimal" has only been built locally. There's a more high-level discussion around the flexibility the --with-jvm-features flag adds, and if we really should allow it. Since this patch only builds upon that existing flexibility, and I don't change the two defined jvm variants, I'd appreciate if that discussion could be kept out of this review thread. For further discussion around this, please see: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021663.html This is the patch queue: The first patch simply cleans up some INCLUDE_ALL_GCS usages in platform-specific files. Some of these changes are already being cleaned up by other RFEs: http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ The second patch pre-cleans some include files: http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ The following is the main patch, which include all relevant HotSpot changes. For a while now, we have been actively working on abstracting away GC specific code from non-GC directories, but as can be seen in this patch, there are still a few places left. Hopefully, we will get rid of most of these in the near future. http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ The last patch adds the make file support to turn on and off the different GCs. The content of this patch has evolved from versions written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that they match the INCLUDE_ defines. http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ Thanks, StefanK From volker.simonis at gmail.com Wed May 2 15:03:17 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 May 2018 17:03:17 +0200 Subject: License and Usage Terms of generated API documentation Message-ID: Hi, we currently build OpenJDK and make it available from various sources (e.g. GitHub, apt-get server, DockerHub). We also build the API documentation (i.e. JavaDoc) and would like to make it available from our project page as well. However the default API doc produced by the build looks as follows: http://cr.openjdk.java.net/~simonis/webrevs/2018/jdk10-api-doc/overview-summary.html Especially the footer seems to be weired and only valid for the API doc hosted by Oracle itself. It reads as follows: Use is subject to "license terms" and the "documentation redistribution policy". "license terms" links to http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html which redirects to http://download.oracle.com/otndocs/jcp/java_se-10-final-spec/license.html "documentation redistribution policy" links to http://www.oracle.com/technetwork/java/redist-137594.html Especially the "documentation redistribution policy" is very strict. It states: "The Java SE API Specification is not redistributable." This is a very strong statement. While it may be fine for the API documentation hosted by Oracle (under https://docs.oracle.com/javase/10/docs/api/overview-summary.html) I doubt this can be valid for the OpenJDK API documentation which was produced exclusively from GPLv2 licensed sources (actually even GPLv2 plus Classpath Exception). From my understanding the whole HTML tree generated by "make docs-image" should be by default licensed under GPLv2 as well. I would therefore like to propose to make the following variables from "make/Docs.gmk" configurable with corresponding configure flags: JAVADOC_BASE_URL := http://www.oracle.com/pls/topic/lookup?ctx=javase10&id=homepage BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/ COPYRIGHT_URL := {@docroot}/../legal/copyright.html LICENSE_URL := http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html REDISTRIBUTION_URL := http://www.oracle.com/technetwork/java/redist-137594.html "JAVADOC_BASE_URL" should by default point to an OpenJDK site (although I'm not sure which one will be best suited). It seems strange that the default documentation generated from an OpenSource project like OpenJDK points to some Oracle-proprietary documentation. "BUG_SUBMIT_URL" should use the value of the already existing "--with-vendor-bug-url" if that was set at configure time. "COPYRIGHT_URL" currently points to "copyright.html" which doesn't exist neither in the OpenJDK sources nor in the generated images. Not sure what would be a useful default value here. Maybe just leave it empty? "Copyright ? 1993, 2018, Oracle.." already seems self-explanatory and clear enough. "LICENSE_URL" and "REDISTRIBUTION_URL" should both by default point to the GPLv2+CPE LICENSE file and this LICENSE file should be copied into the API doc HTML tree (much like it is copied into the various subdirectories of the "legel/" directory of an OpenJDK image) I can open an issue for this topic and propose an implementation if there's consensus on this topic. Thank you and best regards, Volker From gnu.andrew at redhat.com Wed May 2 15:55:19 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 2 May 2018 16:55:19 +0100 Subject: [8u] RFR: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390 In-Reply-To: <1525265037.4303.26.camel@redhat.com> References: <1525265037.4303.26.camel@redhat.com> Message-ID: On 2 May 2018 at 13:43, Severin Gehwolf wrote: > Hi, > > Could I please get a review for a fix which went into JDK 11 already. > It reduces the maximum heap requirement for 32bit builds, which breaks > s390 (31 bit) builds: > > + /usr/lib/jvm/java-openjdk/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=768 -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/dist/bootstrap/lib/javac.jar -classpath /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/btclasses genstubs.GenStubs -s /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/tmpstubs -sourcepath /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/jdk/src/share/classes java.util.function.Predicate > Error occurred during initialization of VM > Could not reserve enough space for object heap > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > gmake[1]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/langtools/make' > gmake[1]: *** No rule to make target `all', needed by `default'. Stop. > make: *** [langtools-only] Error 2 > > The patch for JDK 11 does not apply cleanly since the build system got > changed. The JDK 8 patch is here: > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.jdk8/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8201495 > JDK 11 review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021754.html > > Once this has been reviewed, I'll ask for approval on the jdk8u-dev > list before it gets pushed to JDK 8u. > > Thanks, > Severin Looks good to me, though I believe it will also need a re-generated configure script for inclusion in 8u (and thus needs to be pushed by someone at Oracle with access to their closed repos). -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed May 2 16:01:51 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 May 2018 18:01:51 +0200 Subject: [8u] RFR: 8201495: [Zero] Reduce limits of max heap size for boot JDK on s390 In-Reply-To: References: <1525265037.4303.26.camel@redhat.com> Message-ID: <1525276911.4303.47.camel@redhat.com> On Wed, 2018-05-02 at 16:55 +0100, Andrew Hughes wrote: > On 2 May 2018 at 13:43, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review for a fix which went into JDK 11 already. > > It reduces the maximum heap requirement for 32bit builds, which breaks > > s390 (31 bit) builds: > > > > + /usr/lib/jvm/java-openjdk/bin/java -Xms64M -Xmx1100M -XX:ThreadStackSize=768 -XX:PermSize=32m -XX:MaxPermSize=160m -Xbootclasspath/p:/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/dist/bootstrap/lib/javac.jar -classpath /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/btclasses genstubs.GenStubs -s /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/build/jdk8.build/langtools/tmpstubs -sourcepath /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/jdk/src/share/classes java.util.function.Predicate > > Error occurred during initialization of VM > > Could not reserve enough space for object heap > > Error: Could not create the Java Virtual Machine. > > Error: A fatal exception has occurred. Program will exit. > > gmake[1]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.171-8.b10.el7.s390/openjdk/langtools/make' > > gmake[1]: *** No rule to make target `all', needed by `default'. Stop. > > make: *** [langtools-only] Error 2 > > > > The patch for JDK 11 does not apply cleanly since the build system got > > changed. The JDK 8 patch is here: > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8201495/webrev.jdk8/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201495 > > JDK 11 review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021754.html > > > > Once this has been reviewed, I'll ask for approval on the jdk8u-dev > > list before it gets pushed to JDK 8u. > > > > Thanks, > > Severin > > Looks good to me, though I believe it will also need a re-generated > configure script > for inclusion in 8u (and thus needs to be pushed by someone at Oracle > with access > to their closed repos). Thanks for the review, Andrew! I'll keep that in mind when requesting approval. Cheers, Severin From philip.race at oracle.com Wed May 2 16:28:29 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 2 May 2018 09:28:29 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> Message-ID: <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> So ... the original change that removed the mapfiles broke the 32 bit build because of inconsistency between declarations + definitions of some functions. It did not affect 64 bit build because JNICALL is a no-op there. The next change (8201226) added JNICALL to make it consistent, but was not reviewed on 2d and was pushed without such review and may have fixed build issues but did NOT fix the product. This change now removes JNICALL where it is not needed and fixes the product and does not break any builds! Please confirm that you've run 64+32 bit builds through the build system AND run imaging tests on both of those. After that is confirmed you have my OK. -phil. On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: > Looks good to me, but you should have a reviewer from the client team as well. > > /Magnus > >> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >> >> Hi, >> >> Could you please review the following fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >> >> This is a follow-up fix for JDK-8201226 which enabled building JDK for 32 bit Windows, its code review: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >> >> I found this issue: >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >> >> >> This fix removes JNICALL modifiers from exported functions in medialib. >> After the fix, the failing tests in test/jdk/java/awt/image pass. >> >> >> Thank you in advance. >> >> Regards, >> Alexey From vladimir.kozlov at oracle.com Wed May 2 17:59:50 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 May 2018 10:59:50 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: <395AD9F0-DBBF-4FCC-A01F-9C0D42B83BBD@oracle.com> References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> <395AD9F0-DBBF-4FCC-A01F-9C0D42B83BBD@oracle.com> Message-ID: I wish we have ability to include other files with definitions into TEST.group file. It is very ugly to double size of TEST.group file just for that purpose. Thanks, Vladimir On 5/1/18 9:39 PM, Igor Ignatev wrote: > Vladimir, > > Tests are listed only in _quick test group b/c it doesn?t include all tests from the directory. We use this group in some of our test configurations, and :vmTestbase_nsk_monitoring in others. vmTestbase_nsk_monitoring is defined by the directory as other groups. > > Thanks, > ? Igor > >> On May 1, 2018, at 7:54 PM, Vladimir Kozlov wrote: >> >> Igor, >> >> Why you need to list each test in TEST.groups and not just directory as we do in other cases? >> >> Thanks, >> Vladimir >> >>> On 5/1/18 7:10 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >>>> 41276 lines changed: 41274 ins; 1 del; 1 mod; >>> Hi all, >>> could you please review the patch which open sources monitoring tests from vm testbase? >>> The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html >>> testing: vmTestbase_nsk_monitoring test group >>> Thanks, >>> -- Igor > From alexey.ivanov at oracle.com Wed May 2 18:24:32 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 2 May 2018 19:24:32 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> Message-ID: <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> Hi Phil, Thank you for your review. On 02/05/2018 17:28, Phil Race wrote: > So ... the original change that removed the mapfiles broke the 32 bit > build > because of inconsistency between declarations + definitions of some > functions. > It did not affect 64 bit build because JNICALL is a no-op there. > > The next change (8201226) added JNICALL to make it consistent, but > was not reviewed on 2d and was pushed without such review > and may have fixed build issues but did NOT fix the product. Yes, you're right. It made the product buildable but it did not fix the product. > > This change now removes JNICALL where it is not needed and fixes the > product and does not break > any builds! > > Please confirm that you've run 64+32 bit builds through the build > system AND run imaging tests > on both of those. Yes, I ran 64 builds through the build system and ran 32 bit Windows build on my laptop. I ran regression tests from test/jdk/java/awt/image with both 64 and 32 bit builds on Windows. No failures. Regards, Alexey > > After that is confirmed you have my OK. > > -phil. > > On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >> Looks good to me, but you should have a reviewer from the client team >> as well. >> >> /Magnus >> >>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>> >>> Hi, >>> >>> Could you please review the following fix for jdk11? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>> >>> This is a follow-up fix for JDK-8201226 which enabled building JDK >>> for 32 bit Windows, its code review: >>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>> >>> I found this issue: >>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>> >>> >>> This fix removes JNICALL modifiers from exported functions in medialib. >>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey > From thomas.stuefe at gmail.com Wed May 2 18:46:44 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 2 May 2018 20:46:44 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces Message-ID: Hi, My 32bit builds on Windows were failing since quite a while and I finally had some minutes to look into that. See prior discussion here: http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html My output used to look like this: checking if fixpath.exe works... yes POSSIBLE_MSVC_DLL /cygdrive/c/Program POSSIBLE_MSVC_DLL Files POSSIBLE_MSVC_DLL (x86)/Microsoft POSSIBLE_MSVC_DLL Visual POSSIBLE_MSVC_DLL Studio POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll configure: Found msvcr120.dll at /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in SYSTEMROOT So basically, build does not correctly search for msvcr120.dll in "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it fails and falls back to the system default "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, and so configure fails. Note that 64bit build shows exactly the same behaviour! Only there it works by accident, since the default /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a 64bit library too, so configure succeeds. Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in toolchain_windows.m4. We use a bash for loop to iterate thru a list of one or more files, but that for expression should be quoted. If I make this fix: --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 2018 -0700 +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 2018 +0200 @@ -556,7 +556,7 @@ fi fi # In case any of the above finds more than one file, loop over them. - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$possible_msvc_dll], [well-known location in VCINSTALLDIR]) the 32bit configure correctly sets the msvcrt dll: POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known location in VCINSTALLDIR checking found msvcr120.dll architecture... ok and I can start the build, but I get follow up errors: ... Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) Compiling 2 files for BUILD_JVMTI_TOOLS make[3]: *** No rule to make target '/cygdrive/c/Program', needed by '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. Stop. make[3]: *** Waiting for unfinished jobs.... make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 make[2]: *** Waiting for unfinished jobs.... I stopped looking at that point, but to me it looks like the build cannot survive msvcrt.dll locations with spaces in them. Kind Regards, Thomas From igor.ignatyev at oracle.com Wed May 2 18:57:48 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 2 May 2018 11:57:48 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> <395AD9F0-DBBF-4FCC-A01F-9C0D42B83BBD@oracle.com> Message-ID: <97CBC6A4-0E3C-4D92-BE29-4FC67FAE574F@oracle.com> Vladimir, we can introduce 'quick' keyword, mark these tests w/ them and use this keyword in test selection. I personally don't like this way either, as it uses a loosely defined property. it also might be possible to create a separate test group file and use it to define only _quick groups. I'll look into these and other possible options. in any case, although it will create a temporary mess, I'd prefer not to change how we define these *_quick test groups or how we do test selection, until all vm testbase tests are open sourced as it might create unneeded complications w/ test execution. I'll file an RFE to not forget about it. Thanks, -- Igor > On May 2, 2018, at 10:59 AM, Vladimir Kozlov wrote: > > I wish we have ability to include other files with definitions into TEST.group file. It is very ugly to double size of TEST.group file just for that purpose. > > Thanks, > Vladimir > > On 5/1/18 9:39 PM, Igor Ignatev wrote: >> Vladimir, >> Tests are listed only in _quick test group b/c it doesn?t include all tests from the directory. We use this group in some of our test configurations, and :vmTestbase_nsk_monitoring in others. vmTestbase_nsk_monitoring is defined by the directory as other groups. >> Thanks, >> ? Igor >>> On May 1, 2018, at 7:54 PM, Vladimir Kozlov wrote: >>> >>> Igor, >>> >>> Why you need to list each test in TEST.groups and not just directory as we do in other cases? >>> >>> Thanks, >>> Vladimir >>> >>>> On 5/1/18 7:10 PM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >>>>> 41276 lines changed: 41274 ins; 1 del; 1 mod; >>>> Hi all, >>>> could you please review the patch which open sources monitoring tests from vm testbase? >>>> The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html >>>> testing: vmTestbase_nsk_monitoring test group >>>> Thanks, >>>> -- Igor From vladimir.kozlov at oracle.com Wed May 2 19:13:06 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 May 2018 12:13:06 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: <97CBC6A4-0E3C-4D92-BE29-4FC67FAE574F@oracle.com> References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> <395AD9F0-DBBF-4FCC-A01F-9C0D42B83BBD@oracle.com> <97CBC6A4-0E3C-4D92-BE29-4FC67FAE574F@oracle.com> Message-ID: <9ebc00f5-d0fb-df28-f9b8-0f6c945f17e3@oracle.com> On 5/2/18 11:57 AM, Igor Ignatyev wrote: > Vladimir, > > we can introduce 'quick' keyword, mark these tests w/ them and use this keyword in test selection. I personally don't like this way either, as it uses a loosely defined property. it also might be possible to create a separate test group file and use it to define only _quick groups. I'll look into these and other possible options. > > in any case, although it will create a temporary mess, I'd prefer not to change how we define these *_quick test groups or how we do test selection, until all vm testbase tests are open sourced as it might create unneeded complications w/ test execution. I'll file an RFE to not forget about it. Yes, this sounds good. Reviewed. Thanks, Vladimir > > Thanks, > -- Igor > >> On May 2, 2018, at 10:59 AM, Vladimir Kozlov wrote: >> >> I wish we have ability to include other files with definitions into TEST.group file. It is very ugly to double size of TEST.group file just for that purpose. >> >> Thanks, >> Vladimir >> >> On 5/1/18 9:39 PM, Igor Ignatev wrote: >>> Vladimir, >>> Tests are listed only in _quick test group b/c it doesn?t include all tests from the directory. We use this group in some of our test configurations, and :vmTestbase_nsk_monitoring in others. vmTestbase_nsk_monitoring is defined by the directory as other groups. >>> Thanks, >>> ? Igor >>>> On May 1, 2018, at 7:54 PM, Vladimir Kozlov wrote: >>>> >>>> Igor, >>>> >>>> Why you need to list each test in TEST.groups and not just directory as we do in other cases? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> On 5/1/18 7:10 PM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >>>>>> 41276 lines changed: 41274 ins; 1 del; 1 mod; >>>>> Hi all, >>>>> could you please review the patch which open sources monitoring tests from vm testbase? >>>>> The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html >>>>> testing: vmTestbase_nsk_monitoring test group >>>>> Thanks, >>>>> -- Igor > From kim.barrett at oracle.com Wed May 2 20:40:22 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 May 2018 16:40:22 -0400 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> Message-ID: > On May 2, 2018, at 5:10 AM, Michal Vala wrote: > > > > On 05/01/2018 07:59 PM, Kim Barrett wrote: >>> On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: >>> Someone to sponsor this please? >> Do you have a sponsor yet? If not, I?ll do it. > > No, I don't. I'd really appreciate if you sponsor it. Will do. I should be able to take care of it in the next day or so. From serguei.spitsyn at oracle.com Wed May 2 21:18:56 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 2 May 2018 14:18:56 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> Message-ID: <8fd2e124-47c9-98ff-90e8-104f1a78ed28@oracle.com> Hi Igor, It looks good. Thanks, Serguei On 5/1/18 19:10, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html >> 41276 lines changed: 41274 ins; 1 del; 1 mod; > Hi all, > > could you please review the patch which open sources monitoring tests from vm testbase? > > The tests were developed to test hotspot related JMX functionality. as w/ common VM testbase code, these tests are old, they have been run from hotspot testing for a long period of time. originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. in a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 > webrev: http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html > testing: vmTestbase_nsk_monitoring test group > > Thanks, > -- Igor From vladimir.kozlov at oracle.com Wed May 2 22:13:51 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 May 2018 15:13:51 -0700 Subject: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT Message-ID: http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8202552 Stefan K. found several places where #ifdef instead of #if is used for INCLUDE_JVMCI. I also found places where we can use COMPILER2_OR_JVMCI. An other problem surprised me that we don't set INCLUDE_AOT to 1. Makefile defines that variable without value. I changed code to match other variables setting - in makefile set it to 0 if it is not part of build and set it to 1 in macros.hpp if it is not defined. Tested with tier1, tier2 and tier2 with Graal as JIT compiler. -- Thanks, Vladimir From stefan.karlsson at oracle.com Thu May 3 07:20:16 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 3 May 2018 09:20:16 +0200 Subject: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT In-Reply-To: References: Message-ID: Looks good to me. Thanks for fixing. StefanK On 2018-05-03 00:13, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8202552 > > Stefan K. found several places where #ifdef instead of #if is used for > INCLUDE_JVMCI. > I also found places where we can use COMPILER2_OR_JVMCI. > > An other problem surprised me that we don't set INCLUDE_AOT to 1. > Makefile defines that variable without value. I changed code to match > other variables setting - in makefile set it to 0 if it is not part of > build and set it to 1 in macros.hpp if it is not defined. > > Tested with tier1, tier2 and tier2 with Graal as JIT compiler. > From magnus.ihse.bursie at oracle.com Thu May 3 08:40:07 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 10:40:07 +0200 Subject: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT In-Reply-To: References: Message-ID: <728b7bc3-a6ae-c913-4256-c7bc58434f70@oracle.com> On 2018-05-03 00:13, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8202552 Looks good to me. Just some thinking out loud... The way we handle the responsibility split between the makefiles and the hotspot source files is actually a bit corny. :-( It would make more sense for the makefiles to set -DINCLUDE_features=1 when the feature is enabled, and -DINCLUDE_feature=0 when it is not (or just leave it out), and skip all the #ifndef INCLUDE_ #define INCLUDE_ 1 ...in macros.hpp. But that is the work of a future cleanup. This patch makes sure we use the same pattern everywhere, which is good. /Magnus > > Stefan K. found several places where #ifdef instead of #if is used for > INCLUDE_JVMCI. > I also found places where we can use COMPILER2_OR_JVMCI. > > An other problem surprised me that we don't set INCLUDE_AOT to 1. > Makefile defines that variable without value. I changed code to match > other variables setting - in makefile set it to 0 if it is not part of > build and set it to 1 in macros.hpp if it is not defined. > > Tested with tier1, tier2 and tier2 with Graal as JIT compiler. From magnus.ihse.bursie at oracle.com Thu May 3 09:06:45 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 11:06:45 +0200 Subject: RFR: 8200729: Conditional compilation of GCs In-Reply-To: References: Message-ID: <493e0b27-7200-c361-661b-05573645f279@oracle.com> On 2018-05-02 16:37, Stefan Karlsson wrote: > Hi all, > > Please review these patches to allow for conditional compilation of > the GCs in HotSpot. > > Full patch: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ It's nice to see this cleanup in build logic! I spotted one issue with the build logic, otherwise it looks good. In JvmFeatures.gmk, remove the? "JVM_EXCLUDE_FILES += none" lines. They are not needed and are technically incorrect (makes the build tries to exclude files named "none"). /Magnus > > (See below for a more fine-grained division into smaller patches) > > Today Parallel, G1, and CMS, are all guarded by INCLUDE_ALL_GCS. > INCLUDE_ALL_GCS becomes defined to 1 for our server > (--with-jvm-variants=server) builds, and is defined to 0 for the > minimal (--with-jvm-variants=minimal) builds. There are also ways to > forcefully remove these GCs from the compilation by configuring with, > for example, --with-jvm-features=all-gcs. > > The proposed patch removes INCLUDE_ALL_GCS (and all-gcs) and replaces > it with INCLUDE_CMSGC, INCLUDE_G1GC, and INCLUDE_PARALLELGC. In > addition to that, INCLUDE_SERIALGC has been added to guard the Serial > GC code. > > Future GCs should adopt this scheme before they get incorporated into > the code base. Note, that there will be some files in gc/shared that > are going to have to know about all GCs, but the goal is to have very > few of these INCLUDE_ checks in the non-GC parts of HotSpot. > > With this patch, it's also going to be easier to stop compiling CMS > when the time as come for it to move from deprecated to removed. > > Note, that even though this adds great flexibility, and allows for > easy inclusion / exclusion of GCs, there's no guarantee that a > specific combination of GCs is going to be maintained in the future. > Just like not all combinations of the different Runtime features (CDS, > NMT, JFR) and Compiler features (AOT, COMPILER1, COMPILER2) are > guaranteed to compile and be supported. I've sanity checked the > different GC configurations build locally, but I've only fully tested > the "server" variant, and "minimal" has only been built locally. > > There's a more high-level discussion around the flexibility the > --with-jvm-features flag adds, and if we really should allow it. Since > this patch only builds upon that existing flexibility, and I don't > change the two defined jvm variants, I'd appreciate if that discussion > could be kept out of this review thread. For further discussion around > this, please see: > > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021663.html > > This is the patch queue: > > The first patch simply cleans up some INCLUDE_ALL_GCS usages in > platform-specific files. Some of these changes are already being > cleaned up by other RFEs: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ > > > > The second patch pre-cleans some include files: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ > > > The following is the main patch, which include all relevant HotSpot > changes. For a while now, we have been actively working on abstracting > away GC specific code from non-GC directories, but as can be seen in > this patch, there are still a few places left. Hopefully, we will get > rid of most of these in the near future. > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ > > > The last patch adds the make file support to turn on and off the > different GCs. The content of this patch has evolved from versions > written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed > version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but > I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that > they match the INCLUDE_ defines. > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ > > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu May 3 09:09:57 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 3 May 2018 11:09:57 +0200 Subject: RFR: 8200729: Conditional compilation of GCs In-Reply-To: <493e0b27-7200-c361-661b-05573645f279@oracle.com> References: <493e0b27-7200-c361-661b-05573645f279@oracle.com> Message-ID: On 2018-05-03 11:06, Magnus Ihse Bursie wrote: > On 2018-05-02 16:37, Stefan Karlsson wrote: >> Hi all, >> >> Please review these patches to allow for conditional compilation of >> the GCs in HotSpot. >> >> Full patch: >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ > > It's nice to see this cleanup in build logic! > > I spotted one issue with the build logic, otherwise it looks good. In > JvmFeatures.gmk, remove the? "JVM_EXCLUDE_FILES += none" lines. They are > not needed and are technically incorrect (makes the build tries to > exclude files named "none"). Thanks for reviewing this, and helping out writing the make files changes! I'll remove the += none lines. StefanK > > /Magnus > >> >> (See below for a more fine-grained division into smaller patches) >> >> Today Parallel, G1, and CMS, are all guarded by INCLUDE_ALL_GCS. >> INCLUDE_ALL_GCS becomes defined to 1 for our server >> (--with-jvm-variants=server) builds, and is defined to 0 for the >> minimal (--with-jvm-variants=minimal) builds. There are also ways to >> forcefully remove these GCs from the compilation by configuring with, >> for example, --with-jvm-features=all-gcs. >> >> The proposed patch removes INCLUDE_ALL_GCS (and all-gcs) and replaces >> it with INCLUDE_CMSGC, INCLUDE_G1GC, and INCLUDE_PARALLELGC. In >> addition to that, INCLUDE_SERIALGC has been added to guard the Serial >> GC code. >> >> Future GCs should adopt this scheme before they get incorporated into >> the code base. Note, that there will be some files in gc/shared that >> are going to have to know about all GCs, but the goal is to have very >> few of these INCLUDE_ checks in the non-GC parts of HotSpot. >> >> With this patch, it's also going to be easier to stop compiling CMS >> when the time as come for it to move from deprecated to removed. >> >> Note, that even though this adds great flexibility, and allows for >> easy inclusion / exclusion of GCs, there's no guarantee that a >> specific combination of GCs is going to be maintained in the future. >> Just like not all combinations of the different Runtime features (CDS, >> NMT, JFR) and Compiler features (AOT, COMPILER1, COMPILER2) are >> guaranteed to compile and be supported. I've sanity checked the >> different GC configurations build locally, but I've only fully tested >> the "server" variant, and "minimal" has only been built locally. >> >> There's a more high-level discussion around the flexibility the >> --with-jvm-features flag adds, and if we really should allow it. Since >> this patch only builds upon that existing flexibility, and I don't >> change the two defined jvm variants, I'd appreciate if that discussion >> could be kept out of this review thread. For further discussion around >> this, please see: >> >> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021663.html >> >> This is the patch queue: >> >> The first patch simply cleans up some INCLUDE_ALL_GCS usages in >> platform-specific files. Some of these changes are already being >> cleaned up by other RFEs: >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ >> >> >> >> The second patch pre-cleans some include files: >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ >> >> >> The following is the main patch, which include all relevant HotSpot >> changes. For a while now, we have been actively working on abstracting >> away GC specific code from non-GC directories, but as can be seen in >> this patch, there are still a few places left. Hopefully, we will get >> rid of most of these in the near future. >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ >> >> >> The last patch adds the make file support to turn on and off the >> different GCs. The content of this patch has evolved from versions >> written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed >> version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but >> I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that >> they match the INCLUDE_ defines. >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ >> >> >> Thanks, >> StefanK > From magnus.ihse.bursie at oracle.com Thu May 3 10:21:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 12:21:52 +0200 Subject: License and Usage Terms of generated API documentation In-Reply-To: References: Message-ID: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> On 2018-05-02 17:03, Volker Simonis wrote: > Hi, > > we currently build OpenJDK and make it available from various sources > (e.g. GitHub, apt-get server, DockerHub). We also build the API > documentation (i.e. JavaDoc) and would like to make it available from > our project page as well. However the default API doc produced by the > build looks as follows: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/jdk10-api-doc/overview-summary.html > > Especially the footer seems to be weired and only valid for the API > doc hosted by Oracle itself. It reads as follows: > > Use is subject to "license terms" and the "documentation redistribution policy". > > "license terms" links to > http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html > which redirects to > http://download.oracle.com/otndocs/jcp/java_se-10-final-spec/license.html > > "documentation redistribution policy" links to > http://www.oracle.com/technetwork/java/redist-137594.html > > Especially the "documentation redistribution policy" is very strict. It states: > > "The Java SE API Specification is not redistributable." > > This is a very strong statement. While it may be fine for the API > documentation hosted by Oracle (under > https://docs.oracle.com/javase/10/docs/api/overview-summary.html) I > doubt this can be valid for the OpenJDK API documentation which was > produced exclusively from GPLv2 licensed sources (actually even GPLv2 > plus Classpath Exception). From my understanding the whole HTML tree > generated by "make docs-image" should be by default licensed under > GPLv2 as well. > > I would therefore like to propose to make the following variables from > "make/Docs.gmk" configurable with corresponding configure flags: > > JAVADOC_BASE_URL := > http://www.oracle.com/pls/topic/lookup?ctx=javase10&id=homepage > BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/ > COPYRIGHT_URL := {@docroot}/../legal/copyright.html > LICENSE_URL := http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html > REDISTRIBUTION_URL := http://www.oracle.com/technetwork/java/redist-137594.html > > "JAVADOC_BASE_URL" should by default point to an OpenJDK site > (although I'm not sure which one will be best suited). It seems > strange that the default documentation generated from an OpenSource > project like OpenJDK points to some Oracle-proprietary documentation. > > "BUG_SUBMIT_URL" should use the value of the already existing > "--with-vendor-bug-url" if that was set at configure time. > > "COPYRIGHT_URL" currently points to "copyright.html" which doesn't > exist neither in the OpenJDK sources nor in the generated images. Not > sure what would be a useful default value here. Maybe just leave it > empty? "Copyright ? 1993, 2018, Oracle.." already seems > self-explanatory and clear enough. > > "LICENSE_URL" and "REDISTRIBUTION_URL" should both by default point to > the GPLv2+CPE LICENSE file and this LICENSE file should be copied into > the API doc HTML tree (much like it is copied into the various > subdirectories of the "legel/" directory of an OpenJDK image) > > I can open an issue for this topic and propose an implementation if > there's consensus on this topic. > > Thank you and best regards, > Volker Since you added build-dev, I'll chip in some of my cents. The code in the make file has been around like Forever. The current implementation is just what has been ported between frameworks and source control systems and updated for changes in release version and URL schemes. I agree that is odd that the Oracle URL is hard-coded. On the other hand, there is no common place where generated OpenJDK documents are published. (The Oracle site technically speaking documents the Java Platform API, not the OpenJDK, even if any actual difference is minimal to non-existant wrt docs.) It would make sense to me to have a OpenJDK-based documentation driven by the community. I'm guessing it's no easy thing to create this, though. A lot of links on the interwebz are pointing to the docs at docs.oracle.com, and it would probably be quite messy if the same (or even worse, almost the same) documentation were published both at docs.oracle.com and java.net. Also, the question arises as to who should do the hosting, and how. So it's definitely a community issue to resolve, and one in which Oracle's legacy is important to take into consideration. Until a consensus of a better solution for hosting the generated documentation is reached, I'd like to avoid changing the build code. That will just open for an uneccessary split in what constitutes the proper documentation URL. /Magnus From magnus.ihse.bursie at oracle.com Thu May 3 10:41:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 12:41:52 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: References: Message-ID: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> I think the main issue here is that BASIC_FIXUP_PATH should be called for the located msvcr*.dll files. I don't have time to look at it now, but see if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is located. This should remove all spaces from the path. /Magnus On 2018-05-02 20:46, Thomas St?fe wrote: > Hi, > > My 32bit builds on Windows were failing since quite a while and I > finally had some minutes to look into that. > > See prior discussion here: > http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html > > My output used to look like this: > > checking if fixpath.exe works... yes > POSSIBLE_MSVC_DLL /cygdrive/c/Program > POSSIBLE_MSVC_DLL Files > POSSIBLE_MSVC_DLL (x86)/Microsoft > POSSIBLE_MSVC_DLL Visual > POSSIBLE_MSVC_DLL Studio > POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll > configure: Found msvcr120.dll at > /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in > SYSTEMROOT > > So basically, build does not correctly search for msvcr120.dll in > "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio > 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it > fails and falls back to the system default > "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, > and so configure fails. > > Note that 64bit build shows exactly the same behaviour! Only there it > works by accident, since the default > /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a > 64bit library too, so configure succeeds. > > Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in > toolchain_windows.m4. We use a bash for loop to iterate thru a list of > one or more files, but that for expression should be quoted. > > If I make this fix: > > --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 2018 -0700 > +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 2018 +0200 > @@ -556,7 +556,7 @@ > fi > fi > # In case any of the above finds more than one file, loop over them. > - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do > + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do > $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" > TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], [$possible_msvc_dll], > [well-known location in VCINSTALLDIR]) > > > the 32bit configure correctly sets the msvcrt dll: > > POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual > Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll > configure: Found msvcr120.dll at /cygdrive/c/Program Files > (x86)/Microsoft Visual Studio > 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known > location in VCINSTALLDIR > checking found msvcr120.dll architecture... ok > > and I can start the build, but I get follow up errors: > > ... > Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) > Compiling 2 files for BUILD_JVMTI_TOOLS > make[3]: *** No rule to make target '/cygdrive/c/Program', needed by > '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. > Stop. > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 > make[2]: *** Waiting for unfinished jobs.... > > I stopped looking at that point, but to me it looks like the build > cannot survive msvcrt.dll locations with spaces in them. > > Kind Regards, Thomas From sgehwolf at redhat.com Thu May 3 11:33:26 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 May 2018 13:33:26 +0200 Subject: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols Message-ID: <1525347206.4079.19.camel@redhat.com> Hi, Could I please get a review of this change for JDK 8u? We are seing build failures due to unresolved symbols when building libfontmanager.so. The build flag to trigger this is to configure with: --with-extra-ldflags="-Wl,-z,defs" Attempting a build of JDK 8 with this fails. This has been fixed in JDK 11 and hasn't shown any issues so far. Due to the change in the build system the JDK 11 patch does not apply cleanly after path unshuffeling (different context it seems). Hence, asking here for a review before asking for JDK 8 backport approval. Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.jdk8/ Review thread for JDK 11: http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021575.html Thanks, Severin From volker.simonis at gmail.com Thu May 3 12:16:11 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 May 2018 14:16:11 +0200 Subject: License and Usage Terms of generated API documentation In-Reply-To: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> References: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> Message-ID: On Thu, May 3, 2018 at 12:21 PM, Magnus Ihse Bursie wrote: > On 2018-05-02 17:03, Volker Simonis wrote: >> >> Hi, >> >> we currently build OpenJDK and make it available from various sources >> (e.g. GitHub, apt-get server, DockerHub). We also build the API >> documentation (i.e. JavaDoc) and would like to make it available from >> our project page as well. However the default API doc produced by the >> build looks as follows: >> >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/jdk10-api-doc/overview-summary.html >> >> Especially the footer seems to be weired and only valid for the API >> doc hosted by Oracle itself. It reads as follows: >> >> Use is subject to "license terms" and the "documentation redistribution >> policy". >> >> "license terms" links to >> >> http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html >> which redirects to >> http://download.oracle.com/otndocs/jcp/java_se-10-final-spec/license.html >> >> "documentation redistribution policy" links to >> http://www.oracle.com/technetwork/java/redist-137594.html >> >> Especially the "documentation redistribution policy" is very strict. It >> states: >> >> "The Java SE API Specification is not redistributable." >> >> This is a very strong statement. While it may be fine for the API >> documentation hosted by Oracle (under >> https://docs.oracle.com/javase/10/docs/api/overview-summary.html) I >> doubt this can be valid for the OpenJDK API documentation which was >> produced exclusively from GPLv2 licensed sources (actually even GPLv2 >> plus Classpath Exception). From my understanding the whole HTML tree >> generated by "make docs-image" should be by default licensed under >> GPLv2 as well. >> >> I would therefore like to propose to make the following variables from >> "make/Docs.gmk" configurable with corresponding configure flags: >> >> JAVADOC_BASE_URL := >> http://www.oracle.com/pls/topic/lookup?ctx=javase10&id=homepage >> BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/ >> COPYRIGHT_URL := {@docroot}/../legal/copyright.html >> LICENSE_URL := >> http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html >> REDISTRIBUTION_URL := >> http://www.oracle.com/technetwork/java/redist-137594.html >> >> "JAVADOC_BASE_URL" should by default point to an OpenJDK site >> (although I'm not sure which one will be best suited). It seems >> strange that the default documentation generated from an OpenSource >> project like OpenJDK points to some Oracle-proprietary documentation. >> >> "BUG_SUBMIT_URL" should use the value of the already existing >> "--with-vendor-bug-url" if that was set at configure time. >> >> "COPYRIGHT_URL" currently points to "copyright.html" which doesn't >> exist neither in the OpenJDK sources nor in the generated images. Not >> sure what would be a useful default value here. Maybe just leave it >> empty? "Copyright ? 1993, 2018, Oracle.." already seems >> self-explanatory and clear enough. >> >> "LICENSE_URL" and "REDISTRIBUTION_URL" should both by default point to >> the GPLv2+CPE LICENSE file and this LICENSE file should be copied into >> the API doc HTML tree (much like it is copied into the various >> subdirectories of the "legel/" directory of an OpenJDK image) >> >> I can open an issue for this topic and propose an implementation if >> there's consensus on this topic. >> >> Thank you and best regards, >> Volker > > Since you added build-dev, I'll chip in some of my cents. > > The code in the make file has been around like Forever. The current > implementation is just what has been ported between frameworks and source > control systems and updated for changes in release version and URL schemes. > Thanks for confirming this. That was my impression as well :) > I agree that is odd that the Oracle URL is hard-coded. On the other hand, > there is no common place where generated OpenJDK documents are published. > (The Oracle site technically speaking documents the Java Platform API, not > the OpenJDK, even if any actual difference is minimal to non-existant wrt > docs.) > > It would make sense to me to have a OpenJDK-based documentation driven by > the community. I'm guessing it's no easy thing to create this, though. A lot > of links on the interwebz are pointing to the docs at docs.oracle.com, and > it would probably be quite messy if the same (or even worse, almost the > same) documentation were published both at docs.oracle.com and java.net. > Also, the question arises as to who should do the hosting, and how. > > So it's definitely a community issue to resolve, and one in which Oracle's > legacy is important to take into consideration. > > Until a consensus of a better solution for hosting the generated > documentation is reached, I'd like to avoid changing the build code. That > will just open for an uneccessary split in what constitutes the proper > documentation URL. > The JAVADOC_BASE_URL is the minor issue here and I agree that it would be not easy to create a community driven documentation of the same or at least similar quality as we have today from Oracle. Nevertheless I don't see why we shouldn't be able to make this URL configurable at configure time. The main issue are the two links to "LICENSE_URL" and "REDISTRIBUTION_URL" which clearly refer to the API-docs published by Oracle. I just want to be able to publish these API-docs myself without having to refer to these restrictive licenses. The change itself, to make these URLs configurable at configure time, would be trivial (and again, I'm not against leaving the default "as-is" if this is important for you). > /Magnus > From magnus.ihse.bursie at oracle.com Thu May 3 12:31:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 14:31:15 +0200 Subject: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1525347206.4079.19.camel@redhat.com> References: <1525347206.4079.19.camel@redhat.com> Message-ID: <29bfd9cf-5019-d1d5-4437-301dcb8ab64b@oracle.com> On 2018-05-03 13:33, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this change for JDK 8u? We are seing > build failures due to unresolved symbols when building > libfontmanager.so. The build flag to trigger this is to configure with: > > --with-extra-ldflags="-Wl,-z,defs" > > Attempting a build of JDK 8 with this fails. This has been fixed in JDK > 11 and hasn't shown any issues so far. Due to the change in the build > system the JDK 11 patch does not apply cleanly after path unshuffeling > (different context it seems). Hence, asking here for a review before > asking for JDK 8 backport approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.jdk8/ Looks good to me. /Magnus > > Review thread for JDK 11: > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021575.html > > Thanks, > Severin From thomas.stuefe at gmail.com Thu May 3 13:22:31 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 May 2018 15:22:31 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> Message-ID: Thank you Magnus, will do. On Thu, May 3, 2018 at 12:41 PM, Magnus Ihse Bursie wrote: > I think the main issue here is that BASIC_FIXUP_PATH should be called for > the located msvcr*.dll files. I don't have time to look at it now, but see > if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is > located. This should remove all spaces from the path. > > /Magnus > > > On 2018-05-02 20:46, Thomas St?fe wrote: >> >> Hi, >> >> My 32bit builds on Windows were failing since quite a while and I >> finally had some minutes to look into that. >> >> See prior discussion here: >> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >> >> My output used to look like this: >> >> checking if fixpath.exe works... yes >> POSSIBLE_MSVC_DLL /cygdrive/c/Program >> POSSIBLE_MSVC_DLL Files >> POSSIBLE_MSVC_DLL (x86)/Microsoft >> POSSIBLE_MSVC_DLL Visual >> POSSIBLE_MSVC_DLL Studio >> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >> configure: Found msvcr120.dll at >> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >> SYSTEMROOT >> >> So basically, build does not correctly search for msvcr120.dll in >> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >> fails and falls back to the system default >> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >> and so configure fails. >> >> Note that 64bit build shows exactly the same behaviour! Only there it >> works by accident, since the default >> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >> 64bit library too, so configure succeeds. >> >> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >> one or more files, but that for expression should be quoted. >> >> If I make this fix: >> >> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 2018 >> -0700 >> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 2018 >> +0200 >> @@ -556,7 +556,7 @@ >> fi >> fi >> # In case any of the above finds more than one file, loop over >> them. >> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >> [$possible_msvc_dll], >> [well-known location in VCINSTALLDIR]) >> >> >> the 32bit configure correctly sets the msvcrt dll: >> >> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >> configure: Found msvcr120.dll at /cygdrive/c/Program Files >> (x86)/Microsoft Visual Studio >> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >> location in VCINSTALLDIR >> checking found msvcr120.dll architecture... ok >> >> and I can start the build, but I get follow up errors: >> >> ... >> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >> Compiling 2 files for BUILD_JVMTI_TOOLS >> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >> >> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >> Stop. >> make[3]: *** Waiting for unfinished jobs.... >> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> >> I stopped looking at that point, but to me it looks like the build >> cannot survive msvcrt.dll locations with spaces in them. >> >> Kind Regards, Thomas > > From erik.helin at oracle.com Thu May 3 13:19:10 2018 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 3 May 2018 15:19:10 +0200 Subject: RFR: 8200729: Conditional compilation of GCs In-Reply-To: References: Message-ID: <1a5cc589-79cf-4139-d894-c4dc3e3ca6bd@oracle.com> On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > Hi all, Hi Stefan, thanks for taking on this work, much appreciated! On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > The first patch simply cleans up some INCLUDE_ALL_GCS usages in platform-specific files. Some of these changes are already being cleaned up by other RFEs: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ Looks good, Reviewed. On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > The second patch pre-cleans some include files: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ Also looks good, Reviewed. On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > The following is the main patch, which include all relevant HotSpot changes. For a while now, we have been actively working on abstracting away GC specific code from non-GC directories, but as can be seen in this patch, there are still a few places left. Hopefully, we will get rid of most of these in the near future. > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ Very nice, just one small nit: - barrierSetConfig.hpp: could you move "+ G1GC_ONLY(f(G1BarrierSet))" into FOR_EACH_CONCRETE_BARRIER_SET_DO ? As in // Do something for each concrete barrier set part of the build. #define FOR_EACH_CONCRETE_BARRIER_SET_DO(f) \ f(CardTableBarrierSet) \ G1GC_ONLY(f(G1BarrierSet)) As a note for people following along this thread (and to a future version of myself), the following work is ongoing to further clean up the GC specific bits and pieces sprinkled throughout the rest of the VM: - 8202377: Modularize C2 GC barriers - 8202547: Move G1 runtime calls used by generated code to G1BarrierSetRuntime - 8201436: Replace oop_ps_push_contents with oop_iterate and closure In addition to the above work, this patch highlights a few more places that needs to be taken care of: - get rid of #if INCLUDE_CMS in defNewGeneration.cpp - split collector specific parts of gcTrace.hpp into collector specific tracers - rework Threads::create_thread_roots_tasks into something more generic that parallel then can use to implement its own create_thread_roots_task - remove marksweep_init() and set up MarkSweep::_gc_timer and MarkSweep::_gc_tracer in SerialHeap and ParallelScavengeHeap - benchmark (and measure file sizes) to see if it is still worthwhile to keep the INCLUDE_OOP_OOP_ITERATE_BACKWARDS guard (i.e. can we always compile the oop_iterate_backwards methods?) - need to do some work to encapsulate the G1 and CDS code (see e.g. oop.cpp, metaspaceShared.cpp and file.cpp) - move VM_CollectForMetadataAllocation::initiate_concurrent_GC to something like CollectedHeap::initiate_concurrent_GC_for_metadata_allocation (preferably with a shorter name (the above list is _not_ complete, there will always be a need for cleanups :D) > The last patch adds the make file support to turn on and off the different GCs. The content of this patch has evolved from versions written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that they match the INCLUDE_ defines. > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ My Makefile knowledge is limited to smaller hacks, I will leave this patch for Magnus to review (which I see he already has done). Overall, very nice work Stefan, thanks! Erik From stefan.karlsson at oracle.com Thu May 3 13:29:21 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 3 May 2018 15:29:21 +0200 Subject: RFR: 8200729: Conditional compilation of GCs In-Reply-To: <1a5cc589-79cf-4139-d894-c4dc3e3ca6bd@oracle.com> References: <1a5cc589-79cf-4139-d894-c4dc3e3ca6bd@oracle.com> Message-ID: On 2018-05-03 15:19, Erik Helin wrote: > On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > > Hi all, > > Hi Stefan, > > thanks for taking on this work, much appreciated! > > On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > > The first patch simply cleans up some INCLUDE_ALL_GCS usages in > platform-specific files. Some of these changes are already being cleaned > up by other RFEs: > > > > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ > > > Looks good, Reviewed. > > On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > > The second patch pre-cleans some include files: > > > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ > > Also looks good, Reviewed. > > On 05/02/2018 04:37 PM, Stefan Karlsson wrote: > > The following is the main patch, which include all relevant HotSpot > changes. For a while now, we have been actively working on abstracting > away GC specific code from non-GC directories, but as can be seen in > this patch, there are still a few places left. Hopefully, we will get > rid of most of these in the near future. > > > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ > > Very nice, just one small nit: > > - barrierSetConfig.hpp: > ? could you move "+? G1GC_ONLY(f(G1BarrierSet))" into > ? FOR_EACH_CONCRETE_BARRIER_SET_DO ? As in > > ?? // Do something for each concrete barrier set part of the build. > ?? #define FOR_EACH_CONCRETE_BARRIER_SET_DO(f)????????? \ > ???? f(CardTableBarrierSet)???????????????????????????? \ > ???? G1GC_ONLY(f(G1BarrierSet)) > Yes. That's better. > As a note for people following along this thread (and to a future > version of myself), the following work is ongoing to further clean up > the GC specific bits and pieces sprinkled throughout the rest of the VM: > - 8202377: Modularize C2 GC barriers > - 8202547: Move G1 runtime calls used by generated code to > G1BarrierSetRuntime > - 8201436: Replace oop_ps_push_contents with oop_iterate and closure > > In addition to the above work, this patch highlights a few more places > that needs to be taken care of: > - get rid of #if INCLUDE_CMS in defNewGeneration.cpp > - split collector specific parts of gcTrace.hpp into collector > ? specific tracers > - rework Threads::create_thread_roots_tasks into something more generic > ? that parallel then can use to implement its own > ? create_thread_roots_task > - remove marksweep_init() and set up MarkSweep::_gc_timer and > ? MarkSweep::_gc_tracer in SerialHeap and ParallelScavengeHeap > - benchmark (and measure file sizes) to see if it is still worthwhile to > ? keep the INCLUDE_OOP_OOP_ITERATE_BACKWARDS guard (i.e. can we always > ? compile the oop_iterate_backwards methods?) > - need to do some work to encapsulate the G1 and CDS code > ? (see e.g. oop.cpp, metaspaceShared.cpp and file.cpp) > - move VM_CollectForMetadataAllocation::initiate_concurrent_GC to > ? something like > ? CollectedHeap::initiate_concurrent_GC_for_metadata_allocation > ? (preferably with a shorter name > > (the above list is _not_ complete, there will always be a need for > cleanups :D) I agree. > > > The last patch adds the make file support to turn on and off the > different GCs. The content of this patch has evolved from versions > written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed > version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but > I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that they > match the INCLUDE_ defines. > > > > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ > > > My Makefile knowledge is limited to smaller hacks, I will leave this > patch for Magnus to review (which I see he already has done). > > Overall, very nice work Stefan, thanks! Thanks Erik! StefanK > Erik From Michael.Rasmussen at roguewave.com Thu May 3 11:00:38 2018 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Thu, 3 May 2018 11:00:38 +0000 Subject: License and Usage Terms of generated API documentation In-Reply-To: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> References: , <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> Message-ID: On 2018-05-03 13:21, Magnus Ihse Bursie wrote: > A lot of links on the interwebz are pointing to the docs at > docs.oracle.com, and it would probably be quite messy if the same (or > even worse, almost the same) documentation were published both at > docs.oracle.com and java.net. Well, until quite recently, that was the case. The docs were available at both download.java.net and docs.oracle.com (though download.java.net seemed to basically just be a proxy for docs.oracle.com) Google still returns results for download.java.net for the Java 10 docs, for instance this link: https://download.java.net/java/jdk10/docs/api/java/lang/Integer.html ( https://i.imgur.com/4ZugUQa.png ) Also, the Java 11 EA docs are on download.java.net: https://download.java.net/java/early_access/jdk11/docs/api/index.html?overview-summary.html /Michael From vladimir.kozlov at oracle.com Thu May 3 15:57:27 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 May 2018 08:57:27 -0700 Subject: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT In-Reply-To: References: Message-ID: <0a4567fc-935f-2769-0c39-b6df85d3b6a6@oracle.com> Thank you, Stefan Vladimir K On 5/3/18 12:20 AM, Stefan Karlsson wrote: > Looks good to me. Thanks for fixing. > > StefanK > > On 2018-05-03 00:13, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8202552 >> >> Stefan K. found several places where #ifdef instead of #if is used for >> INCLUDE_JVMCI. >> I also found places where we can use COMPILER2_OR_JVMCI. >> >> An other problem surprised me that we don't set INCLUDE_AOT to 1. >> Makefile defines that variable without value. I changed code to match >> other variables setting - in makefile set it to 0 if it is not part of >> build and set it to 1 in macros.hpp if it is not defined. >> >> Tested with tier1, tier2 and tier2 with Graal as JIT compiler. >> From vladimir.kozlov at oracle.com Thu May 3 15:59:51 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 May 2018 08:59:51 -0700 Subject: [11] RFR(S) 8202552: [AOT][JVMCI] Incorrect usage of INCLUDE_JVMCI and INCLUDE_AOT In-Reply-To: <728b7bc3-a6ae-c913-4256-c7bc58434f70@oracle.com> References: <728b7bc3-a6ae-c913-4256-c7bc58434f70@oracle.com> Message-ID: <2b271a2b-bdb3-6d5b-dd8f-91d2e2efdff9@oracle.com> Thank you, Magnus On 5/3/18 1:40 AM, Magnus Ihse Bursie wrote: > On 2018-05-03 00:13, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8202552/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8202552 > > Looks good to me. > > Just some thinking out loud... The way we handle the responsibility > split between the makefiles and the hotspot source files is actually a > bit corny. :-( It would make more sense for the makefiles to set > -DINCLUDE_features=1 when the feature is enabled, and > -DINCLUDE_feature=0 when it is not (or just leave it out), and skip all > the #ifndef INCLUDE_ #define INCLUDE_ 1 ...in macros.hpp. Yes, I thought the same thing but it was too much change for this fix. > > But that is the work of a future cleanup. This patch makes sure we use > the same pattern everywhere, which is good. Thanks, Vladimir K > > /Magnus > > >> >> Stefan K. found several places where #ifdef instead of #if is used for >> INCLUDE_JVMCI. >> I also found places where we can use COMPILER2_OR_JVMCI. >> >> An other problem surprised me that we don't set INCLUDE_AOT to 1. >> Makefile defines that variable without value. I changed code to match >> other variables setting - in makefile set it to 0 if it is not part of >> build and set it to 1 in macros.hpp if it is not defined. >> >> Tested with tier1, tier2 and tier2 with Graal as JIT compiler. > From vladimir.kozlov at oracle.com Thu May 3 16:56:20 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 May 2018 09:56:20 -0700 Subject: RFR: 8200729: Conditional compilation of GCs In-Reply-To: References: Message-ID: I see that you don't guard Use*GC flags with _ONLY macros. It is hard to figure out from gcConfig.cpp what happened if UseG1GC is specified on command line for VM which does not include it. What happens? I don't see C1 changes but it looks like it was changed with 8201543. C2 changes seems fine but they will be also affected by 8202377. What is left is AOT and JVMCI/Graal. We thought to implement "cross" compilation when we can specify for which configuration we should generate AOT code. It includes GC barriers code. Currently I see that you keep all GCs in build as before so it is not a issue. And we record VM version so we will not generate and use G1 barriers if it is not in VM used by jaotc. So it seems to me compiler and AOT, Graal changes are fine. I would suggest in addition to hs-tier2 testing run hs-tier2-graal to make sure Graal still works. Thanks, Vladimir On 5/2/18 7:37 AM, Stefan Karlsson wrote: > Hi all, > > Please review these patches to allow for conditional compilation of the > GCs in HotSpot. > > Full patch: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ > > (See below for a more fine-grained division into smaller patches) > > Today Parallel, G1, and CMS, are all guarded by INCLUDE_ALL_GCS. > INCLUDE_ALL_GCS becomes defined to 1 for our server > (--with-jvm-variants=server) builds, and is defined to 0 for the minimal > (--with-jvm-variants=minimal) builds. There are also ways to forcefully > remove these GCs from the compilation by configuring with, for example, > --with-jvm-features=all-gcs. > > The proposed patch removes INCLUDE_ALL_GCS (and all-gcs) and replaces it > with INCLUDE_CMSGC, INCLUDE_G1GC, and INCLUDE_PARALLELGC. In addition to > that, INCLUDE_SERIALGC has been added to guard the Serial GC code. > > Future GCs should adopt this scheme before they get incorporated into > the code base. Note, that there will be some files in gc/shared that are > going to have to know about all GCs, but the goal is to have very few of > these INCLUDE_ checks in the non-GC parts of HotSpot. > > With this patch, it's also going to be easier to stop compiling CMS when > the time as come for it to move from deprecated to removed. > > Note, that even though this adds great flexibility, and allows for easy > inclusion / exclusion of GCs, there's no guarantee that a specific > combination of GCs is going to be maintained in the future. Just like > not all combinations of the different Runtime features (CDS, NMT, JFR) > and Compiler features (AOT, COMPILER1, COMPILER2) are guaranteed to > compile and be supported. I've sanity checked the different GC > configurations build locally, but I've only fully tested the "server" > variant, and "minimal" has only been built locally. > > There's a more high-level discussion around the flexibility the > --with-jvm-features flag adds, and if we really should allow it. Since > this patch only builds upon that existing flexibility, and I don't > change the two defined jvm variants, I'd appreciate if that discussion > could be kept out of this review thread. For further discussion around > this, please see: > > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021663.html > > This is the patch queue: > > The first patch simply cleans up some INCLUDE_ALL_GCS usages in > platform-specific files. Some of these changes are already being cleaned > up by other RFEs: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ > > > > The second patch pre-cleans some include files: > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ > > > The following is the main patch, which include all relevant HotSpot > changes. For a while now, we have been actively working on abstracting > away GC specific code from non-GC directories, but as can be seen in > this patch, there are still a few places left. Hopefully, we will get > rid of most of these in the near future. > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ > > > The last patch adds the make file support to turn on and off the > different GCs. The content of this patch has evolved from versions > written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed > version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but > I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that they > match the INCLUDE_ defines. > > http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ > > > Thanks, > StefanK From erik.joelsson at oracle.com Thu May 3 17:06:53 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 May 2018 10:06:53 -0700 Subject: [8u] RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols In-Reply-To: <1525347206.4079.19.camel@redhat.com> References: <1525347206.4079.19.camel@redhat.com> Message-ID: Looks good. /Erik On 2018-05-03 04:33, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this change for JDK 8u? We are seing > build failures due to unresolved symbols when building > libfontmanager.so. The build flag to trigger this is to configure with: > > --with-extra-ldflags="-Wl,-z,defs" > > Attempting a build of JDK 8 with this fails. This has been fixed in JDK > 11 and hasn't shown any issues so far. Due to the change in the build > system the JDK 11 patch does not apply cleanly after path unshuffeling > (different context it seems). Hence, asking here for a review before > asking for JDK 8 backport approval. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.jdk8/ > > Review thread for JDK 11: > http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021575.html > > Thanks, > Severin From erik.joelsson at oracle.com Thu May 3 17:13:56 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 May 2018 10:13:56 -0700 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> Message-ID: <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> Hello, On 2018-05-03 03:41, Magnus Ihse Bursie wrote: > I think the main issue here is that BASIC_FIXUP_PATH should be called > for the located msvcr*.dll files. I don't have time to look at it now, > but see if you can do a rewrite using BASIC_FIXUP_PATH when the > potential file is located. This should remove all spaces from the path. > No, that is not a good solution. I intentionally removed that BASIC_FIXUP_PATH because in VS2017, one of the files has a file name longer than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short style. This in turn has weird consequences in make when we copy that file using generated copy rules. The target file then gets the short style name literally. When I made that change, I looked at all the calls for potential locations and thought all of them had the directory prepared properly already. It seems I was wrong. I think the correct solution is to either get rid of spaces earlier for all the input directories we search, or maybe tweak BASIC_FIXUP_PATH to not touch the actual filename. /Erik > /Magnus > > On 2018-05-02 20:46, Thomas St?fe wrote: >> Hi, >> >> My 32bit builds on Windows were failing since quite a while and I >> finally had some minutes to look into that. >> >> See prior discussion here: >> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >> >> My output used to look like this: >> >> checking if fixpath.exe works... yes >> POSSIBLE_MSVC_DLL /cygdrive/c/Program >> POSSIBLE_MSVC_DLL Files >> POSSIBLE_MSVC_DLL (x86)/Microsoft >> POSSIBLE_MSVC_DLL Visual >> POSSIBLE_MSVC_DLL Studio >> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >> configure: Found msvcr120.dll at >> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >> SYSTEMROOT >> >> So basically, build does not correctly search for msvcr120.dll in >> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >> fails and falls back to the system default >> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >> and so configure fails. >> >> Note that 64bit build shows exactly the same behaviour! Only there it >> works by accident, since the default >> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >> 64bit library too, so configure succeeds. >> >> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >> one or more files, but that for expression should be quoted. >> >> If I make this fix: >> >> --- a/make/autoconf/toolchain_windows.m4??????? Mon Apr 23 18:04:17 >> 2018 -0700 >> +++ b/make/autoconf/toolchain_windows.m4??????? Wed May 02 18:38:04 >> 2018 +0200 >> @@ -556,7 +556,7 @@ >> ????????? fi >> ??????? fi >> ??????? # In case any of the above finds more than one file, loop >> over them. >> -????? for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >> +????? for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >> ????????? $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >> ????????? TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >> [$possible_msvc_dll], >> ????????????? [well-known location in VCINSTALLDIR]) >> >> >> the 32bit configure correctly sets the msvcrt dll: >> >> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >> configure: Found msvcr120.dll at /cygdrive/c/Program Files >> (x86)/Microsoft Visual Studio >> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >> location in VCINSTALLDIR >> checking found msvcr120.dll architecture... ok >> >> and I can start the build, but I get follow up errors: >> >> ... >> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >> Compiling 2 files for BUILD_JVMTI_TOOLS >> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >> >> Stop. >> make[3]: *** Waiting for unfinished jobs.... >> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> >> I stopped looking at that point, but to me it looks like the build >> cannot survive msvcrt.dll locations with spaces in them. >> >> Kind Regards, Thomas > From erik.joelsson at oracle.com Thu May 3 17:18:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 May 2018 10:18:33 -0700 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> Message-ID: <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> Also, on my windows system, if I try using my local Visual Studio, both MSVC dll's are found in the Visual Studio dir, and the spaces are all cleaned up. I wonder what's different about your setup, Thomas. /Erik On 2018-05-03 10:13, Erik Joelsson wrote: > Hello, > > On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >> I think the main issue here is that BASIC_FIXUP_PATH should be called >> for the located msvcr*.dll files. I don't have time to look at it >> now, but see if you can do a rewrite using BASIC_FIXUP_PATH when the >> potential file is located. This should remove all spaces from the path. >> > No, that is not a good solution. I intentionally removed that > BASIC_FIXUP_PATH because in VS2017, one of the files has a file name > longer than 8 characters and BASIC_FIXUP_PATH rewrites that filename > to short style. This in turn has weird consequences in make when we > copy that file using generated copy rules. The target file then gets > the short style name literally. > > When I made that change, I looked at all the calls for potential > locations and thought all of them had the directory prepared properly > already. It seems I was wrong. I think the correct solution is to > either get rid of spaces earlier for all the input directories we > search, or maybe tweak BASIC_FIXUP_PATH to not touch the actual filename. > > /Erik >> /Magnus >> >> On 2018-05-02 20:46, Thomas St?fe wrote: >>> Hi, >>> >>> My 32bit builds on Windows were failing since quite a while and I >>> finally had some minutes to look into that. >>> >>> See prior discussion here: >>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>> >>> My output used to look like this: >>> >>> checking if fixpath.exe works... yes >>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>> POSSIBLE_MSVC_DLL Files >>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>> POSSIBLE_MSVC_DLL Visual >>> POSSIBLE_MSVC_DLL Studio >>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>> configure: Found msvcr120.dll at >>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >>> SYSTEMROOT >>> >>> So basically, build does not correctly search for msvcr120.dll in >>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>> fails and falls back to the system default >>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >>> and so configure fails. >>> >>> Note that 64bit build shows exactly the same behaviour! Only there it >>> works by accident, since the default >>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>> 64bit library too, so configure succeeds. >>> >>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >>> one or more files, but that for expression should be quoted. >>> >>> If I make this fix: >>> >>> --- a/make/autoconf/toolchain_windows.m4??????? Mon Apr 23 18:04:17 >>> 2018 -0700 >>> +++ b/make/autoconf/toolchain_windows.m4??????? Wed May 02 18:38:04 >>> 2018 +0200 >>> @@ -556,7 +556,7 @@ >>> ????????? fi >>> ??????? fi >>> ??????? # In case any of the above finds more than one file, loop >>> over them. >>> -????? for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>> +????? for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>> ????????? $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>> ????????? TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>> [$possible_msvc_dll], >>> ????????????? [well-known location in VCINSTALLDIR]) >>> >>> >>> the 32bit configure correctly sets the msvcrt dll: >>> >>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>> (x86)/Microsoft Visual Studio >>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >>> location in VCINSTALLDIR >>> checking found msvcr120.dll architecture... ok >>> >>> and I can start the build, but I get follow up errors: >>> >>> ... >>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>> Compiling 2 files for BUILD_JVMTI_TOOLS >>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>> >>> Stop. >>> make[3]: *** Waiting for unfinished jobs.... >>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>> make[2]: *** Waiting for unfinished jobs.... >>> >>> I stopped looking at that point, but to me it looks like the build >>> cannot survive msvcrt.dll locations with spaces in them. >>> >>> Kind Regards, Thomas >> > From stefan.karlsson at oracle.com Thu May 3 17:22:23 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 3 May 2018 19:22:23 +0200 Subject: RFR: 8200729: Conditional compilation of GCs In-Reply-To: References: Message-ID: Hi Vladimir, On 2018-05-03 18:56, Vladimir Kozlov wrote: > I see that you don't guard Use*GC flags with _ONLY macros. It is hard to > figure out from gcConfig.cpp what happened if UseG1GC is specified on > command line for VM which does not include it. What happens? Right. The current patch leaves the Use*GC flags available in all builds, so that we can accept the flag but give a warning: $ build/slowdebug-no-g1/jdk/bin/java -XX:+UseG1GC Java HotSpot(TM) 64-Bit Server VM warning: -XX:+UseG1GC not supported in this VM This is handled in GCConfig::select_gc_ergonomically with this line: NOT_G1GC( UNSUPPORTED_OPTION(UseG1GC);) That expands into: // Disable options not supported in this release, with a warning if they // were explicitly requested on the command-line #define UNSUPPORTED_OPTION(opt) \ do { \ if (opt) { \ if (FLAG_IS_CMDLINE(opt)) { \ warning("-XX:+" #opt " not supported in this VM"); \ } \ FLAG_SET_DEFAULT(opt, false); \ } \ } while(0) > > I don't see C1 changes but it looks like it was changed with 8201543. Right. There's no INCLUDE_ guards left in C1! > C2 changes seems fine but they will be also affected by 8202377. Exactly. > > What is left is AOT and JVMCI/Graal. We thought to implement "cross" > compilation when we can specify for which configuration we should > generate AOT code. It includes GC barriers code. Currently I see that > you keep all GCs in build as before so it is not a issue. And we record > VM version so we will not generate and use G1 barriers if it is not in > VM used by jaotc. > > So it seems to me compiler and AOT, Graal changes are fine. OK. Thanks for taking a close look at this. > > I would suggest in addition to hs-tier2 testing run hs-tier2-graal to > make sure Graal still works. I'll make sure to test with hs-tier2-graal. Thanks for reviewing! StefanK > > Thanks, > Vladimir > > On 5/2/18 7:37 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review these patches to allow for conditional compilation of >> the GCs in HotSpot. >> >> Full patch: >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/all/ >> >> (See below for a more fine-grained division into smaller patches) >> >> Today Parallel, G1, and CMS, are all guarded by INCLUDE_ALL_GCS. >> INCLUDE_ALL_GCS becomes defined to 1 for our server >> (--with-jvm-variants=server) builds, and is defined to 0 for the >> minimal (--with-jvm-variants=minimal) builds. There are also ways to >> forcefully remove these GCs from the compilation by configuring with, >> for example, --with-jvm-features=all-gcs. >> >> The proposed patch removes INCLUDE_ALL_GCS (and all-gcs) and replaces >> it with INCLUDE_CMSGC, INCLUDE_G1GC, and INCLUDE_PARALLELGC. In >> addition to that, INCLUDE_SERIALGC has been added to guard the Serial >> GC code. >> >> Future GCs should adopt this scheme before they get incorporated into >> the code base. Note, that there will be some files in gc/shared that >> are going to have to know about all GCs, but the goal is to have very >> few of these INCLUDE_ checks in the non-GC parts of HotSpot. >> >> With this patch, it's also going to be easier to stop compiling CMS >> when the time as come for it to move from deprecated to removed. >> >> Note, that even though this adds great flexibility, and allows for >> easy inclusion / exclusion of GCs, there's no guarantee that a >> specific combination of GCs is going to be maintained in the future. >> Just like not all combinations of the different Runtime features (CDS, >> NMT, JFR) and Compiler features (AOT, COMPILER1, COMPILER2) are >> guaranteed to compile and be supported. I've sanity checked the >> different GC configurations build locally, but I've only fully tested >> the "server" variant, and "minimal" has only been built locally. >> >> There's a more high-level discussion around the flexibility the >> --with-jvm-features flag adds, and if we really should allow it. Since >> this patch only builds upon that existing flexibility, and I don't >> change the two defined jvm variants, I'd appreciate if that discussion >> could be kept out of this review thread. For further discussion around >> this, please see: >> >> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021663.html >> >> This is the patch queue: >> >> The first patch simply cleans up some INCLUDE_ALL_GCS usages in >> platform-specific files. Some of these changes are already being >> cleaned up by other RFEs: >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/00.removeUnneededIncludeAllGCs/ >> >> >> >> The second patch pre-cleans some include files: >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/01.fixIncludes/ >> >> >> The following is the main patch, which include all relevant HotSpot >> changes. For a while now, we have been actively working on abstracting >> away GC specific code from non-GC directories, but as can be seen in >> this patch, there are still a few places left. Hopefully, we will get >> rid of most of these in the near future. >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/02.mainPatch/ >> >> >> The last patch adds the make file support to turn on and off the >> different GCs. The content of this patch has evolved from versions >> written by myself, Per, and Magnus Ihse Bursie. Magnus last proposed >> version used the names gc-cms, gc-g1, gc-parallel, and gc-serial, but >> I've changed them to cmsgc, g1gc, parallelgc, and serialgc, so that >> they match the INCLUDE_ defines. >> >> http://cr.openjdk.java.net/~stefank/8200729/webrev.04/03.selectIndivudualGCsMakePatch/ >> >> >> Thanks, >> StefanK From bsrbnd at gmail.com Thu May 3 17:52:27 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 3 May 2018 19:52:27 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> Message-ID: Hi, On 2 May 2018 at 22:40, Kim Barrett wrote: >> On May 2, 2018, at 5:10 AM, Michal Vala wrote: >> >> >> >> On 05/01/2018 07:59 PM, Kim Barrett wrote: >>>> On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: >>>> Someone to sponsor this please? >>> Do you have a sponsor yet? If not, I?ll do it. >> >> No, I don't. I'd really appreciate if you sponsor it. > > Will do. I should be able to take care of it in the next day or so. > I've noted some similar issues at several other places which makes the JDK build fail on Linux with glibc = 2.26, see comments here: https://bugs.openjdk.java.net/browse/JDK-8202353 Here is a patch for that, does this look reasonable (tier1 seems OK)? Thanks, Bernard diff -r 1871c5d07caf src/java.base/unix/native/libjava/TimeZone_md.c --- a/src/java.base/unix/native/libjava/TimeZone_md.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/java.base/unix/native/libjava/TimeZone_md.c Thu May 03 17:59:31 2018 +0200 @@ -122,7 +122,9 @@ DIR *dirp = NULL; struct stat statbuf; struct dirent64 *dp = NULL; +#ifndef __linux__ struct dirent64 *entry = NULL; +#endif char *pathname = NULL; int fd = -1; char *dbuf = NULL; @@ -140,7 +142,7 @@ if (name_max < 1024) { name_max = 1024; } - +#ifndef __linux__ entry = (struct dirent64 *)malloc(offsetof(struct dirent64, d_name) + name_max + 1); if (entry == NULL) { (void) closedir(dirp); @@ -148,6 +150,9 @@ } while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { +#else + while ((dp = readdir64(dirp)) != NULL) { +#endif /* * Skip '.' and '..' (and possibly other .* files) */ @@ -213,10 +218,11 @@ free((void *) pathname); pathname = NULL; } - +#ifndef __linux__ if (entry != NULL) { free((void *) entry); } +#endif if (dirp != NULL) { (void) closedir(dirp); } diff -r 1871c5d07caf src/java.base/unix/native/libjava/UnixFileSystem_md.c --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Thu May 03 17:59:31 2018 +0200 @@ -312,7 +312,9 @@ { DIR *dir = NULL; struct dirent64 *ptr; +#ifndef __linux__ struct dirent64 *result; +#endif int len, maxlen; jobjectArray rv, old; jclass str_class; @@ -324,14 +326,14 @@ dir = opendir(path); } END_PLATFORM_STRING(env, path); if (dir == NULL) return NULL; - +#ifndef __linux__ ptr = malloc(sizeof(struct dirent64) + (PATH_MAX + 1)); if (ptr == NULL) { JNU_ThrowOutOfMemoryError(env, "heap allocation failed"); closedir(dir); return NULL; } - +#endif /* Allocate an initial String array */ len = 0; maxlen = 16; @@ -339,7 +341,11 @@ if (rv == NULL) goto error; /* Scan the directory */ +#ifndef __linux__ while ((readdir64_r(dir, ptr, &result) == 0) && (result != NULL)) { +#else + while ((ptr = readdir64(dir)) != NULL) { +#endif jstring name; if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) continue; @@ -360,7 +366,9 @@ (*env)->DeleteLocalRef(env, name); } closedir(dir); +#ifndef __linux__ free(ptr); +#endif /* Copy the final results into an appropriately-sized array */ old = rv; @@ -375,7 +383,9 @@ error: closedir(dir); +#ifndef __linux__ free(ptr); +#endif return NULL; } diff -r 1871c5d07caf src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Thu May 03 17:59:31 2018 +0200 @@ -726,12 +726,18 @@ char name_extra[PATH_MAX + 1 - sizeof result->d_name]; } entry; struct dirent64* ptr = &entry.buf; +#ifndef __linux__ int res; +#endif DIR* dirp = jlong_to_ptr(value); /* EINTR not listed as a possible error */ /* TDB: reentrant version probably not required here */ +#ifndef __linux__ res = readdir64_r(dirp, ptr, &result); +#else + ptr = result = readdir64(dirp); +#endif #ifdef _AIX /* On AIX, readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL for the */ @@ -741,10 +747,12 @@ } #endif +#ifndef __linux__ if (res != 0) { throwUnixException(env, res); return NULL; } else { +#endif if (result == NULL) { return NULL; } else { @@ -755,7 +763,9 @@ } return bytes; } +#ifndef __linux__ } +#endif } JNIEXPORT void JNICALL diff -r 1871c5d07caf src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Thu May 03 17:59:31 2018 +0200 @@ -75,10 +75,10 @@ #endif /* _ALLBSD_SOURCE */ static struct dirent* read_dir(DIR* dirp, struct dirent* entry) { -#ifdef __solaris__ +#if defined(__solaris__) || defined(__linux__) struct dirent* dbuf = readdir(dirp); return dbuf; -#else /* __linux__ || _ALLBSD_SOURCE */ +#else /* _ALLBSD_SOURCE */ struct dirent* p; if (readdir_r(dirp, entry, &p) == 0) { return p; From thomas.stuefe at gmail.com Thu May 3 18:17:44 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 May 2018 20:17:44 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> Message-ID: Hi Erik, I see the error on two very different machines. One is my private machine - windows 7, VS2013 and VS2017 installed. The second one is my corporate Laptop, Windows 10 and only VS2013. In both cases I use a very recent cygwin64 installation. Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using well-known location from Visual Studio 12.0 and older" case, and in the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL variable content. Here the 64bit build on my corporate laptop: checking if fixpath.exe works... yes POSSIBLE_MSVC_DLL /cygdrive/c/Program POSSIBLE_MSVC_DLL Files POSSIBLE_MSVC_DLL (x86)/Microsoft POSSIBLE_MSVC_DLL Visual POSSIBLE_MSVC_DLL Studio POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll configure: Found msvcr120.dll at /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in SYSTEMROOT checking found msvcr120.dll architecture... ok checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll POSSIBLE_MSVC_DLL /cygdrive/c/Program POSSIBLE_MSVC_DLL Files POSSIBLE_MSVC_DLL (x86)/Microsoft POSSIBLE_MSVC_DLL Visual POSSIBLE_MSVC_DLL Studio POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll configure: Found msvcp120.dll at /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in SYSTEMROOT As you can see, we fall back to the default in windows/system32, which happens to be working for 64bit. On 32bit, we get this error: checking if fixpath.exe works... yes POSSIBLE_MSVC_DLL /cygdrive/c/Program POSSIBLE_MSVC_DLL Files POSSIBLE_MSVC_DLL (x86)/Microsoft POSSIBLE_MSVC_DLL Visual POSSIBLE_MSVC_DLL Studio POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll configure: Found msvcr120.dll at /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in SYSTEMROOT checking found msvcr120.dll architecture... incorrect, ignoring configure: The file type of the located msvcr120.dll is PE32+ executable (DLL) (GUI) x86-64, for MS Windows configure: Found msvcr120.dll at /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of VCINSTALLDIR checking found msvcr120.dll architecture... incorrect, ignoring configure: The file type of the located msvcr120.dll is PE32 executable (DLL) (GUI) ARMv7 Thumb, for MS Windows checking for msvcr120.dll... no configure: error: Could not find msvcr120.dll. Please specify using --with-msvcr-dll. configure exiting with result code 1 Best Regards, Thomas On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson wrote: > Also, on my windows system, if I try using my local Visual Studio, both MSVC > dll's are found in the Visual Studio dir, and the spaces are all cleaned up. > I wonder what's different about your setup, Thomas. > > /Erik > > > > On 2018-05-03 10:13, Erik Joelsson wrote: >> >> Hello, >> >> On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >>> >>> I think the main issue here is that BASIC_FIXUP_PATH should be called for >>> the located msvcr*.dll files. I don't have time to look at it now, but see >>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is >>> located. This should remove all spaces from the path. >>> >> No, that is not a good solution. I intentionally removed that >> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name longer >> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short >> style. This in turn has weird consequences in make when we copy that file >> using generated copy rules. The target file then gets the short style name >> literally. >> >> When I made that change, I looked at all the calls for potential locations >> and thought all of them had the directory prepared properly already. It >> seems I was wrong. I think the correct solution is to either get rid of >> spaces earlier for all the input directories we search, or maybe tweak >> BASIC_FIXUP_PATH to not touch the actual filename. >> >> /Erik >>> >>> /Magnus >>> >>> On 2018-05-02 20:46, Thomas St?fe wrote: >>>> >>>> Hi, >>>> >>>> My 32bit builds on Windows were failing since quite a while and I >>>> finally had some minutes to look into that. >>>> >>>> See prior discussion here: >>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>>> >>>> My output used to look like this: >>>> >>>> checking if fixpath.exe works... yes >>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>> POSSIBLE_MSVC_DLL Files >>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>> POSSIBLE_MSVC_DLL Visual >>>> POSSIBLE_MSVC_DLL Studio >>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>> configure: Found msvcr120.dll at >>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >>>> SYSTEMROOT >>>> >>>> So basically, build does not correctly search for msvcr120.dll in >>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>>> fails and falls back to the system default >>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >>>> and so configure fails. >>>> >>>> Note that 64bit build shows exactly the same behaviour! Only there it >>>> works by accident, since the default >>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>>> 64bit library too, so configure succeeds. >>>> >>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >>>> one or more files, but that for expression should be quoted. >>>> >>>> If I make this fix: >>>> >>>> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 2018 >>>> -0700 >>>> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 2018 >>>> +0200 >>>> @@ -556,7 +556,7 @@ >>>> fi >>>> fi >>>> # In case any of the above finds more than one file, loop over >>>> them. >>>> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>>> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>>> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>>> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>>> [$possible_msvc_dll], >>>> [well-known location in VCINSTALLDIR]) >>>> >>>> >>>> the 32bit configure correctly sets the msvcrt dll: >>>> >>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>> (x86)/Microsoft Visual Studio >>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >>>> location in VCINSTALLDIR >>>> checking found msvcr120.dll architecture... ok >>>> >>>> and I can start the build, but I get follow up errors: >>>> >>>> ... >>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >>>> >>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>>> Stop. >>>> make[3]: *** Waiting for unfinished jobs.... >>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>>> make[2]: *** Waiting for unfinished jobs.... >>>> >>>> I stopped looking at that point, but to me it looks like the build >>>> cannot survive msvcrt.dll locations with spaces in them. >>>> >>>> Kind Regards, Thomas >>> >>> >> > From kim.barrett at oracle.com Thu May 3 19:43:57 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 May 2018 15:43:57 -0400 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> Message-ID: > On May 3, 2018, at 1:52 PM, B. Blaser wrote: > > Hi, > > On 2 May 2018 at 22:40, Kim Barrett wrote: >>> On May 2, 2018, at 5:10 AM, Michal Vala wrote: >>> >>> >>> >>> On 05/01/2018 07:59 PM, Kim Barrett wrote: >>>>> On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: >>>>> Someone to sponsor this please? >>>> Do you have a sponsor yet? If not, I?ll do it. >>> >>> No, I don't. I'd really appreciate if you sponsor it. >> >> Will do. I should be able to take care of it in the next day or so. >> > > I've noted some similar issues at several other places which makes the > JDK build fail on Linux with glibc = 2.26, see comments here: > https://bugs.openjdk.java.net/browse/JDK-8202353 > > Here is a patch for that, does this look reasonable (tier1 seems OK)? I think we should move in the direction of eliminating the use of readdir_r entirely, either under JDK-8202353, or leave that as only the HotSpot part and have another RFE for the uses in java.base/unix/native. From erik.joelsson at oracle.com Thu May 3 20:13:06 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 3 May 2018 13:13:06 -0700 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> Message-ID: <3055b9bb-1f01-8b9f-33fc-621043aab511@oracle.com> Hello, In my case, VCINSTALLDIR is in short form already. Could you try changing line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to BASIC_FIXUP_PATH? /Erik On 2018-05-03 11:17, Thomas St?fe wrote: > Hi Erik, > > I see the error on two very different machines. One is my private > machine - windows 7, VS2013 and VS2017 installed. The second one is my > corporate Laptop, Windows 10 and only VS2013. > > In both cases I use a very recent cygwin64 installation. > > Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using > well-known location from Visual Studio 12.0 and older" case, and in > the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL > variable content. Here the 64bit build on my corporate laptop: > > checking if fixpath.exe works... yes > POSSIBLE_MSVC_DLL /cygdrive/c/Program > POSSIBLE_MSVC_DLL Files > POSSIBLE_MSVC_DLL (x86)/Microsoft > POSSIBLE_MSVC_DLL Visual > POSSIBLE_MSVC_DLL Studio > POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll > configure: Found msvcr120.dll at > /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in > SYSTEMROOT > checking found msvcr120.dll architecture... ok > checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll > POSSIBLE_MSVC_DLL /cygdrive/c/Program > POSSIBLE_MSVC_DLL Files > POSSIBLE_MSVC_DLL (x86)/Microsoft > POSSIBLE_MSVC_DLL Visual > POSSIBLE_MSVC_DLL Studio > POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll > configure: Found msvcp120.dll at > /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in > SYSTEMROOT > > As you can see, we fall back to the default in windows/system32, which > happens to be working for 64bit. On 32bit, we get this error: > > checking if fixpath.exe works... yes > POSSIBLE_MSVC_DLL /cygdrive/c/Program > POSSIBLE_MSVC_DLL Files > POSSIBLE_MSVC_DLL (x86)/Microsoft > POSSIBLE_MSVC_DLL Visual > POSSIBLE_MSVC_DLL Studio > POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll > configure: Found msvcr120.dll at > /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in > SYSTEMROOT > checking found msvcr120.dll architecture... incorrect, ignoring > configure: The file type of the located msvcr120.dll is PE32+ > executable (DLL) (GUI) x86-64, for MS Windows > configure: Found msvcr120.dll at /cygdrive/c/Program Files > (x86)/Microsoft Visual Studio > 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of > VCINSTALLDIR > checking found msvcr120.dll architecture... incorrect, ignoring > configure: The file type of the located msvcr120.dll is PE32 > executable (DLL) (GUI) ARMv7 Thumb, for MS Windows > checking for msvcr120.dll... no > configure: error: Could not find msvcr120.dll. Please specify using > --with-msvcr-dll. > configure exiting with result code 1 > > Best Regards, Thomas > > On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson wrote: >> Also, on my windows system, if I try using my local Visual Studio, both MSVC >> dll's are found in the Visual Studio dir, and the spaces are all cleaned up. >> I wonder what's different about your setup, Thomas. >> >> /Erik >> >> >> >> On 2018-05-03 10:13, Erik Joelsson wrote: >>> Hello, >>> >>> On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >>>> I think the main issue here is that BASIC_FIXUP_PATH should be called for >>>> the located msvcr*.dll files. I don't have time to look at it now, but see >>>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential file is >>>> located. This should remove all spaces from the path. >>>> >>> No, that is not a good solution. I intentionally removed that >>> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name longer >>> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short >>> style. This in turn has weird consequences in make when we copy that file >>> using generated copy rules. The target file then gets the short style name >>> literally. >>> >>> When I made that change, I looked at all the calls for potential locations >>> and thought all of them had the directory prepared properly already. It >>> seems I was wrong. I think the correct solution is to either get rid of >>> spaces earlier for all the input directories we search, or maybe tweak >>> BASIC_FIXUP_PATH to not touch the actual filename. >>> >>> /Erik >>>> /Magnus >>>> >>>> On 2018-05-02 20:46, Thomas St?fe wrote: >>>>> Hi, >>>>> >>>>> My 32bit builds on Windows were failing since quite a while and I >>>>> finally had some minutes to look into that. >>>>> >>>>> See prior discussion here: >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>>>> >>>>> My output used to look like this: >>>>> >>>>> checking if fixpath.exe works... yes >>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>> POSSIBLE_MSVC_DLL Files >>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>> POSSIBLE_MSVC_DLL Visual >>>>> POSSIBLE_MSVC_DLL Studio >>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>>> configure: Found msvcr120.dll at >>>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >>>>> SYSTEMROOT >>>>> >>>>> So basically, build does not correctly search for msvcr120.dll in >>>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>>>> fails and falls back to the system default >>>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >>>>> and so configure fails. >>>>> >>>>> Note that 64bit build shows exactly the same behaviour! Only there it >>>>> works by accident, since the default >>>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>>>> 64bit library too, so configure succeeds. >>>>> >>>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >>>>> one or more files, but that for expression should be quoted. >>>>> >>>>> If I make this fix: >>>>> >>>>> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 2018 >>>>> -0700 >>>>> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 2018 >>>>> +0200 >>>>> @@ -556,7 +556,7 @@ >>>>> fi >>>>> fi >>>>> # In case any of the above finds more than one file, loop over >>>>> them. >>>>> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>>>> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>>>> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>>>> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>>>> [$possible_msvc_dll], >>>>> [well-known location in VCINSTALLDIR]) >>>>> >>>>> >>>>> the 32bit configure correctly sets the msvcrt dll: >>>>> >>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>>> (x86)/Microsoft Visual Studio >>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >>>>> location in VCINSTALLDIR >>>>> checking found msvcr120.dll architecture... ok >>>>> >>>>> and I can start the build, but I get follow up errors: >>>>> >>>>> ... >>>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >>>>> >>>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>>>> Stop. >>>>> make[3]: *** Waiting for unfinished jobs.... >>>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>>>> make[2]: *** Waiting for unfinished jobs.... >>>>> >>>>> I stopped looking at that point, but to me it looks like the build >>>>> cannot survive msvcrt.dll locations with spaces in them. >>>>> >>>>> Kind Regards, Thomas >>>> From gary.adams at oracle.com Thu May 3 22:01:37 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 3 May 2018 18:01:37 -0400 Subject: Fwd: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 In-Reply-To: References: <5AE1FFD0.1090803@oracle.com> Message-ID: <95043b95-1427-3576-4ad9-30aa18d016c7@oracle.com> Attached an updated patch for 8202319. Kim or David could you please sponsor the push of the patch. On 4/26/18 6:49 PM, gary.adams at oracle.com wrote: > > Adding build-dev and hotspot-runtime-dev aliases. > > -------- Forwarded Message -------- > Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug > builds for DevStudio 12.6 > Date: Thu, 26 Apr 2018 12:35:28 -0400 > From: Gary Adams > Reply-To: gary.adams at oracle.com > To: OpenJDK Serviceability > > > > Getting the sources ready for the next Solaris developer studio toolchain. > Some additional warnings were found in the debug build. > > ?Issue:https://bugs.openjdk.java.net/browse/JDK-8202319 > Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/ > > This update conditionally disables some new error checks, if the > new toolchain is used. -------------- next part -------------- # HG changeset patch # User gadams # Date 1525176684 14400 # Tue May 01 08:11:24 2018 -0400 # Node ID c2219a364d79a09d5de1480ee1fc280e6fcb0f16 # Parent 2ace90aec48858c5d82fd64b546c29b395ea5524 8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 Reviewed-by: kbarrett, dholmes diff --git a/src/hotspot/share/runtime/frame.cpp b/src/hotspot/share/runtime/frame.cpp --- a/src/hotspot/share/runtime/frame.cpp +++ b/src/hotspot/share/runtime/frame.cpp @@ -1103,6 +1103,9 @@ void frame::oops_do_internal(OopClosure* f, CodeBlobClosure* cf, RegisterMap* map, bool use_interpreter_oop_map_cache) { #ifndef PRODUCT +#if defined(__SUNPRO_CC) && __SUNPRO_CC >= 0x5140 +#pragma error_messages(off, SEC_NULL_PTR_DEREF) +#endif // simulate GC crash here to dump java thread in error report if (CrashGCForDumpingJavaThread) { char *t = NULL; diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp --- a/src/hotspot/share/utilities/vmError.cpp +++ b/src/hotspot/share/utilities/vmError.cpp @@ -1606,6 +1606,9 @@ } #ifndef PRODUCT +#if defined(__SUNPRO_CC) && __SUNPRO_CC >= 0x5140 +#pragma error_messages(off, SEC_NULL_PTR_DEREF) +#endif typedef void (*voidfun_t)(); // Crash with an authentic sigfpe static void crash_with_sigfpe() { From david.holmes at oracle.com Thu May 3 22:15:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 May 2018 08:15:39 +1000 Subject: Fwd: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 In-Reply-To: <95043b95-1427-3576-4ad9-30aa18d016c7@oracle.com> References: <5AE1FFD0.1090803@oracle.com> <95043b95-1427-3576-4ad9-30aa18d016c7@oracle.com> Message-ID: <5a4dabc1-852b-aff9-d47b-e0b42667b70b@oracle.com> Looks okay. Thanks, David On 4/05/2018 8:01 AM, gary.adams at oracle.com wrote: > Attached an updated patch for 8202319. > Kim or David could you please sponsor the push of the patch. > > On 4/26/18 6:49 PM, gary.adams at oracle.com wrote: >> >> Adding build-dev and hotspot-runtime-dev aliases. >> >> -------- Forwarded Message -------- >> Subject:???? RFR: JDK-8202319: Fix compilation warnings in Solaris >> debug builds for DevStudio 12.6 >> Date:???? Thu, 26 Apr 2018 12:35:28 -0400 >> From:???? Gary Adams >> Reply-To:???? gary.adams at oracle.com >> To:???? OpenJDK Serviceability >> >> >> >> Getting the sources ready for the next Solaris developer studio >> toolchain. >> Some additional warnings were found in the debug build. >> >> ?? ?Issue:https://bugs.openjdk.java.net/browse/JDK-8202319 >> ??? Webrev:http://cr.openjdk.java.net/~gadams/8202319/webrev.00/ >> >> This update conditionally disables some new error checks, if the >> new toolchain is used. > > From igor.ignatyev at oracle.com Fri May 4 04:14:21 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 3 May 2018 21:14:21 -0700 Subject: RFR(L) : 8199382 : [TESTBUG] Open source VM testbase JDI tests Message-ID: <302F3A6E-6485-42E7-BB6C-B21A483B18F2@oracle.com> http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html > 577169 lines changed: 577169 ins; 0 del; 0 mod; Hi all, could you please review the patch which open sources JDI tests from vm testbase? These tests cover different aspects of JDI implementation. As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. JBS: https://bugs.openjdk.java.net/browse/JDK-8199382 webrev: http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html testing: vmTestbase_nsk_jdi test group Thanks, -- Igor From thomas.stuefe at gmail.com Fri May 4 06:30:39 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 4 May 2018 08:30:39 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: <3055b9bb-1f01-8b9f-33fc-621043aab511@oracle.com> References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> <3055b9bb-1f01-8b9f-33fc-621043aab511@oracle.com> Message-ID: Hi Erik, that worked on both machines for all builds. Thanks, Thomas On Thu, May 3, 2018 at 10:13 PM, Erik Joelsson wrote: > Hello, > > In my case, VCINSTALLDIR is in short form already. Could you try changing > line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to BASIC_FIXUP_PATH? > > /Erik > > > > On 2018-05-03 11:17, Thomas St?fe wrote: >> >> Hi Erik, >> >> I see the error on two very different machines. One is my private >> machine - windows 7, VS2013 and VS2017 installed. The second one is my >> corporate Laptop, Windows 10 and only VS2013. >> >> In both cases I use a very recent cygwin64 installation. >> >> Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using >> well-known location from Visual Studio 12.0 and older" case, and in >> the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL >> variable content. Here the 64bit build on my corporate laptop: >> >> checking if fixpath.exe works... yes >> POSSIBLE_MSVC_DLL /cygdrive/c/Program >> POSSIBLE_MSVC_DLL Files >> POSSIBLE_MSVC_DLL (x86)/Microsoft >> POSSIBLE_MSVC_DLL Visual >> POSSIBLE_MSVC_DLL Studio >> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >> configure: Found msvcr120.dll at >> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >> SYSTEMROOT >> checking found msvcr120.dll architecture... ok >> checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll >> POSSIBLE_MSVC_DLL /cygdrive/c/Program >> POSSIBLE_MSVC_DLL Files >> POSSIBLE_MSVC_DLL (x86)/Microsoft >> POSSIBLE_MSVC_DLL Visual >> POSSIBLE_MSVC_DLL Studio >> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll >> configure: Found msvcp120.dll at >> /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in >> SYSTEMROOT >> >> As you can see, we fall back to the default in windows/system32, which >> happens to be working for 64bit. On 32bit, we get this error: >> >> checking if fixpath.exe works... yes >> POSSIBLE_MSVC_DLL /cygdrive/c/Program >> POSSIBLE_MSVC_DLL Files >> POSSIBLE_MSVC_DLL (x86)/Microsoft >> POSSIBLE_MSVC_DLL Visual >> POSSIBLE_MSVC_DLL Studio >> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >> configure: Found msvcr120.dll at >> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >> SYSTEMROOT >> checking found msvcr120.dll architecture... incorrect, ignoring >> configure: The file type of the located msvcr120.dll is PE32+ >> executable (DLL) (GUI) x86-64, for MS Windows >> configure: Found msvcr120.dll at /cygdrive/c/Program Files >> (x86)/Microsoft Visual Studio >> 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of >> VCINSTALLDIR >> checking found msvcr120.dll architecture... incorrect, ignoring >> configure: The file type of the located msvcr120.dll is PE32 >> executable (DLL) (GUI) ARMv7 Thumb, for MS Windows >> checking for msvcr120.dll... no >> configure: error: Could not find msvcr120.dll. Please specify using >> --with-msvcr-dll. >> configure exiting with result code 1 >> >> Best Regards, Thomas >> >> On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson >> wrote: >>> >>> Also, on my windows system, if I try using my local Visual Studio, both >>> MSVC >>> dll's are found in the Visual Studio dir, and the spaces are all cleaned >>> up. >>> I wonder what's different about your setup, Thomas. >>> >>> /Erik >>> >>> >>> >>> On 2018-05-03 10:13, Erik Joelsson wrote: >>>> >>>> Hello, >>>> >>>> On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >>>>> >>>>> I think the main issue here is that BASIC_FIXUP_PATH should be called >>>>> for >>>>> the located msvcr*.dll files. I don't have time to look at it now, but >>>>> see >>>>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential file >>>>> is >>>>> located. This should remove all spaces from the path. >>>>> >>>> No, that is not a good solution. I intentionally removed that >>>> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name >>>> longer >>>> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short >>>> style. This in turn has weird consequences in make when we copy that >>>> file >>>> using generated copy rules. The target file then gets the short style >>>> name >>>> literally. >>>> >>>> When I made that change, I looked at all the calls for potential >>>> locations >>>> and thought all of them had the directory prepared properly already. It >>>> seems I was wrong. I think the correct solution is to either get rid of >>>> spaces earlier for all the input directories we search, or maybe tweak >>>> BASIC_FIXUP_PATH to not touch the actual filename. >>>> >>>> /Erik >>>>> >>>>> /Magnus >>>>> >>>>> On 2018-05-02 20:46, Thomas St?fe wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> My 32bit builds on Windows were failing since quite a while and I >>>>>> finally had some minutes to look into that. >>>>>> >>>>>> See prior discussion here: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>>>>> >>>>>> My output used to look like this: >>>>>> >>>>>> checking if fixpath.exe works... yes >>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>>> POSSIBLE_MSVC_DLL Files >>>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>>> POSSIBLE_MSVC_DLL Visual >>>>>> POSSIBLE_MSVC_DLL Studio >>>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>>>> configure: Found msvcr120.dll at >>>>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >>>>>> SYSTEMROOT >>>>>> >>>>>> So basically, build does not correctly search for msvcr120.dll in >>>>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>>>>> fails and falls back to the system default >>>>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >>>>>> and so configure fails. >>>>>> >>>>>> Note that 64bit build shows exactly the same behaviour! Only there it >>>>>> works by accident, since the default >>>>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>>>>> 64bit library too, so configure succeeds. >>>>>> >>>>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>>>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >>>>>> one or more files, but that for expression should be quoted. >>>>>> >>>>>> If I make this fix: >>>>>> >>>>>> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 >>>>>> 2018 >>>>>> -0700 >>>>>> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 >>>>>> 2018 >>>>>> +0200 >>>>>> @@ -556,7 +556,7 @@ >>>>>> fi >>>>>> fi >>>>>> # In case any of the above finds more than one file, loop >>>>>> over >>>>>> them. >>>>>> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>>>>> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>>>>> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>>>>> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>>>>> [$possible_msvc_dll], >>>>>> [well-known location in VCINSTALLDIR]) >>>>>> >>>>>> >>>>>> the 32bit configure correctly sets the msvcrt dll: >>>>>> >>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>>>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>>>> (x86)/Microsoft Visual Studio >>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >>>>>> location in VCINSTALLDIR >>>>>> checking found msvcr120.dll architecture... ok >>>>>> >>>>>> and I can start the build, but I get follow up errors: >>>>>> >>>>>> ... >>>>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>>>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >>>>>> >>>>>> >>>>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>>>>> Stop. >>>>>> make[3]: *** Waiting for unfinished jobs.... >>>>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>>>>> make[2]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> I stopped looking at that point, but to me it looks like the build >>>>>> cannot survive msvcrt.dll locations with spaces in them. >>>>>> >>>>>> Kind Regards, Thomas >>>>> >>>>> > From jan.lahoda at oracle.com Fri May 4 13:48:55 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 4 May 2018 15:48:55 +0200 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEBB6FE.5090400@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> Message-ID: <5AEC64C7.9020206@oracle.com> [+build-dev] On 4.5.2018 03:27, Jonathan Gibbons wrote: > OK. > > It would be even better, perhaps in a subsequent update, if > make/gendata/Gendata-jdk.compiler.gmk > did not have to be updated for each release ... i.e. by changing A to B, > and soon to C etc. The version > letter can surely be inferred by the system. True. Updated webrevs: http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ (code changes, including update to Makefiles to automatically infer the current JDK version) http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ (historical data for JDK 10, similar patches will be needed for each new JDK version) How does this look? Thanks, Jan > > -- Jon > > > > On 05/03/2018 11:07 AM, Jan Lahoda wrote: >> Hi, >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8202387 >> >> This patch adds historical data for JDK 10 and adds support for >> --release 11. >> >> To simplify adding new platforms, the CreateSymbols tool is updated to >> support incrementally adding platform support. So now it is possible >> to run command like: >> /bin/java >> build.tools.symbolgenerator.CreateSymbols >> build-description-incremental symbols include.list >> >> to add historical data for JDK 10. In the future it might even be >> possible to use the source launcher so that one would not need to >> compile the tool before use. >> >> The webrevs are split into two: >> -updating the CreateSymbols tool, and adding a test that verifies that >> "--release " works (as suggested): >> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >> -actually adding the data for JDK 10, and adding --release 11: >> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >> >> How does this look? >> >> Thanks, >> Jan > From christoph.langer at sap.com Fri May 4 14:07:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 4 May 2018 14:07:00 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) Message-ID: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> Hi, please help reviewing the contribution of the support for the AIX Input Method Editor (IME) in AWT's Input Method Framework. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 I took Ichiroh's initial proposal [1] and tried to integrate it better with existing code. I have split src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into a) a base class containing the common code: src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java b) a specific class for the common Linux/Unixes: src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and c) a specific class for AIX: src/java.desktop/aix/classes/sun/awt/X11InputMethod.java The AIX specific additions to the native code of src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so much that I decided to add a specific implementation file for AIX: src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The changes to the former file are some cleanups. I'm still in the process of testing the changes - but maybe you can run further tests, especially on non-AIX unixes to make sure we didn't break something. Thanks & Best regards Christoph [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013869.html From bsrbnd at gmail.com Fri May 4 15:31:26 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 4 May 2018 17:31:26 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> Message-ID: On 3 May 2018 at 21:43, Kim Barrett wrote: >> On May 3, 2018, at 1:52 PM, B. Blaser wrote: >> >> Hi, >> >> On 2 May 2018 at 22:40, Kim Barrett wrote: >>>> On May 2, 2018, at 5:10 AM, Michal Vala wrote: >>>> >>>> >>>> >>>> On 05/01/2018 07:59 PM, Kim Barrett wrote: >>>>>> On Apr 27, 2018, at 4:26 PM, Michal Vala wrote: >>>>>> Someone to sponsor this please? >>>>> Do you have a sponsor yet? If not, I?ll do it. >>>> >>>> No, I don't. I'd really appreciate if you sponsor it. >>> >>> Will do. I should be able to take care of it in the next day or so. >>> >> >> I've noted some similar issues at several other places which makes the >> JDK build fail on Linux with glibc = 2.26, see comments here: >> https://bugs.openjdk.java.net/browse/JDK-8202353 >> >> Here is a patch for that, does this look reasonable (tier1 seems OK)? > > I think we should move in the direction of eliminating the use of readdir_r entirely, > either under JDK-8202353, or leave that as only the HotSpot part and have another > RFE for the uses in java.base/unix/native. I'll create a new JBS issue (unless you want to) since the fix is mostly located in core-libs and only intended to make the build complete. But I'll still need someone to review and push the fix, would you be interested in doing this? Thanks, Bernard From erik.joelsson at oracle.com Fri May 4 15:33:12 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 May 2018 08:33:12 -0700 Subject: RFR(L) : 8199382 : [TESTBUG] Open source VM testbase JDI tests In-Reply-To: <302F3A6E-6485-42E7-BB6C-B21A483B18F2@oracle.com> References: <302F3A6E-6485-42E7-BB6C-B21A483B18F2@oracle.com> Message-ID: Build change looks good. /Erik On 2018-05-03 21:14, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html >> 577169 lines changed: 577169 ins; 0 del; 0 mod; > Hi all, > > could you please review the patch which open sources JDI tests from vm testbase? These tests cover different aspects of JDI implementation. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199382 > webrev: http://cr.openjdk.java.net/~iignatyev/8199382/webrev.00/index.html > testing: vmTestbase_nsk_jdi test group > > Thanks, > -- Igor From erik.joelsson at oracle.com Fri May 4 15:36:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 May 2018 08:36:50 -0700 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEC64C7.9020206@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> Message-ID: <62cbe2a0-dc93-5f7f-8888-b8708d064a0d@oracle.com> Build change looks good. /Erik On 2018-05-04 06:48, Jan Lahoda wrote: > [+build-dev] > > On 4.5.2018 03:27, Jonathan Gibbons wrote: >> OK. >> >> It would be even better, perhaps in a subsequent update, if >> make/gendata/Gendata-jdk.compiler.gmk >> did not have to be updated for each release ... i.e. by changing A to B, >> and soon to C etc. The version >> letter can surely be inferred by the system. > > True. Updated webrevs: > http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ > (code changes, including update to Makefiles to automatically infer > the current JDK version) > > http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ > (historical data for JDK 10, similar patches will be needed for each > new JDK version) > > How does this look? > > Thanks, > ??? Jan > >> >> -- Jon >> >> >> >> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>> >>> This patch adds historical data for JDK 10 and adds support for >>> --release 11. >>> >>> To simplify adding new platforms, the CreateSymbols tool is updated to >>> support incrementally adding platform support. So now it is possible >>> to run command like: >>> /bin/java >>> build.tools.symbolgenerator.CreateSymbols >>> build-description-incremental symbols include.list >>> >>> to add historical data for JDK 10. In the future it might even be >>> possible to use the source launcher so that one would not need to >>> compile the tool before use. >>> >>> The webrevs are split into two: >>> -updating the CreateSymbols tool, and adding a test that verifies that >>> "--release " works (as suggested): >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>> -actually adding the data for JDK 10, and adding --release 11: >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>> >>> How does this look? >>> >>> Thanks, >>> ??? Jan >> From Alan.Bateman at oracle.com Fri May 4 15:42:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 4 May 2018 16:42:59 +0100 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> Message-ID: <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> On 04/05/2018 16:31, B. Blaser wrote: > : > > I'll create a new JBS issue (unless you want to) since the fix is > mostly located in core-libs and only intended to make the build > complete. > But I'll still need someone to review and push the fix, would you be > interested in doing this? > I think someone needs to explore the behavior on other platforms too as the #ifndef __linux__ patches are ugly. Is there discussion on the original thread about this? -Alan From erik.joelsson at oracle.com Fri May 4 15:44:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 May 2018 08:44:47 -0700 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> Message-ID: <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> Hello, It looks like what you are trying to achieve is to override awt_InputMethod.c with an OS specific version of that file. We have a construct for this in SetupNativeCompilation that should handle it automatically, if you just list the source dirs in priority order. I would suggest leveraging this by making this change instead: First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like this: $(wildcard $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) \ /Erik On 2018-05-04 07:07, Langer, Christoph wrote: > Hi, > > please help reviewing the contribution of the support for the AIX Input Method Editor (IME) in AWT's Input Method Framework. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 > > I took Ichiroh's initial proposal [1] and tried to integrate it better with existing code. I have split src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into > a) a base class containing the common code: src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java > b) a specific class for the common Linux/Unixes: src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and > c) a specific class for AIX: src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > > The AIX specific additions to the native code of src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so much that I decided to add a specific implementation file for AIX: src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The changes to the former file are some cleanups. > > I'm still in the process of testing the changes - but maybe you can run further tests, especially on non-AIX unixes to make sure we didn't break something. > > Thanks & Best regards > Christoph > > [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018-April/013869.html > From kim.barrett at oracle.com Fri May 4 16:23:48 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 May 2018 12:23:48 -0400 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> Message-ID: <815413A7-5809-4820-A939-F9EC4D8AD61C@oracle.com> > On May 4, 2018, at 11:42 AM, Alan Bateman wrote: > > On 04/05/2018 16:31, B. Blaser wrote: >> : >> >> I'll create a new JBS issue (unless you want to) since the fix is >> mostly located in core-libs and only intended to make the build >> complete. >> But I'll still need someone to review and push the fix, would you be >> interested in doing this? >> > I think someone needs to explore the behavior on other platforms too as the #ifndef __linux__ patches are ugly. Is there discussion on the original thread about this? > > -Alan Yes, see https://bugs.openjdk.java.net/browse/JDK-8202353 From forax at univ-mlv.fr Fri May 4 16:09:35 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 4 May 2018 18:09:35 +0200 (CEST) Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEC64C7.9020206@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> Message-ID: <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> Hi Jan, there is several occurences of Arrays.asList() that can be replaced by List.of() to make them really immutable. in CreateSymbols.java in dumpCurrentClasses, while ((read = in.read()) != (-1)) { baos.write(read); } should be replaced by in.transferTo(baos); in TransitiveDependencies.java, - todo should be an ArrayDeque instead of a LinkedList, array based data structure are usually faster - newBufferedWriter can takes only one argument in PreviewOptionTest.java, - versionsToTest.stream().forEach can be replaced by versionsToTest.forEach regards, R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "jonathan gibbons" , "compiler-dev" , > build-dev at openjdk.java.net > Envoy?: Vendredi 4 Mai 2018 15:48:55 > Objet: Re: RFR : JDK-8202387: javac --release 11 not supported > [+build-dev] > > On 4.5.2018 03:27, Jonathan Gibbons wrote: >> OK. >> >> It would be even better, perhaps in a subsequent update, if >> make/gendata/Gendata-jdk.compiler.gmk >> did not have to be updated for each release ... i.e. by changing A to B, >> and soon to C etc. The version >> letter can surely be inferred by the system. > > True. Updated webrevs: > http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ > (code changes, including update to Makefiles to automatically infer the > current JDK version) > > http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ > (historical data for JDK 10, similar patches will be needed for each new > JDK version) > > How does this look? > > Thanks, > Jan > >> >> -- Jon >> >> >> >> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>> >>> This patch adds historical data for JDK 10 and adds support for >>> --release 11. >>> >>> To simplify adding new platforms, the CreateSymbols tool is updated to >>> support incrementally adding platform support. So now it is possible >>> to run command like: >>> /bin/java >>> build.tools.symbolgenerator.CreateSymbols >>> build-description-incremental symbols include.list >>> >>> to add historical data for JDK 10. In the future it might even be >>> possible to use the source launcher so that one would not need to >>> compile the tool before use. >>> >>> The webrevs are split into two: >>> -updating the CreateSymbols tool, and adding a test that verifies that >>> "--release " works (as suggested): >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>> -actually adding the data for JDK 10, and adding --release 11: >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan From alexey.ivanov at oracle.com Fri May 4 17:45:37 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 4 May 2018 18:45:37 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> Message-ID: <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> Hi Phil, Just to confirm: do you approve the change? Thank you, Alexey On 02/05/2018 19:24, Alexey Ivanov wrote: > Hi Phil, > > Thank you for your review. > > On 02/05/2018 17:28, Phil Race wrote: >> So ... the original change that removed the mapfiles broke the 32 bit >> build >> because of inconsistency between declarations + definitions of some >> functions. >> It did not affect 64 bit build because JNICALL is a no-op there. >> >> The next change (8201226) added JNICALL to make it consistent, but >> was not reviewed on 2d and was pushed without such review >> and may have fixed build issues but did NOT fix the product. > > Yes, you're right. It made the product buildable but it did not fix > the product. > >> >> This change now removes JNICALL where it is not needed and fixes the >> product and does not break >> any builds! >> >> Please confirm that you've run 64+32 bit builds through the build >> system AND run imaging tests >> on both of those. > > Yes, I ran 64 builds through the build system and ran 32 bit Windows > build on my laptop. > > I ran regression tests from test/jdk/java/awt/image with both 64 and > 32 bit builds on Windows. No failures. > > > Regards, > Alexey > >> >> After that is confirmed you have my OK. >> >> -phil. >> >> On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >>> Looks good to me, but you should have a reviewer from the client >>> team as well. >>> >>> /Magnus >>> >>>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>>> >>>> Hi, >>>> >>>> Could you please review the following fix for jdk11? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>>> >>>> This is a follow-up fix for JDK-8201226 which enabled building JDK >>>> for 32 bit Windows, its code review: >>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>> >>>> >>>> I found this issue: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>>> >>>> >>>> This fix removes JNICALL modifiers from exported functions in >>>> medialib. >>>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>>> >>>> >>>> Thank you in advance. >>>> >>>> Regards, >>>> Alexey >> > From philip.race at oracle.com Fri May 4 17:53:43 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 4 May 2018 10:53:43 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> Message-ID: <509389b9-ca45-98b6-dbdd-798cb6c1ebcd@oracle.com> Yes, your confirmation on the testing was all that was needed. -phil. On 5/4/2018 10:45 AM, Alexey Ivanov wrote: > Hi Phil, > > Just to confirm: do you approve the change? > > Thank you, > Alexey > > On 02/05/2018 19:24, Alexey Ivanov wrote: >> Hi Phil, >> >> Thank you for your review. >> >> On 02/05/2018 17:28, Phil Race wrote: >>> So ... the original change that removed the mapfiles broke the 32 >>> bit build >>> because of inconsistency between declarations + definitions of some >>> functions. >>> It did not affect 64 bit build because JNICALL is a no-op there. >>> >>> The next change (8201226) added JNICALL to make it consistent, but >>> was not reviewed on 2d and was pushed without such review >>> and may have fixed build issues but did NOT fix the product. >> >> Yes, you're right. It made the product buildable but it did not fix >> the product. >> >>> >>> This change now removes JNICALL where it is not needed and fixes the >>> product and does not break >>> any builds! >>> >>> Please confirm that you've run 64+32 bit builds through the build >>> system AND run imaging tests >>> on both of those. >> >> Yes, I ran 64 builds through the build system and ran 32 bit Windows >> build on my laptop. >> >> I ran regression tests from test/jdk/java/awt/image with both 64 and >> 32 bit builds on Windows. No failures. >> >> >> Regards, >> Alexey >> >>> >>> After that is confirmed you have my OK. >>> >>> -phil. >>> >>> On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >>>> Looks good to me, but you should have a reviewer from the client >>>> team as well. >>>> >>>> /Magnus >>>> >>>>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>>>> >>>>> Hi, >>>>> >>>>> Could you please review the following fix for jdk11? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>>>> >>>>> This is a follow-up fix for JDK-8201226 which enabled building JDK >>>>> for 32 bit Windows, its code review: >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>> >>>>> >>>>> I found this issue: >>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>>>> >>>>> >>>>> This fix removes JNICALL modifiers from exported functions in >>>>> medialib. >>>>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>>>> >>>>> >>>>> Thank you in advance. >>>>> >>>>> Regards, >>>>> Alexey >>> >> > From alexey.ivanov at oracle.com Fri May 4 17:52:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 4 May 2018 18:52:12 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8202476: ImageLib is broken in 32 bit Windows In-Reply-To: <509389b9-ca45-98b6-dbdd-798cb6c1ebcd@oracle.com> References: <00D5D227-DBA4-42C0-B5D5-AE0C5E9B3C07@oracle.com> <7630ee3c-1e1b-3e44-ff75-99e761ad4b1e@oracle.com> <4856df6e-6a59-ae58-96d1-07fa9f47b87f@oracle.com> <4f6bd15f-0055-8043-2a08-b7682cd614f7@oracle.com> <509389b9-ca45-98b6-dbdd-798cb6c1ebcd@oracle.com> Message-ID: Thank you! -- Alexey On 04/05/2018 18:53, Phil Race wrote: > Yes, your confirmation on the testing was all that was needed. > > -phil. > > On 5/4/2018 10:45 AM, Alexey Ivanov wrote: >> Hi Phil, >> >> Just to confirm: do you approve the change? >> >> Thank you, >> Alexey >> >> On 02/05/2018 19:24, Alexey Ivanov wrote: >>> Hi Phil, >>> >>> Thank you for your review. >>> >>> On 02/05/2018 17:28, Phil Race wrote: >>>> So ... the original change that removed the mapfiles broke the 32 >>>> bit build >>>> because of inconsistency between declarations + definitions of some >>>> functions. >>>> It did not affect 64 bit build because JNICALL is a no-op there. >>>> >>>> The next change (8201226) added JNICALL to make it consistent, but >>>> was not reviewed on 2d and was pushed without such review >>>> and may have fixed build issues but did NOT fix the product. >>> >>> Yes, you're right. It made the product buildable but it did not fix >>> the product. >>> >>>> >>>> This change now removes JNICALL where it is not needed and fixes >>>> the product and does not break >>>> any builds! >>>> >>>> Please confirm that you've run 64+32 bit builds through the build >>>> system AND run imaging tests >>>> on both of those. >>> >>> Yes, I ran 64 builds through the build system and ran 32 bit Windows >>> build on my laptop. >>> >>> I ran regression tests from test/jdk/java/awt/image with both 64 and >>> 32 bit builds on Windows. No failures. >>> >>> >>> Regards, >>> Alexey >>> >>>> >>>> After that is confirmed you have my OK. >>>> >>>> -phil. >>>> >>>> On 05/02/2018 05:03 AM, Magnus Ihse Bursie wrote: >>>>> Looks good to me, but you should have a reviewer from the client >>>>> team as well. >>>>> >>>>> /Magnus >>>>> >>>>>> 2 maj 2018 kl. 11:52 skrev Alexey Ivanov : >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could you please review the following fix for jdk11? >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202476 >>>>>> webrev: http://cr.openjdk.java.net/~aivanov/8202476/jdk11/webrev.0/ >>>>>> >>>>>> This is a follow-up fix for JDK-8201226 which enabled building >>>>>> JDK for 32 bit Windows, its code review: >>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-April/021553.html >>>>>> >>>>>> >>>>>> I found this issue: >>>>>> http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009150.html >>>>>> >>>>>> >>>>>> This fix removes JNICALL modifiers from exported functions in >>>>>> medialib. >>>>>> After the fix, the failing tests in test/jdk/java/awt/image pass. >>>>>> >>>>>> >>>>>> Thank you in advance. >>>>>> >>>>>> Regards, >>>>>> Alexey >>>> >>> >> > From kim.barrett at oracle.com Fri May 4 20:00:00 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 4 May 2018 16:00:00 -0400 Subject: RFR: JDK-8202319: Fix compilation warnings in Solaris debug builds for DevStudio 12.6 In-Reply-To: <95043b95-1427-3576-4ad9-30aa18d016c7@oracle.com> References: <5AE1FFD0.1090803@oracle.com> <95043b95-1427-3576-4ad9-30aa18d016c7@oracle.com> Message-ID: Patch looks good. I will sponsor. From jonathan.gibbons at oracle.com Fri May 4 20:45:11 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 May 2018 13:45:11 -0700 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEC64C7.9020206@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> Message-ID: <5AECC657.3050304@oracle.com> I like the Makefile improvement. +1 -- Jon On 05/04/2018 06:48 AM, Jan Lahoda wrote: > [+build-dev] > > On 4.5.2018 03:27, Jonathan Gibbons wrote: >> OK. >> >> It would be even better, perhaps in a subsequent update, if >> make/gendata/Gendata-jdk.compiler.gmk >> did not have to be updated for each release ... i.e. by changing A to B, >> and soon to C etc. The version >> letter can surely be inferred by the system. > > True. Updated webrevs: > http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ > (code changes, including update to Makefiles to automatically infer > the current JDK version) > > http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ > (historical data for JDK 10, similar patches will be needed for each > new JDK version) > > How does this look? > > Thanks, > Jan > >> >> -- Jon >> >> >> >> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>> Hi, >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>> >>> This patch adds historical data for JDK 10 and adds support for >>> --release 11. >>> >>> To simplify adding new platforms, the CreateSymbols tool is updated to >>> support incrementally adding platform support. So now it is possible >>> to run command like: >>> /bin/java >>> build.tools.symbolgenerator.CreateSymbols >>> build-description-incremental symbols include.list >>> >>> to add historical data for JDK 10. In the future it might even be >>> possible to use the source launcher so that one would not need to >>> compile the tool before use. >>> >>> The webrevs are split into two: >>> -updating the CreateSymbols tool, and adding a test that verifies that >>> "--release " works (as suggested): >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>> -actually adding the data for JDK 10, and adding --release 11: >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>> >>> How does this look? >>> >>> Thanks, >>> Jan >> From jonathan.gibbons at oracle.com Fri May 4 21:59:53 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 May 2018 14:59:53 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5AECD7D9.4080400@oracle.com> Here's an update to the previously proposed patch for JEP 330: Launch Single-File Source-Code Programs. It includes all review feedback so far. The changes are mostly minor, but with the addition of more test cases. The webrev includes a delta-webrev for those that just want to see what has changed since last time. Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html Original webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html Delta webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html Note that the work is temporarily blocked by JDK-8202387: javac --release 11 not supported. A fix for that is underway and in review: http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html This work has been tested using a workaround for this issue, and will be tested again when the real fix is in place. -- Jon On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon From shade at redhat.com Sat May 5 11:26:21 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 5 May 2018 13:26:21 +0200 Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms Message-ID: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8202683 Fix: http://cr.openjdk.java.net/~shade/8202683/webrev.01/ Minimal VM is targeted to 32-bit only, but hear me out. Recent build system changes, notably conditional GC compilation, requires build/testing with some GCs disabled. Ultimately, we want minimal VM to be buildable at all times. Today, we need to cross-compile to x86_32 to verify that, but with this change, we can build minimal on x86_64, thus simplifying our day-to-day jobs. The change itself generates jvm.cfg for minimal VM properly on both bitnesses. Testing: x86_64 server/minimal builds, x86_32 server/minimal builds Thanks, -Aleksey From bsrbnd at gmail.com Sat May 5 12:03:42 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sat, 5 May 2018 14:03:42 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> Message-ID: On 4 May 2018 at 17:42, Alan Bateman wrote: > On 04/05/2018 16:31, B. Blaser wrote: >> >> : >> >> I'll create a new JBS issue (unless you want to) since the fix is >> mostly located in core-libs and only intended to make the build >> complete. >> But I'll still need someone to review and push the fix, would you be >> interested in doing this? >> > I think someone needs to explore the behavior on other platforms too as the > #ifndef __linux__ patches are ugly. Yes sure but I cannot test it elsewhere myself... and we can easily remove them once POSIX officially deprecates 'readdir_r' or if someone validates the fix on other systems. > Is there discussion on the original > thread about this? As Kim said, JDK-8202353 summarize the situation. > -Alan I've just made a small improvement (below) using 'errno' to preserve the exact behavior when necessary, what do yo think? Bernard diff -r 1871c5d07caf src/java.base/unix/native/libjava/TimeZone_md.c --- a/src/java.base/unix/native/libjava/TimeZone_md.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/java.base/unix/native/libjava/TimeZone_md.c Sat May 05 12:54:56 2018 +0200 @@ -122,7 +122,9 @@ DIR *dirp = NULL; struct stat statbuf; struct dirent64 *dp = NULL; +#ifndef __linux__ struct dirent64 *entry = NULL; +#endif char *pathname = NULL; int fd = -1; char *dbuf = NULL; @@ -140,7 +142,7 @@ if (name_max < 1024) { name_max = 1024; } - +#ifndef __linux__ entry = (struct dirent64 *)malloc(offsetof(struct dirent64, d_name) + name_max + 1); if (entry == NULL) { (void) closedir(dirp); @@ -148,6 +150,9 @@ } while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { +#else + while ((dp = readdir64(dirp)) != NULL) { +#endif /* * Skip '.' and '..' (and possibly other .* files) */ @@ -213,10 +218,11 @@ free((void *) pathname); pathname = NULL; } - +#ifndef __linux__ if (entry != NULL) { free((void *) entry); } +#endif if (dirp != NULL) { (void) closedir(dirp); } diff -r 1871c5d07caf src/java.base/unix/native/libjava/UnixFileSystem_md.c --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Sat May 05 12:54:56 2018 +0200 @@ -312,7 +312,9 @@ { DIR *dir = NULL; struct dirent64 *ptr; +#ifndef __linux__ struct dirent64 *result; +#endif int len, maxlen; jobjectArray rv, old; jclass str_class; @@ -324,14 +326,14 @@ dir = opendir(path); } END_PLATFORM_STRING(env, path); if (dir == NULL) return NULL; - +#ifndef __linux__ ptr = malloc(sizeof(struct dirent64) + (PATH_MAX + 1)); if (ptr == NULL) { JNU_ThrowOutOfMemoryError(env, "heap allocation failed"); closedir(dir); return NULL; } - +#endif /* Allocate an initial String array */ len = 0; maxlen = 16; @@ -339,7 +341,11 @@ if (rv == NULL) goto error; /* Scan the directory */ +#ifndef __linux__ while ((readdir64_r(dir, ptr, &result) == 0) && (result != NULL)) { +#else + while ((ptr = readdir64(dir)) != NULL) { +#endif jstring name; if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) continue; @@ -360,7 +366,9 @@ (*env)->DeleteLocalRef(env, name); } closedir(dir); +#ifndef __linux__ free(ptr); +#endif /* Copy the final results into an appropriately-sized array */ old = rv; @@ -375,7 +383,9 @@ error: closedir(dir); +#ifndef __linux__ free(ptr); +#endif return NULL; } diff -r 1871c5d07caf src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Sat May 05 12:54:56 2018 +0200 @@ -726,12 +726,19 @@ char name_extra[PATH_MAX + 1 - sizeof result->d_name]; } entry; struct dirent64* ptr = &entry.buf; +#ifndef __linux__ int res; +#endif DIR* dirp = jlong_to_ptr(value); /* EINTR not listed as a possible error */ /* TDB: reentrant version probably not required here */ +#ifndef __linux__ res = readdir64_r(dirp, ptr, &result); +#else + errno = 0; + ptr = result = readdir64(dirp); +#endif #ifdef _AIX /* On AIX, readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL for the */ @@ -741,8 +748,13 @@ } #endif +#ifndef __linux__ if (res != 0) { throwUnixException(env, res); +#else + if (errno != 0) { + throwUnixException(env, errno); +#endif return NULL; } else { if (result == NULL) { diff -r 1871c5d07caf src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Fri Apr 27 15:55:29 2018 -0700 +++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Sat May 05 12:54:56 2018 +0200 @@ -75,10 +75,10 @@ #endif /* _ALLBSD_SOURCE */ static struct dirent* read_dir(DIR* dirp, struct dirent* entry) { -#ifdef __solaris__ +#if defined(__solaris__) || defined(__linux__) struct dirent* dbuf = readdir(dirp); return dbuf; -#else /* __linux__ || _ALLBSD_SOURCE */ +#else /* _ALLBSD_SOURCE */ struct dirent* p; if (readdir_r(dirp, entry, &p) == 0) { return p; From kim.barrett at oracle.com Sat May 5 20:26:36 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 5 May 2018 16:26:36 -0400 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> Message-ID: <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com> > On May 5, 2018, at 8:03 AM, B. Blaser wrote: > > On 4 May 2018 at 17:42, Alan Bateman wrote: >> On 04/05/2018 16:31, B. Blaser wrote: >>> >>> : >>> >>> I'll create a new JBS issue (unless you want to) since the fix is >>> mostly located in core-libs and only intended to make the build >>> complete. >>> But I'll still need someone to review and push the fix, would you be >>> interested in doing this? >>> >> I think someone needs to explore the behavior on other platforms too as the >> #ifndef __linux__ patches are ugly. > > Yes sure but I cannot test it elsewhere myself... and we can easily > remove them once POSIX officially deprecates 'readdir_r' or if someone > validates the fix on other systems. I'm not sure anyone has the ability to test on all supported. That doesn't (and really can't) prevent making changes across platforms to platform-specific code. It just means one needs to get help with testing. Make the change across platforms, test on those platforms one has access to, and ask here for help testing on others. Waiting for a POSIX change is even more like watching paint dry than waiting for Java releases used to be. From david.holmes at oracle.com Sun May 6 07:20:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 May 2018 00:20:18 -0700 (PDT) Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms In-Reply-To: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> References: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> Message-ID: On 5/05/2018 9:26 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8202683 > > Fix: > http://cr.openjdk.java.net/~shade/8202683/webrev.01/ > > Minimal VM is targeted to 32-bit only, but hear me out. Recent build system changes, notably > conditional GC compilation, requires build/testing with some GCs disabled. Ultimately, we want > minimal VM to be buildable at all times. Today, we need to cross-compile to x86_32 to verify that, > but with this change, we can build minimal on x86_64, thus simplifying our day-to-day jobs. The > change itself generates jvm.cfg for minimal VM properly on both bitnesses. Is 64-bit client VM now able to be built routinely? I'm not sure we should be expanding the ability to build the Minimal VM. David > Testing: x86_64 server/minimal builds, x86_32 server/minimal builds > > Thanks, > -Aleksey > From bsrbnd at gmail.com Sun May 6 16:35:32 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Sun, 6 May 2018 18:35:32 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com> References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com> Message-ID: On 5 May 2018 at 22:26, Kim Barrett wrote: >> On May 5, 2018, at 8:03 AM, B. Blaser wrote: >> >> On 4 May 2018 at 17:42, Alan Bateman wrote: >>> On 04/05/2018 16:31, B. Blaser wrote: >>>> >>>> : >>>> >>>> I'll create a new JBS issue (unless you want to) since the fix is >>>> mostly located in core-libs and only intended to make the build >>>> complete. >>>> But I'll still need someone to review and push the fix, would you be >>>> interested in doing this? >>>> >>> I think someone needs to explore the behavior on other platforms too as the >>> #ifndef __linux__ patches are ugly. >> >> Yes sure but I cannot test it elsewhere myself... and we can easily >> remove them once POSIX officially deprecates 'readdir_r' or if someone >> validates the fix on other systems. > > I'm not sure anyone has the ability to test on all supported. That > doesn't (and really can't) prevent making changes across platforms to > platform-specific code. It just means one needs to get help with > testing. Make the change across platforms, test on those platforms > one has access to, and ask here for help testing on others. OK, I'll provide a cross-platform fix to be evaluated on other systems too. Thanks, Bernard > Waiting for a POSIX change is even more like watching paint dry than > waiting for Java releases used to be. From jan.lahoda at oracle.com Sun May 6 18:39:24 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Sun, 6 May 2018 20:39:24 +0200 Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> Message-ID: <5AEF4BDC.8060609@oracle.com> Hi R?mi, Thanks for the comments; updated webrev: http://cr.openjdk.java.net/~jlahoda/8202387/code.02/ Jan On 4.5.2018 18:09, Remi Forax wrote: > Hi Jan, > there is several occurences of Arrays.asList() that can be replaced by List.of() to make them really immutable. > > in CreateSymbols.java > in dumpCurrentClasses, > while ((read = in.read()) != (-1)) { > baos.write(read); > } > should be replaced by > in.transferTo(baos); > > in TransitiveDependencies.java, > - todo should be an ArrayDeque instead of a LinkedList, array based data structure are usually faster > - newBufferedWriter can takes only one argument > > in PreviewOptionTest.java, > - versionsToTest.stream().forEach can be replaced by versionsToTest.forEach > > regards, > R?mi > > ----- Mail original ----- >> De: "jan lahoda" >> ?: "jonathan gibbons" , "compiler-dev" , >> build-dev at openjdk.java.net >> Envoy?: Vendredi 4 Mai 2018 15:48:55 >> Objet: Re: RFR : JDK-8202387: javac --release 11 not supported > >> [+build-dev] >> >> On 4.5.2018 03:27, Jonathan Gibbons wrote: >>> OK. >>> >>> It would be even better, perhaps in a subsequent update, if >>> make/gendata/Gendata-jdk.compiler.gmk >>> did not have to be updated for each release ... i.e. by changing A to B, >>> and soon to C etc. The version >>> letter can surely be inferred by the system. >> >> True. Updated webrevs: >> http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ >> (code changes, including update to Makefiles to automatically infer the >> current JDK version) >> >> http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ >> (historical data for JDK 10, similar patches will be needed for each new >> JDK version) >> >> How does this look? >> >> Thanks, >> Jan >> >>> >>> -- Jon >>> >>> >>> >>> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>>> Hi, >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>>> >>>> This patch adds historical data for JDK 10 and adds support for >>>> --release 11. >>>> >>>> To simplify adding new platforms, the CreateSymbols tool is updated to >>>> support incrementally adding platform support. So now it is possible >>>> to run command like: >>>> /bin/java >>>> build.tools.symbolgenerator.CreateSymbols >>>> build-description-incremental symbols include.list >>>> >>>> to add historical data for JDK 10. In the future it might even be >>>> possible to use the source launcher so that one would not need to >>>> compile the tool before use. >>>> >>>> The webrevs are split into two: >>>> -updating the CreateSymbols tool, and adding a test that verifies that >>>> "--release " works (as suggested): >>>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>>> -actually adding the data for JDK 10, and adding --release 11: >>>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>>> >>>> How does this look? >>>> >>>> Thanks, >>>> Jan From forax at univ-mlv.fr Sun May 6 18:53:27 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 6 May 2018 20:53:27 +0200 (CEST) Subject: RFR : JDK-8202387: javac --release 11 not supported In-Reply-To: <5AEF4BDC.8060609@oracle.com> References: <5AEB4FEF.9080306@oracle.com> <5AEBB6FE.5090400@oracle.com> <5AEC64C7.9020206@oracle.com> <551463107.1794248.1525450175516.JavaMail.zimbra@u-pem.fr> <5AEF4BDC.8060609@oracle.com> Message-ID: <1679984286.2142883.1525632807277.JavaMail.zimbra@u-pem.fr> Looks good. R?mi ----- Mail original ----- > De: "jan lahoda" > ?: "Remi Forax" > Cc: "jonathan gibbons" , "compiler-dev" , "build-dev" > > Envoy?: Dimanche 6 Mai 2018 20:39:24 > Objet: Re: RFR : JDK-8202387: javac --release 11 not supported > Hi R?mi, > > Thanks for the comments; updated webrev: > http://cr.openjdk.java.net/~jlahoda/8202387/code.02/ > > Jan > > On 4.5.2018 18:09, Remi Forax wrote: >> Hi Jan, >> there is several occurences of Arrays.asList() that can be replaced by List.of() >> to make them really immutable. >> >> in CreateSymbols.java >> in dumpCurrentClasses, >> while ((read = in.read()) != (-1)) { >> baos.write(read); >> } >> should be replaced by >> in.transferTo(baos); >> >> in TransitiveDependencies.java, >> - todo should be an ArrayDeque instead of a LinkedList, array based data >> structure are usually faster >> - newBufferedWriter can takes only one argument >> >> in PreviewOptionTest.java, >> - versionsToTest.stream().forEach can be replaced by versionsToTest.forEach >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "jan lahoda" >>> ?: "jonathan gibbons" , "compiler-dev" >>> , >>> build-dev at openjdk.java.net >>> Envoy?: Vendredi 4 Mai 2018 15:48:55 >>> Objet: Re: RFR : JDK-8202387: javac --release 11 not supported >> >>> [+build-dev] >>> >>> On 4.5.2018 03:27, Jonathan Gibbons wrote: >>>> OK. >>>> >>>> It would be even better, perhaps in a subsequent update, if >>>> make/gendata/Gendata-jdk.compiler.gmk >>>> did not have to be updated for each release ... i.e. by changing A to B, >>>> and soon to C etc. The version >>>> letter can surely be inferred by the system. >>> >>> True. Updated webrevs: >>> http://cr.openjdk.java.net/~jlahoda/8202387/code.01/ >>> (code changes, including update to Makefiles to automatically infer the >>> current JDK version) >>> >>> http://cr.openjdk.java.net/~jlahoda/8202387/data.01/ >>> (historical data for JDK 10, similar patches will be needed for each new >>> JDK version) >>> >>> How does this look? >>> >>> Thanks, >>> Jan >>> >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 05/03/2018 11:07 AM, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8202387 >>>>> >>>>> This patch adds historical data for JDK 10 and adds support for >>>>> --release 11. >>>>> >>>>> To simplify adding new platforms, the CreateSymbols tool is updated to >>>>> support incrementally adding platform support. So now it is possible >>>>> to run command like: >>>>> /bin/java >>>>> build.tools.symbolgenerator.CreateSymbols >>>>> build-description-incremental symbols include.list >>>>> >>>>> to add historical data for JDK 10. In the future it might even be >>>>> possible to use the source launcher so that one would not need to >>>>> compile the tool before use. >>>>> >>>>> The webrevs are split into two: >>>>> -updating the CreateSymbols tool, and adding a test that verifies that >>>>> "--release " works (as suggested): >>>>> http://cr.openjdk.java.net/~jlahoda/8202387/code.00/ >>>>> -actually adding the data for JDK 10, and adding --release 11: >>>>> http://cr.openjdk.java.net/~jlahoda/8202387/data.00/ >>>>> >>>>> How does this look? >>>>> >>>>> Thanks, > >>>> Jan From shade at redhat.com Mon May 7 08:20:04 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 May 2018 10:20:04 +0200 Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms In-Reply-To: References: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> Message-ID: <6b11455b-2b05-be75-0f1a-67156e201b70@redhat.com> On 05/06/2018 09:20 AM, David Holmes wrote: > On 5/05/2018 9:26 PM, Aleksey Shipilev wrote: >> RFE: >> ?? https://bugs.openjdk.java.net/browse/JDK-8202683 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8202683/webrev.01/ >> >> Minimal VM is targeted to 32-bit only, but hear me out. Recent build system changes, notably >> conditional GC compilation, requires build/testing with some GCs disabled. Ultimately, we want >> minimal VM to be buildable at all times. Today, we need to cross-compile to x86_32 to verify that, >> but with this change, we can build minimal on x86_64, thus simplifying our day-to-day jobs. The >> change itself generates jvm.cfg for minimal VM properly on both bitnesses. > > Is 64-bit client VM now able to be built routinely? As far as I understand, the culprit before was x86_64 C1, which was fixed to allow Tiered compilation. Anyhow, with the build fix above, Minimal VM seems to build, bootcycle, and run fine on x86_64. > I'm not sure we should be expanding the ability to build the Minimal VM. I am thinking about the patch as removing the 32-bit special case from the jvm.cfg generation. If we want to forbid some JVM variants from building on some arches, we should be doing that explicitly somewhere else. -Aleksey From david.holmes at oracle.com Mon May 7 09:04:13 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 May 2018 19:04:13 +1000 Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms In-Reply-To: <6b11455b-2b05-be75-0f1a-67156e201b70@redhat.com> References: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> <6b11455b-2b05-be75-0f1a-67156e201b70@redhat.com> Message-ID: <43cf7be8-bca3-df73-e5eb-e7fad9c903e6@oracle.com> On 7/05/2018 6:20 PM, Aleksey Shipilev wrote: > On 05/06/2018 09:20 AM, David Holmes wrote: >> On 5/05/2018 9:26 PM, Aleksey Shipilev wrote: >>> RFE: >>> ?? https://bugs.openjdk.java.net/browse/JDK-8202683 >>> >>> Fix: >>> ?? http://cr.openjdk.java.net/~shade/8202683/webrev.01/ >>> >>> Minimal VM is targeted to 32-bit only, but hear me out. Recent build system changes, notably >>> conditional GC compilation, requires build/testing with some GCs disabled. Ultimately, we want >>> minimal VM to be buildable at all times. Today, we need to cross-compile to x86_32 to verify that, >>> but with this change, we can build minimal on x86_64, thus simplifying our day-to-day jobs. The >>> change itself generates jvm.cfg for minimal VM properly on both bitnesses. >> >> Is 64-bit client VM now able to be built routinely? > > As far as I understand, the culprit before was x86_64 C1, which was fixed to allow Tiered > compilation. Anyhow, with the build fix above, Minimal VM seems to build, bootcycle, and run fine on > x86_64. Okay. I don't know how well stand-alone 64-bit C1 is supported. > >> I'm not sure we should be expanding the ability to build the Minimal VM. > > I am thinking about the patch as removing the 32-bit special case from the jvm.cfg generation. If we > want to forbid some JVM variants from building on some arches, we should be doing that explicitly > somewhere else. Perhaps. But until that happens this may give an illusion of being able to do more than you really can. Anyway my unease has been noted. I don't object enough to make an issue of it. Cheers, David > -Aleksey > From mark.reinhold at oracle.com Mon May 7 09:31:58 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 May 2018 10:31:58 +0100 Subject: License and Usage Terms of generated API documentation In-Reply-To: References: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> Message-ID: <20180507103158.909726963@eggemoggin.niobe.net> 2018/5/3 13:16:11 +0100, volker.simonis at gmail.com: > On Thu, May 3, 2018 at 12:21 PM, magnus.ihse.bursie at oracle.com wrote: >> ... >> >> Until a consensus of a better solution for hosting the generated >> documentation is reached, I'd like to avoid changing the build code. That >> will just open for an uneccessary split in what constitutes the proper >> documentation URL. > > The JAVADOC_BASE_URL is the minor issue here and I agree that it would > be not easy to create a community driven documentation of the same or > at least similar quality as we have today from Oracle. We should publish the API Javadoc somewhere on OpenJDK at some point, but that?s not something that we can do today -- if nothing else, we?d have to set up a CDN to front these very popular pages. > Nevertheless I > don't see why we shouldn't be able to make this URL configurable at > configure time. Agreed. > The main issue are the two links to "LICENSE_URL" and > "REDISTRIBUTION_URL" which clearly refer to the API-docs published by > Oracle. I just want to be able to publish these API-docs myself > without having to refer to these restrictive licenses. The change > itself, to make these URLs configurable at configure time, would be > trivial (and again, I'm not against leaving the default "as-is" if > this is important for you). Making these things configurable is a fine idea, but I agree with Magnus that it?d be simpler for now to retain the current values as defaults. - Mark From bsrbnd at gmail.com Mon May 7 12:19:14 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 7 May 2018 14:19:14 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com> Message-ID: On 6 May 2018 at 18:35, B. Blaser wrote: > On 5 May 2018 at 22:26, Kim Barrett wrote: >>> On May 5, 2018, at 8:03 AM, B. Blaser wrote: >>> >>> On 4 May 2018 at 17:42, Alan Bateman wrote: >>>> On 04/05/2018 16:31, B. Blaser wrote: >>>>> >>>>> : >>>>> >>>>> I'll create a new JBS issue (unless you want to) since the fix is >>>>> mostly located in core-libs and only intended to make the build >>>>> complete. >>>>> But I'll still need someone to review and push the fix, would you be >>>>> interested in doing this? >>>>> >>>> I think someone needs to explore the behavior on other platforms too as the >>>> #ifndef __linux__ patches are ugly. >>> >>> Yes sure but I cannot test it elsewhere myself... and we can easily >>> remove them once POSIX officially deprecates 'readdir_r' or if someone >>> validates the fix on other systems. >> >> I'm not sure anyone has the ability to test on all supported. That >> doesn't (and really can't) prevent making changes across platforms to >> platform-specific code. It just means one needs to get help with >> testing. Make the change across platforms, test on those platforms >> one has access to, and ask here for help testing on others. > > OK, I'll provide a cross-platform fix to be evaluated on other systems too. Here it is, tier1 is successful on Linux with glibc=2.26. Any feedback on other systems would be very helpful. Does this look better? Thanks, Bernard diff -r e81481fea884 src/java.base/unix/native/libjava/TimeZone_md.c --- a/src/java.base/unix/native/libjava/TimeZone_md.c Mon May 07 08:56:35 2018 +0200 +++ b/src/java.base/unix/native/libjava/TimeZone_md.c Mon May 07 12:38:42 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -122,32 +122,18 @@ DIR *dirp = NULL; struct stat statbuf; struct dirent64 *dp = NULL; - struct dirent64 *entry = NULL; char *pathname = NULL; int fd = -1; char *dbuf = NULL; char *tz = NULL; int res; - long name_max = 0; dirp = opendir(dir); if (dirp == NULL) { return NULL; } - name_max = pathconf(dir, _PC_NAME_MAX); - // If pathconf did not work, fall back to a mimimum buffer size. - if (name_max < 1024) { - name_max = 1024; - } - - entry = (struct dirent64 *)malloc(offsetof(struct dirent64, d_name) + name_max + 1); - if (entry == NULL) { - (void) closedir(dirp); - return NULL; - } - - while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { + while ((dp = readdir64(dirp)) != NULL) { /* * Skip '.' and '..' (and possibly other .* files) */ @@ -214,9 +200,6 @@ pathname = NULL; } - if (entry != NULL) { - free((void *) entry); - } if (dirp != NULL) { (void) closedir(dirp); } diff -r e81481fea884 src/java.base/unix/native/libjava/UnixFileSystem_md.c --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon May 07 08:56:35 2018 +0200 +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon May 07 12:38:42 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -312,7 +312,6 @@ { DIR *dir = NULL; struct dirent64 *ptr; - struct dirent64 *result; int len, maxlen; jobjectArray rv, old; jclass str_class; @@ -325,13 +324,6 @@ } END_PLATFORM_STRING(env, path); if (dir == NULL) return NULL; - ptr = malloc(sizeof(struct dirent64) + (PATH_MAX + 1)); - if (ptr == NULL) { - JNU_ThrowOutOfMemoryError(env, "heap allocation failed"); - closedir(dir); - return NULL; - } - /* Allocate an initial String array */ len = 0; maxlen = 16; @@ -339,7 +331,7 @@ if (rv == NULL) goto error; /* Scan the directory */ - while ((readdir64_r(dir, ptr, &result) == 0) && (result != NULL)) { + while ((ptr = readdir64(dir)) != NULL) { jstring name; if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) continue; @@ -360,7 +352,6 @@ (*env)->DeleteLocalRef(env, name); } closedir(dir); - free(ptr); /* Copy the final results into an appropriately-sized array */ old = rv; @@ -375,7 +366,6 @@ error: closedir(dir); - free(ptr); return NULL; } diff -r e81481fea884 src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Mon May 07 08:56:35 2018 +0200 +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Mon May 07 12:38:42 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -720,24 +720,20 @@ JNIEXPORT jbyteArray JNICALL Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv* env, jclass this, jlong value) { - struct dirent64* result; - struct { - struct dirent64 buf; - char name_extra[PATH_MAX + 1 - sizeof result->d_name]; - } entry; - struct dirent64* ptr = &entry.buf; + struct dirent64* ptr = NULL; int res; DIR* dirp = jlong_to_ptr(value); /* EINTR not listed as a possible error */ - /* TDB: reentrant version probably not required here */ - res = readdir64_r(dirp, ptr, &result); + errno = 0; + ptr = readdir64(dirp); + res = errno; #ifdef _AIX - /* On AIX, readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL for the */ + /* On AIX, readdir() returns EBADF (i.e. '9') and sets 'result' to NULL for the */ /* directory stream end. Otherwise, 'errno' will contain the error code. */ if (res != 0) { - res = (result == NULL && res == EBADF) ? 0 : errno; + res = (ptr == NULL && res == EBADF) ? 0 : errno; } #endif @@ -745,7 +741,7 @@ throwUnixException(env, res); return NULL; } else { - if (result == NULL) { + if (ptr == NULL) { return NULL; } else { jsize len = strlen(ptr->d_name); diff -r e81481fea884 src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Mon May 07 08:56:35 2018 +0200 +++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Mon May 07 12:38:42 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -75,17 +75,8 @@ #endif /* _ALLBSD_SOURCE */ static struct dirent* read_dir(DIR* dirp, struct dirent* entry) { -#ifdef __solaris__ struct dirent* dbuf = readdir(dirp); return dbuf; -#else /* __linux__ || _ALLBSD_SOURCE */ - struct dirent* p; - if (readdir_r(dirp, entry, &p) == 0) { - return p; - } else { - return NULL; - } -#endif } // true = get available swap in bytes From thomas.stuefe at gmail.com Mon May 7 14:37:09 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 7 May 2018 16:37:09 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> <3055b9bb-1f01-8b9f-33fc-621043aab511@oracle.com> Message-ID: Hi Erik, since your proposal worked, will you do a fix? Thanks, Thomas On Fri, May 4, 2018 at 8:30 AM, Thomas St?fe wrote: > Hi Erik, > > that worked on both machines for all builds. > > Thanks, Thomas > > On Thu, May 3, 2018 at 10:13 PM, Erik Joelsson wrote: >> Hello, >> >> In my case, VCINSTALLDIR is in short form already. Could you try changing >> line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to BASIC_FIXUP_PATH? >> >> /Erik >> >> >> >> On 2018-05-03 11:17, Thomas St?fe wrote: >>> >>> Hi Erik, >>> >>> I see the error on two very different machines. One is my private >>> machine - windows 7, VS2013 and VS2017 installed. The second one is my >>> corporate Laptop, Windows 10 and only VS2013. >>> >>> In both cases I use a very recent cygwin64 installation. >>> >>> Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using >>> well-known location from Visual Studio 12.0 and older" case, and in >>> the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL >>> variable content. Here the 64bit build on my corporate laptop: >>> >>> checking if fixpath.exe works... yes >>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>> POSSIBLE_MSVC_DLL Files >>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>> POSSIBLE_MSVC_DLL Visual >>> POSSIBLE_MSVC_DLL Studio >>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>> configure: Found msvcr120.dll at >>> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >>> SYSTEMROOT >>> checking found msvcr120.dll architecture... ok >>> checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll >>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>> POSSIBLE_MSVC_DLL Files >>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>> POSSIBLE_MSVC_DLL Visual >>> POSSIBLE_MSVC_DLL Studio >>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll >>> configure: Found msvcp120.dll at >>> /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in >>> SYSTEMROOT >>> >>> As you can see, we fall back to the default in windows/system32, which >>> happens to be working for 64bit. On 32bit, we get this error: >>> >>> checking if fixpath.exe works... yes >>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>> POSSIBLE_MSVC_DLL Files >>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>> POSSIBLE_MSVC_DLL Visual >>> POSSIBLE_MSVC_DLL Studio >>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>> configure: Found msvcr120.dll at >>> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >>> SYSTEMROOT >>> checking found msvcr120.dll architecture... incorrect, ignoring >>> configure: The file type of the located msvcr120.dll is PE32+ >>> executable (DLL) (GUI) x86-64, for MS Windows >>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>> (x86)/Microsoft Visual Studio >>> 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of >>> VCINSTALLDIR >>> checking found msvcr120.dll architecture... incorrect, ignoring >>> configure: The file type of the located msvcr120.dll is PE32 >>> executable (DLL) (GUI) ARMv7 Thumb, for MS Windows >>> checking for msvcr120.dll... no >>> configure: error: Could not find msvcr120.dll. Please specify using >>> --with-msvcr-dll. >>> configure exiting with result code 1 >>> >>> Best Regards, Thomas >>> >>> On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson >>> wrote: >>>> >>>> Also, on my windows system, if I try using my local Visual Studio, both >>>> MSVC >>>> dll's are found in the Visual Studio dir, and the spaces are all cleaned >>>> up. >>>> I wonder what's different about your setup, Thomas. >>>> >>>> /Erik >>>> >>>> >>>> >>>> On 2018-05-03 10:13, Erik Joelsson wrote: >>>>> >>>>> Hello, >>>>> >>>>> On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >>>>>> >>>>>> I think the main issue here is that BASIC_FIXUP_PATH should be called >>>>>> for >>>>>> the located msvcr*.dll files. I don't have time to look at it now, but >>>>>> see >>>>>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential file >>>>>> is >>>>>> located. This should remove all spaces from the path. >>>>>> >>>>> No, that is not a good solution. I intentionally removed that >>>>> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name >>>>> longer >>>>> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short >>>>> style. This in turn has weird consequences in make when we copy that >>>>> file >>>>> using generated copy rules. The target file then gets the short style >>>>> name >>>>> literally. >>>>> >>>>> When I made that change, I looked at all the calls for potential >>>>> locations >>>>> and thought all of them had the directory prepared properly already. It >>>>> seems I was wrong. I think the correct solution is to either get rid of >>>>> spaces earlier for all the input directories we search, or maybe tweak >>>>> BASIC_FIXUP_PATH to not touch the actual filename. >>>>> >>>>> /Erik >>>>>> >>>>>> /Magnus >>>>>> >>>>>> On 2018-05-02 20:46, Thomas St?fe wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> My 32bit builds on Windows were failing since quite a while and I >>>>>>> finally had some minutes to look into that. >>>>>>> >>>>>>> See prior discussion here: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>>>>>> >>>>>>> My output used to look like this: >>>>>>> >>>>>>> checking if fixpath.exe works... yes >>>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>>>> POSSIBLE_MSVC_DLL Files >>>>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>>>> POSSIBLE_MSVC_DLL Visual >>>>>>> POSSIBLE_MSVC_DLL Studio >>>>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>>>>> configure: Found msvcr120.dll at >>>>>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >>>>>>> SYSTEMROOT >>>>>>> >>>>>>> So basically, build does not correctly search for msvcr120.dll in >>>>>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>>>>>> fails and falls back to the system default >>>>>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >>>>>>> and so configure fails. >>>>>>> >>>>>>> Note that 64bit build shows exactly the same behaviour! Only there it >>>>>>> works by accident, since the default >>>>>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>>>>>> 64bit library too, so configure succeeds. >>>>>>> >>>>>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>>>>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >>>>>>> one or more files, but that for expression should be quoted. >>>>>>> >>>>>>> If I make this fix: >>>>>>> >>>>>>> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 >>>>>>> 2018 >>>>>>> -0700 >>>>>>> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 >>>>>>> 2018 >>>>>>> +0200 >>>>>>> @@ -556,7 +556,7 @@ >>>>>>> fi >>>>>>> fi >>>>>>> # In case any of the above finds more than one file, loop >>>>>>> over >>>>>>> them. >>>>>>> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>>>>>> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>>>>>> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>>>>>> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>>>>>> [$possible_msvc_dll], >>>>>>> [well-known location in VCINSTALLDIR]) >>>>>>> >>>>>>> >>>>>>> the 32bit configure correctly sets the msvcrt dll: >>>>>>> >>>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>>>>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>>>>> (x86)/Microsoft Visual Studio >>>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >>>>>>> location in VCINSTALLDIR >>>>>>> checking found msvcr120.dll architecture... ok >>>>>>> >>>>>>> and I can start the build, but I get follow up errors: >>>>>>> >>>>>>> ... >>>>>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>>>>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>>>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >>>>>>> >>>>>>> >>>>>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>>>>>> Stop. >>>>>>> make[3]: *** Waiting for unfinished jobs.... >>>>>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>>>>>> make[2]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> I stopped looking at that point, but to me it looks like the build >>>>>>> cannot survive msvcrt.dll locations with spaces in them. >>>>>>> >>>>>>> Kind Regards, Thomas >>>>>> >>>>>> >> From bsrbnd at gmail.com Mon May 7 15:20:11 2018 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 7 May 2018 17:20:11 +0200 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com> Message-ID: On 7 May 2018 at 14:19, B. Blaser wrote: > On 6 May 2018 at 18:35, B. Blaser wrote: >> On 5 May 2018 at 22:26, Kim Barrett wrote: >>>> On May 5, 2018, at 8:03 AM, B. Blaser wrote: >>>> >>>> On 4 May 2018 at 17:42, Alan Bateman wrote: >>>>> On 04/05/2018 16:31, B. Blaser wrote: >>>>>> >>>>>> : >>>>>> >>>>>> I'll create a new JBS issue (unless you want to) since the fix is >>>>>> mostly located in core-libs and only intended to make the build >>>>>> complete. >>>>>> But I'll still need someone to review and push the fix, would you be >>>>>> interested in doing this? >>>>>> >>>>> I think someone needs to explore the behavior on other platforms too as the >>>>> #ifndef __linux__ patches are ugly. >>>> >>>> Yes sure but I cannot test it elsewhere myself... and we can easily >>>> remove them once POSIX officially deprecates 'readdir_r' or if someone >>>> validates the fix on other systems. >>> >>> I'm not sure anyone has the ability to test on all supported. That >>> doesn't (and really can't) prevent making changes across platforms to >>> platform-specific code. It just means one needs to get help with >>> testing. Make the change across platforms, test on those platforms >>> one has access to, and ask here for help testing on others. >> >> OK, I'll provide a cross-platform fix to be evaluated on other systems too. > > Here it is, tier1 is successful on Linux with glibc=2.26. > Any feedback on other systems would be very helpful. Some more cleanup... Does this look better? Thanks, Bernard diff -r e81481fea884 src/java.base/unix/native/libjava/TimeZone_md.c --- a/src/java.base/unix/native/libjava/TimeZone_md.c Mon May 07 08:56:35 2018 +0200 +++ b/src/java.base/unix/native/libjava/TimeZone_md.c Mon May 07 15:14:26 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -122,32 +122,18 @@ DIR *dirp = NULL; struct stat statbuf; struct dirent64 *dp = NULL; - struct dirent64 *entry = NULL; char *pathname = NULL; int fd = -1; char *dbuf = NULL; char *tz = NULL; int res; - long name_max = 0; dirp = opendir(dir); if (dirp == NULL) { return NULL; } - name_max = pathconf(dir, _PC_NAME_MAX); - // If pathconf did not work, fall back to a mimimum buffer size. - if (name_max < 1024) { - name_max = 1024; - } - - entry = (struct dirent64 *)malloc(offsetof(struct dirent64, d_name) + name_max + 1); - if (entry == NULL) { - (void) closedir(dirp); - return NULL; - } - - while (readdir64_r(dirp, entry, &dp) == 0 && dp != NULL) { + while ((dp = readdir64(dirp)) != NULL) { /* * Skip '.' and '..' (and possibly other .* files) */ @@ -214,9 +200,6 @@ pathname = NULL; } - if (entry != NULL) { - free((void *) entry); - } if (dirp != NULL) { (void) closedir(dirp); } diff -r e81481fea884 src/java.base/unix/native/libjava/UnixFileSystem_md.c --- a/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon May 07 08:56:35 2018 +0200 +++ b/src/java.base/unix/native/libjava/UnixFileSystem_md.c Mon May 07 15:14:26 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -312,7 +312,6 @@ { DIR *dir = NULL; struct dirent64 *ptr; - struct dirent64 *result; int len, maxlen; jobjectArray rv, old; jclass str_class; @@ -325,13 +324,6 @@ } END_PLATFORM_STRING(env, path); if (dir == NULL) return NULL; - ptr = malloc(sizeof(struct dirent64) + (PATH_MAX + 1)); - if (ptr == NULL) { - JNU_ThrowOutOfMemoryError(env, "heap allocation failed"); - closedir(dir); - return NULL; - } - /* Allocate an initial String array */ len = 0; maxlen = 16; @@ -339,7 +331,7 @@ if (rv == NULL) goto error; /* Scan the directory */ - while ((readdir64_r(dir, ptr, &result) == 0) && (result != NULL)) { + while ((ptr = readdir64(dir)) != NULL) { jstring name; if (!strcmp(ptr->d_name, ".") || !strcmp(ptr->d_name, "..")) continue; @@ -360,7 +352,6 @@ (*env)->DeleteLocalRef(env, name); } closedir(dir); - free(ptr); /* Copy the final results into an appropriately-sized array */ old = rv; @@ -375,7 +366,6 @@ error: closedir(dir); - free(ptr); return NULL; } diff -r e81481fea884 src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c --- a/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Mon May 07 08:56:35 2018 +0200 +++ b/src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c Mon May 07 15:14:26 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -720,24 +720,20 @@ JNIEXPORT jbyteArray JNICALL Java_sun_nio_fs_UnixNativeDispatcher_readdir(JNIEnv* env, jclass this, jlong value) { - struct dirent64* result; - struct { - struct dirent64 buf; - char name_extra[PATH_MAX + 1 - sizeof result->d_name]; - } entry; - struct dirent64* ptr = &entry.buf; + struct dirent64* ptr = NULL; int res; DIR* dirp = jlong_to_ptr(value); /* EINTR not listed as a possible error */ - /* TDB: reentrant version probably not required here */ - res = readdir64_r(dirp, ptr, &result); + errno = 0; + ptr = readdir64(dirp); + res = errno; #ifdef _AIX - /* On AIX, readdir_r() returns EBADF (i.e. '9') and sets 'result' to NULL for the */ + /* On AIX, readdir() returns EBADF (i.e. '9') and sets 'result' to NULL for the */ /* directory stream end. Otherwise, 'errno' will contain the error code. */ if (res != 0) { - res = (result == NULL && res == EBADF) ? 0 : errno; + res = (ptr == NULL && res == EBADF) ? 0 : errno; } #endif @@ -745,7 +741,7 @@ throwUnixException(env, res); return NULL; } else { - if (result == NULL) { + if (ptr == NULL) { return NULL; } else { jsize len = strlen(ptr->d_name); diff -r e81481fea884 src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c --- a/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Mon May 07 08:56:35 2018 +0200 +++ b/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c Mon May 07 15:14:26 2018 +0200 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -74,20 +74,6 @@ #endif /* _ALLBSD_SOURCE */ -static struct dirent* read_dir(DIR* dirp, struct dirent* entry) { -#ifdef __solaris__ - struct dirent* dbuf = readdir(dirp); - return dbuf; -#else /* __linux__ || _ALLBSD_SOURCE */ - struct dirent* p; - if (readdir_r(dirp, entry, &p) == 0) { - return p; - } else { - return NULL; - } -#endif -} - // true = get available swap in bytes // false = get total swap in bytes static jlong get_total_or_available_swap_space_size(JNIEnv* env, jboolean available) { @@ -432,7 +418,6 @@ return (100); #else /* solaris/linux */ DIR *dirp; - struct dirent dbuf; struct dirent* dentp; jlong fds = 0; @@ -453,7 +438,7 @@ // iterate through directory entries, skipping '.' and '..' // each entry represents an open file descriptor. - while ((dentp = read_dir(dirp, &dbuf)) != NULL) { + while ((dentp = readdir(dirp)) != NULL) { if (isdigit(dentp->d_name[0])) { fds++; } From erik.joelsson at oracle.com Mon May 7 15:40:08 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 May 2018 08:40:08 -0700 Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms In-Reply-To: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> References: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> Message-ID: Looks good to me. Note for future, I would like it even more if we got rid of the pre-defined jvm.cfg altogether and just always generated it. The build itself shouldn't be dictating artificial limitations on build parameters. If we want to enforce limitations those should be explicit instead. /Erik On 2018-05-05 04:26, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8202683 > > Fix: > http://cr.openjdk.java.net/~shade/8202683/webrev.01/ > > Minimal VM is targeted to 32-bit only, but hear me out. Recent build system changes, notably > conditional GC compilation, requires build/testing with some GCs disabled. Ultimately, we want > minimal VM to be buildable at all times. Today, we need to cross-compile to x86_32 to verify that, > but with this change, we can build minimal on x86_64, thus simplifying our day-to-day jobs. The > change itself generates jvm.cfg for minimal VM properly on both bitnesses. > > Testing: x86_64 server/minimal builds, x86_32 server/minimal builds > > Thanks, > -Aleksey > From erik.joelsson at oracle.com Mon May 7 15:41:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 May 2018 08:41:50 -0700 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> <3055b9bb-1f01-8b9f-33fc-621043aab511@oracle.com> Message-ID: Yes, sure, I'm working on a different fix in the same area now anyway so can sneak this fix in there. Will get done this week. /Erik On 2018-05-07 07:37, Thomas St?fe wrote: > Hi Erik, > > since your proposal worked, will you do a fix? > > Thanks, Thomas > > On Fri, May 4, 2018 at 8:30 AM, Thomas St?fe wrote: >> Hi Erik, >> >> that worked on both machines for all builds. >> >> Thanks, Thomas >> >> On Thu, May 3, 2018 at 10:13 PM, Erik Joelsson wrote: >>> Hello, >>> >>> In my case, VCINSTALLDIR is in short form already. Could you try changing >>> line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to BASIC_FIXUP_PATH? >>> >>> /Erik >>> >>> >>> >>> On 2018-05-03 11:17, Thomas St?fe wrote: >>>> Hi Erik, >>>> >>>> I see the error on two very different machines. One is my private >>>> machine - windows 7, VS2013 and VS2017 installed. The second one is my >>>> corporate Laptop, Windows 10 and only VS2013. >>>> >>>> In both cases I use a very recent cygwin64 installation. >>>> >>>> Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using >>>> well-known location from Visual Studio 12.0 and older" case, and in >>>> the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL >>>> variable content. Here the 64bit build on my corporate laptop: >>>> >>>> checking if fixpath.exe works... yes >>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>> POSSIBLE_MSVC_DLL Files >>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>> POSSIBLE_MSVC_DLL Visual >>>> POSSIBLE_MSVC_DLL Studio >>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>> configure: Found msvcr120.dll at >>>> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >>>> SYSTEMROOT >>>> checking found msvcr120.dll architecture... ok >>>> checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll >>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>> POSSIBLE_MSVC_DLL Files >>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>> POSSIBLE_MSVC_DLL Visual >>>> POSSIBLE_MSVC_DLL Studio >>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll >>>> configure: Found msvcp120.dll at >>>> /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in >>>> SYSTEMROOT >>>> >>>> As you can see, we fall back to the default in windows/system32, which >>>> happens to be working for 64bit. On 32bit, we get this error: >>>> >>>> checking if fixpath.exe works... yes >>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>> POSSIBLE_MSVC_DLL Files >>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>> POSSIBLE_MSVC_DLL Visual >>>> POSSIBLE_MSVC_DLL Studio >>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>> configure: Found msvcr120.dll at >>>> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >>>> SYSTEMROOT >>>> checking found msvcr120.dll architecture... incorrect, ignoring >>>> configure: The file type of the located msvcr120.dll is PE32+ >>>> executable (DLL) (GUI) x86-64, for MS Windows >>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>> (x86)/Microsoft Visual Studio >>>> 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of >>>> VCINSTALLDIR >>>> checking found msvcr120.dll architecture... incorrect, ignoring >>>> configure: The file type of the located msvcr120.dll is PE32 >>>> executable (DLL) (GUI) ARMv7 Thumb, for MS Windows >>>> checking for msvcr120.dll... no >>>> configure: error: Could not find msvcr120.dll. Please specify using >>>> --with-msvcr-dll. >>>> configure exiting with result code 1 >>>> >>>> Best Regards, Thomas >>>> >>>> On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson >>>> wrote: >>>>> Also, on my windows system, if I try using my local Visual Studio, both >>>>> MSVC >>>>> dll's are found in the Visual Studio dir, and the spaces are all cleaned >>>>> up. >>>>> I wonder what's different about your setup, Thomas. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> >>>>> On 2018-05-03 10:13, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >>>>>>> I think the main issue here is that BASIC_FIXUP_PATH should be called >>>>>>> for >>>>>>> the located msvcr*.dll files. I don't have time to look at it now, but >>>>>>> see >>>>>>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential file >>>>>>> is >>>>>>> located. This should remove all spaces from the path. >>>>>>> >>>>>> No, that is not a good solution. I intentionally removed that >>>>>> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name >>>>>> longer >>>>>> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to short >>>>>> style. This in turn has weird consequences in make when we copy that >>>>>> file >>>>>> using generated copy rules. The target file then gets the short style >>>>>> name >>>>>> literally. >>>>>> >>>>>> When I made that change, I looked at all the calls for potential >>>>>> locations >>>>>> and thought all of them had the directory prepared properly already. It >>>>>> seems I was wrong. I think the correct solution is to either get rid of >>>>>> spaces earlier for all the input directories we search, or maybe tweak >>>>>> BASIC_FIXUP_PATH to not touch the actual filename. >>>>>> >>>>>> /Erik >>>>>>> /Magnus >>>>>>> >>>>>>> On 2018-05-02 20:46, Thomas St?fe wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> My 32bit builds on Windows were failing since quite a while and I >>>>>>>> finally had some minutes to look into that. >>>>>>>> >>>>>>>> See prior discussion here: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>>>>>>> >>>>>>>> My output used to look like this: >>>>>>>> >>>>>>>> checking if fixpath.exe works... yes >>>>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>>>>> POSSIBLE_MSVC_DLL Files >>>>>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>>>>> POSSIBLE_MSVC_DLL Visual >>>>>>>> POSSIBLE_MSVC_DLL Studio >>>>>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>>>>>> configure: Found msvcr120.dll at >>>>>>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location in >>>>>>>> SYSTEMROOT >>>>>>>> >>>>>>>> So basically, build does not correctly search for msvcr120.dll in >>>>>>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>>>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>>>>>>> fails and falls back to the system default >>>>>>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit dll, >>>>>>>> and so configure fails. >>>>>>>> >>>>>>>> Note that 64bit build shows exactly the same behaviour! Only there it >>>>>>>> works by accident, since the default >>>>>>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>>>>>>> 64bit library too, so configure succeeds. >>>>>>>> >>>>>>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>>>>>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list of >>>>>>>> one or more files, but that for expression should be quoted. >>>>>>>> >>>>>>>> If I make this fix: >>>>>>>> >>>>>>>> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 >>>>>>>> 2018 >>>>>>>> -0700 >>>>>>>> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 >>>>>>>> 2018 >>>>>>>> +0200 >>>>>>>> @@ -556,7 +556,7 @@ >>>>>>>> fi >>>>>>>> fi >>>>>>>> # In case any of the above finds more than one file, loop >>>>>>>> over >>>>>>>> them. >>>>>>>> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>>>>>>> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>>>>>>> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>>>>>>> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>>>>>>> [$possible_msvc_dll], >>>>>>>> [well-known location in VCINSTALLDIR]) >>>>>>>> >>>>>>>> >>>>>>>> the 32bit configure correctly sets the msvcrt dll: >>>>>>>> >>>>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>>>>>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>>>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>>>>>> (x86)/Microsoft Visual Studio >>>>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using well-known >>>>>>>> location in VCINSTALLDIR >>>>>>>> checking found msvcr120.dll architecture... ok >>>>>>>> >>>>>>>> and I can start the build, but I get follow up errors: >>>>>>>> >>>>>>>> ... >>>>>>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>>>>>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>>>>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed by >>>>>>>> >>>>>>>> >>>>>>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>>>>>>> Stop. >>>>>>>> make[3]: *** Waiting for unfinished jobs.... >>>>>>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>>>>>>> make[2]: *** Waiting for unfinished jobs.... >>>>>>>> >>>>>>>> I stopped looking at that point, but to me it looks like the build >>>>>>>> cannot survive msvcrt.dll locations with spaces in them. >>>>>>>> >>>>>>>> Kind Regards, Thomas >>>>>>> From erik.joelsson at oracle.com Mon May 7 15:44:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 May 2018 08:44:50 -0700 Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms In-Reply-To: References: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> Message-ID: On 2018-05-07 08:40, Erik Joelsson wrote: > Looks good to me. > > Note for future, I would like it even more if we got rid of the > pre-defined jvm.cfg altogether and just always generated it. The build > itself shouldn't be dictating artificial limitations on build > parameters. If we want to enforce limitations those should be explicit > instead. > Just to clarify, I mean implicit artificial limitations. /Erik > /Erik > > > On 2018-05-05 04:26, Aleksey Shipilev wrote: >> RFE: >> ?? https://bugs.openjdk.java.net/browse/JDK-8202683 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8202683/webrev.01/ >> >> Minimal VM is targeted to 32-bit only, but hear me out. Recent build >> system changes, notably >> conditional GC compilation, requires build/testing with some GCs >> disabled. Ultimately, we want >> minimal VM to be buildable at all times. Today, we need to >> cross-compile to x86_32 to verify that, >> but with this change, we can build minimal on x86_64, thus >> simplifying our day-to-day jobs. The >> change itself generates jvm.cfg for minimal VM properly on both >> bitnesses. >> >> Testing: x86_64 server/minimal builds, x86_32 server/minimal builds >> >> Thanks, >> -Aleksey >> > From thomas.stuefe at gmail.com Mon May 7 15:45:53 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 7 May 2018 17:45:53 +0200 Subject: Windows: problem with msvxxx.dll locations containing spaces In-Reply-To: References: <55c83d52-3db3-2dd2-6603-3cec121303eb@oracle.com> <17b04d57-c581-f77f-1bf0-78b312be006e@oracle.com> <29c6e7fb-b32a-2765-d5cb-304bff2f1e2e@oracle.com> <3055b9bb-1f01-8b9f-33fc-621043aab511@oracle.com> Message-ID: Great, thanks! On Mon, May 7, 2018 at 5:41 PM, Erik Joelsson wrote: > Yes, sure, I'm working on a different fix in the same area now anyway so can > sneak this fix in there. Will get done this week. > > /Erik > > > > On 2018-05-07 07:37, Thomas St?fe wrote: >> >> Hi Erik, >> >> since your proposal worked, will you do a fix? >> >> Thanks, Thomas >> >> On Fri, May 4, 2018 at 8:30 AM, Thomas St?fe >> wrote: >>> >>> Hi Erik, >>> >>> that worked on both machines for all builds. >>> >>> Thanks, Thomas >>> >>> On Thu, May 3, 2018 at 10:13 PM, Erik Joelsson >>> wrote: >>>> >>>> Hello, >>>> >>>> In my case, VCINSTALLDIR is in short form already. Could you try >>>> changing >>>> line 543 from BASIC_WINDOWS_REWRITE_AS_UNIX_PATH to BASIC_FIXUP_PATH? >>>> >>>> /Erik >>>> >>>> >>>> >>>> On 2018-05-03 11:17, Thomas St?fe wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> I see the error on two very different machines. One is my private >>>>> machine - windows 7, VS2013 and VS2017 installed. The second one is my >>>>> corporate Laptop, Windows 10 and only VS2013. >>>>> >>>>> In both cases I use a very recent cygwin64 installation. >>>>> >>>>> Both cases run in TOOLCHAIN_SETUP_MSVC_DLL into the "# Probe: Using >>>>> well-known location from Visual Studio 12.0 and older" case, and in >>>>> the for loop at line 559 attempt to tokenize the POSSIBLE_MSVC_DLL >>>>> variable content. Here the 64bit build on my corporate laptop: >>>>> >>>>> checking if fixpath.exe works... yes >>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>> POSSIBLE_MSVC_DLL Files >>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>> POSSIBLE_MSVC_DLL Visual >>>>> POSSIBLE_MSVC_DLL Studio >>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>>> configure: Found msvcr120.dll at >>>>> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >>>>> SYSTEMROOT >>>>> checking found msvcr120.dll architecture... ok >>>>> checking for msvcr120.dll... /cygdrive/c/WINDOWS/system32/msvcr120.dll >>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>> POSSIBLE_MSVC_DLL Files >>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>> POSSIBLE_MSVC_DLL Visual >>>>> POSSIBLE_MSVC_DLL Studio >>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcp120.dll >>>>> configure: Found msvcp120.dll at >>>>> /cygdrive/c/WINDOWS/system32/msvcp120.dll using well-known location in >>>>> SYSTEMROOT >>>>> >>>>> As you can see, we fall back to the default in windows/system32, which >>>>> happens to be working for 64bit. On 32bit, we get this error: >>>>> >>>>> checking if fixpath.exe works... yes >>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>> POSSIBLE_MSVC_DLL Files >>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>> POSSIBLE_MSVC_DLL Visual >>>>> POSSIBLE_MSVC_DLL Studio >>>>> POSSIBLE_MSVC_DLL 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>>> configure: Found msvcr120.dll at >>>>> /cygdrive/c/WINDOWS/system32/msvcr120.dll using well-known location in >>>>> SYSTEMROOT >>>>> checking found msvcr120.dll architecture... incorrect, ignoring >>>>> configure: The file type of the located msvcr120.dll is PE32+ >>>>> executable (DLL) (GUI) x86-64, for MS Windows >>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>>> (x86)/Microsoft Visual Studio >>>>> 12.0/VC/redist/arm/Microsoft.VC120.CRT/msvcr120.dll using search of >>>>> VCINSTALLDIR >>>>> checking found msvcr120.dll architecture... incorrect, ignoring >>>>> configure: The file type of the located msvcr120.dll is PE32 >>>>> executable (DLL) (GUI) ARMv7 Thumb, for MS Windows >>>>> checking for msvcr120.dll... no >>>>> configure: error: Could not find msvcr120.dll. Please specify using >>>>> --with-msvcr-dll. >>>>> configure exiting with result code 1 >>>>> >>>>> Best Regards, Thomas >>>>> >>>>> On Thu, May 3, 2018 at 7:18 PM, Erik Joelsson >>>>> >>>>> wrote: >>>>>> >>>>>> Also, on my windows system, if I try using my local Visual Studio, >>>>>> both >>>>>> MSVC >>>>>> dll's are found in the Visual Studio dir, and the spaces are all >>>>>> cleaned >>>>>> up. >>>>>> I wonder what's different about your setup, Thomas. >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> >>>>>> On 2018-05-03 10:13, Erik Joelsson wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> On 2018-05-03 03:41, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> I think the main issue here is that BASIC_FIXUP_PATH should be >>>>>>>> called >>>>>>>> for >>>>>>>> the located msvcr*.dll files. I don't have time to look at it now, >>>>>>>> but >>>>>>>> see >>>>>>>> if you can do a rewrite using BASIC_FIXUP_PATH when the potential >>>>>>>> file >>>>>>>> is >>>>>>>> located. This should remove all spaces from the path. >>>>>>>> >>>>>>> No, that is not a good solution. I intentionally removed that >>>>>>> BASIC_FIXUP_PATH because in VS2017, one of the files has a file name >>>>>>> longer >>>>>>> than 8 characters and BASIC_FIXUP_PATH rewrites that filename to >>>>>>> short >>>>>>> style. This in turn has weird consequences in make when we copy that >>>>>>> file >>>>>>> using generated copy rules. The target file then gets the short style >>>>>>> name >>>>>>> literally. >>>>>>> >>>>>>> When I made that change, I looked at all the calls for potential >>>>>>> locations >>>>>>> and thought all of them had the directory prepared properly already. >>>>>>> It >>>>>>> seems I was wrong. I think the correct solution is to either get rid >>>>>>> of >>>>>>> spaces earlier for all the input directories we search, or maybe >>>>>>> tweak >>>>>>> BASIC_FIXUP_PATH to not touch the actual filename. >>>>>>> >>>>>>> /Erik >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> On 2018-05-02 20:46, Thomas St?fe wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> My 32bit builds on Windows were failing since quite a while and I >>>>>>>>> finally had some minutes to look into that. >>>>>>>>> >>>>>>>>> See prior discussion here: >>>>>>>>> >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021150.html >>>>>>>>> >>>>>>>>> My output used to look like this: >>>>>>>>> >>>>>>>>> checking if fixpath.exe works... yes >>>>>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program >>>>>>>>> POSSIBLE_MSVC_DLL Files >>>>>>>>> POSSIBLE_MSVC_DLL (x86)/Microsoft >>>>>>>>> POSSIBLE_MSVC_DLL Visual >>>>>>>>> POSSIBLE_MSVC_DLL Studio >>>>>>>>> POSSIBLE_MSVC_DLL >>>>>>>>> 12.0/VC/redist/x64/Microsoft.VC120.CRT/msvcr120.dll >>>>>>>>> configure: Found msvcr120.dll at >>>>>>>>> /cygdrive/c/Windows/system32/msvcr120.dll using well-known location >>>>>>>>> in >>>>>>>>> SYSTEMROOT >>>>>>>>> >>>>>>>>> So basically, build does not correctly search for msvcr120.dll in >>>>>>>>> "/cygdrive/c/Program Files (x86)/Microsoft Visual Studio >>>>>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll" - instead, it >>>>>>>>> fails and falls back to the system default >>>>>>>>> "/cygdrive/c/Windows/system32/msvcr120.dll". That dll is a 64bit >>>>>>>>> dll, >>>>>>>>> and so configure fails. >>>>>>>>> >>>>>>>>> Note that 64bit build shows exactly the same behaviour! Only there >>>>>>>>> it >>>>>>>>> works by accident, since the default >>>>>>>>> /cygdrive/c/Windows/system32/msvcr120.dll it finds happens to be a >>>>>>>>> 64bit library too, so configure succeeds. >>>>>>>>> >>>>>>>>> Part of the problem is TOOLCHAIN_SETUP_MSVC_DLL in >>>>>>>>> toolchain_windows.m4. We use a bash for loop to iterate thru a list >>>>>>>>> of >>>>>>>>> one or more files, but that for expression should be quoted. >>>>>>>>> >>>>>>>>> If I make this fix: >>>>>>>>> >>>>>>>>> --- a/make/autoconf/toolchain_windows.m4 Mon Apr 23 18:04:17 >>>>>>>>> 2018 >>>>>>>>> -0700 >>>>>>>>> +++ b/make/autoconf/toolchain_windows.m4 Wed May 02 18:38:04 >>>>>>>>> 2018 >>>>>>>>> +0200 >>>>>>>>> @@ -556,7 +556,7 @@ >>>>>>>>> fi >>>>>>>>> fi >>>>>>>>> # In case any of the above finds more than one file, loop >>>>>>>>> over >>>>>>>>> them. >>>>>>>>> - for possible_msvc_dll in $POSSIBLE_MSVC_DLL; do >>>>>>>>> + for possible_msvc_dll in "$POSSIBLE_MSVC_DLL"; do >>>>>>>>> $ECHO "POSSIBLE_MSVC_DLL $possible_msvc_dll" >>>>>>>>> TOOLCHAIN_CHECK_POSSIBLE_MSVC_DLL([$DLL_NAME], >>>>>>>>> [$possible_msvc_dll], >>>>>>>>> [well-known location in VCINSTALLDIR]) >>>>>>>>> >>>>>>>>> >>>>>>>>> the 32bit configure correctly sets the msvcrt dll: >>>>>>>>> >>>>>>>>> POSSIBLE_MSVC_DLL /cygdrive/c/Program Files (x86)/Microsoft Visual >>>>>>>>> Studio 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll >>>>>>>>> configure: Found msvcr120.dll at /cygdrive/c/Program Files >>>>>>>>> (x86)/Microsoft Visual Studio >>>>>>>>> 12.0/VC/redist/x86/Microsoft.VC120.CRT/msvcr120.dll using >>>>>>>>> well-known >>>>>>>>> location in VCINSTALLDIR >>>>>>>>> checking found msvcr120.dll architecture... ok >>>>>>>>> >>>>>>>>> and I can start the build, but I get follow up errors: >>>>>>>>> >>>>>>>>> ... >>>>>>>>> Creating hotspot/variant-server/tools/adlc/adlc.exe from 13 file(s) >>>>>>>>> Compiling 2 files for BUILD_JVMTI_TOOLS >>>>>>>>> make[3]: *** No rule to make target '/cygdrive/c/Program', needed >>>>>>>>> by >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> '/cygdrive/c/mine/projects/openjdk/jdk-jdk/output-fastdebug-32/support/modules_libs/java.base/Program'. >>>>>>>>> Stop. >>>>>>>>> make[3]: *** Waiting for unfinished jobs.... >>>>>>>>> make[2]: *** [make/Main.gmk:165: java.base-copy] Error 2 >>>>>>>>> make[2]: *** Waiting for unfinished jobs.... >>>>>>>>> >>>>>>>>> I stopped looking at that point, but to me it looks like the build >>>>>>>>> cannot survive msvcrt.dll locations with spaces in them. >>>>>>>>> >>>>>>>>> Kind Regards, Thomas >>>>>>>> >>>>>>>> > From david.holmes at oracle.com Mon May 7 21:00:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 May 2018 07:00:33 +1000 Subject: RFR 8202683: Minimal VM should build cleanly on 64-bit platforms In-Reply-To: References: <0b22cc97-f4ad-14c3-0002-031285761b9c@redhat.com> Message-ID: <8f069301-697a-7acc-5614-09d46abc9132@oracle.com> On 8/05/2018 1:40 AM, Erik Joelsson wrote: > Looks good to me. > > Note for future, I would like it even more if we got rid of the > pre-defined jvm.cfg altogether and just always generated it. The build That was supposed to be happening ... see (non-public sorry) JDK-8179985. Don't know what the current status is. David > itself shouldn't be dictating artificial limitations on build > parameters. If we want to enforce limitations those should be explicit > instead. > > /Erik > > > On 2018-05-05 04:26, Aleksey Shipilev wrote: >> RFE: >> ?? https://bugs.openjdk.java.net/browse/JDK-8202683 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8202683/webrev.01/ >> >> Minimal VM is targeted to 32-bit only, but hear me out. Recent build >> system changes, notably >> conditional GC compilation, requires build/testing with some GCs >> disabled. Ultimately, we want >> minimal VM to be buildable at all times. Today, we need to >> cross-compile to x86_32 to verify that, >> but with this change, we can build minimal on x86_64, thus simplifying >> our day-to-day jobs. The >> change itself generates jvm.cfg for minimal VM properly on both >> bitnesses. >> >> Testing: x86_64 server/minimal builds, x86_32 server/minimal builds >> >> Thanks, >> -Aleksey >> > From erik.joelsson at oracle.com Mon May 7 21:19:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 May 2018 14:19:32 -0700 Subject: RFR: JDK-8202557: OpenJDK fails to start in Windows 7 and 8.1 after upgrading compiler to VC 2017 Message-ID: With the new VS2017 toolchain Microsoft has changed how the C++ libraries work. In addition to the old msvcr* and msvcp* dll files, we now have a big lot of UCRT dlls as well. These files are also redistributable but are found in the Windows Kit rather than the Visual Studio installation. On modern and updated Windows systems these files should be present on the system, but to support older and non updated OSes, you can bundle them with your app, just like we already do with the old msvc* files. This patch does the following: * Adds the UCRT dll files to the windows devkit * Adds logic in configure for finding the correct UCRT redist dir if the toolchain version needs it * Makes the build copy the files into java.base * Makes sure any of these files are filtered out of any imported module to avoid conflicts Bug: https://bugs.openjdk.java.net/browse/JDK-8202557 Webrev: http://cr.openjdk.java.net/~erikj/8202557/webrev.01/index.html /Erik From igor.ignatyev at oracle.com Mon May 7 22:35:55 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 7 May 2018 15:35:55 -0700 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests Message-ID: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html > 45710 lines changed: 45710 ins; 0 del; 0 mod; Hi all, could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: - vmTestbase_vm_g1classunloading - vmTestbase_vm_gc_compact - vmTestbase_vm_gc_concurrent - vmTestbase_vm_gc_container - vmTestbase_vm_gc_juggle - vmTestbase_vm_gc_locker - vmTestbase_vm_gc_ref - vmTestbase_vm_gc_misc besides these test groups, which split tests by functionality under test, the patch also adds test groups used only for test selection purposes: - vmTestbase_vm_gc which includes all vmTestbase_vm_gc_* test groups - vmTestbase_vm_gc_quick -- "quick" tests from vmTestbase_vm_gc test group - vmTestbase_largepages which consists of tests which are believed to be good candidate to test largepage. this group is used in our testing w/ external vm flags and/or on pre-configured hosts. As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html Thanks, -- Igor From erik.joelsson at oracle.com Mon May 7 22:46:14 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 May 2018 15:46:14 -0700 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: References: Message-ID: <53e5b90f-0b4f-3f71-5615-ee87c97f97e7@oracle.com> Build change looks good. /Erik On 2018-05-07 15:35, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html >> 45710 lines changed: 45710 ins; 0 del; 0 mod; > Hi all, > > could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: > - vmTestbase_vm_g1classunloading > - vmTestbase_vm_gc_compact > - vmTestbase_vm_gc_concurrent > - vmTestbase_vm_gc_container > - vmTestbase_vm_gc_juggle > - vmTestbase_vm_gc_locker > - vmTestbase_vm_gc_ref > - vmTestbase_vm_gc_misc > > besides these test groups, which split tests by functionality under test, the patch also adds test groups used only for test selection purposes: > - vmTestbase_vm_gc which includes all vmTestbase_vm_gc_* test groups > - vmTestbase_vm_gc_quick -- "quick" tests from vmTestbase_vm_gc test group > - vmTestbase_largepages which consists of tests which are believed to be good candidate to test largepage. this group is used in our testing w/ external vm flags and/or on pre-configured hosts. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 > webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html > > Thanks, > -- Igor From magnus.ihse.bursie at oracle.com Tue May 8 09:06:15 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 8 May 2018 11:06:15 +0200 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: References: Message-ID: <0fecb84f-9d8b-8056-ee01-6e16c5e9467a@oracle.com> On 2018-05-08 00:35, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html >> 45710 lines changed: 45710 ins; 0 del; 0 mod; > Hi all, > > could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: > - vmTestbase_vm_g1classunloading > - vmTestbase_vm_gc_compact > - vmTestbase_vm_gc_concurrent > - vmTestbase_vm_gc_container > - vmTestbase_vm_gc_juggle > - vmTestbase_vm_gc_locker > - vmTestbase_vm_gc_ref > - vmTestbase_vm_gc_misc > > besides these test groups, which split tests by functionality under test, the patch also adds test groups used only for test selection purposes: > - vmTestbase_vm_gc which includes all vmTestbase_vm_gc_* test groups > - vmTestbase_vm_gc_quick -- "quick" tests from vmTestbase_vm_gc test group > - vmTestbase_largepages which consists of tests which are believed to be good candidate to test largepage. this group is used in our testing w/ external vm flags and/or on pre-configured hosts. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 > webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html Build changes look good. /Magnus > > Thanks, > -- Igor From christoph.langer at sap.com Tue May 8 09:54:10 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 8 May 2018 09:54:10 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> Message-ID: Hi Eric, thanks for that excellent suggestion. I already thought there should be some means to do that but was not aware of how that could be accomplished. I updated the webrev in place. Thanks Christoph > -----Original Message----- > From: Erik Joelsson [mailto:erik.joelsson at oracle.com] > Sent: Freitag, 4. Mai 2018 17:45 > To: Langer, Christoph ; awt- > dev at openjdk.java.net > Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT > Input Method Framework (IMF) > > Hello, > > It looks like what you are trying to achieve is to override > awt_InputMethod.c with an OS specific version of that file. We have a > construct for this in SetupNativeCompilation that should handle it > automatically, if you just list the source dirs in priority order. I > would suggest leveraging this by making this change instead: > > First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like this: > > $(wildcard > $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) > \ > > /Erik > > > On 2018-05-04 07:07, Langer, Christoph wrote: > > Hi, > > > > please help reviewing the contribution of the support for the AIX Input > Method Editor (IME) in AWT's Input Method Framework. > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 > > > > I took Ichiroh's initial proposal [1] and tried to integrate it better with > existing code. I have split > src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into > > a) a base class containing the common code: > src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java > > b) a specific class for the common Linux/Unixes: > src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and > > c) a specific class for AIX: > src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > > > > The AIX specific additions to the native code of > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so > much that I decided to add a specific implementation file for AIX: > src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The > changes to the former file are some cleanups. > > > > I'm still in the process of testing the changes - but maybe you can run > further tests, especially on non-AIX unixes to make sure we didn't break > something. > > > > Thanks & Best regards > > Christoph > > > > [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018- > April/013869.html > > From sgehwolf at redhat.com Tue May 8 13:22:14 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 15:22:14 +0200 Subject: JDK 10u and generated-configure.sh In-Reply-To: <20180508130907.GD3211@vimes> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> Message-ID: Hi Rob, I can file a bug and follow the approval process and get it pushed. First, I'd like to know whether: A. An action needs to be taken at all? I assume yes, but just making sure. B. Contributors outside Oracle can push generated-configure.sh changes? I seem to remember that for JDK 8 that has to be done by an Oracle sponsor since some generated-configure.sh changes need to be done on closed sources. Not sure whether this info is accurate. Thanks, Severin On Tue, 2018-05-08 at 14:09 +0100, Rob McKenna wrote: > Ahem: http://openjdk.java.net/census#jdk-updates > > -Rob > > On 08/05/18 14:08, Rob McKenna wrote: > > (also, according to http://db.openjdk.java.net/people/ you have > > committer rights to the jdk-updates project.) > > > > -Rob > > > > On 08/05/18 14:07, Rob McKenna wrote: > > > Hi Severin, > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > -Rob > > > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > > configure.sh. If so there is a good chance that my recent push to > > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > > this? > > > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > > --- a/make/autoconf/generated-configure.sh > > > > +++ b/make/autoconf/generated-configure.sh > > > > @@ -5187,7 +5187,7 @@ > > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > > -DATE_WHEN_GENERATED=1516225089 > > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > > > ############################################################################### > > > > # > > > > @@ -67486,7 +67486,7 @@ > > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > > > # Maximum amount of heap memory and stack size. > > > > - JVM_HEAP_LIMIT_32="1024" > > > > + JVM_HEAP_LIMIT_32="768" > > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > > JVM_HEAP_LIMIT_64="1600" > > > > STACK_SIZE_32=768 > > > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > > > Please advise whether anything needs to be done. > > > > > > > > Thanks, > > > > Severin > > > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From yasuenag at gmail.com Tue May 8 13:42:04 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 8 May 2018 22:42:04 +0900 Subject: Build failure on Fedora 28 Message-ID: <55fe1553-3557-c560-e604-3c5cabe83a6d@gmail.com> Hi all, I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as following: ``` [ysuenaga at fc28 jdk]$ make images Building target 'images' in configuration 'linux-x86_64-normal-server-fastdebug' gmake[3]: *** [GenerateLinkOptData.gmk:64: /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] Error 1 gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-server-fastdebug' (exit code 2) No indication of failed target found. Hint: Try searching the build log for '] Error'. Hint: See doc/building.html#troubleshooting for assistance. make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error 2 make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 ``` It seems "interim-image" is not valid: ``` [ysuenaga at fc28 jdk]$ ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java --version Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object ``` It can succeed on Fedora 27. So I think it causes by OS. I've disabled SELinux, and warnings / errors are nothing in `journalctl -a`. Do you have any idea to resolve this issue? Thanks, Yasumasa From tim.bell at oracle.com Tue May 8 14:17:11 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 08 May 2018 07:17:11 -0700 Subject: RFR: JDK-8202557: OpenJDK fails to start in Windows 7 and 8.1 after upgrading compiler to VC 2017 In-Reply-To: References: Message-ID: <5AF1B167.1090607@oracle.com> Erik: > With the new VS2017 toolchain Microsoft has changed how the C++ > libraries work. In addition to the old msvcr* and msvcp* dll files, we > now have a big lot of UCRT dlls as well. These files are also > redistributable but are found in the Windows Kit rather than the Visual > Studio installation. On modern and updated Windows systems these files > should be present on the system, but to support older and non updated > OSes, you can bundle them with your app, just like we already do with > the old msvc* files. > > This patch does the following: > > * Adds the UCRT dll files to the windows devkit > * Adds logic in configure for finding the correct UCRT redist dir if the > toolchain version needs it > * Makes the build copy the files into java.base > * Makes sure any of these files are filtered out of any imported module > to avoid conflicts > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202557 > > Webrev: http://cr.openjdk.java.net/~erikj/8202557/webrev.01/index.html Looks good. Tim From rob.mckenna at oracle.com Tue May 8 14:20:22 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 8 May 2018 15:20:22 +0100 Subject: JDK 10u and generated-configure.sh In-Reply-To: References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> Message-ID: <20180508142022.GE3211@vimes> No, you're correct. The closed changes do need to be handled by someone in Oracle so it makes sense to get an Oracle committer to push. So: A. Yes. B. You're absolutely right. I'll take care of the push once you've got the change codereviewed / approved for push. Thanks, -Rob On 08/05/18 15:22, Severin Gehwolf wrote: > Hi Rob, > > I can file a bug and follow the approval process and get it pushed. > First, I'd like to know whether: > > A. An action needs to be taken at all? I assume yes, but just making > sure. > B. Contributors outside Oracle can push generated-configure.sh changes? > I seem to remember that for JDK 8 that has to be done by an Oracle > sponsor since some generated-configure.sh changes need to be done on > closed sources. Not sure whether this info is accurate. > > Thanks, > Severin > > On Tue, 2018-05-08 at 14:09 +0100, Rob McKenna wrote: > > Ahem: http://openjdk.java.net/census#jdk-updates > > > > -Rob > > > > On 08/05/18 14:08, Rob McKenna wrote: > > > (also, according to http://db.openjdk.java.net/people/ you have > > > committer rights to the jdk-updates project.) > > > > > > -Rob > > > > > > On 08/05/18 14:07, Rob McKenna wrote: > > > > Hi Severin, > > > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > > > -Rob > > > > > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > > > configure.sh. If so there is a good chance that my recent push to > > > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > > > this? > > > > > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > > > --- a/make/autoconf/generated-configure.sh > > > > > +++ b/make/autoconf/generated-configure.sh > > > > > @@ -5187,7 +5187,7 @@ > > > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > > > -DATE_WHEN_GENERATED=1516225089 > > > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > > > > > ############################################################################### > > > > > # > > > > > @@ -67486,7 +67486,7 @@ > > > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > > > > > # Maximum amount of heap memory and stack size. > > > > > - JVM_HEAP_LIMIT_32="1024" > > > > > + JVM_HEAP_LIMIT_32="768" > > > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > > > JVM_HEAP_LIMIT_64="1600" > > > > > STACK_SIZE_32=768 > > > > > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > > > > > Please advise whether anything needs to be done. > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From sgehwolf at redhat.com Tue May 8 14:39:02 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 16:39:02 +0200 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 (was: Re: JDK 10u and generated-configure.sh) In-Reply-To: <20180508142022.GE3211@vimes> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> Message-ID: Hi, On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: > No, you're correct. The closed changes do need to be handled by someone > in Oracle so it makes sense to get an Oracle committer to push. > > So: > > A. Yes. > B. You're absolutely right. I'll take care of the push once you've got > the change codereviewed / approved for push. Thank you, Rob! This seems a rather strange case as the actual change is already pushed[1]. What's missing are the generated-configure.sh changes after "bash make/autoconf/autogen.sh". Not sure what needs to get code- reviewed in this case. Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and then performing the autogen.sh step should give you the changes that need to get pushed. That's what the following webrev is: Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ Anyway, can somebody on the build-team rubber-stamp this, please? Thanks, Severin [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > Thanks, > > -Rob > > On 08/05/18 15:22, Severin Gehwolf wrote: > > Hi Rob, > > > > I can file a bug and follow the approval process and get it pushed. > > First, I'd like to know whether: > > > > A. An action needs to be taken at all? I assume yes, but just making > > sure. > > B. Contributors outside Oracle can push generated-configure.sh changes? > > I seem to remember that for JDK 8 that has to be done by an Oracle > > sponsor since some generated-configure.sh changes need to be done on > > closed sources. Not sure whether this info is accurate. > > > > Thanks, > > Severin > > > > On Tue, 2018-05-08 at 14:09 +0100, Rob McKenna wrote: > > > Ahem: http://openjdk.java.net/census#jdk-updates > > > > > > -Rob > > > > > > On 08/05/18 14:08, Rob McKenna wrote: > > > > (also, according to http://db.openjdk.java.net/people/ you have > > > > committer rights to the jdk-updates project.) > > > > > > > > -Rob > > > > > > > > On 08/05/18 14:07, Rob McKenna wrote: > > > > > Hi Severin, > > > > > > > > > > You'll need to file a bug and follow the approval request process. > > > > > > > > > > http://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > > > > > -Rob > > > > > > > > > > On 08/05/18 14:56, Severin Gehwolf wrote: > > > > > > Hi, > > > > > > > > > > > > It just occurred to me that JDK 10u seems to still be using generated- > > > > > > configure.sh. If so there is a good chance that my recent push to > > > > > > jdk10u[1] might have broken something. Is it enough to ammend this with > > > > > > this? > > > > > > > > > > > > diff --git a/make/autoconf/generated-configure.sh b/make/autoconf/generated-configure.sh > > > > > > --- a/make/autoconf/generated-configure.sh > > > > > > +++ b/make/autoconf/generated-configure.sh > > > > > > @@ -5187,7 +5187,7 @@ > > > > > > #CUSTOM_AUTOCONF_INCLUDE > > > > > > > > > > > > # Do not change or remove the following line, it is needed for consistency checks: > > > > > > -DATE_WHEN_GENERATED=1516225089 > > > > > > +DATE_WHEN_GENERATED=1525783673 > > > > > > > > > > > > ############################################################################### > > > > > > # > > > > > > @@ -67486,7 +67486,7 @@ > > > > > > BOOTCYCLE_JVM_ARGS_BIG=-Xms64M > > > > > > > > > > > > # Maximum amount of heap memory and stack size. > > > > > > - JVM_HEAP_LIMIT_32="1024" > > > > > > + JVM_HEAP_LIMIT_32="768" > > > > > > # Running a 64 bit JVM allows for and requires a bigger heap > > > > > > JVM_HEAP_LIMIT_64="1600" > > > > > > STACK_SIZE_32=768 > > > > > > > > > > > > Does somebody at Oracle need to push this for me? My sincere appologies for the trouble! > > > > > > > > > > > > Please advise whether anything needs to be done. > > > > > > > > > > > > Thanks, > > > > > > Severin > > > > > > > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From tim.bell at oracle.com Tue May 8 14:53:48 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 08 May 2018 07:53:48 -0700 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 In-Reply-To: References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> Message-ID: <5AF1B9FC.4070605@oracle.com> See below- On 05/08/18 07:39, Severin Gehwolf wrote: > Hi, > > On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: >> No, you're correct. The closed changes do need to be handled by someone >> in Oracle so it makes sense to get an Oracle committer to push. >> >> So: >> >> A. Yes. >> B. You're absolutely right. I'll take care of the push once you've got >> the change codereviewed / approved for push. > > Thank you, Rob! > > This seems a rather strange case as the actual change is already > pushed[1]. What's missing are the generated-configure.sh changes after > "bash make/autoconf/autogen.sh". Not sure what needs to get code- > reviewed in this case. > > Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and > then performing the autogen.sh step should give you the changes that > need to get pushed. That's what the following webrev is: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ > > Anyway, can somebody on the build-team rubber-stamp this, please? The make/autoconf/generated-configure.sh changes look good. Approved. Over to Rob for the pushing, including the closed generated-configure.sh. Tim > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f From erik.joelsson at oracle.com Tue May 8 15:21:37 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 08:21:37 -0700 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 In-Reply-To: <5AF1B9FC.4070605@oracle.com> References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> <5AF1B9FC.4070605@oracle.com> Message-ID: Please note that Severin mistakenly pushed just the .m4 change here: http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f We now need another bugid for pushing just a new generated-configure.sh. This needs to be pushed to both open and closed. To generate it, just do "bash closed/make/autoconf/autogen.sh". /Erik On 2018-05-08 07:53, Tim Bell wrote: > See below- > > On 05/08/18 07:39, Severin Gehwolf wrote: >> Hi, >> >> On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: >>> No, you're correct. The closed changes do need to be handled by someone >>> in Oracle so it makes sense to get an Oracle committer to push. >>> >>> So: >>> >>> A. Yes. >>> B. You're absolutely right. I'll take care of the push once you've got >>> the change codereviewed / approved for push. >> >> Thank you, Rob! >> >> This seems a rather strange case as the actual change is already >> pushed[1]. What's missing are the generated-configure.sh changes after >> "bash make/autoconf/autogen.sh". Not sure what needs to get code- >> reviewed in this case. >> >> Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and >> then performing the autogen.sh step should give you the changes that >> need to get pushed. That's what the following webrev is: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ >> >> Anyway, can somebody on the build-team rubber-stamp this, please? > > > The make/autoconf/generated-configure.sh changes look good. Approved. > > Over to Rob for the pushing, including the closed generated-configure.sh. > > Tim > >> >> Thanks, >> Severin >> >> [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > From erik.joelsson at oracle.com Tue May 8 15:24:22 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 08:24:22 -0700 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> Message-ID: <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> Build change looks good. /Erik On 2018-05-08 02:54, Langer, Christoph wrote: > Hi Eric, > > thanks for that excellent suggestion. I already thought there should be some means to do that but was not aware of how that could be accomplished. I updated the webrev in place. > > Thanks > Christoph > >> -----Original Message----- >> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] >> Sent: Freitag, 4. Mai 2018 17:45 >> To: Langer, Christoph ; awt- >> dev at openjdk.java.net >> Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT >> Input Method Framework (IMF) >> >> Hello, >> >> It looks like what you are trying to achieve is to override >> awt_InputMethod.c with an OS specific version of that file. We have a >> construct for this in SetupNativeCompilation that should handle it >> automatically, if you just list the source dirs in priority order. I >> would suggest leveraging this by making this change instead: >> >> First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like this: >> >> $(wildcard >> $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) >> \ >> >> /Erik >> >> >> On 2018-05-04 07:07, Langer, Christoph wrote: >>> Hi, >>> >>> please help reviewing the contribution of the support for the AIX Input >> Method Editor (IME) in AWT's Input Method Framework. >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 >>> >>> I took Ichiroh's initial proposal [1] and tried to integrate it better with >> existing code. I have split >> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into >>> a) a base class containing the common code: >> src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java >>> b) a specific class for the common Linux/Unixes: >> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and >>> c) a specific class for AIX: >> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>> The AIX specific additions to the native code of >> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were so >> much that I decided to add a specific implementation file for AIX: >> src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. The >> changes to the former file are some cleanups. >>> I'm still in the process of testing the changes - but maybe you can run >> further tests, especially on non-AIX unixes to make sure we didn't break >> something. >>> Thanks & Best regards >>> Christoph >>> >>> [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018- >> April/013869.html From erik.joelsson at oracle.com Tue May 8 15:27:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 08:27:59 -0700 Subject: Build failure on Fedora 28 In-Reply-To: <55fe1553-3557-c560-e604-3c5cabe83a6d@gmail.com> References: <55fe1553-3557-c560-e604-3c5cabe83a6d@gmail.com> Message-ID: Hello, Your assessment is looks correct so far. At this point, one would have to start debugging the image to figure out what's wrong with it. Are you able to run the exploded image in ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? Has anyone at Redhat built successfully on Fedora 28 yet? /Erik On 2018-05-08 06:42, Yasumasa Suenaga wrote: > Hi all, > > I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as > following: > > ``` > [ysuenaga at fc28 jdk]$ make images > Building target 'images' in configuration > 'linux-x86_64-normal-server-fastdebug' > gmake[3]: *** [GenerateLinkOptData.gmk:64: > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] > Error 1 > gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 > > ERROR: Build failed for target 'images' in configuration > 'linux-x86_64-normal-server-fastdebug' (exit code 2) > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error 2 > make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 > ``` > > It seems "interim-image" is not valid: > > ``` > [ysuenaga at fc28 jdk]$ > ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java > --version > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/Object > ``` > > It can succeed on Fedora 27. So I think it causes by OS. > I've disabled SELinux, and warnings / errors are nothing in > `journalctl -a`. > > Do you have any idea to resolve this issue? > > > Thanks, > > Yasumasa From sgehwolf at redhat.com Tue May 8 15:28:59 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 17:28:59 +0200 Subject: [10u] RFR: 8202784: generated-configure.sh changes missing in 8201495 In-Reply-To: References: <3f251397cbcfd0ddd98cea904ef2fe8725d7aeb5.camel@redhat.com> <20180508130718.GB3211@vimes> <20180508130825.GC3211@vimes> <20180508130907.GD3211@vimes> <20180508142022.GE3211@vimes> <5AF1B9FC.4070605@oracle.com> Message-ID: <27fb782a5957d994f8d881f0f0d0f1ebc2d83cbe.camel@redhat.com> On Tue, 2018-05-08 at 08:21 -0700, Erik Joelsson wrote: > Please note that Severin mistakenly pushed just the .m4 change here: > > http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > > We now need another bugid for pushing just a new generated-configure.sh. > This needs to be pushed to both open and closed. To generate it, just do > "bash closed/make/autoconf/autogen.sh". Yes, thanks. I've created a bug for this already: https://bugs.openjdk.java.net/browse/JDK-8202784 My appologies again for this screw-up :-( Cheers, Severin > /Erik > > > On 2018-05-08 07:53, Tim Bell wrote: > > See below- > > > > On 05/08/18 07:39, Severin Gehwolf wrote: > > > Hi, > > > > > > On Tue, 2018-05-08 at 15:20 +0100, Rob McKenna wrote: > > > > No, you're correct. The closed changes do need to be handled by someone > > > > in Oracle so it makes sense to get an Oracle committer to push. > > > > > > > > So: > > > > > > > > A. Yes. > > > > B. You're absolutely right. I'll take care of the push once you've got > > > > the change codereviewed / approved for push. > > > > > > Thank you, Rob! > > > > > > This seems a rather strange case as the actual change is already > > > pushed[1]. What's missing are the generated-configure.sh changes after > > > "bash make/autoconf/autogen.sh". Not sure what needs to get code- > > > reviewed in this case. > > > > > > Getting the latest revision (ddb10178cbb2) from jdk-updates/jdk10u and > > > then performing the autogen.sh step should give you the changes that > > > need to get pushed. That's what the following webrev is: > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202784 > > > webrev: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8202784/webrev.01/ > > > > > > Anyway, can somebody on the build-team rubber-stamp this, please? > > > > > > The make/autoconf/generated-configure.sh changes look good. Approved. > > > > Over to Rob for the pushing, including the closed generated-configure.sh. > > > > Tim > > > > > > > > Thanks, > > > Severin > > > > > > [1] http://hg.openjdk.java.net/jdk-updates/jdk10u/rev/2f8a4aafe85f > > From sgehwolf at redhat.com Tue May 8 15:30:14 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 17:30:14 +0200 Subject: Build failure on Fedora 28 In-Reply-To: <55fe1553-3557-c560-e604-3c5cabe83a6d@gmail.com> References: <55fe1553-3557-c560-e604-3c5cabe83a6d@gmail.com> Message-ID: On Tue, 2018-05-08 at 22:42 +0900, Yasumasa Suenaga wrote: > Hi all, > > I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as following: > > ``` > [ysuenaga at fc28 jdk]$ make images > Building target 'images' in configuration 'linux-x86_64-normal-server-fastdebug' > gmake[3]: *** [GenerateLinkOptData.gmk:64: /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] Error 1 > gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 > > ERROR: Build failed for target 'images' in configuration 'linux-x86_64-normal-server-fastdebug' (exit code 2) > > No indication of failed target found. > Hint: Try searching the build log for '] Error'. > Hint: See doc/building.html#troubleshooting for assistance. > > make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error 2 > make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 > ``` > > It seems "interim-image" is not valid: > > ``` > [ysuenaga at fc28 jdk]$ ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java --version > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/Object > ``` > > It can succeed on Fedora 27. So I think it causes by OS. > I've disabled SELinux, and warnings / errors are nothing in `journalctl -a`. > > Do you have any idea to resolve this issue? Not exactly sure what's going on, but I've reproduced. I'll have a poke at this too. Note that F28 has GCC 8. F27 has GCC 7. Thanks, Severin From sgehwolf at redhat.com Tue May 8 15:37:35 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 May 2018 17:37:35 +0200 Subject: Build failure on Fedora 28 In-Reply-To: References: <55fe1553-3557-c560-e604-3c5cabe83a6d@gmail.com> Message-ID: <4016c7ca18160eced1291ec767a3dee1f4f9f36e.camel@redhat.com> On Tue, 2018-05-08 at 08:27 -0700, Erik Joelsson wrote: > Hello, > > Your assessment is looks correct so far. At this point, one would have > to start debugging the image to figure out what's wrong with it. Are you > able to run the exploded image in > ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? > > Has anyone at Redhat built successfully on Fedora 28 yet? It's Red Hat, not Redhat ;-) We've built JDK 10 on Fedora 28[1]. I've just recently upgraded to F28 so looking into getting JDK 11 to build on Fedora 28 currently. Thanks, Severin [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1077848 > /Erik > > > On 2018-05-08 06:42, Yasumasa Suenaga wrote: > > Hi all, > > > > I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as > > following: > > > > ``` > > [ysuenaga at fc28 jdk]$ make images > > Building target 'images' in configuration > > 'linux-x86_64-normal-server-fastdebug' > > gmake[3]: *** [GenerateLinkOptData.gmk:64: > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] > > Error 1 > > gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 > > > > ERROR: Build failed for target 'images' in configuration > > 'linux-x86_64-normal-server-fastdebug' (exit code 2) > > > > No indication of failed target found. > > Hint: Try searching the build log for '] Error'. > > Hint: See doc/building.html#troubleshooting for assistance. > > > > make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error 2 > > make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 > > ``` > > > > It seems "interim-image" is not valid: > > > > ``` > > [ysuenaga at fc28 jdk]$ > > ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java > > --version > > Error occurred during initialization of VM > > java/lang/NoClassDefFoundError: java/lang/Object > > ``` > > > > It can succeed on Fedora 27. So I think it causes by OS. > > I've disabled SELinux, and warnings / errors are nothing in > > `journalctl -a`. > > > > Do you have any idea to resolve this issue? > > > > > > Thanks, > > > > Yasumasa > > From kim.barrett at oracle.com Tue May 8 18:02:02 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 May 2018 14:02:02 -0400 Subject: RFR: 8179887 - Build failure with glibc >= 2.24: error: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated In-Reply-To: References: <121e71e5-bcc7-d907-ce4c-9fdbd0bbddf0@redhat.com> <403C5242-7255-4BE4-BD3E-A5EEAD278283@oracle.com> <3197d649-2c9e-299c-db40-b6715aea8b92@redhat.com> <2a790c19-7331-0908-7c75-9704720a6a0d@redhat.com> <78a4e259-2ac6-7318-6208-82ed8b35292a@oracle.com> <6AE7B98E-FF1B-43E0-8108-7128707BD5F5@oracle.com> Message-ID: > On May 7, 2018, at 11:20 AM, B. Blaser wrote: > > On 7 May 2018 at 14:19, B. Blaser wrote: >> On 6 May 2018 at 18:35, B. Blaser wrote: >>> On 5 May 2018 at 22:26, Kim Barrett wrote: >>>>> On May 5, 2018, at 8:03 AM, B. Blaser wrote: >>>>> >>>>> On 4 May 2018 at 17:42, Alan Bateman wrote: >>>>>> On 04/05/2018 16:31, B. Blaser wrote: >>>>>>> >>>>>>> : >>>>>>> >>>>>>> I'll create a new JBS issue (unless you want to) since the fix is >>>>>>> mostly located in core-libs and only intended to make the build >>>>>>> complete. >>>>>>> But I'll still need someone to review and push the fix, would you be >>>>>>> interested in doing this? >>>>>>> >>>>>> I think someone needs to explore the behavior on other platforms too as the >>>>>> #ifndef __linux__ patches are ugly. >>>>> >>>>> Yes sure but I cannot test it elsewhere myself... and we can easily >>>>> remove them once POSIX officially deprecates 'readdir_r' or if someone >>>>> validates the fix on other systems. >>>> >>>> I'm not sure anyone has the ability to test on all supported. That >>>> doesn't (and really can't) prevent making changes across platforms to >>>> platform-specific code. It just means one needs to get help with >>>> testing. Make the change across platforms, test on those platforms >>>> one has access to, and ask here for help testing on others. >>> >>> OK, I'll provide a cross-platform fix to be evaluated on other systems too. >> >> Here it is, tier1 is successful on Linux with glibc=2.26. >> Any feedback on other systems would be very helpful. > > Some more cleanup? I?ve created https://bugs.openjdk.java.net/browse/JDK-8202794 to cover this. Suggest switching the subject line. From igor.ignatyev at oracle.com Tue May 8 19:03:56 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 8 May 2018 12:03:56 -0700 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: <0fecb84f-9d8b-8056-ee01-6e16c5e9467a@oracle.com> References: <0fecb84f-9d8b-8056-ee01-6e16c5e9467a@oracle.com> Message-ID: <019E972C-8B01-4CB4-A918-443916607DBE@oracle.com> Erik, Magnus, thank you for reviewing build change. can someone from GC people Review the rest? -- Igor > On May 8, 2018, at 2:06 AM, Magnus Ihse Bursie wrote: > > On 2018-05-08 00:35, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html >>> 45710 lines changed: 45710 ins; 0 del; 0 mod; >> Hi all, >> >> could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: >> - vmTestbase_vm_g1classunloading >> - vmTestbase_vm_gc_compact >> - vmTestbase_vm_gc_concurrent >> - vmTestbase_vm_gc_container >> - vmTestbase_vm_gc_juggle >> - vmTestbase_vm_gc_locker >> - vmTestbase_vm_gc_ref >> - vmTestbase_vm_gc_misc >> >> besides these test groups, which split tests by functionality under test, the patch also adds test groups used only for test selection purposes: >> - vmTestbase_vm_gc which includes all vmTestbase_vm_gc_* test groups >> - vmTestbase_vm_gc_quick -- "quick" tests from vmTestbase_vm_gc test group >> - vmTestbase_largepages which consists of tests which are believed to be good candidate to test largepage. this group is used in our testing w/ external vm flags and/or on pre-configured hosts. >> >> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 >> webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html > Build changes look good. > > /Magnus > >> >> Thanks, >> -- Igor From leonid.mesnik at oracle.com Tue May 8 21:23:34 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 8 May 2018 14:23:34 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests Message-ID: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> Hi Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8199271 From erik.joelsson at oracle.com Tue May 8 21:41:54 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 8 May 2018 14:41:54 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests In-Reply-To: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> References: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> Message-ID: <4f0ea090-94c9-ffd7-3852-a9a9d14e8af8@oracle.com> Build changes look good. /Erik On 2018-05-08 14:23, Leonid Mesnik wrote: > Hi > > Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. > They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. > > The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. > > I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. > > webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8199271 From yasuenag at gmail.com Wed May 9 01:39:08 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 May 2018 10:39:08 +0900 Subject: Build failure on Fedora 28 Message-ID: Hi, 2018-05-09 0:27 GMT+09:00 Erik Joelsson : > Hello, > > Your assessment is looks correct so far. At this point, one would have to > start debugging the image to figure out what's wrong with it. Are you able > to run the exploded image in > ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? It works. So I wonder why invalid image was built. ``` $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version openjdk 11-internal 2018-09-25 OpenJDK Runtime Environment (fastdebug build 11-internal+0-adhoc.ysuenaga.jdk) OpenJDK 64-Bit Server VM (fastdebug build 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) ``` I'm waiting for Severin's evaluation :-) Thanks, Yasumasa > Has anyone at Redhat built successfully on Fedora 28 yet? > > /Erik > > > > On 2018-05-08 06:42, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >> following: >> >> ``` >> [ysuenaga at fc28 jdk]$ make images >> Building target 'images' in configuration >> 'linux-x86_64-normal-server-fastdebug' >> gmake[3]: *** [GenerateLinkOptData.gmk:64: >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >> Error 1 >> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >> >> ERROR: Build failed for target 'images' in configuration >> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >> >> No indication of failed target found. >> Hint: Try searching the build log for '] Error'. >> Hint: See doc/building.html#troubleshooting for assistance. >> >> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error 2 >> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 >> ``` >> >> It seems "interim-image" is not valid: >> >> ``` >> [ysuenaga at fc28 jdk]$ >> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >> --version >> Error occurred during initialization of VM >> java/lang/NoClassDefFoundError: java/lang/Object >> ``` >> >> It can succeed on Fedora 27. So I think it causes by OS. >> I've disabled SELinux, and warnings / errors are nothing in `journalctl >> -a`. >> >> Do you have any idea to resolve this issue? >> >> >> Thanks, >> >> Yasumasa > > From david.holmes at oracle.com Wed May 9 01:48:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 May 2018 11:48:42 +1000 Subject: Build failure on Fedora 28 In-Reply-To: References: Message-ID: Can you build with LOG=trace to try and see the actual command that is failing? David On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: > Hi, > > 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >> Hello, >> >> Your assessment is looks correct so far. At this point, one would have to >> start debugging the image to figure out what's wrong with it. Are you able >> to run the exploded image in >> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? > > It works. So I wonder why invalid image was built. > > ``` > $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version > openjdk 11-internal 2018-09-25 > OpenJDK Runtime Environment (fastdebug build 11-internal+0-adhoc.ysuenaga.jdk) > OpenJDK 64-Bit Server VM (fastdebug build > 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) > ``` > > I'm waiting for Severin's evaluation :-) > > > Thanks, > > Yasumasa > > >> Has anyone at Redhat built successfully on Fedora 28 yet? >> >> /Erik >> >> >> >> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>> >>> Hi all, >>> >>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>> following: >>> >>> ``` >>> [ysuenaga at fc28 jdk]$ make images >>> Building target 'images' in configuration >>> 'linux-x86_64-normal-server-fastdebug' >>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>> Error 1 >>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>> >>> ERROR: Build failed for target 'images' in configuration >>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error 2 >>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 >>> ``` >>> >>> It seems "interim-image" is not valid: >>> >>> ``` >>> [ysuenaga at fc28 jdk]$ >>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>> --version >>> Error occurred during initialization of VM >>> java/lang/NoClassDefFoundError: java/lang/Object >>> ``` >>> >>> It can succeed on Fedora 27. So I think it causes by OS. >>> I've disabled SELinux, and warnings / errors are nothing in `journalctl >>> -a`. >>> >>> Do you have any idea to resolve this issue? >>> >>> >>> Thanks, >>> >>> Yasumasa >> >> From yasuenag at gmail.com Wed May 9 02:09:40 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 May 2018 11:09:40 +0900 Subject: Build failure on Fedora 28 In-Reply-To: References: Message-ID: Hi David, 2018-05-09 10:48 GMT+09:00 David Holmes : > Can you build with LOG=trace to try and see the actual command that is > failing? I tried it and got following logs. They look good to me. * Creating interim-image + /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 -J-Djlin k.debug=true --module-path /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods --endian little --output /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image --disable-plugin generate-jli-classes --add-modules java.base,java.logging * Command on error: + /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar build.tools.classlist.HelloClasslist Thanks, Yasumasa > David > > > On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >> >> Hi, >> >> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>> >>> Hello, >>> >>> Your assessment is looks correct so far. At this point, one would have to >>> start debugging the image to figure out what's wrong with it. Are you >>> able >>> to run the exploded image in >>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >> >> >> It works. So I wonder why invalid image was built. >> >> ``` >> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >> openjdk 11-internal 2018-09-25 >> OpenJDK Runtime Environment (fastdebug build >> 11-internal+0-adhoc.ysuenaga.jdk) >> OpenJDK 64-Bit Server VM (fastdebug build >> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >> ``` >> >> I'm waiting for Severin's evaluation :-) >> >> >> Thanks, >> >> Yasumasa >> >> >>> Has anyone at Redhat built successfully on Fedora 28 yet? >>> >>> /Erik >>> >>> >>> >>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>> >>>> >>>> Hi all, >>>> >>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>> following: >>>> >>>> ``` >>>> [ysuenaga at fc28 jdk]$ make images >>>> Building target 'images' in configuration >>>> 'linux-x86_64-normal-server-fastdebug' >>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>> Error 1 >>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>> >>>> ERROR: Build failed for target 'images' in configuration >>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>> >>>> No indication of failed target found. >>>> Hint: Try searching the build log for '] Error'. >>>> Hint: See doc/building.html#troubleshooting for assistance. >>>> >>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error >>>> 2 >>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 >>>> ``` >>>> >>>> It seems "interim-image" is not valid: >>>> >>>> ``` >>>> [ysuenaga at fc28 jdk]$ >>>> >>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>> --version >>>> Error occurred during initialization of VM >>>> java/lang/NoClassDefFoundError: java/lang/Object >>>> ``` >>>> >>>> It can succeed on Fedora 27. So I think it causes by OS. >>>> I've disabled SELinux, and warnings / errors are nothing in `journalctl >>>> -a`. >>>> >>>> Do you have any idea to resolve this issue? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>> >>> >>> > From david.holmes at oracle.com Wed May 9 02:17:06 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 May 2018 12:17:06 +1000 Subject: Build failure on Fedora 28 In-Reply-To: References: Message-ID: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: > Hi David, > > 2018-05-09 10:48 GMT+09:00 David Holmes : >> Can you build with LOG=trace to try and see the actual command that is >> failing? > > I tried it and got following logs. They look good to me. Not enough there for me to comment :) > > * Creating interim-image > > + /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink > -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 > -J-Djlin > k.debug=true --module-path > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods > --endian little --output > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image > --disable-plugin generate-jli-classes --add-modules > java.base,java.logging So this seems to produce an interim image that won't run - correct? I'd be scouring the log in the lead up to this to see if anything seems to be unusual. Can you upload the log to cr.openjdk.java.net? Or email me directly? Thanks, David > > * Command on error: > > + /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java > -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw > -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar > build.tools.classlist.HelloClasslist > > Thanks, > > Yasumasa > > >> David >> >> >> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>> >>> Hi, >>> >>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>> >>>> Hello, >>>> >>>> Your assessment is looks correct so far. At this point, one would have to >>>> start debugging the image to figure out what's wrong with it. Are you >>>> able >>>> to run the exploded image in >>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>> >>> >>> It works. So I wonder why invalid image was built. >>> >>> ``` >>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>> openjdk 11-internal 2018-09-25 >>> OpenJDK Runtime Environment (fastdebug build >>> 11-internal+0-adhoc.ysuenaga.jdk) >>> OpenJDK 64-Bit Server VM (fastdebug build >>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>> ``` >>> >>> I'm waiting for Severin's evaluation :-) >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>> >>>> /Erik >>>> >>>> >>>> >>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>> >>>>> >>>>> Hi all, >>>>> >>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>>> following: >>>>> >>>>> ``` >>>>> [ysuenaga at fc28 jdk]$ make images >>>>> Building target 'images' in configuration >>>>> 'linux-x86_64-normal-server-fastdebug' >>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>> Error 1 >>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>> >>>>> ERROR: Build failed for target 'images' in configuration >>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>> >>>>> No indication of failed target found. >>>>> Hint: Try searching the build log for '] Error'. >>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>> >>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] Error >>>>> 2 >>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error 2 >>>>> ``` >>>>> >>>>> It seems "interim-image" is not valid: >>>>> >>>>> ``` >>>>> [ysuenaga at fc28 jdk]$ >>>>> >>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>> --version >>>>> Error occurred during initialization of VM >>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>> ``` >>>>> >>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>> I've disabled SELinux, and warnings / errors are nothing in `journalctl >>>>> -a`. >>>>> >>>>> Do you have any idea to resolve this issue? >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>> >>>> >>>> >> From yasuenag at gmail.com Wed May 9 03:46:47 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 May 2018 12:46:47 +0900 Subject: Build failure on Fedora 28 In-Reply-To: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: Hi David, I uploaded build.log: http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log Is it enough? Thanks, Yasumasa 2018-05-09 11:17 GMT+09:00 David Holmes : > On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> 2018-05-09 10:48 GMT+09:00 David Holmes : >>> >>> Can you build with LOG=trace to try and see the actual command that is >>> failing? >> >> >> I tried it and got following logs. They look good to me. > > > Not enough there for me to comment :) >> >> >> * Creating interim-image >> >> + >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >> -J-Djlin >> k.debug=true --module-path >> >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >> --endian little --output >> >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >> --disable-plugin generate-jli-classes --add-modules >> java.base,java.logging > > > So this seems to produce an interim image that won't run - correct? I'd be > scouring the log in the lead up to this to see if anything seems to be > unusual. Can you upload the log to cr.openjdk.java.net? Or email me > directly? > > Thanks, > David > > >> >> * Command on error: >> >> + >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >> >> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >> >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >> build.tools.classlist.HelloClasslist >> >> Thanks, >> >> Yasumasa >> >> >>> David >>> >>> >>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>> >>>> >>>> Hi, >>>> >>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>> >>>>> >>>>> Hello, >>>>> >>>>> Your assessment is looks correct so far. At this point, one would have >>>>> to >>>>> start debugging the image to figure out what's wrong with it. Are you >>>>> able >>>>> to run the exploded image in >>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>> >>>> >>>> >>>> It works. So I wonder why invalid image was built. >>>> >>>> ``` >>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>> openjdk 11-internal 2018-09-25 >>>> OpenJDK Runtime Environment (fastdebug build >>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>> OpenJDK 64-Bit Server VM (fastdebug build >>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>> ``` >>>> >>>> I'm waiting for Severin's evaluation :-) >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>> >>>>> /Erik >>>>> >>>>> >>>>> >>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>>>> following: >>>>>> >>>>>> ``` >>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>> Building target 'images' in configuration >>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>> >>>>>> >>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>> Error 1 >>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>> >>>>>> ERROR: Build failed for target 'images' in configuration >>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>> >>>>>> No indication of failed target found. >>>>>> Hint: Try searching the build log for '] Error'. >>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>> >>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>> Error >>>>>> 2 >>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error >>>>>> 2 >>>>>> ``` >>>>>> >>>>>> It seems "interim-image" is not valid: >>>>>> >>>>>> ``` >>>>>> [ysuenaga at fc28 jdk]$ >>>>>> >>>>>> >>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>> --version >>>>>> Error occurred during initialization of VM >>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>> ``` >>>>>> >>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>> `journalctl >>>>>> -a`. >>>>>> >>>>>> Do you have any idea to resolve this issue? >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>> >>>>> >>>>> >>>>> >>> > From thomas.stuefe at gmail.com Wed May 9 04:59:39 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 May 2018 06:59:39 +0200 Subject: RFR(xxs): 8202822: Add .git to .hgignore Message-ID: Hi all, could we add .git to .hgignore? Bug: https://bugs.openjdk.java.net/browse/JDK-8202822 Diff: --- a/.hgignore Wed May 09 06:51:41 2018 +0200 +++ b/.hgignore Wed May 09 06:55:10 2018 +0200 @@ -13,3 +13,4 @@ NashornProfile.txt .*/JTreport/.* .*/JTwork/.* +.*/.git/.* Thanks! Thomas From thomas.stuefe at gmail.com Wed May 9 05:36:36 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 May 2018 07:36:36 +0200 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: Hi, sorry for quick dropping in. Just wanted to remark that it may be useful to run with --with-build-jdk= with being a good working jdk you trust. It must be close to the source you build - I usually use a clean current release build. This excludes build errors which may be caused by the JDK you are building being faulty (the build uses itself in places). ..Thomas On Wed, May 9, 2018 at 5:46 AM, Yasumasa Suenaga wrote: > Hi David, > > I uploaded build.log: > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log > > Is it enough? > > > Thanks, > > Yasumasa > > > > 2018-05-09 11:17 GMT+09:00 David Holmes : >> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> >>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>> >>>> Can you build with LOG=trace to try and see the actual command that is >>>> failing? >>> >>> >>> I tried it and got following logs. They look good to me. >> >> >> Not enough there for me to comment :) >>> >>> >>> * Creating interim-image >>> >>> + >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>> -J-Djlin >>> k.debug=true --module-path >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>> --endian little --output >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>> --disable-plugin generate-jli-classes --add-modules >>> java.base,java.logging >> >> >> So this seems to produce an interim image that won't run - correct? I'd be >> scouring the log in the lead up to this to see if anything seems to be >> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >> directly? >> >> Thanks, >> David >> >> >>> >>> * Command on error: >>> >>> + >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>> >>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>> build.tools.classlist.HelloClasslist >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> David >>>> >>>> >>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> Your assessment is looks correct so far. At this point, one would have >>>>>> to >>>>>> start debugging the image to figure out what's wrong with it. Are you >>>>>> able >>>>>> to run the exploded image in >>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>> >>>>> >>>>> >>>>> It works. So I wonder why invalid image was built. >>>>> >>>>> ``` >>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>>> openjdk 11-internal 2018-09-25 >>>>> OpenJDK Runtime Environment (fastdebug build >>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>> ``` >>>>> >>>>> I'm waiting for Severin's evaluation :-) >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> >>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>>>>> following: >>>>>>> >>>>>>> ``` >>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>> Building target 'images' in configuration >>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>> Error 1 >>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>> >>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>> >>>>>>> No indication of failed target found. >>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>> >>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>> Error >>>>>>> 2 >>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error >>>>>>> 2 >>>>>>> ``` >>>>>>> >>>>>>> It seems "interim-image" is not valid: >>>>>>> >>>>>>> ``` >>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>> >>>>>>> >>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>> --version >>>>>>> Error occurred during initialization of VM >>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>> ``` >>>>>>> >>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>> `journalctl >>>>>>> -a`. >>>>>>> >>>>>>> Do you have any idea to resolve this issue? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Wed May 9 06:31:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 May 2018 16:31:02 +1000 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: On 9/05/2018 1:46 PM, Yasumasa Suenaga wrote: > Hi David, > > I uploaded build.log: > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log > > Is it enough? It's all there is. :) But no errors. It all is fine right up to the part that it isn't. Can you run: /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java with full logging enabled - -Xlog:all=trace (I think that's the right syntax). It may show how far the VM gets before something goes wrong. Thanks, David > > Thanks, > > Yasumasa > > > > 2018-05-09 11:17 GMT+09:00 David Holmes : >> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> >>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>> >>>> Can you build with LOG=trace to try and see the actual command that is >>>> failing? >>> >>> >>> I tried it and got following logs. They look good to me. >> >> >> Not enough there for me to comment :) >>> >>> >>> * Creating interim-image >>> >>> + >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>> -J-Djlin >>> k.debug=true --module-path >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>> --endian little --output >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>> --disable-plugin generate-jli-classes --add-modules >>> java.base,java.logging >> >> >> So this seems to produce an interim image that won't run - correct? I'd be >> scouring the log in the lead up to this to see if anything seems to be >> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >> directly? >> >> Thanks, >> David >> >> >>> >>> * Command on error: >>> >>> + >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>> >>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>> build.tools.classlist.HelloClasslist >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> David >>>> >>>> >>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>> >>>>>> >>>>>> Hello, >>>>>> >>>>>> Your assessment is looks correct so far. At this point, one would have >>>>>> to >>>>>> start debugging the image to figure out what's wrong with it. Are you >>>>>> able >>>>>> to run the exploded image in >>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>> >>>>> >>>>> >>>>> It works. So I wonder why invalid image was built. >>>>> >>>>> ``` >>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>>> openjdk 11-internal 2018-09-25 >>>>> OpenJDK Runtime Environment (fastdebug build >>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>> ``` >>>>> >>>>> I'm waiting for Severin's evaluation :-) >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> >>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>>>>> following: >>>>>>> >>>>>>> ``` >>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>> Building target 'images' in configuration >>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>> Error 1 >>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>> >>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>> >>>>>>> No indication of failed target found. >>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>> >>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>> Error >>>>>>> 2 >>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error >>>>>>> 2 >>>>>>> ``` >>>>>>> >>>>>>> It seems "interim-image" is not valid: >>>>>>> >>>>>>> ``` >>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>> >>>>>>> >>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>> --version >>>>>>> Error occurred during initialization of VM >>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>> ``` >>>>>>> >>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>> `journalctl >>>>>>> -a`. >>>>>>> >>>>>>> Do you have any idea to resolve this issue? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From yasuenag at gmail.com Wed May 9 07:19:58 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 May 2018 16:19:58 +0900 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: Hi David, I uploaded trace log: http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/trace-all.log It seems to open module file, but any class is not loaded from there. Thanks, Yasumasa 2018-05-09 15:31 GMT+09:00 David Holmes : > On 9/05/2018 1:46 PM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> I uploaded build.log: >> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >> >> Is it enough? > > > It's all there is. :) But no errors. It all is fine right up to the part > that it isn't. > > Can you run: > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java > > with full logging enabled - -Xlog:all=trace (I think that's the right > syntax). It may show how far the VM gets before something goes wrong. > > Thanks, > David > > >> >> Thanks, >> >> Yasumasa >> >> >> >> 2018-05-09 11:17 GMT+09:00 David Holmes : >>> >>> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>>> >>>> >>>> Hi David, >>>> >>>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>>> >>>>> >>>>> Can you build with LOG=trace to try and see the actual command that is >>>>> failing? >>>> >>>> >>>> >>>> I tried it and got following logs. They look good to me. >>> >>> >>> >>> Not enough there for me to comment :) >>>> >>>> >>>> >>>> * Creating interim-image >>>> >>>> + >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>>> -J-Djlin >>>> k.debug=true --module-path >>>> >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>>> --endian little --output >>>> >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>>> --disable-plugin generate-jli-classes --add-modules >>>> java.base,java.logging >>> >>> >>> >>> So this seems to produce an interim image that won't run - correct? I'd >>> be >>> scouring the log in the lead up to this to see if anything seems to be >>> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >>> directly? >>> >>> Thanks, >>> David >>> >>> >>>> >>>> * Command on error: >>>> >>>> + >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>> >>>> >>>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>>> >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>>> build.tools.classlist.HelloClasslist >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> David >>>>> >>>>> >>>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Your assessment is looks correct so far. At this point, one would >>>>>>> have >>>>>>> to >>>>>>> start debugging the image to figure out what's wrong with it. Are you >>>>>>> able >>>>>>> to run the exploded image in >>>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It works. So I wonder why invalid image was built. >>>>>> >>>>>> ``` >>>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>>>> openjdk 11-internal 2018-09-25 >>>>>> OpenJDK Runtime Environment (fastdebug build >>>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>>> ``` >>>>>> >>>>>> I'm waiting for Severin's evaluation :-) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed >>>>>>>> as >>>>>>>> following: >>>>>>>> >>>>>>>> ``` >>>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>>> Building target 'images' in configuration >>>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>>> Error 1 >>>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>>> >>>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>>> >>>>>>>> No indication of failed target found. >>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>>> >>>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>>> Error >>>>>>>> 2 >>>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] >>>>>>>> Error >>>>>>>> 2 >>>>>>>> ``` >>>>>>>> >>>>>>>> It seems "interim-image" is not valid: >>>>>>>> >>>>>>>> ``` >>>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>>> --version >>>>>>>> Error occurred during initialization of VM >>>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>>> ``` >>>>>>>> >>>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>>> `journalctl >>>>>>>> -a`. >>>>>>>> >>>>>>>> Do you have any idea to resolve this issue? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Wed May 9 07:26:58 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 May 2018 17:26:58 +1000 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: On 9/05/2018 5:19 PM, Yasumasa Suenaga wrote: > Hi David, > > I uploaded trace log: > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/trace-all.log > > It seems to open module file, but any class is not loaded from there. The last line I see is: [0.266s][trace][gc,tlab ] TLAB: fill thread: 0x00007fd7c801f800 [id: 17487] desired_size: 491KB slow allocs: 0 refill waste: 7864B alloc: 0.99999 2048KB refills: 1 waste 0.0% gc: 0B slow: 0B fast: 0B is that right? Seems we just have a silent abort during VM initialization. This seems quite bizarre. Can you run it in the debugger? Thanks, David > > Thanks, > > Yasumasa > > > > 2018-05-09 15:31 GMT+09:00 David Holmes : >> On 9/05/2018 1:46 PM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> >>> I uploaded build.log: >>> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >>> >>> Is it enough? >> >> >> It's all there is. :) But no errors. It all is fine right up to the part >> that it isn't. >> >> Can you run: >> >> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >> >> with full logging enabled - -Xlog:all=trace (I think that's the right >> syntax). It may show how far the VM gets before something goes wrong. >> >> Thanks, >> David >> >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> 2018-05-09 11:17 GMT+09:00 David Holmes : >>>> >>>> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>>>> >>>>>> >>>>>> Can you build with LOG=trace to try and see the actual command that is >>>>>> failing? >>>>> >>>>> >>>>> >>>>> I tried it and got following logs. They look good to me. >>>> >>>> >>>> >>>> Not enough there for me to comment :) >>>>> >>>>> >>>>> >>>>> * Creating interim-image >>>>> >>>>> + >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>>>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>>>> -J-Djlin >>>>> k.debug=true --module-path >>>>> >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>>>> --endian little --output >>>>> >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>>>> --disable-plugin generate-jli-classes --add-modules >>>>> java.base,java.logging >>>> >>>> >>>> >>>> So this seems to produce an interim image that won't run - correct? I'd >>>> be >>>> scouring the log in the lead up to this to see if anything seems to be >>>> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >>>> directly? >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> * Command on error: >>>>> >>>>> + >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>> >>>>> >>>>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>>>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>>>> >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>>>> build.tools.classlist.HelloClasslist >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Your assessment is looks correct so far. At this point, one would >>>>>>>> have >>>>>>>> to >>>>>>>> start debugging the image to figure out what's wrong with it. Are you >>>>>>>> able >>>>>>>> to run the exploded image in >>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It works. So I wonder why invalid image was built. >>>>>>> >>>>>>> ``` >>>>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>>>>> openjdk 11-internal 2018-09-25 >>>>>>> OpenJDK Runtime Environment (fastdebug build >>>>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>>>> ``` >>>>>>> >>>>>>> I'm waiting for Severin's evaluation :-) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed >>>>>>>>> as >>>>>>>>> following: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>>>> Building target 'images' in configuration >>>>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>>>> Error 1 >>>>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>>>> >>>>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>>>> >>>>>>>>> No indication of failed target found. >>>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>>>> >>>>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>>>> Error >>>>>>>>> 2 >>>>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] >>>>>>>>> Error >>>>>>>>> 2 >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> It seems "interim-image" is not valid: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>>>> --version >>>>>>>>> Error occurred during initialization of VM >>>>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>>>> `journalctl >>>>>>>>> -a`. >>>>>>>>> >>>>>>>>> Do you have any idea to resolve this issue? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> From yasuenag at gmail.com Wed May 9 07:40:33 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 May 2018 16:40:33 +0900 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: Hi David, 2018-05-09 16:26 GMT+09:00 David Holmes : > On 9/05/2018 5:19 PM, Yasumasa Suenaga wrote: >> >> Hi David, >> >> I uploaded trace log: >> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/trace-all.log >> >> It seems to open module file, but any class is not loaded from there. > > > The last line I see is: > > [0.266s][trace][gc,tlab ] TLAB: fill thread: 0x00007fd7c801f800 > [id: 17487] desired_size: 491KB slow allocs: 0 refill waste: 7864B alloc: > 0.99999 2048KB refills: 1 waste 0.0% gc: 0B slow: 0B fast: 0B > > is that right? Seems we just have a silent abort during VM initialization. > This seems quite bizarre. Yes, I guess VM was aborted because it could not load java/lang/Object. http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021999.html > Can you run it in the debugger? No, I ran `./java -Xlog:all=trace:/home/ysuenaga/trace-all.log --version` Thanks, Yasumasa > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> >> 2018-05-09 15:31 GMT+09:00 David Holmes : >>> >>> On 9/05/2018 1:46 PM, Yasumasa Suenaga wrote: >>>> >>>> >>>> Hi David, >>>> >>>> I uploaded build.log: >>>> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >>>> >>>> Is it enough? >>> >>> >>> >>> It's all there is. :) But no errors. It all is fine right up to the part >>> that it isn't. >>> >>> Can you run: >>> >>> >>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>> >>> with full logging enabled - -Xlog:all=trace (I think that's the right >>> syntax). It may show how far the VM gets before something goes wrong. >>> >>> Thanks, >>> David >>> >>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> 2018-05-09 11:17 GMT+09:00 David Holmes : >>>>> >>>>> >>>>> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi David, >>>>>> >>>>>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>>>>> >>>>>>> >>>>>>> >>>>>>> Can you build with LOG=trace to try and see the actual command that >>>>>>> is >>>>>>> failing? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I tried it and got following logs. They look good to me. >>>>> >>>>> >>>>> >>>>> >>>>> Not enough there for me to comment :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> * Creating interim-image >>>>>> >>>>>> + >>>>>> >>>>>> >>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>>>>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>>>>> -J-Djlin >>>>>> k.debug=true --module-path >>>>>> >>>>>> >>>>>> >>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>>>>> --endian little --output >>>>>> >>>>>> >>>>>> >>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>>>>> --disable-plugin generate-jli-classes --add-modules >>>>>> java.base,java.logging >>>>> >>>>> >>>>> >>>>> >>>>> So this seems to produce an interim image that won't run - correct? I'd >>>>> be >>>>> scouring the log in the lead up to this to see if anything seems to be >>>>> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >>>>> directly? >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> >>>>>> * Command on error: >>>>>> >>>>>> + >>>>>> >>>>>> >>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>> >>>>>> >>>>>> >>>>>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>>>>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>>>>> >>>>>> >>>>>> >>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>>>>> build.tools.classlist.HelloClasslist >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Your assessment is looks correct so far. At this point, one would >>>>>>>>> have >>>>>>>>> to >>>>>>>>> start debugging the image to figure out what's wrong with it. Are >>>>>>>>> you >>>>>>>>> able >>>>>>>>> to run the exploded image in >>>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It works. So I wonder why invalid image was built. >>>>>>>> >>>>>>>> ``` >>>>>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java >>>>>>>> --version >>>>>>>> openjdk 11-internal 2018-09-25 >>>>>>>> OpenJDK Runtime Environment (fastdebug build >>>>>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>>>>> ``` >>>>>>>> >>>>>>>> I'm waiting for Severin's evaluation :-) >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed >>>>>>>>>> as >>>>>>>>>> following: >>>>>>>>>> >>>>>>>>>> ``` >>>>>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>>>>> Building target 'images' in configuration >>>>>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>>>>> Error 1 >>>>>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>>>>> >>>>>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>>>>> >>>>>>>>>> No indication of failed target found. >>>>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>>>>> >>>>>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>>>>> Error >>>>>>>>>> 2 >>>>>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] >>>>>>>>>> Error >>>>>>>>>> 2 >>>>>>>>>> ``` >>>>>>>>>> >>>>>>>>>> It seems "interim-image" is not valid: >>>>>>>>>> >>>>>>>>>> ``` >>>>>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>>>>> --version >>>>>>>>>> Error occurred during initialization of VM >>>>>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>>>>> ``` >>>>>>>>>> >>>>>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>>>>> `journalctl >>>>>>>>>> -a`. >>>>>>>>>> >>>>>>>>>> Do you have any idea to resolve this issue? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> > From david.holmes at oracle.com Wed May 9 07:43:47 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 May 2018 17:43:47 +1000 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: <3c85e70b-cfea-e1bd-6c14-6124f984ce78@oracle.com> On 9/05/2018 5:40 PM, Yasumasa Suenaga wrote: > Hi David, > > 2018-05-09 16:26 GMT+09:00 David Holmes : >> On 9/05/2018 5:19 PM, Yasumasa Suenaga wrote: >>> >>> Hi David, >>> >>> I uploaded trace log: >>> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/trace-all.log >>> >>> It seems to open module file, but any class is not loaded from there. >> >> >> The last line I see is: >> >> [0.266s][trace][gc,tlab ] TLAB: fill thread: 0x00007fd7c801f800 >> [id: 17487] desired_size: 491KB slow allocs: 0 refill waste: 7864B alloc: >> 0.99999 2048KB refills: 1 waste 0.0% gc: 0B slow: 0B fast: 0B >> >> is that right? Seems we just have a silent abort during VM initialization. >> This seems quite bizarre. > > Yes, I guess VM was aborted because it could not load java/lang/Object. > http://mail.openjdk.java.net/pipermail/build-dev/2018-May/021999.html Ah so you still see: Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object I'm surprised there isn't more in the log prior to reaching that point. David ----- > >> Can you run it in the debugger? > > No, I ran `./java -Xlog:all=trace:/home/ysuenaga/trace-all.log --version` > > > Thanks, > > Yasumasa > > >> Thanks, >> David >> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> 2018-05-09 15:31 GMT+09:00 David Holmes : >>>> >>>> On 9/05/2018 1:46 PM, Yasumasa Suenaga wrote: >>>>> >>>>> >>>>> Hi David, >>>>> >>>>> I uploaded build.log: >>>>> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >>>>> >>>>> Is it enough? >>>> >>>> >>>> >>>> It's all there is. :) But no errors. It all is fine right up to the part >>>> that it isn't. >>>> >>>> Can you run: >>>> >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>> >>>> with full logging enabled - -Xlog:all=trace (I think that's the right >>>> syntax). It may show how far the VM gets before something goes wrong. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> >>>>> 2018-05-09 11:17 GMT+09:00 David Holmes : >>>>>> >>>>>> >>>>>> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Can you build with LOG=trace to try and see the actual command that >>>>>>>> is >>>>>>>> failing? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I tried it and got following logs. They look good to me. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Not enough there for me to comment :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Creating interim-image >>>>>>> >>>>>>> + >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>>>>>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>>>>>> -J-Djlin >>>>>>> k.debug=true --module-path >>>>>>> >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>>>>>> --endian little --output >>>>>>> >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>>>>>> --disable-plugin generate-jli-classes --add-modules >>>>>>> java.base,java.logging >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> So this seems to produce an interim image that won't run - correct? I'd >>>>>> be >>>>>> scouring the log in the lead up to this to see if anything seems to be >>>>>> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >>>>>> directly? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> * Command on error: >>>>>>> >>>>>>> + >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>> >>>>>>> >>>>>>> >>>>>>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>>>>>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>>>>>> >>>>>>> >>>>>>> >>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>>>>>> build.tools.classlist.HelloClasslist >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Your assessment is looks correct so far. At this point, one would >>>>>>>>>> have >>>>>>>>>> to >>>>>>>>>> start debugging the image to figure out what's wrong with it. Are >>>>>>>>>> you >>>>>>>>>> able >>>>>>>>>> to run the exploded image in >>>>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It works. So I wonder why invalid image was built. >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java >>>>>>>>> --version >>>>>>>>> openjdk 11-internal 2018-09-25 >>>>>>>>> OpenJDK Runtime Environment (fastdebug build >>>>>>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>>>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>>>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> I'm waiting for Severin's evaluation :-) >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>>>>>> >>>>>>>>>> /Erik >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed >>>>>>>>>>> as >>>>>>>>>>> following: >>>>>>>>>>> >>>>>>>>>>> ``` >>>>>>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>>>>>> Building target 'images' in configuration >>>>>>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>>>>>> Error 1 >>>>>>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>>>>>> >>>>>>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>>>>>> >>>>>>>>>>> No indication of failed target found. >>>>>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>>>>>> >>>>>>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>>>>>> Error >>>>>>>>>>> 2 >>>>>>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] >>>>>>>>>>> Error >>>>>>>>>>> 2 >>>>>>>>>>> ``` >>>>>>>>>>> >>>>>>>>>>> It seems "interim-image" is not valid: >>>>>>>>>>> >>>>>>>>>>> ``` >>>>>>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>>>>>> --version >>>>>>>>>>> Error occurred during initialization of VM >>>>>>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>>>>>> ``` >>>>>>>>>>> >>>>>>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>>>>>> `journalctl >>>>>>>>>>> -a`. >>>>>>>>>>> >>>>>>>>>>> Do you have any idea to resolve this issue? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >> From yasuenag at gmail.com Wed May 9 08:03:40 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 May 2018 17:03:40 +0900 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: Hi Thomas, Build was succeeded with --with-build-jdk= configure option, but JDK image does not work as below: ``` [ysuenaga at f4i jdk]$ ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java --version Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object ``` Thanks, Yasumasa 2018-05-09 14:36 GMT+09:00 Thomas St?fe : > Hi, > > sorry for quick dropping in. Just wanted to remark that it may be > useful to run with --with-build-jdk= with being a good working > jdk you trust. It must be close to the source you build - I usually > use a clean current release build. > > This excludes build errors which may be caused by the JDK you are > building being faulty (the build uses itself in places). > > ..Thomas > > On Wed, May 9, 2018 at 5:46 AM, Yasumasa Suenaga wrote: >> Hi David, >> >> I uploaded build.log: >> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >> >> Is it enough? >> >> >> Thanks, >> >> Yasumasa >> >> >> >> 2018-05-09 11:17 GMT+09:00 David Holmes : >>> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>>> >>>> Hi David, >>>> >>>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>>> >>>>> Can you build with LOG=trace to try and see the actual command that is >>>>> failing? >>>> >>>> >>>> I tried it and got following logs. They look good to me. >>> >>> >>> Not enough there for me to comment :) >>>> >>>> >>>> * Creating interim-image >>>> >>>> + >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>>> -J-Djlin >>>> k.debug=true --module-path >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>>> --endian little --output >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>>> --disable-plugin generate-jli-classes --add-modules >>>> java.base,java.logging >>> >>> >>> So this seems to produce an interim image that won't run - correct? I'd be >>> scouring the log in the lead up to this to see if anything seems to be >>> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >>> directly? >>> >>> Thanks, >>> David >>> >>> >>>> >>>> * Command on error: >>>> >>>> + >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>> >>>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>>> >>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>>> build.tools.classlist.HelloClasslist >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>>> David >>>>> >>>>> >>>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Your assessment is looks correct so far. At this point, one would have >>>>>>> to >>>>>>> start debugging the image to figure out what's wrong with it. Are you >>>>>>> able >>>>>>> to run the exploded image in >>>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>>> >>>>>> >>>>>> >>>>>> It works. So I wonder why invalid image was built. >>>>>> >>>>>> ``` >>>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>>>> openjdk 11-internal 2018-09-25 >>>>>> OpenJDK Runtime Environment (fastdebug build >>>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>>> ``` >>>>>> >>>>>> I'm waiting for Severin's evaluation :-) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>>>>>> following: >>>>>>>> >>>>>>>> ``` >>>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>>> Building target 'images' in configuration >>>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>>> >>>>>>>> >>>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>>> Error 1 >>>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>>> >>>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>>> >>>>>>>> No indication of failed target found. >>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>>> >>>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>>> Error >>>>>>>> 2 >>>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error >>>>>>>> 2 >>>>>>>> ``` >>>>>>>> >>>>>>>> It seems "interim-image" is not valid: >>>>>>>> >>>>>>>> ``` >>>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>>> >>>>>>>> >>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>>> --version >>>>>>>> Error occurred during initialization of VM >>>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>>> ``` >>>>>>>> >>>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>>> `journalctl >>>>>>>> -a`. >>>>>>>> >>>>>>>> Do you have any idea to resolve this issue? >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> From thomas.stuefe at gmail.com Wed May 9 08:08:07 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 May 2018 10:08:07 +0200 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: Hi Yasumasa, On Wed, May 9, 2018 at 10:03 AM, Yasumasa Suenaga wrote: > Hi Thomas, > > Build was succeeded with --with-build-jdk= configure > option, but JDK image does not work as below: > > ``` > [ysuenaga at f4i jdk]$ > ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java > --version > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/Object > ``` > Yes, I expected that. The intent was only to make it easier to analyze the crash. I usually prefer that to analyzing build logs to find the crashing vm call. Maybe it is just a matter of preference. I know some people actually prefer the crashes during the build since they consider the build to be a good first-line stress test. Thanks, Thomas > > Thanks, > > Yasumasa > > > 2018-05-09 14:36 GMT+09:00 Thomas St?fe : >> Hi, >> >> sorry for quick dropping in. Just wanted to remark that it may be >> useful to run with --with-build-jdk= with being a good working >> jdk you trust. It must be close to the source you build - I usually >> use a clean current release build. >> >> This excludes build errors which may be caused by the JDK you are >> building being faulty (the build uses itself in places). >> >> ..Thomas >> >> On Wed, May 9, 2018 at 5:46 AM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> I uploaded build.log: >>> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >>> >>> Is it enough? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> 2018-05-09 11:17 GMT+09:00 David Holmes : >>>> On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >>>>> >>>>> Hi David, >>>>> >>>>> 2018-05-09 10:48 GMT+09:00 David Holmes : >>>>>> >>>>>> Can you build with LOG=trace to try and see the actual command that is >>>>>> failing? >>>>> >>>>> >>>>> I tried it and got following logs. They look good to me. >>>> >>>> >>>> Not enough there for me to comment :) >>>>> >>>>> >>>>> * Creating interim-image >>>>> >>>>> + >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/jdk/bin/jlink >>>>> -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 >>>>> -J-Djlin >>>>> k.debug=true --module-path >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-jmods >>>>> --endian little --output >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image >>>>> --disable-plugin generate-jli-classes --add-modules >>>>> java.base,java.logging >>>> >>>> >>>> So this seems to produce an interim image that won't run - correct? I'd be >>>> scouring the log in the lead up to this to see if anything seems to be >>>> unusual. Can you upload the log to cr.openjdk.java.net? Or email me >>>> directly? >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> * Command on error: >>>>> >>>>> + >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>> >>>>> -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist.raw >>>>> -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >>>>> >>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/classlist.jar >>>>> build.tools.classlist.HelloClasslist >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> David >>>>>> >>>>>> >>>>>> On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> 2018-05-09 0:27 GMT+09:00 Erik Joelsson : >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Your assessment is looks correct so far. At this point, one would have >>>>>>>> to >>>>>>>> start debugging the image to figure out what's wrong with it. Are you >>>>>>>> able >>>>>>>> to run the exploded image in >>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java? >>>>>>> >>>>>>> >>>>>>> >>>>>>> It works. So I wonder why invalid image was built. >>>>>>> >>>>>>> ``` >>>>>>> $ ./build/linux-x86_64-normal-server-fastdebug/jdk/bin/java --version >>>>>>> openjdk 11-internal 2018-09-25 >>>>>>> OpenJDK Runtime Environment (fastdebug build >>>>>>> 11-internal+0-adhoc.ysuenaga.jdk) >>>>>>> OpenJDK 64-Bit Server VM (fastdebug build >>>>>>> 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >>>>>>> ``` >>>>>>> >>>>>>> I'm waiting for Severin's evaluation :-) >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>>> Has anyone at Redhat built successfully on Fedora 28 yet? >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2018-05-08 06:42, Yasumasa Suenaga wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, but it failed as >>>>>>>>> following: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> [ysuenaga at fc28 jdk]$ make images >>>>>>>>> Building target 'images' in configuration >>>>>>>>> 'linux-x86_64-normal-server-fastdebug' >>>>>>>>> gmake[3]: *** [GenerateLinkOptData.gmk:64: >>>>>>>>> >>>>>>>>> >>>>>>>>> /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server-fastdebug/support/link_opt/classlist] >>>>>>>>> Error 1 >>>>>>>>> gmake[2]: *** [make/Main.gmk:448: generate-link-opt-data] Error 2 >>>>>>>>> >>>>>>>>> ERROR: Build failed for target 'images' in configuration >>>>>>>>> 'linux-x86_64-normal-server-fastdebug' (exit code 2) >>>>>>>>> >>>>>>>>> No indication of failed target found. >>>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>>> Hint: See doc/building.html#troubleshooting for assistance. >>>>>>>>> >>>>>>>>> make[1]: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >>>>>>>>> Error >>>>>>>>> 2 >>>>>>>>> make: *** [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: images] Error >>>>>>>>> 2 >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> It seems "interim-image" is not valid: >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> [ysuenaga at fc28 jdk]$ >>>>>>>>> >>>>>>>>> >>>>>>>>> ./build/linux-x86_64-normal-server-fastdebug/support/interim-image/bin/java >>>>>>>>> --version >>>>>>>>> Error occurred during initialization of VM >>>>>>>>> java/lang/NoClassDefFoundError: java/lang/Object >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> It can succeed on Fedora 27. So I think it causes by OS. >>>>>>>>> I've disabled SELinux, and warnings / errors are nothing in >>>>>>>>> `journalctl >>>>>>>>> -a`. >>>>>>>>> >>>>>>>>> Do you have any idea to resolve this issue? >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> From sgehwolf at redhat.com Wed May 9 08:22:18 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 09 May 2018 10:22:18 +0200 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> Message-ID: <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> Hi, Note that slowdebug builds work: $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version openjdk version "11-internal" 2018-09-25 OpenJDK Runtime Environment (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs) OpenJDK 64-Bit Server VM (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs, mixed mode) In summary we have: * Build fails with fastdebug/release debug config (-O3) * Build succeeds with slowdebug (-O0) * F28 has GCC 8 * Older GCC-based builds continue to work for fastdebug/release config * JDK 10.0.1 builds fine with GCC 8. So far showing all symptoms of either a GCC bug or some UB in recent OpenJDK code which breaks with new optimizations done in GCC 8. I'll continue to investigate what it is... Cheers, Severin On Wed, 2018-05-09 at 17:03 +0900, Yasumasa Suenaga wrote: > Hi Thomas, > > Build was succeeded with --with-build-jdk= > configure > option, but JDK image does not work as below: > > ``` > [ysuenaga at f4i jdk]$ > ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java > --version > Error occurred during initialization of VM > java/lang/NoClassDefFoundError: java/lang/Object > ``` > > > Thanks, > > Yasumasa > > > 2018-05-09 14:36 GMT+09:00 Thomas St?fe : > > Hi, > > > > sorry for quick dropping in. Just wanted to remark that it may be > > useful to run with --with-build-jdk= with being a good > > working > > jdk you trust. It must be close to the source you build - I usually > > use a clean current release build. > > > > This excludes build errors which may be caused by the JDK you are > > building being faulty (the build uses itself in places). > > > > ..Thomas > > > > On Wed, May 9, 2018 at 5:46 AM, Yasumasa Suenaga > m> wrote: > > > Hi David, > > > > > > I uploaded build.log: > > > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log > > > > > > Is it enough? > > > > > > > > > Thanks, > > > > > > Yasumasa > > > > > > > > > > > > 2018-05-09 11:17 GMT+09:00 David Holmes > > > : > > > > On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: > > > > > > > > > > Hi David, > > > > > > > > > > 2018-05-09 10:48 GMT+09:00 David Holmes > > > > com>: > > > > > > > > > > > > Can you build with LOG=trace to try and see the actual > > > > > > command that is > > > > > > failing? > > > > > > > > > > > > > > > I tried it and got following logs. They look good to me. > > > > > > > > > > > > Not enough there for me to comment :) > > > > > > > > > > > > > > > * Creating interim-image > > > > > > > > > > + > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- > > > > > fastdebug/jdk/bin/jlink > > > > > -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J- > > > > > XX:TieredStopAtLevel=1 > > > > > -J-Djlin > > > > > k.debug=true --module-path > > > > > > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- > > > > > fastdebug/support/interim-jmods > > > > > --endian little --output > > > > > > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- > > > > > fastdebug/support/interim-image > > > > > --disable-plugin generate-jli-classes --add-modules > > > > > java.base,java.logging > > > > > > > > > > > > So this seems to produce an interim image that won't run - > > > > correct? I'd be > > > > scouring the log in the lead up to this to see if anything > > > > seems to be > > > > unusual. Can you upload the log to cr.openjdk.java.net? Or > > > > email me > > > > directly? > > > > > > > > Thanks, > > > > David > > > > > > > > > > > > > > > > > > * Command on error: > > > > > > > > > > + > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- > > > > > fastdebug/support/interim-image/bin/java > > > > > > > > > > -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linu > > > > > x-x86_64-normal-server- > > > > > fastdebug/support/link_opt/classlist.raw > > > > > -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp > > > > > > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- > > > > > fastdebug/support/classlist.jar > > > > > build.tools.classlist.HelloClasslist > > > > > > > > > > Thanks, > > > > > > > > > > Yasumasa > > > > > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > 2018-05-09 0:27 GMT+09:00 Erik Joelsson > > > > > > acle.com>: > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > Your assessment is looks correct so far. At this point, > > > > > > > > one would have > > > > > > > > to > > > > > > > > start debugging the image to figure out what's wrong > > > > > > > > with it. Are you > > > > > > > > able > > > > > > > > to run the exploded image in > > > > > > > > ./build/linux-x86_64-normal-server- > > > > > > > > fastdebug/jdk/bin/java? > > > > > > > > > > > > > > > > > > > > > > > > > > > > It works. So I wonder why invalid image was built. > > > > > > > > > > > > > > ``` > > > > > > > $ ./build/linux-x86_64-normal-server- > > > > > > > fastdebug/jdk/bin/java --version > > > > > > > openjdk 11-internal 2018-09-25 > > > > > > > OpenJDK Runtime Environment (fastdebug build > > > > > > > 11-internal+0-adhoc.ysuenaga.jdk) > > > > > > > OpenJDK 64-Bit Server VM (fastdebug build > > > > > > > 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) > > > > > > > ``` > > > > > > > > > > > > > > I'm waiting for Severin's evaluation :-) > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Yasumasa > > > > > > > > > > > > > > > > > > > > > > Has anyone at Redhat built successfully on Fedora 28 > > > > > > > > yet? > > > > > > > > > > > > > > > > /Erik > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2018-05-08 06:42, Yasumasa Suenaga wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, > > > > > > > > > but it failed as > > > > > > > > > following: > > > > > > > > > > > > > > > > > > ``` > > > > > > > > > [ysuenaga at fc28 jdk]$ make images > > > > > > > > > Building target 'images' in configuration > > > > > > > > > 'linux-x86_64-normal-server-fastdebug' > > > > > > > > > gmake[3]: *** [GenerateLinkOptData.gmk:64: > > > > > > > > > > > > > > > > > > > > > > > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal- > > > > > > > > > server-fastdebug/support/link_opt/classlist] > > > > > > > > > Error 1 > > > > > > > > > gmake[2]: *** [make/Main.gmk:448: generate-link-opt- > > > > > > > > > data] Error 2 > > > > > > > > > > > > > > > > > > ERROR: Build failed for target 'images' in > > > > > > > > > configuration > > > > > > > > > 'linux-x86_64-normal-server-fastdebug' (exit code 2) > > > > > > > > > > > > > > > > > > No indication of failed target found. > > > > > > > > > Hint: Try searching the build log for '] Error'. > > > > > > > > > Hint: See doc/building.html#troubleshooting for > > > > > > > > > assistance. > > > > > > > > > > > > > > > > > > make[1]: *** > > > > > > > > > [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] > > > > > > > > > Error > > > > > > > > > 2 > > > > > > > > > make: *** > > > > > > > > > [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: > > > > > > > > > images] Error > > > > > > > > > 2 > > > > > > > > > ``` > > > > > > > > > > > > > > > > > > It seems "interim-image" is not valid: > > > > > > > > > > > > > > > > > > ``` > > > > > > > > > [ysuenaga at fc28 jdk]$ > > > > > > > > > > > > > > > > > > > > > > > > > > > ./build/linux-x86_64-normal-server- > > > > > > > > > fastdebug/support/interim-image/bin/java > > > > > > > > > --version > > > > > > > > > Error occurred during initialization of VM > > > > > > > > > java/lang/NoClassDefFoundError: java/lang/Object > > > > > > > > > ``` > > > > > > > > > > > > > > > > > > It can succeed on Fedora 27. So I think it causes by > > > > > > > > > OS. > > > > > > > > > I've disabled SELinux, and warnings / errors are > > > > > > > > > nothing in > > > > > > > > > `journalctl > > > > > > > > > -a`. > > > > > > > > > > > > > > > > > > Do you have any idea to resolve this issue? > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Yasumasa > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From alexey.ivanov at oracle.com Wed May 9 14:34:45 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 9 May 2018 15:34:45 +0100 Subject: [11] RFR for JDK-8202544: Hide unused exports in libzip In-Reply-To: References: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> Message-ID: <426447b2-974e-bbf6-e1df-3ce235930252@oracle.com> Any volunteers from core-libs and/or hotspot? Thank you, Alexey On 02/05/2018 13:02, Magnus Ihse Bursie wrote: > Looks good to me, FWIW. > > /Magnus > >> 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : >> >> Hi, >> >> Could you please review the following fix for jdk11? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8202544 >> webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ >> >> The following exported functions in libzip are not used: >> ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read >> >> I removed JNIEXPORT modifiers from these functions. With the fix, they're not exported on Windows; on Linux they're listed as Local rather than Global. >> >> I ran tests, no failures. >> >> >> Thank you in advance. >> >> Regards, >> Alexey From erik.joelsson at oracle.com Wed May 9 15:52:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 May 2018 08:52:40 -0700 Subject: RFR(xxs): 8202822: Add .git to .hgignore In-Reply-To: References: Message-ID: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> Looks good to me. /Erik On 2018-05-08 21:59, Thomas St?fe wrote: > Hi all, > > could we add .git to .hgignore? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202822 > > Diff: > > --- a/.hgignore Wed May 09 06:51:41 2018 +0200 > +++ b/.hgignore Wed May 09 06:55:10 2018 +0200 > @@ -13,3 +13,4 @@ > NashornProfile.txt > .*/JTreport/.* > .*/JTwork/.* > +.*/.git/.* > > Thanks! > > Thomas From glaubitz at physik.fu-berlin.de Wed May 9 15:56:54 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 9 May 2018 17:56:54 +0200 Subject: RFR(xxs): 8202822: Add .git to .hgignore In-Reply-To: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> References: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> Message-ID: Shouldn't we also add .hg to .gitignore? :-) On 05/09/2018 05:52 PM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > > On 2018-05-08 21:59, Thomas St?fe wrote: >> Hi all, >> >> could we add .git to .hgignore? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202822 >> >> Diff: >> >> --- a/.hgignore Wed May 09 06:51:41 2018 +0200 >> +++ b/.hgignore Wed May 09 06:55:10 2018 +0200 >> @@ -13,3 +13,4 @@ >> ? NashornProfile.txt >> ? .*/JTreport/.* >> ? .*/JTwork/.* >> +.*/.git/.* >> >> Thanks! >> >> Thomas -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Wed May 9 15:58:23 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 May 2018 17:58:23 +0200 Subject: RFR(xxs): 8202822: Add .git to .hgignore In-Reply-To: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> References: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> Message-ID: Thanks! On Wed, May 9, 2018 at 5:52 PM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > > > On 2018-05-08 21:59, Thomas St?fe wrote: >> >> Hi all, >> >> could we add .git to .hgignore? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202822 >> >> Diff: >> >> --- a/.hgignore Wed May 09 06:51:41 2018 +0200 >> +++ b/.hgignore Wed May 09 06:55:10 2018 +0200 >> @@ -13,3 +13,4 @@ >> NashornProfile.txt >> .*/JTreport/.* >> .*/JTwork/.* >> +.*/.git/.* >> >> Thanks! >> >> Thomas > > From thomas.stuefe at gmail.com Wed May 9 15:58:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 May 2018 17:58:57 +0200 Subject: RFR(xxs): 8202822: Add .git to .hgignore In-Reply-To: References: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> Message-ID: Feel free :) On Wed, May 9, 2018 at 5:56 PM, John Paul Adrian Glaubitz wrote: > Shouldn't we also add .hg to .gitignore? :-) > > > On 05/09/2018 05:52 PM, Erik Joelsson wrote: >> >> Looks good to me. >> >> /Erik >> >> >> On 2018-05-08 21:59, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> could we add .git to .hgignore? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202822 >>> >>> Diff: >>> >>> --- a/.hgignore Wed May 09 06:51:41 2018 +0200 >>> +++ b/.hgignore Wed May 09 06:55:10 2018 +0200 >>> @@ -13,3 +13,4 @@ >>> NashornProfile.txt >>> .*/JTreport/.* >>> .*/JTwork/.* >>> +.*/.git/.* >>> >>> Thanks! >>> >>> Thomas > > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From igor.ignatyev at oracle.com Wed May 9 21:09:53 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 9 May 2018 14:09:53 -0700 Subject: RFR(L) : 8199384 : [TESTBUG] Open source VM testbase MLVM tests Message-ID: <53E4CA40-DE86-41A2-A1BE-239BE1D85069@oracle.com> http://cr.openjdk.java.net/~iignatyev//8199384/webrev.00/index.html > 61414 lines changed: 61414 ins; 0 del; 0 mod; Hi all, could you please review this patch which open sources MLVM tests from VM testbase? these tests were developed in early days of JSR292 to test different aspects of MethodHandles and invokedynamic. As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. JBS: https://bugs.openjdk.java.net/browse/JDK-8199384 webrev: http://cr.openjdk.java.net/~iignatyev//8199384/webrev.00/index.html testing: :vmTestbase_vm_mlvm test group Thanks, -- Igor From erik.joelsson at oracle.com Wed May 9 21:29:44 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 9 May 2018 14:29:44 -0700 Subject: RFR(L) : 8199384 : [TESTBUG] Open source VM testbase MLVM tests In-Reply-To: <53E4CA40-DE86-41A2-A1BE-239BE1D85069@oracle.com> References: <53E4CA40-DE86-41A2-A1BE-239BE1D85069@oracle.com> Message-ID: Build changes look good. /Erik On 2018-05-09 14:09, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199384/webrev.00/index.html >> 61414 lines changed: 61414 ins; 0 del; 0 mod; > Hi all, > > could you please review this patch which open sources MLVM tests from VM testbase? > > these tests were developed in early days of JSR292 to test different aspects of MethodHandles and invokedynamic. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199384 > webrev: http://cr.openjdk.java.net/~iignatyev//8199384/webrev.00/index.html > testing: :vmTestbase_vm_mlvm test group > > Thanks, > -- Igor > From mandy.chung at oracle.com Thu May 10 04:04:13 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 9 May 2018 21:04:13 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5AECD7D9.4080400@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5AECD7D9.4080400@oracle.com> Message-ID: On 5/4/18 2:59 PM, Jonathan Gibbons wrote: > Here's an update to the previously proposed patch for JEP 330: Launch > Single-File Source-Code Programs. > It includes all review feedback so far. The changes are mostly minor, > but with the addition of more test cases. > > The webrev includes a delta-webrev for those that just want to see > what has changed since last time. > > Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html > > ??? Original webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html > ??? Delta webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html > I looked through the change and it looks fine to me. Mandy From thomas.stuefe at gmail.com Thu May 10 05:20:23 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 10 May 2018 07:20:23 +0200 Subject: RFR(xxs): 8202822: Add .git to .hgignore In-Reply-To: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> References: <26a28f37-d826-d528-188b-6dae0e3f5135@oracle.com> Message-ID: Thanks Erik! I'll push this now under the trivial rule. Thanks, Thomas On Wed, May 9, 2018 at 5:52 PM, Erik Joelsson wrote: > Looks good to me. > > /Erik > > > > On 2018-05-08 21:59, Thomas St?fe wrote: >> >> Hi all, >> >> could we add .git to .hgignore? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202822 >> >> Diff: >> >> --- a/.hgignore Wed May 09 06:51:41 2018 +0200 >> +++ b/.hgignore Wed May 09 06:55:10 2018 +0200 >> @@ -13,3 +13,4 @@ >> NashornProfile.txt >> .*/JTreport/.* >> .*/JTwork/.* >> +.*/.git/.* >> >> Thanks! >> >> Thomas > > From erik.joelsson at oracle.com Thu May 10 14:53:03 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 May 2018 07:53:03 -0700 Subject: RFR: JDK-8202914: Let custom makefile override jmod intput dir locations Message-ID: We need to be able to override some input dir locations from a custom makefile extension. Bug: https://bugs.openjdk.java.net/browse/JDK-8202914 Webrev: http://javaweb.us.oracle.com/~ejoelsso/webrev/8202914/webrev.01/ /Erik From tim.bell at oracle.com Thu May 10 14:57:43 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 10 May 2018 07:57:43 -0700 Subject: RFR: JDK-8202914: Let custom makefile override jmod intput dir locations In-Reply-To: References: Message-ID: <5AF45DE7.5030402@oracle.com> Erik: > We need to be able to override some input dir locations from a custom > makefile extension. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202914 > > Webrev: http://javaweb.us.oracle.com/~ejoelsso/webrev/8202914/webrev.01/ Looks good. Tim From erik.joelsson at oracle.com Thu May 10 16:36:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 May 2018 09:36:57 -0700 Subject: RFR: JDK-8202919: JDK-8202683 broke macosx build Message-ID: <7e22291e-cbd8-eda7-317c-dbaef7fd78e6@oracle.com> The macosx build fails with: jib > /usr/bin/printf: illegal option -- s jib > usage: printf format [arguments ...] jib > Copy-java.base.gmk:123: recipe for target '/scratch/mesos/slaves/555f5737-a945-4eb0-8d30-afb1fc816afd-S23/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6b28d42d-8028-4658-a23d-8f6d3f314161/runs/f48124fc-fd2c-4db3-9cfe-4eddde371989/workspace/build/macosx-x64/support/modules_libs/java.base/jvm.cfg' failed Adding -- first on the printf lines fixes this build error. Bug: https://bugs.openjdk.java.net/browse/JDK-8202919 Webrev: http://cr.openjdk.java.net/~erikj/8202919/webrev.01/ /Erik From shade at redhat.com Thu May 10 16:42:24 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 10 May 2018 18:42:24 +0200 Subject: RFR: JDK-8202919: JDK-8202683 broke macosx build In-Reply-To: <7e22291e-cbd8-eda7-317c-dbaef7fd78e6@oracle.com> References: <7e22291e-cbd8-eda7-317c-dbaef7fd78e6@oracle.com> Message-ID: <118d2576-1894-4b95-6626-7ad7f7a29ea2@redhat.com> On 05/10/2018 06:36 PM, Erik Joelsson wrote: > The macosx build fails with: > > jib > /usr/bin/printf: illegal option -- s > jib > usage: printf format [arguments ...] > jib > Copy-java.base.gmk:123: recipe for target > '/scratch/mesos/slaves/555f5737-a945-4eb0-8d30-afb1fc816afd-S23/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6b28d42d-8028-4658-a23d-8f6d3f314161/runs/f48124fc-fd2c-4db3-9cfe-4eddde371989/workspace/build/macosx-x64/support/modules_libs/java.base/jvm.cfg' > failed > > Adding -- first on the printf lines fixes this build error. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202919 > > Webrev: http://cr.openjdk.java.net/~erikj/8202919/webrev.01/ Looks good. Sorry about the breakage! -Aleksey From tim.bell at oracle.com Thu May 10 16:44:50 2018 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 10 May 2018 09:44:50 -0700 Subject: RFR: JDK-8202919: JDK-8202683 broke macosx build In-Reply-To: <118d2576-1894-4b95-6626-7ad7f7a29ea2@redhat.com> References: <7e22291e-cbd8-eda7-317c-dbaef7fd78e6@oracle.com> <118d2576-1894-4b95-6626-7ad7f7a29ea2@redhat.com> Message-ID: <5AF47702.1020205@oracle.com> Erik: On 05/10/18 09:42, Aleksey Shipilev wrote: > On 05/10/2018 06:36 PM, Erik Joelsson wrote: >> The macosx build fails with: >> >> jib > /usr/bin/printf: illegal option -- s >> jib > usage: printf format [arguments ...] >> jib > Copy-java.base.gmk:123: recipe for target >> '/scratch/mesos/slaves/555f5737-a945-4eb0-8d30-afb1fc816afd-S23/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6b28d42d-8028-4658-a23d-8f6d3f314161/runs/f48124fc-fd2c-4db3-9cfe-4eddde371989/workspace/build/macosx-x64/support/modules_libs/java.base/jvm.cfg' >> failed >> >> Adding -- first on the printf lines fixes this build error. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202919 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8202919/webrev.01/ > > Looks good. Sorry about the breakage! Looks good to me as well. Tim From erik.joelsson at oracle.com Thu May 10 17:38:03 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 May 2018 10:38:03 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect Message-ID: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> I took a further look at the jvm.cfg generation and reworked it completely. This change removes all the predefined jvm.cfg files and replaces them with a simple generation script. This should produce the same files as before JDK-8202683 for any configuration Oracle builds officially and zero. For special jvm variant combinations, it will stay closer to the official ones. See bug comments for details. Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ /Erik From shade at redhat.com Thu May 10 18:29:57 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 10 May 2018 20:29:57 +0200 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> Message-ID: On 05/10/2018 07:38 PM, Erik Joelsson wrote: > I took a further look at the jvm.cfg generation and reworked it completely. This change removes all > the predefined jvm.cfg files and replaces them with a simple generation script. This should produce > the same files as before JDK-8202683 for any configuration Oracle builds officially and zero. For > special jvm variant combinations, it will stay closer to the official ones. See bug comments for > details. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 > > Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ Yes, this makes much more sense. Looks good! We do not want ALIASED_TO anymore? -Aleksey From christoph.langer at sap.com Thu May 10 21:11:55 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 10 May 2018 21:11:55 +0000 Subject: [11] RFR for JDK-8202544: Hide unused exports in libzip In-Reply-To: <426447b2-974e-bbf6-e1df-3ce235930252@oracle.com> References: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> <426447b2-974e-bbf6-e1df-3ce235930252@oracle.com> Message-ID: <4cfd517954d1462e9c8e4fe5f34aada5@sap.com> Hi Alexey, looks good to me. Symbols don't seem to be needed outside libzip (java.base). Best regards Christoph > -----Original Message----- > From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of > Alexey Ivanov > Sent: Mittwoch, 9. Mai 2018 16:35 > To: core-libs ; hotspot-dev dev at openjdk.java.net> > Cc: build-dev > Subject: Re: [11] RFR for JDK-8202544: Hide unused exports in libzip > > Any volunteers from core-libs and/or hotspot? > > Thank you, > Alexey > > On 02/05/2018 13:02, Magnus Ihse Bursie wrote: > > Looks good to me, FWIW. > > > > /Magnus > > > >> 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : > >> > >> Hi, > >> > >> Could you please review the following fix for jdk11? > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8202544 > >> webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ > >> > >> The following exported functions in libzip are not used: > >> ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read > >> > >> I removed JNIEXPORT modifiers from these functions. With the fix, > they're not exported on Windows; on Linux they're listed as Local rather than > Global. > >> > >> I ran tests, no failures. > >> > >> > >> Thank you in advance. > >> > >> Regards, > >> Alexey From david.holmes at oracle.com Thu May 10 21:41:26 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 May 2018 07:41:26 +1000 Subject: RFR: JDK-8202919: JDK-8202683 broke macosx build In-Reply-To: <7e22291e-cbd8-eda7-317c-dbaef7fd78e6@oracle.com> References: <7e22291e-cbd8-eda7-317c-dbaef7fd78e6@oracle.com> Message-ID: <3d2137b4-cd5d-f5f2-54ac-2f7d399ae77a@oracle.com> On 11/05/2018 2:36 AM, Erik Joelsson wrote: > The macosx build fails with: > > jib > /usr/bin/printf: illegal option -- s > jib > usage: printf format [arguments ...] > jib > Copy-java.base.gmk:123: recipe for target > '/scratch/mesos/slaves/555f5737-a945-4eb0-8d30-afb1fc816afd-S23/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/6b28d42d-8028-4658-a23d-8f6d3f314161/runs/f48124fc-fd2c-4db3-9cfe-4eddde371989/workspace/build/macosx-x64/support/modules_libs/java.base/jvm.cfg' > failed > > Adding -- first on the printf lines fixes this build error. Seems the affect of 8202683 was not what I expected. It was only supposed to allow for the minimal VM to be built/used on 64-bit - I did not realize that it changed the way the jvm.cfg file is handled for all 64-bit platforms! There should have been a verification on every platform that for non-Minimal VM cases the old and new jvm.cfg files are identical. This was obviously not done for all platforms. Was it done at all? David ----- > Bug: https://bugs.openjdk.java.net/browse/JDK-8202919 > > Webrev: http://cr.openjdk.java.net/~erikj/8202919/webrev.01/ > > /Erik > From david.holmes at oracle.com Thu May 10 22:12:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 May 2018 08:12:01 +1000 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> Message-ID: Hi Erik, cc'ing Kumar as he is nominally the owner of the jvm.cfg files. On 11/05/2018 3:38 AM, Erik Joelsson wrote: > I took a further look at the jvm.cfg generation and reworked it > completely. This change removes all the predefined jvm.cfg files and > replaces them with a simple generation script. This should produce the > same files as before JDK-8202683 for any configuration Oracle builds > officially and zero. For special jvm variant combinations, it will stay > closer to the official ones. See bug comments for details. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 > > Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ I'm not sure of the details here. You no longer alias any flags for VMs not present, but list them as "ignore". IIUC that means the default VM will be selected - so as long as the default VM is the one previously aliased to then it is equivalent. I also thought that the first line in the file defined the default VM and so had to be a known VM - with these changes a client-only build, for example, will have a first entry of "-server ignore". There is always some debate as to whether a non-present VM should be ignored or cause an error. For the minimal VM builds we used to do for SE Embedded it was chosen to ignore them and just use the Minimal VM. This isn't necessarily what everyone would want. David > /Erik > From erik.joelsson at oracle.com Thu May 10 22:32:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 May 2018 15:32:35 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> Message-ID: <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> On 2018-05-10 15:12, David Holmes wrote: > Hi Erik, > > cc'ing Kumar as he is nominally the owner of the jvm.cfg files. > > On 11/05/2018 3:38 AM, Erik Joelsson wrote: >> I took a further look at the jvm.cfg generation and reworked it >> completely. This change removes all the predefined jvm.cfg files and >> replaces them with a simple generation script. This should produce >> the same files as before JDK-8202683 for any configuration Oracle >> builds officially and zero. For special jvm variant combinations, it >> will stay closer to the official ones. See bug comments for details. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ > > I'm not sure of the details here. You no longer alias any flags for > VMs not present, but list them as "ignore". IIUC that means the > default VM will be selected - so as long as the default VM is the one > previously aliased to then it is equivalent. I also thought that the > first line in the file defined the default VM and so had to be a known > VM - with these changes a client-only build, for example, will have a > first entry of "-server ignore". > I wasn't sure about the ordering and default, but if the first one matters, then I need to rework this a bit. In particular the order is now reversed for windows x86 (if that is something we would want to preserve). Inserting the KNOWN should also be moved last as you point out. > There is always some debate as to whether a non-present VM should be > ignored or cause an error. For the minimal VM builds we used to do for > SE Embedded it was chosen to ignore them and just use the Minimal VM. > This isn't necessarily what everyone would want. > For that part, this change is not changing behavior for any configuration that we really care about. (Note that you need to compare to the behavior previous to Shipilev's change which did indeed move things around.) All the static jvm.cfg files should be equivalent as none of them had ALIAS in them anymore (since your change way back in JDK 8). There will only be a difference if you explicitly build a non standard combination, like only client or only minimal. In those cases, the old generation logic would kick in and generate aliases. Do we want to keep aliases in those cases? Does it really matter? /Erik > David > >> /Erik >> From erik.joelsson at oracle.com Thu May 10 22:41:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 May 2018 15:41:47 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> Message-ID: Here is a new webrev where the IGNORED are added last. http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ It will still change the default on windows-x86 however. If we really care about this, then perhaps we need to add a configure flag that allows the builder to pick the default variant. /Erik On 2018-05-10 15:32, Erik Joelsson wrote: > On 2018-05-10 15:12, David Holmes wrote: >> Hi Erik, >> >> cc'ing Kumar as he is nominally the owner of the jvm.cfg files. >> >> On 11/05/2018 3:38 AM, Erik Joelsson wrote: >>> I took a further look at the jvm.cfg generation and reworked it >>> completely. This change removes all the predefined jvm.cfg files and >>> replaces them with a simple generation script. This should produce >>> the same files as before JDK-8202683 for any configuration Oracle >>> builds officially and zero. For special jvm variant combinations, it >>> will stay closer to the official ones. See bug comments for details. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ >> >> I'm not sure of the details here. You no longer alias any flags for >> VMs not present, but list them as "ignore". IIUC that means the >> default VM will be selected - so as long as the default VM is the one >> previously aliased to then it is equivalent. I also thought that the >> first line in the file defined the default VM and so had to be a >> known VM - with these changes a client-only build, for example, will >> have a first entry of "-server ignore". >> > I wasn't sure about the ordering and default, but if the first one > matters, then I need to rework this a bit. In particular the order is > now reversed for windows x86 (if that is something we would want to > preserve). Inserting the KNOWN should also be moved last as you point > out. >> There is always some debate as to whether a non-present VM should be >> ignored or cause an error. For the minimal VM builds we used to do >> for SE Embedded it was chosen to ignore them and just use the Minimal >> VM. This isn't necessarily what everyone would want. >> > For that part, this change is not changing behavior for any > configuration that we really care about. (Note that you need to > compare to the behavior previous to Shipilev's change which did indeed > move things around.) All the static jvm.cfg files should be equivalent > as none of them had ALIAS in them anymore (since your change way back > in JDK 8). There will only be a difference if you explicitly build a > non standard combination, like only client or only minimal. In those > cases, the old generation logic would kick in and generate aliases. Do > we want to keep aliases in those cases? Does it really matter? > > /Erik >> David >> >>> /Erik >>> > From david.holmes at oracle.com Thu May 10 22:52:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 May 2018 08:52:36 +1000 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> Message-ID: On 11/05/2018 8:41 AM, Erik Joelsson wrote: > Here is a new webrev where the IGNORED are added last. > > http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ > > It will still change the default on windows-x86 however. If we really > care about this, then perhaps we need to add a configure flag that > allows the builder to pick the default variant. For 32-bit, client was always the default. That should be easy enough to maintain. Given these jvm.cfg files have been slated for removal for a very long time, I don't think you want to add new configure options related to them. Even this current work is rather a waste of everyone's time in the circumstance. David > /Erik > > On 2018-05-10 15:32, Erik Joelsson wrote: >> On 2018-05-10 15:12, David Holmes wrote: >>> Hi Erik, >>> >>> cc'ing Kumar as he is nominally the owner of the jvm.cfg files. >>> >>> On 11/05/2018 3:38 AM, Erik Joelsson wrote: >>>> I took a further look at the jvm.cfg generation and reworked it >>>> completely. This change removes all the predefined jvm.cfg files and >>>> replaces them with a simple generation script. This should produce >>>> the same files as before JDK-8202683 for any configuration Oracle >>>> builds officially and zero. For special jvm variant combinations, it >>>> will stay closer to the official ones. See bug comments for details. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ >>> >>> I'm not sure of the details here. You no longer alias any flags for >>> VMs not present, but list them as "ignore". IIUC that means the >>> default VM will be selected - so as long as the default VM is the one >>> previously aliased to then it is equivalent. I also thought that the >>> first line in the file defined the default VM and so had to be a >>> known VM - with these changes a client-only build, for example, will >>> have a first entry of "-server ignore". >>> >> I wasn't sure about the ordering and default, but if the first one >> matters, then I need to rework this a bit. In particular the order is >> now reversed for windows x86 (if that is something we would want to >> preserve). Inserting the KNOWN should also be moved last as you point >> out. >>> There is always some debate as to whether a non-present VM should be >>> ignored or cause an error. For the minimal VM builds we used to do >>> for SE Embedded it was chosen to ignore them and just use the Minimal >>> VM. This isn't necessarily what everyone would want. >>> >> For that part, this change is not changing behavior for any >> configuration that we really care about. (Note that you need to >> compare to the behavior previous to Shipilev's change which did indeed >> move things around.) All the static jvm.cfg files should be equivalent >> as none of them had ALIAS in them anymore (since your change way back >> in JDK 8). There will only be a difference if you explicitly build a >> non standard combination, like only client or only minimal. In those >> cases, the old generation logic would kick in and generate aliases. Do >> we want to keep aliases in those cases? Does it really matter? >> >> /Erik >>> David >>> >>>> /Erik >>>> >> > From jiangli.zhou at Oracle.COM Thu May 10 23:11:36 2018 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Thu, 10 May 2018 16:11:36 -0700 Subject: RFR: 8199807 & 8202738: AppCDS performs overly restrictive path matching check Message-ID: Hi, Please review the following webrev that addresses the issue of copied/moved JDK image after generating a CDS archive. Thanks Karen Kinnear and Alan Baterman for initiating the investigation & discussions in this area (especially the ease of usage). Thanks Ioi for implementing a test case for moved JDK (JDK-8202935). webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921 Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921 The webrev includes the following three main parts: 1. Reduced check for JDK ?modules? image file at runtime. The runtime path to the ?modules? image is no longer required to the the same as dump time path. Runtime performs file size check only for the ?modules? image, which must match with the dump time ?modules? size. Invalidation of an outdated archive is achieved by the existing vm_version string check (the archived vm_version string must match with the runtime vm_version string). 2. Boot path check are now performed based on the content of the archive. Also added a new test case in BootClassPathMismatch.java and add more comments for existing test cases. 3. Fixed the stale vm_version string issue with incremental build. The issue was discovered during the work of 8199807. CDS uses vm_version string as part of the runtime validation check for archive. A stale vm_version string causes the CDS runtime to mistakenly accept an outdated archive. The fix is to make sure vm_version.o is recompiled properly when the library/vm is rebuilt. Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK image manually after generating an archive. Also tested with Ioi?s test both locally and via Mach5. Thanks, Jiangli From erik.joelsson at oracle.com Fri May 11 00:03:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 May 2018 17:03:51 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> Message-ID: <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> On 2018-05-10 15:52, David Holmes wrote: > On 11/05/2018 8:41 AM, Erik Joelsson wrote: >> Here is a new webrev where the IGNORED are added last. >> >> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >> >> It will still change the default on windows-x86 however. If we really >> care about this, then perhaps we need to add a configure flag that >> allows the builder to pick the default variant. > > For 32-bit, client was always the default. That should be easy enough > to maintain. > No, if you look at: http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html It has server as default, whereas: http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html has client, so it varies on OS (and cpu type for legacy oracle closed platforms). This can certainly be maintained, but the question is if anyone cares. There is a cost to maintaining exceptions. I think the best cause of action right now is to go with my current patch and if anyone thinks they need to control the default (i.e. set client default for certain configurations) we can add a configure flag later. > Given these jvm.cfg files have been slated for removal for a very long > time, I don't think you want to add new configure options related to > them. Even this current work is rather a waste of everyone's time in > the circumstance. > You mean the launcher will be reworked? Perhaps it will. However, right now, the combination of JDK-8202919 and JDK-8202683 has quite drastically changed the contents of jvm.cfg, so I'm trying to restore some kind of order short term. /Erik > David > >> /Erik >> >> On 2018-05-10 15:32, Erik Joelsson wrote: >>> On 2018-05-10 15:12, David Holmes wrote: >>>> Hi Erik, >>>> >>>> cc'ing Kumar as he is nominally the owner of the jvm.cfg files. >>>> >>>> On 11/05/2018 3:38 AM, Erik Joelsson wrote: >>>>> I took a further look at the jvm.cfg generation and reworked it >>>>> completely. This change removes all the predefined jvm.cfg files >>>>> and replaces them with a simple generation script. This should >>>>> produce the same files as before JDK-8202683 for any configuration >>>>> Oracle builds officially and zero. For special jvm variant >>>>> combinations, it will stay closer to the official ones. See bug >>>>> comments for details. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ >>>> >>>> I'm not sure of the details here. You no longer alias any flags for >>>> VMs not present, but list them as "ignore". IIUC that means the >>>> default VM will be selected - so as long as the default VM is the >>>> one previously aliased to then it is equivalent. I also thought >>>> that the first line in the file defined the default VM and so had >>>> to be a known VM - with these changes a client-only build, for >>>> example, will have a first entry of "-server ignore". >>>> >>> I wasn't sure about the ordering and default, but if the first one >>> matters, then I need to rework this a bit. In particular the order >>> is now reversed for windows x86 (if that is something we would want >>> to preserve). Inserting the KNOWN should also be moved last as you >>> point out. >>>> There is always some debate as to whether a non-present VM should >>>> be ignored or cause an error. For the minimal VM builds we used to >>>> do for SE Embedded it was chosen to ignore them and just use the >>>> Minimal VM. This isn't necessarily what everyone would want. >>>> >>> For that part, this change is not changing behavior for any >>> configuration that we really care about. (Note that you need to >>> compare to the behavior previous to Shipilev's change which did >>> indeed move things around.) All the static jvm.cfg files should be >>> equivalent as none of them had ALIAS in them anymore (since your >>> change way back in JDK 8). There will only be a difference if you >>> explicitly build a non standard combination, like only client or >>> only minimal. In those cases, the old generation logic would kick in >>> and generate aliases. Do we want to keep aliases in those cases? >>> Does it really matter? >>> >>> /Erik >>>> David >>>> >>>>> /Erik >>>>> >>> >> From yasuenag at gmail.com Fri May 11 03:55:48 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 11 May 2018 12:55:48 +0900 Subject: Build failure on Fedora 28 In-Reply-To: <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> Message-ID: Hi, I found 1 GCC optimization issue, but it is not enough. http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/gdb-before.txt I traced class loading from `modules`. Above log is copy of GDB console in ImageFileReader::verify_location(). The code expects `*next++` increments after referring the value, but it do not so. Thus I fixed the code as following changeset: http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/wip.00/ It passes module name check, but it fails parent (package name) check. GDB log is here: http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/gdb-after.txt I guess the value of parent should be `java/lang`, but it sets to `sun/refrect/generics/factory`. Do you have anything to think about? Thanks, Yasumasa 2018-05-09 17:22 GMT+09:00 Severin Gehwolf : > Hi, > > Note that slowdebug builds work: > > $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version > openjdk version "11-internal" 2018-09-25 > OpenJDK Runtime Environment (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs) > OpenJDK 64-Bit Server VM (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs, mixed mode) > > In summary we have: > > * Build fails with fastdebug/release debug config (-O3) > * Build succeeds with slowdebug (-O0) > * F28 has GCC 8 > * Older GCC-based builds continue to work for fastdebug/release config > > * JDK 10.0.1 builds fine with GCC 8. > > So far showing all symptoms of either a GCC bug or some UB in recent > OpenJDK code which breaks with new optimizations done in GCC 8. > > I'll continue to investigate what it is... > > Cheers, > Severin > > On Wed, 2018-05-09 at 17:03 +0900, Yasumasa Suenaga wrote: >> Hi Thomas, >> >> Build was succeeded with --with-build-jdk= >> configure >> option, but JDK image does not work as below: >> >> ``` >> [ysuenaga at f4i jdk]$ >> ./build/linux-x86_64-normal-server-fastdebug/images/jdk/bin/java >> --version >> Error occurred during initialization of VM >> java/lang/NoClassDefFoundError: java/lang/Object >> ``` >> >> >> Thanks, >> >> Yasumasa >> >> >> 2018-05-09 14:36 GMT+09:00 Thomas St?fe : >> > Hi, >> > >> > sorry for quick dropping in. Just wanted to remark that it may be >> > useful to run with --with-build-jdk= with being a good >> > working >> > jdk you trust. It must be close to the source you build - I usually >> > use a clean current release build. >> > >> > This excludes build errors which may be caused by the JDK you are >> > building being faulty (the build uses itself in places). >> > >> > ..Thomas >> > >> > On Wed, May 9, 2018 at 5:46 AM, Yasumasa Suenaga > > m> wrote: >> > > Hi David, >> > > >> > > I uploaded build.log: >> > > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/build.log >> > > >> > > Is it enough? >> > > >> > > >> > > Thanks, >> > > >> > > Yasumasa >> > > >> > > >> > > >> > > 2018-05-09 11:17 GMT+09:00 David Holmes >> > > : >> > > > On 9/05/2018 12:09 PM, Yasumasa Suenaga wrote: >> > > > > >> > > > > Hi David, >> > > > > >> > > > > 2018-05-09 10:48 GMT+09:00 David Holmes > > > > > com>: >> > > > > > >> > > > > > Can you build with LOG=trace to try and see the actual >> > > > > > command that is >> > > > > > failing? >> > > > > >> > > > > >> > > > > I tried it and got following logs. They look good to me. >> > > > >> > > > >> > > > Not enough there for me to comment :) >> > > > > >> > > > > >> > > > > * Creating interim-image >> > > > > >> > > > > + >> > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- >> > > > > fastdebug/jdk/bin/jlink >> > > > > -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J- >> > > > > XX:TieredStopAtLevel=1 >> > > > > -J-Djlin >> > > > > k.debug=true --module-path >> > > > > >> > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- >> > > > > fastdebug/support/interim-jmods >> > > > > --endian little --output >> > > > > >> > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- >> > > > > fastdebug/support/interim-image >> > > > > --disable-plugin generate-jli-classes --add-modules >> > > > > java.base,java.logging >> > > > >> > > > >> > > > So this seems to produce an interim image that won't run - >> > > > correct? I'd be >> > > > scouring the log in the lead up to this to see if anything >> > > > seems to be >> > > > unusual. Can you upload the log to cr.openjdk.java.net? Or >> > > > email me >> > > > directly? >> > > > >> > > > Thanks, >> > > > David >> > > > >> > > > >> > > > > >> > > > > * Command on error: >> > > > > >> > > > > + >> > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- >> > > > > fastdebug/support/interim-image/bin/java >> > > > > >> > > > > -XX:DumpLoadedClassList=/home/ysuenaga/OpenJDK/jdk/build/linu >> > > > > x-x86_64-normal-server- >> > > > > fastdebug/support/link_opt/classlist.raw >> > > > > -Djava.lang.invoke.MethodHandle.TRACE_RESOLVE=true -cp >> > > > > >> > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal-server- >> > > > > fastdebug/support/classlist.jar >> > > > > build.tools.classlist.HelloClasslist >> > > > > >> > > > > Thanks, >> > > > > >> > > > > Yasumasa >> > > > > >> > > > > >> > > > > > David >> > > > > > >> > > > > > >> > > > > > On 9/05/2018 11:39 AM, Yasumasa Suenaga wrote: >> > > > > > > >> > > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > 2018-05-09 0:27 GMT+09:00 Erik Joelsson > > > > > > > acle.com>: >> > > > > > > > >> > > > > > > > >> > > > > > > > Hello, >> > > > > > > > >> > > > > > > > Your assessment is looks correct so far. At this point, >> > > > > > > > one would have >> > > > > > > > to >> > > > > > > > start debugging the image to figure out what's wrong >> > > > > > > > with it. Are you >> > > > > > > > able >> > > > > > > > to run the exploded image in >> > > > > > > > ./build/linux-x86_64-normal-server- >> > > > > > > > fastdebug/jdk/bin/java? >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > It works. So I wonder why invalid image was built. >> > > > > > > >> > > > > > > ``` >> > > > > > > $ ./build/linux-x86_64-normal-server- >> > > > > > > fastdebug/jdk/bin/java --version >> > > > > > > openjdk 11-internal 2018-09-25 >> > > > > > > OpenJDK Runtime Environment (fastdebug build >> > > > > > > 11-internal+0-adhoc.ysuenaga.jdk) >> > > > > > > OpenJDK 64-Bit Server VM (fastdebug build >> > > > > > > 11-internal+0-adhoc.ysuenaga.jdk, mixed mode) >> > > > > > > ``` >> > > > > > > >> > > > > > > I'm waiting for Severin's evaluation :-) >> > > > > > > >> > > > > > > >> > > > > > > Thanks, >> > > > > > > >> > > > > > > Yasumasa >> > > > > > > >> > > > > > > >> > > > > > > > Has anyone at Redhat built successfully on Fedora 28 >> > > > > > > > yet? >> > > > > > > > >> > > > > > > > /Erik >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > On 2018-05-08 06:42, Yasumasa Suenaga wrote: >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > Hi all, >> > > > > > > > > >> > > > > > > > > I tried to build OpenJDK (jdk/jdk) on Fedora 28 x64, >> > > > > > > > > but it failed as >> > > > > > > > > following: >> > > > > > > > > >> > > > > > > > > ``` >> > > > > > > > > [ysuenaga at fc28 jdk]$ make images >> > > > > > > > > Building target 'images' in configuration >> > > > > > > > > 'linux-x86_64-normal-server-fastdebug' >> > > > > > > > > gmake[3]: *** [GenerateLinkOptData.gmk:64: >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > /home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-normal- >> > > > > > > > > server-fastdebug/support/link_opt/classlist] >> > > > > > > > > Error 1 >> > > > > > > > > gmake[2]: *** [make/Main.gmk:448: generate-link-opt- >> > > > > > > > > data] Error 2 >> > > > > > > > > >> > > > > > > > > ERROR: Build failed for target 'images' in >> > > > > > > > > configuration >> > > > > > > > > 'linux-x86_64-normal-server-fastdebug' (exit code 2) >> > > > > > > > > >> > > > > > > > > No indication of failed target found. >> > > > > > > > > Hint: Try searching the build log for '] Error'. >> > > > > > > > > Hint: See doc/building.html#troubleshooting for >> > > > > > > > > assistance. >> > > > > > > > > >> > > > > > > > > make[1]: *** >> > > > > > > > > [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:305: main] >> > > > > > > > > Error >> > > > > > > > > 2 >> > > > > > > > > make: *** >> > > > > > > > > [/home/ysuenaga/OpenJDK/jdk/make/Init.gmk:186: >> > > > > > > > > images] Error >> > > > > > > > > 2 >> > > > > > > > > ``` >> > > > > > > > > >> > > > > > > > > It seems "interim-image" is not valid: >> > > > > > > > > >> > > > > > > > > ``` >> > > > > > > > > [ysuenaga at fc28 jdk]$ >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > ./build/linux-x86_64-normal-server- >> > > > > > > > > fastdebug/support/interim-image/bin/java >> > > > > > > > > --version >> > > > > > > > > Error occurred during initialization of VM >> > > > > > > > > java/lang/NoClassDefFoundError: java/lang/Object >> > > > > > > > > ``` >> > > > > > > > > >> > > > > > > > > It can succeed on Fedora 27. So I think it causes by >> > > > > > > > > OS. >> > > > > > > > > I've disabled SELinux, and warnings / errors are >> > > > > > > > > nothing in >> > > > > > > > > `journalctl >> > > > > > > > > -a`. >> > > > > > > > > >> > > > > > > > > Do you have any idea to resolve this issue? >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > Thanks, >> > > > > > > > > >> > > > > > > > > Yasumasa >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > From david.holmes at oracle.com Fri May 11 04:56:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 May 2018 14:56:14 +1000 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> Message-ID: On 11/05/2018 10:03 AM, Erik Joelsson wrote: > On 2018-05-10 15:52, David Holmes wrote: >> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>> Here is a new webrev where the IGNORED are added last. >>> >>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>> >>> It will still change the default on windows-x86 however. If we really >>> care about this, then perhaps we need to add a configure flag that >>> allows the builder to pick the default variant. >> >> For 32-bit, client was always the default. That should be easy enough >> to maintain. >> > No, if you look at: > http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html > > > It has server as default, whereas: > http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html > > > has client, so it varies on OS (and cpu type for legacy oracle closed Sorry I meant with respect to windows-x86, that being the subject of your comment. > platforms). This can certainly be maintained, but the question is if > anyone cares. There is a cost to maintaining exceptions. I think the > best cause of action right now is to go with my current patch and if > anyone thinks they need to control the default (i.e. set client default > for certain configurations) we can add a configure flag later. I strongly disagree. For anyone who is producing a 32-bit Windows bundle for use by others, the behaviour will change from running client by default to running server! At best that will impact startup and performance; at worst startup scripts will fail if client specific flags are used. >> Given these jvm.cfg files have been slated for removal for a very long >> time, I don't think you want to add new configure options related to >> them. Even this current work is rather a waste of everyone's time in >> the circumstance. >> > You mean the launcher will be reworked? Perhaps it will. However, right > now, the combination of JDK-8202919 and JDK-8202683 has quite > drastically changed the contents of jvm.cfg, so I'm trying to restore > some kind of order short term. Personally when the problem with Aleksey's original change was detected I would have rolled it back. If you want to restore order by other means, then do so, but that means restoring the previous contents of the jvm.cfg files to me. David > /Erik >> David >> >>> /Erik >>> >>> On 2018-05-10 15:32, Erik Joelsson wrote: >>>> On 2018-05-10 15:12, David Holmes wrote: >>>>> Hi Erik, >>>>> >>>>> cc'ing Kumar as he is nominally the owner of the jvm.cfg files. >>>>> >>>>> On 11/05/2018 3:38 AM, Erik Joelsson wrote: >>>>>> I took a further look at the jvm.cfg generation and reworked it >>>>>> completely. This change removes all the predefined jvm.cfg files >>>>>> and replaces them with a simple generation script. This should >>>>>> produce the same files as before JDK-8202683 for any configuration >>>>>> Oracle builds officially and zero. For special jvm variant >>>>>> combinations, it will stay closer to the official ones. See bug >>>>>> comments for details. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202920 >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202920/webrev.01/ >>>>> >>>>> I'm not sure of the details here. You no longer alias any flags for >>>>> VMs not present, but list them as "ignore". IIUC that means the >>>>> default VM will be selected - so as long as the default VM is the >>>>> one previously aliased to then it is equivalent. I also thought >>>>> that the first line in the file defined the default VM and so had >>>>> to be a known VM - with these changes a client-only build, for >>>>> example, will have a first entry of "-server ignore". >>>>> >>>> I wasn't sure about the ordering and default, but if the first one >>>> matters, then I need to rework this a bit. In particular the order >>>> is now reversed for windows x86 (if that is something we would want >>>> to preserve). Inserting the KNOWN should also be moved last as you >>>> point out. >>>>> There is always some debate as to whether a non-present VM should >>>>> be ignored or cause an error. For the minimal VM builds we used to >>>>> do for SE Embedded it was chosen to ignore them and just use the >>>>> Minimal VM. This isn't necessarily what everyone would want. >>>>> >>>> For that part, this change is not changing behavior for any >>>> configuration that we really care about. (Note that you need to >>>> compare to the behavior previous to Shipilev's change which did >>>> indeed move things around.) All the static jvm.cfg files should be >>>> equivalent as none of them had ALIAS in them anymore (since your >>>> change way back in JDK 8). There will only be a difference if you >>>> explicitly build a non standard combination, like only client or >>>> only minimal. In those cases, the old generation logic would kick in >>>> and generate aliases. Do we want to keep aliases in those cases? >>>> Does it really matter? >>>> >>>> /Erik >>>>> David >>>>> >>>>>> /Erik >>>>>> >>>> >>> > From shade at redhat.com Fri May 11 06:29:37 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 11 May 2018 08:29:37 +0200 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> Message-ID: <2e9431d7-c81d-f046-bd54-7b697646e338@redhat.com> On 05/11/2018 06:56 AM, David Holmes wrote: > On 11/05/2018 10:03 AM, Erik Joelsson wrote: >> On 2018-05-10 15:52, David Holmes wrote: >>> Given these jvm.cfg files have been slated for removal for a very long time, I don't think you >>> want to add new configure options related to them. Even this current work is rather a waste of >>> everyone's time in the circumstance. >>> >> You mean the launcher will be reworked? Perhaps it will. However, right now, the combination of >> JDK-8202919 and JDK-8202683 has quite drastically changed the contents of jvm.cfg, so I'm trying >> to restore some kind of order short term. > > Personally when the problem with Aleksey's original change was detected I would have rolled it back. > If you want to restore order by other means, then do so, but that means restoring the previous > contents of the jvm.cfg files to me. Yeah, we can backout the original jvm.cfg change, since it produced unexpected breakages. I expected the change to be innocuous, but in glaring hindsight it wasn't. It was not very essential to begin with, and if it comes with roadbumps, it is sensible to backout. Erik's "--" MacOS fix is still good, because it fixed jvm.cfg generation on unusual path. -Aleksey From shade at redhat.com Fri May 11 07:01:18 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 11 May 2018 09:01:18 +0200 Subject: RFR 8202974: Backout JDK-8202683 Message-ID: <5ee4f1fe-ccd5-f111-999d-1def28ed5601@redhat.com> Hi, As we can see, recent fix to jvm.cfg configuration was messed up. Erik is trying to fix that with JDK-8202920 (thanks!). Meanwhile, it seems prudent to backout the offending change. Backout applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8202974 Fix: http://cr.openjdk.java.net/~shade/8202974/webrev.01/ Testing: x86_64 build, hg diff with previous Copy-java.base.gmk Thanks, -Aleksey From thomas.stuefe at gmail.com Fri May 11 07:41:38 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 11 May 2018 09:41:38 +0200 Subject: RFR 8202974: Backout JDK-8202683 In-Reply-To: <5ee4f1fe-ccd5-f111-999d-1def28ed5601@redhat.com> References: <5ee4f1fe-ccd5-f111-999d-1def28ed5601@redhat.com> Message-ID: Looks fine and trivial. .. Thomas On Fri, May 11, 2018 at 9:01 AM, Aleksey Shipilev wrote: > Hi, > > As we can see, recent fix to jvm.cfg configuration was messed up. Erik is trying to fix that with > JDK-8202920 (thanks!). Meanwhile, it seems prudent to backout the offending change. Backout applies > cleanly. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8202974 > > Fix: > http://cr.openjdk.java.net/~shade/8202974/webrev.01/ > > Testing: x86_64 build, hg diff with previous Copy-java.base.gmk > > Thanks, > -Aleksey > From maurizio.cimadamore at oracle.com Fri May 11 10:31:04 2018 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 11 May 2018 11:31:04 +0100 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5AECD7D9.4080400@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5AECD7D9.4080400@oracle.com> Message-ID: Thumbs up - thanks for taking the comments into account. Great job! Maurizio On 04/05/18 22:59, Jonathan Gibbons wrote: > Here's an update to the previously proposed patch for JEP 330: Launch > Single-File Source-Code Programs. > It includes all review feedback so far. The changes are mostly minor, > but with the addition of more test cases. > > The webrev includes a delta-webrev for those that just want to see > what has changed since last time. > > Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html > > ??? Original webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html > ??? Delta webrev: > http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html > > Note that the work is temporarily blocked by JDK-8202387: javac > --release 11 not supported. > A fix for that is underway and in review: > http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html > This work has been tested using a workaround for this issue, and will > be tested again when the real fix is in place. > > -- Jon > > On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> ? * The part to handle the new command-line options is in the native >> ??? Java launcher code. >> ? * The part to invoke the compiler and subsequently execute the code >> ??? found in the source file is in a new class in the jdk.compiler >> module. >> ? * There are some minor Makefile changes, to add support for a new >> ??? resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From alexey.ivanov at oracle.com Fri May 11 11:20:41 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 11 May 2018 12:20:41 +0100 Subject: [11] RFR for JDK-8202544: Hide unused exports in libzip In-Reply-To: <4cfd517954d1462e9c8e4fe5f34aada5@sap.com> References: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> <426447b2-974e-bbf6-e1df-3ce235930252@oracle.com> <4cfd517954d1462e9c8e4fe5f34aada5@sap.com> Message-ID: <168390df-4124-6a92-0d30-0f34f6a48815@oracle.com> Hi Christoph, Thank you for your review. I was checking the changeset before pushing and noticed I had forgotten to remove JNIEXPORT modifier from ZIP_GetEntry in zip_util.h. Here's the updated webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.1/ The only difference with previous one is in this snippet in zip_util.h: -JNIEXPORT jzentry * +jzentry * ?ZIP_GetEntry(jzfile *zip, char *name, jint ulen); Thank you! Regards, Alexey On 10/05/2018 22:11, Langer, Christoph wrote: > Hi Alexey, > > looks good to me. Symbols don't seem to be needed outside libzip (java.base). > > Best regards > Christoph > >> -----Original Message----- >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of >> Alexey Ivanov >> Sent: Mittwoch, 9. Mai 2018 16:35 >> To: core-libs ; hotspot-dev > dev at openjdk.java.net> >> Cc: build-dev >> Subject: Re: [11] RFR for JDK-8202544: Hide unused exports in libzip >> >> Any volunteers from core-libs and/or hotspot? >> >> Thank you, >> Alexey >> >> On 02/05/2018 13:02, Magnus Ihse Bursie wrote: >>> Looks good to me, FWIW. >>> >>> /Magnus >>> >>>> 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : >>>> >>>> Hi, >>>> >>>> Could you please review the following fix for jdk11? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202544 >>>> webrev: http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ >>>> >>>> The following exported functions in libzip are not used: >>>> ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read >>>> >>>> I removed JNIEXPORT modifiers from these functions. With the fix, >> they're not exported on Windows; on Linux they're listed as Local rather than >> Global. >>>> I ran tests, no failures. >>>> >>>> >>>> Thank you in advance. >>>> >>>> Regards, >>>> Alexey From christoph.langer at sap.com Fri May 11 12:33:46 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 11 May 2018 12:33:46 +0000 Subject: [11] RFR for JDK-8202544: Hide unused exports in libzip In-Reply-To: <168390df-4124-6a92-0d30-0f34f6a48815@oracle.com> References: <4b0e27bb-8167-4ae5-c5e5-6ec054015d30@oracle.com> <426447b2-974e-bbf6-e1df-3ce235930252@oracle.com> <4cfd517954d1462e9c8e4fe5f34aada5@sap.com> <168390df-4124-6a92-0d30-0f34f6a48815@oracle.com> Message-ID: <6f9e6834441241b4869369c28dc1e546@sap.com> Hi Alexey, good catch, I missed that. Best regards Christoph > -----Original Message----- > From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > Sent: Freitag, 11. Mai 2018 13:21 > To: Langer, Christoph ; core-libs dev at openjdk.java.net>; hotspot-dev ; > build-dev ; Magnus Ihse Bursie > > Subject: Re: [11] RFR for JDK-8202544: Hide unused exports in libzip > > Hi Christoph, > > Thank you for your review. > > I was checking the changeset before pushing and noticed I had forgotten > to remove JNIEXPORT modifier from ZIP_GetEntry in zip_util.h. > > Here's the updated webrev: > http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.1/ > > The only difference with previous one is in this snippet in zip_util.h: > > -JNIEXPORT jzentry * > +jzentry * > ?ZIP_GetEntry(jzfile *zip, char *name, jint ulen); > > > Thank you! > > Regards, > Alexey > > On 10/05/2018 22:11, Langer, Christoph wrote: > > Hi Alexey, > > > > looks good to me. Symbols don't seem to be needed outside libzip > (java.base). > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf > Of > >> Alexey Ivanov > >> Sent: Mittwoch, 9. Mai 2018 16:35 > >> To: core-libs ; hotspot-dev >> dev at openjdk.java.net> > >> Cc: build-dev > >> Subject: Re: [11] RFR for JDK-8202544: Hide unused exports in libzip > >> > >> Any volunteers from core-libs and/or hotspot? > >> > >> Thank you, > >> Alexey > >> > >> On 02/05/2018 13:02, Magnus Ihse Bursie wrote: > >>> Looks good to me, FWIW. > >>> > >>> /Magnus > >>> > >>>> 2 maj 2018 kl. 13:52 skrev Alexey Ivanov : > >>>> > >>>> Hi, > >>>> > >>>> Could you please review the following fix for jdk11? > >>>> > >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8202544 > >>>> webrev: > http://cr.openjdk.java.net/~aivanov/8202544/jdk11/webrev.0/ > >>>> > >>>> The following exported functions in libzip are not used: > >>>> ZIP_GetEntry, ZIP_FreeEntry, ZIP_Lock, ZIP_Unlock, ZIP_Read > >>>> > >>>> I removed JNIEXPORT modifiers from these functions. With the fix, > >> they're not exported on Windows; on Linux they're listed as Local rather > than > >> Global. > >>>> I ran tests, no failures. > >>>> > >>>> > >>>> Thank you in advance. > >>>> > >>>> Regards, > >>>> Alexey From shade at redhat.com Fri May 11 12:39:26 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 11 May 2018 14:39:26 +0200 Subject: RFR 8202974: Backout JDK-8202683 In-Reply-To: References: <5ee4f1fe-ccd5-f111-999d-1def28ed5601@redhat.com> Message-ID: Thanks! Erik J., want me to push this? -Aleksey On 05/11/2018 09:41 AM, Thomas St?fe wrote: > Looks fine and trivial. > > .. Thomas > > On Fri, May 11, 2018 at 9:01 AM, Aleksey Shipilev wrote: >> Hi, >> >> As we can see, recent fix to jvm.cfg configuration was messed up. Erik is trying to fix that with >> JDK-8202920 (thanks!). Meanwhile, it seems prudent to backout the offending change. Backout applies >> cleanly. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8202974 >> >> Fix: >> http://cr.openjdk.java.net/~shade/8202974/webrev.01/ >> >> Testing: x86_64 build, hg diff with previous Copy-java.base.gmk >> >> Thanks, >> -Aleksey >> From jan.lahoda at oracle.com Fri May 11 13:17:32 2018 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 11 May 2018 15:17:32 +0200 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: References: <5ACFBE5C.1080508@oracle.com> <5AECD7D9.4080400@oracle.com> Message-ID: On 11.5.2018 12:31, Maurizio Cimadamore wrote: > Thumbs up - thanks for taking the comments into account. > > Great job! +1 Jan > > Maurizio > > > On 04/05/18 22:59, Jonathan Gibbons wrote: >> Here's an update to the previously proposed patch for JEP 330: Launch >> Single-File Source-Code Programs. >> It includes all review feedback so far. The changes are mostly minor, >> but with the addition of more test cases. >> >> The webrev includes a delta-webrev for those that just want to see >> what has changed since last time. >> >> Full webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/index.html >> >> ??? Original webrev: >> http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v1/index.html >> ??? Delta webrev: >> http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/webrev.v2/index.html >> >> Note that the work is temporarily blocked by JDK-8202387: javac >> --release 11 not supported. >> A fix for that is underway and in review: >> http://mail.openjdk.java.net/pipermail/compiler-dev/2018-May/011868.html >> This work has been tested using a workaround for this issue, and will >> be tested again when the real fix is in place. >> >> -- Jon >> >> On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: >>> Please review an initial implementation for the feature described in >>> JEP 330: Launch Single-File Source-Code Programs. >>> >>> The work is described in the JEP and CSR, and falls into various parts: >>> >>> ? * The part to handle the new command-line options is in the native >>> ??? Java launcher code. >>> ? * The part to invoke the compiler and subsequently execute the code >>> ??? found in the source file is in a new class in the jdk.compiler >>> module. >>> ? * There are some minor Makefile changes, to add support for a new >>> ??? resource file. >>> >>> There are no changes to javac itself. >>> >>> JEP: http://openjdk.java.net/jeps/330 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >>> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >>> >>> -- Jon >> > From erik.joelsson at oracle.com Fri May 11 15:35:05 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 May 2018 08:35:05 -0700 Subject: RFR 8202974: Backout JDK-8202683 In-Reply-To: References: <5ee4f1fe-ccd5-f111-999d-1def28ed5601@redhat.com> Message-ID: Please do, thanks! /Erik On 2018-05-11 05:39, Aleksey Shipilev wrote: > Thanks! > > Erik J., want me to push this? > > -Aleksey > > On 05/11/2018 09:41 AM, Thomas St?fe wrote: >> Looks fine and trivial. >> >> .. Thomas >> >> On Fri, May 11, 2018 at 9:01 AM, Aleksey Shipilev wrote: >>> Hi, >>> >>> As we can see, recent fix to jvm.cfg configuration was messed up. Erik is trying to fix that with >>> JDK-8202920 (thanks!). Meanwhile, it seems prudent to backout the offending change. Backout applies >>> cleanly. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8202974 >>> >>> Fix: >>> http://cr.openjdk.java.net/~shade/8202974/webrev.01/ >>> >>> Testing: x86_64 build, hg diff with previous Copy-java.base.gmk >>> >>> Thanks, >>> -Aleksey >>> > From shade at redhat.com Fri May 11 15:39:29 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 11 May 2018 17:39:29 +0200 Subject: RFR 8202974: Backout JDK-8202683 In-Reply-To: References: <5ee4f1fe-ccd5-f111-999d-1def28ed5601@redhat.com> Message-ID: <00ed47f9-3c7a-730c-2ab2-ab4c9e02678a@redhat.com> Pushed. Sorry for the mess! -Aleksey On 05/11/2018 05:35 PM, Erik Joelsson wrote: > Please do, thanks! > > /Erik > > > On 2018-05-11 05:39, Aleksey Shipilev wrote: >> Thanks! >> >> Erik J., want me to push this? >> >> -Aleksey >> >> On 05/11/2018 09:41 AM, Thomas St?fe wrote: >>> Looks fine and trivial. >>> >>> .. Thomas >>> >>> On Fri, May 11, 2018 at 9:01 AM, Aleksey Shipilev wrote: >>>> Hi, >>>> >>>> As we can see, recent fix to jvm.cfg configuration was messed up. Erik is trying to fix that with >>>> JDK-8202920 (thanks!). Meanwhile, it seems prudent to backout the offending change. Backout applies >>>> cleanly. >>>> >>>> Bug: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8202974 >>>> >>>> Fix: >>>> ?? http://cr.openjdk.java.net/~shade/8202974/webrev.01/ >>>> >>>> Testing: x86_64 build, hg diff with previous Copy-java.base.gmk >>>> >>>> Thanks, >>>> -Aleksey >>>> >> > From erik.joelsson at oracle.com Fri May 11 15:56:08 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 May 2018 08:56:08 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> Message-ID: <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> On 2018-05-10 21:56, David Holmes wrote: > On 11/05/2018 10:03 AM, Erik Joelsson wrote: >> On 2018-05-10 15:52, David Holmes wrote: >>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>> Here is a new webrev where the IGNORED are added last. >>>> >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>> >>>> It will still change the default on windows-x86 however. If we >>>> really care about this, then perhaps we need to add a configure >>>> flag that allows the builder to pick the default variant. >>> >>> For 32-bit, client was always the default. That should be easy >>> enough to maintain. >>> >> No, if you look at: >> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >> >> >> It has server as default, whereas: >> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >> >> >> has client, so it varies on OS (and cpu type for legacy oracle closed > > Sorry I meant with respect to windows-x86, that being the subject of > your comment. > Right, then we are on the same page there. >> platforms). This can certainly be maintained, but the question is if >> anyone cares. There is a cost to maintaining exceptions. I think the >> best cause of action right now is to go with my current patch and if >> anyone thinks they need to control the default (i.e. set client >> default for certain configurations) we can add a configure flag later. > > I strongly disagree. For anyone who is producing a 32-bit Windows > bundle for use by others, the behaviour will change from running > client by default to running server! At best that will impact startup > and performance; at worst startup scripts will fail if client specific > flags are used. > You are right, I will rework this to make sure we can generate different defaults for different configurations so that the current behavior is preserved for any of the current predefined jvm.cfg files. >>> Given these jvm.cfg files have been slated for removal for a very >>> long time, I don't think you want to add new configure options >>> related to them. Even this current work is rather a waste of >>> everyone's time in the circumstance. >>> >> You mean the launcher will be reworked? Perhaps it will. However, >> right now, the combination of JDK-8202919 and JDK-8202683 has quite >> drastically changed the contents of jvm.cfg, so I'm trying to restore >> some kind of order short term. > > Personally when the problem with Aleksey's original change was > detected I would have rolled it back. If you want to restore order by > other means, then do so, but that means restoring the previous > contents of the jvm.cfg files to me. > The problematic change has now been backed out but I will make another attempt at this change. /Erik From mikhailo.seledtsov at oracle.com Fri May 11 16:10:35 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 11 May 2018 09:10:35 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests In-Reply-To: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> References: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> Message-ID: <5AF5C07B.1080909@oracle.com> Looks good to me, Misha On 5/8/18, 2:23 PM, Leonid Mesnik wrote: > Hi > > Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. > They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. > > The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. > > I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. > > webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8199271 From jcbeyler at google.com Fri May 11 16:27:31 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 11 May 2018 09:27:31 -0700 Subject: RFR(L) : 8199375 : [TESTBUG] Open source vm testbase monitoring tests In-Reply-To: <8fd2e124-47c9-98ff-90e8-104f1a78ed28@oracle.com> References: <0BDC93A6-7D0E-4B4B-A797-936A58A296B9@oracle.com> <8fd2e124-47c9-98ff-90e8-104f1a78ed28@oracle.com> Message-ID: Just wanted to chime in and say that this is great, the more the tests are all in the open, the easier it will be for all to be able to test what is needed and not be surprised by closed test failures :) So thank you for doing this and for the other open sourcing of tests efforts! Jc On Wed, May 2, 2018 at 2:19 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Igor, > > It looks good. > > Thanks, > Serguei > > > On 5/1/18 19:10, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8199375/webrev.00/index.html > >> 41276 lines changed: 41274 ins; 1 del; 1 mod; > > Hi all, > > > > could you please review the patch which open sources monitoring tests > from vm testbase? > > > > The tests were developed to test hotspot related JMX functionality. as > w/ common VM testbase code, these tests are old, they have been run from > hotspot testing for a long period of time. originally, these tests were run > by a test harness different from jtreg and had different build and > execution schemes, some parts couldn't be easily translated to jtreg, so > tests might have actions or pieces of code which look weird. in a long > term, we are planning to rework them. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199375 > > webrev: > http://cr.openjdk.java.net/~iignatyev/8199375/webrev.00/index.html > > testing: vmTestbase_nsk_monitoring test group > > > > Thanks, > > -- Igor > > From erik.joelsson at oracle.com Fri May 11 17:46:11 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 May 2018 10:46:11 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> Message-ID: Here is a new attempt. This time I'm pretty sure it produces the same jvm.cfg as all the predefined ones. It's easy to define a new default variant for specific configurations (as is done for windows-x86). It also handles the jvm variants that aren't server, client or minimal correctly (by treating them as server). The only real difference compared to before all this is that we no longer generate ALIASED_TO, but that only happened on very specific manual configurations that anyway. http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ /Erik On 2018-05-11 08:56, Erik Joelsson wrote: > On 2018-05-10 21:56, David Holmes wrote: >> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>> On 2018-05-10 15:52, David Holmes wrote: >>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>> Here is a new webrev where the IGNORED are added last. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>> >>>>> It will still change the default on windows-x86 however. If we >>>>> really care about this, then perhaps we need to add a configure >>>>> flag that allows the builder to pick the default variant. >>>> >>>> For 32-bit, client was always the default. That should be easy >>>> enough to maintain. >>>> >>> No, if you look at: >>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>> >>> >>> It has server as default, whereas: >>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>> >>> >>> has client, so it varies on OS (and cpu type for legacy oracle closed >> >> Sorry I meant with respect to windows-x86, that being the subject of >> your comment. >> > Right, then we are on the same page there. >>> platforms). This can certainly be maintained, but the question is if >>> anyone cares. There is a cost to maintaining exceptions. I think the >>> best cause of action right now is to go with my current patch and if >>> anyone thinks they need to control the default (i.e. set client >>> default for certain configurations) we can add a configure flag later. >> >> I strongly disagree. For anyone who is producing a 32-bit Windows >> bundle for use by others, the behaviour will change from running >> client by default to running server! At best that will impact startup >> and performance; at worst startup scripts will fail if client >> specific flags are used. >> > You are right, I will rework this to make sure we can generate > different defaults for different configurations so that the current > behavior is preserved for any of the current predefined jvm.cfg files. >>>> Given these jvm.cfg files have been slated for removal for a very >>>> long time, I don't think you want to add new configure options >>>> related to them. Even this current work is rather a waste of >>>> everyone's time in the circumstance. >>>> >>> You mean the launcher will be reworked? Perhaps it will. However, >>> right now, the combination of JDK-8202919 and JDK-8202683 has quite >>> drastically changed the contents of jvm.cfg, so I'm trying to >>> restore some kind of order short term. >> >> Personally when the problem with Aleksey's original change was >> detected I would have rolled it back. If you want to restore order by >> other means, then do so, but that means restoring the previous >> contents of the jvm.cfg files to me. >> > The problematic change has now been backed out but I will make another > attempt at this change. > > /Erik From erik.joelsson at oracle.com Fri May 11 21:33:20 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 11 May 2018 14:33:20 -0700 Subject: RFR: 8199807 & 8202738: AppCDS performs overly restrictive path matching check In-Reply-To: References: Message-ID: Hello, For the build change, it's very undesirable to always have to relink libjvm on every incremental build. Such a change cannot be accepted. I have a counter suggestion, which is still a bit of a hack, but it will cause vm_version.cpp to be recompiled (almost) every time libjvm.so needs to be relinked. The drawback is that compiling vm_version.cpp is now bound to happen absolutely last and so cannot happen in parallel with other compilations. Webrev: http://cr.openjdk.java.net/~erikj/8202738/webrev.01/index.html Bug: https://bugs.openjdk.java.net/browse/JDK-8202738 /Erik On 2018-05-10 16:11, Jiangli Zhou wrote: > Hi, > > Please review the following webrev that addresses the issue of copied/moved JDK image after generating a CDS archive. Thanks Karen Kinnear and Alan Baterman for initiating the investigation & discussions in this area (especially the ease of usage). Thanks Ioi for implementing a test case for moved JDK (JDK-8202935). > > webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/ > RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921 > Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921 > > The webrev includes the following three main parts: > > 1. Reduced check for JDK ?modules? image file at runtime. The runtime path to the ?modules? image is no longer required to the the same as dump time path. Runtime performs file size check only for the ?modules? image, which must match with the dump time ?modules? size. Invalidation of an outdated archive is achieved by the existing vm_version string check (the archived vm_version string must match with the runtime vm_version string). > > 2. Boot path check are now performed based on the content of the archive. Also added a new test case in BootClassPathMismatch.java and add more comments for existing test cases. > > 3. Fixed the stale vm_version string issue with incremental build. The issue was discovered during the work of 8199807. CDS uses vm_version string as part of the runtime validation check for archive. A stale vm_version string causes the CDS runtime to mistakenly accept an outdated archive. The fix is to make sure vm_version.o is recompiled properly when the library/vm is rebuilt. > > Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK image manually after generating an archive. Also tested with Ioi?s test both locally and via Mach5. > > Thanks, > Jiangli > From jiangli.zhou at oracle.com Fri May 11 21:44:21 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 11 May 2018 14:44:21 -0700 Subject: RFR: 8199807 & 8202738: AppCDS performs overly restrictive path matching check In-Reply-To: References: Message-ID: <2D898ED9-D84F-4EDF-9DF3-88571396223D@oracle.com> Hi Erik, Thank you so much for investigating a proper fix for the vm_version.o issue. I will withdraw the build change from my original webrev. Thanks again for taking over the bug! Jiangli > On May 11, 2018, at 2:33 PM, Erik Joelsson wrote: > > Received: from [10.132.185.167] (/10.132.185.167) > by default (Oracle Beehive Gateway v4.0) > with ESMTP ; Fri, 11 May 2018 14:33:20 -0700 > Subject: Re: RFR: 8199807 & 8202738: AppCDS performs overly restrictive path > matching check > To: Jiangli Zhou , > "hotspot-runtime-dev at openjdk.java.net runtime" > , > build-dev > References: > From: Erik Joelsson > Organization: Oracle Corporation > Message-ID: > Date: Fri, 11 May 2018 14:33:20 -0700 > User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) > Gecko/20100101 Thunderbird/52.7.0 > MIME-Version: 1.0 > In-Reply-To: > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 8bit > Content-Language: en-US > > Hello, > > For the build change, it's very undesirable to always have to relink libjvm on every incremental build. Such a change cannot be accepted. > > I have a counter suggestion, which is still a bit of a hack, but it will cause vm_version.cpp to be recompiled (almost) every time libjvm.so needs to be relinked. The drawback is that compiling vm_version.cpp is now bound to happen absolutely last and so cannot happen in parallel with other compilations. > > Webrev: http://cr.openjdk.java.net/~erikj/8202738/webrev.01/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202738 > > /Erik > > >> On 2018-05-10 16:11, Jiangli Zhou wrote: >> Hi, >> >> Please review the following webrev that addresses the issue of copied/moved JDK image after generating a CDS archive. Thanks Karen Kinnear and Alan Baterman for initiating the investigation & discussions in this area (especially the ease of usage). Thanks Ioi for implementing a test case for moved JDK (JDK-8202935). >> >> webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/ >> RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921 >> >> The webrev includes the following three main parts: >> >> 1. Reduced check for JDK ?modules? image file at runtime. The runtime path to the ?modules? image is no longer required to the the same as dump time path. Runtime performs file size check only for the ?modules? image, which must match with the dump time ?modules? size. Invalidation of an outdated archive is achieved by the existing vm_version string check (the archived vm_version string must match with the runtime vm_version string). >> >> 2. Boot path check are now performed based on the content of the archive. Also added a new test case in BootClassPathMismatch.java and add more comments for existing test cases. >> >> 3. Fixed the stale vm_version string issue with incremental build. The issue was discovered during the work of 8199807. CDS uses vm_version string as part of the runtime validation check for archive. A stale vm_version string causes the CDS runtime to mistakenly accept an outdated archive. The fix is to make sure vm_version.o is recompiled properly when the library/vm is rebuilt. >> >> Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK image manually after generating an archive. Also tested with Ioi?s test both locally and via Mach5. >> >> Thanks, >> Jiangli >> > > Hello, > > For the build change, it's very undesirable to always have to relink libjvm on every incremental build. Such a change cannot be accepted. > > I have a counter suggestion, which is still a bit of a hack, but it will cause vm_version.cpp to be recompiled (almost) every time libjvm.so needs to be relinked. The drawback is that compiling vm_version.cpp is now bound to happen absolutely last and so cannot happen in parallel with other compilations. > > Webrev: http://cr.openjdk.java.net/~erikj/8202738/webrev.01/index.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202738 > > /Erik > > >> On 2018-05-10 16:11, Jiangli Zhou wrote: >> Hi, >> >> Please review the following webrev that addresses the issue of copied/moved JDK image after generating a CDS archive. Thanks Karen Kinnear and Alan Baterman for initiating the investigation & discussions in this area (especially the ease of usage). Thanks Ioi for implementing a test case for moved JDK (JDK-8202935). >> >> webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/ >> RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921 >> >> The webrev includes the following three main parts: >> >> 1. Reduced check for JDK ?modules? image file at runtime. The runtime path to the ?modules? image is no longer required to the the same as dump time path. Runtime performs file size check only for the ?modules? image, which must match with the dump time ?modules? size. Invalidation of an outdated archive is achieved by the existing vm_version string check (the archived vm_version string must match with the runtime vm_version string). >> >> 2. Boot path check are now performed based on the content of the archive. Also added a new test case in BootClassPathMismatch.java and add more comments for existing test cases. >> >> 3. Fixed the stale vm_version string issue with incremental build. The issue was discovered during the work of 8199807. CDS uses vm_version string as part of the runtime validation check for archive. A stale vm_version string causes the CDS runtime to mistakenly accept an outdated archive. The fix is to make sure vm_version.o is recompiled properly when the library/vm is rebuilt. >> >> Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK image manually after generating an archive. Also tested with Ioi?s test both locally and via Mach5. >> >> Thanks, >> Jiangli >> > From magnus.ihse.bursie at oracle.com Sun May 13 07:37:02 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sun, 13 May 2018 09:37:02 +0200 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> Message-ID: <9FF9E002-87F7-494C-82DE-66819E5C2773@oracle.com> Just to mess a bit more with you all, maybe this code does not really belong in "copy" "java.base", but rather more Hotspot and gensrc? The jvm.cfg is, after all, describing the hotspot build configuration. /Magnus > 11 maj 2018 kl. 19:46 skrev Erik Joelsson : > > Here is a new attempt. This time I'm pretty sure it produces the same jvm.cfg as all the predefined ones. It's easy to define a new default variant for specific configurations (as is done for windows-x86). It also handles the jvm variants that aren't server, client or minimal correctly (by treating them as server). > > The only real difference compared to before all this is that we no longer generate ALIASED_TO, but that only happened on very specific manual configurations that anyway. > > http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ > > /Erik > > >> On 2018-05-11 08:56, Erik Joelsson wrote: >>> On 2018-05-10 21:56, David Holmes wrote: >>>> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>>>> On 2018-05-10 15:52, David Holmes wrote: >>>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>>> Here is a new webrev where the IGNORED are added last. >>>>>> >>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>>> >>>>>> It will still change the default on windows-x86 however. If we really care about this, then perhaps we need to add a configure flag that allows the builder to pick the default variant. >>>>> >>>>> For 32-bit, client was always the default. That should be easy enough to maintain. >>>> No, if you look at: >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>>> >>>> It has server as default, whereas: >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>>> >>>> has client, so it varies on OS (and cpu type for legacy oracle closed >>> >>> Sorry I meant with respect to windows-x86, that being the subject of your comment. >> Right, then we are on the same page there. >>>> platforms). This can certainly be maintained, but the question is if anyone cares. There is a cost to maintaining exceptions. I think the best cause of action right now is to go with my current patch and if anyone thinks they need to control the default (i.e. set client default for certain configurations) we can add a configure flag later. >>> >>> I strongly disagree. For anyone who is producing a 32-bit Windows bundle for use by others, the behaviour will change from running client by default to running server! At best that will impact startup and performance; at worst startup scripts will fail if client specific flags are used. >> You are right, I will rework this to make sure we can generate different defaults for different configurations so that the current behavior is preserved for any of the current predefined jvm.cfg files. >>>>> Given these jvm.cfg files have been slated for removal for a very long time, I don't think you want to add new configure options related to them. Even this current work is rather a waste of everyone's time in the circumstance. >>>> You mean the launcher will be reworked? Perhaps it will. However, right now, the combination of JDK-8202919 and JDK-8202683 has quite drastically changed the contents of jvm.cfg, so I'm trying to restore some kind of order short term. >>> >>> Personally when the problem with Aleksey's original change was detected I would have rolled it back. If you want to restore order by other means, then do so, but that means restoring the previous contents of the jvm.cfg files to me. >> The problematic change has now been backed out but I will make another attempt at this change. >> >> /Erik > From adam.farley at uk.ibm.com Mon May 14 10:06:26 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 14 May 2018 11:06:26 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> Message-ID: Hi Phil, Would an acceptable compromise be to deliver the source code change and send the code to the upstream community, allowing them to include the fix if/when they are able? I believe Magnus was advocating this idea as well. See below. Best Regards Adam Farley > Same here. I would like to have this fix in, but do not want to go > over Phils head. > > I think Phil was the main objector, maybe he could reconsider?` > > Thanks, Thomas > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > wrote: > > I don't object, but it's not build code so I don't have the final say. > > > > /Magnus > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > Hi All, > > > > Does anyone have an objection to pushing this tiny change in? > > > > It doesn't break anything, it fixes a build break on two supported > > platforms, and it seems > > like we never refresh the code from upstream. > > > > - Adam > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > >> of logic required > >> to properly analyse the toolchain version string. > >> > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > >> and Make doesn't > >> seem to do substring stuff unless you mess around with shells. > >> > >> Plus, as people have said, it's better to solve problem x (or work around > >> a specific > >> instance of x) than to ignore the exception, even if the ignoring code is > >> toolchain- > >> specific. > >> > >> - Adam Farley > >> > >> > On 2018-03-27 18:44, Phil Race wrote: > >> > > >> >> As I said I prefer the make file change, since this is a change to an > >> >> upstream library. > >> > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > >> > reviewer. :) > >> > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > >> > complaint seems reasonable, and disabling it might cause us to miss other > >> > future errors. > >> > > >> > Why can't we push the source code fix, and also submit it upstream? > >> > > >> > /Magnus > >> > > >> > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > >> > 6b, so this code > >> > seems to have stood the test of time. I'm also unclear why the compiler > >> > would > >> > complain about that and not the one a few lines later > >> > > >> > > >> > 819 while (bits[i] == 0) /* find largest codelength still in > >> > use */ > >> > 820 i--; > >> > > >> > A push to jchuff.c will get blown away if/when we upgrade. > >> > A tool-chain specific fix in the makefile with an appropriate comment is > >> > more targeted. > >> > >> Phil, > >> > >> Returning to this. > >> > >> While I understand your reluctance to patch upstream code, let me point > >> out that we have not updated libjpeg a single time since the JDK was open > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page > >> on libjpeg, and this is the latest "uncontroversial" version of the source. > >> Versions 7 and up have proprietary extensions, which in turn has resulted in > >> multiple forks of libjpeg. As it stands, it seems unlikely that we will ever > >> replace libjpeg 6b with a simple upgrade from upstream. > >> > >> I therefore maintain my position that a source code fix would be the best > >> way forward here. > >> > >> /Magnus > >> > >> > > >> > > >> > -phil. > >> > > >> > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > >> > > >> > Hi all, > >> > > >> > > >> > just a friendly reminder. I would like to push this tiny fix because > >> > tripping over this on our linux s390x builds is annoying (yes, we can > >> > maintain patch queues, but this is a constant error source). > >> > > >> > > >> > I will wait for 24 more hours until a reaction. If no serious objections > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph > >> > langer are both Reviewers). > >> > > >> > > >> > Thanks! Thomas > >> > > >> > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > >> > wrote: > >> > > >> > Hi all, > >> > > >> > > >> > may I please have another review for this really trivial change. It > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix > >> > this. > >> > > >> > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > >> > webrev: > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > >> > > >> > > >> > This was contributed by Adam Farley at IBM. > >> > > >> > > >> > I already reviewed this. I also test-built on zlinux and it works. > >> > > >> > > >> > Thanks, Thomas > >> > > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >> > >> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.helin at oracle.com Mon May 14 11:23:43 2018 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 14 May 2018 13:23:43 +0200 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: References: Message-ID: On 05/08/2018 12:35 AM, Igor Ignatyev wrote: > Hi all, Hi Igor, On 05/08/2018 12:35 AM, Igor Ignatyev wrote: > could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: > - vmTestbase_vm_g1classunloading > - vmTestbase_vm_gc_compact > - vmTestbase_vm_gc_concurrent > - vmTestbase_vm_gc_container > - vmTestbase_vm_gc_juggle > - vmTestbase_vm_gc_locker > - vmTestbase_vm_gc_ref > - vmTestbase_vm_gc_misc This is a very welcome, and pretty massive, change :) I won't be able to read through each test, there are simple too many, but I can sample a few of them and have a look. On 05/08/2018 12:35 AM, Igor Ignatyev wrote: > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. I'm also assuming that to help the open sourcing of these tests, most comments will likely be deferred until later? If so, that is fine with me. On 05/08/2018 12:35 AM, Igor Ignatyev wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 > webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html Many of the tests are a bit cryptic, but that can be refactored later. Could you please file bugs for the two tests written in shell? Particularly parOld/test.sh should be trivial to rewrite in Java. It seems like a lot of tests contains a TEST.properties file with the content `exclusiveAccess.dirs=.`. Could this become the default value somewhere, so we don't need all those TEST.properties files? Thanks, Erik > Thanks, > -- Igor > From takiguc at linux.vnet.ibm.com Mon May 14 12:44:50 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 14 May 2018 21:44:50 +0900 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> Message-ID: <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> Hello Christoph. Our team tested your fixed code on Linux (RHEL7) and AIX (7.1). resetCompositionState() was missing in src/java.desktop/aix/classes/sun/awt/X11InputMethod.java ============================================================ --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May 09 09:05:32 2018 +0900 +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon May 14 21:25:50 2018 +0900 @@ -56,6 +56,21 @@ } /** + * Reset the composition state to the current composition state. + */ + protected void resetCompositionState() { + if (compositionEnableSupported && haveActiveClient()) { + try { + /* Restore the composition mode to the last saved composition + mode. */ + setCompositionEnabled(savedCompositionState); + } catch (UnsupportedOperationException e) { + compositionEnableSupported = false; + } + } + } + + /** * Activate input method. */ public synchronized void activate() { ============================================================ Otherwise, we could not find out any functional difference on Linux. we could not find out any functional difference between our modified code and your code on AIX. By code check, we found following difference. ============================================================ --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c Wed May 09 09:05:32 2018 +0900 +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c Mon May 14 21:25:50 2018 +0900 @@ -248,6 +248,10 @@ "flushText", "()V"); JNU_CHECK_EXCEPTION_RETURN(env, NULL); + if ((*env)->ExceptionOccurred(env)) { + (*env)->ExceptionDescribe(env); + (*env)->ExceptionClear(env); + } /* IMPORTANT: The order of the following calls is critical since "imInstance" may point to the global reference itself, if "freeX11InputMethodData" is called ============================================================ Did you remove this code intentionally ? Otherwise, I think the other changes were acceptable. Thanks, On 2018-05-09 00:24, Erik Joelsson wrote: > Build change looks good. > > /Erik > > > On 2018-05-08 02:54, Langer, Christoph wrote: >> Hi Eric, >> >> thanks for that excellent suggestion. I already thought there should >> be some means to do that but was not aware of how that could be >> accomplished. I updated the webrev in place. >> >> Thanks >> Christoph >> >>> -----Original Message----- >>> From: Erik Joelsson [mailto:erik.joelsson at oracle.com] >>> Sent: Freitag, 4. Mai 2018 17:45 >>> To: Langer, Christoph ; awt- >>> dev at openjdk.java.net >>> Cc: build-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net >>> Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for >>> AWT >>> Input Method Framework (IMF) >>> >>> Hello, >>> >>> It looks like what you are trying to achieve is to override >>> awt_InputMethod.c with an OS specific version of that file. We have a >>> construct for this in SetupNativeCompilation that should handle it >>> automatically, if you just list the source dirs in priority order. I >>> would suggest leveraging this by making this change instead: >>> >>> First in the list of LIBAWT_XAWT_DIRS (line 272), prepend a line like >>> this: >>> >>> $(wildcard >>> $(TOPDIR)/src/java.desktop/$(OPENJDK_TARGET_OS)/native/libawt_xawt) >>> \ >>> >>> /Erik >>> >>> >>> On 2018-05-04 07:07, Langer, Christoph wrote: >>>> Hi, >>>> >>>> please help reviewing the contribution of the support for the AIX >>>> Input >>> Method Editor (IME) in AWT's Input Method Framework. >>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.1/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201429 >>>> >>>> I took Ichiroh's initial proposal [1] and tried to integrate it >>>> better with >>> existing code. I have split >>> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java into >>>> a) a base class containing the common code: >>> src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java >>>> b) a specific class for the common Linux/Unixes: >>> src/java.desktop/unix/classes/sun/awt/X11InputMethod.java and >>>> c) a specific class for AIX: >>> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >>>> The AIX specific additions to the native code of >>> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c were >>> so >>> much that I decided to add a specific implementation file for AIX: >>> src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod_aix.c. >>> The >>> changes to the former file are some cleanups. >>>> I'm still in the process of testing the changes - but maybe you can >>>> run >>> further tests, especially on non-AIX unixes to make sure we didn't >>> break >>> something. >>>> Thanks & Best regards >>>> Christoph >>>> >>>> [1]: http://mail.openjdk.java.net/pipermail/awt-dev/2018- >>> April/013869.html From erik.gahlin at oracle.com Mon May 14 14:36:56 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 14 May 2018 16:36:56 +0200 Subject: RFR(XL): 8199712: Flight Recorder In-Reply-To: <5AE0612F.8060200@oracle.com> References: <5AE0612F.8060200@oracle.com> Message-ID: <5AF99F08.6060408@oracle.com> Here is an updated webrev: http://cr.openjdk.java.net/~egahlin/8199712.1/ [1] that incorporates: - build changes - new event prefix, i.e. "com.oracle.jdk.CPULoad" becomes "jdk.CPULoad" - obsolete command line options EnableTracing and UseLockedTracing - fixed typos in the Javadoc - simplified #include files RFEs have been filed for other issues, CSR is approved and tests pass. Erik and Markus [1] Parent: changeset: 50092:0e42d3120e51 user: clanger date: Sat May 12 10:26:42 2018 +0200 summary: 8202915: [JAXP] Performance enhancements and cleanups in com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator > Greetings, > > Could I have a review of 8199712: Flight Recorder > > As mentioned in the preview [1] the tracing backend has been removed. > Event metadata has been consolidated into a single XML file and event > classes are now generated by GenerateJfrFiles.java. > > Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64. > > For details about the feature, see the JEP: > https://bugs.openjdk.java.net/browse/JDK-8193393 > > Webrev: > http://cr.openjdk.java.net/~egahlin/8199712.0/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8199712 > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html > > Thanks > Erik and Markus From erik.joelsson at oracle.com Mon May 14 15:50:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 May 2018 08:50:25 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: <9FF9E002-87F7-494C-82DE-66819E5C2773@oracle.com> References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> <9FF9E002-87F7-494C-82DE-66819E5C2773@oracle.com> Message-ID: On 2018-05-13 00:37, Magnus Ihse Bursie wrote: > Just to mess a bit more with you all, maybe this code does not really belong in "copy" "java.base", but rather more Hotspot and gensrc? The jvm.cfg is, after all, describing the hotspot build configuration. Maybe, but I believe historically it's been considered part of the launcher logic rather than hotspot. I wouldn't agree with gensrc either, as the file is not being compiled or processed further after this. It could be argued to be gendata rather than copy, but the difference between those two is really not well defined. In reality, the difference bweteen gendata and copy is that copy does not depend on the buildtools targets to be run first, while gendata does. I prefer just keeping it where it is for now. /Erik > /Magnus > >> 11 maj 2018 kl. 19:46 skrev Erik Joelsson : >> >> Here is a new attempt. This time I'm pretty sure it produces the same jvm.cfg as all the predefined ones. It's easy to define a new default variant for specific configurations (as is done for windows-x86). It also handles the jvm variants that aren't server, client or minimal correctly (by treating them as server). >> >> The only real difference compared to before all this is that we no longer generate ALIASED_TO, but that only happened on very specific manual configurations that anyway. >> >> http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ >> >> /Erik >> >> >>> On 2018-05-11 08:56, Erik Joelsson wrote: >>>> On 2018-05-10 21:56, David Holmes wrote: >>>>> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>>>>> On 2018-05-10 15:52, David Holmes wrote: >>>>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>>>> Here is a new webrev where the IGNORED are added last. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>>>> >>>>>>> It will still change the default on windows-x86 however. If we really care about this, then perhaps we need to add a configure flag that allows the builder to pick the default variant. >>>>>> For 32-bit, client was always the default. That should be easy enough to maintain. >>>>> No, if you look at: >>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>>>> >>>>> It has server as default, whereas: >>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>>>> >>>>> has client, so it varies on OS (and cpu type for legacy oracle closed >>>> Sorry I meant with respect to windows-x86, that being the subject of your comment. >>> Right, then we are on the same page there. >>>>> platforms). This can certainly be maintained, but the question is if anyone cares. There is a cost to maintaining exceptions. I think the best cause of action right now is to go with my current patch and if anyone thinks they need to control the default (i.e. set client default for certain configurations) we can add a configure flag later. >>>> I strongly disagree. For anyone who is producing a 32-bit Windows bundle for use by others, the behaviour will change from running client by default to running server! At best that will impact startup and performance; at worst startup scripts will fail if client specific flags are used. >>> You are right, I will rework this to make sure we can generate different defaults for different configurations so that the current behavior is preserved for any of the current predefined jvm.cfg files. >>>>>> Given these jvm.cfg files have been slated for removal for a very long time, I don't think you want to add new configure options related to them. Even this current work is rather a waste of everyone's time in the circumstance. >>>>> You mean the launcher will be reworked? Perhaps it will. However, right now, the combination of JDK-8202919 and JDK-8202683 has quite drastically changed the contents of jvm.cfg, so I'm trying to restore some kind of order short term. >>>> Personally when the problem with Aleksey's original change was detected I would have rolled it back. If you want to restore order by other means, then do so, but that means restoring the previous contents of the jvm.cfg files to me. >>> The problematic change has now been backed out but I will make another attempt at this change. >>> >>> /Erik From erik.joelsson at oracle.com Mon May 14 16:05:21 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 May 2018 09:05:21 -0700 Subject: RFR(XL): 8199712: Flight Recorder In-Reply-To: <5AF99F08.6060408@oracle.com> References: <5AE0612F.8060200@oracle.com> <5AF99F08.6060408@oracle.com> Message-ID: Oh, I missed the new makefiles last time I looked at this. in Copy-jdk.jfr.gmk, everything looks like it's indented an extra 4 steps. I'm assuming this is because it used to be conditional in the previous closed file. GensrcJfr.gmk, line 94, please move )) to the left. Looking closer at GensrcJfr.gmk, The macro SetupJfrGeneration looks like it is only called once. This could be greatly simplified by just taking the body of the macro and inlining all the inputs. This of course unless you see a need in the future to generate additional files using the jfr tool. /Erik On 2018-05-14 07:36, Erik Gahlin wrote: > Here is an updated webrev: > > http://cr.openjdk.java.net/~egahlin/8199712.1/ [1] > > that incorporates: > > - build changes > - new event prefix, i.e. "com.oracle.jdk.CPULoad" becomes "jdk.CPULoad" > - obsolete command line options EnableTracing and UseLockedTracing > - fixed typos in the Javadoc > - simplified #include files > > RFEs have been filed for other issues, CSR is approved and tests pass. > > Erik and Markus > > [1] Parent: > > changeset:?? 50092:0e42d3120e51 > > user:??????? clanger > date:??????? Sat May 12 10:26:42 2018 +0200 > summary:???? 8202915: [JAXP] Performance enhancements and cleanups in > com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator > > >> Greetings, >> >> Could I have a review of 8199712: Flight Recorder >> >> As mentioned in the preview [1] the tracing backend has been removed. >> Event metadata has been consolidated into a single XML file and event >> classes are now generated by GenerateJfrFiles.java. >> >> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64. >> >> For details about the feature, see the JEP: >> https://bugs.openjdk.java.net/browse/JDK-8193393 >> >> Webrev: >> http://cr.openjdk.java.net/~egahlin/8199712.0/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8199712 >> >> [1] >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html >> >> Thanks >> Erik and Markus > From shade at redhat.com Mon May 14 16:24:30 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 May 2018 18:24:30 +0200 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> Message-ID: On 05/11/2018 07:46 PM, Erik Joelsson wrote: > Here is a new attempt. This time I'm pretty sure it produces the same jvm.cfg as all the predefined > ones. It's easy to define a new default variant for specific configurations (as is done for > windows-x86). It also handles the jvm variants that aren't server, client or minimal correctly (by > treating them as server). > > The only real difference compared to before all this is that we no longer generate ALIASED_TO, but > that only happened on very specific manual configurations that anyway. > > http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ Thanks for doing this! This looks good to me. -Aleksey From mikhailo.seledtsov at oracle.com Mon May 14 17:54:36 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Mon, 14 May 2018 10:54:36 -0700 Subject: RFR(L) : 8199384 : [TESTBUG] Open source VM testbase MLVM tests In-Reply-To: <53E4CA40-DE86-41A2-A1BE-239BE1D85069@oracle.com> References: <53E4CA40-DE86-41A2-A1BE-239BE1D85069@oracle.com> Message-ID: Changes look good to me, Misha On 05/09/2018 02:09 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199384/webrev.00/index.html >> 61414 lines changed: 61414 ins; 0 del; 0 mod; > Hi all, > > could you please review this patch which open sources MLVM tests from VM testbase? > > these tests were developed in early days of JSR292 to test different aspects of MethodHandles and invokedynamic. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199384 > webrev: http://cr.openjdk.java.net/~iignatyev//8199384/webrev.00/index.html > testing: :vmTestbase_vm_mlvm test group > > Thanks, > -- Igor > From leonid.mesnik at oracle.com Mon May 14 21:04:18 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 14 May 2018 14:04:18 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests In-Reply-To: <5AF5C07B.1080909@oracle.com> References: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> <5AF5C07B.1080909@oracle.com> Message-ID: <8BA2B023-E947-4EF8-9D97-EBA28BAA07E2@oracle.com> Misha Thank you for review. I still need one more review from 'R'eviewer. Leonid > On May 11, 2018, at 9:10 AM, Mikhailo Seledtsov wrote: > > Looks good to me, > > Misha > > On 5/8/18, 2:23 PM, Leonid Mesnik wrote: >> Hi >> >> Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. >> They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. >> >> The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. >> >> I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8199271 From leonid.mesnik at oracle.com Mon May 14 21:04:30 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 14 May 2018 14:04:30 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests In-Reply-To: <4f0ea090-94c9-ffd7-3852-a9a9d14e8af8@oracle.com> References: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> <4f0ea090-94c9-ffd7-3852-a9a9d14e8af8@oracle.com> Message-ID: <8FBFB3E8-2E13-42F8-82F3-6E601E900AED@oracle.com> Thank you for review. Leonid > On May 8, 2018, at 2:41 PM, Erik Joelsson wrote: > > Build changes look good. > > /Erik > > > On 2018-05-08 14:23, Leonid Mesnik wrote: >> Hi >> >> Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. >> They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. >> >> The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. >> >> I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8199271 > From magnus.ihse.bursie at oracle.com Mon May 14 21:14:36 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 May 2018 23:14:36 +0200 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> <9FF9E002-87F7-494C-82DE-66819E5C2773@oracle.com> Message-ID: On 2018-05-14 17:50, Erik Joelsson wrote: > On 2018-05-13 00:37, Magnus Ihse Bursie wrote: >> Just to mess a bit more with you all, maybe this code does not really >> belong in "copy" "java.base", but rather more Hotspot and gensrc? The >> jvm.cfg is, after all, describing the hotspot build configuration. > Maybe, but I believe historically it's been considered part of the > launcher logic rather than hotspot. I wouldn't agree with gensrc > either, as the file is not being compiled or processed further after > this. It could be argued to be gendata rather than copy, but the > difference between those two is really not well defined. In reality, > the difference bweteen gendata and copy is that copy does not depend > on the buildtools targets to be run first, while gendata does. > > I prefer just keeping it where it is for now. Hm. Oh well. I'm happy enough that you're cleaning it up, so I'll leave it to you. :) /Magnus > > /Erik >> /Magnus >> >>> 11 maj 2018 kl. 19:46 skrev Erik Joelsson : >>> >>> Here is a new attempt. This time I'm pretty sure it produces the >>> same jvm.cfg as all the predefined ones. It's easy to define a new >>> default variant for specific configurations (as is done for >>> windows-x86). It also handles the jvm variants that aren't server, >>> client or minimal correctly (by treating them as server). >>> >>> The only real difference compared to before all this is that we no >>> longer generate ALIASED_TO, but that only happened on very specific >>> manual configurations that anyway. >>> >>> http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ >>> >>> /Erik >>> >>> >>>> On 2018-05-11 08:56, Erik Joelsson wrote: >>>>> On 2018-05-10 21:56, David Holmes wrote: >>>>>> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>>>>>> On 2018-05-10 15:52, David Holmes wrote: >>>>>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>>>>> Here is a new webrev where the IGNORED are added last. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>>>>> >>>>>>>> It will still change the default on windows-x86 however. If we >>>>>>>> really care about this, then perhaps we need to add a configure >>>>>>>> flag that allows the builder to pick the default variant. >>>>>>> For 32-bit, client was always the default. That should be easy >>>>>>> enough to maintain. >>>>>> No, if you look at: >>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>>>>> >>>>>> >>>>>> It has server as default, whereas: >>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>>>>> >>>>>> >>>>>> has client, so it varies on OS (and cpu type for legacy oracle >>>>>> closed >>>>> Sorry I meant with respect to windows-x86, that being the subject >>>>> of your comment. >>>> Right, then we are on the same page there. >>>>>> platforms). This can certainly be maintained, but the question is >>>>>> if anyone cares. There is a cost to maintaining exceptions. I >>>>>> think the best cause of action right now is to go with my current >>>>>> patch and if anyone thinks they need to control the default (i.e. >>>>>> set client default for certain configurations) we can add a >>>>>> configure flag later. >>>>> I strongly disagree. For anyone who is producing a 32-bit Windows >>>>> bundle for use by others, the behaviour will change from running >>>>> client by default to running server! At best that will impact >>>>> startup and performance; at worst startup scripts will fail if >>>>> client specific flags are used. >>>> You are right, I will rework this to make sure we can generate >>>> different defaults for different configurations so that the current >>>> behavior is preserved for any of the current predefined jvm.cfg files. >>>>>>> Given these jvm.cfg files have been slated for removal for a >>>>>>> very long time, I don't think you want to add new configure >>>>>>> options related to them. Even this current work is rather a >>>>>>> waste of everyone's time in the circumstance. >>>>>> You mean the launcher will be reworked? Perhaps it will. However, >>>>>> right now, the combination of JDK-8202919 and JDK-8202683 has >>>>>> quite drastically changed the contents of jvm.cfg, so I'm trying >>>>>> to restore some kind of order short term. >>>>> Personally when the problem with Aleksey's original change was >>>>> detected I would have rolled it back. If you want to restore order >>>>> by other means, then do so, but that means restoring the previous >>>>> contents of the jvm.cfg files to me. >>>> The problematic change has now been backed out but I will make >>>> another attempt at this change. >>>> >>>> /Erik > From magnus.ihse.bursie at oracle.com Mon May 14 21:36:07 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 May 2018 23:36:07 +0200 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> Message-ID: On 2018-05-11 19:46, Erik Joelsson wrote: > Here is a new attempt. This time I'm pretty sure it produces the same > jvm.cfg as all the predefined ones. It's easy to define a new default > variant for specific configurations (as is done for windows-x86). It > also handles the jvm variants that aren't server, client or minimal > correctly (by treating them as server). > > The only real difference compared to before all this is that we no > longer generate ALIASED_TO, but that only happened on very specific > manual configurations that anyway. > > http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ This looks good to me. I missed that you had sent this out earlier. /Magnus > > /Erik > > > On 2018-05-11 08:56, Erik Joelsson wrote: >> On 2018-05-10 21:56, David Holmes wrote: >>> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>>> On 2018-05-10 15:52, David Holmes wrote: >>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>>> Here is a new webrev where the IGNORED are added last. >>>>>> >>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>>> >>>>>> It will still change the default on windows-x86 however. If we >>>>>> really care about this, then perhaps we need to add a configure >>>>>> flag that allows the builder to pick the default variant. >>>>> >>>>> For 32-bit, client was always the default. That should be easy >>>>> enough to maintain. >>>>> >>>> No, if you look at: >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>>> >>>> >>>> It has server as default, whereas: >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>>> >>>> >>>> has client, so it varies on OS (and cpu type for legacy oracle closed >>> >>> Sorry I meant with respect to windows-x86, that being the subject of >>> your comment. >>> >> Right, then we are on the same page there. >>>> platforms). This can certainly be maintained, but the question is >>>> if anyone cares. There is a cost to maintaining exceptions. I think >>>> the best cause of action right now is to go with my current patch >>>> and if anyone thinks they need to control the default (i.e. set >>>> client default for certain configurations) we can add a configure >>>> flag later. >>> >>> I strongly disagree. For anyone who is producing a 32-bit Windows >>> bundle for use by others, the behaviour will change from running >>> client by default to running server! At best that will impact >>> startup and performance; at worst startup scripts will fail if >>> client specific flags are used. >>> >> You are right, I will rework this to make sure we can generate >> different defaults for different configurations so that the current >> behavior is preserved for any of the current predefined jvm.cfg files. >>>>> Given these jvm.cfg files have been slated for removal for a very >>>>> long time, I don't think you want to add new configure options >>>>> related to them. Even this current work is rather a waste of >>>>> everyone's time in the circumstance. >>>>> >>>> You mean the launcher will be reworked? Perhaps it will. However, >>>> right now, the combination of JDK-8202919 and JDK-8202683 has quite >>>> drastically changed the contents of jvm.cfg, so I'm trying to >>>> restore some kind of order short term. >>> >>> Personally when the problem with Aleksey's original change was >>> detected I would have rolled it back. If you want to restore order >>> by other means, then do so, but that means restoring the previous >>> contents of the jvm.cfg files to me. >>> >> The problematic change has now been backed out but I will make >> another attempt at this change. >> >> /Erik > From magnus.ihse.bursie at oracle.com Mon May 14 21:53:58 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 May 2018 23:53:58 +0200 Subject: RFR(XL): 8199712: Flight Recorder In-Reply-To: References: <5AE0612F.8060200@oracle.com> <5AF99F08.6060408@oracle.com> Message-ID: On 2018-05-14 18:05, Erik Joelsson wrote: > Oh, I missed the new makefiles last time I looked at this. > > in Copy-jdk.jfr.gmk, everything looks like it's indented an extra 4 > steps. I'm assuming this is because it used to be conditional in the > previous closed file. > > GensrcJfr.gmk, line 94, please move )) to the left. > > Looking closer at GensrcJfr.gmk, The macro SetupJfrGeneration looks > like it is only called once. This could be greatly simplified by just > taking the body of the macro and inlining all the inputs. This of > course unless you see a need in the future to generate additional > files using the jfr tool. Also, the JFR_DEPS variable does not seem to be used. Is it a left-over from a previous attempt to get proper dependencies? (The current solution looks like it should work.) /Magnus > > /Erik > > On 2018-05-14 07:36, Erik Gahlin wrote: >> Here is an updated webrev: >> >> http://cr.openjdk.java.net/~egahlin/8199712.1/ [1] >> >> that incorporates: >> >> - build changes >> - new event prefix, i.e. "com.oracle.jdk.CPULoad" becomes "jdk.CPULoad" >> - obsolete command line options EnableTracing and UseLockedTracing >> - fixed typos in the Javadoc >> - simplified #include files >> >> RFEs have been filed for other issues, CSR is approved and tests pass. >> >> Erik and Markus >> >> [1] Parent: >> >> changeset:?? 50092:0e42d3120e51 >> >> user:??????? clanger >> date:??????? Sat May 12 10:26:42 2018 +0200 >> summary:???? 8202915: [JAXP] Performance enhancements and cleanups in >> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator >> >> >>> Greetings, >>> >>> Could I have a review of 8199712: Flight Recorder >>> >>> As mentioned in the preview [1] the tracing backend has been >>> removed. Event metadata has been consolidated into a single XML file >>> and event classes are now generated by GenerateJfrFiles.java. >>> >>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64. >>> >>> For details about the feature, see the JEP: >>> https://bugs.openjdk.java.net/browse/JDK-8193393 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8199712.0/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8199712 >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html >>> >>> Thanks >>> Erik and Markus >> > From magnus.ihse.bursie at oracle.com Mon May 14 21:56:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 May 2018 23:56:37 +0200 Subject: RFR: 8199807 & 8202738: AppCDS performs overly restrictive path matching check In-Reply-To: References: Message-ID: On 2018-05-11 23:33, Erik Joelsson wrote: > Hello, > > For the build change, it's very undesirable to always have to relink > libjvm on every incremental build. Such a change cannot be accepted. > > I have a counter suggestion, which is still a bit of a hack, but it > will cause vm_version.cpp to be recompiled (almost) every time > libjvm.so needs to be relinked. The drawback is that compiling > vm_version.cpp is now bound to happen absolutely last and so cannot > happen in parallel with other compilations. > > Webrev: http://cr.openjdk.java.net/~erikj/8202738/webrev.01/index.html This looks as good as it can get for a simple fix, but I'd still like to get on the record that I think the way we handle both __TIME__/__DATE__ in hotspot, and ad-hoc version strings in general, is broken and leave much to be desired. /Magnus > > Bug: https://bugs.openjdk.java.net/browse/JDK-8202738 > > /Erik > > > On 2018-05-10 16:11, Jiangli Zhou wrote: >> Hi, >> >> Please review the following webrev that addresses the issue of >> copied/moved JDK image after generating a CDS archive. Thanks Karen >> Kinnear and Alan Baterman for initiating the investigation & >> discussions in this area (especially the ease of usage). Thanks Ioi >> for implementing a test case for moved JDK (JDK-8202935). >> >> webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/ >> RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921 >> >> The webrev includes the following three main parts: >> >> 1. Reduced check for JDK ?modules? image file at runtime. The runtime >> path to the ?modules? image is no longer required to the the same as >> dump time path. Runtime performs file size check only for the >> ?modules? image, which must match with the dump time ?modules? size. >> Invalidation of an outdated archive is achieved by the existing >> vm_version string check (the archived vm_version string must match >> with the runtime vm_version string). >> >> 2. Boot path check are now performed based on the content of the >> archive. Also added a new test case in BootClassPathMismatch.java and >> add more comments for existing test cases. >> >> 3. Fixed the stale vm_version string issue with incremental build. >> The issue was discovered during the work of 8199807. CDS uses >> vm_version string as part of the runtime validation check for >> archive. A stale vm_version string causes the CDS runtime to >> mistakenly accept an outdated archive. The fix is to make sure >> vm_version.o is recompiled properly when the library/vm is rebuilt. >> >> Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK >> image manually after generating an archive. Also tested with Ioi?s >> test both locally and via Mach5. >> >> Thanks, >> Jiangli >> > From david.holmes at oracle.com Mon May 14 22:02:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 May 2018 08:02:15 +1000 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> Message-ID: Hi Erik, As long as the end result is a jvm.cfg that matches the current ones in the repo then this looks fine. Thanks, David On 12/05/2018 3:46 AM, Erik Joelsson wrote: > Here is a new attempt. This time I'm pretty sure it produces the same > jvm.cfg as all the predefined ones. It's easy to define a new default > variant for specific configurations (as is done for windows-x86). It > also handles the jvm variants that aren't server, client or minimal > correctly (by treating them as server). > > The only real difference compared to before all this is that we no > longer generate ALIASED_TO, but that only happened on very specific > manual configurations that anyway. > > http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ > > /Erik > > > On 2018-05-11 08:56, Erik Joelsson wrote: >> On 2018-05-10 21:56, David Holmes wrote: >>> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>>> On 2018-05-10 15:52, David Holmes wrote: >>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>>> Here is a new webrev where the IGNORED are added last. >>>>>> >>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>>> >>>>>> It will still change the default on windows-x86 however. If we >>>>>> really care about this, then perhaps we need to add a configure >>>>>> flag that allows the builder to pick the default variant. >>>>> >>>>> For 32-bit, client was always the default. That should be easy >>>>> enough to maintain. >>>>> >>>> No, if you look at: >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>>> >>>> >>>> It has server as default, whereas: >>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>>> >>>> >>>> has client, so it varies on OS (and cpu type for legacy oracle closed >>> >>> Sorry I meant with respect to windows-x86, that being the subject of >>> your comment. >>> >> Right, then we are on the same page there. >>>> platforms). This can certainly be maintained, but the question is if >>>> anyone cares. There is a cost to maintaining exceptions. I think the >>>> best cause of action right now is to go with my current patch and if >>>> anyone thinks they need to control the default (i.e. set client >>>> default for certain configurations) we can add a configure flag later. >>> >>> I strongly disagree. For anyone who is producing a 32-bit Windows >>> bundle for use by others, the behaviour will change from running >>> client by default to running server! At best that will impact startup >>> and performance; at worst startup scripts will fail if client >>> specific flags are used. >>> >> You are right, I will rework this to make sure we can generate >> different defaults for different configurations so that the current >> behavior is preserved for any of the current predefined jvm.cfg files. >>>>> Given these jvm.cfg files have been slated for removal for a very >>>>> long time, I don't think you want to add new configure options >>>>> related to them. Even this current work is rather a waste of >>>>> everyone's time in the circumstance. >>>>> >>>> You mean the launcher will be reworked? Perhaps it will. However, >>>> right now, the combination of JDK-8202919 and JDK-8202683 has quite >>>> drastically changed the contents of jvm.cfg, so I'm trying to >>>> restore some kind of order short term. >>> >>> Personally when the problem with Aleksey's original change was >>> detected I would have rolled it back. If you want to restore order by >>> other means, then do so, but that means restoring the previous >>> contents of the jvm.cfg files to me. >>> >> The problematic change has now been backed out but I will make another >> attempt at this change. >> >> /Erik > From jiangli.zhou at oracle.com Mon May 14 22:33:43 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 14 May 2018 15:33:43 -0700 Subject: RFR: 8199807 & 8202738: AppCDS performs overly restrictive path matching check In-Reply-To: References: Message-ID: > On May 14, 2018, at 2:56 PM, Magnus Ihse Bursie wrote: > > On 2018-05-11 23:33, Erik Joelsson wrote: >> Hello, >> >> For the build change, it's very undesirable to always have to relink libjvm on every incremental build. Such a change cannot be accepted. >> >> I have a counter suggestion, which is still a bit of a hack, but it will cause vm_version.cpp to be recompiled (almost) every time libjvm.so needs to be relinked. The drawback is that compiling vm_version.cpp is now bound to happen absolutely last and so cannot happen in parallel with other compilations. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8202738/webrev.01/index.html > > This looks as good as it can get for a simple fix, but I'd still like to get on the record that I think the way we handle both __TIME__/__DATE__ in hotspot, and ad-hoc version strings in general, is broken and leave much to be desired. +1 on the above (both the review and the usage of __TIME__/__DATE__). Thanks! Jiangli > > /Magnus > > > >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738 >> >> /Erik >> >> >> On 2018-05-10 16:11, Jiangli Zhou wrote: >>> Hi, >>> >>> Please review the following webrev that addresses the issue of copied/moved JDK image after generating a CDS archive. Thanks Karen Kinnear and Alan Baterman for initiating the investigation & discussions in this area (especially the ease of usage). Thanks Ioi for implementing a test case for moved JDK (JDK-8202935). >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8199807_8202738/webrev.00/ >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8199807?filter=14921 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202738?filter=14921 >>> >>> The webrev includes the following three main parts: >>> >>> 1. Reduced check for JDK ?modules? image file at runtime. The runtime path to the ?modules? image is no longer required to the the same as dump time path. Runtime performs file size check only for the ?modules? image, which must match with the dump time ?modules? size. Invalidation of an outdated archive is achieved by the existing vm_version string check (the archived vm_version string must match with the runtime vm_version string). >>> >>> 2. Boot path check are now performed based on the content of the archive. Also added a new test case in BootClassPathMismatch.java and add more comments for existing test cases. >>> >>> 3. Fixed the stale vm_version string issue with incremental build. The issue was discovered during the work of 8199807. CDS uses vm_version string as part of the runtime validation check for archive. A stale vm_version string causes the CDS runtime to mistakenly accept an outdated archive. The fix is to make sure vm_version.o is recompiled properly when the library/vm is rebuilt. >>> >>> Tested with hs-tier1-4 and jdk-tier1-2. Tested by relocating the JDK image manually after generating an archive. Also tested with Ioi?s test both locally and via Mach5. >>> >>> Thanks, >>> Jiangli >>> >> > From kumar.x.srinivasan at oracle.com Mon May 14 23:27:09 2018 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 14 May 2018 16:27:09 -0700 Subject: RFR: JDK-8202920: jvm.cfg generation incorrect In-Reply-To: References: <0f1f4b16-0f34-a750-cb8a-88c71b8e9d3e@oracle.com> <2b6735c8-0666-0a83-fba8-d988d3c821f7@oracle.com> <9a59ec58-9272-d54b-edbd-9448479b663f@oracle.com> <62970b4c-6a9e-0f2d-23e7-8c4ce907706f@oracle.com> Message-ID: <5AFA1B4D.8010604@oracle.com> +1 Kumar > Hi Erik, > > As long as the end result is a jvm.cfg that matches the current ones > in the repo then this looks fine. > > Thanks, > David > > On 12/05/2018 3:46 AM, Erik Joelsson wrote: >> Here is a new attempt. This time I'm pretty sure it produces the same >> jvm.cfg as all the predefined ones. It's easy to define a new default >> variant for specific configurations (as is done for windows-x86). It >> also handles the jvm variants that aren't server, client or minimal >> correctly (by treating them as server). >> >> The only real difference compared to before all this is that we no >> longer generate ALIASED_TO, but that only happened on very specific >> manual configurations that anyway. >> >> http://cr.openjdk.java.net/~erikj/8202920/webrev.03/ >> >> /Erik >> >> >> On 2018-05-11 08:56, Erik Joelsson wrote: >>> On 2018-05-10 21:56, David Holmes wrote: >>>> On 11/05/2018 10:03 AM, Erik Joelsson wrote: >>>>> On 2018-05-10 15:52, David Holmes wrote: >>>>>> On 11/05/2018 8:41 AM, Erik Joelsson wrote: >>>>>>> Here is a new webrev where the IGNORED are added last. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/ >>>>>>> >>>>>>> It will still change the default on windows-x86 however. If we >>>>>>> really care about this, then perhaps we need to add a configure >>>>>>> flag that allows the builder to pick the default variant. >>>>>> >>>>>> For 32-bit, client was always the default. That should be easy >>>>>> enough to maintain. >>>>>> >>>>> No, if you look at: >>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/unix/conf/i586/jvm.cfg-.html >>>>> >>>>> >>>>> It has server as default, whereas: >>>>> http://cr.openjdk.java.net/~erikj/8202920/webrev.02/src/java.base/windows/conf/i586/jvm.cfg-.html >>>>> >>>>> >>>>> has client, so it varies on OS (and cpu type for legacy oracle closed >>>> >>>> Sorry I meant with respect to windows-x86, that being the subject >>>> of your comment. >>>> >>> Right, then we are on the same page there. >>>>> platforms). This can certainly be maintained, but the question is >>>>> if anyone cares. There is a cost to maintaining exceptions. I >>>>> think the best cause of action right now is to go with my current >>>>> patch and if anyone thinks they need to control the default (i.e. >>>>> set client default for certain configurations) we can add a >>>>> configure flag later. >>>> >>>> I strongly disagree. For anyone who is producing a 32-bit Windows >>>> bundle for use by others, the behaviour will change from running >>>> client by default to running server! At best that will impact >>>> startup and performance; at worst startup scripts will fail if >>>> client specific flags are used. >>>> >>> You are right, I will rework this to make sure we can generate >>> different defaults for different configurations so that the current >>> behavior is preserved for any of the current predefined jvm.cfg files. >>>>>> Given these jvm.cfg files have been slated for removal for a very >>>>>> long time, I don't think you want to add new configure options >>>>>> related to them. Even this current work is rather a waste of >>>>>> everyone's time in the circumstance. >>>>>> >>>>> You mean the launcher will be reworked? Perhaps it will. However, >>>>> right now, the combination of JDK-8202919 and JDK-8202683 has >>>>> quite drastically changed the contents of jvm.cfg, so I'm trying >>>>> to restore some kind of order short term. >>>> >>>> Personally when the problem with Aleksey's original change was >>>> detected I would have rolled it back. If you want to restore order >>>> by other means, then do so, but that means restoring the previous >>>> contents of the jvm.cfg files to me. >>>> >>> The problematic change has now been backed out but I will make >>> another attempt at this change. >>> >>> /Erik >> From markus.gronlund at oracle.com Tue May 15 07:14:14 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 15 May 2018 00:14:14 -0700 (PDT) Subject: RFR(XL): 8199712: Flight Recorder In-Reply-To: References: <5AE0612F.8060200@oracle.com> <5AF99F08.6060408@oracle.com> Message-ID: Thanks Magnus, About JFR_DEPS, it is somewhat of a remnant from the previous system. Looks like the previous system eventually took the local variable and appended it to DEPS (is this a global where all dependencies are tracked?) Can we do the following instead to ensure file edits trigger recompilation? DEPS := $(METADATA_XML) DEPS := $(METADATA_XSD) Thanks Markus -----Original Message----- From: Magnus Ihse Bursie Sent: den 14 maj 2018 23:54 To: Erik Joelsson ; Erik Gahlin ; hotspot-dev Source Developers Cc: hotspot-jfr-dev at openjdk.java.net; build-dev at openjdk.java.net Subject: Re: RFR(XL): 8199712: Flight Recorder On 2018-05-14 18:05, Erik Joelsson wrote: > Oh, I missed the new makefiles last time I looked at this. > > in Copy-jdk.jfr.gmk, everything looks like it's indented an extra 4 > steps. I'm assuming this is because it used to be conditional in the > previous closed file. > > GensrcJfr.gmk, line 94, please move )) to the left. > > Looking closer at GensrcJfr.gmk, The macro SetupJfrGeneration looks > like it is only called once. This could be greatly simplified by just > taking the body of the macro and inlining all the inputs. This of > course unless you see a need in the future to generate additional > files using the jfr tool. Also, the JFR_DEPS variable does not seem to be used. Is it a left-over from a previous attempt to get proper dependencies? (The current solution looks like it should work.) /Magnus > > /Erik > > On 2018-05-14 07:36, Erik Gahlin wrote: >> Here is an updated webrev: >> >> http://cr.openjdk.java.net/~egahlin/8199712.1/ [1] >> >> that incorporates: >> >> - build changes >> - new event prefix, i.e. "com.oracle.jdk.CPULoad" becomes "jdk.CPULoad" >> - obsolete command line options EnableTracing and UseLockedTracing >> - fixed typos in the Javadoc >> - simplified #include files >> >> RFEs have been filed for other issues, CSR is approved and tests pass. >> >> Erik and Markus >> >> [1] Parent: >> >> changeset:?? 50092:0e42d3120e51 >> >> user:??????? clanger >> date:??????? Sat May 12 10:26:42 2018 +0200 >> summary:???? 8202915: [JAXP] Performance enhancements and cleanups in >> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator >> >> >>> Greetings, >>> >>> Could I have a review of 8199712: Flight Recorder >>> >>> As mentioned in the preview [1] the tracing backend has been >>> removed. Event metadata has been consolidated into a single XML file >>> and event classes are now generated by GenerateJfrFiles.java. >>> >>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64. >>> >>> For details about the feature, see the JEP: >>> https://bugs.openjdk.java.net/browse/JDK-8193393 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8199712.0/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8199712 >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359 >>> .html >>> >>> Thanks >>> Erik and Markus >> > From erik.gahlin at oracle.com Tue May 15 13:12:25 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 15 May 2018 15:12:25 +0200 Subject: RFR(XL): 8199712: Flight Recorder In-Reply-To: References: <5AE0612F.8060200@oracle.com> <5AF99F08.6060408@oracle.com> Message-ID: <5AFADCB9.4060904@oracle.com> On 2018-05-14 18:05, Erik Joelsson wrote: > Oh, I missed the new makefiles last time I looked at this. > > in Copy-jdk.jfr.gmk, everything looks like it's indented an extra 4 > steps. I'm assuming this is because it used to be conditional in the > previous closed file. Will fix! > > GensrcJfr.gmk, line 94, please move )) to the left. > Will fix! > Looking closer at GensrcJfr.gmk, The macro SetupJfrGeneration looks > like it is only called once. This could be greatly simplified by just > taking the body of the macro and inlining all the inputs. This of > course unless you see a need in the future to generate additional > files using the jfr tool. Will fix this in a follow up bug: https://bugs.openjdk.java.net/browse/JDK-8203221 Thanks Erik > > /Erik > > On 2018-05-14 07:36, Erik Gahlin wrote: >> Here is an updated webrev: >> >> http://cr.openjdk.java.net/~egahlin/8199712.1/ [1] >> >> that incorporates: >> >> - build changes >> - new event prefix, i.e. "com.oracle.jdk.CPULoad" becomes "jdk.CPULoad" >> - obsolete command line options EnableTracing and UseLockedTracing >> - fixed typos in the Javadoc >> - simplified #include files >> >> RFEs have been filed for other issues, CSR is approved and tests pass. >> >> Erik and Markus >> >> [1] Parent: >> >> changeset: 50092:0e42d3120e51 >> >> user: clanger >> date: Sat May 12 10:26:42 2018 +0200 >> summary: 8202915: [JAXP] Performance enhancements and cleanups in >> com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator >> >> >>> Greetings, >>> >>> Could I have a review of 8199712: Flight Recorder >>> >>> As mentioned in the preview [1] the tracing backend has been >>> removed. Event metadata has been consolidated into a single XML file >>> and event classes are now generated by GenerateJfrFiles.java. >>> >>> Tests have been run on Linux-x64, Windows-x64 and MaxOSX-x64. >>> >>> For details about the feature, see the JEP: >>> https://bugs.openjdk.java.net/browse/JDK-8193393 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~egahlin/8199712.0/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8199712 >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-April/031359.html >>> >>> Thanks >>> Erik and Markus >> > From sgehwolf at redhat.com Tue May 15 14:07:15 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 May 2018 16:07:15 +0200 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> Message-ID: Hi, On Fri, 2018-05-11 at 12:55 +0900, Yasumasa Suenaga wrote: > Hi, > > I found 1 GCC optimization issue, but it is not enough. > > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/gdb-before.txt > > I traced class loading from `modules`. Above log is copy of GDB > console in ImageFileReader::verify_location(). > The code expects `*next++` increments after referring the value, but > it do not so. > > Thus I fixed the code as following changeset: > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/wip.00/ > > It passes module name check, but it fails parent (package name) check. > GDB log is here: > http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/gdb-after.txt > > I guess the value of parent should be `java/lang`, but it sets to > `sun/refrect/generics/factory`. > Do you have anything to think about? The problematic library was indeed libjimage.so. More below. > 2018-05-09 17:22 GMT+09:00 Severin Gehwolf : > > Hi, > > > > Note that slowdebug builds work: > > > > $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version > > openjdk version "11-internal" 2018-09-25 > > OpenJDK Runtime Environment (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs) > > OpenJDK 64-Bit Server VM (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs, mixed mode) > > > > In summary we have: > > > > * Build fails with fastdebug/release debug config (-O3) > > * Build succeeds with slowdebug (-O0) > > * F28 has GCC 8 > > * Older GCC-based builds continue to work for fastdebug/release config > > > > * JDK 10.0.1 builds fine with GCC 8. > > > > So far showing all symptoms of either a GCC bug or some UB in recent > > OpenJDK code which breaks with new optimizations done in GCC 8. > > > > I'll continue to investigate what it is... Looks like another case of UB in the JDK. This time libjimage.so with a signed integer overflow: https://bugs.openjdk.java.net/browse/JDK-8203223 Thanks, Severin From yasuenag at gmail.com Tue May 15 14:56:43 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 15 May 2018 23:56:43 +0900 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> Message-ID: <52ea2f89-1f4b-ce67-8308-5e349f43d3a9@gmail.com> Hi Severin, > Looks like another case of UB in the JDK. This time libjimage.so with a > signed integer overflow: > > https://bugs.openjdk.java.net/browse/JDK-8203223 Thanks! Can you fix pointer increment issue (I reported) at the same time? Yasumasa On 2018/05/15 23:07, Severin Gehwolf wrote: > Hi, > > On Fri, 2018-05-11 at 12:55 +0900, Yasumasa Suenaga wrote: >> Hi, >> >> I found 1 GCC optimization issue, but it is not enough. >> >> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/gdb-before.txt >> >> I traced class loading from `modules`. Above log is copy of GDB >> console in ImageFileReader::verify_location(). >> The code expects `*next++` increments after referring the value, but >> it do not so. >> >> Thus I fixed the code as following changeset: >> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/wip.00/ >> >> It passes module name check, but it fails parent (package name) check. >> GDB log is here: >> http://cr.openjdk.java.net/~ysuenaga/openjdk-fc28/gcc8-opt/gdb-after.txt >> >> I guess the value of parent should be `java/lang`, but it sets to >> `sun/refrect/generics/factory`. >> Do you have anything to think about? > > The problematic library was indeed libjimage.so. More below. > >> 2018-05-09 17:22 GMT+09:00 Severin Gehwolf : >>> Hi, >>> >>> Note that slowdebug builds work: >>> >>> $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -version >>> openjdk version "11-internal" 2018-09-25 >>> OpenJDK Runtime Environment (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs) >>> OpenJDK 64-Bit Server VM (slowdebug build 11-internal+0-adhoc.sgehwolf.openjdk-hs, mixed mode) >>> >>> In summary we have: >>> >>> * Build fails with fastdebug/release debug config (-O3) >>> * Build succeeds with slowdebug (-O0) >>> * F28 has GCC 8 >>> * Older GCC-based builds continue to work for fastdebug/release config >>> >>> * JDK 10.0.1 builds fine with GCC 8. >>> >>> So far showing all symptoms of either a GCC bug or some UB in recent >>> OpenJDK code which breaks with new optimizations done in GCC 8. >>> >>> I'll continue to investigate what it is... > > Looks like another case of UB in the JDK. This time libjimage.so with a > signed integer overflow: > > https://bugs.openjdk.java.net/browse/JDK-8203223 > > Thanks, > Severin > From sgehwolf at redhat.com Tue May 15 15:09:24 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 15 May 2018 17:09:24 +0200 Subject: Build failure on Fedora 28 In-Reply-To: <52ea2f89-1f4b-ce67-8308-5e349f43d3a9@gmail.com> References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> <52ea2f89-1f4b-ce67-8308-5e349f43d3a9@gmail.com> Message-ID: Hi Yasumasa, On Tue, 2018-05-15 at 23:56 +0900, Yasumasa Suenaga wrote: > Hi Severin, > > > Looks like another case of UB in the JDK. This time libjimage.so with a > > signed integer overflow: > > > > https://bugs.openjdk.java.net/browse/JDK-8203223 > > Thanks! > Can you fix pointer increment issue (I reported) at the same time? I'd prefer if this was fixed via a separate bug. It doesn't seem to be needed to fix the build failure, fwiw. Thanks, Severin From igor.ignatyev at oracle.com Tue May 15 18:58:48 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 15 May 2018 11:58:48 -0700 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: References: Message-ID: <8D49F7BE-84F3-4E3D-B9DC-30233E005263@oracle.com> Hi Erik, please see my answers inline. can I consider this RFR as reviewed by you? Thanks, -- Igor > On May 14, 2018, at 4:23 AM, Erik Helin wrote: > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> Hi all, > > Hi Igor, > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: >> - vmTestbase_vm_g1classunloading >> - vmTestbase_vm_gc_compact >> - vmTestbase_vm_gc_concurrent >> - vmTestbase_vm_gc_container >> - vmTestbase_vm_gc_juggle >> - vmTestbase_vm_gc_locker >> - vmTestbase_vm_gc_ref >> - vmTestbase_vm_gc_misc > > This is a very welcome, and pretty massive, change :) I won't be able to read through each test, there are simple too many, but I can sample a few of them and have a look. > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > I'm also assuming that to help the open sourcing of these tests, most comments will likely be deferred until later? If so, that is fine with me. y, unless it is something very important and cost of delaying changes is high, I'd prefer to defer all comments/improvements till later. > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 >> webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html > > Many of the tests are a bit cryptic, but that can be refactored later. Could you please file bugs for the two tests written in shell? Particularly parOld/test.sh should be trivial to rewrite in Java. sure, I've filed 8203239 and 8203238. > > It seems like a lot of tests contains a TEST.properties file with the content `exclusiveAccess.dirs=.`. Could this become the default value somewhere, so we don't need all those TEST.properties files? y, but this will require finding a most top directory whose all tests have this TEST.properties file and it will also make it harder to understand how a test is executed. there was/is ongoing discussing w/ Jon on moving 'exclusiveAccess' to test description. anyhow I've filed an RFE to clean that up -- 8203241. > > Thanks, > Erik > >> Thanks, >> -- Igor From magnus.ihse.bursie at oracle.com Tue May 15 23:14:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 May 2018 01:14:08 +0200 Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder Message-ID: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> Cleanups of the build system after Flight Recorder. Bug: https://bugs.openjdk.java.net/browse/JDK-8203221 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8203221-makefile-fixes-after-flight-recorder/webrev.01 /Magnus From erik.joelsson at oracle.com Tue May 15 23:39:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 15 May 2018 16:39:28 -0700 Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder In-Reply-To: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> References: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> Message-ID: <867f2308-6f92-edd1-e76b-50e685f47a26@oracle.com> Hello, In GensrcJfr, JFR_TOOLS_OUTPUTDIR is defined twice. Other build tools are in make/{jdk,hotspot}/src/classes. Do you think we should be moving them to one place? Regardless, I think we need an INCLUDE in the SetupJavaCompilation so that we only build the tool we need. There is currently no other tools in make/src/classes, but that directory is inviting for others. /Erik On 2018-05-15 16:14, Magnus Ihse Bursie wrote: > Cleanups of the build system after Flight Recorder. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203221 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8203221-makefile-fixes-after-flight-recorder/webrev.01 > > /Magnus From markus.gronlund at oracle.com Tue May 15 23:55:49 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 15 May 2018 16:55:49 -0700 (PDT) Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder In-Reply-To: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> References: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> Message-ID: Magnus and Erik, Big thanks in regards to your ongoing assistance and follow-up on this. Best regards Markus and Erik (G) -----Original Message----- From: Magnus Ihse Bursie Sent: den 16 maj 2018 01:14 To: build-dev ; hotspot-jfr-dev at openjdk.java.net Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder Cleanups of the build system after Flight Recorder. Bug: https://bugs.openjdk.java.net/browse/JDK-8203221 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8203221-makefile-fixes-after-flight-recorder/webrev.01 /Magnus From yasuenag at gmail.com Wed May 16 01:02:35 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 16 May 2018 10:02:35 +0900 Subject: Build failure on Fedora 28 In-Reply-To: References: <0a00ed14-2cf5-c519-c8d5-60939f0e96fa@oracle.com> <2e8d65806f3cfba12ef2b9123f6bcd72ec93ea97.camel@redhat.com> <52ea2f89-1f4b-ce67-8308-5e349f43d3a9@gmail.com> Message-ID: Hi Severin, >> > Looks like another case of UB in the JDK. This time libjimage.so with a >> > signed integer overflow: >> > >> > https://bugs.openjdk.java.net/browse/JDK-8203223 It works on my Fedora 28. I hope your change will be merged ASAP. Thanks again! Yasumasa 2018-05-16 0:09 GMT+09:00 Severin Gehwolf : > Hi Yasumasa, > > On Tue, 2018-05-15 at 23:56 +0900, Yasumasa Suenaga wrote: >> Hi Severin, >> >> > Looks like another case of UB in the JDK. This time libjimage.so with a >> > signed integer overflow: >> > >> > https://bugs.openjdk.java.net/browse/JDK-8203223 >> >> Thanks! >> Can you fix pointer increment issue (I reported) at the same time? > > I'd prefer if this was fixed via a separate bug. It doesn't seem to be > needed to fix the build failure, fwiw. > > Thanks, > Severin From matthias.baesken at sap.com Wed May 16 07:05:32 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 16 May 2018 07:05:32 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: References: <8361024dba4f44309292e73ec9ad7b83@sap.com> Message-ID: <7c8765c8a59b4522bd0ed772cdccfb05@sap.com> Hi Christoph can I add you as second reviewer (other reviewer was Erik Joelsson) can push the change ? Best regards, Matthias From: Langer, Christoph Sent: Donnerstag, 26. April 2018 16:38 To: Baesken, Matthias ; 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Simonis, Volker Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hi Matthias, to me the change in principal looks good. I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) - but maybe it is too complicated and the current single version compare suits our needs ? Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 26. April 2018 16:14 To: 'build-dev at openjdk.java.net' >; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph >; Simonis, Volker > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8202322 Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ Best regards, Matthias From christoph.langer at sap.com Wed May 16 07:08:10 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 16 May 2018 07:08:10 +0000 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 In-Reply-To: <7c8765c8a59b4522bd0ed772cdccfb05@sap.com> References: <8361024dba4f44309292e73ec9ad7b83@sap.com> <7c8765c8a59b4522bd0ed772cdccfb05@sap.com> Message-ID: <418229a2ef3e43da8541e4100e906672@sap.com> Hi Matthias, yes, reviewed. Best regards Christoph From: Baesken, Matthias Sent: Mittwoch, 16. Mai 2018 09:06 To: Langer, Christoph ; 'build-dev at openjdk.java.net' ; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hi Christoph can I add you as second reviewer (other reviewer was Erik Joelsson) can push the change ? Best regards, Matthias From: Langer, Christoph Sent: Donnerstag, 26. April 2018 16:38 To: Baesken, Matthias >; 'build-dev at openjdk.java.net' >; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Simonis, Volker > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hi Matthias, to me the change in principal looks good. I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. extract major number before the first dot, then compare numerically) - but maybe it is too complicated and the current single version compare suits our needs ? Best regards Christoph From: Baesken, Matthias Sent: Donnerstag, 26. April 2018 16:14 To: 'build-dev at openjdk.java.net' >; ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Langer, Christoph >; Simonis, Volker > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Hello , could you please review this small adjustment to the symbol visibility compilation settings on AIX ? Currently we use XLC 12.1 to compile JDK on AIX . However XLC 12.1 does not support the "-qvisibility=hidden" setting currently set on AIX. It was introduced with XLC 13.1 . Christoph found some info about it here : https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html Setting it only generates hundreds of warnings in the build log , warnings look like this : XlC12.1 bash-4.4$ xlC -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0019 bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list of valid options. Compare to XLC13.1 bash-3.00$ xlC -qversion IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) Version: 13.01.0000.0008 bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc So it is better to avoid setting these flags when using xlc12.1 . Please review : Bug : https://bugs.openjdk.java.net/browse/JDK-8202322 Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ Best regards, Matthias From magnus.ihse.bursie at oracle.com Wed May 16 14:18:38 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 May 2018 16:18:38 +0200 Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder In-Reply-To: <867f2308-6f92-edd1-e76b-50e685f47a26@oracle.com> References: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> <867f2308-6f92-edd1-e76b-50e685f47a26@oracle.com> Message-ID: <03B02EC4-3594-4476-8ED3-8606B53DF6BC@oracle.com> > 16 maj 2018 kl. 01:39 skrev Erik Joelsson : > > Hello, > > In GensrcJfr, JFR_TOOLS_OUTPUTDIR is defined twice. Oops, will fix. > Other build tools are in make/{jdk,hotspot}/src/classes. Do you think we should be moving them to one place? Regardless, I think we need an INCLUDE in the SetupJavaCompilation so that we only build the tool we need. There is currently no other tools in make/src/classes, but that directory is inviting for others. I think we should move all tools to a common place. The current solution is more an effect of how things ended up due to the old multi-repo design. So I though: let's start doing things right, and put this one in a common build tool directory, and then we can move the rest there in a follow up. But if you think that is confusing (I could really agree) we can skip doing that now. If so, I'll just move this to some jfr_build_tools_classes dir instead. /Magnus > > /Erik > > >> On 2018-05-15 16:14, Magnus Ihse Bursie wrote: >> Cleanups of the build system after Flight Recorder. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203221 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8203221-makefile-fixes-after-flight-recorder/webrev.01 >> >> /Magnus > From Sergey.Bylokhov at oracle.com Wed May 16 16:18:55 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 16 May 2018 09:18:55 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> Message-ID: Looks fine. cc build-dev to review changes in the make file. On 14/05/2018 14:01, Alan Snyder wrote: > http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 > > https://bugs.openjdk.java.net/browse/JDK-8194327 -- Best regards, Sergey. From erik.joelsson at oracle.com Wed May 16 18:51:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 May 2018 11:51:57 -0700 Subject: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors In-Reply-To: References: <95521a57-5afa-52bf-b35a-c866479289a7@oracle.com> <22D883A4-B362-411D-82F7-76A418487ADE@cbfiddle.com> <35F57A44-F3B1-484B-9A88-66849FFA9E47@cbfiddle.com> <60f03131-a79d-ed9a-d86d-3ea4be8184c2@oracle.com> <2384DD98-D388-4200-96CB-E81D2B054F25@cbfiddle.com> <2696BB8F-83BC-4AC4-8275-5AAA14809B5F@cbfiddle.com> Message-ID: <66abf74f-c1c9-2304-20ee-b68ffba8742d@oracle.com> Build changes look good. /Erik On 2018-05-16 09:18, Sergey Bylokhov wrote: > Looks fine. > cc build-dev to review changes in the make file. > > On 14/05/2018 14:01, Alan Snyder wrote: >> http://cr.openjdk.java.net/~serb/alans/8194327/webrev.02 >> >> https://bugs.openjdk.java.net/browse/JDK-8194327 > > From kevin.walls at oracle.com Wed May 16 21:14:02 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 16 May 2018 22:14:02 +0100 Subject: [8u] RFR: 8042707: Source changes needed to build JDK 9 with Visual Studio 2013 (VS2013) In-Reply-To: <34c5e1e8-218b-8008-445a-fecb6fcbcc90@oracle.com> References: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com> <31e018fb-074b-041f-05fb-b61e882fb619@oracle.com> <34c5e1e8-218b-8008-445a-fecb6fcbcc90@oracle.com> Message-ID: <1fe93ae2-a116-d715-ef8d-78fc6dd00280@oracle.com> Hi, FYI, I haven't pushed this to 8u yet but am about to, with two changes in jdk/make/CopyFiles.gmk: define copy-and-chmod had a colon and extra space on the end of the line. LIB_DST_DIR is not defined here in 8u, it should be $(JDK_OUTPUTDIR)/bin Thanks Kevin On 26/04/2018 16:57, Erik Joelsson wrote: > > Looks good. > > /Erik > > > On 2018-04-26 01:38, Kevin Walls wrote: >> >> Thanks Erik - >> >> I went ahead with the jdk's make/CopyFiles.gmk change, and added >> SetupCopyFiles to the base repo's make/common/MakeBase.gmk. >> >> I updated the webrev, to include base and jdk repos: >> >> http://cr.openjdk.java.net/~kevinw/8042707/webrev.01/ >> >> I'm getting these build OK with VS2012, but there will be further >> hotspot change at least for VS2013 to be a working option in 8u. >> >> Thanks >> Kevin >> (my previous reply was not the the list, so this is the open response!) >> >> >> >> On 20/04/2018 23:27, Erik Joelsson wrote: >>> The root repo changes look ok. >>> >>> The changes in Copy-java.base.gmk applies to jdk/make/CopyFiles.gmk. >>> Those changes are definitely needed. >>> >>> /Erik >>> >>> >>> On 2018-04-20 13:18, Kevin Walls wrote: >>>> Hi, >>>> >>>> I'd like to request a review of the backport from 9 to 8u: >>>> >>>> 8042707: Source changes needed to build JDK 9 with Visual Studio >>>> 2013 (VS2013) >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8042707 >>>> >>>> 9 changesets: >>>> base repo: http://hg.openjdk.java.net/jdk9/jdk9/rev/39ee0ee4f890 >>>> jdk repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c622a8ba90ad >>>> >>>> 9 review thread: >>>> http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014029.html >>>> >>>> >>>> Notes: >>>> base repo: >>>> toolchain_windows.m4: quite a bit of manual work, but no conflicts. >>>> make/common/MakeBase.gmk: changes in SetupCopyFiles which we don't >>>> have in 8u >>>> flags.m4: we don't call it COMMON_CXXFLAGS_JDK in 8u, but made the >>>> same change. >>>> >>>> jdk repo: >>>> make/copy/Copy-java.base.gmk we don't have in 8u. The other two >>>> files apply cleanly. >>>> >>>> >>>> Clearly this backport isn't to change anything about what compilers >>>> are supported or recommended, >>>> it's just about the build infrastructure. >>>> >>>> >>>> 8u change: webrev of the base repo changes: >>>> http://cr.openjdk.java.net/~kevinw/8042707/webrev.00/ >>>> >>>> Many thanks >>>> Kevin >>>> >>> >> > From erik.joelsson at oracle.com Wed May 16 21:36:56 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 May 2018 14:36:56 -0700 Subject: [8u] RFR: 8042707: Source changes needed to build JDK 9 with Visual Studio 2013 (VS2013) In-Reply-To: <1fe93ae2-a116-d715-ef8d-78fc6dd00280@oracle.com> References: <8395bc7a-ce9b-e67e-c873-3a4305026d2c@oracle.com> <31e018fb-074b-041f-05fb-b61e882fb619@oracle.com> <34c5e1e8-218b-8008-445a-fecb6fcbcc90@oracle.com> <1fe93ae2-a116-d715-ef8d-78fc6dd00280@oracle.com> Message-ID: Sounds good. /Erik On 2018-05-16 14:14, Kevin Walls wrote: > Hi, > > FYI, I haven't pushed this to 8u yet but am about to, with two changes > in jdk/make/CopyFiles.gmk: > > define copy-and-chmod had a colon and extra space on the end of the > line. LIB_DST_DIR is not defined here in 8u, it should be > $(JDK_OUTPUTDIR)/bin > > Thanks > Kevin > > > On 26/04/2018 16:57, Erik Joelsson wrote: >> >> Looks good. >> >> /Erik >> >> >> On 2018-04-26 01:38, Kevin Walls wrote: >>> >>> Thanks Erik - >>> >>> I went ahead with the jdk's make/CopyFiles.gmk change, and added >>> SetupCopyFiles to the base repo's make/common/MakeBase.gmk. >>> >>> I updated the webrev, to include base and jdk repos: >>> >>> http://cr.openjdk.java.net/~kevinw/8042707/webrev.01/ >>> >>> I'm getting these build OK with VS2012, but there will be further >>> hotspot change at least for VS2013 to be a working option in 8u. >>> >>> Thanks >>> Kevin >>> (my previous reply was not the the list, so this is the open response!) >>> >>> >>> >>> On 20/04/2018 23:27, Erik Joelsson wrote: >>>> The root repo changes look ok. >>>> >>>> The changes in Copy-java.base.gmk applies to >>>> jdk/make/CopyFiles.gmk. Those changes are definitely needed. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-04-20 13:18, Kevin Walls wrote: >>>>> Hi, >>>>> >>>>> I'd like to request a review of the backport from 9 to 8u: >>>>> >>>>> 8042707: Source changes needed to build JDK 9 with Visual Studio >>>>> 2013 (VS2013) >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8042707 >>>>> >>>>> 9 changesets: >>>>> base repo: http://hg.openjdk.java.net/jdk9/jdk9/rev/39ee0ee4f890 >>>>> jdk repo: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c622a8ba90ad >>>>> >>>>> 9 review thread: >>>>> http://mail.openjdk.java.net/pipermail/build-dev/2015-January/014029.html >>>>> >>>>> >>>>> Notes: >>>>> base repo: >>>>> toolchain_windows.m4: quite a bit of manual work, but no conflicts. >>>>> make/common/MakeBase.gmk: changes in SetupCopyFiles which we don't >>>>> have in 8u >>>>> flags.m4: we don't call it COMMON_CXXFLAGS_JDK in 8u, but made the >>>>> same change. >>>>> >>>>> jdk repo: >>>>> make/copy/Copy-java.base.gmk we don't have in 8u. The other two >>>>> files apply cleanly. >>>>> >>>>> >>>>> Clearly this backport isn't to change anything about what >>>>> compilers are supported or recommended, >>>>> it's just about the build infrastructure. >>>>> >>>>> >>>>> 8u change: webrev of the base repo changes: >>>>> http://cr.openjdk.java.net/~kevinw/8042707/webrev.00/ >>>>> >>>>> Many thanks >>>>> Kevin >>>>> >>>> >>> >> > From philip.race at oracle.com Wed May 16 22:52:17 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 16 May 2018 15:52:17 -0700 Subject: RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources Message-ID: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> Webrev: http://cr.openjdk.java.net/~prr/8191522/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 The Lucida fonts have never been part of OpenJDK but many places in the code and tests reference them. There are even a couple of stray fonts.dir files that probably should not have been in there. This fix cleans up as much of this as we are also intending to no longer ship these fonts with Oracle JDK as it converges with OpenJDK. There is one minor build change in here, so I've included the build list. -phil. From erik.joelsson at oracle.com Wed May 16 23:08:40 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 16 May 2018 16:08:40 -0700 Subject: RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources In-Reply-To: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> References: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> Message-ID: Build changes look good. /Erik On 2018-05-16 15:52, Phil Race wrote: > Webrev: http://cr.openjdk.java.net/~prr/8191522/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 > > The Lucida fonts have never been part of OpenJDK but many places in > the code > and tests reference them. There are even a couple of stray fonts.dir > files that > probably should not have been in there. > > This fix cleans up as much of this as we are also intending to no > longer ship > these fonts with Oracle JDK as it converges with OpenJDK. > > There is one minor build change in here, so I've included the build list. > > -phil. > From philip.race at oracle.com Thu May 17 00:20:16 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 16 May 2018 17:20:16 -0700 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> Message-ID: <5AFCCAC0.6000706@oracle.com> Hi, OK .. if you can convince upstream this is worth doing, then we can accept it as we would not regress when updating. As I noted previously : http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html this is still an issue in the currently being developed 9c train. -phil. On 5/14/18, 3:06 AM, Adam Farley8 wrote: > Hi Phil, > > Would an acceptable compromise be to deliver the source code change > and send the code to the upstream community, allowing them to include > the fix if/when they are able? > > I believe Magnus was advocating this idea as well. See below. > > Best Regards > > Adam Farley > > > Same here. I would like to have this fix in, but do not want to go > > over Phils head. > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > Thanks, Thomas > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > wrote: > > > I don't object, but it's not build code so I don't have the final say. > > > > > > /Magnus > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > Hi All, > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > It doesn't break anything, it fixes a build break on two supported > > > platforms, and it seems > > > like we never refresh the code from upstream. > > > > > > - Adam > > > > > >> I also advocate the source code fix, as Make isn't meant to use > the sort > > >> of logic required > > >> to properly analyse the toolchain version string. > > >> > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using > 4.8.6, > > >> and Make doesn't > > >> seem to do substring stuff unless you mess around with shells. > > >> > > >> Plus, as people have said, it's better to solve problem x (or work > around > > >> a specific > > >> instance of x) than to ignore the exception, even if the ignoring > code is > > >> toolchain- > > >> specific. > > >> > > >> - Adam Farley > > >> > > >> > On 2018-03-27 18:44, Phil Race wrote: > > >> > > > >> >> As I said I prefer the make file change, since this is a change > to an > > >> >> upstream library. > > >> > > > >> > Newtons fourth law: For every reviewer, there's an equal and > opposite > > >> > reviewer. :) > > >> > > > >> > Here I am, advocating a source code fix. As Thomas says, the > compiler > > >> > complaint seems reasonable, and disabling it might cause us to > miss other > > >> > future errors. > > >> > > > >> > Why can't we push the source code fix, and also submit it upstream? > > >> > > > >> > /Magnus > > >> > > > >> > > > >> > I've looked at jpeg-9c and it still looks identical to what we > have in > > >> > 6b, so this code > > >> > seems to have stood the test of time. I'm also unclear why the > compiler > > >> > would > > >> > complain about that and not the one a few lines later > > >> > > > >> > > > >> > 819 while (bits[i] == 0) /* find largest codelength > still in > > >> > use */ > > >> > 820 i--; > > >> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > >> > A tool-chain specific fix in the makefile with an appropriate > comment is > > >> > more targeted. > > >> > > >> Phil, > > >> > > >> Returning to this. > > >> > > >> While I understand your reluctance to patch upstream code, let me > point > > >> out that we have not updated libjpeg a single time since the JDK > was open > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > Wikipedia page > > >> on libjpeg, and this is the latest "uncontroversial" version of > the source. > > >> Versions 7 and up have proprietary extensions, which in turn has > resulted in > > >> multiple forks of libjpeg. As it stands, it seems unlikely that we > will ever > > >> replace libjpeg 6b with a simple upgrade from upstream. > > >> > > >> I therefore maintain my position that a source code fix would be > the best > > >> way forward here. > > >> > > >> /Magnus > > >> > > >> > > > >> > > > >> > -phil. > > >> > > > >> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > just a friendly reminder. I would like to push this tiny fix > because > > >> > tripping over this on our linux s390x builds is annoying (yes, > we can > > >> > maintain patch queues, but this is a constant error source). > > >> > > > >> > > > >> > I will wait for 24 more hours until a reaction. If no serious > objections > > >> > are forcoming, I want to push it (tier1 tests ran thru, and me > and Christoph > > >> > langer are both Reviewers). > > >> > > > >> > > > >> > Thanks! Thomas > > >> > > > >> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > >> > wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > may I please have another review for this really trivial change. It > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good > idea to fix > > >> > this. > > >> > > > >> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > >> > webrev: > > >> > > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > > >> > > > >> > > > >> > This was contributed by Adam Farley at IBM. > > >> > > > >> > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > >> > > > >> > > > >> > Thanks, Thomas > > >> > > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with > number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > >> > > >> > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From serguei.spitsyn at oracle.com Thu May 17 03:48:47 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 16 May 2018 20:48:47 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests In-Reply-To: <8BA2B023-E947-4EF8-9D97-EBA28BAA07E2@oracle.com> References: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> <5AF5C07B.1080909@oracle.com> <8BA2B023-E947-4EF8-9D97-EBA28BAA07E2@oracle.com> Message-ID: <58bfdd2c-9163-2464-93bd-9ee1e265d97e@oracle.com> Hi Leonid, Looks good to me too. Thanks, Serguei On 5/14/18 14:04, Leonid Mesnik wrote: > Misha > > Thank you for review. I still need one more review from 'R'eviewer. > > Leonid > >> On May 11, 2018, at 9:10 AM, Mikhailo Seledtsov wrote: >> >> Looks good to me, >> >> Misha >> >> On 5/8/18, 2:23 PM, Leonid Mesnik wrote: >>> Hi >>> >>> Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. >>> They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. >>> >>> The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. >>> >>> I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. >>> >>> webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8199271 From erik.helin at oracle.com Thu May 17 07:12:17 2018 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 17 May 2018 09:12:17 +0200 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: <8D49F7BE-84F3-4E3D-B9DC-30233E005263@oracle.com> References: <8D49F7BE-84F3-4E3D-B9DC-30233E005263@oracle.com> Message-ID: <38097225-0570-5865-0177-b1f8c230733c@oracle.com> On 05/15/2018 08:58 PM, Igor Ignatyev wrote: > Hi Erik, > > please see my answers inline. > > can I consider this RFR as reviewed by you? Yep! > Thanks, > -- Igor > >> On May 14, 2018, at 4:23 AM, Erik Helin wrote: >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> Hi all, >> >> Hi Igor, >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: >>> - vmTestbase_vm_g1classunloading >>> - vmTestbase_vm_gc_compact >>> - vmTestbase_vm_gc_concurrent >>> - vmTestbase_vm_gc_container >>> - vmTestbase_vm_gc_juggle >>> - vmTestbase_vm_gc_locker >>> - vmTestbase_vm_gc_ref >>> - vmTestbase_vm_gc_misc >> >> This is a very welcome, and pretty massive, change :) I won't be able to read through each test, there are simple too many, but I can sample a few of them and have a look. >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >> >> I'm also assuming that to help the open sourcing of these tests, most comments will likely be deferred until later? If so, that is fine with me. > y, unless it is something very important and cost of delaying changes is high, I'd prefer to defer all comments/improvements till later. Ok, normally I would like it to be cleaned up prior to pushing, but I'm also aware of the history of these tests. Right now it seems more valuable to push these tests so we can collaborate on cleaning them up in upstream. >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html >> >> Many of the tests are a bit cryptic, but that can be refactored later. Could you please file bugs for the two tests written in shell? Particularly parOld/test.sh should be trivial to rewrite in Java. > sure, I've filed 8203239 and 8203238. Thanks! >> It seems like a lot of tests contains a TEST.properties file with the content `exclusiveAccess.dirs=.`. Could this become the default value somewhere, so we don't need all those TEST.properties files? > y, but this will require finding a most top directory whose all tests have this TEST.properties file and it will also make it harder to understand how a test is executed. there was/is ongoing discussing w/ Jon on moving 'exclusiveAccess' to test description. anyhow I've filed an RFE to clean that up -- 8203241. Ok, we can continue the discussion in 8203241. Thanks, Erik >> >> Thanks, >> Erik >> >>> Thanks, >>> -- Igor > From leonid.mesnik at oracle.com Thu May 17 19:59:46 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 17 May 2018 12:59:46 -0700 Subject: 8199271: [TESTBUG] open source VM testbase stress tests In-Reply-To: <58bfdd2c-9163-2464-93bd-9ee1e265d97e@oracle.com> References: <1BC403EC-BDF0-4CA2-B87F-B38A92B6765F@oracle.com> <5AF5C07B.1080909@oracle.com> <8BA2B023-E947-4EF8-9D97-EBA28BAA07E2@oracle.com> <58bfdd2c-9163-2464-93bd-9ee1e265d97e@oracle.com> Message-ID: <175FD6F0-AAF1-4985-A899-002320444F3B@oracle.com> Thank you for review. Leonid > On May 16, 2018, at 8:48 PM, serguei.spitsyn at oracle.com wrote: > > Hi Leonid, > > Looks good to me too. > > Thanks, > Serguei > > > On 5/14/18 14:04, Leonid Mesnik wrote: >> Misha >> >> Thank you for review. I still need one more review from 'R'eviewer. >> >> Leonid >> >>> On May 11, 2018, at 9:10 AM, Mikhailo Seledtsov wrote: >>> >>> Looks good to me, >>> >>> Misha >>> >>> On 5/8/18, 2:23 PM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Please review this change open sourcing vm testbase stress tests. These tests have been developed a long time ago for internal test harness and don't looks very nice now. >>>> They are open sourced with minimal changes only. The long term plan is to review and improve them moving out of vmTestbase directory in corresponding components. >>>> >>>> The fix introduce vmTestbase_nsk_stress test group and have make files changes required to build native part of tests. >>>> >>>> I've verified that "make -- run-test TEST=:vmTestbase_nsk_stress" pass on my linux locally. >>>> >>>> webrev: http://cr.openjdk.java.net/~lmesnik/8199271/webrev.00/ >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8199271 > From kevin.walls at oracle.com Thu May 17 22:21:47 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 17 May 2018 23:21:47 +0100 Subject: [8u] 8203349: 8u hotspot should recognise later Windows compilers Message-ID: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> Hi, I'd like to get a review for this 8u/hotspot build change for Windows, to loosen the restriction on what compilers we can use. JBS: 8203349: 8u hotspot should recognise later Windows compilers https://bugs.openjdk.java.net/browse/JDK-8203349 Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/ Changes in the places we (sanity) check version numbers, set some compile options, and expand the check in vm.make to make sure we put the precompiled object? _build_pch_file.obj on the jvm link command. In compile.make I added blocks for VS2013 and 17, and left them as separate, duplicated, blocks of settings to make them easier to change independently. This doesn't change anything about what is "supported" or documented as working. Thanks! Kevin From erik.joelsson at oracle.com Thu May 17 22:32:58 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 17 May 2018 15:32:58 -0700 Subject: [8u] 8203349: 8u hotspot should recognise later Windows compilers In-Reply-To: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> References: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> Message-ID: Hello Kevin, In JDK 11, vm_version.cpp we have _MSC_VER == 1900 translating to VS2015 and 1912 to VS2017. Is it really 1900 in nmake? Otherwise I think this looks ok. /Erik On 2018-05-17 15:21, Kevin Walls wrote: > Hi, > > I'd like to get a review for this 8u/hotspot build change for > Windows, to loosen the restriction on what compilers we can use. > > JBS: > 8203349: 8u hotspot should recognise later Windows compilers > https://bugs.openjdk.java.net/browse/JDK-8203349 > > Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/ > > Changes in the places we (sanity) check version numbers, set some compile > options, and expand the check in vm.make to make sure we put the > precompiled > object? _build_pch_file.obj on the jvm link command. > > In compile.make I added blocks for VS2013 and 17, and left them as > separate, > duplicated, blocks of settings to make them easier to change > independently. > > This doesn't change anything about what is "supported" or documented > as working. > > Thanks! > Kevin > > From philip.race at oracle.com Thu May 17 23:58:29 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 17 May 2018 16:58:29 -0700 Subject: RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources In-Reply-To: References: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> Message-ID: <5AFE1725.7080609@oracle.com> http://cr.openjdk.java.net/~prr/8191522.1 uploaded. Adding .. the removal of .. a couple of uses of lucida - sanity check of lucida in font config files is no longer needed. - J2DBench demo opts change from lucida to dialog. Not sure why it had lucida anyway .. -phil. On 5/16/18, 4:08 PM, Erik Joelsson wrote: > Build changes look good. > > /Erik > > > On 2018-05-16 15:52, Phil Race wrote: >> Webrev: http://cr.openjdk.java.net/~prr/8191522/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 >> >> The Lucida fonts have never been part of OpenJDK but many places in >> the code >> and tests reference them. There are even a couple of stray fonts.dir >> files that >> probably should not have been in there. >> >> This fix cleans up as much of this as we are also intending to no >> longer ship >> these fonts with Oracle JDK as it converges with OpenJDK. >> >> There is one minor build change in here, so I've included the build >> list. >> >> -phil. >> > From Sergey.Bylokhov at oracle.com Fri May 18 02:01:21 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 17 May 2018 19:01:21 -0700 Subject: RFR: 8191522: Remove references to Lucida fonts from OpenJDK sources In-Reply-To: <5AFE1725.7080609@oracle.com> References: <931ca8e0-64a4-cbc5-fc30-085a516682d7@oracle.com> <5AFE1725.7080609@oracle.com> Message-ID: <0dd5e94b-0be4-4be7-fe9d-67fc30a714aa@oracle.com> Looks fine. On 17/05/2018 16:58, Philip Race wrote: > http://cr.openjdk.java.net/~prr/8191522.1 uploaded. > Adding .. the removal of .. a couple of uses of lucida > - sanity check of lucida in font config files is no longer needed. > - J2DBench demo opts change from lucida to dialog. Not sure why it had > lucida anyway .. > > -phil. > > On 5/16/18, 4:08 PM, Erik Joelsson wrote: >> Build changes look good. >> >> /Erik >> >> >> On 2018-05-16 15:52, Phil Race wrote: >>> Webrev: http://cr.openjdk.java.net/~prr/8191522/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191522 >>> >>> The Lucida fonts have never been part of OpenJDK but many places in >>> the code >>> and tests reference them. There are even a couple of stray fonts.dir >>> files that >>> probably should not have been in there. >>> >>> This fix cleans up as much of this as we are also intending to no >>> longer ship >>> these fonts with Oracle JDK as it converges with OpenJDK. >>> >>> There is one minor build change in here, so I've included the build >>> list. >>> >>> -phil. >>> >> -- Best regards, Sergey. From kevin.walls at oracle.com Fri May 18 08:51:45 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 18 May 2018 09:51:45 +0100 Subject: [8u] 8203349: 8u hotspot should recognise later Windows compilers In-Reply-To: References: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> Message-ID: <13e5ccc0-cdfb-aa02-1cfd-da966bfe4b4e@oracle.com> Hi Erik - Quite right, thanks.? Actually I should include recognising VS2015 while I'm doing this. Update: http://cr.openjdk.java.net/~kevinw/8203349/webrev.01/ Also, update Abstract_VM_Version::internal_vm_info_string()? in src/share/vm/runtime/vm_version.cpp so the long version string is readable for these compilers. In the sanity checks for VS2015, I am predicting it has a linker version of 1900 as it's between the 1800 and 1900 that I have seen myself for the other versions I have. I have a local VS2013 build, and builds using the unchanged "official" compiler are still OK. Thanks Kevin On 17/05/2018 23:32, Erik Joelsson wrote: > Hello Kevin, > > In JDK 11, vm_version.cpp we have _MSC_VER == 1900 translating to > VS2015 and 1912 to VS2017. Is it really 1900 in nmake? > > Otherwise I think this looks ok. > > /Erik > > > On 2018-05-17 15:21, Kevin Walls wrote: >> Hi, >> >> I'd like to get a review for this 8u/hotspot build change for >> Windows, to loosen the restriction on what compilers we can use. >> >> JBS: >> 8203349: 8u hotspot should recognise later Windows compilers >> https://bugs.openjdk.java.net/browse/JDK-8203349 >> >> Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/ >> >> Changes in the places we (sanity) check version numbers, set some >> compile >> options, and expand the check in vm.make to make sure we put the >> precompiled >> object? _build_pch_file.obj on the jvm link command. >> >> In compile.make I added blocks for VS2013 and 17, and left them as >> separate, >> duplicated, blocks of settings to make them easier to change >> independently. >> >> This doesn't change anything about what is "supported" or documented >> as working. >> >> Thanks! >> Kevin >> >> > From christoph.langer at sap.com Fri May 18 11:59:01 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 May 2018 11:59:01 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> Message-ID: Hi all, Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ Can someone from the graphics/awt team please have a look at that change? Especially checking that we don't break non-AIX platforms? Thanks in advance. @Ichiroh: Thanks for your review and tests. Adressing your points: > resetCompositionState() was missing in > src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > ========================================================== > == > --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May > 09 09:05:32 2018 +0900 > +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon > May > 14 21:25:50 2018 +0900 > @@ -56,6 +56,21 @@ > } > > /** > + * Reset the composition state to the current composition state. > + */ > + protected void resetCompositionState() { > + if (compositionEnableSupported && haveActiveClient()) { > + try { > + /* Restore the composition mode to the last saved > composition > + mode. */ > + setCompositionEnabled(savedCompositionState); > + } catch (UnsupportedOperationException e) { > + compositionEnableSupported = false; > + } > + } > + } > + > + /** > * Activate input method. > */ > public synchronized void activate() { > ========================================================== Good catch. I've incorporated that in my new webrev. > Otherwise, > we could not find out any functional difference on Linux. > we could not find out any functional difference between our modified code and your code on AIX. > > By code check, we found following difference. > ========================================================== > == > --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > Wed May 09 09:05:32 2018 +0900 > +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > Mon May 14 21:25:50 2018 +0900 > @@ -248,6 +248,10 @@ > "flushText", > "()V"); > JNU_CHECK_EXCEPTION_RETURN(env, NULL); > + if ((*env)->ExceptionOccurred(env)) { > + (*env)->ExceptionDescribe(env); > + (*env)->ExceptionClear(env); > + } > /* IMPORTANT: > The order of the following calls is critical since > "imInstance" may > point to the global reference itself, if > "freeX11InputMethodData" is called > ========================================================== > > Did you remove this code intentionally ? Yes, I removed that one intentionally. There is no point in doing the Exception check/clearing after a call to JNU_CHECK_EXCEPTION_RETURN(env, NULL); > Otherwise, I think the other changes were acceptable. ? Thanks and Best regards Christoph From martin.doerr at sap.com Fri May 18 12:03:18 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 18 May 2018 12:03:18 +0000 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: <8D49F7BE-84F3-4E3D-B9DC-30233E005263@oracle.com> References: <8D49F7BE-84F3-4E3D-B9DC-30233E005263@oracle.com> Message-ID: <71c70cd8821a4f1ca333f4ceea578e4f@sap.com> Hi Igor, we get compiler warnings on linux ppc64le (GCC 4.8.5): libnativeGC05.c:80:19: error: 'pair_getj_mid' may be used uninitialized in this function [-Werror=maybe-uninitialized] j = (*env)->CallIntMethod(env, pair, pair_getj_mid); ^ libnativeGC05.c:78:19: error: 'pair_geti_mid' may be used uninitialized in this function [-Werror=maybe-uninitialized] i = (*env)->CallIntMethod(env, pair, pair_geti_mid); ^ Unfortunately, the files are compiled with warnings as errors. We think this should get fixed. Best regards, Martin -----Original Message----- From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev Sent: Dienstag, 15. Mai 2018 20:59 To: Erik Helin Cc: hotspot-gc-dev ; build-dev ; hotspot-dev developers Subject: Re: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests Hi Erik, please see my answers inline. can I consider this RFR as reviewed by you? Thanks, -- Igor > On May 14, 2018, at 4:23 AM, Erik Helin wrote: > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> Hi all, > > Hi Igor, > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: >> - vmTestbase_vm_g1classunloading >> - vmTestbase_vm_gc_compact >> - vmTestbase_vm_gc_concurrent >> - vmTestbase_vm_gc_container >> - vmTestbase_vm_gc_juggle >> - vmTestbase_vm_gc_locker >> - vmTestbase_vm_gc_ref >> - vmTestbase_vm_gc_misc > > This is a very welcome, and pretty massive, change :) I won't be able to read through each test, there are simple too many, but I can sample a few of them and have a look. > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > I'm also assuming that to help the open sourcing of these tests, most comments will likely be deferred until later? If so, that is fine with me. y, unless it is something very important and cost of delaying changes is high, I'd prefer to defer all comments/improvements till later. > > On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 >> webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html > > Many of the tests are a bit cryptic, but that can be refactored later. Could you please file bugs for the two tests written in shell? Particularly parOld/test.sh should be trivial to rewrite in Java. sure, I've filed 8203239 and 8203238. > > It seems like a lot of tests contains a TEST.properties file with the content `exclusiveAccess.dirs=.`. Could this become the default value somewhere, so we don't need all those TEST.properties files? y, but this will require finding a most top directory whose all tests have this TEST.properties file and it will also make it harder to understand how a test is executed. there was/is ongoing discussing w/ Jon on moving 'exclusiveAccess' to test description. anyhow I've filed an RFE to clean that up -- 8203241. > > Thanks, > Erik > >> Thanks, >> -- Igor From sgehwolf at redhat.com Fri May 18 13:57:10 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 May 2018 15:57:10 +0200 Subject: RFR: 8203410: Zero: Disable jfr feature by default Message-ID: <8116f11e918dc5d4b678d51715ed8f8f28e6724b.camel@redhat.com> Hi, Currently the jfr (Flight Recorder) feature is being built by default for Zero JVMs. However, it's not clear whether there will be jfr support for the Zero variant JVM. At this point, when StartFlightRecording option is being used for a Zero JVM it asserts/crashes. It seems more appropriate to disable the feature for a default build and require one to enable the feature explicitly via: configure --with-jvm-feature=jfr --with-jvm-variants=zero We can revisit this change of default once there is good Zero+JFR support, which currently isn't the case. Bug: https://bugs.openjdk.java.net/browse/JDK-8203410 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.01/ Testing: Verified that the StartFlightRecording option is unrecognized for a default --with-jvm-variants=zero build. Thoughts? Thanks, Severin From adam.farley at uk.ibm.com Fri May 18 15:23:35 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 18 May 2018 16:23:35 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: <5AFCCAC0.6000706@oracle.com> References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: Hi, I tried to use the IJG's contact page, but no joy. Seems broken; there a spinning icon when you hit "send", but nothing happens. http://jpegclub.org/reference/contact/ So I used a slightly older mailing list on sourceforge. The request to update their code has been sent, and I hope it will appear on the mailing list soon. https://sourceforge.net/p/libjpeg/mailman/libjpeg-devel-6x/ However, that list seems fairly idle too. Does anyone know of another method we can use to communicate this fix upstream? Best Regards Adam > Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.cPhilip Race to: Adam Farley8 17/05/2018 03:32 > Cc: 2d-dev, Andrew Leonard, build-dev, Magnus Ihse Bursie, "Thomas St?fe" > From: Philip Race > To: Adam Farley8 > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard , build-dev , Magnus Ihse Bursie , "Thomas St?fe" > > > Hi, > > OK .. if you can convince upstream this is worth doing, then we can accept it > as we would not regress when updating. As I noted previously : > http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html > this is still an issue in the currently being developed 9c train. > > -phil. > > On 5/14/18, 3:06 AM, Adam Farley8 wrote: > Hi Phil, > > Would an acceptable compromise be to deliver the source code change > and send the code to the upstream community, allowing them to include > the fix if/when they are able? > > I believe Magnus was advocating this idea as well. See below. > > Best Regards > > Adam Farley > > > Same here. I would like to have this fix in, but do not want to go > > over Phils head. > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > Thanks, Thomas > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > wrote: > > > I don't object, but it's not build code so I don't have the final say. > > > > > > /Magnus > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > Hi All, > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > It doesn't break anything, it fixes a build break on two supported > > > platforms, and it seems > > > like we never refresh the code from upstream. > > > > > > - Adam > > > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > > >> of logic required > > >> to properly analyse the toolchain version string. > > >> > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > > >> and Make doesn't > > >> seem to do substring stuff unless you mess around with shells. > > >> > > >> Plus, as people have said, it's better to solve problem x (or work around > > >> a specific > > >> instance of x) than to ignore the exception, even if the ignoring code is > > >> toolchain- > > >> specific. > > >> > > >> - Adam Farley > > >> > > >> > On 2018-03-27 18:44, Phil Race wrote: > > >> > > > >> >> As I said I prefer the make file change, since this is a change to an > > >> >> upstream library. > > >> > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > >> > reviewer. :) > > >> > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > >> > complaint seems reasonable, and disabling it might cause us to miss other > > >> > future errors. > > >> > > > >> > Why can't we push the source code fix, and also submit it upstream? > > >> > > > >> > /Magnus > > >> > > > >> > > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > > >> > 6b, so this code > > >> > seems to have stood the test of time. I'm also unclear why the compiler > > >> > would > > >> > complain about that and not the one a few lines later > > >> > > > >> > > > >> > 819 while (bits[i] == 0) /* find largest codelength still in > > >> > use */ > > >> > 820 i--; > > >> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > >> > A tool-chain specific fix in the makefile with an appropriate comment is > > >> > more targeted. > > >> > > >> Phil, > > >> > > >> Returning to this. > > >> > > >> While I understand your reluctance to patch upstream code, let me point > > >> out that we have not updated libjpeg a single time since the JDK was open > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page > > >> on libjpeg, and this is the latest "uncontroversial" version of the source. > > >> Versions 7 and up have proprietary extensions, which in turn has resulted in > > >> multiple forks of libjpeg. As it stands, it seems unlikely that we will ever > > >> replace libjpeg 6b with a simple upgrade from upstream. > > >> > > >> I therefore maintain my position that a source code fix would be the best > > >> way forward here. > > >> > > >> /Magnus > > >> > > >> > > > >> > > > >> > -phil. > > >> > > > >> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > just a friendly reminder. I would like to push this tiny fix because > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > >> > maintain patch queues, but this is a constant error source). > > >> > > > >> > > > >> > I will wait for 24 more hours until a reaction. If no serious objections > > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph > > >> > langer are both Reviewers). > > >> > > > >> > > > >> > Thanks! Thomas > > >> > > > >> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > >> > wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > may I please have another review for this really trivial change. It > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix > > >> > this. > > >> > > > >> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > >> > webrev: > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > >> > > > >> > > > >> > This was contributed by Adam Farley at IBM. > > >> > > > >> > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > >> > > > >> > > > >> > Thanks, Thomas > > >> > > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > >> > > >> > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Fri May 18 15:29:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 May 2018 08:29:43 -0700 Subject: [8u] 8203349: 8u hotspot should recognise later Windows compilers In-Reply-To: <13e5ccc0-cdfb-aa02-1cfd-da966bfe4b4e@oracle.com> References: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> <13e5ccc0-cdfb-aa02-1cfd-da966bfe4b4e@oracle.com> Message-ID: Hello Kevin, I have a machine with both 2015 and 2017 installed and checked the link version numbers: VS2015: C:\Program Files (x86)\Microsoft Visual Studio 14.0>link /? Microsoft (R) Incremental Linker Version 14.00.24215.1 Copyright (C) Microsoft Corporation.? All rights reserved. VS2017: C:\Users\erik\source>link /? Microsoft (R) Incremental Linker Version 14.12.25835.0 Copyright (C) Microsoft Corporation.? All rights reserved. So it looks like you need to add 1412 to checkLink in sanity.make. /Erik On 2018-05-18 01:51, Kevin Walls wrote: > Hi Erik - > > Quite right, thanks.? Actually I should include recognising VS2015 > while I'm doing this. > > Update: http://cr.openjdk.java.net/~kevinw/8203349/webrev.01/ > > Also, update Abstract_VM_Version::internal_vm_info_string()? in > src/share/vm/runtime/vm_version.cpp so the long version string is > readable for these compilers. > > In the sanity checks for VS2015, I am predicting it has a linker > version of 1900 as it's between the 1800 and 1900 that I have seen > myself for the other versions I have. > > I have a local VS2013 build, and builds using the unchanged "official" > compiler are still OK. > > Thanks > Kevin > > > > On 17/05/2018 23:32, Erik Joelsson wrote: >> Hello Kevin, >> >> In JDK 11, vm_version.cpp we have _MSC_VER == 1900 translating to >> VS2015 and 1912 to VS2017. Is it really 1900 in nmake? >> >> Otherwise I think this looks ok. >> >> /Erik >> >> >> On 2018-05-17 15:21, Kevin Walls wrote: >>> Hi, >>> >>> I'd like to get a review for this 8u/hotspot build change for >>> Windows, to loosen the restriction on what compilers we can use. >>> >>> JBS: >>> 8203349: 8u hotspot should recognise later Windows compilers >>> https://bugs.openjdk.java.net/browse/JDK-8203349 >>> >>> Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/ >>> >>> Changes in the places we (sanity) check version numbers, set some >>> compile >>> options, and expand the check in vm.make to make sure we put the >>> precompiled >>> object? _build_pch_file.obj on the jvm link command. >>> >>> In compile.make I added blocks for VS2013 and 17, and left them as >>> separate, >>> duplicated, blocks of settings to make them easier to change >>> independently. >>> >>> This doesn't change anything about what is "supported" or documented >>> as working. >>> >>> Thanks! >>> Kevin >>> >>> >> > From erik.joelsson at oracle.com Fri May 18 15:41:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 May 2018 08:41:09 -0700 Subject: RFR: 8203410: Zero: Disable jfr feature by default In-Reply-To: <8116f11e918dc5d4b678d51715ed8f8f28e6724b.camel@redhat.com> References: <8116f11e918dc5d4b678d51715ed8f8f28e6724b.camel@redhat.com> Message-ID: <03443c3e-87e9-a5e4-883c-36178e9ba710@oracle.com> The change makes sense, but I think I would prefer if the conditional was based on jvm variant rather than the target cpu, like this: if ! HOTSPOT_CHECK_JVM_VARIANT(zero); then /Erik On 2018-05-18 06:57, Severin Gehwolf wrote: > Hi, > > Currently the jfr (Flight Recorder) feature is being built by default > for Zero JVMs. However, it's not clear whether there will be jfr > support for the Zero variant JVM. At this point, when > StartFlightRecording option is being used for a Zero JVM it > asserts/crashes. It seems more appropriate to disable the feature for a > default build and require one to enable the feature explicitly via: > > configure --with-jvm-feature=jfr --with-jvm-variants=zero > > We can revisit this change of default once there is good Zero+JFR > support, which currently isn't the case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203410 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.01/ > > Testing: Verified that the StartFlightRecording option is unrecognized > for a default --with-jvm-variants=zero build. > > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Fri May 18 16:27:41 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 18 May 2018 18:27:41 +0200 Subject: RFR: 8203410: Zero: Disable jfr feature by default In-Reply-To: <03443c3e-87e9-a5e4-883c-36178e9ba710@oracle.com> References: <8116f11e918dc5d4b678d51715ed8f8f28e6724b.camel@redhat.com> <03443c3e-87e9-a5e4-883c-36178e9ba710@oracle.com> Message-ID: <0cc5d89355b10bf5fe3d6d6f2239c3fb17da22c6.camel@redhat.com> Hi Erik, On Fri, 2018-05-18 at 08:41 -0700, Erik Joelsson wrote: > The change makes sense, but I think I would prefer if the conditional > was based on jvm variant rather than the target cpu, like this: > > if ! HOTSPOT_CHECK_JVM_VARIANT(zero); then Thanks for the review! New webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.02/ Cheers, Severin > /Erik > > > On 2018-05-18 06:57, Severin Gehwolf wrote: > > Hi, > > > > Currently the jfr (Flight Recorder) feature is being built by default > > for Zero JVMs. However, it's not clear whether there will be jfr > > support for the Zero variant JVM. At this point, when > > StartFlightRecording option is being used for a Zero JVM it > > asserts/crashes. It seems more appropriate to disable the feature for a > > default build and require one to enable the feature explicitly via: > > > > configure --with-jvm-feature=jfr --with-jvm-variants=zero > > > > We can revisit this change of default once there is good Zero+JFR > > support, which currently isn't the case. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203410 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.01/ > > > > Testing: Verified that the StartFlightRecording option is unrecognized > > for a default --with-jvm-variants=zero build. > > > > Thoughts? > > > > Thanks, > > Severin > > From erik.joelsson at oracle.com Fri May 18 16:50:35 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 May 2018 09:50:35 -0700 Subject: RFR: 8203410: Zero: Disable jfr feature by default In-Reply-To: <0cc5d89355b10bf5fe3d6d6f2239c3fb17da22c6.camel@redhat.com> References: <8116f11e918dc5d4b678d51715ed8f8f28e6724b.camel@redhat.com> <03443c3e-87e9-a5e4-883c-36178e9ba710@oracle.com> <0cc5d89355b10bf5fe3d6d6f2239c3fb17da22c6.camel@redhat.com> Message-ID: Looks good (assuming you have verified that it behaves as it should) /Erik On 2018-05-18 09:27, Severin Gehwolf wrote: > Hi Erik, > > On Fri, 2018-05-18 at 08:41 -0700, Erik Joelsson wrote: >> The change makes sense, but I think I would prefer if the conditional >> was based on jvm variant rather than the target cpu, like this: >> >> if ! HOTSPOT_CHECK_JVM_VARIANT(zero); then > Thanks for the review! > > New webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.02/ > > Cheers, > Severin > >> /Erik >> >> >> On 2018-05-18 06:57, Severin Gehwolf wrote: >>> Hi, >>> >>> Currently the jfr (Flight Recorder) feature is being built by default >>> for Zero JVMs. However, it's not clear whether there will be jfr >>> support for the Zero variant JVM. At this point, when >>> StartFlightRecording option is being used for a Zero JVM it >>> asserts/crashes. It seems more appropriate to disable the feature for a >>> default build and require one to enable the feature explicitly via: >>> >>> configure --with-jvm-feature=jfr --with-jvm-variants=zero >>> >>> We can revisit this change of default once there is good Zero+JFR >>> support, which currently isn't the case. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203410 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203410/webrev.01/ >>> >>> Testing: Verified that the StartFlightRecording option is unrecognized >>> for a default --with-jvm-variants=zero build. >>> >>> Thoughts? >>> >>> Thanks, >>> Severin >> From kevin.walls at oracle.com Fri May 18 16:53:05 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 18 May 2018 17:53:05 +0100 Subject: [8u] 8203349: 8u hotspot should recognise later Windows compilers In-Reply-To: References: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> <13e5ccc0-cdfb-aa02-1cfd-da966bfe4b4e@oracle.com> Message-ID: <09c35443-c51d-68f9-d963-5be80692eb4e@oracle.com> Great, thanks, rebuilt the webrev. If we add many more there we might want to rethink or reword the sanity warning, but I'd like to save that for another time. 8-) Thanks Kevin On 18/05/2018 16:29, Erik Joelsson wrote: > Hello Kevin, > > I have a machine with both 2015 and 2017 installed and checked the > link version numbers: > > VS2015: > > C:\Program Files (x86)\Microsoft Visual Studio 14.0>link /? > Microsoft (R) Incremental Linker Version 14.00.24215.1 > Copyright (C) Microsoft Corporation.? All rights reserved. > > VS2017: > > C:\Users\erik\source>link /? > Microsoft (R) Incremental Linker Version 14.12.25835.0 > Copyright (C) Microsoft Corporation.? All rights reserved. > > So it looks like you need to add 1412 to checkLink in sanity.make. > > /Erik > > > On 2018-05-18 01:51, Kevin Walls wrote: >> Hi Erik - >> >> Quite right, thanks.? Actually I should include recognising VS2015 >> while I'm doing this. >> >> Update: http://cr.openjdk.java.net/~kevinw/8203349/webrev.01/ >> >> Also, update Abstract_VM_Version::internal_vm_info_string()? in >> src/share/vm/runtime/vm_version.cpp so the long version string is >> readable for these compilers. >> >> In the sanity checks for VS2015, I am predicting it has a linker >> version of 1900 as it's between the 1800 and 1900 that I have seen >> myself for the other versions I have. >> >> I have a local VS2013 build, and builds using the unchanged >> "official" compiler are still OK. >> >> Thanks >> Kevin >> >> >> >> On 17/05/2018 23:32, Erik Joelsson wrote: >>> Hello Kevin, >>> >>> In JDK 11, vm_version.cpp we have _MSC_VER == 1900 translating to >>> VS2015 and 1912 to VS2017. Is it really 1900 in nmake? >>> >>> Otherwise I think this looks ok. >>> >>> /Erik >>> >>> >>> On 2018-05-17 15:21, Kevin Walls wrote: >>>> Hi, >>>> >>>> I'd like to get a review for this 8u/hotspot build change for >>>> Windows, to loosen the restriction on what compilers we can use. >>>> >>>> JBS: >>>> 8203349: 8u hotspot should recognise later Windows compilers >>>> https://bugs.openjdk.java.net/browse/JDK-8203349 >>>> >>>> Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/ >>>> >>>> Changes in the places we (sanity) check version numbers, set some >>>> compile >>>> options, and expand the check in vm.make to make sure we put the >>>> precompiled >>>> object? _build_pch_file.obj on the jvm link command. >>>> >>>> In compile.make I added blocks for VS2013 and 17, and left them as >>>> separate, >>>> duplicated, blocks of settings to make them easier to change >>>> independently. >>>> >>>> This doesn't change anything about what is "supported" or >>>> documented as working. >>>> >>>> Thanks! >>>> Kevin >>>> >>>> >>> >> > From erik.joelsson at oracle.com Fri May 18 16:54:30 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 May 2018 09:54:30 -0700 Subject: [8u] 8203349: 8u hotspot should recognise later Windows compilers In-Reply-To: <09c35443-c51d-68f9-d963-5be80692eb4e@oracle.com> References: <672231ce-9a74-af4e-88db-8044e4a74ebe@oracle.com> <13e5ccc0-cdfb-aa02-1cfd-da966bfe4b4e@oracle.com> <09c35443-c51d-68f9-d963-5be80692eb4e@oracle.com> Message-ID: Looks good. /Erik On 2018-05-18 09:53, Kevin Walls wrote: > Great, thanks, rebuilt the webrev. > > If we add many more there we might want to rethink or reword the > sanity warning, but I'd like to save that for another time. 8-) > > Thanks > Kevin > > > On 18/05/2018 16:29, Erik Joelsson wrote: >> Hello Kevin, >> >> I have a machine with both 2015 and 2017 installed and checked the >> link version numbers: >> >> VS2015: >> >> C:\Program Files (x86)\Microsoft Visual Studio 14.0>link /? >> Microsoft (R) Incremental Linker Version 14.00.24215.1 >> Copyright (C) Microsoft Corporation.? All rights reserved. >> >> VS2017: >> >> C:\Users\erik\source>link /? >> Microsoft (R) Incremental Linker Version 14.12.25835.0 >> Copyright (C) Microsoft Corporation.? All rights reserved. >> >> So it looks like you need to add 1412 to checkLink in sanity.make. >> >> /Erik >> >> >> On 2018-05-18 01:51, Kevin Walls wrote: >>> Hi Erik - >>> >>> Quite right, thanks.? Actually I should include recognising VS2015 >>> while I'm doing this. >>> >>> Update: http://cr.openjdk.java.net/~kevinw/8203349/webrev.01/ >>> >>> Also, update Abstract_VM_Version::internal_vm_info_string() in >>> src/share/vm/runtime/vm_version.cpp so the long version string is >>> readable for these compilers. >>> >>> In the sanity checks for VS2015, I am predicting it has a linker >>> version of 1900 as it's between the 1800 and 1900 that I have seen >>> myself for the other versions I have. >>> >>> I have a local VS2013 build, and builds using the unchanged >>> "official" compiler are still OK. >>> >>> Thanks >>> Kevin >>> >>> >>> >>> On 17/05/2018 23:32, Erik Joelsson wrote: >>>> Hello Kevin, >>>> >>>> In JDK 11, vm_version.cpp we have _MSC_VER == 1900 translating to >>>> VS2015 and 1912 to VS2017. Is it really 1900 in nmake? >>>> >>>> Otherwise I think this looks ok. >>>> >>>> /Erik >>>> >>>> >>>> On 2018-05-17 15:21, Kevin Walls wrote: >>>>> Hi, >>>>> >>>>> I'd like to get a review for this 8u/hotspot build change for >>>>> Windows, to loosen the restriction on what compilers we can use. >>>>> >>>>> JBS: >>>>> 8203349: 8u hotspot should recognise later Windows compilers >>>>> https://bugs.openjdk.java.net/browse/JDK-8203349 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~kevinw/8203349/webrev.00/ >>>>> >>>>> Changes in the places we (sanity) check version numbers, set some >>>>> compile >>>>> options, and expand the check in vm.make to make sure we put the >>>>> precompiled >>>>> object? _build_pch_file.obj on the jvm link command. >>>>> >>>>> In compile.make I added blocks for VS2013 and 17, and left them as >>>>> separate, >>>>> duplicated, blocks of settings to make them easier to change >>>>> independently. >>>>> >>>>> This doesn't change anything about what is "supported" or >>>>> documented as working. >>>>> >>>>> Thanks! >>>>> Kevin >>>>> >>>>> >>>> >>> >> > From thomas.stuefe at gmail.com Fri May 18 17:09:21 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 18 May 2018 19:09:21 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: I admire your perseverance :) but I think this is a fools errand. The amount of work you have to put into this far outbalances the amount of work the OpenJDK maintainers would have to spend when (if ever) they were to merge down upstream libjpeg. Note that we have a lot of experience with downstream work, since we are downstream from OpenJDK - and Oracle JDK before that - since like 14 years. Merging upstream with downstream-local patches is part of our daily business. That is why I also think that it is quite normal to keep local changes downstream and to merge, not just to replace, upstream changes. But to do that differently is Oracle's prerogative. I for now am resigned to live with local patches (the irony :-) to the s390 build. It is annoying but no big deal breaker. Thanks & best Regards, Thomas On Fri, May 18, 2018 at 5:23 PM, Adam Farley8 wrote: > Hi, > > I tried to use the IJG's contact page, but no joy. Seems broken; there a > spinning icon when you hit "send", but nothing happens. > > http://jpegclub.org/reference/contact/ > > So I used a slightly older mailing list on sourceforge. The request to > update their code has been sent, and I hope it will appear on the mailing > list soon. > > https://sourceforge.net/p/libjpeg/mailman/libjpeg-devel-6x/ > > However, that list seems fairly idle too. > > Does anyone know of another method we can use to communicate this fix > upstream? > > Best Regards > > Adam > >> Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning >> in jchuff.cPhilip Race to: Adam Farley8 17/05/2018 03:32 >> Cc: 2d-dev, Andrew Leonard, build-dev, Magnus Ihse Bursie, "Thomas St?fe" >> From: Philip Race >> To: Adam Farley8 >> Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard >> , build-dev , >> Magnus Ihse Bursie , "Thomas St?fe" >> >> >> >> Hi, >> >> OK .. if you can convince upstream this is worth doing, then we can accept >> it >> as we would not regress when updating. As I noted previously : >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html >> this is still an issue in the currently being developed 9c train. >> >> -phil. >> >> On 5/14/18, 3:06 AM, Adam Farley8 wrote: >> Hi Phil, >> >> Would an acceptable compromise be to deliver the source code change >> and send the code to the upstream community, allowing them to include >> the fix if/when they are able? >> >> I believe Magnus was advocating this idea as well. See below. >> >> Best Regards >> >> Adam Farley >> >> > Same here. I would like to have this fix in, but do not want to go >> > over Phils head. >> > >> > I think Phil was the main objector, maybe he could reconsider?` >> > >> > Thanks, Thomas >> > >> > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie >> > wrote: >> > > I don't object, but it's not build code so I don't have the final say. >> > > >> > > /Magnus >> > > >> > > >> > > On 2018-04-25 17:43, Adam Farley8 wrote: >> > > >> > > Hi All, >> > > >> > > Does anyone have an objection to pushing this tiny change in? >> > > >> > > It doesn't break anything, it fixes a build break on two supported >> > > platforms, and it seems >> > > like we never refresh the code from upstream. >> > > >> > > - Adam >> > > >> > >> I also advocate the source code fix, as Make isn't meant to use the >> > >> sort >> > >> of logic required >> > >> to properly analyse the toolchain version string. >> > >> >> > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using >> > >> 4.8.6, >> > >> and Make doesn't >> > >> seem to do substring stuff unless you mess around with shells. >> > >> >> > >> Plus, as people have said, it's better to solve problem x (or work >> > >> around >> > >> a specific >> > >> instance of x) than to ignore the exception, even if the ignoring >> > >> code is >> > >> toolchain- >> > >> specific. >> > >> >> > >> - Adam Farley >> > >> >> > >> > On 2018-03-27 18:44, Phil Race wrote: >> > >> > >> > >> >> As I said I prefer the make file change, since this is a change to >> > >> >> an >> > >> >> upstream library. >> > >> > >> > >> > Newtons fourth law: For every reviewer, there's an equal and >> > >> > opposite >> > >> > reviewer. :) >> > >> > >> > >> > Here I am, advocating a source code fix. As Thomas says, the >> > >> > compiler >> > >> > complaint seems reasonable, and disabling it might cause us to miss >> > >> > other >> > >> > future errors. >> > >> > >> > >> > Why can't we push the source code fix, and also submit it upstream? >> > >> > >> > >> > /Magnus >> > >> > >> > >> > >> > >> > I've looked at jpeg-9c and it still looks identical to what we have >> > >> > in >> > >> > 6b, so this code >> > >> > seems to have stood the test of time. I'm also unclear why the >> > >> > compiler >> > >> > would >> > >> > complain about that and not the one a few lines later >> > >> > >> > >> > >> > >> > 819 while (bits[i] == 0) /* find largest codelength >> > >> > still in >> > >> > use */ >> > >> > 820 i--; >> > >> > >> > >> > A push to jchuff.c will get blown away if/when we upgrade. >> > >> > A tool-chain specific fix in the makefile with an appropriate >> > >> > comment is >> > >> > more targeted. >> > >> >> > >> Phil, >> > >> >> > >> Returning to this. >> > >> >> > >> While I understand your reluctance to patch upstream code, let me >> > >> point >> > >> out that we have not updated libjpeg a single time since the JDK was >> > >> open >> > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the >> > >> Wikipedia page >> > >> on libjpeg, and this is the latest "uncontroversial" version of the >> > >> source. >> > >> Versions 7 and up have proprietary extensions, which in turn has >> > >> resulted in >> > >> multiple forks of libjpeg. As it stands, it seems unlikely that we >> > >> will ever >> > >> replace libjpeg 6b with a simple upgrade from upstream. >> > >> >> > >> I therefore maintain my position that a source code fix would be the >> > >> best >> > >> way forward here. >> > >> >> > >> /Magnus >> > >> >> > >> > >> > >> > >> > >> > -phil. >> > >> > >> > >> > >> > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: >> > >> > >> > >> > Hi all, >> > >> > >> > >> > >> > >> > just a friendly reminder. I would like to push this tiny fix >> > >> > because >> > >> > tripping over this on our linux s390x builds is annoying (yes, we >> > >> > can >> > >> > maintain patch queues, but this is a constant error source). >> > >> > >> > >> > >> > >> > I will wait for 24 more hours until a reaction. If no serious >> > >> > objections >> > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and >> > >> > Christoph >> > >> > langer are both Reviewers). >> > >> > >> > >> > >> > >> > Thanks! Thomas >> > >> > >> > >> > >> > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe >> > >> > >> > >> > wrote: >> > >> > >> > >> > Hi all, >> > >> > >> > >> > >> > >> > may I please have another review for this really trivial change. It >> > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good >> > >> > idea to fix >> > >> > this. >> > >> > >> > >> > >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 >> > >> > webrev: >> > >> > >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ >> > >> > >> > >> > >> > >> > This was contributed by Adam Farley at IBM. >> > >> > >> > >> > >> > >> > I already reviewed this. I also test-built on zlinux and it works. >> > >> > >> > >> > >> > >> > Thanks, Thomas >> > >> > >> > >> >> > >> Unless stated otherwise above: >> > >> IBM United Kingdom Limited - Registered in England and Wales with >> > >> number >> > >> 741598. >> > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire >> > >> PO6 3AU >> > >> >> > >> >> > > >> > > Unless stated otherwise above: >> > > IBM United Kingdom Limited - Registered in England and Wales with >> > > number >> > > 741598. >> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 >> > > 3AU >> > > >> > > >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From igor.ignatyev at oracle.com Fri May 18 17:12:36 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 May 2018 10:12:36 -0700 Subject: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests In-Reply-To: <71c70cd8821a4f1ca333f4ceea578e4f@sap.com> References: <8D49F7BE-84F3-4E3D-B9DC-30233E005263@oracle.com> <71c70cd8821a4f1ca333f4ceea578e4f@sap.com> Message-ID: <5B99D22D-1862-405B-80E8-2568DCB7435A@oracle.com> Hi Martin, as it breaks build, it definitely has to be fixed. I have filed 8203437. the obvious fix for this warning would be: > diff -r 3af6ed2513aa test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c > --- a/test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c Thu May 17 21:05:43 2018 -0700 > +++ b/test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.c Fri May 18 10:02:11 2018 -0700 > @@ -27,7 +27,7 @@ > Java_gc_gctests_nativeGC05_nativeGC05_kickOffRefillers > (JNIEnv *env, jobject obj, jobject matrix, jobject stack) { > jclass matrixClass, stackClass, pairClass = 0; > - jmethodID stack_pop_mid, stack_empty_mid, matrix_repopulate_mid, pair_geti_mid, pair_getj_mid; > + jmethodID stack_pop_mid, stack_empty_mid, matrix_repopulate_mid, pair_geti_mid, pair_getj_mid = 0; > jobject pair; > jint i, j; > jboolean b; while I'm in progress of setting up a linux w/ gcc4.8.5 (which due to different reasons might take some time), could you please verify whether it fixes this warning and if there are other warnings from your compilers? if there are, you can get the whole list by disable warnings as error (configure --disable-warnings-as-errors) and then grep for ': warning:' in 'build/*/build.log'. Thanks, -- Igor > On May 18, 2018, at 5:03 AM, Doerr, Martin wrote: > > Hi Igor, > > we get compiler warnings on linux ppc64le (GCC 4.8.5): > > libnativeGC05.c:80:19: error: 'pair_getj_mid' may be used uninitialized in this function [-Werror=maybe-uninitialized] > j = (*env)->CallIntMethod(env, pair, pair_getj_mid); > ^ > > libnativeGC05.c:78:19: error: 'pair_geti_mid' may be used uninitialized in this function [-Werror=maybe-uninitialized] > i = (*env)->CallIntMethod(env, pair, pair_geti_mid); > ^ > > Unfortunately, the files are compiled with warnings as errors. We think this should get fixed. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev > Sent: Dienstag, 15. Mai 2018 20:59 > To: Erik Helin > Cc: hotspot-gc-dev ; build-dev ; hotspot-dev developers > Subject: Re: RFR(L) : 8199370: [TESTBUG] Open source vm testbase GC tests > > Hi Erik, > > please see my answers inline. > > can I consider this RFR as reviewed by you? > > Thanks, > -- Igor > >> On May 14, 2018, at 4:23 AM, Erik Helin wrote: >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> Hi all, >> >> Hi Igor, >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> could you please review the patch which open sources GC tests from vm testbase? it introduces the following test groups: >>> - vmTestbase_vm_g1classunloading >>> - vmTestbase_vm_gc_compact >>> - vmTestbase_vm_gc_concurrent >>> - vmTestbase_vm_gc_container >>> - vmTestbase_vm_gc_juggle >>> - vmTestbase_vm_gc_locker >>> - vmTestbase_vm_gc_ref >>> - vmTestbase_vm_gc_misc >> >> This is a very welcome, and pretty massive, change :) I won't be able to read through each test, there are simple too many, but I can sample a few of them and have a look. >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. >> >> I'm also assuming that to help the open sourcing of these tests, most comments will likely be deferred until later? If so, that is fine with me. > y, unless it is something very important and cost of delaying changes is high, I'd prefer to defer all comments/improvements till later. >> >> On 05/08/2018 12:35 AM, Igor Ignatyev wrote: >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199370 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8199370/webrev.00/index.html >> >> Many of the tests are a bit cryptic, but that can be refactored later. Could you please file bugs for the two tests written in shell? Particularly parOld/test.sh should be trivial to rewrite in Java. > sure, I've filed 8203239 and 8203238. >> >> It seems like a lot of tests contains a TEST.properties file with the content `exclusiveAccess.dirs=.`. Could this become the default value somewhere, so we don't need all those TEST.properties files? > y, but this will require finding a most top directory whose all tests have this TEST.properties file and it will also make it harder to understand how a test is executed. there was/is ongoing discussing w/ Jon on moving 'exclusiveAccess' to test description. anyhow I've filed an RFE to clean that up -- 8203241. > >> >> Thanks, >> Erik >> >>> Thanks, >>> -- Igor > From kevin.walls at oracle.com Fri May 18 20:42:32 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 18 May 2018 21:42:32 +0100 Subject: [8u] 8078437: Enable use of devkits for Windows. Message-ID: <4d7dfbb2-88b4-0a47-cb6b-87112e162414@oracle.com> Hi, I'd like to get a review of a backport from 9 to 8u: 8078437: Enable use of devkits for Windows. JBS: https://bugs.openjdk.java.net/browse/JDK-8078437 9 changeset: URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/bc02cff96b92 9 review thread: http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014870.html 8u webrev: http://cr.openjdk.java.net/~kevinw/8078437/webrev.00/ common/autoconf/toolchain_windows.m4? ...this one had some manual work, but some of that was just re-indenting. common/autoconf/toolchain.m4 change didn't import but the line split in the if statement looks cosmetic anyway.? I copied it as I'm here. Other files import OK, plus regenerating the generated files. With this change, the regular build still works as before, plus we can do: $ bash ./configure --with-toolchain-version=2013 --with-devkit=/devkitdir ..and e.g. make images uses that compiler. (that does also need the hotspot change 8203349, but 2013 is the devkit bundle I have to hand) Thanks! Kevin From erik.joelsson at oracle.com Fri May 18 21:14:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 May 2018 14:14:36 -0700 Subject: [8u] 8078437: Enable use of devkits for Windows. In-Reply-To: <4d7dfbb2-88b4-0a47-cb6b-87112e162414@oracle.com> References: <4d7dfbb2-88b4-0a47-cb6b-87112e162414@oracle.com> Message-ID: <36b87d80-5b68-e21f-d435-9ccfceb8c200@oracle.com> Hello, In toolchain_windows.m4, line 296 needs indentation. Also you skipped line 327-332 which were broken up in the jdk 9 change. Can't see anything functionally bad, only style issues. I don't think you need to specify --with-toolchain-version=2013 when using the devkit, it should contain the necessary information for configure to pick it up automatically. /Erik On 2018-05-18 13:42, Kevin Walls wrote: > Hi, > > I'd like to get a review of a backport from 9 to 8u: > > 8078437: Enable use of devkits for Windows. > JBS: https://bugs.openjdk.java.net/browse/JDK-8078437 > > 9 changeset: > URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/bc02cff96b92 > > 9 review thread: > http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014870.html > > 8u webrev: http://cr.openjdk.java.net/~kevinw/8078437/webrev.00/ > > common/autoconf/toolchain_windows.m4? ...this one had some manual > work, but some of that was just re-indenting. > common/autoconf/toolchain.m4 change didn't import but the line split > in the if statement looks cosmetic anyway.? I copied it as I'm here. > Other files import OK, plus regenerating the generated files. > > With this change, the regular build still works as before, plus we can > do: > > $ bash ./configure --with-toolchain-version=2013 --with-devkit=/devkitdir > ..and e.g. make images uses that compiler. > > (that does also need the hotspot change 8203349, but 2013 is the > devkit bundle I have to hand) > > Thanks! > Kevin > From kevin.walls at oracle.com Fri May 18 21:58:00 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 18 May 2018 22:58:00 +0100 Subject: [8u] 8078437: Enable use of devkits for Windows. In-Reply-To: <36b87d80-5b68-e21f-d435-9ccfceb8c200@oracle.com> References: <4d7dfbb2-88b4-0a47-cb6b-87112e162414@oracle.com> <36b87d80-5b68-e21f-d435-9ccfceb8c200@oracle.com> Message-ID: <9c238f77-16e5-dfc0-8d33-e83999fe316f@oracle.com> Thanks Erik - OK, got those indent and line breaks added, updated webrev in the same location. Quite right, it will accept the devkit location with being told its specific toolchain version. Thanks for the feeback! Kevin On 18/05/2018 22:14, Erik Joelsson wrote: > Hello, > > In toolchain_windows.m4, line 296 needs indentation. Also you skipped > line 327-332 which were broken up in the jdk 9 change. > > Can't see anything functionally bad, only style issues. > > I don't think you need to specify --with-toolchain-version=2013 when > using the devkit, it should contain the necessary information for > configure to pick it up automatically. > > /Erik > > On 2018-05-18 13:42, Kevin Walls wrote: >> Hi, >> >> I'd like to get a review of a backport from 9 to 8u: >> >> 8078437: Enable use of devkits for Windows. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8078437 >> >> 9 changeset: >> URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/bc02cff96b92 >> >> 9 review thread: >> http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014870.html >> >> 8u webrev: http://cr.openjdk.java.net/~kevinw/8078437/webrev.00/ >> >> common/autoconf/toolchain_windows.m4? ...this one had some manual >> work, but some of that was just re-indenting. >> common/autoconf/toolchain.m4 change didn't import but the line split >> in the if statement looks cosmetic anyway.? I copied it as I'm here. >> Other files import OK, plus regenerating the generated files. >> >> With this change, the regular build still works as before, plus we >> can do: >> >> $ bash ./configure --with-toolchain-version=2013 >> --with-devkit=/devkitdir >> ..and e.g. make images uses that compiler. >> >> (that does also need the hotspot change 8203349, but 2013 is the >> devkit bundle I have to hand) >> >> Thanks! >> Kevin >> > From erik.joelsson at oracle.com Fri May 18 22:28:19 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 18 May 2018 15:28:19 -0700 Subject: [8u] 8078437: Enable use of devkits for Windows. In-Reply-To: <9c238f77-16e5-dfc0-8d33-e83999fe316f@oracle.com> References: <4d7dfbb2-88b4-0a47-cb6b-87112e162414@oracle.com> <36b87d80-5b68-e21f-d435-9ccfceb8c200@oracle.com> <9c238f77-16e5-dfc0-8d33-e83999fe316f@oracle.com> Message-ID: Looks good. /Erik On 2018-05-18 14:58, Kevin Walls wrote: > Thanks Erik - > > OK, got those indent and line breaks added, updated webrev in the same > location. > > Quite right, it will accept the devkit location with being told its > specific toolchain version. > > Thanks for the feeback! > Kevin > > > On 18/05/2018 22:14, Erik Joelsson wrote: >> Hello, >> >> In toolchain_windows.m4, line 296 needs indentation. Also you skipped >> line 327-332 which were broken up in the jdk 9 change. >> >> Can't see anything functionally bad, only style issues. >> >> I don't think you need to specify --with-toolchain-version=2013 when >> using the devkit, it should contain the necessary information for >> configure to pick it up automatically. >> >> /Erik >> >> On 2018-05-18 13:42, Kevin Walls wrote: >>> Hi, >>> >>> I'd like to get a review of a backport from 9 to 8u: >>> >>> 8078437: Enable use of devkits for Windows. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8078437 >>> >>> 9 changeset: >>> URL:?? http://hg.openjdk.java.net/jdk9/dev/rev/bc02cff96b92 >>> >>> 9 review thread: >>> http://mail.openjdk.java.net/pipermail/build-dev/2015-April/014870.html >>> >>> 8u webrev: http://cr.openjdk.java.net/~kevinw/8078437/webrev.00/ >>> >>> common/autoconf/toolchain_windows.m4? ...this one had some manual >>> work, but some of that was just re-indenting. >>> common/autoconf/toolchain.m4 change didn't import but the line split >>> in the if statement looks cosmetic anyway.? I copied it as I'm here. >>> Other files import OK, plus regenerating the generated files. >>> >>> With this change, the regular build still works as before, plus we >>> can do: >>> >>> $ bash ./configure --with-toolchain-version=2013 >>> --with-devkit=/devkitdir >>> ..and e.g. make images uses that compiler. >>> >>> (that does also need the hotspot change 8203349, but 2013 is the >>> devkit bundle I have to hand) >>> >>> Thanks! >>> Kevin >>> >> > From shade at redhat.com Sat May 19 09:20:16 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 19 May 2018 11:20:16 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) Message-ID: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8203454 Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) would require excluding their "gc//c2" as well. Fix: diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 11:01:16 2018 +0200 @@ -41,7 +41,7 @@ else JVM_EXCLUDES += opto libadt JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp - JVM_EXCLUDE_PATTERNS += c2_ runtime_ + JVM_EXCLUDE_PATTERNS += c2_ runtime_ gc/shared/c2 gc/g1/c2 endif ifeq ($(call check-jvm-feature, zero), true) Testing: {x86-minimal, x86_64-zero, x86_64-server} builds Thanks, -Aleksey From thomas.stuefe at gmail.com Sat May 19 09:54:46 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 19 May 2018 11:54:46 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> Message-ID: Hi Alexey, looks good and works. Thanks for fixing. ..Thomas On Sat, May 19, 2018 at 11:20 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8203454 > > Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) > would require excluding their "gc//c2" as well. > > Fix: > > diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk > --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 > +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 11:01:16 2018 +0200 > @@ -41,7 +41,7 @@ > else > JVM_EXCLUDES += opto libadt > JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp > - JVM_EXCLUDE_PATTERNS += c2_ runtime_ > + JVM_EXCLUDE_PATTERNS += c2_ runtime_ gc/shared/c2 gc/g1/c2 > endif > > ifeq ($(call check-jvm-feature, zero), true) > > Testing: {x86-minimal, x86_64-zero, x86_64-server} builds > > Thanks, > -Aleksey > From erik.osterlund at oracle.com Sat May 19 10:50:42 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Sat, 19 May 2018 12:50:42 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> Message-ID: <0AABBD63-D166-47F8-AE3E-CFCF60B0D4A7@oracle.com> Hi Aleksey, Thanks for fixing. I wonder if /c2/ could be added to the exclude pattern instead though, instead of enumerating all GCs. Thanks, /Erik > On 19 May 2018, at 11:20, Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8203454 > > Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) > would require excluding their "gc//c2" as well. > > Fix: > > diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk > --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 > +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 11:01:16 2018 +0200 > @@ -41,7 +41,7 @@ > else > JVM_EXCLUDES += opto libadt > JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp > - JVM_EXCLUDE_PATTERNS += c2_ runtime_ > + JVM_EXCLUDE_PATTERNS += c2_ runtime_ gc/shared/c2 gc/g1/c2 > endif > > ifeq ($(call check-jvm-feature, zero), true) > > Testing: {x86-minimal, x86_64-zero, x86_64-server} builds > > Thanks, > -Aleksey > From shade at redhat.com Sat May 19 11:52:07 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 19 May 2018 13:52:07 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <0AABBD63-D166-47F8-AE3E-CFCF60B0D4A7@oracle.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <0AABBD63-D166-47F8-AE3E-CFCF60B0D4A7@oracle.com> Message-ID: <5a088cc5-47ce-9ea5-69a8-ffde4465c995@redhat.com> Okay, this also works for Zero, Minimal and server: diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 13:36:32 2018 +0200 @@ -41,7 +41,7 @@ else JVM_EXCLUDES += opto libadt JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp - JVM_EXCLUDE_PATTERNS += c2_ runtime_ + JVM_EXCLUDE_PATTERNS += c2_ runtime_ /c2/ endif ifeq ($(call check-jvm-feature, zero), true) -Aleksey On 05/19/2018 12:50 PM, Erik Osterlund wrote: > Hi Aleksey, > > Thanks for fixing. > > I wonder if /c2/ could be added to the exclude pattern instead though, instead of enumerating all GCs. > > Thanks, > /Erik > >> On 19 May 2018, at 11:20, Aleksey Shipilev wrote: >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8203454 >> >> Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) >> would require excluding their "gc//c2" as well. >> >> Fix: >> >> diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk >> --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 >> +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 11:01:16 2018 +0200 >> @@ -41,7 +41,7 @@ >> else >> JVM_EXCLUDES += opto libadt >> JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp >> - JVM_EXCLUDE_PATTERNS += c2_ runtime_ >> + JVM_EXCLUDE_PATTERNS += c2_ runtime_ gc/shared/c2 gc/g1/c2 >> endif >> >> ifeq ($(call check-jvm-feature, zero), true) >> >> Testing: {x86-minimal, x86_64-zero, x86_64-server} builds >> >> Thanks, >> -Aleksey >> > From erik.osterlund at oracle.com Sat May 19 11:57:24 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Sat, 19 May 2018 13:57:24 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <5a088cc5-47ce-9ea5-69a8-ffde4465c995@redhat.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <0AABBD63-D166-47F8-AE3E-CFCF60B0D4A7@oracle.com> <5a088cc5-47ce-9ea5-69a8-ffde4465c995@redhat.com> Message-ID: Hi Aleksey, Looks good. Thanks, /Erik On 2018-05-19 13:52, Aleksey Shipilev wrote: > Okay, this also works for Zero, Minimal and server: > > diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk > --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 > +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 13:36:32 2018 +0200 > @@ -41,7 +41,7 @@ > else > JVM_EXCLUDES += opto libadt > JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp > - JVM_EXCLUDE_PATTERNS += c2_ runtime_ > + JVM_EXCLUDE_PATTERNS += c2_ runtime_ /c2/ > endif > > ifeq ($(call check-jvm-feature, zero), true) > > > -Aleksey > > On 05/19/2018 12:50 PM, Erik Osterlund wrote: >> Hi Aleksey, >> >> Thanks for fixing. >> >> I wonder if /c2/ could be added to the exclude pattern instead though, instead of enumerating all GCs. >> >> Thanks, >> /Erik >> >>> On 19 May 2018, at 11:20, Aleksey Shipilev wrote: >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8203454 >>> >>> Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) >>> would require excluding their "gc//c2" as well. >>> >>> Fix: >>> >>> diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk >>> --- a/make/hotspot/lib/JvmFeatures.gmk Fri May 18 18:31:28 2018 -0700 >>> +++ b/make/hotspot/lib/JvmFeatures.gmk Sat May 19 11:01:16 2018 +0200 >>> @@ -41,7 +41,7 @@ >>> else >>> JVM_EXCLUDES += opto libadt >>> JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp >>> - JVM_EXCLUDE_PATTERNS += c2_ runtime_ >>> + JVM_EXCLUDE_PATTERNS += c2_ runtime_ gc/shared/c2 gc/g1/c2 >>> endif >>> >>> ifeq ($(call check-jvm-feature, zero), true) >>> >>> Testing: {x86-minimal, x86_64-zero, x86_64-server} builds >>> >>> Thanks, >>> -Aleksey >>> > From philip.race at oracle.com Sat May 19 23:53:19 2018 From: philip.race at oracle.com (Philip Race) Date: Sat, 19 May 2018 16:53:19 -0700 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> Message-ID: <5B00B8EF.8000208@oracle.com> I think I am 99% OK with this. In general I see what you are doing here and how you've presented the webrev. Treating even the new files as moved helps see the differences but it is still a challenge to follow all the moving pieces. So before we had just abstract class unix/X11InputMethod <- class unix/XInputMethod Now we have abstract class unix/X11InputMethodBase / \ / \ / \ / \ abstract class unix/X11InputMethod abstract class aix/X11InputMethod \ / \ / \ / class unix/XInputMethod I have submitted a build job with this patch to make sure it all builds on Linux & Solaris .. and it was all fine. But testing for this would have to be manual, and I don't have cycles for that. So I'll have to accept that the testing done by IBM was enough So only minor comments ... http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java.sdiff.html 730 case 0: //None of the value is set by Wnn "value is " -> "values are " ? http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c.sdiff.html why did you move 26 #ifdef HEADLESS 27 #error This file should not be included in headless library 28 #endif I think it should be first. It is also missing from the equivalent AIX file but that is up to you .. I really didn't look any further at the AIX files. .. and there seems no point to moving around some of the other includes except to make the webrev harder to read :-) But good job cleaning up a lot of the formatting of the native code. -phil. On 5/18/18, 4:59 AM, Langer, Christoph wrote: > Hi all, > > Here is an updated webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ > Can someone from the graphics/awt team please have a look at that change? Especially checking that we don't break non-AIX platforms? Thanks in advance. > > @Ichiroh: Thanks for your review and tests. Adressing your points: > >> resetCompositionState() was missing in >> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java >> ========================================================== >> == >> --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May >> 09 09:05:32 2018 +0900 >> +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon >> May >> 14 21:25:50 2018 +0900 >> @@ -56,6 +56,21 @@ >> } >> >> /** >> + * Reset the composition state to the current composition state. >> + */ >> + protected void resetCompositionState() { >> + if (compositionEnableSupported&& haveActiveClient()) { >> + try { >> + /* Restore the composition mode to the last saved >> composition >> + mode. */ >> + setCompositionEnabled(savedCompositionState); >> + } catch (UnsupportedOperationException e) { >> + compositionEnableSupported = false; >> + } >> + } >> + } >> + >> + /** >> * Activate input method. >> */ >> public synchronized void activate() { >> ========================================================== > Good catch. I've incorporated that in my new webrev. > >> Otherwise, >> we could not find out any functional difference on Linux. >> we could not find out any functional difference between our modified code and your code on AIX. >> >> By code check, we found following difference. >> ========================================================== >> == >> --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >> Wed May 09 09:05:32 2018 +0900 >> +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c >> Mon May 14 21:25:50 2018 +0900 >> @@ -248,6 +248,10 @@ >> "flushText", >> "()V"); >> JNU_CHECK_EXCEPTION_RETURN(env, NULL); >> + if ((*env)->ExceptionOccurred(env)) { >> + (*env)->ExceptionDescribe(env); >> + (*env)->ExceptionClear(env); >> + } >> /* IMPORTANT: >> The order of the following calls is critical since >> "imInstance" may >> point to the global reference itself, if >> "freeX11InputMethodData" is called >> ========================================================== >> >> Did you remove this code intentionally ? > Yes, I removed that one intentionally. There is no point in doing the Exception check/clearing after a call to JNU_CHECK_EXCEPTION_RETURN(env, NULL); > >> Otherwise, I think the other changes were acceptable. > ? > > Thanks and Best regards > Christoph > From adam.farley at uk.ibm.com Mon May 21 08:51:48 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 21 May 2018 09:51:48 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: Thanks for the compliment, but I plan to leave this open for a little while longer. I have already heard back from the 6x community, and they say they are no longer associated with the IJG group (jpegclub.org) that creates 9x. Unless we see the potential for an upstream merge from the sourceforge 6x group, I'll be concentrating exclusively on pushing the change to the IJG 9x group. I found some email addresses on the IJG "Site Notice" page, and have already emailed the most likely one to try and push the change. In the meantime, I recommend getting the change into our local copy of the code to fix the bug. Phil, your thoughts? Best Regards Adam > I admire your perseverance :) but I think this is a fools errand. > > The amount of work you have to put into this far outbalances the > amount of work the OpenJDK maintainers would have to spend when (if > ever) they were to merge down upstream libjpeg. > > Note that we have a lot of experience with downstream work, since we > are downstream from OpenJDK - and Oracle JDK before that - since like > 14 years. Merging upstream with downstream-local patches is part of > our daily business. That is why I also think that it is quite normal > to keep local changes downstream and to merge, not just to replace, > upstream changes. But to do that differently is Oracle's prerogative. > > I for now am resigned to live with local patches (the irony :-) to the > s390 build. It is annoying but no big deal breaker. > > Thanks & best Regards, Thomas > > > On Fri, May 18, 2018 at 5:23 PM, Adam Farley8 wrote: > > Hi, > > > > I tried to use the IJG's contact page, but no joy. Seems broken; there a > > spinning icon when you hit "send", but nothing happens. > > > > http://jpegclub.org/reference/contact/ > > > > So I used a slightly older mailing list on sourceforge. The request to > > update their code has been sent, and I hope it will appear on the mailing > > list soon. > > > > https://sourceforge.net/p/libjpeg/mailman/libjpeg-devel-6x/ > > > > However, that list seems fairly idle too. > > > > Does anyone know of another method we can use to communicate this fix > > upstream? > > > > Best Regards > > > > Adam > > > >> Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning > >> in jchuff.cPhilip Race to: Adam Farley8 17/05/2018 03:32 > >> Cc: 2d-dev, Andrew Leonard, build-dev, Magnus Ihse Bursie, "Thomas St?fe" > >> From: Philip Race > >> To: Adam Farley8 > >> Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > >> , build-dev , > >> Magnus Ihse Bursie , "Thomas St?fe" > >> > >> > >> > >> Hi, > >> > >> OK .. if you can convince upstream this is worth doing, then we can accept > >> it > >> as we would not regress when updating. As I noted previously : > >> http://mail.openjdk.java.net/pipermail/2d-dev/2018-March/009086.html > >> this is still an issue in the currently being developed 9c train. > >> > >> -phil. > >> > >> On 5/14/18, 3:06 AM, Adam Farley8 wrote: > >> Hi Phil, > >> > >> Would an acceptable compromise be to deliver the source code change > >> and send the code to the upstream community, allowing them to include > >> the fix if/when they are able? > >> > >> I believe Magnus was advocating this idea as well. See below. > >> > >> Best Regards > >> > >> Adam Farley > >> > >> > Same here. I would like to have this fix in, but do not want to go > >> > over Phils head. > >> > > >> > I think Phil was the main objector, maybe he could reconsider?` > >> > > >> > Thanks, Thomas > >> > > >> > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > >> > wrote: > >> > > I don't object, but it's not build code so I don't have the final say. > >> > > > >> > > /Magnus > >> > > > >> > > > >> > > On 2018-04-25 17:43, Adam Farley8 wrote: > >> > > > >> > > Hi All, > >> > > > >> > > Does anyone have an objection to pushing this tiny change in? > >> > > > >> > > It doesn't break anything, it fixes a build break on two supported > >> > > platforms, and it seems > >> > > like we never refresh the code from upstream. > >> > > > >> > > - Adam > >> > > > >> > >> I also advocate the source code fix, as Make isn't meant to use the > >> > >> sort > >> > >> of logic required > >> > >> to properly analyse the toolchain version string. > >> > >> > >> > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using > >> > >> 4.8.6, > >> > >> and Make doesn't > >> > >> seem to do substring stuff unless you mess around with shells. > >> > >> > >> > >> Plus, as people have said, it's better to solve problem x (or work > >> > >> around > >> > >> a specific > >> > >> instance of x) than to ignore the exception, even if the ignoring > >> > >> code is > >> > >> toolchain- > >> > >> specific. > >> > >> > >> > >> - Adam Farley > >> > >> > >> > >> > On 2018-03-27 18:44, Phil Race wrote: > >> > >> > > >> > >> >> As I said I prefer the make file change, since this is a change to > >> > >> >> an > >> > >> >> upstream library. > >> > >> > > >> > >> > Newtons fourth law: For every reviewer, there's an equal and > >> > >> > opposite > >> > >> > reviewer. :) > >> > >> > > >> > >> > Here I am, advocating a source code fix. As Thomas says, the > >> > >> > compiler > >> > >> > complaint seems reasonable, and disabling it might cause us to miss > >> > >> > other > >> > >> > future errors. > >> > >> > > >> > >> > Why can't we push the source code fix, and also submit it upstream? > >> > >> > > >> > >> > /Magnus > >> > >> > > >> > >> > > >> > >> > I've looked at jpeg-9c and it still looks identical to what we have > >> > >> > in > >> > >> > 6b, so this code > >> > >> > seems to have stood the test of time. I'm also unclear why the > >> > >> > compiler > >> > >> > would > >> > >> > complain about that and not the one a few lines later > >> > >> > > >> > >> > > >> > >> > 819 while (bits[i] == 0) /* find largest codelength > >> > >> > still in > >> > >> > use */ > >> > >> > 820 i--; > >> > >> > > >> > >> > A push to jchuff.c will get blown away if/when we upgrade. > >> > >> > A tool-chain specific fix in the makefile with an appropriate > >> > >> > comment is > >> > >> > more targeted. > >> > >> > >> > >> Phil, > >> > >> > >> > >> Returning to this. > >> > >> > >> > >> While I understand your reluctance to patch upstream code, let me > >> > >> point > >> > >> out that we have not updated libjpeg a single time since the JDK was > >> > >> open > >> > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > >> > >> Wikipedia page > >> > >> on libjpeg, and this is the latest "uncontroversial" version of the > >> > >> source. > >> > >> Versions 7 and up have proprietary extensions, which in turn has > >> > >> resulted in > >> > >> multiple forks of libjpeg. As it stands, it seems unlikely that we > >> > >> will ever > >> > >> replace libjpeg 6b with a simple upgrade from upstream. > >> > >> > >> > >> I therefore maintain my position that a source code fix would be the > >> > >> best > >> > >> way forward here. > >> > >> > >> > >> /Magnus > >> > >> > >> > >> > > >> > >> > > >> > >> > -phil. > >> > >> > > >> > >> > > >> > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > >> > >> > > >> > >> > Hi all, > >> > >> > > >> > >> > > >> > >> > just a friendly reminder. I would like to push this tiny fix > >> > >> > because > >> > >> > tripping over this on our linux s390x builds is annoying (yes, we > >> > >> > can > >> > >> > maintain patch queues, but this is a constant error source). > >> > >> > > >> > >> > > >> > >> > I will wait for 24 more hours until a reaction. If no serious > >> > >> > objections > >> > >> > are forcoming, I want to push it (tier1 tests ran thru, and me and > >> > >> > Christoph > >> > >> > langer are both Reviewers). > >> > >> > > >> > >> > > >> > >> > Thanks! Thomas > >> > >> > > >> > >> > > >> > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > >> > >> > > >> > >> > wrote: > >> > >> > > >> > >> > Hi all, > >> > >> > > >> > >> > > >> > >> > may I please have another review for this really trivial change. It > >> > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good > >> > >> > idea to fix > >> > >> > this. > >> > >> > > >> > >> > > >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > >> > >> > webrev: > >> > >> > > >> > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > >> > >> > > >> > >> > > >> > >> > This was contributed by Adam Farley at IBM. > >> > >> > > >> > >> > > >> > >> > I already reviewed this. I also test-built on zlinux and it works. > >> > >> > > >> > >> > > >> > >> > Thanks, Thomas > >> > >> > > >> > >> > >> > >> Unless stated otherwise above: > >> > >> IBM United Kingdom Limited - Registered in England and Wales with > >> > >> number > >> > >> 741598. > >> > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > >> > >> PO6 3AU > >> > >> > >> > >> > >> > > > >> > > Unless stated otherwise above: > >> > > IBM United Kingdom Limited - Registered in England and Wales with > >> > > number > >> > > 741598. > >> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > >> > > 3AU > >> > > > >> > > > >> > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > >> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From glaubitz at physik.fu-berlin.de Mon May 21 09:07:06 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 21 May 2018 11:07:06 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: On 05/18/2018 07:09 PM, Thomas St?fe wrote: > The amount of work you have to put into this far outbalances the > amount of work the OpenJDK maintainers would have to spend when (if > ever) they were to merge down upstream libjpeg. You might have more luck if you replaced libjpeg with libjpeg-turbo which is used as the default libjpeg implementation in most Linux distributions these days. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Mon May 21 09:14:43 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 21 May 2018 11:14:43 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: On Mon, May 21, 2018 at 11:07 AM, John Paul Adrian Glaubitz wrote: > On 05/18/2018 07:09 PM, Thomas St?fe wrote: >> The amount of work you have to put into this far outbalances the >> amount of work the OpenJDK maintainers would have to spend when (if >> ever) they were to merge down upstream libjpeg. > > You might have more luck if you replaced libjpeg with libjpeg-turbo > which is used as the default libjpeg implementation in most Linux > distributions these days. > Good idea, but not my call to make.... ..Thomas > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From akashche at redhat.com Mon May 21 12:31:21 2018 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 21 May 2018 13:31:21 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> <5AFCCAC0.6000706@oracle.com> Message-ID: <8846c77d-2501-7b6e-aaf1-3da557b5ddbd@redhat.com> Hi, On 05/21/2018 10:14 AM, Thomas St?fe wrote: > On Mon, May 21, 2018 at 11:07 AM, John Paul Adrian Glaubitz > wrote: >> On 05/18/2018 07:09 PM, Thomas St?fe wrote: >>> The amount of work you have to put into this far outbalances the >>> amount of work the OpenJDK maintainers would have to spend when (if >>> ever) they were to merge down upstream libjpeg. >> >> You might have more luck if you replaced libjpeg with libjpeg-turbo >> which is used as the default libjpeg implementation in most Linux >> distributions these days. >> > > Good idea, but not my call to make.... We ship libjpeg-turbo with RH windows builds of OpenJDK. I can say that it is not the nicest codebase to build (mostly asm, written for NASM; can be built without asm part, but that is not how most people use it). While linux distros give it for free, it may be not an optimal variant for a portable jpeg impl. Just my 0.02 . > > ..Thomas > >> Adrian >> >> -- >> .''`. John Paul Adrian Glaubitz >> : :' : Debian Developer - glaubitz at debian.org >> `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de >> `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- -Alex From erik.joelsson at oracle.com Mon May 21 15:32:21 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 May 2018 08:32:21 -0700 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <0AABBD63-D166-47F8-AE3E-CFCF60B0D4A7@oracle.com> <5a088cc5-47ce-9ea5-69a8-ffde4465c995@redhat.com> Message-ID: <88ca9168-d55d-b143-3a30-75424c26f843@oracle.com> Looks good. /Erik On 2018-05-19 04:57, Erik ?sterlund wrote: > Hi Aleksey, > > Looks good. > > Thanks, > /Erik > > On 2018-05-19 13:52, Aleksey Shipilev wrote: >> Okay, this also works for Zero, Minimal and server: >> >> diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk >> --- a/make/hotspot/lib/JvmFeatures.gmk??? Fri May 18 18:31:28 2018 -0700 >> +++ b/make/hotspot/lib/JvmFeatures.gmk??? Sat May 19 13:36:32 2018 +0200 >> @@ -41,7 +41,7 @@ >> ? else >> ??? JVM_EXCLUDES += opto libadt >> ??? JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp >> -? JVM_EXCLUDE_PATTERNS += c2_ runtime_ >> +? JVM_EXCLUDE_PATTERNS += c2_ runtime_ /c2/ >> ? endif >> >> ? ifeq ($(call check-jvm-feature, zero), true) >> >> >> -Aleksey >> >> On 05/19/2018 12:50 PM, Erik Osterlund wrote: >>> Hi Aleksey, >>> >>> Thanks for fixing. >>> >>> I wonder if /c2/ could be added to the exclude pattern instead >>> though, instead of enumerating all GCs. >>> >>> Thanks, >>> /Erik >>> >>>> On 19 May 2018, at 11:20, Aleksey Shipilev wrote: >>>> >>>> Bug: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8203454 >>>> >>>> Other GCs that would eventually bring their own BarrierSetC2 files >>>> (e.g. Epsilon, Shenandoah, ZGC) >>>> would require excluding their "gc//c2" as well. >>>> >>>> Fix: >>>> >>>> diff -r 5ec7380f671d make/hotspot/lib/JvmFeatures.gmk >>>> --- a/make/hotspot/lib/JvmFeatures.gmk??? Fri May 18 18:31:28 2018 >>>> -0700 >>>> +++ b/make/hotspot/lib/JvmFeatures.gmk??? Sat May 19 11:01:16 2018 >>>> +0200 >>>> @@ -41,7 +41,7 @@ >>>> else >>>> ?? JVM_EXCLUDES += opto libadt >>>> ?? JVM_EXCLUDE_FILES += bcEscapeAnalyzer.cpp ciTypeFlow.cpp >>>> -? JVM_EXCLUDE_PATTERNS += c2_ runtime_ >>>> +? JVM_EXCLUDE_PATTERNS += c2_ runtime_ gc/shared/c2 gc/g1/c2 >>>> endif >>>> >>>> ifeq ($(call check-jvm-feature, zero), true) >>>> >>>> Testing: {x86-minimal, x86_64-zero, x86_64-server} builds >>>> >>>> Thanks, >>>> -Aleksey >>>> >> > From mikhailo.seledtsov at oracle.com Mon May 21 18:34:59 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 21 May 2018 11:34:59 -0700 Subject: RFR(L): 8199255: [TESTBUG] Open source VM testbase default methods tests Message-ID: <5B031153.6020408@oracle.com> Please review this change that will open source VM default method tests. These tests have been used internally for a while, and are now being open sourced. Since this is not an creation of new tests, we would like to keep the changes during this review to a minimum required for open sourcing these tests, such as major issues and integration blockers. If you have other feedback regarding improvements to these tests, please file RFE(s) that will be addressed later in order of priority. Here is what was done for this change: 1. Moved the tests to OpenJDK repository to the specified directory location and structure. 3. Updated Copyright statements accordingly. 4. Updated "@library" statements accordingly. 5. Updated TEST.groups and a HotSpot test make file JBS: https://bugs.openjdk.java.net/browse/JDK-8199255 Webrev: http://cr.openjdk.java.net/~mseledtsov/8199255.01/ Testing: 1. Ran the following tests on open-only repository and build, using "make run-test" (Linux-x64) vmTestbase_vm_defmeth All PASS 2. Automated multip-platform test system (usual 4 platforms): - vmTestbase_vm_defmeth - hs-tier{1,2} In progress Thank you, Misha From erik.joelsson at oracle.com Mon May 21 18:43:30 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 May 2018 11:43:30 -0700 Subject: RFR(L): 8199255: [TESTBUG] Open source VM testbase default methods tests In-Reply-To: <5B031153.6020408@oracle.com> References: <5B031153.6020408@oracle.com> Message-ID: Build changes look ok. /Erik On 2018-05-21 11:34, Mikhailo Seledtsov wrote: > Please review this change that will open source VM default method tests. > These tests have been used internally for a while, and are now being > open sourced. Since this is not an creation of new tests, we would > like to keep the changes during this review to a minimum required for > open sourcing these tests, such as major issues and integration > blockers. If you have other feedback regarding improvements to these > tests, please file RFE(s) that will be addressed later in order of > priority. > > Here is what was done for this change: > ? 1. Moved the tests to OpenJDK repository to the specified directory > location and structure. > ? 3. Updated Copyright statements accordingly. > ? 4. Updated "@library" statements accordingly. > ? 5. Updated TEST.groups and a HotSpot test make file > > ? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8199255 > ? Webrev: http://cr.openjdk.java.net/~mseledtsov/8199255.01/ > > ? Testing: > ????? 1. Ran the following tests on open-only repository and build, > using "make run-test" (Linux-x64) > ???????? vmTestbase_vm_defmeth > ???????? All PASS > > ????? 2. Automated multip-platform test system (usual 4 platforms): > ???????? - vmTestbase_vm_defmeth > ???????? - hs-tier{1,2} > ???????? In progress > > > Thank you, > Misha > From erik.joelsson at oracle.com Mon May 21 20:21:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 21 May 2018 13:21:57 -0700 Subject: RFR: JDK-8203497: Bump Jib format version to 1.2 Message-ID: <21778229-cc2b-04cb-7b16-386d42077bf7@oracle.com> The jib format version is defined in jib-profiles.js. It is used by Jib to identify correct parsing of the file and adjust behavior of Jib if necessary. This version needs to be bumped to 1.2. Bug: https://bugs.openjdk.java.net/browse/JDK-8203497 Webrev: http://cr.openjdk.java.net/~erikj/8203497/webrev.01/ /Erik From tim.bell at oracle.com Mon May 21 23:54:53 2018 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 21 May 2018 16:54:53 -0700 Subject: RFR: JDK-8203497: Bump Jib format version to 1.2 In-Reply-To: <21778229-cc2b-04cb-7b16-386d42077bf7@oracle.com> References: <21778229-cc2b-04cb-7b16-386d42077bf7@oracle.com> Message-ID: <5B035C4D.1070407@oracle.com> Erik: > The jib format version is defined in jib-profiles.js. It is used by Jib > to identify correct parsing of the file and adjust behavior of Jib if > necessary. This version needs to be bumped to 1.2. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203497 > > Webrev: http://cr.openjdk.java.net/~erikj/8203497/webrev.01/ Looks good. Tim From Sergey.Bylokhov at oracle.com Tue May 22 02:39:06 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 21 May 2018 19:39:06 -0700 Subject: [11] Review Request: 8203308 Remove the appletviewer classes Message-ID: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> Hello. Please review the fix for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 Description: - Implementation of the AppletViewer was removed - Tests in sun/applet were removed and TEST.ROOT/TEST.groups were updated - Small update in make file was done We still have a few classes in sun.applet package which are related to the client security, sound. I think that we can drop it as well at some point. -- Best regards, Sergey. From weijun.wang at oracle.com Tue May 22 15:25:13 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 May 2018 23:25:13 +0800 Subject: RFR 8201815: Use Mozilla Public Suffix List Message-ID: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. There is no plan to update the data in a different channel other than a JDK release. Thanks Max From erik.joelsson at oracle.com Tue May 22 15:32:11 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 May 2018 08:32:11 -0700 Subject: [11] Review Request: 8203308 Remove the appletviewer classes In-Reply-To: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> References: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> Message-ID: <7f1b9c47-58be-6949-b9fd-b798381c1c4c@oracle.com> Build changes look good. /Erik On 2018-05-21 19:39, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk11. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 > Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 > > Description: > ?- Implementation of the AppletViewer was removed > ?- Tests in sun/applet were removed and TEST.ROOT/TEST.groups were > updated > ?- Small update in make file was done > > We still have a few classes in sun.applet package which are related to > the client security, sound. I think that we can drop it as well at > some point. > From erik.joelsson at oracle.com Tue May 22 15:44:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 May 2018 08:44:36 -0700 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> Message-ID: <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> Build changes look ok. /Erik On 2018-05-22 08:25, Weijun Wang wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ > > With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. > > There is no plan to update the data in a different channel other than a JDK release. > > Thanks > Max > From magnus.ihse.bursie at oracle.com Tue May 22 20:21:55 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 22 May 2018 22:21:55 +0200 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> Message-ID: <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> .. but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. /Magnus > 22 maj 2018 kl. 17:44 skrev Erik Joelsson : > > Build changes look ok. > > /Erik > > >> On 2018-05-22 08:25, Weijun Wang wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >> >> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >> >> There is no plan to update the data in a different channel other than a JDK release. >> >> Thanks >> Max >> > From igor.ignatyev at oracle.com Tue May 22 23:35:09 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 22 May 2018 16:35:09 -0700 Subject: RFR(XL) : 8199383 : [TESTBUG] Open source VM testbase JVMTI tests Message-ID: http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html > 308253 lines changed: 308253 ins; 0 del; 0 mod; Hi all, could you please review this patch which open sources JVMTI tests from VM testbase? As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. webrev: http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8199383 testing: :vmTestbase_nsk_jvmti test group Thanks, -- Igor From weijun.wang at oracle.com Wed May 23 00:01:53 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 23 May 2018 08:01:53 +0800 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> Message-ID: <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> > On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: > > ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) In below cases, CHMOD is called after MV/CP. gendata/Gendata-java.base.gmk 59- $(MV) $@.tmp $@ 60: $(CHMOD) 444 $@ 61- common/JavaCompilation.gmk 80- $(CP) $$< $$@ 81: $(CHMOD) -f ug+w $$@ Thanks Max > > /Magnus > >> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >> >> Build changes look ok. >> >> /Erik >> >> >>> On 2018-05-22 08:25, Weijun Wang wrote: >>> Please take a review at >>> >>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>> >>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>> >>> There is no plan to update the data in a different channel other than a JDK release. >>> >>> Thanks >>> Max >>> >> > From erik.joelsson at oracle.com Wed May 23 00:05:17 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 22 May 2018 17:05:17 -0700 Subject: RFR(XL) : 8199383 : [TESTBUG] Open source VM testbase JVMTI tests In-Reply-To: References: Message-ID: <8bfed6c4-d0e0-4324-5982-d4ef040d12c1@oracle.com> Looks like the line "# } nsk/jvmti" is a left over. Otherwise this looks ok, even if it's an enormous amount of duplication. Hopefully we can figure out a better way to express common parameters for tests soon. /Erik On 2018-05-22 16:35, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html >> 308253 lines changed: 308253 ins; 0 del; 0 mod; > Hi all, > > could you please review this patch which open sources JVMTI tests from VM testbase? > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > webrev: http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8199383 > testing: :vmTestbase_nsk_jvmti test group > > Thanks, > -- Igor From aoqi at loongson.cn Wed May 23 10:18:11 2018 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 23 May 2018 18:18:11 +0800 Subject: Configure broken on MIPS when uname returns mipsel or mips64el Message-ID: Hi all, I tried to configure jdk/jdk on MIPS, but I failed. The output of configure: ... checking for pandoc... no checking build system type... /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable to guess system type This script, last modified 2012-02-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD If the version you run (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is already up to date, please send the following data and any information you think might be pertinent to in order to provide the needed information to handle your system. config.guess timestamp = 2012-02-10 uname -m = mips64el uname -r = 3.10.0-693.5.2.ns7.032.mips64el uname -s = Linux uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 /usr/bin/uname -p = mips64el /bin/uname -X = hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = mips64el /usr/bin/oslevel = /usr/convex/getsysinfo = UNAME_MACHINE = mips64el UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el UNAME_SYSTEM = Linux UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 configure: error: cannot guess build type; you must specify one configure exiting with result code 1 ... I think the reason is that uname returns mips64el. autoconf-config.guess can handle mips and mips64, but cannot handle mipsel and mips64el. I made a patch to pass the configure: $ hg diff diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 10:08:04 2018 -0700 +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 18:06:52 2018 +0800 @@ -977,6 +977,9 @@ eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } ;; + mipsel:Linux:*:* | mips64el:Linux:*:*) + echo ${UNAME_MACHINE}-unknown-linux-gnu + exit ;; or32:Linux:*:*) echo ${UNAME_MACHINE}-unknown-linux-gnu exit ;; I think ppc has the same problem, but it is fixed in make/autoconf/build-aux/config.guess. Thanks, Ao Qi From magnus.ihse.bursie at oracle.com Wed May 23 10:54:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 May 2018 12:54:39 +0200 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> Message-ID: <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> mv should not modify attributes. cp will, but mv should not. Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. I believe the other cases that you quote are also incorrect. But I'd like to hear Erik's input on this as well. /Magnus > 23 maj 2018 kl. 02:01 skrev Weijun Wang : > > > >> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: >> >> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. > > I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) > > In below cases, CHMOD is called after MV/CP. > > gendata/Gendata-java.base.gmk > 59- $(MV) $@.tmp $@ > 60: $(CHMOD) 444 $@ > 61- > > common/JavaCompilation.gmk > 80- $(CP) $$< $$@ > 81: $(CHMOD) -f ug+w $$@ > > Thanks > Max > >> >> /Magnus >> >>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >>> >>> Build changes look ok. >>> >>> /Erik >>> >>> >>>> On 2018-05-22 08:25, Weijun Wang wrote: >>>> Please take a review at >>>> >>>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>>> >>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>>> >>>> There is no plan to update the data in a different channel other than a JDK release. >>>> >>>> Thanks >>>> Max > From erik.joelsson at oracle.com Wed May 23 16:19:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 May 2018 09:19:31 -0700 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: References: Message-ID: Hello Ao Qi, Due to licensing reasons, we are unable to directly update the autoconf-config.guess file. Instead we have the wrapper, config.guess in which we make adjustments to the result returned by autoconf-config.guess. Your fix needs to go in the wrapper file. /Erik On 2018-05-23 03:18, Ao Qi wrote: > Hi all, > I tried to configure jdk/jdk on MIPS, but I failed. The output of configure: > ... > checking for pandoc... no > checking build system type... > /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable > to guess system type > > This script, last modified 2012-02-10, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > > If the version you run > (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is > already up to date, please > send the following data and any information you think might be > pertinent to in order to provide the needed > information to handle your system. > > config.guess timestamp = 2012-02-10 > > uname -m = mips64el > uname -r = 3.10.0-693.5.2.ns7.032.mips64el > uname -s = Linux > uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 > > /usr/bin/uname -p = mips64el > /bin/uname -X = > > hostinfo = > /bin/universe = > /usr/bin/arch -k = > /bin/arch = mips64el > /usr/bin/oslevel = > /usr/convex/getsysinfo = > > UNAME_MACHINE = mips64el > UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el > UNAME_SYSTEM = Linux > UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 > configure: error: cannot guess build type; you must specify one > configure exiting with result code 1 > ... > > I think the reason is that uname returns mips64el. > autoconf-config.guess can handle mips and mips64, but cannot handle > mipsel and mips64el. > I made a patch to pass the configure: > > $ hg diff > diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess > --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 > 10:08:04 2018 -0700 > +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 > 18:06:52 2018 +0800 > @@ -977,6 +977,9 @@ > eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` > test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } > ;; > + mipsel:Linux:*:* | mips64el:Linux:*:*) > + echo ${UNAME_MACHINE}-unknown-linux-gnu > + exit ;; > or32:Linux:*:*) > echo ${UNAME_MACHINE}-unknown-linux-gnu > exit ;; > > > I think ppc has the same problem, but it is fixed in > make/autoconf/build-aux/config.guess. > > Thanks, > Ao Qi From erik.joelsson at oracle.com Wed May 23 16:30:11 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 May 2018 09:30:11 -0700 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> Message-ID: <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com> On 2018-05-23 03:54, Magnus Ihse Bursie wrote: > mv should not modify attributes. cp will, but mv should not. > > Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. > > I believe the other cases that you quote are also incorrect. > > But I'd like to hear Erik's input on this as well. We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct. /Erik > /Magnus > >> 23 maj 2018 kl. 02:01 skrev Weijun Wang : >> >> >> >>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: >>> >>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. >> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) >> >> In below cases, CHMOD is called after MV/CP. >> >> gendata/Gendata-java.base.gmk >> 59- $(MV) $@.tmp $@ >> 60: $(CHMOD) 444 $@ >> 61- >> >> common/JavaCompilation.gmk >> 80- $(CP) $$< $$@ >> 81: $(CHMOD) -f ug+w $$@ >> >> Thanks >> Max >> >>> /Magnus >>> >>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >>>> >>>> Build changes look ok. >>>> >>>> /Erik >>>> >>>> >>>>> On 2018-05-22 08:25, Weijun Wang wrote: >>>>> Please take a review at >>>>> >>>>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>>>> >>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>>>> >>>>> There is no plan to update the data in a different channel other than a JDK release. >>>>> >>>>> Thanks >>>>> Max From philip.race at oracle.com Wed May 23 17:53:08 2018 From: philip.race at oracle.com (Philip Race) Date: Wed, 23 May 2018 10:53:08 -0700 Subject: [11] Review Request: 8203308 Remove the appletviewer classes In-Reply-To: <7f1b9c47-58be-6949-b9fd-b798381c1c4c@oracle.com> References: <071dcdda-7d21-74bf-a1fa-dc05c6747d3a@oracle.com> <7f1b9c47-58be-6949-b9fd-b798381c1c4c@oracle.com> Message-ID: <5B05AA84.7030000@oracle.com> I verified that applet based tests (manual + automated) still run in jtreg. So +1 -phil. On 5/22/18, 8:32 AM, Erik Joelsson wrote: > Build changes look good. > > /Erik > > > On 2018-05-21 19:39, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk11. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203308 >> Webrev: http://cr.openjdk.java.net/~serb/8203308/webrev.00 >> >> Description: >> - Implementation of the AppletViewer was removed >> - Tests in sun/applet were removed and TEST.ROOT/TEST.groups were >> updated >> - Small update in make file was done >> >> We still have a few classes in sun.applet package which are related >> to the client security, sound. I think that we can drop it as well at >> some point. >> > From igor.ignatyev at oracle.com Wed May 23 19:44:32 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 May 2018 12:44:32 -0700 Subject: RFR(M) : 8199380 : [TESTBUG] Open source VM testbase AOD tests Message-ID: <5E87B35F-FC4E-4814-A4A6-CE1E24D3C479@oracle.com> http://cr.openjdk.java.net/~iignatyev/8199380/webrev.00/ > 2370 lines changed: 2370 ins; 0 del; 0 mod; Hi all, could you please review this patch which open sources AOD tests from VM testbase? these tests test hotspot's attach-on-demand. As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. JBS: https://bugs.openjdk.java.net/browse/JDK-8199380 webrev: http://cr.openjdk.java.net/~iignatyev//8199380/webrev.00/index.html testing: :vmTestbase_vm_aod test group Thanks, -- Igor From erik.joelsson at oracle.com Wed May 23 19:53:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 23 May 2018 12:53:31 -0700 Subject: RFR(M) : 8199380 : [TESTBUG] Open source VM testbase AOD tests In-Reply-To: <5E87B35F-FC4E-4814-A4A6-CE1E24D3C479@oracle.com> References: <5E87B35F-FC4E-4814-A4A6-CE1E24D3C479@oracle.com> Message-ID: Build changes look good. /Erik On 2018-05-23 12:44, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8199380/webrev.00/ >> 2370 lines changed: 2370 ins; 0 del; 0 mod; > Hi all, > > could you please review this patch which open sources AOD tests from VM testbase? these tests test hotspot's attach-on-demand. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199380 > webrev: http://cr.openjdk.java.net/~iignatyev//8199380/webrev.00/index.html > testing: :vmTestbase_vm_aod test group > > Thanks, > -- Igor From calvin.cheung at oracle.com Wed May 23 22:15:56 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 23 May 2018 15:15:56 -0700 Subject: RFR(L): 8199255: [TESTBUG] Open source VM testbase default methods tests In-Reply-To: <5B031153.6020408@oracle.com> References: <5B031153.6020408@oracle.com> Message-ID: <5B05E81C.60406@oracle.com> Hi Misha, I've compared the file.list from your closed webrev with the one from this open webrev and didn't see any missing files. Also spot checked a few copyright headers and they look good. Regarding TEST.groups, why was the following removed? 1160 vmTestbase_nsk_stress = \ 1161 vmTestbase/nsk/stress Could you also remove the extra blank line added at line 1273? thanks, Calvin On 5/21/18, 11:34 AM, Mikhailo Seledtsov wrote: > Please review this change that will open source VM default method tests. > These tests have been used internally for a while, and are now being > open sourced. Since this is not an creation of new tests, we would > like to keep the changes during this review to a minimum required for > open sourcing these tests, such as major issues and integration > blockers. If you have other feedback regarding improvements to these > tests, please file RFE(s) that will be addressed later in order of > priority. > > Here is what was done for this change: > 1. Moved the tests to OpenJDK repository to the specified directory > location and structure. > 3. Updated Copyright statements accordingly. > 4. Updated "@library" statements accordingly. > 5. Updated TEST.groups and a HotSpot test make file > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199255 > Webrev: http://cr.openjdk.java.net/~mseledtsov/8199255.01/ > > Testing: > 1. Ran the following tests on open-only repository and build, > using "make run-test" (Linux-x64) > vmTestbase_vm_defmeth > All PASS > > 2. Automated multip-platform test system (usual 4 platforms): > - vmTestbase_vm_defmeth > - hs-tier{1,2} > In progress > > > Thank you, > Misha > From mikhailo.seledtsov at oracle.com Wed May 23 23:13:16 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Wed, 23 May 2018 16:13:16 -0700 Subject: RFR(L): 8199255: [TESTBUG] Open source VM testbase default methods tests In-Reply-To: <5B05E81C.60406@oracle.com> References: <5B031153.6020408@oracle.com> <5B05E81C.60406@oracle.com> Message-ID: Hi Calvin, ? Thank you for review. I will fix the issue with vmTestbase_nsk_stress (merge issue) and will remove the blank line at line 1273 prior to check in. Misha On 05/23/2018 03:15 PM, Calvin Cheung wrote: > Hi Misha, > > I've compared the file.list from your closed webrev with the one from > this open webrev and didn't see any missing files. > Also spot checked a few copyright headers and they look good. > > Regarding TEST.groups, why was the following removed? > 1160 vmTestbase_nsk_stress = \ > 1161?? vmTestbase/nsk/stress > > Could you also remove the extra blank line added at line 1273? > > thanks, > Calvin > > On 5/21/18, 11:34 AM, Mikhailo Seledtsov wrote: >> Please review this change that will open source VM default method tests. >> These tests have been used internally for a while, and are now being >> open sourced. Since this is not an creation of new tests, we would >> like to keep the changes during this review to a minimum required for >> open sourcing these tests, such as major issues and integration >> blockers. If you have other feedback regarding improvements to these >> tests, please file RFE(s) that will be addressed later in order of >> priority. >> >> Here is what was done for this change: >> ? 1. Moved the tests to OpenJDK repository to the specified directory >> location and structure. >> ? 3. Updated Copyright statements accordingly. >> ? 4. Updated "@library" statements accordingly. >> ? 5. Updated TEST.groups and a HotSpot test make file >> >> ? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8199255 >> ? Webrev: http://cr.openjdk.java.net/~mseledtsov/8199255.01/ >> >> ? Testing: >> ????? 1. Ran the following tests on open-only repository and build, >> using "make run-test" (Linux-x64) >> ???????? vmTestbase_vm_defmeth >> ???????? All PASS >> >> ????? 2. Automated multip-platform test system (usual 4 platforms): >> ???????? - vmTestbase_vm_defmeth >> ???????? - hs-tier{1,2} >> ???????? In progress >> >> >> Thank you, >> Misha >> From igor.ignatyev at oracle.com Wed May 23 23:13:17 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 May 2018 16:13:17 -0700 Subject: RFR(L): 8199255: [TESTBUG] Open source VM testbase default methods tests In-Reply-To: References: <5B031153.6020408@oracle.com> <5B05E81C.60406@oracle.com> Message-ID: Hi Misha, looks good to me. -- Igor > On May 23, 2018, at 4:13 PM, mikhailo wrote: > > Hi Calvin, > > Thank you for review. I will fix the issue with vmTestbase_nsk_stress (merge issue) and will remove the blank line at line 1273 prior to check in. > > > Misha > > > On 05/23/2018 03:15 PM, Calvin Cheung wrote: >> Hi Misha, >> >> I've compared the file.list from your closed webrev with the one from this open webrev and didn't see any missing files. >> Also spot checked a few copyright headers and they look good. >> >> Regarding TEST.groups, why was the following removed? >> 1160 vmTestbase_nsk_stress = \ >> 1161 vmTestbase/nsk/stress >> >> Could you also remove the extra blank line added at line 1273? >> >> thanks, >> Calvin >> >> On 5/21/18, 11:34 AM, Mikhailo Seledtsov wrote: >>> Please review this change that will open source VM default method tests. >>> These tests have been used internally for a while, and are now being open sourced. Since this is not an creation of new tests, we would like to keep the changes during this review to a minimum required for open sourcing these tests, such as major issues and integration blockers. If you have other feedback regarding improvements to these tests, please file RFE(s) that will be addressed later in order of priority. >>> >>> Here is what was done for this change: >>> 1. Moved the tests to OpenJDK repository to the specified directory location and structure. >>> 3. Updated Copyright statements accordingly. >>> 4. Updated "@library" statements accordingly. >>> 5. Updated TEST.groups and a HotSpot test make file >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199255 >>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8199255.01/ >>> >>> Testing: >>> 1. Ran the following tests on open-only repository and build, using "make run-test" (Linux-x64) >>> vmTestbase_vm_defmeth >>> All PASS >>> >>> 2. Automated multip-platform test system (usual 4 platforms): >>> - vmTestbase_vm_defmeth >>> - hs-tier{1,2} >>> In progress >>> >>> >>> Thank you, >>> Misha >>> > From mikhailo.seledtsov at oracle.com Thu May 24 00:05:17 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Wed, 23 May 2018 17:05:17 -0700 Subject: RFR(L): 8199255: [TESTBUG] Open source VM testbase default methods tests In-Reply-To: References: <5B031153.6020408@oracle.com> <5B05E81C.60406@oracle.com> Message-ID: <430598e1-fb60-eba3-6324-f466a975bcd8@oracle.com> Thank you, Misha On 05/23/2018 04:13 PM, Igor Ignatyev wrote: > Hi Misha, > > looks good to me. > > -- Igor > >> On May 23, 2018, at 4:13 PM, mikhailo wrote: >> >> Hi Calvin, >> >> Thank you for review. I will fix the issue with vmTestbase_nsk_stress (merge issue) and will remove the blank line at line 1273 prior to check in. >> >> >> Misha >> >> >> On 05/23/2018 03:15 PM, Calvin Cheung wrote: >>> Hi Misha, >>> >>> I've compared the file.list from your closed webrev with the one from this open webrev and didn't see any missing files. >>> Also spot checked a few copyright headers and they look good. >>> >>> Regarding TEST.groups, why was the following removed? >>> 1160 vmTestbase_nsk_stress = \ >>> 1161 vmTestbase/nsk/stress >>> >>> Could you also remove the extra blank line added at line 1273? >>> >>> thanks, >>> Calvin >>> >>> On 5/21/18, 11:34 AM, Mikhailo Seledtsov wrote: >>>> Please review this change that will open source VM default method tests. >>>> These tests have been used internally for a while, and are now being open sourced. Since this is not an creation of new tests, we would like to keep the changes during this review to a minimum required for open sourcing these tests, such as major issues and integration blockers. If you have other feedback regarding improvements to these tests, please file RFE(s) that will be addressed later in order of priority. >>>> >>>> Here is what was done for this change: >>>> 1. Moved the tests to OpenJDK repository to the specified directory location and structure. >>>> 3. Updated Copyright statements accordingly. >>>> 4. Updated "@library" statements accordingly. >>>> 5. Updated TEST.groups and a HotSpot test make file >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8199255 >>>> Webrev: http://cr.openjdk.java.net/~mseledtsov/8199255.01/ >>>> >>>> Testing: >>>> 1. Ran the following tests on open-only repository and build, using "make run-test" (Linux-x64) >>>> vmTestbase_vm_defmeth >>>> All PASS >>>> >>>> 2. Automated multip-platform test system (usual 4 platforms): >>>> - vmTestbase_vm_defmeth >>>> - hs-tier{1,2} >>>> In progress >>>> >>>> >>>> Thank you, >>>> Misha >>>> From aoqi at loongson.cn Thu May 24 01:08:20 2018 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 24 May 2018 09:08:20 +0800 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: References: Message-ID: Hi Erik, Thanks for your comments. I made a new patch: $ hg diff diff -r 31361382634b make/autoconf/build-aux/config.guess --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700 +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800 @@ -86,6 +86,17 @@ fi fi +# Test and fix little endian MIPS. +if [ "x$OUT" = x ]; then + if [ `uname -s` = Linux ]; then + if [ `uname -m` = mipsel ]; then + OUT=mipsel-unknown-linux-gnu + elif [ `uname -m` = mips64el ]; then + OUT=mips64el-unknown-linux-gnu + fi + fi +fi + # Test and fix cpu on Macosx when C preprocessor is not on the path echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null if test $? = 0; then Cheers, Ao Qi 2018-05-24 0:19 GMT+08:00 Erik Joelsson : > Hello Ao Qi, > > Due to licensing reasons, we are unable to directly update the > autoconf-config.guess file. Instead we have the wrapper, config.guess in > which we make adjustments to the result returned by autoconf-config.guess. > Your fix needs to go in the wrapper file. > > /Erik > > > > On 2018-05-23 03:18, Ao Qi wrote: >> >> Hi all, >> I tried to configure jdk/jdk on MIPS, but I failed. The output of >> configure: >> ... >> checking for pandoc... no >> checking build system type... >> /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable >> to guess system type >> >> This script, last modified 2012-02-10, has failed to recognize >> the operating system you are using. It is advised that you >> download the most up to date version of the config scripts from >> >> >> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >> and >> >> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD >> >> If the version you run >> (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is >> already up to date, please >> send the following data and any information you think might be >> pertinent to in order to provide the needed >> information to handle your system. >> >> config.guess timestamp = 2012-02-10 >> >> uname -m = mips64el >> uname -r = 3.10.0-693.5.2.ns7.032.mips64el >> uname -s = Linux >> uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >> >> /usr/bin/uname -p = mips64el >> /bin/uname -X = >> >> hostinfo = >> /bin/universe = >> /usr/bin/arch -k = >> /bin/arch = mips64el >> /usr/bin/oslevel = >> /usr/convex/getsysinfo = >> >> UNAME_MACHINE = mips64el >> UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el >> UNAME_SYSTEM = Linux >> UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >> configure: error: cannot guess build type; you must specify one >> configure exiting with result code 1 >> ... >> >> I think the reason is that uname returns mips64el. >> autoconf-config.guess can handle mips and mips64, but cannot handle >> mipsel and mips64el. >> I made a patch to pass the configure: >> >> $ hg diff >> diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess >> --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 >> 10:08:04 2018 -0700 >> +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 >> 18:06:52 2018 +0800 >> @@ -977,6 +977,9 @@ >> eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` >> test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } >> ;; >> + mipsel:Linux:*:* | mips64el:Linux:*:*) >> + echo ${UNAME_MACHINE}-unknown-linux-gnu >> + exit ;; >> or32:Linux:*:*) >> echo ${UNAME_MACHINE}-unknown-linux-gnu >> exit ;; >> >> >> I think ppc has the same problem, but it is fixed in >> make/autoconf/build-aux/config.guess. >> >> Thanks, >> Ao Qi > > From weijun.wang at oracle.com Thu May 24 04:52:43 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 24 May 2018 12:52:43 +0800 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com> References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com> Message-ID: Good. It's now simply $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS) $(call LogInfo, Generating public suffix list) $(call MakeDir, $(@D)) $(RM) $@ $(TOOL_PUBLICSUFFIXLIST) $< $@ $(CHMOD) 444 $@ Thanks Max > On May 24, 2018, at 12:30 AM, Erik Joelsson wrote: > > On 2018-05-23 03:54, Magnus Ihse Bursie wrote: >> mv should not modify attributes. cp will, but mv should not. >> >> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. >> >> I believe the other cases that you quote are also incorrect. >> >> But I'd like to hear Erik's input on this as well. > We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct. > > /Erik >> /Magnus >> >>> 23 maj 2018 kl. 02:01 skrev Weijun Wang : >>> >>> >>> >>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: >>>> >>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. >>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) >>> >>> In below cases, CHMOD is called after MV/CP. >>> >>> gendata/Gendata-java.base.gmk >>> 59- $(MV) $@.tmp $@ >>> 60: $(CHMOD) 444 $@ >>> 61- >>> >>> common/JavaCompilation.gmk >>> 80- $(CP) $$< $$@ >>> 81: $(CHMOD) -f ug+w $$@ >>> >>> Thanks >>> Max >>> >>>> /Magnus >>>> >>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >>>>> >>>>> Build changes look ok. >>>>> >>>>> /Erik >>>>> >>>>> >>>>>> On 2018-05-22 08:25, Weijun Wang wrote: >>>>>> Please take a review at >>>>>> >>>>>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>>>>> >>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>>>>> >>>>>> There is no plan to update the data in a different channel other than a JDK release. >>>>>> >>>>>> Thanks >>>>>> Max > From magnus.ihse.bursie at oracle.com Thu May 24 12:09:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 May 2018 14:09:08 +0200 Subject: RFR (round 3), JEP-318: Epsilon GC In-Reply-To: <6c1ae009-769c-fab4-f691-96a0d8af38ce@redhat.com> References: <6c1ae009-769c-fab4-f691-96a0d8af38ce@redhat.com> Message-ID: <2e5ab487-b37e-3028-3865-e6bf4b470293@oracle.com> Hi Aleksey! Please remember to include build-dev whenever you make changes to the build system. Build part of your webrev looks good. /Magnus On 2018-05-21 15:07, Aleksey Shipilev wrote: > Hi, > > This is third (and hopefully final) round of code review for Epsilon GC changes. > > JEP, targeted to 11: > http://openjdk.java.net/jeps/318 > (you can find links to binary builds and sandbox locations there) > > Webrev: > http://cr.openjdk.java.net/~shade/epsilon/webrev.07/ > > Notes: > *) C2 barrier modularization had landed, and now Epsilon has no platform-specific impact (this > alone makes me impressed and happy); > *) Elastic TLAB machinery is now able to decay TLAB sizes as well, cutting down memory footprint > on bursty allocations, more tests for it added, gating by VM options implemented; > *) Serviceability support implemented, verified with ad-hoc hsdb session ("universe" and > "scanoops" work as expected), and serviceability/sa tests; > *) Tests are properly keyed with vm.gc.Epsilon, so they are ignored if Epsilon is not built > > Builds: > server X {x86_64, x86_32, aarch64, arm32, ppc64le, s390x} > zero X {x86_64} > minimal X {x86} > > Testing: gc/epsilon on x86_64 > > Thanks, > -Aleksey > From magnus.ihse.bursie at oracle.com Thu May 24 12:32:45 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 May 2018 14:32:45 +0200 Subject: RFR: JDK-8203366 tag added wrongly in Docs.gmk Message-ID: From the bug report: This line in Docs.gmk is incorrect, and should be removed. -tag version \ It incorrectly enables support for the @version tag, which should only be enabled by the (poorly-named) -version option.? (@version and -version are a similar pair to @author and -author). A small number of java SE API files contain a very-old @version tag, and this started showing up in JavaSE docs in JDK 8. You can find these files by grepping recursively for @version.? The change that added this line is probably a side-effect of adding support for the @apiNote, @implNote, @implSpec tags. Note that removing this line will change the Java SE API docs, reverting the handling of @version back to its original treatment of being ignored up through and including JDK 7. Bug: https://bugs.openjdk.java.net/browse/JDK-8203366 Patch inline: diff --git a/make/Docs.gmk b/make/Docs.gmk --- a/make/Docs.gmk +++ b/make/Docs.gmk @@ -85,7 +85,6 @@ ???? -tag throws \ ???? -taglet build.tools.taglet.ModuleGraph \ ???? -tag since \ -??? -tag version \ ???? -tag serialData \ ???? -tag factory \ ???? -tag see \ /Magnus From glaubitz at physik.fu-berlin.de Thu May 24 12:38:59 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 May 2018 14:38:59 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> Message-ID: Hi! On 05/19/2018 11:20 AM, Aleksey Shipilev wrote: > Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) > would require excluding their "gc//c2" as well. I'm seeing this bug on linux-sparc as well. Does SPARC have support for C2 on Solaris so that we need to add it for linux-sparc as well or is this limited to x86_64 only? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From shade at redhat.com Thu May 24 12:42:08 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 May 2018 14:42:08 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> Message-ID: On 05/24/2018 02:38 PM, John Paul Adrian Glaubitz wrote: > Hi! > > On 05/19/2018 11:20 AM, Aleksey Shipilev wrote: >> Other GCs that would eventually bring their own BarrierSetC2 files (e.g. Epsilon, Shenandoah, ZGC) >> would require excluding their "gc//c2" as well. > > I'm seeing this bug on linux-sparc as well. > > Does SPARC have support for C2 on Solaris so that we need to > add it for linux-sparc as well or is this limited to x86_64 only? You must be seeing something new, because the fix for Minimal and Zero was pushed to jdk/jdk already. Submit a bug report? -Aleksey From magnus.ihse.bursie at oracle.com Thu May 24 12:47:53 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 May 2018 14:47:53 +0200 Subject: RFR 8201815: Use Mozilla Public Suffix List In-Reply-To: References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com> <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com> <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com> <61048D27-07DB-4283-82E6-B7909296171F@oracle.com> <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com> <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com> Message-ID: On 2018-05-24 06:52, Weijun Wang wrote: > Good. It's now simply > > $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS) > $(call LogInfo, Generating public suffix list) > $(call MakeDir, $(@D)) > $(RM) $@ > $(TOOL_PUBLICSUFFIXLIST) $< $@ > $(CHMOD) 444 $@ > > Thanks > Max Great! Looks good to me now. I've forgotten that we started using .DELETE_ON_ERROR. Thanks for reminding me Erik. :) /Magnus > >> On May 24, 2018, at 12:30 AM, Erik Joelsson wrote: >> >> On 2018-05-23 03:54, Magnus Ihse Bursie wrote: >>> mv should not modify attributes. cp will, but mv should not. >>> >>> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. >>> >>> I believe the other cases that you quote are also incorrect. >>> >>> But I'd like to hear Erik's input on this as well. >> We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct. >> >> /Erik >>> /Magnus >>> >>>> 23 maj 2018 kl. 02:01 skrev Weijun Wang : >>>> >>>> >>>> >>>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: >>>>> >>>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. >>>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) >>>> >>>> In below cases, CHMOD is called after MV/CP. >>>> >>>> gendata/Gendata-java.base.gmk >>>> 59- $(MV) $@.tmp $@ >>>> 60: $(CHMOD) 444 $@ >>>> 61- >>>> >>>> common/JavaCompilation.gmk >>>> 80- $(CP) $$< $$@ >>>> 81: $(CHMOD) -f ug+w $$@ >>>> >>>> Thanks >>>> Max >>>> >>>>> /Magnus >>>>> >>>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson : >>>>>> >>>>>> Build changes look ok. >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>>> On 2018-05-22 08:25, Weijun Wang wrote: >>>>>>> Please take a review at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ >>>>>>> >>>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. >>>>>>> >>>>>>> There is no plan to update the data in a different channel other than a JDK release. >>>>>>> >>>>>>> Thanks >>>>>>> Max From glaubitz at physik.fu-berlin.de Thu May 24 12:49:38 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 May 2018 14:49:38 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> Message-ID: <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> On 05/24/2018 02:42 PM, Aleksey Shipilev wrote: >> Does SPARC have support for C2 on Solaris so that we need to >> add it for linux-sparc as well or is this limited to x86_64 only? > > You must be seeing something new, because the fix for Minimal and Zero was pushed to jdk/jdk > already. Submit a bug report? I am seeing the same problem as yesterday (or was it the day before yesterday?), after running "hg pull && hg update --clean" today. And "hg blame" showed me the regression came through JDK-8202377. The error remains the same: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_library_call.o:\n" * For target hotspot_variant-server_libjvm_objs_library_call.o: (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log || true) | /usr/bin/head -n 12 /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp: In member function ?bool LibraryCallKit::inline_native_clone(bool)?: /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp:4272:38: error: incomplete type ?BarrierSet? used in nested name specifier BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2(); ^~~~~~~~~~~ if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs.\n" * All command lines available in /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From shade at redhat.com Thu May 24 12:53:52 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 May 2018 14:53:52 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> Message-ID: <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> On 05/24/2018 02:49 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:42 PM, Aleksey Shipilev wrote: >>> Does SPARC have support for C2 on Solaris so that we need to >>> add it for linux-sparc as well or is this limited to x86_64 only? >> >> You must be seeing something new, because the fix for Minimal and Zero was pushed to jdk/jdk >> already. Submit a bug report? > > I am seeing the same problem as yesterday (or was it the day before yesterday?), > after running "hg pull && hg update --clean" today. And "hg blame" showed me > the regression came through JDK-8202377. > > The error remains the same: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_library_call.o:\n" > * For target hotspot_variant-server_libjvm_objs_library_call.o: > (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log || true) | /usr/bin/head -n 12 > /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp: In member function ?bool LibraryCallKit::inline_native_clone(bool)?: > /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp:4272:38: error: incomplete type ?BarrierSet? used in nested name specifier > BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2(); > ^~~~~~~~~~~ Yeah, but this issue dealt with: /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: fatal error: adfiles/adGlobals_x86.hpp: No such file or directory #include CPU_HEADER(adfiles/adGlobals) Let's not conflate the two. What you are seeing seems to be specific to Zero, and not to Minimal. -Aleksey From glaubitz at physik.fu-berlin.de Thu May 24 12:55:05 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 May 2018 14:55:05 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> Message-ID: On 05/24/2018 02:53 PM, Aleksey Shipilev wrote: > Yeah, but this issue dealt with: > > /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: fatal error: > adfiles/adGlobals_x86.hpp: No such file or directory > #include CPU_HEADER(adfiles/adGlobals) > > Let's not conflate the two. What you are seeing seems to be specific to Zero, and not to Minimal. I'm not building Zero in this case but Hotspot native for linux-sparc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From shade at redhat.com Thu May 24 12:57:57 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 May 2018 14:57:57 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> Message-ID: <8733d113-b0d4-a7ae-20bb-ae505e0ff539@redhat.com> On 05/24/2018 02:55 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:53 PM, Aleksey Shipilev wrote: >> Yeah, but this issue dealt with: >> >> /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: fatal error: >> adfiles/adGlobals_x86.hpp: No such file or directory >> #include CPU_HEADER(adfiles/adGlobals) >> >> Let's not conflate the two. What you are seeing seems to be specific to Zero, and not to Minimal. > > I'm not building Zero in this case but Hotspot native for linux-sparc. Oh. I am just confused you are replying to the stale review thread for "Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)". What you are seeing is something else. -Aleksey From shade at redhat.com Thu May 24 12:59:07 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 May 2018 14:59:07 +0200 Subject: RFR (round 3), JEP-318: Epsilon GC In-Reply-To: <2e5ab487-b37e-3028-3865-e6bf4b470293@oracle.com> References: <6c1ae009-769c-fab4-f691-96a0d8af38ce@redhat.com> <2e5ab487-b37e-3028-3865-e6bf4b470293@oracle.com> Message-ID: <304b8b1f-36d8-fc44-49e2-fb970c19a8c3@redhat.com> On 05/24/2018 02:09 PM, Magnus Ihse Bursie wrote: > Please remember to include build-dev whenever you make changes to the build system. Yeah, this was by accident: the prior webrevs had no changes in the build system, and only after GC modularization uptake some of them emerged. > Build part of your webrev looks good. Thanks! -Aleksey From glaubitz at physik.fu-berlin.de Thu May 24 12:59:58 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 May 2018 14:59:58 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <8733d113-b0d4-a7ae-20bb-ae505e0ff539@redhat.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> <8733d113-b0d4-a7ae-20bb-ae505e0ff539@redhat.com> Message-ID: <6fb79d00-6ec5-9571-6f64-496590ed778f@physik.fu-berlin.de> On 05/24/2018 02:57 PM, Aleksey Shipilev wrote: > Oh. I am just confused you are replying to the stale review thread for "Minimal, Zero builds fail > after JDK-8202377 (Modularize C2 barriers)". What you are seeing is something else. As I said, "hg blame" indicates the change which probably broke linux-sparc here is 8202377, most likely because it was assumed SPARC needs to work on Solaris only -.-. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Thu May 24 13:01:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 May 2018 23:01:36 +1000 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> Message-ID: <729182b0-5cda-d3f6-84ee-dd07cfd96c56@oracle.com> On 24/05/2018 10:55 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:53 PM, Aleksey Shipilev wrote: >> Yeah, but this issue dealt with: >> >> /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: fatal error: >> adfiles/adGlobals_x86.hpp: No such file or directory >> #include CPU_HEADER(adfiles/adGlobals) >> >> Let's not conflate the two. What you are seeing seems to be specific to Zero, and not to Minimal. > > I'm not building Zero in this case but Hotspot native for linux-sparc. Are you building an interpreter only version of linux-sparc? This barrier code seems highly suspect to me with regards to how it tries to deal with C1 versus C2. I suspect at least one must be present. But if this is not Minimal nor Zero then it needs another bug filed :) David > Adrian > From shade at redhat.com Thu May 24 13:03:17 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 May 2018 15:03:17 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <6fb79d00-6ec5-9571-6f64-496590ed778f@physik.fu-berlin.de> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> <8733d113-b0d4-a7ae-20bb-ae505e0ff539@redhat.com> <6fb79d00-6ec5-9571-6f64-496590ed778f@physik.fu-berlin.de> Message-ID: <4754754c-7336-731e-8535-b9282e50465f@redhat.com> On 05/24/2018 02:59 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:57 PM, Aleksey Shipilev wrote: >> Oh. I am just confused you are replying to the stale review thread for "Minimal, Zero builds fail >> after JDK-8202377 (Modularize C2 barriers)". What you are seeing is something else. > > As I said, "hg blame" indicates the change which probably broke linux-sparc > here is 8202377, most likely because it was assumed SPARC needs to work > on Solaris only -.-. Yes, 8202377 might have caused more than one type of regression! This is something else. Submit the new bug for it. Let's not do this discussion in the thread for *another* bug that was already fixed. This would bite us once you would start doing mailing list archeology months later. -Aleksey From glaubitz at physik.fu-berlin.de Thu May 24 13:04:22 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 24 May 2018 15:04:22 +0200 Subject: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers) In-Reply-To: <729182b0-5cda-d3f6-84ee-dd07cfd96c56@oracle.com> References: <230b059e-7a98-e1a0-f747-970e64d47678@redhat.com> <85d050be-86bd-afda-52c2-b6beded4850d@physik.fu-berlin.de> <911cedc2-9b8e-0a1a-a0dd-4b69a5166c0c@redhat.com> <729182b0-5cda-d3f6-84ee-dd07cfd96c56@oracle.com> Message-ID: <8655c921-ae69-b403-d495-a470e3966111@physik.fu-berlin.de> On 05/24/2018 03:01 PM, David Holmes wrote: >> I'm not building Zero in this case but Hotspot native for linux-sparc. > > Are you building an interpreter only version of linux-sparc? No, I don't think so: MAKE_VERBOSE=y QUIETLY= LOG=debug sh ./configure --with-jvm-variants=server --with-boot-jdk=/usr/lib/jvm/java-10-openjdk-sparc64 --disable-precompiled-headers --with-debug-level=release --disable-warnings-as-errors --disable-javac-server --with-num-cores=16 > This barrier code seems highly suspect to me with regards to how it tries to deal with C1 versus C2. I suspect at least one must be present. > > But if this is not Minimal nor Zero then it needs another bug filed :) Already done: https://bugs.openjdk.java.net/browse/JDK-8203787 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From jonathan.gibbons at oracle.com Thu May 24 16:24:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 24 May 2018 09:24:20 -0700 Subject: RFR: JDK-8203366 tag added wrongly in Docs.gmk In-Reply-To: References: Message-ID: Looks good to me. -- Jon On 5/24/18 5:32 AM, Magnus Ihse Bursie wrote: > From the bug report: > > This line in Docs.gmk is incorrect, and should be removed. > > -tag version \ > > It incorrectly enables support for the @version tag, which should only > be enabled by the (poorly-named) -version option.? (@version and > -version are a similar pair to @author and -author). > > A small number of java SE API files contain a very-old @version tag, > and this started showing up in JavaSE docs in JDK 8. You can find > these files by grepping recursively for @version.? The change that > added this line is probably a side-effect of adding support for the > @apiNote, @implNote, @implSpec tags. > > Note that removing this line will change the Java SE API docs, > reverting the handling of @version back to its original treatment of > being ignored up through and including JDK 7. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203366 > Patch inline: > diff --git a/make/Docs.gmk b/make/Docs.gmk > --- a/make/Docs.gmk > +++ b/make/Docs.gmk > @@ -85,7 +85,6 @@ > ???? -tag throws \ > ???? -taglet build.tools.taglet.ModuleGraph \ > ???? -tag since \ > -??? -tag version \ > ???? -tag serialData \ > ???? -tag factory \ > ???? -tag see \ > > /Magnus From erik.joelsson at oracle.com Thu May 24 17:44:28 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 May 2018 10:44:28 -0700 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: References: Message-ID: This looks ok to me. /Erik On 2018-05-23 18:08, Ao Qi wrote: > Hi Erik, > > Thanks for your comments. I made a new patch: > > $ hg diff > diff -r 31361382634b make/autoconf/build-aux/config.guess > --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700 > +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800 > @@ -86,6 +86,17 @@ > fi > fi > > +# Test and fix little endian MIPS. > +if [ "x$OUT" = x ]; then > + if [ `uname -s` = Linux ]; then > + if [ `uname -m` = mipsel ]; then > + OUT=mipsel-unknown-linux-gnu > + elif [ `uname -m` = mips64el ]; then > + OUT=mips64el-unknown-linux-gnu > + fi > + fi > +fi > + > # Test and fix cpu on Macosx when C preprocessor is not on the path > echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null > if test $? = 0; then > > Cheers, > Ao Qi > > 2018-05-24 0:19 GMT+08:00 Erik Joelsson : >> Hello Ao Qi, >> >> Due to licensing reasons, we are unable to directly update the >> autoconf-config.guess file. Instead we have the wrapper, config.guess in >> which we make adjustments to the result returned by autoconf-config.guess. >> Your fix needs to go in the wrapper file. >> >> /Erik >> >> >> >> On 2018-05-23 03:18, Ao Qi wrote: >>> Hi all, >>> I tried to configure jdk/jdk on MIPS, but I failed. The output of >>> configure: >>> ... >>> checking for pandoc... no >>> checking build system type... >>> /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable >>> to guess system type >>> >>> This script, last modified 2012-02-10, has failed to recognize >>> the operating system you are using. It is advised that you >>> download the most up to date version of the config scripts from >>> >>> >>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >>> and >>> >>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD >>> >>> If the version you run >>> (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is >>> already up to date, please >>> send the following data and any information you think might be >>> pertinent to in order to provide the needed >>> information to handle your system. >>> >>> config.guess timestamp = 2012-02-10 >>> >>> uname -m = mips64el >>> uname -r = 3.10.0-693.5.2.ns7.032.mips64el >>> uname -s = Linux >>> uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >>> >>> /usr/bin/uname -p = mips64el >>> /bin/uname -X = >>> >>> hostinfo = >>> /bin/universe = >>> /usr/bin/arch -k = >>> /bin/arch = mips64el >>> /usr/bin/oslevel = >>> /usr/convex/getsysinfo = >>> >>> UNAME_MACHINE = mips64el >>> UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el >>> UNAME_SYSTEM = Linux >>> UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >>> configure: error: cannot guess build type; you must specify one >>> configure exiting with result code 1 >>> ... >>> >>> I think the reason is that uname returns mips64el. >>> autoconf-config.guess can handle mips and mips64, but cannot handle >>> mipsel and mips64el. >>> I made a patch to pass the configure: >>> >>> $ hg diff >>> diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess >>> --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 >>> 10:08:04 2018 -0700 >>> +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 >>> 18:06:52 2018 +0800 >>> @@ -977,6 +977,9 @@ >>> eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` >>> test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } >>> ;; >>> + mipsel:Linux:*:* | mips64el:Linux:*:*) >>> + echo ${UNAME_MACHINE}-unknown-linux-gnu >>> + exit ;; >>> or32:Linux:*:*) >>> echo ${UNAME_MACHINE}-unknown-linux-gnu >>> exit ;; >>> >>> >>> I think ppc has the same problem, but it is fixed in >>> make/autoconf/build-aux/config.guess. >>> >>> Thanks, >>> Ao Qi >> From erik.joelsson at oracle.com Thu May 24 17:51:57 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 May 2018 10:51:57 -0700 Subject: RFR: JDK-8203366 tag added wrongly in Docs.gmk In-Reply-To: References: Message-ID: <8115aec7-af3f-ca49-fdde-536306f7d9b2@oracle.com> Looks good. /Erik On 2018-05-24 05:32, Magnus Ihse Bursie wrote: > From the bug report: > > This line in Docs.gmk is incorrect, and should be removed. > > -tag version \ > > It incorrectly enables support for the @version tag, which should only > be enabled by the (poorly-named) -version option.? (@version and > -version are a similar pair to @author and -author). > > A small number of java SE API files contain a very-old @version tag, > and this started showing up in JavaSE docs in JDK 8. You can find > these files by grepping recursively for @version.? The change that > added this line is probably a side-effect of adding support for the > @apiNote, @implNote, @implSpec tags. > > Note that removing this line will change the Java SE API docs, > reverting the handling of @version back to its original treatment of > being ignored up through and including JDK 7. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203366 > Patch inline: > diff --git a/make/Docs.gmk b/make/Docs.gmk > --- a/make/Docs.gmk > +++ b/make/Docs.gmk > @@ -85,7 +85,6 @@ > ???? -tag throws \ > ???? -taglet build.tools.taglet.ModuleGraph \ > ???? -tag since \ > -??? -tag version \ > ???? -tag serialData \ > ???? -tag factory \ > ???? -tag see \ > > /Magnus From erik.joelsson at oracle.com Thu May 24 22:26:38 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 24 May 2018 15:26:38 -0700 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 Message-ID: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> Now that we have support for building with VS2017, it's time to change the default compiler picked up by the configure script to VS2017. Oracle is also changing the version used internally, by updating jib-profiles.js Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 /Erik From philip.race at oracle.com Thu May 24 22:52:10 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 24 May 2018 15:52:10 -0700 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 In-Reply-To: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> References: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> Message-ID: <5B07421A.7060901@oracle.com> # The order of these defines the priority by which we try to find them. -VALID_VS_VERSIONS="2013 2012 2010 2015 2017" +VALID_VS_VERSIONS="2017 2015 2013 2012 2010" I think it better to have VS2013 as the 2nd option since 2015 was never an official compiler and people might have 2015 configs that are not suitable in some way but it did not matter before .. -phil On 5/24/18, 3:26 PM, Erik Joelsson wrote: > Now that we have support for building with VS2017, it's time to change > the default compiler picked up by the configure script to VS2017. > > Oracle is also changing the version used internally, by updating > jib-profiles.js > > Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 > > /Erik > From serguei.spitsyn at oracle.com Fri May 25 00:00:00 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 May 2018 17:00:00 -0700 Subject: RFR(XL) : 8199383 : [TESTBUG] Open source VM testbase JVMTI tests In-Reply-To: References: Message-ID: Hi Igor, It looks good to me. Thanks, Serguei On 5/22/18 16:35, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html >> 308253 lines changed: 308253 ins; 0 del; 0 mod; > Hi all, > > could you please review this patch which open sources JVMTI tests from VM testbase? > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > webrev: http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8199383 > testing: :vmTestbase_nsk_jvmti test group > > Thanks, > -- Igor From thomas.stuefe at gmail.com Fri May 25 05:56:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 25 May 2018 07:56:12 +0200 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 In-Reply-To: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> References: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> Message-ID: Hi Erik, will Oracle change the jdk-submit builds to VS2017? Most of our guys still work with VS2013, so we may miss build errors on our machines. Thanks, Thomas On Fri, May 25, 2018 at 12:26 AM, Erik Joelsson wrote: > Now that we have support for building with VS2017, it's time to change the > default compiler picked up by the configure script to VS2017. > > Oracle is also changing the version used internally, by updating > jib-profiles.js > > Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 > > /Erik > From magnus.ihse.bursie at oracle.com Fri May 25 07:38:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 09:38:13 +0200 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 In-Reply-To: References: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> Message-ID: On 2018-05-25 07:56, Thomas St?fe wrote: > Hi Erik, > > will Oracle change the jdk-submit builds to VS2017? Most of our guys > still work with VS2013, so we may miss build errors on our machines. This change will affect all our build systems, including jdk-submit, yes. Fix looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Fri May 25 07:40:51 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 09:40:51 +0200 Subject: RFR(XL) : 8199383 : [TESTBUG] Open source VM testbase JVMTI tests In-Reply-To: <8bfed6c4-d0e0-4324-5982-d4ef040d12c1@oracle.com> References: <8bfed6c4-d0e0-4324-5982-d4ef040d12c1@oracle.com> Message-ID: On 2018-05-23 02:05, Erik Joelsson wrote: > Looks like the line "# } nsk/jvmti" is a left over. Otherwise this > looks ok, even if it's an enormous amount of duplication. Hopefully we > can figure out a better way to express common parameters for tests soon. Argee, the current solution is not scaling to this kind of multiple test with additions. There is already an issue on JBS for this: https://bugs.openjdk.java.net/browse/JDK-8201582 /Magnus > > /Erik > > > On 2018-05-22 16:35, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html >>> 308253 lines changed: 308253 ins; 0 del; 0 mod; >> Hi all, >> >> could you please review this patch which open sources JVMTI tests >> from VM testbase? >> >> As usually w/ VM testbase code, these tests are old, they have been >> run in hotspot testing for a long period of time. Originally, these >> tests were run by a test harness different from jtreg and had >> different build and execution schemes, some parts couldn't be easily >> translated to jtreg, so tests might have actions or pieces of code >> which look weird. In a long term, we are planning to rework them. >> >> webrev: >> http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8199383 >> testing: :vmTestbase_nsk_jvmti test group >> >> Thanks, >> -- Igor > From magnus.ihse.bursie at oracle.com Fri May 25 07:42:16 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 09:42:16 +0200 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: References: Message-ID: <1a32aeb8-b1a9-cf66-ac12-342f10016db1@oracle.com> On 2018-05-24 03:08, Ao Qi wrote: > Hi Erik, > > Thanks for your comments. I made a new patch: > > $ hg diff > diff -r 31361382634b make/autoconf/build-aux/config.guess > --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700 > +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800 > @@ -86,6 +86,17 @@ > fi > fi > > +# Test and fix little endian MIPS. > +if [ "x$OUT" = x ]; then > + if [ `uname -s` = Linux ]; then > + if [ `uname -m` = mipsel ]; then > + OUT=mipsel-unknown-linux-gnu > + elif [ `uname -m` = mips64el ]; then > + OUT=mips64el-unknown-linux-gnu > + fi > + fi > +fi > + > # Test and fix cpu on Macosx when C preprocessor is not on the path > echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null > if test $? = 0; then Looks good to me. /Magnus > > Cheers, > Ao Qi > > 2018-05-24 0:19 GMT+08:00 Erik Joelsson : >> Hello Ao Qi, >> >> Due to licensing reasons, we are unable to directly update the >> autoconf-config.guess file. Instead we have the wrapper, config.guess in >> which we make adjustments to the result returned by autoconf-config.guess. >> Your fix needs to go in the wrapper file. >> >> /Erik >> >> >> >> On 2018-05-23 03:18, Ao Qi wrote: >>> Hi all, >>> I tried to configure jdk/jdk on MIPS, but I failed. The output of >>> configure: >>> ... >>> checking for pandoc... no >>> checking build system type... >>> /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable >>> to guess system type >>> >>> This script, last modified 2012-02-10, has failed to recognize >>> the operating system you are using. It is advised that you >>> download the most up to date version of the config scripts from >>> >>> >>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >>> and >>> >>> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD >>> >>> If the version you run >>> (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is >>> already up to date, please >>> send the following data and any information you think might be >>> pertinent to in order to provide the needed >>> information to handle your system. >>> >>> config.guess timestamp = 2012-02-10 >>> >>> uname -m = mips64el >>> uname -r = 3.10.0-693.5.2.ns7.032.mips64el >>> uname -s = Linux >>> uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >>> >>> /usr/bin/uname -p = mips64el >>> /bin/uname -X = >>> >>> hostinfo = >>> /bin/universe = >>> /usr/bin/arch -k = >>> /bin/arch = mips64el >>> /usr/bin/oslevel = >>> /usr/convex/getsysinfo = >>> >>> UNAME_MACHINE = mips64el >>> UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el >>> UNAME_SYSTEM = Linux >>> UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >>> configure: error: cannot guess build type; you must specify one >>> configure exiting with result code 1 >>> ... >>> >>> I think the reason is that uname returns mips64el. >>> autoconf-config.guess can handle mips and mips64, but cannot handle >>> mipsel and mips64el. >>> I made a patch to pass the configure: >>> >>> $ hg diff >>> diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess >>> --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 >>> 10:08:04 2018 -0700 >>> +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 >>> 18:06:52 2018 +0800 >>> @@ -977,6 +977,9 @@ >>> eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` >>> test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } >>> ;; >>> + mipsel:Linux:*:* | mips64el:Linux:*:*) >>> + echo ${UNAME_MACHINE}-unknown-linux-gnu >>> + exit ;; >>> or32:Linux:*:*) >>> echo ${UNAME_MACHINE}-unknown-linux-gnu >>> exit ;; >>> >>> >>> I think ppc has the same problem, but it is fixed in >>> make/autoconf/build-aux/config.guess. >>> >>> Thanks, >>> Ao Qi >> From thomas.stuefe at gmail.com Fri May 25 08:20:16 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 25 May 2018 10:20:16 +0200 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 In-Reply-To: References: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> Message-ID: On Fri 25. May 2018 at 09:39, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-05-25 07:56, Thomas St?fe wrote: > > Hi Erik, > > will Oracle change the jdk-submit builds to VS2017? Most of our guys > still work with VS2013, so we may miss build errors on our machines. > > This change will affect all our build systems, including jdk-submit, yes. > Thanks for confirming! ..Thomas > Fix looks good to me. > > > /Magnus > From magnus.ihse.bursie at oracle.com Fri May 25 08:21:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 10:21:22 +0200 Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder In-Reply-To: <03B02EC4-3594-4476-8ED3-8606B53DF6BC@oracle.com> References: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> <867f2308-6f92-edd1-e76b-50e685f47a26@oracle.com> <03B02EC4-3594-4476-8ED3-8606B53DF6BC@oracle.com> Message-ID: <601926c0-036c-6807-691b-b9f871ec3dce@oracle.com> On 2018-05-16 16:18, Magnus Ihse Bursie wrote: >> 16 maj 2018 kl. 01:39 skrev Erik Joelsson : >> >> Hello, >> >> In GensrcJfr, JFR_TOOLS_OUTPUTDIR is defined twice. > Oops, will fix. > >> Other build tools are in make/{jdk,hotspot}/src/classes. Do you think we should be moving them to one place? Regardless, I think we need an INCLUDE in the SetupJavaCompilation so that we only build the tool we need. There is currently no other tools in make/src/classes, but that directory is inviting for others. > I think we should move all tools to a common place. The current solution is more an effect of how things ended up due to the old multi-repo design. > > So I though: let's start doing things right, and put this one in a common build tool directory, and then we can move the rest there in a follow up. > > But if you think that is confusing (I could really agree) we can skip doing that now. If so, I'll just move this to some jfr_build_tools_classes dir instead. I never got a response to this, so I took this as an acceptance and went ahead and pushed it. :-) I opened https://bugs.openjdk.java.net/browse/JDK-8203821 as an enhancement to track the need to deal with the entire java-build-tools thing properly. Hope this was an acceptable solution to you. /Magnus > > /Magnus > >> /Erik >> >> >>> On 2018-05-15 16:14, Magnus Ihse Bursie wrote: >>> Cleanups of the build system after Flight Recorder. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203221 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8203221-makefile-fixes-after-flight-recorder/webrev.01 >>> >>> /Magnus From alexey.ivanov at oracle.com Fri May 25 08:27:57 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 25 May 2018 09:27:57 +0100 Subject: [8u-dev] RFR for JDK-8203790: MSVCP dependency introduced in awt.dll Message-ID: Hi, Could you please review the following fix for 8u-dev? jbs: https://bugs.openjdk.java.net/browse/JDK-8203790 webrev: http://cr.openjdk.java.net/~aivanov/8203790/jdk8/webrev.0/ There's a missing ?C? in the name, and the compiler flags were not added which led to the dependency. Thank you, Alexey From magnus.ihse.bursie at oracle.com Fri May 25 08:30:17 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 10:30:17 +0200 Subject: RFR: JDK-8203822 AIX version of jsig.c was not removed in JDK-8200298 Message-ID: <9263b072-32dd-ed5e-61e9-a97fa7d72f1e@oracle.com> For some reason, the AIX version of jsig.c was not removed in JDK-8200298, as was intended and reviewed in the webrev. (hg hiccup perhaps, or PEBKAC from Yours truly). Bug: https://bugs.openjdk.java.net/browse/JDK-8203822 Patch inline: diff --git a/src/java.base/aix/native/libjsig/jsig.c b/src/java.base/aix/native/libjsig/jsig.c deleted file mode 100644 --- a/src/java.base/aix/native/libjsig/jsig.c +++ /dev/null @@ -1,238 +0,0 @@ -/* - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All rights reserved. [... rest of file omitted] /Magnus From magnus.ihse.bursie at oracle.com Fri May 25 08:45:09 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 10:45:09 +0200 Subject: [8u-dev] RFR for JDK-8203790: MSVCP dependency introduced in awt.dll In-Reply-To: References: Message-ID: <61b99b25-d90d-9469-9ebf-286119c830b9@oracle.com> On 2018-05-25 10:27, Alexey Ivanov wrote: > Hi, > > Could you please review the following fix for 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8203790 > webrev: http://cr.openjdk.java.net/~aivanov/8203790/jdk8/webrev.0/ > > There's a missing ?C? in the name, and the compiler flags were not > added which led to the dependency. Looks good to me. /Magnus > > > Thank you, > Alexey From kevin.walls at oracle.com Fri May 25 08:49:18 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 25 May 2018 09:49:18 +0100 Subject: [8u-dev] RFR for JDK-8203790: MSVCP dependency introduced in awt.dll In-Reply-To: References: Message-ID: <79e6f737-c886-2c23-c5de-602a9ca8be3c@oracle.com> Thanks Alexey - my build with this change completed OK too and the MSVCP dependency in awt.dll has gone, great! Thanks Kevin On 25/05/2018 09:27, Alexey Ivanov wrote: > Hi, > > Could you please review the following fix for 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8203790 > webrev: http://cr.openjdk.java.net/~aivanov/8203790/jdk8/webrev.0/ > > There's a missing ?C? in the name, and the compiler flags were not > added which led to the dependency. > > > Thank you, > Alexey From alexey.ivanov at oracle.com Fri May 25 09:21:08 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 25 May 2018 10:21:08 +0100 Subject: [8u-dev] RFR for JDK-8203790: MSVCP dependency introduced in awt.dll In-Reply-To: <79e6f737-c886-2c23-c5de-602a9ca8be3c@oracle.com> References: <79e6f737-c886-2c23-c5de-602a9ca8be3c@oracle.com> Message-ID: <067ba72d-ca83-33af-3cc3-76a0fe76eedd@oracle.com> Thank you Magnus and Kevin for your quick reviews. Regards, Alexey On 25/05/2018 09:49, Kevin Walls wrote: > > Thanks Alexey - my build with this change completed OK too and the > MSVCP dependency in awt.dll has gone, great! > > Thanks > Kevin > > > On 25/05/2018 09:27, Alexey Ivanov wrote: >> Hi, >> >> Could you please review the following fix for 8u-dev? >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8203790 >> webrev: http://cr.openjdk.java.net/~aivanov/8203790/jdk8/webrev.0/ >> >> There's a missing ?C? in the name, and the compiler flags were not >> added which led to the dependency. >> >> >> Thank you, >> Alexey > From magnus.ihse.bursie at oracle.com Fri May 25 10:06:59 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 May 2018 12:06:59 +0200 Subject: RFR: JDK-8200867 Remove references to "jdk 9" in build system Message-ID: There were some lingering references to jdk 9 in the build documentation. Remove this (and do not replace with new version numbers, due to our accelerated versioning scheme). From the bug report: $ bash ./configure --help | head -1 `configure' configures OpenJDK jdk9 to adapt to many kinds of systems. --- $ grep -i 'jdk.9' doc/building.md This table lists the OS versions used by Oracle when building JDK 9. Such OpenJDK 9, the only supported such layer is Cygwin. (Msys is no longer OpenJDK 9 includes patches that should allow gcc 6 to compile, but this should should be a JDK of major version *N-1*, so for building JDK 9 a JDK 8 would be version, since JDK 8 GA might not be able to build JDK 9 on all platforms. building JDK 9.) make targets. All source code in JDK 9 is organized so it belongs to a module, Bug: https://bugs.openjdk.java.net/browse/JDK-8200867 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01 /Magnus From claes.redestad at oracle.com Fri May 25 11:23:54 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 25 May 2018 13:23:54 +0200 Subject: RFR: JDK-8200867 Remove references to "jdk 9" in build system In-Reply-To: References: Message-ID: <46ac1e52-687a-b8b4-4f98-c0b3c140a46b@oracle.com> On 2018-05-25 12:06, Magnus Ihse Bursie wrote: > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01 > Looks good to me! /Claes From tim.bell at oracle.com Fri May 25 13:52:43 2018 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 25 May 2018 06:52:43 -0700 Subject: RFR: JDK-8200867 Remove references to "jdk 9" in build system In-Reply-To: <46ac1e52-687a-b8b4-4f98-c0b3c140a46b@oracle.com> References: <46ac1e52-687a-b8b4-4f98-c0b3c140a46b@oracle.com> Message-ID: <5B08152B.9050008@oracle.com> Magnus- On 05/25/18 04:23, Claes Redestad wrote: > On 2018-05-25 12:06, Magnus Ihse Bursie wrote: >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01 >> > > Looks good to me! > > /Claes doc/building.md doc/building.html These files also have changes to minimum gcc versions (4.7/4.8/4.9.2/7.3.0) - is that for a different bug number? Looks good to me otherwise. /Tim From erik.joelsson at oracle.com Fri May 25 16:13:04 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 May 2018 09:13:04 -0700 Subject: RFR: JDK-8203221 Makefile fixes after Flight Recorder In-Reply-To: <601926c0-036c-6807-691b-b9f871ec3dce@oracle.com> References: <269e3cbd-1e11-7a21-1492-95a5a19ce014@oracle.com> <867f2308-6f92-edd1-e76b-50e685f47a26@oracle.com> <03B02EC4-3594-4476-8ED3-8606B53DF6BC@oracle.com> <601926c0-036c-6807-691b-b9f871ec3dce@oracle.com> Message-ID: <4ea48de0-4aec-1428-766e-425c74063eaa@oracle.com> On 2018-05-25 01:21, Magnus Ihse Bursie wrote: > On 2018-05-16 16:18, Magnus Ihse Bursie wrote: >>> 16 maj 2018 kl. 01:39 skrev Erik Joelsson: >>> >>> Hello, >>> >>> In GensrcJfr, JFR_TOOLS_OUTPUTDIR is defined twice. >> Oops, will fix. >> >>> Other build tools are in make/{jdk,hotspot}/src/classes. Do you think we should be moving them to one place? Regardless, I think we need an INCLUDE in the SetupJavaCompilation so that we only build the tool we need. There is currently no other tools in make/src/classes, but that directory is inviting for others. >> I think we should move all tools to a common place. The current solution is more an effect of how things ended up due to the old multi-repo design. >> >> So I though: let's start doing things right, and put this one in a common build tool directory, and then we can move the rest there in a follow up. >> >> But if you think that is confusing (I could really agree) we can skip doing that now. If so, I'll just move this to some jfr_build_tools_classes dir instead. > > I never got a response to this, so I took this as an acceptance and > went ahead and pushed it. :-) > > I opened https://bugs.openjdk.java.net/browse/JDK-8203821 as an > enhancement to track the need to deal with the entire java-build-tools > thing properly. > > Hope this was an acceptable solution to you. > I was expecting a new version of the review where you addressed the need for INCLUDE in SetupJavaCompilation. What you pushed works for now because this is the only tool in that source tree, but will not work if you add another tool. As I see it, we need to either: 1. Build all the tools in one go, into a common output dir like "tools_classes" 2. Build each tool separately, carefully only including the relevant files, preferably into separate output dirs, but sharing here is possible, though ugly IMO. /Erik > /Magnus > >> /Magnus >> >>> /Erik >>> >>> >>>> On 2018-05-15 16:14, Magnus Ihse Bursie wrote: >>>> Cleanups of the build system after Flight Recorder. >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8203221 >>>> WebRev:http://cr.openjdk.java.net/~ihse/JDK-8203221-makefile-fixes-after-flight-recorder/webrev.01 >>>> >>>> /Magnus > From erik.joelsson at oracle.com Fri May 25 16:14:16 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 May 2018 09:14:16 -0700 Subject: RFR: JDK-8203822 AIX version of jsig.c was not removed in JDK-8200298 In-Reply-To: <9263b072-32dd-ed5e-61e9-a97fa7d72f1e@oracle.com> References: <9263b072-32dd-ed5e-61e9-a97fa7d72f1e@oracle.com> Message-ID: <5261b893-510d-29c1-9dc8-b40a87bb917c@oracle.com> Looks good. /Erik On 2018-05-25 01:30, Magnus Ihse Bursie wrote: > For some reason, the AIX version of jsig.c was not removed in > JDK-8200298, as was intended and reviewed in the webrev. (hg hiccup > perhaps, or PEBKAC from Yours truly). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203822 > > Patch inline: > diff --git a/src/java.base/aix/native/libjsig/jsig.c > b/src/java.base/aix/native/libjsig/jsig.c > deleted file mode 100644 > --- a/src/java.base/aix/native/libjsig/jsig.c > +++ /dev/null > @@ -1,238 +0,0 @@ > -/* > - * Copyright (c) 2001, 2015, Oracle and/or its affiliates. All rights > reserved. > [... rest of file omitted] > > /Magnus From erik.joelsson at oracle.com Fri May 25 16:17:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 May 2018 09:17:36 -0700 Subject: RFR: JDK-8200867 Remove references to "jdk 9" in build system In-Reply-To: <5B08152B.9050008@oracle.com> References: <46ac1e52-687a-b8b4-4f98-c0b3c140a46b@oracle.com> <5B08152B.9050008@oracle.com> Message-ID: On 2018-05-25 06:52, Tim Bell wrote: > Magnus- > > On 05/25/18 04:23, Claes Redestad wrote: >> On 2018-05-25 12:06, Magnus Ihse Bursie wrote: >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8200867-remove-jdk9-references/webrev.01 >>> >>> >> >> Looks good to me! >> >> /Claes > Looks good! > doc/building.md > doc/building.html > > These files also have changes to minimum gcc versions > (4.7/4.8/4.9.2/7.3.0) - is that for a different bug number? > I believe he is just updating outdated numbers in the doc that he stumbled on. The changes are all correct. /Erik > Looks good to me otherwise. > > /Tim > > From erik.joelsson at oracle.com Fri May 25 17:59:33 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 May 2018 10:59:33 -0700 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 In-Reply-To: <5B07421A.7060901@oracle.com> References: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> <5B07421A.7060901@oracle.com> Message-ID: <6ed38617-019f-f74a-5a97-36515fcdd567@oracle.com> Hello, Valid point. Reordered the versions search order. I also noticed that there is a new build failure caused by a warning in a test. This patch disables the warning. There is a bug filed for fixing it already: https://bugs.openjdk.java.net/browse/JDK-8203802 New webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.02/ /Erik On 2018-05-24 15:52, Philip Race wrote: > # The order of these defines the priority by which we try to find them. > -VALID_VS_VERSIONS="2013 2012 2010 2015 2017" > +VALID_VS_VERSIONS="2017 2015 2013 2012 2010" > I think it better to have VS2013 as the 2nd option since 2015 > was never an official compiler and people might have 2015 configs that > are not suitable in some way but it did not matter before .. > > -phil > > On 5/24/18, 3:26 PM, Erik Joelsson wrote: >> Now that we have support for building with VS2017, it's time to >> change the default compiler picked up by the configure script to VS2017. >> >> Oracle is also changing the version used internally, by updating >> jib-profiles.js >> >> Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 >> >> /Erik >> From philip.race at oracle.com Fri May 25 18:09:36 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 May 2018 11:09:36 -0700 Subject: RFR: JDK-8203795: Change default compiler on Windows to VS2017 In-Reply-To: <6ed38617-019f-f74a-5a97-36515fcdd567@oracle.com> References: <59b464d2-a22b-332d-15c0-9a8785e6fb32@oracle.com> <5B07421A.7060901@oracle.com> <6ed38617-019f-f74a-5a97-36515fcdd567@oracle.com> Message-ID: <0e851268-f8d0-818c-db6b-ca2006f33d47@oracle.com> Looks good to me. -phil. On 05/25/2018 10:59 AM, Erik Joelsson wrote: > > Hello, > > Valid point. Reordered the versions search order. > > I also noticed that there is a new build failure caused by a warning > in a test. This patch disables the warning. There is a bug filed for > fixing it already: > > https://bugs.openjdk.java.net/browse/JDK-8203802 > > New webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.02/ > > /Erik > > > On 2018-05-24 15:52, Philip Race wrote: >> # The order of these defines the priority by which we try to find them. >> -VALID_VS_VERSIONS="2013 2012 2010 2015 2017" >> +VALID_VS_VERSIONS="2017 2015 2013 2012 2010" >> I think it better to have VS2013 as the 2nd option since 2015 >> was never an official compiler and people might have 2015 configs that >> are not suitable in some way but it did not matter before .. >> >> -phil >> >> On 5/24/18, 3:26 PM, Erik Joelsson wrote: >>> Now that we have support for building with VS2017, it's time to >>> change the default compiler picked up by the configure script to >>> VS2017. >>> >>> Oracle is also changing the version used internally, by updating >>> jib-profiles.js >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 >>> >>> /Erik >>> > From mikhailo.seledtsov at oracle.com Fri May 25 21:26:39 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 25 May 2018 14:26:39 -0700 Subject: RFR(L): 8199256: [TESTBUG] Open source VM testbase runtime tests Message-ID: <5B087F8F.2010407@oracle.com> Please review this change that will open source VM Testbase Runtime tests. This group includes tests covering a variety of runtime functional areas: arraycopy, barrier, jni, threads, vtable and contented. These tests have been used internally for a while, and are now being open sourced. Since this is not a creation of new tests, we would like to keep the changes during this review to a minimum required for open sourcing these tests, such as major issues and integration blockers. If you have other feedback regarding improvements to these tests, please file RFE(s), which will be addressed later in order of priority. Here is what was done for this change: 1. Moved the tests to OpenJDK repository preserving relative directory structure. 2. Updated Copyright statements accordingly. 3. Updated "@library" statements accordingly. 4. Updated TEST.groups and Problem List 5. Updated HotSpot test make file JBS: https://bugs.openjdk.java.net/browse/JDK-8199256 Webrev: http://cr.openjdk.java.net/~mseledtsov/8199256.01.open/ Testing: 1. Ran the following tests on open-only repository and build, using "make run-test" (Linux-x64) vmTestbase_vm_runtime All PASS 2. Automated multip-platform test system (usual 4 platforms): - vmTestbase_vm_runtime - hs-tier{1,2} In progress Thank you, Misha From erik.joelsson at oracle.com Fri May 25 21:33:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 25 May 2018 14:33:47 -0700 Subject: RFR(L): 8199256: [TESTBUG] Open source VM testbase runtime tests In-Reply-To: <5B087F8F.2010407@oracle.com> References: <5B087F8F.2010407@oracle.com> Message-ID: <8ff47df7-9102-c0ba-d0df-75332d571178@oracle.com> Build changes look good. /Erik On 2018-05-25 14:26, Mikhailo Seledtsov wrote: > Please review this change that will open source VM Testbase Runtime > tests. This group includes tests covering a variety of runtime > functional areas: arraycopy, barrier, jni, threads, vtable and contented. > > These tests have been used internally for a while, and are now being > open sourced. Since this is not a creation of new tests, we would like > to keep the changes during this review to a minimum required for open > sourcing these tests, such as major issues and integration blockers. > If you have other feedback regarding improvements to these tests, > please file RFE(s), which will be addressed later in order of priority. > > Here is what was done for this change: > ? 1. Moved the tests to OpenJDK repository preserving relative > directory structure. > ? 2. Updated Copyright statements accordingly. > ? 3. Updated "@library" statements accordingly. > ? 4. Updated TEST.groups and Problem List > ? 5. Updated HotSpot test make file > > ? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8199256 > ? Webrev: http://cr.openjdk.java.net/~mseledtsov/8199256.01.open/ > > ? Testing: > ????? 1. Ran the following tests on open-only repository and build, > using "make run-test" > ???????? (Linux-x64) > ???????? vmTestbase_vm_runtime > ???????? All PASS > > ????? 2. Automated multip-platform test system (usual 4 platforms): > ???????? - vmTestbase_vm_runtime > ???????? - hs-tier{1,2} > ???????? In progress > > Thank you, > Misha From christoph.langer at sap.com Mon May 28 12:38:41 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 May 2018 12:38:41 +0000 Subject: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) In-Reply-To: <5B00B8EF.8000208@oracle.com> References: <2a38f5ea83a74e0cad6a1d3b10b063a1@sap.com> <0cf8df6f-d5ad-9db2-8381-ccca9eaf6a5f@oracle.com> <6d6b9a02-3b81-6978-1104-c4b1c12f65a5@oracle.com> <3e96ae93f38a3cfbcb584cf106f5297f@linux.vnet.ibm.com> <5B00B8EF.8000208@oracle.com> Message-ID: <035faeb1c36543378ab06e6828e4f889@sap.com> Hi Phil, thanks for your review. I have incorporated your suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/ I'll run it through our internal testing and run a jdk-submit job with it. When all is green, I'll push it to jdk-client tomorrow. Best regards Christoph > -----Original Message----- > From: Philip Race [mailto:philip.race at oracle.com] > Sent: Sonntag, 20. Mai 2018 01:53 > To: Langer, Christoph > Cc: awt-dev at openjdk.java.net; Ichiroh Takiguchi > ; build-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: Re: RFR: 8201429: Support AIX Input Method Editor > (IME) for AWT Input Method Framework (IMF) > > I think I am 99% OK with this. > > In general I see what you are doing here and how you've presented the > webrev. > Treating even the new files as moved helps see the differences but it is > still > a challenge to follow all the moving pieces. > > So before we had just > > abstract class unix/X11InputMethod <- class unix/XInputMethod > > Now we have > > abstract class unix/X11InputMethodBase > > / \ > > / \ > > / \ > > / \ > > abstract class unix/X11InputMethod abstract class > aix/X11InputMethod > > \ / > \ / > \ / > class unix/XInputMethod > > > > I have submitted a build job with this patch to make sure it all builds > on Linux & Solaris .. > and it was all fine. > > But testing for this would have to be manual, and I don't have cycles > for that. > So I'll have to accept that the testing done by IBM was enough > > So only minor comments ... > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u > nix/classes/sun/awt/X11InputMethodBase.java.sdiff.html > > 730 case 0: //None of the value is set by Wnn > > "value is " -> "values are " ? > > > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u > nix/native/libawt_xawt/awt/awt_InputMethod.c.sdiff.html > > why did you move > > 26 #ifdef HEADLESS > 27 #error This file should not be included in headless library > 28 #endif > > > I think it should be first. It is also missing from the equivalent AIX file but that > is > up to you .. I really didn't look any further at the AIX files. > > .. and there seems no point to moving around some of the other includes > except to make the webrev harder to read :-) > > But good job cleaning up a lot of the formatting of the native code. > > -phil. > > > > > > On 5/18/18, 4:59 AM, Langer, Christoph wrote: > > Hi all, > > > > Here is an updated webrev: > > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ > > Can someone from the graphics/awt team please have a look at that > change? Especially checking that we don't break non-AIX platforms? Thanks > in advance. > > > > @Ichiroh: Thanks for your review and tests. Adressing your points: > > > >> resetCompositionState() was missing in > >> src/java.desktop/aix/classes/sun/awt/X11InputMethod.java > >> > ========================================================== > >> == > >> --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed > May > >> 09 09:05:32 2018 +0900 > >> +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon > >> May > >> 14 21:25:50 2018 +0900 > >> @@ -56,6 +56,21 @@ > >> } > >> > >> /** > >> + * Reset the composition state to the current composition state. > >> + */ > >> + protected void resetCompositionState() { > >> + if (compositionEnableSupported&& haveActiveClient()) { > >> + try { > >> + /* Restore the composition mode to the last saved > >> composition > >> + mode. */ > >> + setCompositionEnabled(savedCompositionState); > >> + } catch (UnsupportedOperationException e) { > >> + compositionEnableSupported = false; > >> + } > >> + } > >> + } > >> + > >> + /** > >> * Activate input method. > >> */ > >> public synchronized void activate() { > >> > ========================================================== > > Good catch. I've incorporated that in my new webrev. > > > >> Otherwise, > >> we could not find out any functional difference on Linux. > >> we could not find out any functional difference between our modified > code and your code on AIX. > >> > >> By code check, we found following difference. > >> > ========================================================== > >> == > >> --- a/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > >> Wed May 09 09:05:32 2018 +0900 > >> +++ b/src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c > >> Mon May 14 21:25:50 2018 +0900 > >> @@ -248,6 +248,10 @@ > >> "flushText", > >> "()V"); > >> JNU_CHECK_EXCEPTION_RETURN(env, NULL); > >> + if ((*env)->ExceptionOccurred(env)) { > >> + (*env)->ExceptionDescribe(env); > >> + (*env)->ExceptionClear(env); > >> + } > >> /* IMPORTANT: > >> The order of the following calls is critical since > >> "imInstance" may > >> point to the global reference itself, if > >> "freeX11InputMethodData" is called > >> > ========================================================== > >> > >> Did you remove this code intentionally ? > > Yes, I removed that one intentionally. There is no point in doing the > Exception check/clearing after a call to > JNU_CHECK_EXCEPTION_RETURN(env, NULL); > > > >> Otherwise, I think the other changes were acceptable. > > ? > > > > Thanks and Best regards > > Christoph > > From alexey.ivanov at oracle.com Tue May 29 12:27:12 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 29 May 2018 13:27:12 +0100 Subject: [8u-dev] RFA for JDK-8079788: Fix broken CL version detection in configure for some Visual Studio configurations Message-ID: <0364db56-a0e9-6037-de9b-0ba78c35b210@oracle.com> Hi, Could you please approve the following backport to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8079788 jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/rev/d57780478145 Code review: http://mail.openjdk.java.net/pipermail/build-dev/2016-August/017566.html The patch applies cleanly to jdk8u-dev; generated-configure.sh is regenerated. Webrev: http://cr.openjdk.java.net/~aivanov/8079788/jdk8/webrev.0/ I recently faced this issue, and configure for 8u cannot complete. It could be related to backporting of JDK-8042707. Thank you in advance. Regards, Alexey From erik.joelsson at oracle.com Tue May 29 14:13:00 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 May 2018 07:13:00 -0700 Subject: [8u-dev] RFA for JDK-8079788: Fix broken CL version detection in configure for some Visual Studio configurations In-Reply-To: <0364db56-a0e9-6037-de9b-0ba78c35b210@oracle.com> References: <0364db56-a0e9-6037-de9b-0ba78c35b210@oracle.com> Message-ID: <6449fd49-3afc-583e-12a9-31142915ea3f@oracle.com> Looks good (except for my spelling error in the comment "siutations". Not sure what the policy is for fixing such in backports.) /Erik On 2018-05-29 05:27, Alexey Ivanov wrote: > Hi, > > Could you please approve the following backport to 8u-dev? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8079788 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/rev/d57780478145 > Code review: > http://mail.openjdk.java.net/pipermail/build-dev/2016-August/017566.html > > The patch applies cleanly to jdk8u-dev; generated-configure.sh is > regenerated. > Webrev: http://cr.openjdk.java.net/~aivanov/8079788/jdk8/webrev.0/ > > I recently faced this issue, and configure for 8u cannot complete. It > could be related to backporting of JDK-8042707. > > Thank you in advance. > > Regards, > Alexey From alexey.ivanov at oracle.com Tue May 29 14:42:22 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 29 May 2018 15:42:22 +0100 Subject: [8u-dev] RFA for JDK-8079788: Fix broken CL version detection in configure for some Visual Studio configurations In-Reply-To: <6449fd49-3afc-583e-12a9-31142915ea3f@oracle.com> References: <0364db56-a0e9-6037-de9b-0ba78c35b210@oracle.com> <6449fd49-3afc-583e-12a9-31142915ea3f@oracle.com> Message-ID: <99eb231e-2430-b8f4-e273-a24345cdb331@oracle.com> I can fix it before pushing. Regards, Alexey On 29/05/2018 15:13, Erik Joelsson wrote: > Looks good (except for my spelling error in the comment "siutations". > Not sure what the policy is for fixing such in backports.) > > /Erik > > On 2018-05-29 05:27, Alexey Ivanov wrote: >> Hi, >> >> Could you please approve the following backport to 8u-dev? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8079788 >> jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/rev/d57780478145 >> Code review: >> http://mail.openjdk.java.net/pipermail/build-dev/2016-August/017566.html >> >> The patch applies cleanly to jdk8u-dev; generated-configure.sh is >> regenerated. >> Webrev: http://cr.openjdk.java.net/~aivanov/8079788/jdk8/webrev.0/ >> >> I recently faced this issue, and configure for 8u cannot complete. It >> could be related to backporting of JDK-8042707. >> >> Thank you in advance. >> >> Regards, >> Alexey > From erik.joelsson at oracle.com Tue May 29 17:54:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 May 2018 10:54:43 -0700 Subject: RFR: JDK-8203932: Windows devkit has wrong dlls in 32 bit tools dir Message-ID: <3e9ec10c-e4a5-1166-bcec-6d0089638396@oracle.com> The generator script for the new windows 2017 devkit has a bug. It puts the 64bit redistributable runtime libraries in the 32 bit tools dir. This causes the 32 bit tools to only work on machines with VS2017 already installed on them. This patch fixes the script to copy the correct DLLs. Bug: https://bugs.openjdk.java.net/browse/JDK-8203932 Webrev: http://cr.openjdk.java.net/~erikj/8203932/webrev.01/ /Erik From philip.race at oracle.com Tue May 29 17:58:19 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 29 May 2018 10:58:19 -0700 Subject: RFR: JDK-8203932: Windows devkit has wrong dlls in 32 bit tools dir In-Reply-To: <3e9ec10c-e4a5-1166-bcec-6d0089638396@oracle.com> References: <3e9ec10c-e4a5-1166-bcec-6d0089638396@oracle.com> Message-ID: Looks good. -phil. On 05/29/2018 10:54 AM, Erik Joelsson wrote: > The generator script for the new windows 2017 devkit has a bug. It > puts the 64bit redistributable runtime libraries in the 32 bit tools > dir. This causes the 32 bit tools to only work on machines with VS2017 > already installed on them. This patch fixes the script to copy the > correct DLLs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203932 > > Webrev: http://cr.openjdk.java.net/~erikj/8203932/webrev.01/ > > /Erik > From thomas.stuefe at gmail.com Tue May 29 18:49:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 May 2018 20:49:12 +0200 Subject: RFR: JDK-8203932: Windows devkit has wrong dlls in 32 bit tools dir In-Reply-To: <3e9ec10c-e4a5-1166-bcec-6d0089638396@oracle.com> References: <3e9ec10c-e4a5-1166-bcec-6d0089638396@oracle.com> Message-ID: Looks good. ..Thomas On Tue, May 29, 2018 at 7:54 PM, Erik Joelsson wrote: > The generator script for the new windows 2017 devkit has a bug. It puts the > 64bit redistributable runtime libraries in the 32 bit tools dir. This causes > the 32 bit tools to only work on machines with VS2017 already installed on > them. This patch fixes the script to copy the correct DLLs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203932 > > Webrev: http://cr.openjdk.java.net/~erikj/8203932/webrev.01/ > > /Erik > From tim.bell at oracle.com Tue May 29 18:50:43 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 29 May 2018 11:50:43 -0700 Subject: RFR: JDK-8203932: Windows devkit has wrong dlls in 32 bit tools dir In-Reply-To: References: <3e9ec10c-e4a5-1166-bcec-6d0089638396@oracle.com> Message-ID: <5B0DA103.10705@oracle.com> Erik: Looks good to me as well. /Tim On 05/29/18 10:58, Phil Race wrote: > Looks good. > > -phil. > > On 05/29/2018 10:54 AM, Erik Joelsson wrote: >> The generator script for the new windows 2017 devkit has a bug. It >> puts the 64bit redistributable runtime libraries in the 32 bit tools >> dir. This causes the 32 bit tools to only work on machines with VS2017 >> already installed on them. This patch fixes the script to copy the >> correct DLLs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203932 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8203932/webrev.01/ >> >> /Erik >> > From erik.joelsson at oracle.com Tue May 29 21:08:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 May 2018 14:08:41 -0700 Subject: RFR: JDK-8203945: Cleanup nashorn build Message-ID: <46acdea0-a319-23b0-b4b1-8965c942f4db@oracle.com> The nashorn module requires some special handling when being built. Because of this, it's not currently compiled like the other modules, in CompileJavaModules.gmk, but instead in a separate BuildNashorn.gmk. While nashorn still needs some special treatment, because of the nasgen tool, this can be reduced quite a bit. This patch reduces (and renames) BuildNashorn.gmk to only be about running nasgen and include that file conditionally from CompileJavaModules.gmk. That way the nashorn classes will be compiled using the same configuration as any other module. Bug: https://bugs.openjdk.java.net/browse/JDK-8203945 Webrev: http://cr.openjdk.java.net/~erikj/8203945/webrev.01/index.html /Erik From erik.joelsson at oracle.com Tue May 29 22:49:47 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 29 May 2018 15:49:47 -0700 Subject: RFR: JDK-8203946: Move UnpackSecurity.gmk to closed Message-ID: <963c5685-1f5e-ba47-7aa1-e24a97600c15@oracle.com> The UnpackSecurity.gmk build logic has never belonged in OpenJDK and should be moved to Oracle's internal makefiles. Bug: https://bugs.openjdk.java.net/browse/JDK-8203946 Webrev: http://cr.openjdk.java.net/~erikj/8203946/webrev.01/ /Erik From tim.bell at oracle.com Tue May 29 23:45:26 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 29 May 2018 16:45:26 -0700 Subject: RFR: JDK-8203945: Cleanup nashorn build In-Reply-To: <46acdea0-a319-23b0-b4b1-8965c942f4db@oracle.com> References: <46acdea0-a319-23b0-b4b1-8965c942f4db@oracle.com> Message-ID: <5B0DE616.6030602@oracle.com> Erik: > The nashorn module requires some special handling when being built. > Because of this, it's not currently compiled like the other modules, in > CompileJavaModules.gmk, but instead in a separate BuildNashorn.gmk. > While nashorn still needs some special treatment, because of the nasgen > tool, this can be reduced quite a bit. > > This patch reduces (and renames) BuildNashorn.gmk to only be about > running nasgen and include that file conditionally from > CompileJavaModules.gmk. That way the nashorn classes will be compiled > using the same configuration as any other module. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203945 > > Webrev: http://cr.openjdk.java.net/~erikj/8203945/webrev.01/index.html Looks good. /Tim From tim.bell at oracle.com Tue May 29 23:50:00 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 29 May 2018 16:50:00 -0700 Subject: RFR: JDK-8203946: Move UnpackSecurity.gmk to closed In-Reply-To: <963c5685-1f5e-ba47-7aa1-e24a97600c15@oracle.com> References: <963c5685-1f5e-ba47-7aa1-e24a97600c15@oracle.com> Message-ID: <5B0DE728.8090508@oracle.com> Erik: > The UnpackSecurity.gmk build logic has never belonged in OpenJDK and > should be moved to Oracle's internal makefiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203946 > > Webrev: http://cr.openjdk.java.net/~erikj/8203946/webrev.01/ Looks good. /Tim From aoqi at loongson.cn Wed May 30 06:13:24 2018 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 30 May 2018 14:13:24 +0800 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: <1a32aeb8-b1a9-cf66-ac12-342f10016db1@oracle.com> References: <1a32aeb8-b1a9-cf66-ac12-342f10016db1@oracle.com> Message-ID: Could someone help to create a bug etc? Thanks, Ao Qi Magnus Ihse Bursie ?2018?5?25??? ?? 3:42??? > On 2018-05-24 03:08, Ao Qi wrote: > Hi Erik, > Thanks for your comments. I made a new patch: > $ hg diff > diff -r 31361382634b make/autoconf/build-aux/config.guess > --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700 > +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800 > @@ -86,6 +86,17 @@ > fi > fi > +# Test and fix little endian MIPS. > +if [ "x$OUT" = x ]; then > + if [ `uname -s` = Linux ]; then > + if [ `uname -m` = mipsel ]; then > + OUT=mipsel-unknown-linux-gnu > + elif [ `uname -m` = mips64el ]; then > + OUT=mips64el-unknown-linux-gnu > + fi > + fi > +fi > + > # Test and fix cpu on Macosx when C preprocessor is not on the path > echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null > if test $? = 0; then > Looks good to me. > /Magnus > Cheers, > Ao Qi > 2018-05-24 0:19 GMT+08:00 Erik Joelsson : > Hello Ao Qi, > Due to licensing reasons, we are unable to directly update the > autoconf-config.guess file. Instead we have the wrapper, config.guess in > which we make adjustments to the result returned by autoconf-config.guess. > Your fix needs to go in the wrapper file. > /Erik > On 2018-05-23 03:18, Ao Qi wrote: > Hi all, > I tried to configure jdk/jdk on MIPS, but I failed. The output of > configure: > ... > checking for pandoc... no > checking build system type... > /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable > to guess system type > This script, last modified 2012-02-10, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > If the version you run > (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is > already up to date, please > send the following data and any information you think might be > pertinent to in order to provide the needed > information to handle your system. > config.guess timestamp = 2012-02-10 > uname -m = mips64el > uname -r = 3.10.0-693.5.2.ns7.032.mips64el > uname -s = Linux > uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 > /usr/bin/uname -p = mips64el > /bin/uname -X = > hostinfo = > /bin/universe = > /usr/bin/arch -k = > /bin/arch = mips64el > /usr/bin/oslevel = > /usr/convex/getsysinfo = > UNAME_MACHINE = mips64el > UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el > UNAME_SYSTEM = Linux > UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 > configure: error: cannot guess build type; you must specify one > configure exiting with result code 1 > ... > I think the reason is that uname returns mips64el. > autoconf-config.guess can handle mips and mips64, but cannot handle > mipsel and mips64el. > I made a patch to pass the configure: > $ hg diff > diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess > --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 > 10:08:04 2018 -0700 > +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 > 18:06:52 2018 +0800 > @@ -977,6 +977,9 @@ > eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` > test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } > ;; > + mipsel:Linux:*:* | mips64el:Linux:*:*) > + echo ${UNAME_MACHINE}-unknown-linux-gnu > + exit ;; > or32:Linux:*:*) > echo ${UNAME_MACHINE}-unknown-linux-gnu > exit ;; > I think ppc has the same problem, but it is fixed in > make/autoconf/build-aux/config.guess. > Thanks, > Ao Qi From david.buck at oracle.com Wed May 30 07:13:57 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 30 May 2018 16:13:57 +0900 Subject: [8] RFR(XXS) 8203845: backport of JDK-8034788 inadvertently rolled back JDK-8187045 changes to toolchain.m4 Message-ID: <43a8929f-4c42-6cd6-1e18-a1f870497a7f@oracle.com> Hi! Please review this very simple fix. The backport for JDK-8034788 [0] did a lot of refactoring and moved the some code from toolchain.m4 to flags.m4. Unfortunately, it also unintentionally rolled back my backport of JDK-8187045 [1] when it moved this chunk of code. As a result, this is only an issue in JDK 8. All I did in this fix was reapply the same change that I had previously made to toolchain.m4 for JDK- 8187045 [2], but to flags.m4 where the relevant code now lives. bug report: https://bugs.openjdk.java.net/browse/JDK-8203845 webrev: http://cr.openjdk.java.net/~dbuck/8203845.0/ Everything has been built and tested (JPRT, manual confirmation of fix). Of course I will also push the closed source version of generated-configure.sh with this fix. Cheers, -Buck [0] https://bugs.openjdk.java.net/browse/JDK-8034788 [1] https://bugs.openjdk.java.net/browse/JDK-8187045 [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/c0b1ccecf70f From sgehwolf at redhat.com Wed May 30 09:15:30 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 May 2018 11:15:30 +0200 Subject: 8203924: Zero: bootcycle-images build fails on x86_64 Message-ID: <4bbfd2355caddc3c67b32d1f51b13d4875208e16.camel@redhat.com> Hi, Could I please get a review of this one-liner fix for a bootcycle- images build of the Zero variant (on x86_64)? The proposed change is to use the big java settings (over small) for the jdk.compiler's annotation processing. Thoughts? diff --git a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk --- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk +++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk @@ -103,7 +103,7 @@ $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) $(call MakeDir, $(@D)) $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) - $(JAVA_SMALL) $(NEW_JAVAC) \ + $(JAVA) $(NEW_JAVAC) \ -XDignore.symbol.file \ --upgrade-module-path $(JDK_OUTPUTDIR)/modules --system none \ $(ADD_EXPORTS) \ Bug: https://bugs.openjdk.java.net/browse/JDK-8203924 Testing: Zero linux-x86_64 bootcycle-images builds post-patch. Fails before. Thanks, Severin From david.holmes at oracle.com Wed May 30 10:00:22 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 May 2018 20:00:22 +1000 Subject: 8203924: Zero: bootcycle-images build fails on x86_64 In-Reply-To: <4bbfd2355caddc3c67b32d1f51b13d4875208e16.camel@redhat.com> References: <4bbfd2355caddc3c67b32d1f51b13d4875208e16.camel@redhat.com> Message-ID: <73b64f8a-4246-10e7-a69b-9297cbbdee3d@oracle.com> Hi Severin, On 30/05/2018 7:15 PM, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this one-liner fix for a bootcycle- > images build of the Zero variant (on x86_64)? The proposed change is to > use the big java settings (over small) for the jdk.compiler's > annotation processing. Thoughts? We set a number of the build steps to use "small Java" because we ran into memory problems with high concurrency builds. I'm unclear what impact this change has overall. Eril or Magnus should be clearer on that. Thanks, David > diff --git a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > --- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > +++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > @@ -103,7 +103,7 @@ > $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) > $(call MakeDir, $(@D)) > $(eval $(call ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) > - $(JAVA_SMALL) $(NEW_JAVAC) \ > + $(JAVA) $(NEW_JAVAC) \ > -XDignore.symbol.file \ > --upgrade-module-path $(JDK_OUTPUTDIR)/modules --system none \ > $(ADD_EXPORTS) \ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203924 > > Testing: Zero linux-x86_64 bootcycle-images builds post-patch. Fails before. > > Thanks, > Severin > From tim.bell at oracle.com Wed May 30 15:28:21 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 30 May 2018 08:28:21 -0700 Subject: [8] RFR(XXS) 8203845: backport of JDK-8034788 inadvertently rolled back JDK-8187045 changes to toolchain.m4 In-Reply-To: <43a8929f-4c42-6cd6-1e18-a1f870497a7f@oracle.com> References: <43a8929f-4c42-6cd6-1e18-a1f870497a7f@oracle.com> Message-ID: <5B0EC315.50209@oracle.com> Hello Looks good. /Tim On 05/30/18 00:13, David Buck wrote: > Hi! > > Please review this very simple fix. The backport for JDK-8034788 [0] did > a lot of refactoring and moved the some code from toolchain.m4 to > flags.m4. Unfortunately, it also unintentionally rolled back my backport > of JDK-8187045 [1] when it moved this chunk of code. As a result, this > is only an issue in JDK 8. > > All I did in this fix was reapply the same change that I had previously > made to toolchain.m4 for JDK- 8187045 [2], but to flags.m4 where the > relevant code now lives. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8203845 > > webrev: > http://cr.openjdk.java.net/~dbuck/8203845.0/ > > Everything has been built and tested (JPRT, manual confirmation of fix). > Of course I will also push the closed source version of > generated-configure.sh with this fix. > > Cheers, > -Buck > > [0] https://bugs.openjdk.java.net/browse/JDK-8034788 > [1] https://bugs.openjdk.java.net/browse/JDK-8187045 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/c0b1ccecf70f > From adam.farley at uk.ibm.com Wed May 30 16:08:08 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 30 May 2018 17:08:08 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c Message-ID: Hi Phil, I spoke with the jpegclub rep "Guido", and he was very helpful. He agreed to accept a code change, but recommended an error instead of a while check. ------------------------------ Line 808: < while (bits[j] == 0) < j--; --- > while (bits[j] == 0) { > if (j == 0) > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > j--; > } ------------------------------ This makes sense to me, and I verified that it prevents the error. He says: @@@@@@@@@@@@ For the release version I would replace the specific JERR_HUFF_CLEN_OVERFLOW by the more general JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this requires a change in jerror.h: -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out of bounds") The next version (9d) is planned for release in January 2020. A pre-release package will be provided in 2019 on http://jpegclub.org/reference/reference-sources/, I will send you a notification. @@@@@@@@@@@@ While we *could* make the jerror.h change, I suggest we don't for now. If we merge from upstream in January 2020, we'll get that change anyway when the time comes. So what do you say to including the dashed change referenced above to fix our problem now, safe in the knowledge that upstream will be similarly modified (except with the new error type). Best Regards Adam Farley P.S. I'm holding off on giving Guido the green light until after people say if they're happy with the error-enabled version of the fix. Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > From: Adam Farley8/UK/IBM > To: Phil Race > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > , build-dev dev at openjdk.java.net>, Magnus Ihse Bursie > , "Thomas St?fe" > Date: 14/05/2018 11:06 > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > compile warning in jchuff.c > > Hi Phil, > > Would an acceptable compromise be to deliver the source code change > and send the code to the upstream community, allowing them to include > the fix if/when they are able? > > I believe Magnus was advocating this idea as well. See below. > > Best Regards > > Adam Farley > > > Same here. I would like to have this fix in, but do not want to go > > over Phils head. > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > Thanks, Thomas > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > wrote: > > > I don't object, but it's not build code so I don't have the final say. > > > > > > /Magnus > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > Hi All, > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > It doesn't break anything, it fixes a build break on two supported > > > platforms, and it seems > > > like we never refresh the code from upstream. > > > > > > - Adam > > > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > > >> of logic required > > >> to properly analyse the toolchain version string. > > >> > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > > >> and Make doesn't > > >> seem to do substring stuff unless you mess around with shells. > > >> > > >> Plus, as people have said, it's better to solve problem x (or work around > > >> a specific > > >> instance of x) than to ignore the exception, even if the ignoring code is > > >> toolchain- > > >> specific. > > >> > > >> - Adam Farley > > >> > > >> > On 2018-03-27 18:44, Phil Race wrote: > > >> > > > >> >> As I said I prefer the make file change, since this is a change to an > > >> >> upstream library. > > >> > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > >> > reviewer. :) > > >> > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > >> > complaint seems reasonable, and disabling it might cause us > to miss other > > >> > future errors. > > >> > > > >> > Why can't we push the source code fix, and also submit it upstream? > > >> > > > >> > /Magnus > > >> > > > >> > > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > > >> > 6b, so this code > > >> > seems to have stood the test of time. I'm also unclear why the compiler > > >> > would > > >> > complain about that and not the one a few lines later > > >> > > > >> > > > >> > 819 while (bits[i] == 0) /* find largest > codelength still in > > >> > use */ > > >> > 820 i--; > > >> > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > >> > A tool-chain specific fix in the makefile with an appropriatecomment is > > >> > more targeted. > > >> > > >> Phil, > > >> > > >> Returning to this. > > >> > > >> While I understand your reluctance to patch upstream code, let me point > > >> out that we have not updated libjpeg a single time since the JDK was open > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > Wikipedia page > > >> on libjpeg, and this is the latest "uncontroversial" version of > the source. > > >> Versions 7 and up have proprietary extensions, which in turn > has resulted in > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > we will ever > > >> replace libjpeg 6b with a simple upgrade from upstream. > > >> > > >> I therefore maintain my position that a source code fix would be the best > > >> way forward here. > > >> > > >> /Magnus > > >> > > >> > > > >> > > > >> > -phil. > > >> > > > >> > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > just a friendly reminder. I would like to push this tiny fix because > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > >> > maintain patch queues, but this is a constant error source). > > >> > > > >> > > > >> > I will wait for 24 more hours until a reaction. If no seriousobjections > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > me and Christoph > > >> > langer are both Reviewers). > > >> > > > >> > > > >> > Thanks! Thomas > > >> > > > >> > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > >> > wrote: > > >> > > > >> > Hi all, > > >> > > > >> > > > >> > may I please have another review for this really trivial change. It > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > good idea to fix > > >> > this. > > >> > > > >> > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > >> > webrev: > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > warning-in-jchuff.c/webrev.00/webrev/ > > >> > > > >> > > > >> > This was contributed by Adam Farley at IBM. > > >> > > > >> > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > >> > > > >> > > > >> > Thanks, Thomas > > >> > > > >> > > >> Unless stated otherwise above: > > >> IBM United Kingdom Limited - Registered in England and Wales with number > > >> 741598. > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > >> > > >> > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From erik.joelsson at oracle.com Wed May 30 16:09:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 May 2018 09:09:31 -0700 Subject: 8203924: Zero: bootcycle-images build fails on x86_64 In-Reply-To: <73b64f8a-4246-10e7-a69b-9297cbbdee3d@oracle.com> References: <4bbfd2355caddc3c67b32d1f51b13d4875208e16.camel@redhat.com> <73b64f8a-4246-10e7-a69b-9297cbbdee3d@oracle.com> Message-ID: <315d814e-bcff-0a9a-97c7-74a9444f147c@oracle.com> Hello, On 2018-05-30 03:00, David Holmes wrote: > Hi Severin, > > On 30/05/2018 7:15 PM, Severin Gehwolf wrote: >> Hi, >> >> Could I please get a review of this one-liner fix for a bootcycle- >> images build of the Zero variant (on x86_64)? The proposed change is to >> use the big java settings (over small) for the jdk.compiler's >> annotation processing. Thoughts? > > We set a number of the build steps to use "small Java" because we ran > into memory problems with high concurrency builds. I'm unclear what > impact this change has overall. Eril or Magnus should be clearer on that. > I think this is a reasonable change. It won't have a big impact since it's only one process in the whole build. The big impact is mostly seen when changing JVM sizing on many JVMs that tend to all run at the same time. So, looks good. /Erik > Thanks, > David > >> diff --git a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk >> b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk >> --- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk >> +++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk >> @@ -103,7 +103,7 @@ >> ? $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) >> ???????? $(call MakeDir, $(@D)) >> ???????? $(eval $(call >> ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) >> -?????? $(JAVA_SMALL) $(NEW_JAVAC) \ >> +?????? $(JAVA) $(NEW_JAVAC) \ >> ???????????? -XDignore.symbol.file \ >> ???????????? --upgrade-module-path $(JDK_OUTPUTDIR)/modules --system >> none \ >> ???????????? $(ADD_EXPORTS) \ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8203924 >> >> Testing: Zero linux-x86_64 bootcycle-images builds post-patch. Fails >> before. >> >> Thanks, >> Severin >> From erik.joelsson at oracle.com Wed May 30 16:11:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 May 2018 09:11:32 -0700 Subject: [8] RFR(XXS) 8203845: backport of JDK-8034788 inadvertently rolled back JDK-8187045 changes to toolchain.m4 In-Reply-To: <43a8929f-4c42-6cd6-1e18-a1f870497a7f@oracle.com> References: <43a8929f-4c42-6cd6-1e18-a1f870497a7f@oracle.com> Message-ID: Looks good. /Erik On 2018-05-30 00:13, David Buck wrote: > Hi! > > Please review this very simple fix. The backport for JDK-8034788 [0] > did a lot of refactoring and moved the some code from toolchain.m4 to > flags.m4. Unfortunately, it also unintentionally rolled back my > backport of JDK-8187045 [1] when it moved this chunk of code. As a > result, this is only an issue in JDK 8. > > All I did in this fix was reapply the same change that I had > previously made to toolchain.m4 for JDK- 8187045 [2], but to flags.m4 > where the relevant code now lives. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8203845 > > webrev: > http://cr.openjdk.java.net/~dbuck/8203845.0/ > > Everything has been built and tested (JPRT, manual confirmation of > fix). Of course I will also push the closed source version of > generated-configure.sh with this fix. > > Cheers, > -Buck > > [0] https://bugs.openjdk.java.net/browse/JDK-8034788 > [1] https://bugs.openjdk.java.net/browse/JDK-8187045 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/c0b1ccecf70f > From erik.joelsson at oracle.com Wed May 30 16:39:29 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 May 2018 09:39:29 -0700 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: References: <1a32aeb8-b1a9-cf66-ac12-342f10016db1@oracle.com> Message-ID: <24f174ce-2157-2649-847e-001cb935a9f2@oracle.com> I'll sponsor it. /Erik On 2018-05-29 23:13, Ao Qi wrote: > Could someone help to create a bug etc? > > Thanks, > Ao Qi > Magnus Ihse Bursie ?2018?5?25??? ?? > 3:42??? > >> On 2018-05-24 03:08, Ao Qi wrote: >> Hi Erik, >> Thanks for your comments. I made a new patch: >> $ hg diff >> diff -r 31361382634b make/autoconf/build-aux/config.guess >> --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700 >> +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800 >> @@ -86,6 +86,17 @@ >> fi >> fi >> +# Test and fix little endian MIPS. >> +if [ "x$OUT" = x ]; then >> + if [ `uname -s` = Linux ]; then >> + if [ `uname -m` = mipsel ]; then >> + OUT=mipsel-unknown-linux-gnu >> + elif [ `uname -m` = mips64el ]; then >> + OUT=mips64el-unknown-linux-gnu >> + fi >> + fi >> +fi >> + >> # Test and fix cpu on Macosx when C preprocessor is not on the path >> echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null >> if test $? = 0; then > >> Looks good to me. >> /Magnus >> Cheers, >> Ao Qi >> 2018-05-24 0:19 GMT+08:00 Erik Joelsson : >> Hello Ao Qi, >> Due to licensing reasons, we are unable to directly update the >> autoconf-config.guess file. Instead we have the wrapper, config.guess in >> which we make adjustments to the result returned by autoconf-config.guess. >> Your fix needs to go in the wrapper file. >> /Erik > > >> On 2018-05-23 03:18, Ao Qi wrote: >> Hi all, >> I tried to configure jdk/jdk on MIPS, but I failed. The output of >> configure: >> ... >> checking for pandoc... no >> checking build system type... >> /home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable >> to guess system type >> This script, last modified 2012-02-10, has failed to recognize >> the operating system you are using. It is advised that you >> download the most up to date version of the config scripts from > > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >> and > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > >> If the version you run >> (/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is >> already up to date, please >> send the following data and any information you think might be >> pertinent to in order to provide the needed >> information to handle your system. >> config.guess timestamp = 2012-02-10 >> uname -m = mips64el >> uname -r = 3.10.0-693.5.2.ns7.032.mips64el >> uname -s = Linux >> uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >> /usr/bin/uname -p = mips64el >> /bin/uname -X = >> hostinfo = >> /bin/universe = >> /usr/bin/arch -k = >> /bin/arch = mips64el >> /usr/bin/oslevel = >> /usr/convex/getsysinfo = >> UNAME_MACHINE = mips64el >> UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el >> UNAME_SYSTEM = Linux >> UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017 >> configure: error: cannot guess build type; you must specify one >> configure exiting with result code 1 >> ... >> I think the reason is that uname returns mips64el. >> autoconf-config.guess can handle mips and mips64, but cannot handle >> mipsel and mips64el. >> I made a patch to pass the configure: >> $ hg diff >> diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess >> --- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22 >> 10:08:04 2018 -0700 >> +++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23 >> 18:06:52 2018 +0800 >> @@ -977,6 +977,9 @@ >> eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'` >> test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; } >> ;; >> + mipsel:Linux:*:* | mips64el:Linux:*:*) >> + echo ${UNAME_MACHINE}-unknown-linux-gnu >> + exit ;; >> or32:Linux:*:*) >> echo ${UNAME_MACHINE}-unknown-linux-gnu >> exit ;; > >> I think ppc has the same problem, but it is fixed in >> make/autoconf/build-aux/config.guess. >> Thanks, >> Ao Qi From sgehwolf at redhat.com Wed May 30 16:45:01 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 May 2018 18:45:01 +0200 Subject: 8203924: Zero: bootcycle-images build fails on x86_64 In-Reply-To: <315d814e-bcff-0a9a-97c7-74a9444f147c@oracle.com> References: <4bbfd2355caddc3c67b32d1f51b13d4875208e16.camel@redhat.com> <73b64f8a-4246-10e7-a69b-9297cbbdee3d@oracle.com> <315d814e-bcff-0a9a-97c7-74a9444f147c@oracle.com> Message-ID: <1f9ed8165c2e96f85d28bdf7fec698b63481b65f.camel@redhat.com> Hi Erik, On Wed, 2018-05-30 at 09:09 -0700, Erik Joelsson wrote: > Hello, > > On 2018-05-30 03:00, David Holmes wrote: > > Hi Severin, > > > > On 30/05/2018 7:15 PM, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get a review of this one-liner fix for a bootcycle- > > > images build of the Zero variant (on x86_64)? The proposed change is to > > > use the big java settings (over small) for the jdk.compiler's > > > annotation processing. Thoughts? > > > > We set a number of the build steps to use "small Java" because we ran > > into memory problems with high concurrency builds. I'm unclear what > > impact this change has overall. Eril or Magnus should be clearer on that. > > > > I think this is a reasonable change. It won't have a big impact since > it's only one process in the whole build. The big impact is mostly seen > when changing JVM sizing on many JVMs that tend to all run at the same time. > > So, looks good. Thanks a lot for the review, Erik! I'll get this through jdk-submit and push if it comes back clean. Cheers, Severin > > Thanks, > > David > > > > > diff --git a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > > > b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > > > --- a/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > > > +++ b/make/gensrc/Gensrc-jdk.internal.vm.compiler.gmk > > > @@ -103,7 +103,7 @@ > > > $(GENSRC_DIR)/_gensrc_proc_done: $(PROC_SRCS) $(PROCESSOR_JARS) > > > $(call MakeDir, $(@D)) > > > $(eval $(call > > > ListPathsSafely,PROC_SRCS,$(@D)/_gensrc_proc_files)) > > > - $(JAVA_SMALL) $(NEW_JAVAC) \ > > > + $(JAVA) $(NEW_JAVAC) \ > > > -XDignore.symbol.file \ > > > --upgrade-module-path $(JDK_OUTPUTDIR)/modules --system > > > none \ > > > $(ADD_EXPORTS) \ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203924 > > > > > > Testing: Zero linux-x86_64 bootcycle-images builds post-patch. Fails > > > before. > > > > > > Thanks, > > > Severin > > > > > From philip.race at oracle.com Wed May 30 17:06:19 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 30 May 2018 10:06:19 -0700 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: Message-ID: <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com> Thank you for persevering with this. Please submit a webrev with this change .. I think you can leave out the change to jerror.h in the jpeg6b case. -phil. On 05/30/2018 09:08 AM, Adam Farley8 wrote: > Hi Phil, > > I spoke with the jpegclub rep "Guido", and he was very helpful. > > He agreed to accept a code change, but recommended an error instead of > a while check. > > ------------------------------ Line 808: > < while (bits[j] == 0) > < j--; > --- > > while (bits[j] == 0) { > > if (j == 0) > > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > > j--; > > } > ------------------------------ > > This makes sense to me, and I verified that it prevents the error. > > He says: > @@@@@@@@@@@@ > For the release version I would replace the specific > JERR_HUFF_CLEN_OVERFLOW by the more general JERR_HUFF_CLEN_OUTOFBOUNDS > so that it suits both cases, this requires a change in jerror.h: > > -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") > +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out of > bounds") > > The next version (9d) is planned for release in January 2020. > A pre-release package will be provided in 2019 on > _http://jpegclub.org/reference/reference-sources/_, I will send you a > notification. > @@@@@@@@@@@@ > > While we *could* make the jerror.h change, I suggest we don't for now. > If we merge from upstream in January 2020, we'll get that change > anyway when the time comes. > > So what do you say to including the dashed change referenced above to > fix our problem now, safe in the knowledge that upstream will be > similarly modified (except with the new error type). > > Best Regards > > Adam Farley > > P.S. I'm holding off on giving Guido the green light until after > people say if they're happy with the error-enabled version of the fix. > > Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > > > From: Adam Farley8/UK/IBM > > To: Phil Race > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > , build-dev > dev at openjdk.java.net>, Magnus Ihse Bursie > > , "Thomas St?fe" > > > Date: 14/05/2018 11:06 > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > compile warning in jchuff.c > > > > Hi Phil, > > > > Would an acceptable compromise be to deliver the source code change > > and send the code to the upstream community, allowing them to include > > the fix if/when they are able? > > > > I believe Magnus was advocating this idea as well. See below. > > > > Best Regards > > > > Adam Farley > > > > > Same here. I would like to have this fix in, but do not want to go > > > over Phils head. > > > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > > > Thanks, Thomas > > > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > > wrote: > > > > I don't object, but it's not build code so I don't have the final say. > > > > > > > > /Magnus > > > > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > > > Hi All, > > > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > > > It doesn't break anything, it fixes a build break on two supported > > > > platforms, and it seems > > > > like we never refresh the code from upstream. > > > > > > > > - Adam > > > > > > > >> I also advocate the source code fix, as Make isn't meant to use the sort > > > >> of logic required > > > >> to properly analyse the toolchain version string. > > > >> > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, > > > >> and Make doesn't > > > >> seem to do substring stuff unless you mess around with shells. > > > >> > > > >> Plus, as people have said, it's better to solve problem x (or work around > > > >> a specific > > > >> instance of x) than to ignore the exception, even if the ignoring code is > > > >> toolchain- > > > >> specific. > > > >> > > > >> - Adam Farley > > > >> > > > >> > On 2018-03-27 18:44, Phil Race wrote: > > > >> > > > > >> >> As I said I prefer the make file change, since this is a change to an > > > >> >> upstream library. > > > >> > > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > > >> > reviewer. :) > > > >> > > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > > >> > complaint seems reasonable, and disabling it might cause us > > to miss other > > > >> > future errors. > > > >> > > > > >> > Why can't we push the source code fix, and also submit it upstream? > > > >> > > > > >> > /Magnus > > > >> > > > > >> > > > > >> > I've looked at jpeg-9c and it still looks identical to what we have in > > > >> > 6b, so this code > > > >> > seems to have stood the test of time. I'm also unclear why the compiler > > > >> > would > > > >> > complain about that and not the one a few lines later > > > >> > > > > >> > > > > >> > 819 while (bits[i] == 0) /* find largest > > codelength still in > > > >> > use */ > > > >> > 820 i--; > > > >> > > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > > >> > A tool-chain specific fix in the makefile with an appropriatecomment is > > > >> > more targeted. > > > >> > > > >> Phil, > > > >> > > > >> Returning to this. > > > >> > > > >> While I understand your reluctance to patch upstream code, let me point > > > >> out that we have not updated libjpeg a single time since the JDK was open > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > > Wikipedia page > > > >> on libjpeg, and this is the latest "uncontroversial" version of > > the source. > > > >> Versions 7 and up have proprietary extensions, which in turn > > has resulted in > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > > we will ever > > > >> replace libjpeg 6b with a simple upgrade from upstream. > > > >> > > > >> I therefore maintain my position that a source code fix would be the best > > > >> way forward here. > > > >> > > > >> /Magnus > > > >> > > > >> > > > > >> > > > > >> > -phil. > > > >> > > > > >> > > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > >> > > > > >> > Hi all, > > > >> > > > > >> > > > > >> > just a friendly reminder. I would like to push this tiny fix because > > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > > >> > maintain patch queues, but this is a constant error source). > > > >> > > > > >> > > > > >> > I will wait for 24 more hours until a reaction. If no seriousobjections > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > > me and Christoph > > > >> > langer are both Reviewers). > > > >> > > > > >> > > > > >> > Thanks! Thomas > > > >> > > > > >> > > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > >> > wrote: > > > >> > > > > >> > Hi all, > > > >> > > > > >> > > > > >> > may I please have another review for this really trivial change. It > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > > good idea to fix > > > >> > this. > > > >> > > > > >> > > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > > >> > webrev: > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > > > warning-in-jchuff.c/webrev.00/webrev/ > > > >> > > > > >> > > > > >> > This was contributed by Adam Farley at IBM. > > > >> > > > > >> > > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > > >> > > > > >> > > > > >> > Thanks, Thomas > > > >> > > > > >> > > > >> Unless stated otherwise above: > > > >> IBM United Kingdom Limited - Registered in England and Wales with number > > > >> 741598. > > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > >> > > > >> > > > > > > > > Unless stated otherwise above: > > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > > 741598. > > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jonathan.gibbons at oracle.com Wed May 30 19:00:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 May 2018 12:00:20 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5ACFBE5C.1080508@oracle.com> References: <5ACFBE5C.1080508@oracle.com> Message-ID: <5B0EF4C4.9050501@oracle.com> Please review a minor update to the proposed implementation of JEP 330. The primary change is to disallow the use of the "shebang" feature in Java source files (i.e. files whose name ends in ".java") as recently proposed on this list [1]. There is some additional minor cleanup to the launcher -help text. In the webrev, the overall changes can be seen in the main webrev index. The recent changes can be see in the delta-webrev named "v3" in the main webrev index page. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/ -- Jon [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: > Please review an initial implementation for the feature described in > JEP 330: Launch Single-File Source-Code Programs. > > The work is described in the JEP and CSR, and falls into various parts: > > * The part to handle the new command-line options is in the native > Java launcher code. > * The part to invoke the compiler and subsequently execute the code > found in the source file is in a new class in the jdk.compiler module. > * There are some minor Makefile changes, to add support for a new > resource file. > > There are no changes to javac itself. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ > > -- Jon From mandy.chung at oracle.com Wed May 30 20:31:57 2018 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 30 May 2018 13:31:57 -0700 Subject: RFR: 8201274: Launch Single-File Source-Code Programs In-Reply-To: <5B0EF4C4.9050501@oracle.com> References: <5ACFBE5C.1080508@oracle.com> <5B0EF4C4.9050501@oracle.com> Message-ID: I reviewed the delta-webrev (v3). Looks good. Thanks for fixing missing newlines in launcher.properties Mandy On 5/30/18 12:00 PM, Jonathan Gibbons wrote: > Please review a minor update to the proposed implementation of JEP 330. > > The primary change is to disallow the use of the "shebang" feature in > Java source files > (i.e. files whose name ends in ".java") as recently proposed on this > list [1]. > > There is some additional minor cleanup to the launcher -help text. > > In the webrev, the overall changes can be seen in the main webrev index. > The recent changes can be see in the delta-webrev named "v3" in the main > webrev index page. > > JEP: http://openjdk.java.net/jeps/330 > JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 > CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 > Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.mq/ > > -- Jon > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html > > On 04/12/2018 01:15 PM, Jonathan Gibbons wrote: >> Please review an initial implementation for the feature described in >> JEP 330: Launch Single-File Source-Code Programs. >> >> The work is described in the JEP and CSR, and falls into various parts: >> >> ? * The part to handle the new command-line options is in the native >> ??? Java launcher code. >> ? * The part to invoke the compiler and subsequently execute the code >> ??? found in the source file is in a new class in the jdk.compiler >> module. >> ? * There are some minor Makefile changes, to add support for a new >> ??? resource file. >> >> There are no changes to javac itself. >> >> JEP: http://openjdk.java.net/jeps/330 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 >> Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ >> >> -- Jon > From erik.joelsson at oracle.com Wed May 30 20:41:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 30 May 2018 13:41:59 -0700 Subject: RFR: JDK-8204109: JDK-8203945 broke nashorn Message-ID: <0a485c59-e7f4-b755-6940-1c9264630c60@oracle.com> In my recent cleanup change for the nashorn build, I accidentally removed a line that caused the nasgen tool to never run. This is causing a bunch of nashorn tests to fail in tier2. I had run tier1-3 on an earlier version of the patch, but forgot to rerun after the last edit. Bug: https://bugs.openjdk.java.net/browse/JDK-8204109 Webrev: http://cr.openjdk.java.net/~erikj/8204109/webrev.01/ /Erik From tim.bell at oracle.com Wed May 30 21:01:19 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 30 May 2018 14:01:19 -0700 Subject: RFR: JDK-8204109: JDK-8203945 broke nashorn In-Reply-To: <0a485c59-e7f4-b755-6940-1c9264630c60@oracle.com> References: <0a485c59-e7f4-b755-6940-1c9264630c60@oracle.com> Message-ID: <5B0F111F.5060606@oracle.com> Erik: > In my recent cleanup change for the nashorn build, I accidentally > removed a line that caused the nasgen tool to never run. This is causing > a bunch of nashorn tests to fail in tier2. I had run tier1-3 on an > earlier version of the patch, but forgot to rerun after the last edit. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204109 > > Webrev: http://cr.openjdk.java.net/~erikj/8204109/webrev.01/ Looks good. /Tim From serguei.spitsyn at oracle.com Wed May 30 22:50:59 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 May 2018 15:50:59 -0700 Subject: RFR(M) : 8199380 : [TESTBUG] Open source VM testbase AOD tests In-Reply-To: <5E87B35F-FC4E-4814-A4A6-CE1E24D3C479@oracle.com> References: <5E87B35F-FC4E-4814-A4A6-CE1E24D3C479@oracle.com> Message-ID: Igor, It looks good. Thank you a lot for taking care about this! Thanks, Serguei On 5/23/18 12:44, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8199380/webrev.00/ >> 2370 lines changed: 2370 ins; 0 del; 0 mod; > Hi all, > > could you please review this patch which open sources AOD tests from VM testbase? these tests test hotspot's attach-on-demand. > > As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8199380 > webrev: http://cr.openjdk.java.net/~iignatyev//8199380/webrev.00/index.html > testing: :vmTestbase_vm_aod test group > > Thanks, > -- Igor From aoqi at loongson.cn Thu May 31 00:53:04 2018 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 31 May 2018 08:53:04 +0800 Subject: Configure broken on MIPS when uname returns mipsel or mips64el In-Reply-To: <24f174ce-2157-2649-847e-001cb935a9f2@oracle.com> References: <1a32aeb8-b1a9-cf66-ac12-342f10016db1@oracle.com> <24f174ce-2157-2649-847e-001cb935a9f2@oracle.com> Message-ID: Hi Erik, Thanks for reviewing and sponsoring. 2018-05-31 0:39 GMT+08:00 Erik Joelsson : > I'll sponsor it. > > /Erik > > > > On 2018-05-29 23:13, Ao Qi wrote: >> >> Could someone help to create a bug etc? >> >> Thanks, >> Ao Qi >> Magnus Ihse Bursie ?2018?5?25??? ?? >> 3:42??? >> >>> On 2018-05-24 03:08, Ao Qi wrote: >>> Hi Erik, >>> Thanks for your comments. I made a new patch: >>> $ hg diff >>> diff -r 31361382634b make/autoconf/build-aux/config.guess >>> --- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700 >>> +++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800 >>> @@ -86,6 +86,17 @@ >>> fi >>> fi >>> +# Test and fix little endian MIPS. >>> +if [ "x$OUT" = x ]; then >>> + if [ `uname -s` = Linux ]; then >>> + if [ `uname -m` = mipsel ]; then >>> + OUT=mipsel-unknown-linux-gnu >>> + elif [ `uname -m` = mips64el ]; then >>> + OUT=mips64el-unknown-linux-gnu >>> + fi >>> + fi >>> +fi >>> + >>> # Test and fix cpu on Macosx when C preprocessor is not on the path >>> echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null >>> if test $? = 0; then >> >> >>> Looks good to me. Hi Magnus, Thanks for reviewing. >>> /Magnus >>> Cheers, >>> Ao Qi >>> 2018-05-24 0:19 GMT+08:00 Erik Joelsson : >>> Hello Ao Qi, >>> Due to licensing reasons, we are unable to directly update the >>> autoconf-config.guess file. Instead we have the wrapper, config.guess in >>> which we make adjustments to the result returned by >>> autoconf-config.guess. >>> Your fix needs to go in the wrapper file. >>> /Erik From sean.coffey at oracle.com Thu May 31 07:32:14 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 31 May 2018 08:32:14 +0100 Subject: [8u-dev] RFA for JDK-8079788: Fix broken CL version detection in configure for some Visual Studio configurations In-Reply-To: <99eb231e-2430-b8f4-e273-a24345cdb331@oracle.com> References: <0364db56-a0e9-6037-de9b-0ba78c35b210@oracle.com> <6449fd49-3afc-583e-12a9-31142915ea3f@oracle.com> <99eb231e-2430-b8f4-e273-a24345cdb331@oracle.com> Message-ID: <0c1318b9-cc61-1eca-81da-d48aafe6684c@oracle.com> Approved for jdk8u-dev. regards, Sean. On 29/05/2018 15:42, Alexey Ivanov wrote: > I can fix it before pushing. > > > Regards, > Alexey > > On 29/05/2018 15:13, Erik Joelsson wrote: >> Looks good (except for my spelling error in the comment "siutations". >> Not sure what the policy is for fixing such in backports.) >> >> /Erik >> >> On 2018-05-29 05:27, Alexey Ivanov wrote: >>> Hi, >>> >>> Could you please approve the following backport to 8u-dev? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8079788 >>> jdk9 changeset: http://hg.openjdk.java.net/jdk9/dev/rev/d57780478145 >>> Code review: >>> http://mail.openjdk.java.net/pipermail/build-dev/2016-August/017566.html >>> >>> >>> The patch applies cleanly to jdk8u-dev; generated-configure.sh is >>> regenerated. >>> Webrev: http://cr.openjdk.java.net/~aivanov/8079788/jdk8/webrev.0/ >>> >>> I recently faced this issue, and configure for 8u cannot complete. >>> It could be related to backporting of JDK-8042707. >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey >> > From takiguc at linux.vnet.ibm.com Thu May 31 07:55:12 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 31 May 2018 16:55:12 +0900 Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc 12.1 Message-ID: <0c73caec8810b9844a463343bdaec064@linux.vnet.ibm.com> Hello. 8202322 was integrated into jdk-11+15. I'm using XLC 13.1.3 on AIX 7.1.4. Build was failed because of "-qvisibility=hidden" on make/lib/LibCommon.gmk. According to "XL C/C++ for AIX 13.1.3" documentation [1], "-qvisibility=hidden" cannot create shared libraries entry points. For example, libverify.so was there, but entry points were not resolved by "-lverify" option. I think it should be "-qvisibility=default" (I tried, it worked) or "-qvisibility=protected" (I had not tried) ? I'm not familiar with -qvisibility option, but I'd like to find out right way. [1] https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.xlcpp1313.aix.doc/compiler_ref/opt_visibility.html On 2018-05-16 16:08, Langer, Christoph wrote: > Hi Matthias, > > yes, reviewed. > > Best regards > Christoph > > From: Baesken, Matthias > Sent: Mittwoch, 16. Mai 2018 09:06 > To: Langer, Christoph ; > 'build-dev at openjdk.java.net' ; > ppc-aix-port-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hi Christoph can I add you as second reviewer (other reviewer was > Erik Joelsson) can push the change ? > > Best regards, Matthias > > > > From: Langer, Christoph > Sent: Donnerstag, 26. April 2018 16:38 > To: Baesken, Matthias > >; > 'build-dev at openjdk.java.net' > >; > ppc-aix-port-dev at openjdk.java.net; > core-libs-dev at openjdk.java.net > Cc: Simonis, Volker > > > Subject: RE: RFR : 8202322: AIX: symbol visibility flags not support on > xlc 12.1 > > Hi Matthias, > > to me the change in principal looks good. > > I'm wondering if it is possible to do a comparison like xlc < 13 (e.g. > extract major number before the first dot, then compare numerically) - > but maybe it is too complicated and the current single version compare > suits our needs ? > > Best regards > Christoph > > From: Baesken, Matthias > Sent: Donnerstag, 26. April 2018 16:14 > To: 'build-dev at openjdk.java.net' > >; > ppc-aix-port-dev at openjdk.java.net; > core-libs-dev at openjdk.java.net > Cc: Langer, Christoph > >; Simonis, > Volker > > Subject: RFR : 8202322: AIX: symbol visibility flags not support on xlc > 12.1 > > Hello , could you please review this small adjustment to the symbol > visibility compilation settings on AIX ? > Currently we use XLC 12.1 to compile JDK on AIX . > > However XLC 12.1 does not support the "-qvisibility=hidden" > setting currently set on AIX. > It was introduced with XLC 13.1 . Christoph found some info about it > here : > > https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html > > Setting it only generates hundreds of warnings in the build log , > warnings look like this : > XlC12.1 > > bash-4.4$ xlC -qversion > IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) > Version: 12.01.0000.0019 > > bash-4.4$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > 1506-173 (W) Option visibility=hidden is not valid. Enter xlC for list > of valid options. > > Compare to XLC13.1 > > bash-3.00$ xlC -qversion > IBM XL C/C++ for AIX, V13.1 (5725-C72, 5765-J07) > Version: 13.01.0000.0008 > bash-3.00$ xlC -qvisibility=default sizeof.c -o sizeof_aixxlc > bash-3.00$ xlC -qvisibility=hidden sizeof.c -o sizeof_aixxlc > > > So it is better to avoid setting these flags when using xlc12.1 . > Please review : > > Bug : > > https://bugs.openjdk.java.net/browse/JDK-8202322 > > Change : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8202322/ > > > Best regards, Matthias From adam.farley at uk.ibm.com Thu May 31 13:31:55 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 31 May 2018 13:31:55 +0000 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com> References: <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com> Message-ID: Hi Phil, As requested: FYI: I've also contacted Guido, confirmed that the fix worked, and asked him to go ahead with merging the fix into his code base. Best Regards Adam Farley Phil Race wrote on 30/05/2018 18:06:19: > From: Phil Race > To: Adam Farley8 > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > , build-dev dev at openjdk.java.net>, Magnus Ihse Bursie > , "Thomas St?fe" > Date: 30/05/2018 18:07 > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > compile warning in jchuff.c > > Thank you for persevering with this. Please submit a webrev with this > change .. I think you can leave out the change to jerror.h in the jpeg6b case. > > -phil. > On 05/30/2018 09:08 AM, Adam Farley8 wrote: > Hi Phil, > > I spoke with the jpegclub rep "Guido", and he was very helpful. > > He agreed to accept a code change, but recommended an error instead > of a while check. > > ------------------------------ Line 808: > < while (bits[j] == 0) > < j--; > --- > > while (bits[j] == 0) { > > if (j == 0) > > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > > j--; > > } > ------------------------------ > > This makes sense to me, and I verified that it prevents the error. > > He says: > @@@@@@@@@@@@ > For the release version I would replace the specific > JERR_HUFF_CLEN_OVERFLOW by the more general > JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this > requires a change in jerror.h: > > -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") > +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out of bounds") > > The next version (9d) is planned for release in January 2020. > A pre-release package will be provided in 2019 on http:// > jpegclub.org/reference/reference-sources/, I will send you a notification. > @@@@@@@@@@@@ > > While we *could* make the jerror.h change, I suggest we don't for > now. If we merge from upstream in January 2020, we'll get that > change anyway when the time comes. > > So what do you say to including the dashed change referenced above > to fix our problem now, safe in the knowledge that upstream will be > similarly modified (except with the new error type). > > Best Regards > > Adam Farley > > P.S. I'm holding off on giving Guido the green light until after > people say if they're happy with the error-enabled version of the fix. > > Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > > > From: Adam Farley8/UK/IBM > > To: Phil Race > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > , build-dev > dev at openjdk.java.net>, Magnus Ihse Bursie > > , "Thomas St?fe" > > Date: 14/05/2018 11:06 > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > compile warning in jchuff.c > > > > Hi Phil, > > > > Would an acceptable compromise be to deliver the source code change > > and send the code to the upstream community, allowing them to include > > the fix if/when they are able? > > > > I believe Magnus was advocating this idea as well. See below. > > > > Best Regards > > > > Adam Farley > > > > > Same here. I would like to have this fix in, but do not want to go > > > over Phils head. > > > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > > > Thanks, Thomas > > > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > > wrote: > > > > I don't object, but it's not build code so I don't have the final say. > > > > > > > > /Magnus > > > > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > > > Hi All, > > > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > > > It doesn't break anything, it fixes a build break on two supported > > > > platforms, and it seems > > > > like we never refresh the code from upstream. > > > > > > > > - Adam > > > > > > > >> I also advocate the source code fix, as Make isn't meant to > use the sort > > > >> of logic required > > > >> to properly analyse the toolchain version string. > > > >> > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is > using 4.8.6, > > > >> and Make doesn't > > > >> seem to do substring stuff unless you mess around with shells. > > > >> > > > >> Plus, as people have said, it's better to solve problem x (or > work around > > > >> a specific > > > >> instance of x) than to ignore the exception, even if the > ignoring code is > > > >> toolchain- > > > >> specific. > > > >> > > > >> - Adam Farley > > > >> > > > >> > On 2018-03-27 18:44, Phil Race wrote: > > > >> > > > > >> >> As I said I prefer the make file change, since this is a > change to an > > > >> >> upstream library. > > > >> > > > > >> > Newtons fourth law: For every reviewer, there's an equal and opposite > > > >> > reviewer. :) > > > >> > > > > >> > Here I am, advocating a source code fix. As Thomas says, the compiler > > > >> > complaint seems reasonable, and disabling it might cause us > > to miss other > > > >> > future errors. > > > >> > > > > >> > Why can't we push the source code fix, and also submit it upstream? > > > >> > > > > >> > /Magnus > > > >> > > > > >> > > > > >> > I've looked at jpeg-9c and it still looks identical to whatwe have in > > > >> > 6b, so this code > > > >> > seems to have stood the test of time. I'm also unclear why > the compiler > > > >> > would > > > >> > complain about that and not the one a few lines later > > > >> > > > > >> > > > > >> > 819 while (bits[i] == 0) /* find largest > > codelength still in > > > >> > use */ > > > >> > 820 i--; > > > >> > > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > > >> > A tool-chain specific fix in the makefile with an > appropriatecomment is > > > >> > more targeted. > > > >> > > > >> Phil, > > > >> > > > >> Returning to this. > > > >> > > > >> While I understand your reluctance to patch upstream code, let me point > > > >> out that we have not updated libjpeg a single time since the > JDK was open > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > > Wikipedia page > > > >> on libjpeg, and this is the latest "uncontroversial" version of > > the source. > > > >> Versions 7 and up have proprietary extensions, which in turn > > has resulted in > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > > we will ever > > > >> replace libjpeg 6b with a simple upgrade from upstream. > > > >> > > > >> I therefore maintain my position that a source code fix would > be the best > > > >> way forward here. > > > >> > > > >> /Magnus > > > >> > > > >> > > > > >> > > > > >> > -phil. > > > >> > > > > >> > > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > >> > > > > >> > Hi all, > > > >> > > > > >> > > > > >> > just a friendly reminder. I would like to push this tiny fix because > > > >> > tripping over this on our linux s390x builds is annoying (yes, we can > > > >> > maintain patch queues, but this is a constant error source). > > > >> > > > > >> > > > > >> > I will wait for 24 more hours until a reaction. If no > seriousobjections > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > > me and Christoph > > > >> > langer are both Reviewers). > > > >> > > > > >> > > > > >> > Thanks! Thomas > > > >> > > > > >> > > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > > >> > wrote: > > > >> > > > > >> > Hi all, > > > >> > > > > >> > > > > >> > may I please have another review for this really trivial change. It > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > > good idea to fix > > > >> > this. > > > >> > > > > >> > > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > > >> > webrev: > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > > warning-in-jchuff.c/webrev.00/webrev/ > > > >> > > > > >> > > > > >> > This was contributed by Adam Farley at IBM. > > > >> > > > > >> > > > > >> > I already reviewed this. I also test-built on zlinux and it works. > > > >> > > > > >> > > > > >> > Thanks, Thomas > > > >> > > > > >> > > > >> Unless stated otherwise above: > > > >> IBM United Kingdom Limited - Registered in England and Wales > with number > > > >> 741598. > > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > >> > > > >> > > > > > > > > Unless stated otherwise above: > > > > IBM United Kingdom Limited - Registered in England and Wales with number > > > > 741598. > > > > Registered office: PO Box 41, North Harbour, Portsmouth, > Hampshire PO6 3AU > > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From philip.race at oracle.com Thu May 31 17:33:46 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 31 May 2018 10:33:46 -0700 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: <5a6f5802-f4f9-c1ef-bc09-c2cce0bd1027@oracle.com> Message-ID: <64b546b2-c33a-dafd-f284-a2aedac8d730@oracle.com> I've grabbed the bug from Thomas and re-opened it https://bugs.openjdk.java.net/browse/ Your webrev was stripped so I've uploaded here : http://cr.openjdk.java.net/~prr/8200052/ It looks fine to me but I am a bit hazy about who to give attribution for the fix .. It is small enough to not require an OCA so there's no issue there if we attribute it to the IJG guy. -phil. On 05/31/2018 06:31 AM, Adam Farley8 wrote: > An attachment in the email has been found to contain executable code > and has been removed. > > File removed : webrev.zip, zip,html,js > ------------------------------------------------------------------------ > Hi Phil, > > As requested: > > > > FYI: I've also contacted Guido, confirmed that the fix worked, and asked > him to go ahead with merging the fix into his code base. > > Best Regards > > Adam Farley > > > Phil Race wrote on 30/05/2018 18:06:19: > > > From: Phil Race > > To: Adam Farley8 > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > , build-dev > dev at openjdk.java.net>, Magnus Ihse Bursie > > , "Thomas St?fe" > > > Date: 30/05/2018 18:07 > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > compile warning in jchuff.c > > > > Thank you for persevering with this. Please submit a webrev with this > > change .. I think you can leave out the change to jerror.h in the > jpeg6b case. > > > > -phil. > > > On 05/30/2018 09:08 AM, Adam Farley8 wrote: > > Hi Phil, > > > > I spoke with the jpegclub rep "Guido", and he was very helpful. > > > > He agreed to accept a code change, but recommended an error instead > > of a while check. > > > > ------------------------------ Line 808: > > < while (bits[j] == 0) > > < j--; > > --- > > > while (bits[j] == 0) { > > > if (j == 0) > > > ERREXIT(cinfo, JERR_HUFF_CLEN_OVERFLOW); > > > j--; > > > } > > ------------------------------ > > > > This makes sense to me, and I verified that it prevents the error. > > > > He says: > > @@@@@@@@@@@@ > > For the release version I would replace the specific > > JERR_HUFF_CLEN_OVERFLOW by the more general > > JERR_HUFF_CLEN_OUTOFBOUNDS so that it suits both cases, this > > requires a change in jerror.h: > > > > -JMESSAGE(JERR_HUFF_CLEN_OVERFLOW, "Huffman code size table overflow") > > +JMESSAGE(JERR_HUFF_CLEN_OUTOFBOUNDS, "Huffman code size table out > of bounds") > > > > The next version (9d) is planned for release in January 2020. > > A pre-release package will be provided in 2019 on http:// > > jpegclub.org/reference/reference-sources/, I will send you a > notification. > > @@@@@@@@@@@@ > > > > While we *could* make the jerror.h change, I suggest we don't for > > now. If we merge from upstream in January 2020, we'll get that > > change anyway when the time comes. > > > > So what do you say to including the dashed change referenced above > > to fix our problem now, safe in the knowledge that upstream will be > > similarly modified (except with the new error type). > > > > Best Regards > > > > Adam Farley > > > > P.S. I'm holding off on giving Guido the green light until after > > people say if they're happy with the error-enabled version of the fix. > > > > Adam Farley8/UK/IBM wrote on 14/05/2018 11:06:28: > > > > > From: Adam Farley8/UK/IBM > > > To: Phil Race > > > Cc: 2d-dev <2d-dev at openjdk.java.net>, Andrew Leonard > > > , build-dev > > dev at openjdk.java.net>, Magnus Ihse Bursie > > > , "Thomas St?fe" > > > > Date: 14/05/2018 11:06 > > > Subject: Re: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix > > > compile warning in jchuff.c > > > > > > Hi Phil, > > > > > > Would an acceptable compromise be to deliver the source code change > > > and send the code to the upstream community, allowing them to include > > > the fix if/when they are able? > > > > > > I believe Magnus was advocating this idea as well. See below. > > > > > > Best Regards > > > > > > Adam Farley > > > > > > > Same here. I would like to have this fix in, but do not want to go > > > > over Phils head. > > > > > > > > I think Phil was the main objector, maybe he could reconsider?` > > > > > > > > Thanks, Thomas > > > > > > > > On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie > > > > wrote: > > > > > I don't object, but it's not build code so I don't have the > final say. > > > > > > > > > > /Magnus > > > > > > > > > > > > > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > > > > > > > > > Hi All, > > > > > > > > > > Does anyone have an objection to pushing this tiny change in? > > > > > > > > > > It doesn't break anything, it fixes a build break on two > supported > > > > > platforms, and it seems > > > > > like we never refresh the code from upstream. > > > > > > > > > > - Adam > > > > > > > > > >> I also advocate the source code fix, as Make isn't meant to > > use the sort > > > > >> of logic required > > > > >> to properly analyse the toolchain version string. > > > > >> > > > > >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is > > using 4.8.6, > > > > >> and Make doesn't > > > > >> seem to do substring stuff unless you mess around with shells. > > > > >> > > > > >> Plus, as people have said, it's better to solve problem x (or > > work around > > > > >> a specific > > > > >> instance of x) than to ignore the exception, even if the > > ignoring code is > > > > >> toolchain- > > > > >> specific. > > > > >> > > > > >> - Adam Farley > > > > >> > > > > >> > On 2018-03-27 18:44, Phil Race wrote: > > > > >> > > > > > >> >> As I said I prefer the make file change, since this is a > > change to an > > > > >> >> upstream library. > > > > >> > > > > > >> > Newtons fourth law: For every reviewer, there's an equal > and opposite > > > > >> > reviewer. :) > > > > >> > > > > > >> > Here I am, advocating a source code fix. As Thomas says, > the compiler > > > > >> > complaint seems reasonable, and disabling it might cause us > > > to miss other > > > > >> > future errors. > > > > >> > > > > > >> > Why can't we push the source code fix, and also submit it > upstream? > > > > >> > > > > > >> > /Magnus > > > > >> > > > > > >> > > > > > >> > I've looked at jpeg-9c and it still looks identical to > whatwe have in > > > > >> > 6b, so this code > > > > >> > seems to have stood the test of time. I'm also unclear why > > the compiler > > > > >> > would > > > > >> > complain about that and not the one a few lines later > > > > >> > > > > > >> > > > > > >> > 819 while (bits[i] == 0) /* find largest > > > codelength still in > > > > >> > use */ > > > > >> > 820 i--; > > > > >> > > > > > >> > A push to jchuff.c will get blown away if/when we upgrade. > > > > >> > A tool-chain specific fix in the makefile with an > > appropriatecomment is > > > > >> > more targeted. > > > > >> > > > > >> Phil, > > > > >> > > > > >> Returning to this. > > > > >> > > > > >> While I understand your reluctance to patch upstream code, > let me point > > > > >> out that we have not updated libjpeg a single time since the > > JDK was open > > > > >> sourced. We're using 6b from 27-Mar-1998. I had a look at the > > > Wikipedia page > > > > >> on libjpeg, and this is the latest "uncontroversial" version of > > > the source. > > > > >> Versions 7 and up have proprietary extensions, which in turn > > > has resulted in > > > > >> multiple forks of libjpeg. As it stands, it seems unlikely that > > > we will ever > > > > >> replace libjpeg 6b with a simple upgrade from upstream. > > > > >> > > > > >> I therefore maintain my position that a source code fix would > > be the best > > > > >> way forward here. > > > > >> > > > > >> /Magnus > > > > >> > > > > >> > > > > > >> > > > > > >> > -phil. > > > > >> > > > > > >> > > > > > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > > >> > > > > > >> > Hi all, > > > > >> > > > > > >> > > > > > >> > just a friendly reminder. I would like to push this tiny > fix because > > > > >> > tripping over this on our linux s390x builds is annoying > (yes, we can > > > > >> > maintain patch queues, but this is a constant error source). > > > > >> > > > > > >> > > > > > >> > I will wait for 24 more hours until a reaction. If no > > seriousobjections > > > > >> > are forcoming, I want to push it (tier1 tests ran thru, and > > > me and Christoph > > > > >> > langer are both Reviewers). > > > > >> > > > > > >> > > > > > >> > Thanks! Thomas > > > > >> > > > > > >> > > > > > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > > > > > > >> > wrote: > > > > >> > > > > > >> > Hi all, > > > > >> > > > > > >> > > > > > >> > may I please have another review for this really trivial > change. It > > > > >> > fixes a gcc warning on s390 and ppc. Also, it is probably a > > > good idea to fix > > > > >> > this. > > > > >> > > > > > >> > > > > > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > > > >> > webrev: > > > > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix- > > > > warning-in-jchuff.c/webrev.00/webrev/ > > > > >> > > > > > >> > > > > > >> > This was contributed by Adam Farley at IBM. > > > > >> > > > > > >> > > > > > >> > I already reviewed this. I also test-built on zlinux and it > works. > > > > >> > > > > > >> > > > > > >> > Thanks, Thomas > > > > >> > > > > > >> > > > > >> Unless stated otherwise above: > > > > >> IBM United Kingdom Limited - Registered in England and Wales > > with number > > > > >> 741598. > > > > >> Registered office: PO Box 41, North Harbour, Portsmouth, > > > Hampshire PO6 3AU > > > > >> > > > > >> > > > > > > > > > > Unless stated otherwise above: > > > > > IBM United Kingdom Limited - Registered in England and Wales > with number > > > > > 741598. > > > > > Registered office: PO Box 41, North Harbour, Portsmouth, > > Hampshire PO6 3AU > > > > > > > > > > > > > > > > Unless stated otherwise above: > > > IBM United Kingdom Limited - Registered in England and Wales with > > > number 741598. > > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU