From shade at redhat.com Mon Jul 1 15:08:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Jul 2019 17:08:10 +0200 Subject: [8u] RFR (S) 8227018: CompletableFuture should not call Runtime.availableProcessors on fast path Message-ID: RFE: https://bugs.openjdk.java.net/browse/JDK-8227018 8u webrev: http://cr.openjdk.java.net/~shade/8227018/webrev.01/ In 8u, CompletableFuture calls Runtime.availableProcessors during spin in waitingGet. Unfortunately, that falls victim to JDK-8227006, which makes it too costly. This is fixed in 9 with JDK-8134851, but that patch is too large and intrusive to backport to 8u. Therefore, we should consider backporting the small part of that patch that deals with availableProcessors handling. Testing: "tier1"-like testing -- Thanks, -Aleksey From martinrb at google.com Mon Jul 1 15:19:51 2019 From: martinrb at google.com (Martin Buchholz) Date: Mon, 1 Jul 2019 08:19:51 -0700 Subject: [8u] RFR (S) 8227018: CompletableFuture should not call Runtime.availableProcessors on fast path In-Reply-To: References: Message-ID: Looks good to me. Of course, this would benefit from our pending 8u jsr166 tck backport, which includes exhaustive tests of CompletableFuture. On Mon, Jul 1, 2019 at 8:08 AM Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8227018 > > 8u webrev: > http://cr.openjdk.java.net/~shade/8227018/webrev.01/ > > In 8u, CompletableFuture calls Runtime.availableProcessors during spin in > waitingGet. Unfortunately, > that falls victim to JDK-8227006, which makes it too costly. This is fixed > in 9 with JDK-8134851, > but that patch is too large and intrusive to backport to 8u. Therefore, we > should consider > backporting the small part of that patch that deals with > availableProcessors handling. > > Testing: "tier1"-like testing > > -- > Thanks, > -Aleksey > > From bob.vandette at oracle.com Mon Jul 1 15:20:16 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 1 Jul 2019 11:20:16 -0400 Subject: [8u] RFR (S) 8227018: CompletableFuture should not call Runtime.availableProcessors on fast path In-Reply-To: References: Message-ID: This quick patch reduces the performance difference to noise. This assumes that none of the cpu resource limits change. Bob. diff -r e64383344f14 src/hotspot/os/linux/osContainer_linux.cpp --- a/src/hotspot/os/linux/osContainer_linux.cpp Wed Jun 26 13:18:38 2019 -0400 +++ b/src/hotspot/os/linux/osContainer_linux.cpp Mon Jul 01 15:13:56 2019 +0000 @@ -581,22 +581,36 @@ * return: * number of CPUs */ +static bool cpu_limits_initialized = false; +static int quota_cache; +static int period_cache; +static int share_cache; +static int last_processor_count; +static int last_active_cpu_count; + int OSContainer::active_processor_count() { int quota_count = 0, share_count = 0; - int cpu_count, limit_count; + int limit_count; int result; - cpu_count = limit_count = os::Linux::active_processor_count(); - int quota = cpu_quota(); - int period = cpu_period(); - int share = cpu_shares(); + if (cpu_limits_initialized) { + int cpu_count = os::Linux::active_processor_count(); + if (cpu_count == last_active_cpu_count) { + return last_processor_count; + } + } - if (quota > -1 && period > 0) { - quota_count = ceilf((float)quota / (float)period); + last_active_cpu_count = limit_count = os::Linux::active_processor_count(); + int quota_cache = cpu_quota(); + int period_cache = cpu_period(); + int share_cache = cpu_shares(); + + if (quota_cache > -1 && period_cache > 0) { + quota_count = ceilf((float)quota_cache / (float)period_cache); log_trace(os, container)("CPU Quota count based on quota/period: %d", quota_count); } - if (share > -1) { - share_count = ceilf((float)share / (float)PER_CPU_SHARES); + if (share_cache > -1) { + share_count = ceilf((float)share_cache / (float)PER_CPU_SHARES); log_trace(os, container)("CPU Share count based on shares: %d", share_count); } @@ -616,8 +630,11 @@ limit_count = share_count; } - result = MIN2(cpu_count, limit_count); + result = MIN2(last_active_cpu_count, limit_count); log_trace(os, container)("OSContainer::active_processor_count: %d", result); + + last_processor_count = result; + cpu_limits_initialized = true; return result; } > On Jul 1, 2019, at 11:08 AM, Aleksey Shipilev wrote: > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8227018 > > 8u webrev: > http://cr.openjdk.java.net/~shade/8227018/webrev.01/ > > In 8u, CompletableFuture calls Runtime.availableProcessors during spin in waitingGet. Unfortunately, > that falls victim to JDK-8227006, which makes it too costly. This is fixed in 9 with JDK-8134851, > but that patch is too large and intrusive to backport to 8u. Therefore, we should consider > backporting the small part of that patch that deals with availableProcessors handling. > > Testing: "tier1"-like testing > > -- > Thanks, > -Aleksey > From shade at redhat.com Mon Jul 1 15:24:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Jul 2019 17:24:12 +0200 Subject: [8u] RFR (S) 8227018: CompletableFuture should not call Runtime.availableProcessors on fast path In-Reply-To: References: Message-ID: On 7/1/19 5:20 PM, Bob Vandette wrote: > This quick patch reduces the performance difference to noise. > This assumes that none of the cpu resource limits change. This looks like a fix for JDK-8227006. We can backport that later too. CompletableFuture is changed since 8u to drop this Runtime.availableProcessor call from the fast path anyway. -- Thanks, -Aleksey From hohensee at amazon.com Mon Jul 1 15:30:22 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Jul 2019 15:30:22 +0000 Subject: 8u222 In-Reply-To: References: Message-ID: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> Looks good. Paul ?On 6/29/19, 9:06 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: It looks like we are now just missing JDK-8218781 from 8u222. If someone could please review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009667.html I can push this final fix and announce the freeze of 8u, prior to the July security update. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Mon Jul 1 15:41:55 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Jul 2019 15:41:55 +0000 Subject: 8u222 In-Reply-To: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> References: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> Message-ID: <56F93311-FDEF-45B9-A6F1-5DBEE86B3A3F@amazon.com> Btw, there are still jdk8u-critical-request issues outstanding, e.g. 8218605. These will presumably go into 8u232? ?On 7/1/19, 8:31 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Looks good. Paul On 6/29/19, 9:06 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: It looks like we are now just missing JDK-8218781 from 8u222. If someone could please review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009667.html I can push this final fix and announce the freeze of 8u, prior to the July security update. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Mon Jul 1 16:09:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 1 Jul 2019 18:09:01 +0200 Subject: [8u] RFR (S) 8227018: CompletableFuture should not call Runtime.availableProcessors on fast path In-Reply-To: References: Message-ID: <3bb4053f-5b08-407a-d904-1d46fd164e2b@redhat.com> On 7/1/19 5:19 PM, Martin Buchholz wrote: > Looks good to me. Thanks! > Of course, this would benefit from our pending 8u jsr166 tck backport, which includes exhaustive > tests of CompletableFuture. Right. I applied JDK-8225213 before this patch, and passed all those tests too. -- Thanks, -Aleksey From gnu.andrew at redhat.com Mon Jul 1 19:47:49 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 1 Jul 2019 20:47:49 +0100 Subject: 8u222 In-Reply-To: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> References: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> Message-ID: On 01/07/2019 16:30, Hohensee, Paul wrote: > Looks good. > > Paul > > ?On 6/29/19, 9:06 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: > > It looks like we are now just missing JDK-8218781 from 8u222. > > If someone could please review: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009667.html > > I can push this final fix and announce the freeze of 8u, prior to the > July security update. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > > > Thanks. Pushed. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Jul 1 20:35:02 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 1 Jul 2019 21:35:02 +0100 Subject: 8u222 In-Reply-To: <56F93311-FDEF-45B9-A6F1-5DBEE86B3A3F@amazon.com> References: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> <56F93311-FDEF-45B9-A6F1-5DBEE86B3A3F@amazon.com> Message-ID: <464e7aa0-c8c2-4d17-2b51-ff1da2d30b72@redhat.com> On 01/07/2019 16:41, Hohensee, Paul wrote: > Btw, there are still jdk8u-critical-request issues outstanding, e.g. 8218605. These will presumably go into 8u232? > Yes, sorry, I should explain what I decided for the other bugs listed in the 8u222 filter [0]. JDK-8218605: No patch available, needs to be reproduced and a patch written JDK-8215982: No patch available, due to https://bugs.openjdk.java.net/browse/JDK-8223388. Worse case it should be visible when Oracle push 12.0.2. JDK-8215210: Much the same as 8218605. JDK-8208666: No patch available, seems it may be Oracle JDK only ("The report is that OpenJDK is fine, so I'd expect JDK 11 to be OK as it uses freetype like OpenJDK") JDK-8194653: No patch available, discussed elsewhere on this mailing list [1] JDK-8178870, JDK-8155951 & JDK-8151066 seemed to have been missed so far because of being resolved in 8u212 b34, so I assumed we'd delay them to 8u232. JDK-8219914 & JDK-8196681 have recently appeared, but are only in 8u221 b31, so I presume these are more 8u232 issues. They are listed for October for 11u. On that note, I suggest people start looking at stuff for 8u232 [2]. 8u-dev is open for such backports. [0] https://bugs.openjdk.java.net/issues/?filter=36456 [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009647.html [2] https://bugs.openjdk.java.net/issues/?filter=36513 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Mon Jul 1 20:46:40 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 1 Jul 2019 20:46:40 +0000 Subject: 8u222 In-Reply-To: <464e7aa0-c8c2-4d17-2b51-ff1da2d30b72@redhat.com> References: <19A3F96E-BE69-4DF5-A52A-0E7F4FE9DF80@amazon.com> <56F93311-FDEF-45B9-A6F1-5DBEE86B3A3F@amazon.com> <464e7aa0-c8c2-4d17-2b51-ff1da2d30b72@redhat.com> Message-ID: Thank you, Andrew. Paul ?On 7/1/19, 1:35 PM, "Andrew John Hughes" wrote: On 01/07/2019 16:41, Hohensee, Paul wrote: > Btw, there are still jdk8u-critical-request issues outstanding, e.g. 8218605. These will presumably go into 8u232? > Yes, sorry, I should explain what I decided for the other bugs listed in the 8u222 filter [0]. JDK-8218605: No patch available, needs to be reproduced and a patch written JDK-8215982: No patch available, due to https://bugs.openjdk.java.net/browse/JDK-8223388. Worse case it should be visible when Oracle push 12.0.2. JDK-8215210: Much the same as 8218605. JDK-8208666: No patch available, seems it may be Oracle JDK only ("The report is that OpenJDK is fine, so I'd expect JDK 11 to be OK as it uses freetype like OpenJDK") JDK-8194653: No patch available, discussed elsewhere on this mailing list [1] JDK-8178870, JDK-8155951 & JDK-8151066 seemed to have been missed so far because of being resolved in 8u212 b34, so I assumed we'd delay them to 8u232. JDK-8219914 & JDK-8196681 have recently appeared, but are only in 8u221 b31, so I presume these are more 8u232 issues. They are listed for October for 11u. On that note, I suggest people start looking at stuff for 8u232 [2]. 8u-dev is open for such backports. [0] https://bugs.openjdk.java.net/issues/?filter=36456 [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009647.html [2] https://bugs.openjdk.java.net/issues/?filter=36513 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Jul 2 10:32:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Jul 2019 12:32:49 +0200 Subject: [8u] RFR 8151486: Class.forName causes memory leak Message-ID: <2b63e90e-9bd4-10ab-7b8e-81f7dfd8448d@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8151486 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1f044f413e6c The product change is exactly the same. I had to massage the test to work on 8u, though: jdk.testlibrary.JarUtils is in different place, and has a little different method we should use for createJarFile. The test fails without the product change, and passes with it. 8u webrev: http://cr.openjdk.java.net/~shade/8151486/webrev.8u.01/ Testing: new test, "tier1"-like profile -- Thanks, -Aleksey From shade at redhat.com Tue Jul 2 19:53:17 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 2 Jul 2019 21:53:17 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() Message-ID: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8214687 https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ Testing: tier1-like suite, new test -- Thanks, -Aleksey From bevans at newrelic.com Wed Jul 3 18:30:55 2019 From: bevans at newrelic.com (Ben Evans) Date: Wed, 3 Jul 2019 19:30:55 +0100 Subject: RFC: minimal backport of 8182299 build on OSX 10 + Xcode 8 In-Reply-To: <0f7be6fc-f8d4-d691-09ad-047933c48443@redhat.com> References: <0f7be6fc-f8d4-d691-09ad-047933c48443@redhat.com> Message-ID: Hi, As this appears to have been Warnock'd ( https://en.wikipedia.org/wiki/Warnock%27s_dilemma), allow me to give it another kick. My personal take (for the little that it's worth) is: Given current adoption rates and trends, JDK 8 is going to be with us for a long time. Restricting the potential community size of developers working on OpenJDK 8 by: 1.) Requiring that people who develop on Macs jump through virtualisation hoops and 2.) Making the building of binaries a byzantine process requiring the maintenance of obsolete Macs is bad, and we should stop doing it. Thanks, Ben On Fri, Jun 28, 2019 at 4:09 PM Simon Tooke wrote: > Hello everyone, > > I would like to make a somewhat controversial proposal: to backport the > minimal changes required to enable jdk8u to compile and run when built > with the latest macOS developer tools. > > I realize this falls outside of aph's guidelines of "bug fixes only, > (for now)" and in many ways is only a developer convenience, since I am > not advocating (at this time) for this build to become the default > supported for macOS [1]. > > There changes do not affect the current mac build, which requires an old > version of Xcode which doesn't run on modern releases of macOS, but they > make it much easier for macOS hackers to work with jdk8. > > At this point, testing has been confined to bootstrapping the build with > a jdk8 built using this patch, and to using this build to build a > working Graal substrateVM. > > My version of the backport limits the scope of the 8182299 patches to > the subset required to get the JDK up and running. I don't propose > backporting any changes to remove Clang warnings, etc. Because of that, > my changes are confined in scope. > > Potential long term benefits (if this build does seem healthy enough for > production) are simplified macOS build platforms, a more modern compiler > and perhaps higher performance. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8182656 > > Webrev: http://cr.openjdk.java.net/~stooke/webrevs/xcodemacos.webrev/ > > Thanks for your time, > > -Simon > > [1] first, potentially removes support for macOS 10.8, second, needs > more testing. > > > From gnu.andrew at redhat.com Wed Jul 3 20:03:07 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 3 Jul 2019 21:03:07 +0100 Subject: RFC: minimal backport of 8182299 build on OSX 10 + Xcode 8 In-Reply-To: References: <0f7be6fc-f8d4-d691-09ad-047933c48443@redhat.com> Message-ID: <815ea1cf-42b9-5224-d820-22b2977834d2@redhat.com> On 03/07/2019 19:30, Ben Evans wrote: > Hi, > > As this appears to have been Warnock'd ( > https://en.wikipedia.org/wiki/Warnock%27s_dilemma), allow me to give it > another kick. > > My personal take (for the little that it's worth) is: Given current > adoption rates and trends, JDK 8 is going to be with us for a long time. > Restricting the potential community size of developers working on OpenJDK 8 > by: > > 1.) Requiring that people who develop on Macs jump through virtualisation > hoops and > 2.) Making the building of binaries a byzantine process requiring the > maintenance of obsolete Macs > > is bad, and we should stop doing it. > > Thanks, > > Ben > > On Fri, Jun 28, 2019 at 4:09 PM Simon Tooke wrote: > >> Hello everyone, >> >> I would like to make a somewhat controversial proposal: to backport the >> minimal changes required to enable jdk8u to compile and run when built >> with the latest macOS developer tools. >> >> I realize this falls outside of aph's guidelines of "bug fixes only, >> (for now)" and in many ways is only a developer convenience, since I am >> not advocating (at this time) for this build to become the default >> supported for macOS [1]. >> >> There changes do not affect the current mac build, which requires an old >> version of Xcode which doesn't run on modern releases of macOS, but they >> make it much easier for macOS hackers to work with jdk8. >> >> At this point, testing has been confined to bootstrapping the build with >> a jdk8 built using this patch, and to using this build to build a >> working Graal substrateVM. >> >> My version of the backport limits the scope of the 8182299 patches to >> the subset required to get the JDK up and running. I don't propose >> backporting any changes to remove Clang warnings, etc. Because of that, >> my changes are confined in scope. >> >> Potential long term benefits (if this build does seem healthy enough for >> production) are simplified macOS build platforms, a more modern compiler >> and perhaps higher performance. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8182656 >> >> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/xcodemacos.webrev/ >> >> Thanks for your time, >> >> -Simon >> >> [1] first, potentially removes support for macOS 10.8, second, needs >> more testing. >> >> >> I saw it, but there's a CPU on right now. I'll have a look properly once that's out of the way. My initial thought is what is the subset you refer to? The problem with backporting bits of a change is that it then looks like that change is backported, but some parts of it are actually missing. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From stooke at redhat.com Wed Jul 3 20:32:18 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 3 Jul 2019 16:32:18 -0400 Subject: RFC: minimal backport of 8182299 build on OSX 10 + Xcode 8 In-Reply-To: <815ea1cf-42b9-5224-d820-22b2977834d2@redhat.com> References: <0f7be6fc-f8d4-d691-09ad-047933c48443@redhat.com> <815ea1cf-42b9-5224-d820-22b2977834d2@redhat.com> Message-ID: <86ad61b6-daf0-a797-3927-99e60e8f6139@redhat.com> On 7/3/2019 4:03 PM, Andrew John Hughes wrote: > > On 03/07/2019 19:30, Ben Evans wrote: >> Hi, >> >> As this appears to have been Warnock'd ( >> https://en.wikipedia.org/wiki/Warnock%27s_dilemma), allow me to give it >> another kick. >> >> My personal take (for the little that it's worth) is: Given current >> adoption rates and trends, JDK 8 is going to be with us for a long time. >> Restricting the potential community size of developers working on OpenJDK 8 >> by: >> >> 1.) Requiring that people who develop on Macs jump through virtualisation >> hoops and >> 2.) Making the building of binaries a byzantine process requiring the >> maintenance of obsolete Macs >> >> is bad, and we should stop doing it. >> >> Thanks, >> >> Ben >> >> On Fri, Jun 28, 2019 at 4:09 PM Simon Tooke wrote: >> >>> Hello everyone, >>> >>> I would like to make a somewhat controversial proposal: to backport the >>> minimal changes required to enable jdk8u to compile and run when built >>> with the latest macOS developer tools. >>> >>> I realize this falls outside of aph's guidelines of "bug fixes only, >>> (for now)" and in many ways is only a developer convenience, since I am >>> not advocating (at this time) for this build to become the default >>> supported for macOS [1]. >>> >>> There changes do not affect the current mac build, which requires an old >>> version of Xcode which doesn't run on modern releases of macOS, but they >>> make it much easier for macOS hackers to work with jdk8. >>> >>> At this point, testing has been confined to bootstrapping the build with >>> a jdk8 built using this patch, and to using this build to build a >>> working Graal substrateVM. >>> >>> My version of the backport limits the scope of the 8182299 patches to >>> the subset required to get the JDK up and running. I don't propose >>> backporting any changes to remove Clang warnings, etc. Because of that, >>> my changes are confined in scope. >>> >>> Potential long term benefits (if this build does seem healthy enough for >>> production) are simplified macOS build platforms, a more modern compiler >>> and perhaps higher performance. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182656 >>> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/xcodemacos.webrev/ >>> >>> Thanks for your time, >>> >>> -Simon >>> >>> [1] first, potentially removes support for macOS 10.8, second, needs >>> more testing. >>> >>> >>> > I saw it, but there's a CPU on right now. I'll have a look properly once > that's out of the way. Yes, I know this is very much on the back burner for now.? > My initial thought is what is the subset you refer to? The problem with > backporting bits of a change is that it then looks like that change is > backported, but some parts of it are actually missing. We could avoid referring to the initial patch altogether; a large part of it (which I avoided) was simply getting rid of clang warning messages.? I just went for the bits that stop the crash, and skipped the rest. From hohensee at amazon.com Wed Jul 3 20:50:22 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 3 Jul 2019 20:50:22 +0000 Subject: minimal backport of 8182299 build on OSX 10 + Xcode 8 Message-ID: <1059C67E-7E46-4F80-A066-388ACB879149@amazon.com> There are quite a few JBS issues that fix gcc 7 and 8 compilation problems. Possibly backporting these will fix most/all of clang's complaints as well. Paul ?On 7/3/19, 1:33 PM, "jdk8u-dev on behalf of Simon Tooke" wrote: On 7/3/2019 4:03 PM, Andrew John Hughes wrote: > > On 03/07/2019 19:30, Ben Evans wrote: >> Hi, >> >> As this appears to have been Warnock'd ( >> https://en.wikipedia.org/wiki/Warnock%27s_dilemma), allow me to give it >> another kick. >> >> My personal take (for the little that it's worth) is: Given current >> adoption rates and trends, JDK 8 is going to be with us for a long time. >> Restricting the potential community size of developers working on OpenJDK 8 >> by: >> >> 1.) Requiring that people who develop on Macs jump through virtualisation >> hoops and >> 2.) Making the building of binaries a byzantine process requiring the >> maintenance of obsolete Macs >> >> is bad, and we should stop doing it. >> >> Thanks, >> >> Ben >> >> On Fri, Jun 28, 2019 at 4:09 PM Simon Tooke wrote: >> >>> Hello everyone, >>> >>> I would like to make a somewhat controversial proposal: to backport the >>> minimal changes required to enable jdk8u to compile and run when built >>> with the latest macOS developer tools. >>> >>> I realize this falls outside of aph's guidelines of "bug fixes only, >>> (for now)" and in many ways is only a developer convenience, since I am >>> not advocating (at this time) for this build to become the default >>> supported for macOS [1]. >>> >>> There changes do not affect the current mac build, which requires an old >>> version of Xcode which doesn't run on modern releases of macOS, but they >>> make it much easier for macOS hackers to work with jdk8. >>> >>> At this point, testing has been confined to bootstrapping the build with >>> a jdk8 built using this patch, and to using this build to build a >>> working Graal substrateVM. >>> >>> My version of the backport limits the scope of the 8182299 patches to >>> the subset required to get the JDK up and running. I don't propose >>> backporting any changes to remove Clang warnings, etc. Because of that, >>> my changes are confined in scope. >>> >>> Potential long term benefits (if this build does seem healthy enough for >>> production) are simplified macOS build platforms, a more modern compiler >>> and perhaps higher performance. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182656 >>> >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/xcodemacos.webrev/ >>> >>> Thanks for your time, >>> >>> -Simon >>> >>> [1] first, potentially removes support for macOS 10.8, second, needs >>> more testing. >>> >>> >>> > I saw it, but there's a CPU on right now. I'll have a look properly once > that's out of the way. Yes, I know this is very much on the back burner for now. > My initial thought is what is the subset you refer to? The problem with > backporting bits of a change is that it then looks like that change is > backported, but some parts of it are actually missing. We could avoid referring to the initial patch altogether; a large part of it (which I avoided) was simply getting rid of clang warning messages. I just went for the bits that stop the crash, and skipped the rest. From sgehwolf at redhat.com Thu Jul 4 09:38:53 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 04 Jul 2019 11:38:53 +0200 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> Message-ID: <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> Hi Christoph, On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > Here you go: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210761/jdk8/02/webrev/ > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate any > > testers for those platforms. > > I pulled the patch into our test environment. It will be run for AIX > and solaris there. Will let you know the results... Any update? Thanks, Severin From christoph.langer at sap.com Thu Jul 4 10:24:04 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 4 Jul 2019 10:24:04 +0000 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> Message-ID: Hi Severin, sorry, this item got drained down in my pile of work. AIX looks good. For Solaris, however, there is a problem. This is an excerpt of the logs: SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ -M jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig -mt -xnolib -xO4 -g0 -xs -o libjsig.so sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl cc: Warning: Option -0 passed to ld, if ld is invoked, ignored otherwise ld: fatal: unrecognized option '-0' ld: fatal: use the '-z help' option for usage information Seems like the options don't work for Oracle Studio (12 u1) when compiling and linking in one go. A fix would be to split compilation and linking of the lib into 2 steps, I guess. Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 4. Juli 2019 11:39 > To: Langer, Christoph ; Andrew John Hughes > ; jdk8u-dev > Cc: build-dev > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization > > Hi Christoph, > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > > Here you go: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8210761/jdk8/02/webrev/ > > > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate any > > > testers for those platforms. > > > > I pulled the patch into our test environment. It will be run for AIX > > and solaris there. Will let you know the results... > > Any update? > > Thanks, > Severin From sgehwolf at redhat.com Thu Jul 4 12:17:31 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 04 Jul 2019 14:17:31 +0200 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> Message-ID: <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> Hi Christoph, On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: > Hi Severin, > > sorry, this item got drained down in my pile of work. > > AIX looks good. For Solaris, however, there is a problem. > > This is an excerpt of the logs: > SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ > -M jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig -mt -xnolib -xO4 -g0 -xs -o libjsig.so sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl > cc: Warning: Option -0 passed to ld, if ld is invoked, ignored otherwise > ld: fatal: unrecognized option '-0' > ld: fatal: use the '-z help' option for usage information Thanks for this info! > Seems like the options don't work for Oracle Studio (12 u1) when > compiling and linking in one go. A fix would be to split compilation > and linking of the lib into 2 steps, I guess. As I don't have access to such a system and test a potential patch, I've removed the solaris changes: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/03/webrev/ If somebody is able to provide me with a solaris patch, I can happily include it. Otherwise, solaris will stay as-is. Thoughts? OK to push? Thanks, Severin > Best regards > Christoph > > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 4. Juli 2019 11:39 > > To: Langer, Christoph ; Andrew John Hughes > > ; jdk8u-dev > > Cc: build-dev > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization > > > > Hi Christoph, > > > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > > > Here you go: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > 8210761/jdk8/02/webrev/ > > > > > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate any > > > > testers for those platforms. > > > > > > I pulled the patch into our test environment. It will be run for AIX > > > and solaris there. Will let you know the results... > > > > Any update? > > > > Thanks, > > Severin From christoph.langer at sap.com Thu Jul 4 12:20:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 4 Jul 2019 12:20:40 +0000 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> Message-ID: Hi Severin, as we have the Solaris infrastructure in-house, let me try to produce something for Solaris. I'll get back to you soon... Cheers Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 4. Juli 2019 14:18 > To: Langer, Christoph ; Andrew John Hughes > ; jdk8u-dev > Cc: build-dev > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization > > Hi Christoph, > > On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > sorry, this item got drained down in my pile of work. > > > > AIX looks good. For Solaris, however, there is a problem. > > > > This is an excerpt of the logs: > > SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ > > -M jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig -mt > -xnolib -xO4 -g0 -xs -o libjsig.so > sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl > > cc: Warning: Option -0 passed to ld, if ld is invoked, ignored otherwise > > ld: fatal: unrecognized option '-0' > > ld: fatal: use the '-z help' option for usage information > > Thanks for this info! > > > Seems like the options don't work for Oracle Studio (12 u1) when > > compiling and linking in one go. A fix would be to split compilation > > and linking of the lib into 2 steps, I guess. > > As I don't have access to such a system and test a potential patch, > I've removed the solaris changes: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210761/jdk8/03/webrev/ > > If somebody is able to provide me with a solaris patch, I can happily > include it. Otherwise, solaris will stay as-is. > > Thoughts? OK to push? > > Thanks, > Severin > > > Best regards > > Christoph > > > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Donnerstag, 4. Juli 2019 11:39 > > > To: Langer, Christoph ; Andrew John Hughes > > > ; jdk8u-dev > > > Cc: build-dev > > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > optimization > > > > > > Hi Christoph, > > > > > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > > > > Here you go: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > 8210761/jdk8/02/webrev/ > > > > > > > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate any > > > > > testers for those platforms. > > > > > > > > I pulled the patch into our test environment. It will be run for AIX > > > > and solaris there. Will let you know the results... > > > > > > Any update? > > > > > > Thanks, > > > Severin From stooke at redhat.com Thu Jul 4 13:22:23 2019 From: stooke at redhat.com (Simon Tooke) Date: Thu, 4 Jul 2019 09:22:23 -0400 Subject: minimal backport of 8182299 build on OSX 10 + Xcode 8 In-Reply-To: <1059C67E-7E46-4F80-A066-388ACB879149@amazon.com> References: <1059C67E-7E46-4F80-A066-388ACB879149@amazon.com> Message-ID: <53f48fda-138b-68ba-ea41-8976efbd6118@redhat.com> On 7/3/2019 4:50 PM, Hohensee, Paul wrote: > There are quite a few JBS issues that fix gcc 7 and 8 compilation problems. Possibly backporting these will fix most/all of clang's complaints as well. I would prefer to address compiler warnings sepaately; they are a really big rabbit hole. In fact, I'd rather address runtime undefined behaviours first; fixing these often fixes compile-time warnings too. -Simon > > Paul > > ?On 7/3/19, 1:33 PM, "jdk8u-dev on behalf of Simon Tooke" wrote: > > > On 7/3/2019 4:03 PM, Andrew John Hughes wrote: > > > > On 03/07/2019 19:30, Ben Evans wrote: > >> Hi, > >> > >> As this appears to have been Warnock'd ( > >> https://en.wikipedia.org/wiki/Warnock%27s_dilemma), allow me to give it > >> another kick. > >> > >> My personal take (for the little that it's worth) is: Given current > >> adoption rates and trends, JDK 8 is going to be with us for a long time. > >> Restricting the potential community size of developers working on OpenJDK 8 > >> by: > >> > >> 1.) Requiring that people who develop on Macs jump through virtualisation > >> hoops and > >> 2.) Making the building of binaries a byzantine process requiring the > >> maintenance of obsolete Macs > >> > >> is bad, and we should stop doing it. > >> > >> Thanks, > >> > >> Ben > >> > >> On Fri, Jun 28, 2019 at 4:09 PM Simon Tooke wrote: > >> > >>> Hello everyone, > >>> > >>> I would like to make a somewhat controversial proposal: to backport the > >>> minimal changes required to enable jdk8u to compile and run when built > >>> with the latest macOS developer tools. > >>> > >>> I realize this falls outside of aph's guidelines of "bug fixes only, > >>> (for now)" and in many ways is only a developer convenience, since I am > >>> not advocating (at this time) for this build to become the default > >>> supported for macOS [1]. > >>> > >>> There changes do not affect the current mac build, which requires an old > >>> version of Xcode which doesn't run on modern releases of macOS, but they > >>> make it much easier for macOS hackers to work with jdk8. > >>> > >>> At this point, testing has been confined to bootstrapping the build with > >>> a jdk8 built using this patch, and to using this build to build a > >>> working Graal substrateVM. > >>> > >>> My version of the backport limits the scope of the 8182299 patches to > >>> the subset required to get the JDK up and running. I don't propose > >>> backporting any changes to remove Clang warnings, etc. Because of that, > >>> my changes are confined in scope. > >>> > >>> Potential long term benefits (if this build does seem healthy enough for > >>> production) are simplified macOS build platforms, a more modern compiler > >>> and perhaps higher performance. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8182656 > >>> > >>> Webrev: http://cr.openjdk.java.net/~stooke/webrevs/xcodemacos.webrev/ > >>> > >>> Thanks for your time, > >>> > >>> -Simon > >>> > >>> [1] first, potentially removes support for macOS 10.8, second, needs > >>> more testing. > >>> > >>> > >>> > > I saw it, but there's a CPU on right now. I'll have a look properly once > > that's out of the way. > Yes, I know this is very much on the back burner for now. > > My initial thought is what is the subset you refer to? The problem with > > backporting bits of a change is that it then looks like that change is > > backported, but some parts of it are actually missing. > > We could avoid referring to the initial patch altogether; a large part > of it (which I avoided) was simply getting rid of clang warning > messages. I just went for the bits that stop the crash, and skipped the > rest. > > > > > From aph at redhat.com Thu Jul 4 14:01:09 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Jul 2019 15:01:09 +0100 Subject: minimal backport of 8182299 build on OSX 10 + Xcode 8 In-Reply-To: <53f48fda-138b-68ba-ea41-8976efbd6118@redhat.com> References: <1059C67E-7E46-4F80-A066-388ACB879149@amazon.com> <53f48fda-138b-68ba-ea41-8976efbd6118@redhat.com> Message-ID: On 7/4/19 2:22 PM, Simon Tooke wrote: > In fact, I'd rather address runtime undefined behaviours first; fixing > these often fixes compile-time warnings too. Which reminds me: I'm hoping to raise the subject of Undefined Behaviour in HotSpot at the OpenJDK Contributors' Meeting this year. I'd like to have a blanket policy that all of it has to go. There are a couple of exceptions for things that are undefined in Standard C but defined in GNU C: these are OK, I believe. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu Jul 4 16:40:51 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 4 Jul 2019 17:40:51 +0100 Subject: [8u] RFR 8151486: Class.forName causes memory leak In-Reply-To: <2b63e90e-9bd4-10ab-7b8e-81f7dfd8448d@redhat.com> References: <2b63e90e-9bd4-10ab-7b8e-81f7dfd8448d@redhat.com> Message-ID: <6a0c57ce-c6ec-1105-3632-c0f487195f28@redhat.com> On 02/07/2019 11:32, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8151486 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1f044f413e6c > > The product change is exactly the same. I had to massage the test to work on 8u, though: > jdk.testlibrary.JarUtils is in different place, and has a little different method we should use for > createJarFile. The test fails without the product change, and passes with it. > > 8u webrev: > http://cr.openjdk.java.net/~shade/8151486/webrev.8u.01/ > > Testing: new test, "tier1"-like profile > Looks fine. I wonder if, long term, we should try and bring JarUtils into line. It seems to have been introduced in 9 by JDK-8142968 (Module Implementation, which we obviously can't backport) in test/lib/testlibrary/JarUtils.java But then JDK-8049171 (Additional tests for jarsigner's warnings) in 8u & 9u adds it as test/lib/testlibrary/jdk/testlibrary/JarUtils.java, so 9 actually ends up with two copies. This seems to have been then later resolved by JDK-8180888: move jdk.testlibrary.JarUtils to the top level testlibrary. So JDK-8151486 was written against a different JarUtils introduced by JDK-8142968 that isn't in 8u! -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Fri Jul 5 14:06:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 5 Jul 2019 16:06:41 +0200 Subject: [8u] RFR 8151486: Class.forName causes memory leak In-Reply-To: <6a0c57ce-c6ec-1105-3632-c0f487195f28@redhat.com> References: <2b63e90e-9bd4-10ab-7b8e-81f7dfd8448d@redhat.com> <6a0c57ce-c6ec-1105-3632-c0f487195f28@redhat.com> Message-ID: <8485b78e-e70a-579a-66eb-09169ed5d427@redhat.com> On 7/4/19 6:40 PM, Andrew John Hughes wrote: > Looks fine. Thanks. I would push shortly. > I wonder if, long term, we should try and bring JarUtils into line. Yes, the whole rearrangement of test infra is quite a mess for the backports. Not only JarUtils, but the entire testlibrary, along with WhiteBox is something that irritatingly moves between releases. -- Thanks, -Aleksey From sgehwolf at redhat.com Fri Jul 5 16:52:06 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 05 Jul 2019 18:52:06 +0200 Subject: RFR: [8u] JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com> References: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com> Message-ID: <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com> Hi Andrew, On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/ > > OpenJDK 8u uses an older version of the CLDR data to 9, and is thus > missing a number of locale data files updated by the original version of > 8218781. Thus, some chunks are absent from the 8u backport. Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't finding anything. Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See: https://bugs.openjdk.java.net/browse/JDK-8062006 In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will result in the default list, which is JRE,SPI as far as I can see. > In most cases, this actually makes no difference in testing, because the > locale data files for hr, in, lt, nl and sv simply duplicate the English > values. Thus, the only ones that fail the test are no (uses a short era > of "R") and sr_Latn ("Reiva"). Right, but why intentionally introduce test failures? I'm worried about signal vs. noise here. > I propose that we apply 8218781 for the locales we have now, and look at > backporting updated CLDR data for 8u232 or 8u242. The updates - > primarily JDK-8008577 - are tied up with configuration changes which we > don't want to import to 8, so a backport will require some work and > significant testing. > > In short, please review this patch, taking into consideration that some > locales will be absent and that data is duplicated for others > (JDK-8159943, not in 8u, makes the short and long eras use a shared > variable where they are identical) Have you considered something like this patch so as to avoid the test failures and then re-enable them once a fix comes in? diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java --- a/test/java/util/Calendar/JapanEraNameCompatTest.java +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java @@ -96,12 +96,12 @@ { new Locale("hi", "IN"), HindiName, HindiName }, { new Locale("ru"), RussianName, RussianName }, { new Locale("sr"), SerbianName, SerbianName }, - { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName }, + //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName }, { new Locale("hr"), EngName, EngName }, { new Locale("in"), EngName, EngName }, { new Locale("lt"), EngName, EngName }, { new Locale("nl"), EngName, EngName }, - { new Locale("no"), EngName, "R" }, + //{ new Locale("no"), EngName, "R" }, { new Locale("sv"), EngName, EngName }, // el fallback to root { new Locale("el"), EngName, EngName } This would make it more apparent that it's intentional. Perhaps filing a bug that it's not a complete fix would be even better. Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29 From gnu.andrew at redhat.com Fri Jul 5 17:49:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 5 Jul 2019 18:49:48 +0100 Subject: RFR: [8u] JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com> References: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com> <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com> Message-ID: <8999a5c4-8cb3-9b3b-e7e0-11c04ce1b8a2@redhat.com> On 05/07/2019 17:52, Severin Gehwolf wrote: > Hi Andrew, > > On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/ >> >> OpenJDK 8u uses an older version of the CLDR data to 9, and is thus >> missing a number of locale data files updated by the original version of >> 8218781. Thus, some chunks are absent from the 8u backport. > > Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't > finding anything. > Ah, so it wasn't a typo on my part in 8u. > Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See: > https://bugs.openjdk.java.net/browse/JDK-8062006 > > In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will > result in the default list, which is JRE,SPI as far as I can see. > Yes, it's effectively redundant. I guess we could remove it but it then creates divergence. >> In most cases, this actually makes no difference in testing, because the >> locale data files for hr, in, lt, nl and sv simply duplicate the English >> values. Thus, the only ones that fail the test are no (uses a short era >> of "R") and sr_Latn ("Reiva"). > > Right, but why intentionally introduce test failures? I'm worried about > signal vs. noise here. > >> I propose that we apply 8218781 for the locales we have now, and look at >> backporting updated CLDR data for 8u232 or 8u242. The updates - >> primarily JDK-8008577 - are tied up with configuration changes which we >> don't want to import to 8, so a backport will require some work and >> significant testing. >> >> In short, please review this patch, taking into consideration that some >> locales will be absent and that data is duplicated for others >> (JDK-8159943, not in 8u, makes the short and long eras use a shared >> variable where they are identical) > > Have you considered something like this patch so as to avoid the test > failures and then re-enable them once a fix comes in? > That seems like a good way to make sure it doesn't get fixed. > diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java > --- a/test/java/util/Calendar/JapanEraNameCompatTest.java > +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java > @@ -96,12 +96,12 @@ > { new Locale("hi", "IN"), HindiName, HindiName }, > { new Locale("ru"), RussianName, RussianName }, > { new Locale("sr"), SerbianName, SerbianName }, > - { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName }, > + //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName }, > { new Locale("hr"), EngName, EngName }, > { new Locale("in"), EngName, EngName }, > { new Locale("lt"), EngName, EngName }, > { new Locale("nl"), EngName, EngName }, > - { new Locale("no"), EngName, "R" }, > + //{ new Locale("no"), EngName, "R" }, > { new Locale("sv"), EngName, EngName }, > // el fallback to root > { new Locale("el"), EngName, EngName } > > This would make it more apparent that it's intentional. Perhaps filing > a bug that it's not a complete fix would be even better. Thoughts? > As I said, the intention is to look at the viability of backporting the updated CLDR data. There are already bugs for that. > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29 > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From srl at icu-project.org Fri Jul 5 18:30:51 2019 From: srl at icu-project.org (Steven R. Loomis) Date: Fri, 5 Jul 2019 11:30:51 -0700 Subject: RFR: [8u] JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: <8999a5c4-8cb3-9b3b-e7e0-11c04ce1b8a2@redhat.com> References: <0e093fe1-2bc5-c1ba-0f69-3e1754ebdef4@redhat.com> <17daddcde35ed4f072a7502c10388a25f49924db.camel@redhat.com> <8999a5c4-8cb3-9b3b-e7e0-11c04ce1b8a2@redhat.com> Message-ID: [Resend from the correct address?] Hi all, For what it?s worth, CLDR itself doesn?t usually ?backport? data. (So there?s no CLDR source for such a backport.) I don?t know if CLDR has ever released a dot release for a release past the last released major version. FYI, For ICU, what we did (for a large number of releases) is a very specific spot fix of the locale data. - icu4j changes for 56.2 including binary data locale blob change: https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32 - icu4c changes for 56.2 including textual changes to the intermediate format: https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43 Example: https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384 ( change for Japanese ) -- Steven R. Loomis | @srl295 | git.io/srl295 > El jul. 5, 2019, a las 10:49 a. m., Andrew John Hughes escribi?: > > > > On 05/07/2019 17:52, Severin Gehwolf wrote: >> Hi Andrew, >> >> On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/ >>> >>> OpenJDK 8u uses an older version of the CLDR data to 9, and is thus >>> missing a number of locale data files updated by the original version of >>> 8218781. Thus, some chunks are absent from the 8u backport. >> >> Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't >> finding anything. >> > > Ah, so it wasn't a typo on my part in 8u. > >> Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See: >> https://bugs.openjdk.java.net/browse/JDK-8062006 >> >> In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will >> result in the default list, which is JRE,SPI as far as I can see. >> > > Yes, it's effectively redundant. I guess we could remove it but it then > creates divergence. > >>> In most cases, this actually makes no difference in testing, because the >>> locale data files for hr, in, lt, nl and sv simply duplicate the English >>> values. Thus, the only ones that fail the test are no (uses a short era >>> of "R") and sr_Latn ("Reiva"). >> >> Right, but why intentionally introduce test failures? I'm worried about >> signal vs. noise here. >> >>> I propose that we apply 8218781 for the locales we have now, and look at >>> backporting updated CLDR data for 8u232 or 8u242. The updates - >>> primarily JDK-8008577 - are tied up with configuration changes which we >>> don't want to import to 8, so a backport will require some work and >>> significant testing. >>> >>> In short, please review this patch, taking into consideration that some >>> locales will be absent and that data is duplicated for others >>> (JDK-8159943, not in 8u, makes the short and long eras use a shared >>> variable where they are identical) >> >> Have you considered something like this patch so as to avoid the test >> failures and then re-enable them once a fix comes in? >> > > That seems like a good way to make sure it doesn't get fixed. > >> diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java >> --- a/test/java/util/Calendar/JapanEraNameCompatTest.java >> +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java >> @@ -96,12 +96,12 @@ >> { new Locale("hi", "IN"), HindiName, HindiName }, >> { new Locale("ru"), RussianName, RussianName }, >> { new Locale("sr"), SerbianName, SerbianName }, >> - { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName }, >> + //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName }, >> { new Locale("hr"), EngName, EngName }, >> { new Locale("in"), EngName, EngName }, >> { new Locale("lt"), EngName, EngName }, >> { new Locale("nl"), EngName, EngName }, >> - { new Locale("no"), EngName, "R" }, >> + //{ new Locale("no"), EngName, "R" }, >> { new Locale("sv"), EngName, EngName }, >> // el fallback to root >> { new Locale("el"), EngName, EngName } >> >> This would make it more apparent that it's intentional. Perhaps filing >> a bug that it's not a complete fix would be even better. Thoughts? >> > > As I said, the intention is to look at the viability of backporting the > updated CLDR data. There are already bugs for that. > >> Thanks, >> Severin >> >> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29 >> > > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > From gnu.andrew at redhat.com Mon Jul 8 02:49:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 8 Jul 2019 03:49:31 +0100 Subject: RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8224560 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.01/ This is the 8u version of the patch proposed in [0]. It mostly applies as is, but the CLDRConverter.java changes can be dropped (no JDK-8189784 and friends in 8u). The changes to TestZoneInfo310.java ideally should be applied after JDK-8157792, which is a clean backport I have also flagged with jdk8u-fix-request. I don't know whether we want to still try and include this in 8u222 or not. It is pretty late and people may already be testing finished builds. Ok for 8u-dev? [0] https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Mon Jul 8 12:35:56 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 08 Jul 2019 14:35:56 +0200 Subject: [8u] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Message-ID: Hi Andrew, On Fri, 2019-06-28 at 14:45 +0100, Andrew John Hughes wrote: > On 28/06/2019 10:52, Severin Gehwolf wrote: > > Hi Andrew, > > > > On Thu, 2019-06-27 at 17:36 +0100, Andrew John Hughes wrote: > > > On 22/05/2019 17:34, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this minimal implementation of a tier1- > > > > like test set for JDK 8u? The implementation is rather barebones as I > > > > don't think it's worth rewriting the build system just for a command > > > > that runs a certain set of tests across a select set of repositories. > > > > I've re-used existing work in Makefiles as much as possible. After this > > > > patch one can do: > > > > > > > > $ make test TEST="tier1" > > > > > > > > Inspiration came from JDK 11u's tier1. As for prior art to this, I've > > > > only found "make test" to be working for JDK 8u from the top level. > > > > Yet, it doesn't run any hotspot tests, exits with a zero code on test > > > > failures and doesn't present a summary at the end. Overall not a nice > > > > developer experience. > > > > > > > > This patch makes it easier for a developers tests. It presents a > > > > summary at the end, returns non-zero on test failures so this can get > > > > used in CI and runs hotspot tests. > > > > > > > > As a follow-on we can work on fixing/excluding tests so that we always > > > > have a passing set of tests for developers to run before a checkin. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ > > > > (includes changes to top/hotspot/jdk/langtools repos) > > > > > > > > Example excerpt from a run: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt > > > > > > > > Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > > > > > > > Is there a reason for creating new tier definitions here rather than > > > backporting the existing ones? > > > > Yes. The tests in JDK 8 are significantly different from JDK 11. Most > > notably the number of tests available and defined test groups. > > Backporting the JDK 11 changes seems like fitting a square peg into a > > round hole. > > > > The JDK 8u "tier1" could only be a rough approximation of the JDK 11 > > "tier1" at best. There is also no intention to make the test output > > 100% identical to JDK 11 as bringing back those changes would be too > > invasive. > > > > I believe the proposed patch is a reasonable minimal patch which aids > > 8u developer's testing. > > > > > https://bugs.openjdk.java.net/browse/JDK-8075543 > > > > > > The subtasks also cover nashorn & jaxp which are missed here. jaxp would > > > need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg. > > > > Sure. We can consider adding later tiers in upcoming work. That's not > > the priority, though. Note that tier1 tests in JDK 11 only run > > jdk/lantools/hotspot tests. The intention of this initial patch would > > be to have some testing "baseline" covering a reasonable set of repos > > and tests. > > > > Thanks, > > Severin > > > > I'm not talking about JDK 11 changes. These are changes in JDK 9. > > For example, > > https://hg.openjdk.java.net/jdk9/dev/jdk/rev/cd4aea326e89 > > adds groups to two tiers, all of which exist in 8u as well. It's not > clear where the list in your patch comes from and it appears to add a > bunch of arbitrary other tests beyond the tier 1 defined in the JDK 9 > change. Other changes to the JDK tier1 definition were taken from current JDK 11u. > It would make more sense to me to backport JDK-8075544 & JDK-8075573 as > pre-requisites rather than creating completely new definitions. Done now. I've added fix-request comments/labels to the above bugs and rebased on top of them. New jdk changeset: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK- 8132854. OK to push? Thanks, Severin From andrew_m_leonard at uk.ibm.com Mon Jul 8 17:17:10 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 8 Jul 2019 18:17:10 +0100 Subject: RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a Message-ID: Note, jdk/test/java/util/Calendar currently don't all pass, suspect this will fix that? FAILED: java/util/Calendar/CalendarRegression.java FAILED: java/util/Calendar/JapanEraNameCompatTest.java Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com 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 christoph.langer at sap.com Mon Jul 8 21:42:41 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 8 Jul 2019 21:42:41 +0000 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> Message-ID: Hi Severin, I have a solution for Solaris. In your webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/02/webrev/, make/solaris/makefiles/jsig.make, Line 52: JSIG_OPT_FLAGS = $(OPT_CFLAGS) Should be: JSIG_OPT_FLAGS = -xO4 -g OPT_CFLAGS are the opt flags for the C++ compiler, but libjsig.o is compiled with the C compiler. And the C compiler does not like -g0 but needs just -g. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 4. Juli 2019 14:21 > To: Severin Gehwolf ; Andrew John Hughes > ; jdk8u-dev > Cc: build-dev > Subject: RE: [8u] RFR: 8210761: libjsig is being compiled without optimization > > Hi Severin, > > as we have the Solaris infrastructure in-house, let me try to produce > something for Solaris. I'll get back to you soon... > > Cheers > Christoph > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 4. Juli 2019 14:18 > > To: Langer, Christoph ; Andrew John Hughes > > ; jdk8u-dev > > Cc: build-dev > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > optimization > > > > Hi Christoph, > > > > On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: > > > Hi Severin, > > > > > > sorry, this item got drained down in my pile of work. > > > > > > AIX looks good. For Solaris, however, there is a problem. > > > > > > This is an excerpt of the logs: > > > SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ > > > -M jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig - > mt > > -xnolib -xO4 -g0 -xs -o libjsig.so > > sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl > > > cc: Warning: Option -0 passed to ld, if ld is invoked, ignored otherwise > > > ld: fatal: unrecognized option '-0' > > > ld: fatal: use the '-z help' option for usage information > > > > Thanks for this info! > > > > > Seems like the options don't work for Oracle Studio (12 u1) when > > > compiling and linking in one go. A fix would be to split compilation > > > and linking of the lib into 2 steps, I guess. > > > > As I don't have access to such a system and test a potential patch, > > I've removed the solaris changes: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210761/jdk8/03/webrev/ > > > > If somebody is able to provide me with a solaris patch, I can happily > > include it. Otherwise, solaris will stay as-is. > > > > Thoughts? OK to push? > > > > Thanks, > > Severin > > > > > Best regards > > > Christoph > > > > > > > > > > -----Original Message----- > > > > From: Severin Gehwolf > > > > Sent: Donnerstag, 4. Juli 2019 11:39 > > > > To: Langer, Christoph ; Andrew John > Hughes > > > > ; jdk8u-dev dev at openjdk.java.net> > > > > Cc: build-dev > > > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > optimization > > > > > > > > Hi Christoph, > > > > > > > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > > > > > Here you go: > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > > > > 8210761/jdk8/02/webrev/ > > > > > > > > > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate any > > > > > > testers for those platforms. > > > > > > > > > > I pulled the patch into our test environment. It will be run for AIX > > > > > and solaris there. Will let you know the results... > > > > > > > > Any update? > > > > > > > > Thanks, > > > > Severin From chengjingwei1 at huawei.com Tue Jul 9 08:51:14 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Tue, 9 Jul 2019 08:51:14 +0000 Subject: Request for backporting [JDK-8135318] Message-ID: max_eden_size is wrongly calculated in CMSCollector::acquire_control_and_collect, as reported in JBS. This issue has already been fixed in jdk9, and should have been backported to jdk8u, but nobody did it. I haven't signed the OCA so I can't make a patch. Would someone help with backporting this? BTW, this patch applies cleanly in jdk8u. From sgehwolf at redhat.com Tue Jul 9 09:10:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Jul 2019 11:10:16 +0200 Subject: Request for backporting [JDK-8135318] In-Reply-To: References: Message-ID: <0b8d98eb8b364901016c94afc03847c737561aef.camel@redhat.com> Hi, On Tue, 2019-07-09 at 08:51 +0000, chengjingwei (A) wrote: > max_eden_size is wrongly calculated in > CMSCollector::acquire_control_and_collect, as reported in JBS. > This issue has already been fixed in jdk9, and should have been > backported to jdk8u, but nobody did it. > I haven't signed the OCA so I can't make a patch. > Would someone help with backporting this? > BTW, this patch applies cleanly in jdk8u. Seems easy enough to backport. I'll look into it. If all goes well it'll be part of 8u232 in October. Thanks, Severin From sgehwolf at redhat.com Tue Jul 9 10:09:25 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Jul 2019 12:09:25 +0200 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> Message-ID: Hi Christoph, On Mon, 2019-07-08 at 21:42 +0000, Langer, Christoph wrote: > Hi Severin, > > I have a solution for Solaris. > > In your webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/02/webrev/, make/solaris/makefiles/jsig.make, Line 52: JSIG_OPT_FLAGS = $(OPT_CFLAGS) > > Should be: JSIG_OPT_FLAGS = -xO4 -g > > OPT_CFLAGS are the opt flags for the C++ compiler, but libjsig.o is compiled with the C compiler. And the C compiler does not like -g0 but needs just -g. Thanks! webrev #04 is here: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/04/webrev/ Good to go? Thanks, Severin > -----Original Message----- From: Langer, Christoph Sent: Donnerstag, 4. Juli 2019 14:21 To: Severin Gehwolf ; Andrew John Hughes ; jdk8u-dev Cc: build-dev Subject: RE: [8u] RFR: 8210761: libjsig is being compiled without optimization Hi Severin, as we have the Solaris infrastructure in-house, let me try to produce something for Solaris. I'll get back to you soon... Cheers Christoph -----Original Message----- From: Severin Gehwolf Sent: Donnerstag, 4. Juli 2019 14:18 To: Langer, Christoph ; Andrew John Hughes ; jdk8u-dev Cc: build-dev Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization Hi Christoph, On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: Hi Severin, sorry, this item got drained down in my pile of work. AIX looks good. For Solaris, however, there is a problem. This is an excerpt of the logs: SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ -M jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig - mt -xnolib -xO4 -g0 -xs -o libjsig.so sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl cc: Warning: Option -0 passed to ld, if ld is invoked, ignored otherwise ld: fatal: unrecognized option '-0' ld: fatal: use the '-z help' option for usage information Thanks for this info! Seems like the options don't work for Oracle Studio (12 u1) when compiling and linking in one go. A fix would be to split compilation and linking of the lib into 2 steps, I guess. As I don't have access to such a system and test a potential patch, I've removed the solaris changes: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- 8210761/jdk8/03/webrev/ If somebody is able to provide me with a solaris patch, I can happily include it. Otherwise, solaris will stay as-is. Thoughts? OK to push? Thanks, Severin Best regards Christoph -----Original Message----- From: Severin Gehwolf Sent: Donnerstag, 4. Juli 2019 11:39 To: Langer, Christoph ; Andrew John Hughes ; jdk8u-dev Cc: build-dev Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization Hi Christoph, On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: Here you go: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- 8210761/jdk8/02/webrev/ I cannot really test on bsd, solaris or aix, though :( Appreciate any testers for those platforms. I pulled the patch into our test environment. It will be run for AIX and solaris there. Will let you know the results... Any update? Thanks, Severin From chengjingwei1 at huawei.com Tue Jul 9 11:21:24 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Tue, 9 Jul 2019 11:21:24 +0000 Subject: Request for backporting [JDK-8135318] In-Reply-To: <0b8d98eb8b364901016c94afc03847c737561aef.camel@redhat.com> References: <0b8d98eb8b364901016c94afc03847c737561aef.camel@redhat.com> Message-ID: Appreciate that. Thanks for your help and quick reply. -----Original Message----- From: Severin Gehwolf [mailto:sgehwolf at redhat.com] Sent: Tuesday, July 09, 2019 5:10 PM To: chengjingwei (A) ; jdk8u-dev at openjdk.java.net Subject: Re: Request for backporting [JDK-8135318] Hi, On Tue, 2019-07-09 at 08:51 +0000, chengjingwei (A) wrote: > max_eden_size is wrongly calculated in > CMSCollector::acquire_control_and_collect, as reported in JBS. > This issue has already been fixed in jdk9, and should have been > backported to jdk8u, but nobody did it. > I haven't signed the OCA so I can't make a patch. > Would someone help with backporting this? > BTW, this patch applies cleanly in jdk8u. Seems easy enough to backport. I'll look into it. If all goes well it'll be part of 8u232 in October. Thanks, Severin From christoph.langer at sap.com Tue Jul 9 12:35:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 9 Jul 2019 12:35:15 +0000 Subject: [11u, 8u]: OpenJDK update releases 11.0.6 and 8u242: Created JBS filter views and published preliminary timeline on Wiki Message-ID: Hi, I just wanted to notify everybody that I've just created JBS backport issue filters for the January 2020 releases 11.0.6 and 8u242. The Wiki pages [1],[2] were updated accordingly along with a preliminary timeline for these releases. The date for the CPU code freeze falls into the Christmas holidays so we'll probably have to adjust this a bit eventually. The filters also received a small bugfix. In the backport view, one will now only see issues that Oracle has already resolved for the relevant update release. When the query finds backport items that are still unresolved or marked as "Won't fix", the according bug will not appear in the list. Best regards Christoph [1] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u [2] https://wiki.openjdk.java.net/display/jdk8u From sgehwolf at redhat.com Tue Jul 9 12:37:09 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Jul 2019 14:37:09 +0200 Subject: [8u] RFR: 8135318: CMS wrong max_eden_size for check_gc_overhead_limit Message-ID: Hi, Could I please get a review for this OpenJDK 8u backport? It's essentially the same patch as in JDK 9+, but it didn't apply cleanly since the surrounding code is different and the files were moved around. Adjustments I've done: JDK 8u uses a different file layout: src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp => src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp JDK 8u doesn't have JDK-8065972 and JDK-8065992, which account for the surrounding code changes. Note that JDK-8065992 makes the _young_gen instance variable ParNewGEneration* from Generation*. Bug: https://bugs.openjdk.java.net/browse/JDK-8135318 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8135318/01/webrev/ JDK 9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/dd0c55eac358 Testing: "tier1" testing of Linux x86_64 which showed no new regressions. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Tue Jul 9 19:59:05 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 9 Jul 2019 20:59:05 +0100 Subject: RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a In-Reply-To: References: Message-ID: <5a8caabd-80de-9630-db19-dfa35aecb05a@redhat.com> On 08/07/2019 18:17, Andrew Leonard wrote: > Note, jdk/test/java/util/Calendar currently don't all pass, suspect this > will fix that? > > FAILED: java/util/Calendar/CalendarRegression.java > FAILED: java/util/Calendar/JapanEraNameCompatTest.java > > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > 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 > These are new tests introduced by JDK-8031145 & JDK-8219781, which I believe are failing due to old locale data in 8u. We'll be looking into that further after the CPU, but it's not resolved by this timezone data update. The tests in sun/util/calendar, sun/util/resources/TimeZone all passed with this change, as did all java/util/TimeZone tests except the newly introduced java/util/TimeZone/HongKong.java (again, a translation issue rather than tzdata). -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Jul 10 09:08:50 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Jul 2019 09:08:50 +0000 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> Message-ID: Hi Severin, You made a little mistake. It must be "-xO4" instead of "-x04" in the Solaris build file (It's the letter O instead of the number 0) ?? Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 9. Juli 2019 12:09 > To: Langer, Christoph > Cc: build-dev ; Andrew John Hughes > ; jdk8u-dev > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization > > Hi Christoph, > > On Mon, 2019-07-08 at 21:42 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > I have a solution for Solaris. > > > > In your webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210761/jdk8/02/webrev/, make/solaris/makefiles/jsig.make, Line 52: > JSIG_OPT_FLAGS = $(OPT_CFLAGS) > > > > Should be: JSIG_OPT_FLAGS = -xO4 -g > > > > OPT_CFLAGS are the opt flags for the C++ compiler, but libjsig.o is compiled > with the C compiler. And the C compiler does not like -g0 but needs just -g. > > Thanks! webrev #04 is here: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210761/jdk8/04/webrev/ > > Good to go? > > Thanks, > Severin > > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 4. Juli 2019 14:21 > To: Severin Gehwolf ; Andrew John Hughes > ; jdk8u-dev > Cc: build-dev > Subject: RE: [8u] RFR: 8210761: libjsig is being compiled without optimization > > Hi Severin, > > as we have the Solaris infrastructure in-house, let me try to produce > something for Solaris. I'll get back to you soon... > > Cheers > Christoph > > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 4. Juli 2019 14:18 > To: Langer, Christoph ; Andrew John Hughes > ; jdk8u-dev > Cc: build-dev > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > optimization > Hi Christoph, > > On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: > Hi Severin, > > sorry, this item got drained down in my pile of work. > > AIX looks good. For Solaris, however, there is a problem. > > This is an excerpt of the logs: > SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ > -M jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig - > mt > -xnolib -xO4 -g0 -xs -o libjsig.so > sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl > cc: Warning: Option -0 passed to ld, if ld is invoked, ignored otherwise > ld: fatal: unrecognized option '-0' > ld: fatal: use the '-z help' option for usage information > > Thanks for this info! > > Seems like the options don't work for Oracle Studio (12 u1) when > compiling and linking in one go. A fix would be to split compilation > and linking of the lib into 2 steps, I guess. > > As I don't have access to such a system and test a potential patch, > I've removed the solaris changes: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210761/jdk8/03/webrev/ > > If somebody is able to provide me with a solaris patch, I can happily > include it. Otherwise, solaris will stay as-is. > > Thoughts? OK to push? > > Thanks, > Severin > > Best regards > Christoph > > > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 4. Juli 2019 11:39 > To: Langer, Christoph ; Andrew John > Hughes > ; jdk8u-dev dev at openjdk.java.net> > Cc: build-dev > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > optimization > Hi Christoph, > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > Here you go: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210761/jdk8/02/webrev/ > > I cannot really test on bsd, solaris or aix, though :( Appreciate any > testers for those platforms. > > I pulled the patch into our test environment. It will be run for AIX > and solaris there. Will let you know the results... > > Any update? > > Thanks, > Severin From sgehwolf at redhat.com Wed Jul 10 09:24:55 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 10 Jul 2019 11:24:55 +0200 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> Message-ID: <2f8fd3b44227e9c54a42202381016d1538d16fb5.camel@redhat.com> Hi Christoph, On Wed, 2019-07-10 at 09:08 +0000, Langer, Christoph wrote: > Hi Severin, > > You made a little mistake. It must be "-xO4" instead of "-x04" in the > Solaris build file (It's the letter O instead of the number 0) ?? Sigh. Take 5: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/05/webrev/ Thanks again for your help! Cheers, Severin > > Best regards > Christoph > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Dienstag, 9. Juli 2019 12:09 > > To: Langer, Christoph > > Cc: build-dev ; Andrew John Hughes > > ; jdk8u-dev > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > optimization > > > > Hi Christoph, > > > > On Mon, 2019-07-08 at 21:42 +0000, Langer, Christoph wrote: > > > Hi Severin, > > > > > > I have a solution for Solaris. > > > > > > In your webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210761/jdk8/02/webrev/, make/solaris/makefiles/jsig.make, Line 52: > > JSIG_OPT_FLAGS = $(OPT_CFLAGS) > > > Should be: JSIG_OPT_FLAGS = -xO4 -g > > > > > > OPT_CFLAGS are the opt flags for the C++ compiler, but libjsig.o > > > is compiled > > with the C compiler. And the C compiler does not like -g0 but needs > > just -g. > > > > Thanks! webrev #04 is here: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210761/jdk8/04/webrev/ > > > > Good to go? > > > > Thanks, > > Severin > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Donnerstag, 4. Juli 2019 14:21 > > To: Severin Gehwolf ; Andrew John Hughes > > ; jdk8u-dev > > Cc: build-dev > > Subject: RE: [8u] RFR: 8210761: libjsig is being compiled without > > optimization > > > > Hi Severin, > > > > as we have the Solaris infrastructure in-house, let me try to > > produce > > something for Solaris. I'll get back to you soon... > > > > Cheers > > Christoph > > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 4. Juli 2019 14:18 > > To: Langer, Christoph ; Andrew John > > Hughes > > ; jdk8u-dev > > Cc: build-dev > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > optimization > > Hi Christoph, > > > > On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > sorry, this item got drained down in my pile of work. > > > > AIX looks good. For Solaris, however, there is a problem. > > > > This is an excerpt of the logs: > > SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ > > -M > > jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig - > > mt > > -xnolib -xO4 -g0 -xs -o libjsig.so > > sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl > > cc: Warning: Option -0 passed to ld, if ld is invoked, ignored > > otherwise > > ld: fatal: unrecognized option '-0' > > ld: fatal: use the '-z help' option for usage information > > > > Thanks for this info! > > > > Seems like the options don't work for Oracle Studio (12 u1) when > > compiling and linking in one go. A fix would be to split > > compilation > > and linking of the lib into 2 steps, I guess. > > > > As I don't have access to such a system and test a potential patch, > > I've removed the solaris changes: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210761/jdk8/03/webrev/ > > > > If somebody is able to provide me with a solaris patch, I can > > happily > > include it. Otherwise, solaris will stay as-is. > > > > Thoughts? OK to push? > > > > Thanks, > > Severin > > > > Best regards > > Christoph > > > > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 4. Juli 2019 11:39 > > To: Langer, Christoph ; Andrew John > > Hughes > > ; jdk8u-dev > dev at openjdk.java.net> > > Cc: build-dev > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > optimization > > Hi Christoph, > > > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > Here you go: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > 8210761/jdk8/02/webrev/ > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate > > any > > testers for those platforms. > > > > I pulled the patch into our test environment. It will be run for > > AIX > > and solaris there. Will let you know the results... > > > > Any update? > > > > Thanks, > > Severin From chengjingwei1 at huawei.com Wed Jul 10 10:08:17 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Wed, 10 Jul 2019 10:08:17 +0000 Subject: Request for backporting [JDK-8196485] Message-ID: This issue was originally reported and fixed in jdk11, but we have reproduced it on jdk8u too. Since the code are slightly different between these two branches, the patch doesn't apply without some necessary modification. So we tried adapting the patch into jdk8u, and got the following diff. Could some one help with merging it into openjdk8u? ==== The patch applicable to jdk8u ==== diff --git a/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp b/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp index 437636281..ad8a3562e 100644 --- a/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp +++ b/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp @@ -102,17 +102,8 @@ protected: // If the test below fails, then this table was reused concurrently // with this operation. This is OK, since the old table was coarsened, // and adding a bit to the new table is never incorrect. - // If the table used to belong to a continues humongous region and is - // now reused for the corresponding start humongous region, we need to - // make sure that we detect this. Thus, we call is_in_reserved_raw() - // instead of just is_in_reserved() here. if (loc_hr->is_in_reserved_raw(from)) { - size_t hw_offset = pointer_delta((HeapWord*)from, loc_hr->bottom()); - CardIdx_t from_card = (CardIdx_t) - hw_offset >> (CardTableModRefBS::card_shift - LogHeapWordSize); - - assert(0 <= from_card && (size_t)from_card < HeapRegion::CardsPerRegion, - "Must be in range."); + CardIdx_t from_card = OtherRegionsTable::card_within_region(from, loc_hr); add_card_work(from_card, par); } } @@ -331,6 +322,12 @@ void OtherRegionsTable::link_to_all(PerRegionTable* prt) { "just checking"); } +CardIdx_t OtherRegionsTable::card_within_region(OopOrNarrowOopStar within_region, HeapRegion* hr) { + assert(hr->is_in_reserved(within_region),"should be"); + CardIdx_t result = (CardIdx_t)(pointer_delta((HeapWord*)within_region, hr->bottom()) >> (CardTableModRefBS::card_shift - LogHeapWordSize)); + return result; +} + void OtherRegionsTable::unlink_from_all(PerRegionTable* prt) { if (prt->prev() != NULL) { assert(_first_all_fine_prts != prt, "just checking"); @@ -364,18 +361,17 @@ void OtherRegionsTable::unlink_from_all(PerRegionTable* prt) { "just checking"); } -int** FromCardCache::_cache = NULL; -uint FromCardCache::_max_regions = 0; -size_t FromCardCache::_static_mem_size = 0; +uintptr_t** FromCardCache::_cache = NULL; +uint FromCardCache::_max_regions = 0; +size_t FromCardCache::_static_mem_size = 0; void FromCardCache::initialize(uint n_par_rs, uint max_num_regions) { guarantee(_cache == NULL, "Should not call this multiple times"); _max_regions = max_num_regions; - _cache = Padded2DArray::create_unfreeable(n_par_rs, - _max_regions, - &_static_mem_size); - + _cache = Padded2DArray::create_unfreeable(n_par_rs, + _max_regions, + &_static_mem_size); invalidate(0, _max_regions); } @@ -396,7 +392,8 @@ void FromCardCache::invalidate(uint start_idx, size_t new_num_regions) { void FromCardCache::print(outputStream* out) { for (uint i = 0; i < HeapRegionRemSet::num_par_rem_sets(); i++) { for (uint j = 0; j < _max_regions; j++) { - out->print_cr("_from_card_cache[" UINT32_FORMAT "][" UINT32_FORMAT "] = " INT32_FORMAT ".", + out->print_cr("_from_card_cache[%u][%u] = " SIZE_FORMAT ".", + i, j, at(i, j)); } } @@ -433,7 +430,8 @@ void OtherRegionsTable::add_reference(OopOrNarrowOopStar from, int tid) { : (void *)oopDesc::load_decode_heap_oop((oop*)from)); } - int from_card = (int)(uintptr_t(from) >> CardTableModRefBS::card_shift); + uintptr_t from_card = uintptr_t(from) >> CardTableModRefBS::card_shift; + if (G1TraceHeapRegionRememberedSet) { gclog_or_tty->print_cr("Table for [" PTR_FORMAT "...): card %d (cache = " INT32_FORMAT ")", diff --git a/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp b/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp index 1646e8cb9..77751b4a9 100644 --- a/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp +++ b/hotspot/src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp @@ -51,21 +51,19 @@ class FromCardCache : public AllStatic { private: // Array of card indices. Indexed by thread X and heap region to minimize // thread contention. - static int** _cache; + static uintptr_t** _cache; static uint _max_regions; static size_t _static_mem_size; public: - enum { - InvalidCard = -1 // Card value of an invalid card, i.e. a card index not otherwise used. - }; + static const uintptr_t InvalidCard = UINTPTR_MAX; static void clear(uint region_idx); // Returns true if the given card is in the cache at the given location, or // replaces the card at that location and returns false. - static bool contains_or_replace(uint worker_id, uint region_idx, int card) { - int card_in_cache = at(worker_id, region_idx); + static bool contains_or_replace(uint worker_id, uint region_idx, uintptr_t card) { + uintptr_t card_in_cache = at(worker_id, region_idx); if (card_in_cache == card) { return true; } else { @@ -74,11 +72,11 @@ class FromCardCache : public AllStatic { } } - static int at(uint worker_id, uint region_idx) { + static uintptr_t at(uint worker_id, uint region_idx) { return _cache[worker_id][region_idx]; } - static void set(uint worker_id, uint region_idx, int val) { + static void set(uint worker_id, uint region_idx, uintptr_t val) { _cache[worker_id][region_idx] = val; } @@ -177,6 +175,9 @@ public: HeapRegion* hr() const { return _hr; } + // Returns the card index of the given within_region pointer relative to the bottom --------------------heapRegionRemSet.hpp:312 OtherRegionsTable + // of the given heap region. + static CardIdx_t card_within_region(OopOrNarrowOopStar within_region, HeapRegion* hr); // For now. Could "expand" some tables in the future, so that this made // sense. void add_reference(OopOrNarrowOopStar from, int tid); diff --git a/hotspot/test/gc/g1/TestFromCardCacheIndex.java b/hotspot/test/gc/g1/TestFromCardCacheIndex.java new file mode 100644 index 000000000..f2332306d --- /dev/null +++ b/hotspot/test/gc/g1/TestFromCardCacheIndex.java @@ -0,0 +1,120 @@ +/* + * @test TestFromCardCacheIndex.java + * @bug 8196485 + * @summary Ensure that G1 does not miss a remembered set entry due to from card cache default value indices. + * @key gc + * @requires vm.gc.G1 + * @requires vm.debug + * @requires vm.bits != "32" + * @library /test/lib + * @modules java.base/jdk.internal.misc + * java.management + * @build sun.hotspot.WhiteBox + * @run driver ClassFileInstaller sun.hotspot.WhiteBox + * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. -Xms20M -Xmx20M -XX:+UseCompressedOops -XX:G1HeapRegionSize=1M -XX:HeapBaseMinAddress=2199011721216 -XX:+UseG1GC -verbose:gc TestFromCardCacheIndex + */ + +import sun.hotspot.WhiteBox; + +/** + * Repeatedly tries to generate references from objects that contained a card with the same index + * of the from card cache default value. + */ +public class TestFromCardCacheIndex { + private static WhiteBox WB; + + // Shift value to calculate card indices from addresses. + private static final int CardSizeShift = 9; + + /** + * Returns the last address on the heap within the object. + * + * @param The Object array to get the last address from. + */ + private static long getObjectLastAddress(Object[] o) { + return WB.getObjectAddress(o) + WB.getObjectSize(o) - 1; + } + + /** + * Returns the (truncated) 32 bit card index for the given address. + * + * @param The address to get the 32 bit card index from. + */ + private static int getCardIndex32bit(long address) { + return (int)(address >> CardSizeShift); + } + + // The source arrays that are placed on the heap in old gen. + private static int numArrays = 7000; + private static int arraySize = 508; + // Size of a humongous byte array, a bit less than a 1M region. This makes sure + // that we always create a cross-region reference when referencing it. + private static int byteArraySize = 1024*1023; + + public static void main(String[] args) { + WB = sun.hotspot.WhiteBox.getWhiteBox(); + for (int i = 0; i < 5; i++) { + runTest(); + WB.fullGC(); + } + } + + public static void runTest() { + System.out.println("Starting test"); + + // Spray the heap with random object arrays in the hope that we get one + // at the proper place. + Object[][] arrays = new Object[numArrays][]; + for (int i = 0; i < numArrays; i++) { + arrays[i] = new Object[arraySize]; + } + + // Make sure that everything is in old gen. + WB.fullGC(); + + // Find if we got an allocation at the right spot. + Object[] arrayWithCardMinus1 = findArray(arrays); + + if (arrayWithCardMinus1 == null) { + System.out.println("Array with card -1 not found. Trying again."); + return; + } else { + System.out.println("Array with card -1 found."); + } + + System.out.println("Modifying the last card in the array with a new object in a different region..."); + // Create a target object that is guaranteed to be in a different region. + byte[] target = new byte[byteArraySize]; + + // Modify the last entry of the object we found. + arrayWithCardMinus1[arraySize - 1] = target; + + target = null; + // Make sure that the dirty cards are flushed by doing a GC. + System.out.println("Doing a GC."); + WB.youngGC(); + + System.out.println("The crash didn't reproduce. Trying again."); + } + + /** + * Finds an returns an array that contains a (32 bit truncated) card with value -1. + */ + private static Object[] findArray(Object[][] arrays) { + for (int i = 0; i < arrays.length; i++) { + Object[] target = arrays[i]; + if (target == null) { + continue; + } + final long startAddress = WB.getObjectAddress(target); + final long lastAddress = getObjectLastAddress(target); + final int card = getCardIndex32bit(lastAddress); + if (card == -1) { + Object[] foundArray = target; + return foundArray; + } + } + return null; + } +} + From gnu.andrew at redhat.com Wed Jul 10 14:01:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 10 Jul 2019 15:01:11 +0100 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: <2f8fd3b44227e9c54a42202381016d1538d16fb5.camel@redhat.com> References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> <2f8fd3b44227e9c54a42202381016d1538d16fb5.camel@redhat.com> Message-ID: On 10/07/2019 10:24, Severin Gehwolf wrote: > Hi Christoph, > > On Wed, 2019-07-10 at 09:08 +0000, Langer, Christoph wrote: >> Hi Severin, >> >> You made a little mistake. It must be "-xO4" instead of "-x04" in the >> Solaris build file (It's the letter O instead of the number 0) ?? > > Sigh. Take 5: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/jdk8/05/webrev/ > > Thanks again for your help! > > Cheers, > Severin > Looks good to me. I had a look to see if there was a cleaner way of getting the right flags for Solaris, but it seems this is part of the whole misuse of CFLAGS as C++ flags that is all over the old HotSpot build. So this is fine. Incidentally, make/solaris/makefiles/sparcWorks.make is full of conditionals to switch between -xO4 and -xO3 for different architectures and compiler versions, even down to the single file. I don't know how valid most of this still is, but best to leave it alone at this stage. Probably my favourite bit of bit rot is: # Pick which compiler is validated ifeq ($(JRE_RELEASE_VER),1.6.0) # Validated compiler for JDK6 is SS11 (5.8) VALIDATED_COMPILER_REVS := 5.8 VALIDATED_CC_COMPILER_REVS := 5.8 else # Validated compiler for JDK7 is SS12 update 1 + patches (5.10) VALIDATED_COMPILER_REVS := 5.10 VALIDATED_CC_COMPILER_REVS := 5.10 endif Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Wed Jul 10 14:08:47 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 10 Jul 2019 15:08:47 +0100 Subject: CFV: New JDK 8 Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: On 6/26/19 2:01 PM, Langer, Christoph wrote: > I hereby nominate Severin Gehwolf (sgehwolf) to JDK 8 Updates Project Reviewer. Vote: yes. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Wed Jul 10 14:19:07 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 10 Jul 2019 14:19:07 +0000 Subject: [8u] RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: <2f8fd3b44227e9c54a42202381016d1538d16fb5.camel@redhat.com> References: <24530220065b6dade99c885a7b82482d8ed8ceb5.camel@redhat.com> <0526b36ccd44c100b8cea7683fda39f25ac50093.camel@redhat.com> <2438ed153b3310efabc110ccad58c3151846ec29.camel@redhat.com> <330b31b7db0d3d8454ff9646a3bd911e973f2bcf.camel@redhat.com> <2f8fd3b44227e9c54a42202381016d1538d16fb5.camel@redhat.com> Message-ID: Hi Severin, now it's good from my end. Finally ?? Thanks Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Mittwoch, 10. Juli 2019 11:25 > To: Langer, Christoph > Cc: build-dev ; Andrew John Hughes > ; jdk8u-dev > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without optimization > > Hi Christoph, > > On Wed, 2019-07-10 at 09:08 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > You made a little mistake. It must be "-xO4" instead of "-x04" in the > > Solaris build file (It's the letter O instead of the number 0) ?? > > Sigh. Take 5: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8210761/jdk8/05/webrev/ > > Thanks again for your help! > > Cheers, > Severin > > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Dienstag, 9. Juli 2019 12:09 > > > To: Langer, Christoph > > > Cc: build-dev ; Andrew John Hughes > > > ; jdk8u-dev > > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > > optimization > > > > > > Hi Christoph, > > > > > > On Mon, 2019-07-08 at 21:42 +0000, Langer, Christoph wrote: > > > > Hi Severin, > > > > > > > > I have a solution for Solaris. > > > > > > > > In your webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8210761/jdk8/02/webrev/, make/solaris/makefiles/jsig.make, Line 52: > > > JSIG_OPT_FLAGS = $(OPT_CFLAGS) > > > > Should be: JSIG_OPT_FLAGS = -xO4 -g > > > > > > > > OPT_CFLAGS are the opt flags for the C++ compiler, but libjsig.o > > > > is compiled > > > with the C compiler. And the C compiler does not like -g0 but needs > > > just -g. > > > > > > Thanks! webrev #04 is here: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8210761/jdk8/04/webrev/ > > > > > > Good to go? > > > > > > Thanks, > > > Severin > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Donnerstag, 4. Juli 2019 14:21 > > > To: Severin Gehwolf ; Andrew John Hughes > > > ; jdk8u-dev > > > Cc: build-dev > > > Subject: RE: [8u] RFR: 8210761: libjsig is being compiled without > > > optimization > > > > > > Hi Severin, > > > > > > as we have the Solaris infrastructure in-house, let me try to > > > produce > > > something for Solaris. I'll get back to you soon... > > > > > > Cheers > > > Christoph > > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Donnerstag, 4. Juli 2019 14:18 > > > To: Langer, Christoph ; Andrew John > > > Hughes > > > ; jdk8u-dev > > > Cc: build-dev > > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > > optimization > > > Hi Christoph, > > > > > > On Thu, 2019-07-04 at 10:24 +0000, Langer, Christoph wrote: > > > Hi Severin, > > > > > > sorry, this item got drained down in my pile of work. > > > > > > AIX looks good. For Solaris, however, there is a problem. > > > > > > This is an excerpt of the logs: > > > SS12u1/SUNWspro/bin/cc -g -xs -m64 -xarch=sparc -G -KPIC \ > > > -M > > > jdk8/hotspot/make/solaris/makefiles/mapfile-vers-jsig - > > > mt > > > -xnolib -xO4 -g0 -xs -o libjsig.so > > > sun_64/nightly/jdk8/hotspot/src/os/solaris/vm/jsig.c -ldl > > > cc: Warning: Option -0 passed to ld, if ld is invoked, ignored > > > otherwise > > > ld: fatal: unrecognized option '-0' > > > ld: fatal: use the '-z help' option for usage information > > > > > > Thanks for this info! > > > > > > Seems like the options don't work for Oracle Studio (12 u1) when > > > compiling and linking in one go. A fix would be to split > > > compilation > > > and linking of the lib into 2 steps, I guess. > > > > > > As I don't have access to such a system and test a potential patch, > > > I've removed the solaris changes: > > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8210761/jdk8/03/webrev/ > > > > > > If somebody is able to provide me with a solaris patch, I can > > > happily > > > include it. Otherwise, solaris will stay as-is. > > > > > > Thoughts? OK to push? > > > > > > Thanks, > > > Severin > > > > > > Best regards > > > Christoph > > > > > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Donnerstag, 4. Juli 2019 11:39 > > > To: Langer, Christoph ; Andrew John > > > Hughes > > > ; jdk8u-dev > > dev at openjdk.java.net> > > > Cc: build-dev > > > Subject: Re: [8u] RFR: 8210761: libjsig is being compiled without > > > optimization > > > Hi Christoph, > > > > > > On Wed, 2019-06-26 at 13:11 +0000, Langer, Christoph wrote: > > > Here you go: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > > > 8210761/jdk8/02/webrev/ > > > > > > I cannot really test on bsd, solaris or aix, though :( Appreciate > > > any > > > testers for those platforms. > > > > > > I pulled the patch into our test environment. It will be run for > > > AIX > > > and solaris there. Will let you know the results... > > > > > > Any update? > > > > > > Thanks, > > > Severin From dcherepanov at azul.com Thu Jul 11 06:37:41 2019 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 11 Jul 2019 06:37:41 +0000 Subject: RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a In-Reply-To: References: Message-ID: Looks good to me. One suggestion: does it make sense to include additional change in ZoneInfoFile.java to address the comment [1] in 8u too, it was fixed in the final patch for jdk/jdk13 [2]. Thanks, Dmitry [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061216.html [2] https://hg.openjdk.java.net/jdk/jdk13/rev/8df81df1cce4#l13.1 > On Jul 8, 2019, at 5:49 AM, Andrew John Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224560 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.01/ > > This is the 8u version of the patch proposed in [0]. It mostly applies > as is, but the CLDRConverter.java changes can be dropped (no JDK-8189784 > and friends in 8u). The changes to TestZoneInfo310.java ideally should > be applied after JDK-8157792, which is a clean backport I have also > flagged with jdk8u-fix-request. > > I don't know whether we want to still try and include this in 8u222 or > not. It is pretty late and people may already be testing finished builds. > > Ok for 8u-dev? > > [0] https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From shade at redhat.com Thu Jul 11 10:04:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 11 Jul 2019 12:04:52 +0200 Subject: [11u, 8u]: OpenJDK update releases 11.0.6 and 8u242: Created JBS filter views and published preliminary timeline on Wiki In-Reply-To: References: Message-ID: On 7/9/19 2:35 PM, Langer, Christoph wrote: > I just wanted to notify everybody that I've just created JBS backport issue filters for the > January 2020 releases 11.0.6 and 8u242. The Wiki pages [1],[2] were updated accordingly along > with a preliminary timeline for these releases. The date for the CPU code freeze falls into the > Christmas holidays so we'll probably have to adjust this a bit eventually. I added the relevant filter dumps here: https://builds.shipilev.net/backports-monitor/filter-oracle-missing-8u242.txt https://builds.shipilev.net/backports-monitor/filter-oracle-missing-11.0.6.txt https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-8u242.txt https://builds.shipilev.net/backports-monitor/filter-openjdk-missing-11.0.6.txt -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Jul 11 17:16:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 11 Jul 2019 18:16:27 +0100 Subject: RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a In-Reply-To: References: Message-ID: <29963c39-7cdc-62af-698f-c3f153fbac18@redhat.com> On 11/07/2019 07:37, Dmitry Cherepanov wrote: > Looks good to me. > > One suggestion: does it make sense to include additional change in ZoneInfoFile.java to address the comment [1] in 8u too, it was fixed in the final patch for jdk/jdk13 [2]. > > Thanks, > > Dmitry > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061216.html > [2] https://hg.openjdk.java.net/jdk/jdk13/rev/8df81df1cce4#l13.1 > Yeah, my original post was based on the original webrev I reviewed prior to that comment being made, and the final commit. Here's an updated version based on the final commit, which I'm also including in 8u222: https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.02/ Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From dcherepanov at azul.com Thu Jul 11 17:25:53 2019 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 11 Jul 2019 17:25:53 +0000 Subject: RFR: [8u] JDK-8224560: (tz) Upgrade time-zone data to tzdata2019a In-Reply-To: <29963c39-7cdc-62af-698f-c3f153fbac18@redhat.com> References: <29963c39-7cdc-62af-698f-c3f153fbac18@redhat.com> Message-ID: > On Jul 11, 2019, at 8:16 PM, Andrew John Hughes wrote: > > > > On 11/07/2019 07:37, Dmitry Cherepanov wrote: >> Looks good to me. >> >> One suggestion: does it make sense to include additional change in ZoneInfoFile.java to address the comment [1] in 8u too, it was fixed in the final patch for jdk/jdk13 [2]. >> >> Thanks, >> >> Dmitry >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061216.html >> [2] https://hg.openjdk.java.net/jdk/jdk13/rev/8df81df1cce4#l13.1 >> > > Yeah, my original post was based on the original webrev I reviewed prior > to that comment being made, and the final commit. > > Here's an updated version based on the final commit, which I'm also > including in 8u222: > > https://cr.openjdk.java.net/~andrew/openjdk8/8224560/webrev.02/ Looks good. Thanks. Dmitry > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > From chengjingwei1 at huawei.com Fri Jul 12 06:50:20 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Fri, 12 Jul 2019 06:50:20 +0000 Subject: [8u-dev] Deadlock involving FileSystems.getDefault and System.loadLibrary Message-ID: Hi there, We got a bug report from our customers some time ago, the situation was the same as described in http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050819.html So we adopted the patch proposed in https://bugs.openjdk.java.net/browse/JDK-8194653 and https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059811.html But after then, we've encountered 2 more issues: 1. Win32 jdk would crash on a win64 environment when running AsynchronousFileChannel test in the jck testsuite 2. Win32 jdk sometimes throw TimeoutException when running AysnchronousChannelGroup test in the jck testsuite We are pretty sure that these issues came up right after we applied this patch. As for the root cause, we are still investigating. If someone is interested in these newly introduced issues, I'd like to post more details about them. From jayweb05 at gmail.com Thu Jul 11 15:32:37 2019 From: jayweb05 at gmail.com (Jay Web) Date: Thu, 11 Jul 2019 10:32:37 -0500 Subject: Request for Linux openjdk8u212 tar.gz Message-ID: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> Hi, Could you please share or point the location to download openjdk8u212. I have searched openjdk site and no luck. Thanks, Jay. From hohensee at amazon.com Thu Jul 11 16:31:26 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Jul 2019 16:31:26 +0000 Subject: Shenandoah and aarch64 Message-ID: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I???d move Shenandoah first, since it presumably has hooks in platform dependent code which we???d have to work around if we did the aarch64 port first. Thoughts? Thanks, Paul From fujie at loongson.cn Fri Jul 12 08:41:44 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 12 Jul 2019 16:41:44 +0800 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> Message-ID: <3a17abdf-dc97-6601-b668-17ba08f09dcb@loongson.cn> https://adoptopenjdk.net/ https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u212-b04/OpenJDK8U-jdk_x64_linux_hotspot_8u212b04.tar.gz On 2019/7/11 ??11:32, Jay Web wrote: > Hi, > > Could you please share or point the location to download openjdk8u212. I have searched openjdk site and no luck. > > Thanks, > Jay. From sgehwolf at redhat.com Fri Jul 12 08:48:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Jul 2019 10:48:58 +0200 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> Message-ID: <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> On Thu, 2019-07-11 at 10:32 -0500, Jay Web wrote: > Hi, > > Could you please share or point the location to download > openjdk8u212. I have searched openjdk site and no luck. OpenJDK 8u project builds (including 8u212-b04) are available here at AdoptOpenJDK: https://adoptopenjdk.net/upstream.html Thanks, Severin From fujie at loongson.cn Fri Jul 12 09:02:09 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 12 Jul 2019 17:02:09 +0800 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> Message-ID: <66d670f8-db27-88c8-d175-f4fb68464ed9@loongson.cn> Hi Severin, I'm confused. Could you explain what's the difference between the two versions? ?- https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b04/OpenJDK8U-x64_linux_8u212b04.tar.gz ?- https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u212-b04/OpenJDK8U-jdk_x64_linux_hotspot_8u212b04.tar.gz Thanks a lot. Best regards, Jie On 2019/7/12 ??4:48, Severin Gehwolf wrote: > On Thu, 2019-07-11 at 10:32 -0500, Jay Web wrote: >> Hi, >> >> Could you please share or point the location to download >> openjdk8u212. I have searched openjdk site and no luck. > OpenJDK 8u project builds (including 8u212-b04) are available here at > AdoptOpenJDK: > https://adoptopenjdk.net/upstream.html > > Thanks, > Severin > > From christoph.langer at sap.com Fri Jul 12 09:11:18 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 Jul 2019 09:11:18 +0000 Subject: Result: New JDK 8 Updates Reviewer: Severin Gehwolf Message-ID: Voting for Severin Gehwolf [1] is now closed. Yes: 6 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Thanks, /Jesper [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009703.html From sgehwolf at redhat.com Fri Jul 12 09:28:17 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Jul 2019 11:28:17 +0200 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <66d670f8-db27-88c8-d175-f4fb68464ed9@loongson.cn> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> <66d670f8-db27-88c8-d175-f4fb68464ed9@loongson.cn> Message-ID: <6988a86bf1eb316fb1e6ec869312e0b864b9ecbe.camel@redhat.com> Hi Jie, On Fri, 2019-07-12 at 17:02 +0800, Jie Fu wrote: > Hi Severin, > > I'm confused. > Could you explain what's the difference between the two versions? This page has a little context what the linked builds are: https://adoptopenjdk.net/upstream.html > - > https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b04/OpenJDK8U-x64_linux_8u212b04.tar.gz So these are JDK 8u OpenJDK Project Builds produced by Red Hat on behalf of the OpenJDK 8u project. Vanilla, vendor neutral, OpenJDK 8u builds, if you will. Think jdk.java.net GPL builds for OpenJDK 8u after Red Hat took on leadership of the project. These are being produced as a curtesy to OpenJDK users. $ openjdk-8u212-b04/bin/java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (build 1.8.0_212-b04) OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > - > https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u212-b04/OpenJDK8U-jdk_x64_linux_hotspot_8u212b04.tar.gz Those are builds produced by the AdoptOpenJDK project on their infrastructure, tested with their tests, supported by them, etc. They are mostly identical, but may have additional bits like installers, IcedTea web integration etc. $ jdk8u212-b04/bin/java -version openjdk version "1.8.0_212" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode) HTH, Severin > Thanks a lot. > Best regards, > Jie > > On 2019/7/12 ??4:48, Severin Gehwolf wrote: > > On Thu, 2019-07-11 at 10:32 -0500, Jay Web wrote: > > > Hi, > > > > > > Could you please share or point the location to download > > > openjdk8u212. I have searched openjdk site and no luck. > > OpenJDK 8u project builds (including 8u212-b04) are available here at > > AdoptOpenJDK: > > https://adoptopenjdk.net/upstream.html > > > > Thanks, > > Severin > > > > From fujie at loongson.cn Fri Jul 12 09:44:31 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 12 Jul 2019 17:44:31 +0800 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <6988a86bf1eb316fb1e6ec869312e0b864b9ecbe.camel@redhat.com> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> <66d670f8-db27-88c8-d175-f4fb68464ed9@loongson.cn> <6988a86bf1eb316fb1e6ec869312e0b864b9ecbe.camel@redhat.com> Message-ID: <9c203251-7ce8-570c-c05f-93eb8d60797e@loongson.cn> Hi Severin, Thanks for your clarification. Best regards, Jie On 2019/7/12 ??5:28, Severin Gehwolf wrote: > Hi Jie, > > On Fri, 2019-07-12 at 17:02 +0800, Jie Fu wrote: >> Hi Severin, >> >> I'm confused. >> Could you explain what's the difference between the two versions? > This page has a little context what the linked builds are: > https://adoptopenjdk.net/upstream.html > >> - >> https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b04/OpenJDK8U-x64_linux_8u212b04.tar.gz > So these are JDK 8u OpenJDK Project Builds produced by Red Hat on > behalf of the OpenJDK 8u project. Vanilla, vendor neutral, OpenJDK 8u > builds, if you will. Think jdk.java.net GPL builds for OpenJDK 8u after > Red Hat took on leadership of the project. These are being produced as > a curtesy to OpenJDK users. > > $ openjdk-8u212-b04/bin/java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > >> - >> https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u212-b04/OpenJDK8U-jdk_x64_linux_hotspot_8u212b04.tar.gz > Those are builds produced by the AdoptOpenJDK project on their > infrastructure, tested with their tests, supported by them, etc. They > are mostly identical, but may have additional bits like installers, > IcedTea web integration etc. > > $ jdk8u212-b04/bin/java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode) > > HTH, > Severin > >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/7/12 ??4:48, Severin Gehwolf wrote: >>> On Thu, 2019-07-11 at 10:32 -0500, Jay Web wrote: >>>> Hi, >>>> >>>> Could you please share or point the location to download >>>> openjdk8u212. I have searched openjdk site and no luck. >>> OpenJDK 8u project builds (including 8u212-b04) are available here at >>> AdoptOpenJDK: >>> https://adoptopenjdk.net/upstream.html >>> >>> Thanks, >>> Severin >>> >>> From andrey at azul.com Fri Jul 12 10:08:31 2019 From: andrey at azul.com (Andrey Petushkov) Date: Fri, 12 Jul 2019 10:08:31 +0000 Subject: Shenandoah and aarch64 In-Reply-To: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> Message-ID: <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> Azul fully supports this idea and would like to propose integration of aarch32 port as well, please Regards, Andrey > On 11 Jul 2019, at 19:31, Hohensee, Paul wrote: > > We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I?d move Shenandoah first, since it presumably has hooks in platform dependent code which we?d have to work around if we did the aarch64 port first. > > Thoughts? > > Thanks, > > Paul From gil at azul.com Fri Jul 12 10:12:23 2019 From: gil at azul.com (Gil Tene) Date: Fri, 12 Jul 2019 10:12:23 +0000 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <6988a86bf1eb316fb1e6ec869312e0b864b9ecbe.camel@redhat.com> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> <66d670f8-db27-88c8-d175-f4fb68464ed9@loongson.cn>, <6988a86bf1eb316fb1e6ec869312e0b864b9ecbe.camel@redhat.com> Message-ID: <6FC302A0-87F7-4BBD-A17A-A3378C0B8A8E@azul.com> Sent from my iPad > On Jul 11, 2019, at 11:29 PM, Severin Gehwolf wrote: > > Hi Jie, > >> On Fri, 2019-07-12 at 17:02 +0800, Jie Fu wrote: >> Hi Severin, >> >> I'm confused. >> Could you explain what's the difference between the two versions? > > This page has a little context what the linked builds are: > https://adoptopenjdk.net/upstream.html > >> - >> https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b04/OpenJDK8U-x64_linux_8u212b04.tar.gz > > So these are JDK 8u OpenJDK Project Builds produced by Red Hat on > behalf of the OpenJDK 8u project. Vanilla, vendor neutral, OpenJDK 8u > builds, if you will. Think jdk.java.net GPL builds for OpenJDK 8u after > Red Hat took on leadership of the project. These are being produced as > a curtesy to OpenJDK users. > > $ openjdk-8u212-b04/bin/java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) Another key difference: AFAIK the ?upstream? bits are actually TCK tested (by RedHat, per project lead statement on this list). > >> - >> https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u212-b04/OpenJDK8U-jdk_x64_linux_hotspot_8u212b04.tar.gz > > Those are builds produced by the AdoptOpenJDK project on their > infrastructure, tested with their tests, supported by them, etc. They > are mostly identical, but may have additional bits like installers, > IcedTea web integration etc. > > $ jdk8u212-b04/bin/java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04) > OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode) > > HTH, > Severin > >> Thanks a lot. >> Best regards, >> Jie >> >>> On 2019/7/12 ??4:48, Severin Gehwolf wrote: >>>> On Thu, 2019-07-11 at 10:32 -0500, Jay Web wrote: >>>> Hi, >>>> >>>> Could you please share or point the location to download >>>> openjdk8u212. I have searched openjdk site and no luck. >>> OpenJDK 8u project builds (including 8u212-b04) are available here at >>> AdoptOpenJDK: >>> https://adoptopenjdk.net/upstream.html >>> >>> Thanks, >>> Severin >>> >>> From shade at redhat.com Fri Jul 12 10:29:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 12 Jul 2019 12:29:33 +0200 Subject: Shenandoah and aarch64 In-Reply-To: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> Message-ID: On 7/11/19 6:31 PM, Hohensee, Paul wrote: > We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be > willing to do much/most of the work. I believe that both currently reside in > http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the > easiest approach would be to take both from there. I?d move Shenandoah first, since it > presumably has hooks in platform dependent code which we?d have to work around if we did the > aarch64 port first. This would certainly simplify 8u maintenance for us (Shenandoah devs and Red Hat maintenance people). There are several wrinkles to consider here: a) Shenandoah hooks up into AArch64 code quite hard, and separating the two would probably be problematic. It would also temporarily give us _another_ Shenandoah tree to maintain, which would be bad. I would rather consider merging the entirety of aarch64-port/jdk8u-shenandoah/ into jdk8u, and sunsetting the aarch64-port repos immediately after that. b) Shenandoah GC interface in 8u is quite messy, because GC API work to isolate GCs better is done in later releases. There are Shenandoah features in backporting queue that would make the exposure in shared parts much more narrow: load-reference barriers would eliminate lots of barrier hooks and compiler opto steps, and eliminating separate fwdptr slot would retract extensions to the allocation path. We (Shenandoah devs) were planning to backport these to 8u after July CPU is out of the door. c) There are some minor changes accrued against upstream 8u over the course of multiple backports and merges. We would need to comb through them and harmonize them against upstream. On the upside, those changes are usually independent of Shenandoah and AArch64. We have the autogenerated webrev of difference between jdk8u and aarch64-port/jdk8u-shenandoah here: https://builds.shipilev.net/patch-openjdk-jdk8-redhat/ I believe we can start combing through that webrev to get the feel how much work there is, and what changes can be done to simplify the merge. aarch64-port-dev@ would probably be the venue to coordinate/review this work. -- Thanks, -Aleksey From rkennke at redhat.com Fri Jul 12 10:36:27 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 12 Jul 2019 12:36:27 +0200 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> Message-ID: <20F5A84B-028F-4643-9C1B-E960E0572F64@redhat.com> I agree with all that Aleksey says. I am wondering if Shenandoah (with LRB and related improvements) should go into 11u first? That is much less problematic and would pave the way for 8u integration? Roman Am 12. Juli 2019 12:29:33 MESZ schrieb Aleksey Shipilev : >On 7/11/19 6:31 PM, Hohensee, Paul wrote: >> We (Amazon) are interested in pushing both Shenandoah and the aarch64 >port to jdk8u and would be >> willing to do much/most of the work. I believe that both currently >reside in >> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me >if not), so to me the >> easiest approach would be to take both from there. I?d move >Shenandoah first, since it >> presumably has hooks in platform dependent code which we?d have to >work around if we did the >> aarch64 port first. > >This would certainly simplify 8u maintenance for us (Shenandoah devs >and Red Hat maintenance >people). There are several wrinkles to consider here: > >a) Shenandoah hooks up into AArch64 code quite hard, and separating the >two would probably be >problematic. It would also temporarily give us _another_ Shenandoah >tree to maintain, which would be >bad. I would rather consider merging the entirety of >aarch64-port/jdk8u-shenandoah/ into jdk8u, and >sunsetting the aarch64-port repos immediately after that. > >b) Shenandoah GC interface in 8u is quite messy, because GC API work to >isolate GCs better is done >in later releases. There are Shenandoah features in backporting queue >that would make the exposure >in shared parts much more narrow: load-reference barriers would >eliminate lots of barrier hooks and >compiler opto steps, and eliminating separate fwdptr slot would retract >extensions to the allocation >path. We (Shenandoah devs) were planning to backport these to 8u after >July CPU is out of the door. > >c) There are some minor changes accrued against upstream 8u over the >course of multiple backports >and merges. We would need to comb through them and harmonize them >against upstream. On the upside, >those changes are usually independent of Shenandoah and AArch64. > >We have the autogenerated webrev of difference between jdk8u and >aarch64-port/jdk8u-shenandoah here: > https://builds.shipilev.net/patch-openjdk-jdk8-redhat/ > >I believe we can start combing through that webrev to get the feel how >much work there is, and what >changes can be done to simplify the merge. aarch64-port-dev@ would >probably be the venue to >coordinate/review this work. > >-- >Thanks, >-Aleksey -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From sgehwolf at redhat.com Fri Jul 12 11:07:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 12 Jul 2019 13:07:58 +0200 Subject: Shenandoah and aarch64 In-Reply-To: <20F5A84B-028F-4643-9C1B-E960E0572F64@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <20F5A84B-028F-4643-9C1B-E960E0572F64@redhat.com> Message-ID: <19102cb97b1977861e6809b4cdfc8921f9d22a37.camel@redhat.com> On Fri, 2019-07-12 at 12:36 +0200, Roman Kennke wrote: > I am wondering if Shenandoah (with LRB and related improvements) > should go into 11u first? That makes a lot of sense. Thanks, Severin From gnu.andrew at redhat.com Fri Jul 12 12:28:10 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 12 Jul 2019 13:28:10 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> Message-ID: <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> On 12/07/2019 11:08, Andrey Petushkov wrote: > Azul fully supports this idea and would like to propose integration of aarch32 port as well, please > > Regards, > Andrey > >> On 11 Jul 2019, at 19:31, Hohensee, Paul wrote: >> >> We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I?d move Shenandoah first, since it presumably has hooks in platform dependent code which we?d have to work around if we did the aarch64 port first. >> >> Thoughts? >> >> Thanks, >> >> Paul > I agree, it would be good to finally see both ports in the main upstream repository. Shenandoah as well, though that should go to 11 first. The work should use a staging repository, as with JFR, so as to minimise disruption to the work on 8u releases. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Jul 12 12:32:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 12 Jul 2019 13:32:31 +0100 Subject: Result: New JDK 8 Updates Reviewer: Severin Gehwolf In-Reply-To: References: Message-ID: <89499d86-b249-2bc3-5ff0-664e863bf2e2@redhat.com> On 12/07/2019 10:11, Langer, Christoph wrote: > Voting for Severin Gehwolf [1] is now closed. > > > > Yes: 6 > > Veto: 0 > > Abstain: 0 > > > > According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. > > > > Thanks, > > /Jesper > > > > [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009703.html > Congratulations Severin. Does this mean I can now take this as a valid review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009605.html and finally push this patch? It's only been waiting a month... Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Fri Jul 12 12:43:30 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 Jul 2019 12:43:30 +0000 Subject: Result: New JDK 8 Updates Reviewer: Severin Gehwolf In-Reply-To: <89499d86-b249-2bc3-5ff0-664e863bf2e2@redhat.com> References: <89499d86-b249-2bc3-5ff0-664e863bf2e2@redhat.com> Message-ID: Hi, > Congratulations Severin. > > Does this mean I can now take this as a valid review: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009605.html > > and finally push this patch? It's only been waiting a month... I would say so... ?? Though, formally the reviewer status needs to be set by the registrar which can take a few days... /Christoph From aph at redhat.com Fri Jul 12 13:28:20 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Jul 2019 14:28:20 +0100 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> Message-ID: On 7/12/19 11:29 AM, Aleksey Shipilev wrote: > On 7/11/19 6:31 PM, Hohensee, Paul wrote: >> We (Amazon) are interested in pushing both Shenandoah and the >> aarch64 port to jdk8u and would be willing to do much/most of the >> work. I believe that both currently reside in >> http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct >> me if not), so to me the easiest approach would be to take both >> from there. I?d move Shenandoah first, since it presumably has >> hooks in platform dependent code which we?d have to work around if >> we did the aarch64 port first. > > This would certainly simplify 8u maintenance for us (Shenandoah devs > and Red Hat maintenance people). There are several wrinkles to > consider here: > > a) Shenandoah hooks up into AArch64 code quite hard, and separating > the two would probably be problematic. It would also temporarily > give us _another_ Shenandoah tree to maintain, which would be bad. I > would rather consider merging the entirety of > aarch64-port/jdk8u-shenandoah/ into jdk8u, and sunsetting the > aarch64-port repos immediately after that. Absolutely. Given that we already have a merged tree, it should be fairly straightforward to port the whole thing as a single piece. > b) Shenandoah GC interface in 8u is quite messy, because GC API work > to isolate GCs better is done in later releases. There are > Shenandoah features in backporting queue that would make the > exposure in shared parts much more narrow: load-reference barriers > would eliminate lots of barrier hooks and compiler opto steps, and > eliminating separate fwdptr slot would retract extensions to the > allocation path. We (Shenandoah devs) were planning to backport > these to 8u after July CPU is out of the door. > > c) There are some minor changes accrued against upstream 8u over > the course of multiple backports and merges. We would need to comb > through them and harmonize them against upstream. On the upside, > those changes are usually independent of Shenandoah and AArch64. Yes. > We have the autogenerated webrev of difference between jdk8u and > aarch64-port/jdk8u-shenandoah here: > https://builds.shipilev.net/patch-openjdk-jdk8-redhat/ > > I believe we can start combing through that webrev to get the feel > how much work there is, and what changes can be done to simplify the > merge. aarch64-port-dev@ would probably be the venue to > coordinate/review this work. It needs maximum exposure. Let's discuss it here. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Jul 12 13:29:13 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Jul 2019 14:29:13 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> Message-ID: On 7/12/19 11:08 AM, Andrey Petushkov wrote: > Azul fully supports this idea and would like to propose integration of aarch32 port as well, please It should be pretty non-intrusive, so I have no objection in principle. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Fri Jul 12 15:07:11 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Jul 2019 15:07:11 +0000 Subject: Shenandoah and aarch64 In-Reply-To: <19102cb97b1977861e6809b4cdfc8921f9d22a37.camel@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <20F5A84B-028F-4643-9C1B-E960E0572F64@redhat.com> <19102cb97b1977861e6809b4cdfc8921f9d22a37.camel@redhat.com> Message-ID: <01E32529-B8E2-4921-AF7E-B7537864C341@amazon.com> +1, though no reason it can't be done at the same time. Paul ?On 7/12/19, 4:08 AM, "Severin Gehwolf" wrote: On Fri, 2019-07-12 at 12:36 +0200, Roman Kennke wrote: > I am wondering if Shenandoah (with LRB and related improvements) > should go into 11u first? That makes a lot of sense. Thanks, Severin From martijnverburg at gmail.com Fri Jul 12 15:45:34 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 12 Jul 2019 16:45:34 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <01E32529-B8E2-4921-AF7E-B7537864C341@amazon.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <20F5A84B-028F-4643-9C1B-E960E0572F64@redhat.com> <19102cb97b1977861e6809b4cdfc8921f9d22a37.camel@redhat.com> <01E32529-B8E2-4921-AF7E-B7537864C341@amazon.com> Message-ID: +1 Starting in August/Sept jClarity can also assist, especially with perf testing/tuning and providing test builds for all aarchs at Adopt. Cheers, Martijn On Fri, 12 Jul 2019 at 16:07, Hohensee, Paul wrote: > +1, though no reason it can't be done at the same time. > > Paul > > ?On 7/12/19, 4:08 AM, "Severin Gehwolf" wrote: > > On Fri, 2019-07-12 at 12:36 +0200, Roman Kennke wrote: > > I am wondering if Shenandoah (with LRB and related improvements) > > should go into 11u first? > > That makes a lot of sense. > > Thanks, > Severin > > > > From aph at redhat.com Fri Jul 12 16:01:29 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Jul 2019 17:01:29 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> Message-ID: <37a67540-07db-a8f2-1cb9-ca885a7ff2d4@redhat.com> On 7/12/19 1:28 PM, Andrew John Hughes wrote: > I agree, it would be good to finally see both ports in the main upstream > repository. Shenandoah as well, though that should go to 11 first. That will have to be another discussion. Maybe we should start by discussing Shenandoah in 11. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Fri Jul 12 21:00:11 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 12 Jul 2019 22:00:11 +0100 Subject: OpenJDK 8u222-b06, 8u222-b07 & 8u222-b08 EA Released Message-ID: <01ebd182-d8a1-aaa2-a83c-a9a96b6b4ce1@redhat.com> For completeness, here are the remaining EA bundles, ahead of next Tuesday's GA release: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b06-ea.tar.xz https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b07-ea.tar.xz https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b08-ea.tar.xz The tarballs are accompanied by digital signatures available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b06-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b07-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b08-ea.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 7a6e00f5ca6101116856f4b24bbf49e5930b58e6a2b3add30bab0bfd1d2b4daf openjdk8u222-b06-ea.tar.xz 03620f8ca901fed8a1b97a720a3d3c179a8e2f068d17cf5326355e37a7a23a9a openjdk8u222-b06-ea.tar.xz.sig 4ad883549341ab745af8b6d028cd6f47c258b0b4d88f9ff48ce07922574df77a openjdk8u222-b07-ea.tar.xz e795d26b6304c453f027c367cc45bb8c834401bc612ed95879665d47fafef1b3 openjdk8u222-b07-ea.tar.xz.sig 23f91e5e7051e43c24de423908b93f60b4e463a78b6218ac553165d106428139 openjdk8u222-b08-ea.tar.xz b08965fc772ded8c64736214070b1264d1d8051a4b5586937b75af0b7271eec6 openjdk8u222-b08-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b06-ea.sha256 https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b07-ea.sha256 https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b08-ea.sha256 Changes in jdk8u222-b06: - 8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores - 8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores - 8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching Changes in jdk8u222-b07: - S8153732: Windows remote printer changes do not reflect in lookupPrintServices() - S8212202: [Windows] Exception if no printers are installed. - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use - S8221412: lookupPrintServices() does not always update the list of Windows remote printers - S8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding Changes in jdk8u222-b08: - S8031145: Re-examine closed i18n tests to see it they can be moved to the jdk repository. - S8040211: Update LSR datafile for BCP 47 - S8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java - S8181594: Efficient and constant-time modular arithmetic - S8182999: SunEC throws ProviderException on invalid curves - S8187946: Support ISO 4217 Amendments 163 and 164 - S8191404: Upgrading JDK with latest available LSR data from IANA. - S8193552: ISO 4217 amendment 165 - S8195478: sun/text/resources/LocaleDataTest.java fails with java.lang.Exception - S8201317: X25519/X448 code improvements - S8202026: ISO 4217 amendment 166 - S8203228: Branch-free output conversion for X25519 and X448 - S8203872: Upgrading JDK with latest available LSR data from IANA. - S8204269: ISO 4217 amendment 167 - S8208648: ECC Field Arithmetic Enhancements - S8208698: Improved ECC Implementation - S8208746: ISO 4217 Amendment #168 update - S8209775: ISO 4217 Amendment #169 update - S8210153: localized currency symbol of VES - S8213294: Upgrade IANA LSR data - S8214935: Upgrade IANA LSR data - S8219781: Localized names for Japanese era Reiwa in COMPAT provider -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From aph at redhat.com Sat Jul 13 08:47:57 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 13 Jul 2019 09:47:57 +0100 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> Message-ID: <0c98957c-a0e8-b5bb-a203-f0dcd7905df7@redhat.com> On 7/12/19 2:29 PM, Andrew Haley wrote: > On 7/12/19 11:08 AM, Andrey Petushkov wrote: >> Azul fully supports this idea and would like to propose integration >> of aarch32 port as well, please > > It should be pretty non-intrusive, so I have no objection in principle. But, having slept on this idea, I think it's impossible. Features are always committed to mainline first, then backported. There is already an Arm 32 port in mainline, so I doubt that the AArch32 port would be accepted there. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Sun Jul 14 11:17:44 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 14 Jul 2019 13:17:44 +0200 Subject: Shenandoah and aarch64 In-Reply-To: <01E32529-B8E2-4921-AF7E-B7537864C341@amazon.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <20F5A84B-028F-4643-9C1B-E960E0572F64@redhat.com> <19102cb97b1977861e6809b4cdfc8921f9d22a37.camel@redhat.com> <01E32529-B8E2-4921-AF7E-B7537864C341@amazon.com> Message-ID: The only reason would be that I'd strongly suggest to wait for the LRB and elimination-of-forwarding pointer backports to arrive. And they are going to arrive in 11 first (I already have them ready and lined up to get pushed), and probably need some time to be done for 8 because this is a whole different story because 8 doesn't have any of the GC interfaces. Roman > +1, though no reason it can't be done at the same time. > > Paul > > ?On 7/12/19, 4:08 AM, "Severin Gehwolf" wrote: > > On Fri, 2019-07-12 at 12:36 +0200, Roman Kennke wrote: > > I am wondering if Shenandoah (with LRB and related improvements) > > should go into 11u first? > > That makes a lot of sense. > > Thanks, > Severin > > > From rkennke at redhat.com Sun Jul 14 11:21:02 2019 From: rkennke at redhat.com (Roman Kennke) Date: Sun, 14 Jul 2019 13:21:02 +0200 Subject: Shenandoah and aarch64 In-Reply-To: <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> Message-ID: > On 12/07/2019 11:08, Andrey Petushkov wrote: >> Azul fully supports this idea and would like to propose integration of aarch32 port as well, please >> >> Regards, >> Andrey >> >>> On 11 Jul 2019, at 19:31, Hohensee, Paul wrote: >>> >>> We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I?d move Shenandoah first, since it presumably has hooks in platform dependent code which we?d have to work around if we did the aarch64 port first. >>> >>> Thoughts? >>> >>> Thanks, >>> >>> Paul >> > > I agree, it would be good to finally see both ports in the main upstream > repository. Shenandoah as well, though that should go to 11 first. > > The work should use a staging repository, as with JFR, so as to minimise > disruption to the work on 8u releases. For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It seems to be the obvious choice because we already have it, and it is supposed to only contain the actual difference between upstream jdk11u and Shenandoah. For jdk8, I am not quite sure. We do have shenandoah/jdk8. I believe it probably would make sense to separate the aarch64 integration into 8u from Shenandoah and not make Aarch64 wait for Shenandoah. In this case, I think shenandoah/jdk8 would be good as staging for Shenandoah into jdk8u too. Roman From shade at redhat.com Mon Jul 15 08:27:31 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Jul 2019 10:27:31 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> Message-ID: On 7/2/19 9:53 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8214687 > https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 > > Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: > type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: > https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ > > Testing: tier1-like suite, new test Friendly reminder. -- Thanks, -Aleksey From aph at redhat.com Mon Jul 15 10:55:31 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jul 2019 11:55:31 +0100 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> Message-ID: <3744742c-4da0-c3aa-e947-da67c77752ba@redhat.com> On 7/14/19 12:21 PM, Roman Kennke wrote: > For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It > seems to be the obvious choice because we already have it, and it is > supposed to only contain the actual difference between upstream jdk11u > and Shenandoah. Perfect. That could not be any better. > For jdk8, I am not quite sure. We do have shenandoah/jdk8. I believe it > probably would make sense to separate the aarch64 integration into 8u > from Shenandoah and not make Aarch64 wait for Shenandoah. In this case, > I think shenandoah/jdk8 would be good as staging for Shenandoah into > jdk8u too. That's OK, but ... that repo is cluttered with a lot of history. Perhaps that doesn't matter, but it will be a confusing repo to work on. Wouldn't something a bit cleaner be easier? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Jul 15 11:19:28 2019 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 15 Jul 2019 13:19:28 +0200 Subject: Shenandoah and aarch64 In-Reply-To: <3744742c-4da0-c3aa-e947-da67c77752ba@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> <3744742c-4da0-c3aa-e947-da67c77752ba@redhat.com> Message-ID: >> For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It >> seems to be the obvious choice because we already have it, and it is >> supposed to only contain the actual difference between upstream jdk11u >> and Shenandoah. > > Perfect. That could not be any better. Great. Let's work with that then. We want to backport the LRB and related stuff first, and comb through and sort out any possibly unneeded changes. >> For jdk8, I am not quite sure. We do have shenandoah/jdk8. I believe it >> probably would make sense to separate the aarch64 integration into 8u >> from Shenandoah and not make Aarch64 wait for Shenandoah. In this case, >> I think shenandoah/jdk8 would be good as staging for Shenandoah into >> jdk8u too. > > That's OK, but ... that repo is cluttered with a lot of history. > Perhaps that doesn't matter, but it will be a confusing repo to work > on. Wouldn't something a bit cleaner be easier? Well, pretty much same as jdk11. We want to first backport LRB and friends, which should clean up the shared code changes very considerably. And after that, we shall comb through: https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8-only-shared/hotspot/ and sort out whatever is no longer needed. Right now it's mixed up with aarch64 changes, which is why I'd probably push aarch64 to jdk8u first, which should be whatever is: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/ When this is done, we can take the complete patch and push it at once to jdk8u. Do you agree? Roman From aph at redhat.com Mon Jul 15 11:35:58 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jul 2019 12:35:58 +0100 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> <3744742c-4da0-c3aa-e947-da67c77752ba@redhat.com> Message-ID: On 7/15/19 12:19 PM, Roman Kennke wrote: >>> For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It >>> seems to be the obvious choice because we already have it, and it is >>> supposed to only contain the actual difference between upstream jdk11u >>> and Shenandoah. >> >> Perfect. That could not be any better. > > Great. Let's work with that then. We want to backport the LRB and > related stuff first, and comb through and sort out any possibly unneeded > changes. Yeah. This may disappoint a few people, but we should perhaps let Shenandoah bake in JDK 11 for a while before pushing it to 8. We'll need to go through the code (again) with a fine-toothed comb to make sure that the changes, particularly to C2, do not leak out if Shenandoah is disabled. > Well, pretty much same as jdk11. We want to first backport LRB and > friends, which should clean up the shared code changes very > considerably. And after that, we shall comb through: > > https://builds.shipilev.net/patch-openjdk-shenandoah-jdk8-only-shared/hotspot/ > > and sort out whatever is no longer needed. > > Right now it's mixed up with aarch64 changes, which is why I'd probably > push aarch64 to jdk8u first, which should be whatever is: > > http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/ > > When this is done, we can take the complete patch and push it at once to > jdk8u. > > Do you agree? That sounds sensible. AArch64 is much less intrusive to the 8u code base than Shenandoah. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon Jul 15 15:25:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 15 Jul 2019 16:25:06 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <0c98957c-a0e8-b5bb-a203-f0dcd7905df7@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <0c98957c-a0e8-b5bb-a203-f0dcd7905df7@redhat.com> Message-ID: <93f95787-8c58-83ff-292e-6533eace14f5@redhat.com> On 13/07/2019 09:47, Andrew Haley wrote: > On 7/12/19 2:29 PM, Andrew Haley wrote: >> On 7/12/19 11:08 AM, Andrey Petushkov wrote: >>> Azul fully supports this idea and would like to propose integration >>> of aarch32 port as well, please >> >> It should be pretty non-intrusive, so I have no objection in principle. > > But, having slept on this idea, I think it's impossible. Features are > always committed to mainline first, then backported. There is already > an Arm 32 port in mainline, so I doubt that the AArch32 port would be > accepted there. > But that port is not in 8u. That leaves the options of bringing in Azul's port or backporting Oracle's port. The former seems the better option, given an 8u version already exists and is in production use. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Jul 15 15:48:37 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 15 Jul 2019 16:48:37 +0100 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> Message-ID: On 14/07/2019 12:21, Roman Kennke wrote: >> On 12/07/2019 11:08, Andrey Petushkov wrote: >>> Azul fully supports this idea and would like to propose integration of aarch32 port as well, please >>> >>> Regards, >>> Andrey >>> >>>> On 11 Jul 2019, at 19:31, Hohensee, Paul wrote: >>>> >>>> We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I?d move Shenandoah first, since it presumably has hooks in platform dependent code which we?d have to work around if we did the aarch64 port first. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> >>>> Paul >>> >> >> I agree, it would be good to finally see both ports in the main upstream >> repository. Shenandoah as well, though that should go to 11 first. >> >> The work should use a staging repository, as with JFR, so as to minimise >> disruption to the work on 8u releases. > > For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It > seems to be the obvious choice because we already have it, and it is > supposed to only contain the actual difference between upstream jdk11u > and Shenandoah. > > For jdk8, I am not quite sure. We do have shenandoah/jdk8. I believe it > probably would make sense to separate the aarch64 integration into 8u > from Shenandoah and not make Aarch64 wait for Shenandoah. In this case, > I think shenandoah/jdk8 would be good as staging for Shenandoah into > jdk8u too. > > Roman > When I refer to a staging repository, I mean something that could be pulled into the mainline jdk8u/jdk8u-dev i.e. something that has a series of changesets that have valid bug IDs and pass jcheck. I don't know how clean sh/jdk11 is now, but aarch64/jdk8u-shenandoah certainly isn't in that state. I would suggest starting with getting Shenandoah into 11u and aarch64 into 8u (the two efforts can run in parallel). Once Shenandoah has soaked into 11u, it can be backported to 8u, by which time it should have aarch64. It'd be nice to get aarch64 into 7u too, but that's probably wanting too much :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From martijnverburg at gmail.com Mon Jul 15 15:57:00 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 15 Jul 2019 16:57:00 +0100 Subject: Request for Linux openjdk8u212 tar.gz In-Reply-To: <6FC302A0-87F7-4BBD-A17A-A3378C0B8A8E@azul.com> References: <79819C7F-4F89-451D-AAC8-68D6D2E46612@gmail.com> <5a9e343c847b6480522ff7654338b2c691c47a82.camel@redhat.com> <66d670f8-db27-88c8-d175-f4fb68464ed9@loongson.cn> <6988a86bf1eb316fb1e6ec869312e0b864b9ecbe.camel@redhat.com> <6FC302A0-87F7-4BBD-A17A-A3378C0B8A8E@azul.com> Message-ID: We'll be working on a website UI update to make all of this a bit clearer in the future (apologies for the confusion). Cheers, Martijn On Fri, 12 Jul 2019 at 17:43, Gil Tene wrote: > > > Sent from my iPad > > > On Jul 11, 2019, at 11:29 PM, Severin Gehwolf > wrote: > > > > Hi Jie, > > > >> On Fri, 2019-07-12 at 17:02 +0800, Jie Fu wrote: > >> Hi Severin, > >> > >> I'm confused. > >> Could you explain what's the difference between the two versions? > > > > This page has a little context what the linked builds are: > > https://adoptopenjdk.net/upstream.html > > > >> - > >> > https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u212-b04/OpenJDK8U-x64_linux_8u212b04.tar.gz > > > > So these are JDK 8u OpenJDK Project Builds produced by Red Hat on > > behalf of the OpenJDK 8u project. Vanilla, vendor neutral, OpenJDK 8u > > builds, if you will. Think jdk.java.net GPL builds for OpenJDK 8u after > > Red Hat took on leadership of the project. These are being produced as > > a curtesy to OpenJDK users. > > > > $ openjdk-8u212-b04/bin/java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-b04) > > OpenJDK 64-Bit Server VM (build 25.212-b04, mixed mode) > > Another key difference: AFAIK the ?upstream? bits are actually TCK tested > (by RedHat, per project lead statement on this list). > > > > >> - > >> > https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u212-b04/OpenJDK8U-jdk_x64_linux_hotspot_8u212b04.tar.gz > > > > Those are builds produced by the AdoptOpenJDK project on their > > infrastructure, tested with their tests, supported by them, etc. They > > are mostly identical, but may have additional bits like installers, > > IcedTea web integration etc. > > > > $ jdk8u212-b04/bin/java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b04) > > OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b04, mixed mode) > > > > HTH, > > Severin > > > >> Thanks a lot. > >> Best regards, > >> Jie > >> > >>> On 2019/7/12 ??4:48, Severin Gehwolf wrote: > >>>> On Thu, 2019-07-11 at 10:32 -0500, Jay Web wrote: > >>>> Hi, > >>>> > >>>> Could you please share or point the location to download > >>>> openjdk8u212. I have searched openjdk site and no luck. > >>> OpenJDK 8u project builds (including 8u212-b04) are available here at > >>> AdoptOpenJDK: > >>> https://adoptopenjdk.net/upstream.html > >>> > >>> Thanks, > >>> Severin > >>> > >>> > From aph at redhat.com Mon Jul 15 16:47:37 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 15 Jul 2019 17:47:37 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <93f95787-8c58-83ff-292e-6533eace14f5@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <0c98957c-a0e8-b5bb-a203-f0dcd7905df7@redhat.com> <93f95787-8c58-83ff-292e-6533eace14f5@redhat.com> Message-ID: <07f849fd-fa07-964c-330d-fa8806278b4e@redhat.com> On 7/15/19 4:25 PM, Andrew John Hughes wrote: > > > On 13/07/2019 09:47, Andrew Haley wrote: >> On 7/12/19 2:29 PM, Andrew Haley wrote: >>> On 7/12/19 11:08 AM, Andrey Petushkov wrote: >>>> Azul fully supports this idea and would like to propose integration >>>> of aarch32 port as well, please >>> >>> It should be pretty non-intrusive, so I have no objection in principle. >> >> But, having slept on this idea, I think it's impossible. Features are >> always committed to mainline first, then backported. There is already >> an Arm 32 port in mainline, so I doubt that the AArch32 port would be >> accepted there. > > But that port is not in 8u. That leaves the options of bringing in > Azul's port or backporting Oracle's port. Or doing neither. I don't think that it's appropriate to bring in Azul's port, given its lack of a future path, and I don't believe we should set a precedent by making a special exception to the "backports only" rule for it. Anybody who wants it can get it from Azul. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Mon Jul 15 17:02:11 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Jul 2019 17:02:11 +0000 Subject: Shenandoah and aarch64 In-Reply-To: References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> Message-ID: <0452FC3A-C364-457F-A94C-188F18B93BC0@amazon.com> My approach might be of interest. I used the icedtea 3.8 source snapshots as the basis for the Amazon 8u aarch64 port, so there was no history to preserve. I did that because I wanted as-shipped source to piggy-back off RedHat's testing (just the way we all used to piggy-back off Oracle testing :)), and didn't want to deal with transient bugs in the dev repos. Here's what I did. First pushed all the platform-specific files, including hotspot/cpu/aarch64, hotspot/os_cpu/aarch64, etc. This was a nop wrt the other platforms, but got the lion's share of the code out of the way. Built and tested the result on linux-x64 (paranoia). Then, found all the places in common code with an ifdef ARM64 and pushed those, since that was also a nop wrt to the other platforms. Built and tested the result on linux-x64 (more paranoia). diff'ed the remainder against jdk8u and eliminated the non-codegen/testing related icedtea code, which left very little to actually analyze for correctness. Added that under temporary ifdefs and enabled them one at a time, testing each on x64-linux (quite tedious) and pushed the result. Then, built on AL2 and fixed all the gcc 8 issues. This was actually the vast majority (as in 99%) of the platform-independent changes. Built and tested the result on linux-x64 and pushed it. Finally (and in parallel), tested aarch64. Had 2 or 3 bugs due to typos, but that went pretty smoothly. 'test' == run TCK, jtreg tests, jbb, etc. Paul ?On 7/15/19, 8:49 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 14/07/2019 12:21, Roman Kennke wrote: >> On 12/07/2019 11:08, Andrey Petushkov wrote: >>> Azul fully supports this idea and would like to propose integration of aarch32 port as well, please >>> >>> Regards, >>> Andrey >>> >>>> On 11 Jul 2019, at 19:31, Hohensee, Paul wrote: >>>> >>>> We (Amazon) are interested in pushing both Shenandoah and the aarch64 port to jdk8u and would be willing to do much/most of the work. I believe that both currently reside in http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/ (correct me if not), so to me the easiest approach would be to take both from there. I?d move Shenandoah first, since it presumably has hooks in platform dependent code which we?d have to work around if we did the aarch64 port first. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> >>>> Paul >>> >> >> I agree, it would be good to finally see both ports in the main upstream >> repository. Shenandoah as well, though that should go to 11 first. >> >> The work should use a staging repository, as with JFR, so as to minimise >> disruption to the work on 8u releases. > > For the Shenandoah part, would shenandoah/jdk11 work as staging repo? It > seems to be the obvious choice because we already have it, and it is > supposed to only contain the actual difference between upstream jdk11u > and Shenandoah. > > For jdk8, I am not quite sure. We do have shenandoah/jdk8. I believe it > probably would make sense to separate the aarch64 integration into 8u > from Shenandoah and not make Aarch64 wait for Shenandoah. In this case, > I think shenandoah/jdk8 would be good as staging for Shenandoah into > jdk8u too. > > Roman > When I refer to a staging repository, I mean something that could be pulled into the mainline jdk8u/jdk8u-dev i.e. something that has a series of changesets that have valid bug IDs and pass jcheck. I don't know how clean sh/jdk11 is now, but aarch64/jdk8u-shenandoah certainly isn't in that state. I would suggest starting with getting Shenandoah into 11u and aarch64 into 8u (the two efforts can run in parallel). Once Shenandoah has soaked into 11u, it can be backported to 8u, by which time it should have aarch64. It'd be nice to get aarch64 into 7u too, but that's probably wanting too much :-) -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Mon Jul 15 17:22:44 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 15 Jul 2019 17:22:44 +0000 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> Message-ID: I'd change the copyright on NCopies.java to 2019 since you've changed the patch, but I'm not certain of the rule on that. Otherwise, looks good. Paul ?On 7/15/19, 1:29 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: On 7/2/19 9:53 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8214687 > https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 > > Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: > type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: > https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ > > Testing: tier1-like suite, new test Friendly reminder. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Jul 16 07:25:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Jul 2019 08:25:27 +0100 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> Message-ID: <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> On 15/07/2019 09:27, Aleksey Shipilev wrote: > On 7/2/19 9:53 PM, Aleksey Shipilev wrote: >> Original RFE: >> https://bugs.openjdk.java.net/browse/JDK-8214687 >> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 >> >> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: >> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: >> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ >> >> Testing: tier1-like suite, new test > > Friendly reminder. > Friendly reminder there's a release today :) Objects.checkIndex is simply a wrapper around Preconditions.checkIndex: public static int checkIndex(int index, int length) { return Preconditions.checkIndex(index, length, null); } which is in 8u. Probably worth adding the 2-argument version to Preconditions. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Jul 16 07:31:14 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Jul 2019 08:31:14 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <0452FC3A-C364-457F-A94C-188F18B93BC0@amazon.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> <0452FC3A-C364-457F-A94C-188F18B93BC0@amazon.com> Message-ID: <79e3c6bb-4521-5d10-0104-53faf4bc89df@redhat.com> On 15/07/2019 18:02, Hohensee, Paul wrote: > > Then, built on AL2 and fixed all the gcc 8 issues. This was actually the vast majority (as in 99%) of the platform-independent changes. Built and tested the result on linux-x64 and pushed it. > Are those specific to AArch64 or general issues? If the latter, that's something we should fix separately. It may be just that 3.8 (8u171) is now pretty old. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Tue Jul 16 15:04:49 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Jul 2019 15:04:49 +0000 Subject: Shenandoah and aarch64 In-Reply-To: <79e3c6bb-4521-5d10-0104-53faf4bc89df@redhat.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> <0452FC3A-C364-457F-A94C-188F18B93BC0@amazon.com> <79e3c6bb-4521-5d10-0104-53faf4bc89df@redhat.com> Message-ID: <91ACE45A-9D6C-44E3-8DE3-15F4D8122C91@amazon.com> They're pretty much all general issues. We could fix them first. Paul ?On 7/16/19, 12:32 AM, "Andrew John Hughes" wrote: On 15/07/2019 18:02, Hohensee, Paul wrote: > > Then, built on AL2 and fixed all the gcc 8 issues. This was actually the vast majority (as in 99%) of the platform-independent changes. Built and tested the result on linux-x64 and pushed it. > Are those specific to AArch64 or general issues? If the latter, that's something we should fix separately. It may be just that 3.8 (8u171) is now pretty old. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Jul 16 17:03:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Jul 2019 18:03:16 +0100 Subject: Shenandoah and aarch64 In-Reply-To: <91ACE45A-9D6C-44E3-8DE3-15F4D8122C91@amazon.com> References: <3A8BC488-09D4-44CC-9844-40F3C03BBD6D@amazon.com> <5D1CD1D6-FA22-42E8-9939-555C976B1D88@azul.com> <81ebb5e7-60ab-3b11-f4fe-d6f548a930c1@redhat.com> <0452FC3A-C364-457F-A94C-188F18B93BC0@amazon.com> <79e3c6bb-4521-5d10-0104-53faf4bc89df@redhat.com> <91ACE45A-9D6C-44E3-8DE3-15F4D8122C91@amazon.com> Message-ID: <1f391eb0-f0d9-91b3-3181-352a196804bc@redhat.com> On 16/07/2019 16:04, Hohensee, Paul wrote: > They're pretty much all general issues. We could fix them first. > > Paul > Yeah... I was going to say "It works for me", and then remembered while writing my reply that I have a bunch of flags to turn off -Werror for return types and readdir_r to make that happen. The latter is fixed in 8u-dev and I should be able to get the patches in for the former once the CPU is out of the way. Another good low-hanging fruit for AArch64 would be making sure it builds using the Zero assembler port. That would make sure all the configure and JDK architecture support bits are in place before adding the HotSpot port. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From fedor.burdun at azul.com Tue Jul 16 17:42:23 2019 From: fedor.burdun at azul.com (Fedor Burdun) Date: Tue, 16 Jul 2019 17:42:23 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently Message-ID: <139d1e126a3f42d187da3c80703b4ecf@azul.com> Hello everyone, The issue described in bugs 8031126/8030631 is still reproducible on java8. May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? The adjusted patch is: <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< diff --git a/src/os/linux/vm/os_linux.cpp b/src/os/linux/vm/os_linux.cpp --- a/src/os/linux/vm/os_linux.cpp +++ b/src/os/linux/vm/os_linux.cpp @@ -6093,8 +6093,6 @@ PRAGMA_DIAG_PUSH PRAGMA_FORMAT_NONLITERAL_IGNORED static jlong slow_thread_cpu_time(Thread *thread, bool user_sys_cpu_time) { - static bool proc_task_unchecked = true; - static const char *proc_stat_path = "/proc/%d/stat"; pid_t tid = thread->osthread()->thread_id(); char *s; char stat[2048]; @@ -6107,23 +6105,7 @@ long ldummy; FILE *fp; - // The /proc//stat aggregates per-process usage on - // new Linux kernels 2.6+ where NPTL is supported. - // The /proc/self/task//stat still has the per-thread usage. - // See bug 6328462. - // There possibly can be cases where there is no directory - // /proc/self/task, so we check its availability. - if (proc_task_unchecked && os::Linux::is_NPTL()) { - // This is executed only once - proc_task_unchecked = false; - fp = fopen("/proc/self/task", "r"); - if (fp != NULL) { - proc_stat_path = "/proc/self/task/%d/stat"; - fclose(fp); - } - } - - sprintf(proc_name, proc_stat_path, tid); + snprintf(proc_name, 64, "/proc/self/task/%d/stat", tid); fp = fopen(proc_name, "r"); if ( fp == NULL ) return -1; statlen = fread(stat, 1, 2047, fp); <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Unfortunately I can not update OpenJDK bug for such request since I have not OpenJDK id. Thanks, Fedor From gnu.andrew at redhat.com Tue Jul 16 21:22:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Jul 2019 22:22:52 +0100 Subject: OpenJDK 8u222 Released Message-ID: <8d71330f-7cf6-a7c6-2f8f-5dd1b0e87916@redhat.com> We are pleased to announce the release of OpenJDK 8u222. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b10.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b10.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 4937dc03e5a6a0bec34576b3300799ee0edc80029c938ffcfc55a9f5ef10d304 openjdk8u222-b10.tar.xz 1ead0e3ce8c5eb4ef13a7580781b643c7fe21d01cc67e4cb54d34c9d023d1888 openjdk8u222-b10.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b10.sha256 What's New? =========== Security fixes - S8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image - S8208698, CVE-2019-2745: Improved ECC Implementation - S8212328, CVE-2019-2762: Exceptional throw cases - S8213431, CVE-2019-2766: Improve file protocol handling - S8213432, CVE-2019-2769: Better copies of CopiesList - S8216381, CVE-2019-2786: More limited privilege usage - S8217563: Improve realm maintenance - S8218863: Better endpoint checks - S8218873: Improve JSSE endpoint checking - S8218876, CVE-2019-7317: Improve PNG support options - S8219018: Adjust positions of glyphs - S8219020: Table alternate substitutions - S8219775: Certificate validation improvements - S8220192: Better outlook for SecureRandom - S8220517: Enhanced GIF support - S8221518, CVE-2019-2816: Normalize normalization - S8223511, CVE-2019-2842: Extended AES support Other changes - S7100957: SOCKS proxying does not work with IPv6 connections - S7102541: RFE: os::set_native_thread_name() cleanups - S8019816: [TEST_BUG][macosx] closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT - S8022879: TEST_BUG: sun/nio/cs/MalformedSurrogates.java fails intermittently - S8025209: Intermittent test failure java/net/Socket/asyncClose/AsyncClose.java - S8030690: TEST_BUG java/nio/Buffer/Chars.java fails intermittently - S8031113: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Basic.java fails intermittently - S8031145: Re-examine closed i18n tests to see it they can be moved to the jdk repository. - S8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once - S8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException - S8040211: Update LSR datafile for BCP 47 - S8044289: In ImageIO.write() and ImageIO.read() null stream is not handled properly. - S8048782: OpenJDK: PiscesCache : xmax/ymax rounding up can cause RasterFormatException - S8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup as a platform neutral class name - S8055814: [TESTBUG] runtime/NMT/NMTWithCDS.java fails with product builds due to missing UnlockDiagnosticVMOptions - S8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests - S8073078: java/nio/file/FileStore/Basic.java sensitive to NFS configuration - S8075939: Stream.flatMap() causes breaking of short-circuiting of terminal operations - S8129988: JSSE should create a single instance of the cacerts KeyStore - S8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify the dump - S8135248: Add utility methods to check indexes and ranges - S8137231: sun/security/rsa/SpecTest.java timeout with Agent error: java.lang.Exception - S8142493: Utility methods to check indexes and ranges doesn't specify behavior when function produces null - S8143097: java/net/ipv6tests/UdpTest.java fails intermittently with "checkTime failed: got 1998 expected 4000" - S8144332: HSDB could not terminate when close button is pushed. - S8146458: Improve exception reporting for Objects.checkIndex/checkFromToIndex/checkFromIndexSize - S8150013: ParNew: Prune nmethods scavengable list. - S8151225: Mark SpecTest.java as intermittently failing - S8151226: Mark UdpTest.java as intermittently failing - S8151322: Implement os::set_native_thread_name() on Solaris - S8151539: Remove duplicate AlwaysTrueClosures - S8153732: Windows remote printer changes do not reflect in lookupPrintServices() - S8154156: PPC64: improve array copy stubs by using vector instructions - S8154387: Parallel unordered Stream.limit() tries to collect 128 elements even if limit is less - S8155794: Move Objects.checkIndex BiFunction accepting methods to an internal package - S8156035: Remove intermittent key from sun/security/rsa/SpecTest.java - S8157287: java/nio/file/FileStore/Basic.java failed with "java.nio.file.AccessDeniedException : /zones/zoneone/root " - S8157792: After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones - S8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions - S8166684: PPC64: implement intrinsic code with vector instructions for Unsafe.copyMemory() - S8171000: Robot.createScreenCapture() crashes in wayland mode - S8173910: (fs) java/nio/file/FileSystem/Basic.java should conditionally check FileStores - S8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles - S8176237: (fs) java/nio/file/FileStore/Basic.java should conditionally check FileStores - S8177472: Remove hard-coded IANA Subtag Registry map in LocaleEquivalentMap.java - S8179098: Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73) - S8181594: Efficient and constant-time modular arithmetic - S8182999: SunEC throws ProviderException on invalid curves - S8185969: PPC64: Improve VSR support to use up to 64 registers - S8187946: Support ISO 4217 Amendments 163 and 164 - S8189131: Open-source the Oracle JDK Root Certificates - S8189949: Remove Baltimore Cybertrust Code Signing CA - S8190974: Parallel stream execution within a custom ForkJoinPool should obey the parallelism - S8191031: Remove several Symantec Root CAs - S8191404: Upgrading JDK with latest available LSR data from IANA. - S8191844: Remove SECOM root (secomevrootca1) - S8192854: FONTCONFIG_CFLAGS missing from spec.gmk.in - S8193552: ISO 4217 amendment 165 - S8193830: Xalan Update: Xalan Java 2.7.2 - S8195478: sun/text/resources/LocaleDataTest.java fails with java.lang.Exception - S8195774: Add Entrust root certificates - S8195793: Remove GTE CyberTrust Global Root - S8196141: Add GoDaddy root certificates - S8196775: java/net/Socket/asyncClose/Race.java failed intermittently on Windows with ConnectException: Connection refused - S8197546: Fix for 8171000 breaks Solaris + Linux builds - S8199779: Add T-Systems, GlobalSign and Starfield services root certificates - S8201317: X25519/X448 code improvements - S8202026: ISO 4217 amendment 166 - S8202414: Unsafe write after primitive array creation may result in array length change - S8202651: Test ComodoCA.java fails - S8202768: [macos] Appkit thread slows when any Window Manager active - S8202884: SA: Attach/detach might fail on Linux if debugee application create/destroy threads during attaching - S8203190: SessionId.hashCode generates too many collisions - S8203228: Branch-free output conversion for X25519 and X448 - S8203627: Swing applications with JRadioButton and JCheckbox fail to render correctly when using GTK3 and the GTK L&F - S8203872: Upgrading JDK with latest available LSR data from IANA. - S8204269: ISO 4217 amendment 167 - S8204923: Restore Symantec root verisignclass2g2ca - S8204929: Fonts with embedded bitmaps are not always rotated - S8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, RPATH and RUNPATH - S8206955: MethodHandleProxies.asInterfaceInstance does not support default methods - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ? - S8208648: ECC Field Arithmetic Enhancements - S8208746: ISO 4217 Amendment #168 update - S8209506: Add Google Trust Services GlobalSign root certificates - S8209775: ISO 4217 Amendment #169 update - S8209951: Problematic sparc intrinsic: com.sun.crypto.provider.CipherBlockChaining - S8210153: localized currency symbol of VES - S8210416: [linux] Poor StrictMath performance due to non-optimized compilation - S8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization - S8210432: Add additional TeliaSonera root certificate - S8210886: Remove references in xwindows.md to non-existent files. - S8210985: Update the default SSL session cache size to 20480 - S8212202: [Windows] Exception if no printers are installed. - S8213183: InputMethod cannot be used after its restarting - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h - S8213294: Upgrade IANA LSR data - S8213825: assert(false) failed: Non-balanced monitor enter/exit! Likely JNI locking - S8214109: XToolkit is not correctly displayed color on 16-bit high color setting - S8214111: There is no icon in all JOptionPane target image - S8214112: The whole text in target JPasswordField image are not selected - S8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3 - S8214253: Tooltip is transparent rather than having a black background - S8214765: All TrayIcon MessageType icons does not show up with gtk3 option set - S8214770: java/time/test/java/time/format/TestNonIsoFormatter.java failed in non-english locales. - S8214935: Upgrade IANA LSR data - S8215982: (tz) Upgrade time-zone data to tzdata2018i - S8216577: Add GlobalSign's R6 Root certificate - S8217263: Automate DashOffset test - S8217315: Proper units should print more significant digits - S8217597: [TESTBUG] old version docker does not support --cpus - S8218020: Back out accidental changes that belong elsewhere - S8218020: Fix version number in mesa.md 3rd party legal file - S8218152: [javac] fails and exits with no error if a bad annotation processor provided - S8218469: JSlider display issue with slider for GTKLookAndFeel - S8218470: JScrollBar display issue with GTKLookAndFeel - S8218472: JProgressBar display issue with GTKLookAndFeel - S8218473: JOptionPane display issue with GTKLookAndFeel - S8218479: JTextPane display issue with GTKLookAndFeel - S8218674: HTML Tooltip with "img=src" on component doesn't show - S8219781: Localized names for Japanese era Reiwa in COMPAT provider - S8220349: The fix done for JDK-8214253 have caused issues in JTree behaviour - S8220495: Update GIFlib library to the 5.1.8 - S8220718: Missing ResourceMark in nmethod::metadata_do - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use - S8221412: lookupPrintServices() does not always update the list of Windows remote printers - S8221789: make reconfigure broken (jdk8u only) - S8222136: Remove two Comodo root CA certificates that are expiring - S8222137: Remove T-Systems root CA certificate - S8222670: pathological case of JIT recompilation and code cache bloat - S8222965: Backport of JDK-8129988 broke the build - S8222975: Fix 'release' file to reflect actual repo checkin used to compile JDK - S8223499: Remove two DocuSign root certificates that are expiring - S8223537: testlibrary_tests/ctw/ClassesListTest.java fails with Agent timeout frequently - S8223555: Cleanups in cacerts tests - S8223664: Add jtreg tests for 8223528, backport to jdk8u of 8176100 - S8223883: Fix jni.cpp copyright date after 8223528 - S8224560: (tz) Upgrade time-zone data to tzdata2019a - S8224727: Problem list test security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java - S8225065: Revert 8221166 (8u backport of 8048782) - S8225580: tzdata2018i integration causes test failures on jdk-13 - S8225716: G1 GC: Undefined behaviour in G1BlockOffsetTablePart::block_at_or_preceding -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Jul 16 21:38:28 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 16 Jul 2019 22:38:28 +0100 Subject: [RFR] [8u] jdk8u222-b09 & jdk8u222-b10 Message-ID: <9f4a5916-84be-592c-86d9-0c72d7e0eb4d@redhat.com> OpenJDK 8u222 has been released: http://bitly.com/oj8u222 Here are the remaining changes for the jdk8u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u222/ Changes in jdk8u222-b09: - S8135248: Add utility methods to check indexes and ranges - S8142493: Utility methods to check indexes and ranges doesn't specify behavior when function produces null - S8146458: Improve exception reporting for Objects.checkIndex/checkFromToIndex/checkFromIndexSize - S8155794: Move Objects.checkIndex BiFunction accepting methods to an internal package - S8179098: Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73) - S8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image - S8212328, CVE-2019-2762: Exceptional throw cases - S8213431, CVE-2019-2766: Improve file protocol handling - S8213432, CVE-2019-2769: Better copies of CopiesList - S8216381, CVE-2019-2786: More limited privilege usage - S8217563: Improve realm maintenance - S8218863: Better endpoint checks - S8218873: Improve JSSE endpoint checking - S8218876, CVE-2019-7317: Improve PNG support options - S8219775: Certificate validation improvements - S8220192: Better outlook for SecureRandom - S8220517: Enhanced GIF support - S8221518, CVE-2019-2816: Normalize normalization - S8223511, CVE-2019-2842: Extended AES support Changes in jdk8u222-b10: - S8157792: After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones - S8215982: (tz) Upgrade time-zone data to tzdata2018i - S8219018: Adjust positions of glyphs - S8219020: Table alternate substitutions - S8224560: (tz) Upgrade time-zone data to tzdata2019a - S8225580: tzdata2018i integration causes test failures on jdk-13 jdk8u222-b10 is tagged as jdk8u222-ga. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Tue Jul 16 21:44:50 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 16 Jul 2019 21:44:50 +0000 Subject: [RFR] [8u] jdk8u222-b09 & jdk8u222-b10 In-Reply-To: <9f4a5916-84be-592c-86d9-0c72d7e0eb4d@redhat.com> References: <9f4a5916-84be-592c-86d9-0c72d7e0eb4d@redhat.com> Message-ID: <36138233-4DA0-47E7-9DC0-B25A73ED8D3D@amazon.com> Looks good to me, ok to push. Paul ?On 7/16/19, 2:39 PM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: OpenJDK 8u222 has been released: http://bitly.com/oj8u222 Here are the remaining changes for the jdk8u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u222/ Changes in jdk8u222-b09: - S8135248: Add utility methods to check indexes and ranges - S8142493: Utility methods to check indexes and ranges doesn't specify behavior when function produces null - S8146458: Improve exception reporting for Objects.checkIndex/checkFromToIndex/checkFromIndexSize - S8155794: Move Objects.checkIndex BiFunction accepting methods to an internal package - S8179098: Crypto AES/ECB encryption/decryption performance regression (introduced in jdk9b73) - S8191073: JpegImageReader throws IndexOutOfBoundsException when trying to read image data from tables-only image - S8212328, CVE-2019-2762: Exceptional throw cases - S8213431, CVE-2019-2766: Improve file protocol handling - S8213432, CVE-2019-2769: Better copies of CopiesList - S8216381, CVE-2019-2786: More limited privilege usage - S8217563: Improve realm maintenance - S8218863: Better endpoint checks - S8218873: Improve JSSE endpoint checking - S8218876, CVE-2019-7317: Improve PNG support options - S8219775: Certificate validation improvements - S8220192: Better outlook for SecureRandom - S8220517: Enhanced GIF support - S8221518, CVE-2019-2816: Normalize normalization - S8223511, CVE-2019-2842: Extended AES support Changes in jdk8u222-b10: - S8157792: After Integrating tzdata2016d the test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and "Asia/Qyzylorda" Timezones - S8215982: (tz) Upgrade time-zone data to tzdata2018i - S8219018: Adjust positions of glyphs - S8219020: Table alternate substitutions - S8224560: (tz) Upgrade time-zone data to tzdata2019a - S8225580: tzdata2018i integration causes test failures on jdk-13 jdk8u222-b10 is tagged as jdk8u222-ga. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Jul 16 21:54:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 16 Jul 2019 23:54:32 +0200 Subject: [RFR] [8u] jdk8u222-b09 & jdk8u222-b10 In-Reply-To: <9f4a5916-84be-592c-86d9-0c72d7e0eb4d@redhat.com> References: <9f4a5916-84be-592c-86d9-0c72d7e0eb4d@redhat.com> Message-ID: <0543a1e4-7934-a74c-7d69-4cf520e518e0@redhat.com> On 7/16/19 11:38 PM, Andrew John Hughes wrote: > OpenJDK 8u222 has been released: http://bitly.com/oj8u222 > > Here are the remaining changes for the jdk8u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8u222/ corba: jaxp: jaxws: langtools: nashorn: root: Looks good and trivial. hotspot: Looks good. Checked the intrinsic names against JDK changeset. jdk: Looks good. I have a bit of concern about exposing jdk/internal/util/Preconditions.java, which is normally protected by module boundaries in 9+. We can tackle that after this lands. -- Thanks, -Aleksey From amaembo at gmail.com Wed Jul 17 03:49:24 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 17 Jul 2019 10:49:24 +0700 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> Message-ID: Looks good to me, thanks. With best regards, Tagir Valeev. On Mon, Jul 15, 2019 at 3:27 PM Aleksey Shipilev wrote: > On 7/2/19 9:53 PM, Aleksey Shipilev wrote: > > Original RFE: > > https://bugs.openjdk.java.net/browse/JDK-8214687 > > https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 > > > > Patch applies with usual reshufflings. But the test parts require > touchups to compile and run on 8u: > > type inference is not that rich, and there is no Objects.checkIndex. 8u > webrev: > > https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ > > > > Testing: tier1-like suite, new test > > Friendly reminder. > > -- > Thanks, > -Aleksey > > From sgehwolf at redhat.com Wed Jul 17 14:18:33 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 17 Jul 2019 16:18:33 +0200 Subject: OpenJDK 8u222 Released In-Reply-To: <8d71330f-7cf6-a7c6-2f8f-5dd1b0e87916@redhat.com> References: <8d71330f-7cf6-a7c6-2f8f-5dd1b0e87916@redhat.com> Message-ID: <76542cfdfa8b763f4ecaae733079e597cc00c105.camel@redhat.com> Hi, The July update of the OpenJDK 8 updates project builds (8u222-b10) are here: https://adoptopenjdk.net/upstream.html Thanks, Severin On Tue, 2019-07-16 at 22:22 +0100, Andrew John Hughes wrote: > We are pleased to announce the release of OpenJDK 8u222. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b10.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b10.tar.xz.sig > > This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F > > SHA256 checksums: > > 4937dc03e5a6a0bec34576b3300799ee0edc80029c938ffcfc55a9f5ef10d304 > openjdk8u222-b10.tar.xz > 1ead0e3ce8c5eb4ef13a7580781b643c7fe21d01cc67e4cb54d34c9d023d1888 > openjdk8u222-b10.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u222-b10.sha256 > > What's New? > =========== > Security fixes > - S8191073: JpegImageReader throws IndexOutOfBoundsException when > trying to read image data from tables-only image > - S8208698, CVE-2019-2745: Improved ECC Implementation > - S8212328, CVE-2019-2762: Exceptional throw cases > - S8213431, CVE-2019-2766: Improve file protocol handling > - S8213432, CVE-2019-2769: Better copies of CopiesList > - S8216381, CVE-2019-2786: More limited privilege usage > - S8217563: Improve realm maintenance > - S8218863: Better endpoint checks > - S8218873: Improve JSSE endpoint checking > - S8218876, CVE-2019-7317: Improve PNG support options > - S8219018: Adjust positions of glyphs > - S8219020: Table alternate substitutions > - S8219775: Certificate validation improvements > - S8220192: Better outlook for SecureRandom > - S8220517: Enhanced GIF support > - S8221518, CVE-2019-2816: Normalize normalization > - S8223511, CVE-2019-2842: Extended AES support > Other changes > - S7100957: SOCKS proxying does not work with IPv6 connections > - S7102541: RFE: os::set_native_thread_name() cleanups > - S8019816: [TEST_BUG][macosx] > closed/java/awt/BasicStroke/DashZeroWidth.java not on EDT > - S8022879: TEST_BUG: sun/nio/cs/MalformedSurrogates.java fails > intermittently > - S8025209: Intermittent test failure > java/net/Socket/asyncClose/AsyncClose.java > - S8030690: TEST_BUG java/nio/Buffer/Chars.java fails intermittently > - S8031113: TEST_BUG: > java/nio/channels/AsynchronousChannelGroup/Basic.java fails intermittently > - S8031145: Re-examine closed i18n tests to see it they can be moved > to the jdk repository. > - S8031563: TEST_BUG: > java/nio/channels/Selector/ChangingInterests.java failed once > - S8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because > of SocketTimeoutException > - S8040211: Update LSR datafile for BCP 47 > - S8044289: In ImageIO.write() and ImageIO.read() null stream is not > handled properly. > - S8048782: OpenJDK: PiscesCache : xmax/ymax rounding up can cause > RasterFormatException > - S8055705: Rename UnixPrintServiceLookup and Win32PrintServiceLookup > as a platform neutral class name > - S8055814: [TESTBUG] runtime/NMT/NMTWithCDS.java fails with product > builds due to missing UnlockDiagnosticVMOptions > - S8059575: JEP-JDK-8043304: Test task: Tiered Compilation level > transition tests > - S8073078: java/nio/file/FileStore/Basic.java sensitive to NFS > configuration > - S8075939: Stream.flatMap() causes breaking of short-circuiting of > terminal operations > - S8129988: JSSE should create a single instance of the cacerts KeyStore > - S8134030: test/serviceability/dcmd/gc/HeapDumpTest fails to verify > the dump > - S8135248: Add utility methods to check indexes and ranges > - S8137231: sun/security/rsa/SpecTest.java timeout with Agent error: > java.lang.Exception > - S8142493: Utility methods to check indexes and ranges doesn't > specify behavior when function produces null > - S8143097: java/net/ipv6tests/UdpTest.java fails intermittently with > "checkTime failed: got 1998 expected 4000" > - S8144332: HSDB could not terminate when close button is pushed. > - S8146458: Improve exception reporting for > Objects.checkIndex/checkFromToIndex/checkFromIndexSize > - S8150013: ParNew: Prune nmethods scavengable list. > - S8151225: Mark SpecTest.java as intermittently failing > - S8151226: Mark UdpTest.java as intermittently failing > - S8151322: Implement os::set_native_thread_name() on Solaris > - S8151539: Remove duplicate AlwaysTrueClosures > - S8153732: Windows remote printer changes do not reflect in > lookupPrintServices() > - S8154156: PPC64: improve array copy stubs by using vector instructions > - S8154387: Parallel unordered Stream.limit() tries to collect 128 > elements even if limit is less > - S8155794: Move Objects.checkIndex BiFunction accepting methods to an > internal package > - S8156035: Remove intermittent key from sun/security/rsa/SpecTest.java > - S8157287: java/nio/file/FileStore/Basic.java failed with > "java.nio.file.AccessDeniedException : /zones/zoneone/root " > - S8157792: After Integrating tzdata2016d the > test/sun/util/calendar/zi/TestZoneInfo310.java fails for "Asia/Oral" and > "Asia/Qyzylorda" Timezones > - S8158232: PPC64: improve byte, int and long array copy stubs by > using VSX instructions > - S8166684: PPC64: implement intrinsic code with vector instructions > for Unsafe.copyMemory() > - S8171000: Robot.createScreenCapture() crashes in wayland mode > - S8173910: (fs) java/nio/file/FileSystem/Basic.java should > conditionally check FileStores > - S8176100: [REDO][REDO] G1 Needs pre barrier on dereference of weak > JNI handles > - S8176237: (fs) java/nio/file/FileStore/Basic.java should > conditionally check FileStores > - S8177472: Remove hard-coded IANA Subtag Registry map in > LocaleEquivalentMap.java > - S8179098: Crypto AES/ECB encryption/decryption performance > regression (introduced in jdk9b73) > - S8181594: Efficient and constant-time modular arithmetic > - S8182999: SunEC throws ProviderException on invalid curves > - S8185969: PPC64: Improve VSR support to use up to 64 registers > - S8187946: Support ISO 4217 Amendments 163 and 164 > - S8189131: Open-source the Oracle JDK Root Certificates > - S8189949: Remove Baltimore Cybertrust Code Signing CA > - S8190974: Parallel stream execution within a custom ForkJoinPool > should obey the parallelism > - S8191031: Remove several Symantec Root CAs > - S8191404: Upgrading JDK with latest available LSR data from IANA. > - S8191844: Remove SECOM root (secomevrootca1) > - S8192854: FONTCONFIG_CFLAGS missing from spec.gmk.in > - S8193552: ISO 4217 amendment 165 > - S8193830: Xalan Update: Xalan Java 2.7.2 > - S8195478: sun/text/resources/LocaleDataTest.java fails with > java.lang.Exception > - S8195774: Add Entrust root certificates > - S8195793: Remove GTE CyberTrust Global Root > - S8196141: Add GoDaddy root certificates > - S8196775: java/net/Socket/asyncClose/Race.java failed intermittently > on Windows with ConnectException: Connection refused > - S8197546: Fix for 8171000 breaks Solaris + Linux builds > - S8199779: Add T-Systems, GlobalSign and Starfield services root > certificates > - S8201317: X25519/X448 code improvements > - S8202026: ISO 4217 amendment 166 > - S8202414: Unsafe write after primitive array creation may result in > array length change > - S8202651: Test ComodoCA.java fails > - S8202768: [macos] Appkit thread slows when any Window Manager active > - S8202884: SA: Attach/detach might fail on Linux if debugee > application create/destroy threads during attaching > - S8203190: SessionId.hashCode generates too many collisions > - S8203228: Branch-free output conversion for X25519 and X448 > - S8203627: Swing applications with JRadioButton and JCheckbox fail to > render correctly when using GTK3 and the GTK L&F > - S8203872: Upgrading JDK with latest available LSR data from IANA. > - S8204269: ISO 4217 amendment 167 > - S8204923: Restore Symantec root verisignclass2g2ca > - S8204929: Fonts with embedded bitmaps are not always rotated > - S8205916: [test] Fix jdk/tools/launcher/RunpathTest to handle both, > RPATH and RUNPATH > - S8206955: MethodHandleProxies.asInterfaceInstance does not support > default methods > - S8207760: SAXException: Invalid UTF-16 surrogate detected: d83c ? > - S8208648: ECC Field Arithmetic Enhancements > - S8208746: ISO 4217 Amendment #168 update > - S8209506: Add Google Trust Services GlobalSign root certificates > - S8209775: ISO 4217 Amendment #169 update > - S8209951: Problematic sparc intrinsic: > com.sun.crypto.provider.CipherBlockChaining > - S8210153: localized currency symbol of VES > - S8210416: [linux] Poor StrictMath performance due to non-optimized > compilation > - S8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled > without optimization > - S8210432: Add additional TeliaSonera root certificate > - S8210886: Remove references in xwindows.md to non-existent files. > - S8210985: Update the default SSL session cache size to 20480 > - S8212202: [Windows] Exception if no printers are installed. > - S8213183: InputMethod cannot be used after its restarting > - S8213213: Remove src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h > - S8213294: Upgrade IANA LSR data > - S8213825: assert(false) failed: Non-balanced monitor enter/exit! > Likely JNI locking > - S8214109: XToolkit is not correctly displayed color on 16-bit high > color setting > - S8214111: There is no icon in all JOptionPane target image > - S8214112: The whole text in target JPasswordField image are not selected > - S8214252: Expanded & Collapsed nodes of a JTree look the same on GTK3 > - S8214253: Tooltip is transparent rather than having a black background > - S8214765: All TrayIcon MessageType icons does not show up with gtk3 > option set > - S8214770: java/time/test/java/time/format/TestNonIsoFormatter.java > failed in non-english locales. > - S8214935: Upgrade IANA LSR data > - S8215982: (tz) Upgrade time-zone data to tzdata2018i > - S8216577: Add GlobalSign's R6 Root certificate > - S8217263: Automate DashOffset test > - S8217315: Proper units should print more significant digits > - S8217597: [TESTBUG] old version docker does not support --cpus > - S8218020: Back out accidental changes that belong elsewhere > - S8218020: Fix version number in mesa.md 3rd party legal file > - S8218152: [javac] fails and exits with no error if a bad annotation > processor provided > - S8218469: JSlider display issue with slider for GTKLookAndFeel > - S8218470: JScrollBar display issue with GTKLookAndFeel > - S8218472: JProgressBar display issue with GTKLookAndFeel > - S8218473: JOptionPane display issue with GTKLookAndFeel > - S8218479: JTextPane display issue with GTKLookAndFeel > - S8218674: HTML Tooltip with "img=src" on component doesn't show > - S8219781: Localized names for Japanese era Reiwa in COMPAT provider > - S8220349: The fix done for JDK-8214253 have caused issues in JTree > behaviour > - S8220495: Update GIFlib library to the 5.1.8 > - S8220718: Missing ResourceMark in nmethod::metadata_do > - S8221263: [TEST_BUG] RemotePrinterStatusRefresh test is hard to use > - S8221412: lookupPrintServices() does not always update the list of > Windows remote printers > - S8221789: make reconfigure broken (jdk8u only) > - S8222136: Remove two Comodo root CA certificates that are expiring > - S8222137: Remove T-Systems root CA certificate > - S8222670: pathological case of JIT recompilation and code cache bloat > - S8222965: Backport of JDK-8129988 broke the build > - S8222975: Fix 'release' file to reflect actual repo checkin used to > compile JDK > - S8223499: Remove two DocuSign root certificates that are expiring > - S8223537: testlibrary_tests/ctw/ClassesListTest.java fails with > Agent timeout frequently > - S8223555: Cleanups in cacerts tests > - S8223664: Add jtreg tests for 8223528, backport to jdk8u of 8176100 > - S8223883: Fix jni.cpp copyright date after 8223528 > - S8224560: (tz) Upgrade time-zone data to tzdata2019a > - S8224727: Problem list test > security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java > - S8225065: Revert 8221166 (8u backport of 8048782) > - S8225580: tzdata2018i integration causes test failures on jdk-13 > - S8225716: G1 GC: Undefined behaviour in > G1BlockOffsetTablePart::block_at_or_preceding > From hohensee at amazon.com Wed Jul 17 14:35:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Jul 2019 14:35:52 +0000 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> Message-ID: <32553E60-FA21-44F2-AF28-CC93A3A08E6C@amazon.com> Turns out that Preconditions.java is part of the one of the security patches released yesterday (thanks, Andrew, for pointing that out!), so indeed can be used here. Paul ?On 7/16/19, 12:26 AM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: On 15/07/2019 09:27, Aleksey Shipilev wrote: > On 7/2/19 9:53 PM, Aleksey Shipilev wrote: >> Original RFE: >> https://bugs.openjdk.java.net/browse/JDK-8214687 >> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 >> >> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: >> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: >> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ >> >> Testing: tier1-like suite, new test > > Friendly reminder. > Friendly reminder there's a release today :) Objects.checkIndex is simply a wrapper around Preconditions.checkIndex: public static int checkIndex(int index, int length) { return Preconditions.checkIndex(index, length, null); } which is in 8u. Probably worth adding the 2-argument version to Preconditions. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Jul 17 14:40:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 17 Jul 2019 15:40:26 +0100 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <32553E60-FA21-44F2-AF28-CC93A3A08E6C@amazon.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <32553E60-FA21-44F2-AF28-CC93A3A08E6C@amazon.com> Message-ID: On 17/07/2019 15:35, Hohensee, Paul wrote: > Turns out that Preconditions.java is part of the one of the security patches released yesterday (thanks, Andrew, for pointing that out!), so indeed can be used here. > > Paul > Well, not a security patch, but a backport relating to a security patch: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/0da125166b2b was public as: https://hg.openjdk.java.net/jdk/jdk/rev/080776992b29 already, just to be clear I wasn't leaking anything non-public :) I'll merge to jdk8u-dev so Aleksey can rework his fix. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From dcherepanov at azul.com Thu Jul 18 08:52:22 2019 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 18 Jul 2019 08:52:22 +0000 Subject: CVF: New JDK Committer: Andrey Petushkov In-Reply-To: References: Message-ID: <92330EDA-0736-497D-A1A4-11C1D66BA794@azul.com> Vote: yes > On Jun 14, 2019, at 7:38 PM, Mario Torre wrote: > > Hi all, > > I hereby nominate Andrey Petushkov (apetushkov) to JDK8u-dev Committer. > > Andrey is part of the Azul Systems, Inc. JVM team and has already > contributed a few fixes into OpenJDK: > > https://bugs.openjdk.java.net/browse/JDK-8153107 > https://bugs.openjdk.java.net/browse/JDK-8215879 > https://bugs.openjdk.java.net/browse/JDK-8184989 > > And he is working on the JFR backport, which consist of already > several patches under review. > > Votes are due by July 28 19:00 CET. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Thu Jul 18 21:55:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 18 Jul 2019 23:55:45 +0200 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate Message-ID: This is original 8u fix: https://bugs.openjdk.java.net/browse/JDK-8228405 https://cr.openjdk.java.net/~shade/8228405/webrev.01/ See the bug for discussion how it came to happen this way. Testing: tier1-like scenario -- Thanks, -Aleksey From abrygin at azul.com Fri Jul 19 08:25:26 2019 From: abrygin at azul.com (Andrew Brygin) Date: Fri, 19 Jul 2019 08:25:26 +0000 Subject: CVF: New JDK Committer: Andrey Petushkov In-Reply-To: References: Message-ID: <598A5C0B-E360-407F-88F7-6C977D327A04@azul.com> Vote: yes Thanks, Andrew > On Jun 14, 2019, at 7:38 PM, Mario Torre wrote: > > Hi all, > > I hereby nominate Andrey Petushkov (apetushkov) to JDK8u-dev Committer. > > Andrey is part of the Azul Systems, Inc. JVM team and has already > contributed a few fixes into OpenJDK: > > https://bugs.openjdk.java.net/browse/JDK-8153107 > https://bugs.openjdk.java.net/browse/JDK-8215879 > https://bugs.openjdk.java.net/browse/JDK-8184989 > > And he is working on the JFR backport, which consist of already > several patches under review. > > Votes are due by July 28 19:00 CET. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Cheers, > Mario > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Fri Jul 19 16:16:08 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 19 Jul 2019 17:16:08 +0100 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil Message-ID: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8228440 This cleans up the backport of JDK-8179098 by moving the new ArrayUtil methods (inside a new class, RangeUtil) and the Preconditions class into the com.sun.crypto.provider class that makes use of them, avoiding the need for such checks to cross two package boundaries (sun.security.util & jdk.internal.util) Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Fri Jul 19 17:46:58 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 19 Jul 2019 19:46:58 +0200 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil In-Reply-To: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> References: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> Message-ID: On 7/19/19 6:16 PM, Andrew John Hughes wrote: > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be somewhere in com/sun/... as well? *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some unused methods and/or their extensive Javadocs. Otherwise looks good. Let's hear what others think. -- Thanks, -Aleksey From gnu.andrew at redhat.com Fri Jul 19 17:53:58 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 19 Jul 2019 18:53:58 +0100 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil In-Reply-To: References: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> Message-ID: On 19/07/2019 18:46, Aleksey Shipilev wrote: > On 7/19/19 6:16 PM, Andrew John Hughes wrote: >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ > > *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be > somewhere in com/sun/... as well? > > *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some > unused methods and/or their extensive Javadocs. > > Otherwise looks good. Let's hear what others think. > On both points, I'm trying to minimise divergence from later versions. While both may be appropriate for 8u independently (and I did consider the first of these myself), they don't make any real function difference and I think they'd just create unnecessary headaches if any future patches touch these classes. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Fri Jul 19 18:01:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 19 Jul 2019 20:01:41 +0200 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil In-Reply-To: References: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> Message-ID: <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> On 7/19/19 7:53 PM, Andrew John Hughes wrote: > On 19/07/2019 18:46, Aleksey Shipilev wrote: >> On 7/19/19 6:16 PM, Andrew John Hughes wrote: >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ >> >> *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be >> somewhere in com/sun/... as well? >> >> *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some >> unused methods and/or their extensive Javadocs. >> >> Otherwise looks good. Let's hear what others think. > > On both points, I'm trying to minimise divergence from later versions. > While both may be appropriate for 8u independently (and I did consider > the first of these myself), they don't make any real function difference > and I think they'd just create unnecessary headaches if any future > patches touch these classes. I understand, but once we forked those implementations, there are no "later version" anymore. These are private implementations now, and the simpler they are, the better. -- Thanks, -Aleksey From hohensee at amazon.com Fri Jul 19 20:43:08 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Jul 2019 20:43:08 +0000 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil In-Reply-To: <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> References: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> Message-ID: <7128FFBA-82B5-4E4E-AFAF-2B1C7FF7DB92@amazon.com> Do we actually have to fork? Why isn't this a problem in tip? Paul ?On 7/19/19, 11:02 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: On 7/19/19 7:53 PM, Andrew John Hughes wrote: > On 19/07/2019 18:46, Aleksey Shipilev wrote: >> On 7/19/19 6:16 PM, Andrew John Hughes wrote: >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ >> >> *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be >> somewhere in com/sun/... as well? >> >> *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some >> unused methods and/or their extensive Javadocs. >> >> Otherwise looks good. Let's hear what others think. > > On both points, I'm trying to minimise divergence from later versions. > While both may be appropriate for 8u independently (and I did consider > the first of these myself), they don't make any real function difference > and I think they'd just create unnecessary headaches if any future > patches touch these classes. I understand, but once we forked those implementations, there are no "later version" anymore. These are private implementations now, and the simpler they are, the better. -- Thanks, -Aleksey From mbalao at redhat.com Fri Jul 19 21:08:04 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 19 Jul 2019 18:08:04 -0300 Subject: [RFR 8u] 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space Message-ID: Hi, I'd like to request a review of the jdk8u backport of JDK-6913047 [1]: http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.jdk8u.jdk.00/ Patch applies cleanly (once jdk8u backport of JDK-6946830 [2] is applied), except for: * Trivial path changes * Trivial copyright date changes * mapfile-vers * JDK-8 trivial change * P11Key.java * Reordering changes mostly (minor) * P11Signature.java * Reordering changes mostly (minor) Testing: * No regressions found in sun/security/pkcs11 * Manually forced key extraction and creation to test the new mechanism * To improve performance, keys remain created until first use (same than in JDK-11 and JDK) Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-6913047 [2] - https://bugs.openjdk.java.net/browse/JDK-6946830 From neugens at redhat.com Tue Jul 23 10:03:06 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 23 Jul 2019 12:03:06 +0200 Subject: RFR: 8223147: JFR Backport (to jdk8u) In-Reply-To: <351D8DC2-D5FB-48F3-A60A-A10F97F7B640@azul.com> References: <3E224264-DA96-48B8-8270-2B77B09E190F@azul.com> <351D8DC2-D5FB-48F3-A60A-A10F97F7B640@azul.com> Message-ID: On Tue, May 7, 2019 at 1:42 PM Andrey Petushkov wrote: > > In addition, Ekaterina Vergizova from Azul Systems (katya at azul.com) has backported bunch of JFR fixes atop of initial [...] > Please could you also review these backports here http://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/ > That is single webrev but created from set of individual commits. If one would like to see individual webrevs please let us know > Relevant JFR jtreg tests have passed on all supported platforms Hi Andrey, Yes, those patches are good to push into the staging repository as well. I think it may be a good idea to push all together (but please remember to retain all the bug ids in the commit) once your committer status is on file at the end of the week. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Tue Jul 23 19:47:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 23 Jul 2019 20:47:52 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao Message-ID: I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 Updates Committer. Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it makes little sense for him not to be a committer for 8u. He has already had a number of changes pushed to the 8u repositories by others. [0] [1] Votes are due by 20h00 UTC on the 6th of August, 2019. Only current OpenJDK 8 Updates Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. [0] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() [1] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() [2] http://openjdk.java.net/census#jdk8u [3] http://openjdk.java.net/projects/#committer-vote -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From zgu at redhat.com Tue Jul 23 19:50:58 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 23 Jul 2019 15:50:58 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes -Zhengyu On 7/23/19 3:47 PM, Andrew John Hughes wrote: > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > From gnu.andrew at redhat.com Tue Jul 23 19:52:07 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 23 Jul 2019 20:52:07 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: <48400a4c-bcba-2450-bdbb-7d835a99ed42@redhat.com> On 23/07/2019 20:47, Andrew John Hughes wrote: > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > Vote: Yes -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Tue Jul 23 20:19:54 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Jul 2019 20:19:54 +0000 Subject: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes ?On 7/23/19, 12:48 PM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 Updates Committer. Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it makes little sense for him not to be a committer for 8u. He has already had a number of changes pushed to the 8u repositories by others. [0] [1] Votes are due by 20h00 UTC on the 6th of August, 2019. Only current OpenJDK 8 Updates Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. [0] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() [1] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() [2] http://openjdk.java.net/census#jdk8u [3] http://openjdk.java.net/projects/#committer-vote -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Jul 24 02:56:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Jul 2019 03:56:23 +0100 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate In-Reply-To: References: Message-ID: <5c27027a-0de7-cc8e-7f01-6d766d225ac0@redhat.com> On 18/07/2019 22:55, Aleksey Shipilev wrote: > This is original 8u fix: > https://bugs.openjdk.java.net/browse/JDK-8228405 > https://cr.openjdk.java.net/~shade/8228405/webrev.01/ > > See the bug for discussion how it came to happen this way. > > Testing: tier1-like scenario > It looks like the full story goes along the lines of: 1. JDK-8182299 [0] is committed to OpenJDK 10. 2. JDK-8173770 is developed in secret as part of the July 2017 CPU. 3. When the CPU is pushed to the public tree, it has to be merged with 8182299, but 8173770 deletes the code that 8182299 fixes up: diff --git a/hotspot/src/share/vm/opto/loopPredicate.cpp b/hotspot/src/share/vm/opto/loopPredicate.cpp --- a/hotspot/src/share/vm/opto/loopPredicate.cpp +++ b/hotspot/src/share/vm/opto/loopPredicate.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2017, 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 @@ -662,9 +662,13 @@ if (offset && (!offset->is_Con() || offset->get_int() != 0)){ max_idx_expr = new AddINode(max_idx_expr, offset); register_new_node(max_idx_expr, ctrl); - if (TraceLoopPredicate) - if (offset->is_Con()) predString->print("+ %d ", offset->get_int()); - else predString->print("+ offset "); + if (TraceLoopPredicate) { + if (offset->is_Con()) { + predString->print("+ %d ", offset->get_int()); + } else { + predString->print("+ offset "); + } + } } CmpUNode* cmp = new CmpUNode(max_idx_expr, range); and introduces three new cases of the same thing. Thus, in this case, the merge is probably the right place to do this (even though it's a bit ugly). The alternative would have been to regress part of 8182299 in 10 during the merge, and then re-apply it in the form of the patch you've posted here. Of course, 8u doesn't have 8182299, so it was never fixed in either version of loopPredicate.cpp. In short, patch looks fine to me. Simon has actually proposed a backport of 8182299 that I haven't had chance to look at yet, so I don't know if he also covered this or not. [0] https://bugs.openjdk.java.net/browse/JDK-8182299 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Jul 24 03:52:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Jul 2019 04:52:44 +0100 Subject: [RFR 8u] 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space In-Reply-To: References: Message-ID: On 19/07/2019 22:08, Martin Balao wrote: > Hi, > > I'd like to request a review of the jdk8u backport of JDK-6913047 [1]: > http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.jdk8u.jdk.00/ > > Patch applies cleanly (once jdk8u backport of JDK-6946830 [2] is > applied), except for: > > * Trivial path changes > > * Trivial copyright date changes > > * mapfile-vers > * JDK-8 trivial change > > * P11Key.java > * Reordering changes mostly (minor) > > * P11Signature.java > * Reordering changes mostly (minor) > > Testing: > > * No regressions found in sun/security/pkcs11 > > * Manually forced key extraction and creation to test the new mechanism > * To improve performance, keys remain created until first use (same > than in JDK-11 and JDK) > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-6913047 > [2] - https://bugs.openjdk.java.net/browse/JDK-6946830 > Changes look good to me, though the webrev seems to have also included 6946830. Please keep webrevs to just the patch being reviewed to make the process easier. I've pushed both on your behalf, prior to you getting commit access. I await posts for JDK-8216597 & JDK-8220513. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Wed Jul 24 08:44:00 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 24 Jul 2019 10:44:00 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: <3ac3a7809ad9c9dcbc0300b581d1ed056d2fb4ed.camel@redhat.com> Vote: yes On Tue, 2019-07-23 at 20:47 +0100, Andrew John Hughes wrote: > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote From shade at redhat.com Wed Jul 24 08:46:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 10:46:01 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes On 7/23/19 9:47 PM, Andrew John Hughes wrote: > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. -- Thanks, -Aleksey From OGATAK at jp.ibm.com Wed Jul 24 08:48:17 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 24 Jul 2019 17:48:17 +0900 Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: Support AES intrinsics on Big Endian Message-ID: Hi, May I get review for backport of 8188868: PPC64: Support AES intrinsics on Big Endian? The original patch itself can be applied cleanly (besides difference of the source directory structure). However, one chunk failed because the code just after the patched code was modified, so I manually applied the chunk and renewed the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8188868 Webrev: http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8188868/webrev.02/ This backport is low risk and affects only PPC64 only. I verified there was no degradation in "make test" results and SPECjbb 2015 ran fine. The intrinsics added in this changeset improved max jOPS by 5% and critical jOPS by 4%. Regards, Ogata From christoph.langer at sap.com Wed Jul 24 12:33:44 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 24 Jul 2019 12:33:44 +0000 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Andrew John Hughes > Sent: Dienstag, 23. Juli 2019 21:48 > To: 'jdk8u-dev at openjdk.java.net' > Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao > > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(auth > or(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=( > author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge > () > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From neugens.limasoftware at gmail.com Wed Jul 24 13:03:39 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Wed, 24 Jul 2019 15:03:39 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario Il giorno mar 23 lug 2019 alle ore 21:48 Andrew John Hughes ha scritto: > > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From gromero at linux.vnet.ibm.com Wed Jul 24 13:31:34 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 24 Jul 2019 10:31:34 -0300 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: <2b744e7a-8e2d-c55a-61e7-87e50e599e3c@linux.vnet.ibm.com> Vote: yes On 07/23/2019 04:47 PM, Andrew John Hughes wrote: > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > From shade at redhat.com Wed Jul 24 14:57:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 16:57:43 +0200 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate In-Reply-To: <5c27027a-0de7-cc8e-7f01-6d766d225ac0@redhat.com> References: <5c27027a-0de7-cc8e-7f01-6d766d225ac0@redhat.com> Message-ID: <15172bf2-b286-8715-4c11-bca9debccad9@redhat.com> On 7/24/19 4:56 AM, Andrew John Hughes wrote: > Thus, in this case, the merge is probably the right place to do this > (even though it's a bit ugly). The alternative would have been to > regress part of 8182299 in 10 during the merge, and then re-apply it in > the form of the patch you've posted here. > > Of course, 8u doesn't have 8182299, so it was never fixed in either > version of loopPredicate.cpp. > > In short, patch looks fine to me. Simon has actually proposed a backport > of 8182299 that I haven't had chance to look at yet, so I don't know if > he also covered this or not. Thanks. Just checking: we are fine with pushing the proposed patch to 8u then? -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Jul 24 15:28:21 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Jul 2019 16:28:21 +0100 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate In-Reply-To: <15172bf2-b286-8715-4c11-bca9debccad9@redhat.com> References: <5c27027a-0de7-cc8e-7f01-6d766d225ac0@redhat.com> <15172bf2-b286-8715-4c11-bca9debccad9@redhat.com> Message-ID: <7e49a066-45ef-a243-5fcc-35cdd9e2b13b@redhat.com> On 24/07/2019 15:57, Aleksey Shipilev wrote: > On 7/24/19 4:56 AM, Andrew John Hughes wrote: >> Thus, in this case, the merge is probably the right place to do this >> (even though it's a bit ugly). The alternative would have been to >> regress part of 8182299 in 10 during the merge, and then re-apply it in >> the form of the patch you've posted here. >> >> Of course, 8u doesn't have 8182299, so it was never fixed in either >> version of loopPredicate.cpp. >> >> In short, patch looks fine to me. Simon has actually proposed a backport >> of 8182299 that I haven't had chance to look at yet, so I don't know if >> he also covered this or not. > > Thanks. Just checking: we are fine with pushing the proposed patch to 8u then? > Yes. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Jul 24 15:41:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 17:41:59 +0200 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate In-Reply-To: References: Message-ID: <25fbb1c8-c60e-ec89-45e7-f741624309b1@redhat.com> On 7/18/19 11:55 PM, Aleksey Shipilev wrote: > This is original 8u fix: > https://bugs.openjdk.java.net/browse/JDK-8228405 > https://cr.openjdk.java.net/~shade/8228405/webrev.01/ Andrew had reviewed. But since this is the original patch, I'd like another reviewer to check the change. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Jul 24 16:16:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 24 Jul 2019 17:16:22 +0100 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil In-Reply-To: <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> References: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> Message-ID: <24b83df1-0457-a735-2cd8-9accddb5823f@redhat.com> On 19/07/2019 19:01, Aleksey Shipilev wrote: > On 7/19/19 7:53 PM, Andrew John Hughes wrote: >> On 19/07/2019 18:46, Aleksey Shipilev wrote: >>> On 7/19/19 6:16 PM, Andrew John Hughes wrote: >>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ >>> >>> *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be >>> somewhere in com/sun/... as well? >>> >>> *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some >>> unused methods and/or their extensive Javadocs. >>> >>> Otherwise looks good. Let's hear what others think. >> >> On both points, I'm trying to minimise divergence from later versions. >> While both may be appropriate for 8u independently (and I did consider >> the first of these myself), they don't make any real function difference >> and I think they'd just create unnecessary headaches if any future >> patches touch these classes. > > I understand, but once we forked those implementations, there are no "later version" anymore. These > are private implementations now, and the simpler they are, the better. > I disagree. At present, they are as close to upstream as possible, with only the necessary changes to make them work in 8u. The changes you suggest would be additional cosmetic changes that only serve to make the code diverge further. On the first point, this is also true for 11u, following JDK-8155794, which moved the vast majority of Objects.checkIndex code into the Preconditions class. So really, such a change to be a testcase for Preconditions would make sense there too. On the second point, it may be that a future backport needs such code and we'd only have to reintroduce it. Also, looking at the JDK 11 codebase, I only see Preconditions.checkFromToIndex being used by Objects and not ArrayUtil. So you seem to be suggesting to just remove a couple of methods AFAICS. Either way, I think such additional changes should be part of a separate changeset and not thrown into this unrelated one. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Jul 24 16:18:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 18:18:12 +0200 Subject: [RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil In-Reply-To: <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> References: <8d95ba99-efcc-b1eb-92ce-6c8147d9e2cc@redhat.com> <6679eaaf-baf0-25d5-d8de-30325cb22f27@redhat.com> Message-ID: <4b89ac0f-a0de-8851-a03d-4867adeff0f1@redhat.com> On 7/19/19 8:01 PM, Aleksey Shipilev wrote: > On 7/19/19 7:53 PM, Andrew John Hughes wrote: >> On 19/07/2019 18:46, Aleksey Shipilev wrote: >>> On 7/19/19 6:16 PM, Andrew John Hughes wrote: >>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/ >>> >>> *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be >>> somewhere in com/sun/... as well? >>> >>> *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some >>> unused methods and/or their extensive Javadocs. >>> >>> Otherwise looks good. Let's hear what others think. >> >> On both points, I'm trying to minimise divergence from later versions. >> While both may be appropriate for 8u independently (and I did consider >> the first of these myself), they don't make any real function difference >> and I think they'd just create unnecessary headaches if any future >> patches touch these classes. > > I understand, but once we forked those implementations, there are no "later version" anymore. These > are private implementations now, and the simpler they are, the better. On the second thought, whatever is simpler. We can hope that any patch to Preconditions, etc would discover another, com.sun.*-specific version and patch it too. I pessimistically foresee this would not happen, but I care less about this today. -- Thanks, -Aleksey From mbalao at redhat.com Wed Jul 24 19:18:23 2019 From: mbalao at redhat.com (Martin Balao) Date: Wed, 24 Jul 2019 16:18:23 -0300 Subject: [RFR 8u] 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider Message-ID: <6b0eb467-5ff4-2d4a-f5ee-4fe2ddebfd69@redhat.com> Hi, I'd like to request a review for the JDK-8 backport of 8220513 [1]: http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.jdk8u.jdk.00/ JDK patch applies cleanly, except for P11Key.java part (which requires some reordering) and paths. Note: this patch is part of the SunPKCS11 memory leak fix sequence (6946830 -> 6913047 -> 8216597 -> 8220513). 6946830 and 6913047 JDK-8 backports have been pushed already. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8220513 From hohensee at amazon.com Wed Jul 24 19:39:13 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 24 Jul 2019 19:39:13 +0000 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate In-Reply-To: <25fbb1c8-c60e-ec89-45e7-f741624309b1@redhat.com> References: <25fbb1c8-c60e-ec89-45e7-f741624309b1@redhat.com> Message-ID: <4A514F0C-C0D6-44DD-BA41-00E1D51BDC86@amazon.com> Looks good. Paul ?On 7/24/19, 8:43 AM, "jdk8u-dev on behalf of Aleksey Shipilev" wrote: On 7/18/19 11:55 PM, Aleksey Shipilev wrote: > This is original 8u fix: > https://bugs.openjdk.java.net/browse/JDK-8228405 > https://cr.openjdk.java.net/~shade/8228405/webrev.01/ Andrew had reviewed. But since this is the original patch, I'd like another reviewer to check the change. -- Thanks, -Aleksey From shade at redhat.com Wed Jul 24 19:44:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 24 Jul 2019 21:44:25 +0200 Subject: [8u] RFR 8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate In-Reply-To: <4A514F0C-C0D6-44DD-BA41-00E1D51BDC86@amazon.com> References: <25fbb1c8-c60e-ec89-45e7-f741624309b1@redhat.com> <4A514F0C-C0D6-44DD-BA41-00E1D51BDC86@amazon.com> Message-ID: On 7/24/19 9:39 PM, Hohensee, Paul wrote: > Looks good. Thanks! Pushed. -- -Aleksey From sgehwolf at redhat.com Thu Jul 25 15:02:14 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 25 Jul 2019 17:02:14 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> Message-ID: <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> On Mon, 2019-07-08 at 14:35 +0200, Severin Gehwolf wrote: > Hi Andrew, > > On Fri, 2019-06-28 at 14:45 +0100, Andrew John Hughes wrote: > > On 28/06/2019 10:52, Severin Gehwolf wrote: > > > Hi Andrew, > > > > > > On Thu, 2019-06-27 at 17:36 +0100, Andrew John Hughes wrote: > > > > On 22/05/2019 17:34, Severin Gehwolf wrote: > > > > > Hi, > > > > > > > > > > Could I please get reviews for this minimal implementation of a tier1- > > > > > like test set for JDK 8u? The implementation is rather barebones as I > > > > > don't think it's worth rewriting the build system just for a command > > > > > that runs a certain set of tests across a select set of repositories. > > > > > I've re-used existing work in Makefiles as much as possible. After this > > > > > patch one can do: > > > > > > > > > > $ make test TEST="tier1" > > > > > > > > > > Inspiration came from JDK 11u's tier1. As for prior art to this, I've > > > > > only found "make test" to be working for JDK 8u from the top level. > > > > > Yet, it doesn't run any hotspot tests, exits with a zero code on test > > > > > failures and doesn't present a summary at the end. Overall not a nice > > > > > developer experience. > > > > > > > > > > This patch makes it easier for a developers tests. It presents a > > > > > summary at the end, returns non-zero on test failures so this can get > > > > > used in CI and runs hotspot tests. > > > > > > > > > > As a follow-on we can work on fixing/excluding tests so that we always > > > > > have a passing set of tests for developers to run before a checkin. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222737 > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/ > > > > > (includes changes to top/hotspot/jdk/langtools repos) > > > > > > > > > > Example excerpt from a run: > > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/example_output.txt > > > > > > > > > > Thoughts? > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > Is there a reason for creating new tier definitions here rather than > > > > backporting the existing ones? > > > > > > Yes. The tests in JDK 8 are significantly different from JDK 11. Most > > > notably the number of tests available and defined test groups. > > > Backporting the JDK 11 changes seems like fitting a square peg into a > > > round hole. > > > > > > The JDK 8u "tier1" could only be a rough approximation of the JDK 11 > > > "tier1" at best. There is also no intention to make the test output > > > 100% identical to JDK 11 as bringing back those changes would be too > > > invasive. > > > > > > I believe the proposed patch is a reasonable minimal patch which aids > > > 8u developer's testing. > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8075543 > > > > > > > > The subtasks also cover nashorn & jaxp which are missed here. jaxp would > > > > need JDK-8065673, JDK-8051540 and friends to convert its tests to jtreg. > > > > > > Sure. We can consider adding later tiers in upcoming work. That's not > > > the priority, though. Note that tier1 tests in JDK 11 only run > > > jdk/lantools/hotspot tests. The intention of this initial patch would > > > be to have some testing "baseline" covering a reasonable set of repos > > > and tests. > > > > > > Thanks, > > > Severin > > > > > > > I'm not talking about JDK 11 changes. These are changes in JDK 9. > > > > For example, > > > > https://hg.openjdk.java.net/jdk9/dev/jdk/rev/cd4aea326e89 > > > > adds groups to two tiers, all of which exist in 8u as well. It's not > > clear where the list in your patch comes from and it appears to add a > > bunch of arbitrary other tests beyond the tier 1 defined in the JDK 9 > > change. > > Other changes to the JDK tier1 definition were taken from current JDK > 11u. > > > It would make more sense to me to backport JDK-8075544 & JDK-8075573 as > > pre-requisites rather than creating completely new definitions. > > Done now. I've added fix-request comments/labels to the above bugs and > rebased on top of them. New jdk changeset: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of > JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo > added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK- > 8132854. > > OK to push? Any more thoughts? Thanks, Severin From adinn at redhat.com Thu Jul 25 15:29:03 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 25 Jul 2019 16:29:03 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: <6c113d88-e036-9054-05eb-6615ff3d6959@redhat.com> Vote: yes On 23/07/2019 20:47, Andrew John Hughes wrote: > I hereby nominate Martin Balao (mbalao) for the role of OpenJDK 8 > Updates Committer. > > Martin is already a committer for OpenJDK HEAD and OpenJDK 7, so it > makes little sense for him not to be a committer for 8u. He has already > had a number of changes pushed to the 8u repositories by others. [0] [1] > > Votes are due by 20h00 UTC on the 6th of August, 2019. > > Only current OpenJDK 8 Updates Committers [2] are eligible to vote on > this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/log?revcount=200&rev=(author(mbalao)+or+desc(%22mbalao%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From serguei.spitsyn at oracle.com Thu Jul 25 17:03:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Jul 2019 10:03:55 -0700 Subject: CFV: New OpenJDK 8 Updates Committer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes From mbalao at redhat.com Thu Jul 25 21:51:53 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 25 Jul 2019 18:51:53 -0300 Subject: [8u] RFR 8201627: Kerberos sequence number issues Message-ID: Hi, I'd like to request a review for the jdk8u backport of 8201627 [1]: * http://cr.openjdk.java.net/~mbalao/webrevs/8201627/8201627.webrev.00.jdk8u.jdk/ Changes that were needed to the baseline patch: * Copyright dates * Paths * GetPropertyAction.privilegedGetProperty receives no default value in jdk8u (InitSecContextToken.java) * test/sun/security/krb5/auto/BasicProc.java (several adjustments) * test/sun/security/krb5/auto/Basic.java (minor adjustments) Testing: * No regressions found in sun/security/krb5/auto Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8201627 From shade at redhat.com Fri Jul 26 07:58:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Jul 2019 09:58:44 +0200 Subject: [RFR 8u] 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <6b0eb467-5ff4-2d4a-f5ee-4fe2ddebfd69@redhat.com> References: <6b0eb467-5ff4-2d4a-f5ee-4fe2ddebfd69@redhat.com> Message-ID: On 7/24/19 9:18 PM, Martin Balao wrote: > I'd like to request a review for the JDK-8 backport of 8220513 [1]: > > http://cr.openjdk.java.net/~mbalao/webrevs/8220513/8220513.webrev.jdk8u.jdk.00/ Backport looks good. > JDK patch applies cleanly, except for P11Key.java part (which requires > some reordering) and paths. I assume this means no actual code changes, and just changing the order (of what? methods?) somewhere. I cannot spot the difference against upstream change, though. -- Thanks, -Aleksey From shade at redhat.com Fri Jul 26 08:10:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Jul 2019 10:10:19 +0200 Subject: [8u] RFR 8201627: Kerberos sequence number issues In-Reply-To: References: Message-ID: <3ebf8120-e3d1-ac11-0bf0-2cf2b9c47e1c@redhat.com> On 7/25/19 11:51 PM, Martin Balao wrote: > http://cr.openjdk.java.net/~mbalao/webrevs/8201627/8201627.webrev.00.jdk8u.jdk/ Original change did this block: http://hg.openjdk.java.net/jdk/jdk/rev/261d0ac3b09d#l5.99 Had to find it in the new patch, realized it is buried in "token = ps.readData()" statements. Maybe inline "token" variable to match original change better? Otherwise looks good. -- Thanks, -Aleksey From shade at redhat.com Fri Jul 26 08:44:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Jul 2019 10:44:55 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> Message-ID: On 7/25/19 5:02 PM, Severin Gehwolf wrote: > Any more thoughts? I think we should go on with it. The lack of tier1 in jdk8u is a serious impediment for backports. I have applied all the recent patches (04/jdk, 03/hotspot, 03/langtools/ 02/top), and tier1 works for me. That is, it produces test failures that we really need to get on fixing. -- Thanks, -Aleksey From sgehwolf at redhat.com Fri Jul 26 08:52:58 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jul 2019 10:52:58 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> Message-ID: On Fri, 2019-07-26 at 10:44 +0200, Aleksey Shipilev wrote: > On 7/25/19 5:02 PM, Severin Gehwolf wrote: > > Any more thoughts? > > I think we should go on with it. The lack of tier1 in jdk8u is a serious impediment for backports. I > have applied all the recent patches (04/jdk, 03/hotspot, 03/langtools/ 02/top), and tier1 works for > me. That is, it produces test failures that we really need to get on fixing. Agreed. Adding jdk8u-fix-request to the bug. Thanks, Severin From felix.yang at huawei.com Fri Jul 26 09:01:39 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 26 Jul 2019 09:01:39 +0000 Subject: Request for Approval: Backport of 8146792 : Predicate moved after partial peel may lead to broken graph Message-ID: Hi, Please approve the backport of 8146792 to 8u-dev. This issue can always be reproduced with jdk built from the latest jdk8u master repo: Test case reduced from one fuzz test: public class Test { public static void foo() { int iArr1[] = new int[10]; int iArr2[][] = new int[10][10]; for (long i = 0; i < 8; ++i) { iArr1[(int)i] = 10; for (int j = 0; j < 16; ++j) { iArr1 = iArr2[0]; } } } public static void main(String[] strArr) { for (int i = 0; i < 256; i++) { foo(); } } } Command line: java -XX:+UseSerialGC -XX:-TieredCompilation -XX:-RangeCheckElimination -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:LoopMaxUnroll=1 -XX:-UseCompressedClassPointers -XX:-UseCompressedOops -XX:CompileCommand=compileonly,Test::foo Test JVM crashed due to bad C2 graph. This issue will not trigger with -XX:-UseLoopPredicate. Bug: https://bugs.openjdk.java.net/browse/JDK-8146792 JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2748d975045f This backport is almost clean for the latest jdk8u master repo. Thanks, Felix From sgehwolf at redhat.com Fri Jul 26 12:50:56 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jul 2019 14:50:56 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> Message-ID: On Fri, 2019-07-26 at 10:44 +0200, Aleksey Shipilev wrote: > On 7/25/19 5:02 PM, Severin Gehwolf wrote: > > Any more thoughts? > > I think we should go on with it. The lack of tier1 in jdk8u is a serious impediment for backports. I > have applied all the recent patches (04/jdk, 03/hotspot, 03/langtools/ 02/top), and tier1 works for > me. That is, it produces test failures that we really need to get on fixing. Coming back to this I've realized the fix request comment has been added a while back. Waiting for approval and then I can push it :) Thanks, Severin From gnu.andrew at redhat.com Fri Jul 26 13:46:59 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Jul 2019 14:46:59 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> Message-ID: <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> On 25/07/2019 16:02, Severin Gehwolf wrote: snip... >> >> Done now. I've added fix-request comments/labels to the above bugs and >> rebased on top of them. New jdk changeset: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ >> >> Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of >> JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo >> added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK- >> 8132854. >> >> OK to push? > > Any more thoughts? > > Thanks, > Severin > This webrev lists three different bug IDs. What exactly is being pushed here? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From mbalao at redhat.com Fri Jul 26 15:17:50 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 26 Jul 2019 12:17:50 -0300 Subject: [RFR 8u] 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: References: <6b0eb467-5ff4-2d4a-f5ee-4fe2ddebfd69@redhat.com> Message-ID: <2e63e365-fbf5-d783-a4aa-b25d76aa283d@redhat.com> Hi Aleksey, On 7/26/19 4:58 AM, Aleksey Shipilev wrote: > >> JDK patch applies cleanly, except for P11Key.java part (which requires >> some reordering) and paths. > > I assume this means no actual code changes, and just changing the order (of what? methods?) > somewhere. I cannot spot the difference against upstream change, though. > Actually, this should have applied cleanly... hmm. Anyways, thanks! Martin.- From sgehwolf at redhat.com Fri Jul 26 15:53:29 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 26 Jul 2019 17:53:29 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> Message-ID: Hi Andrew, On Fri, 2019-07-26 at 14:46 +0100, Andrew John Hughes wrote: > On 25/07/2019 16:02, Severin Gehwolf wrote: > > snip... > > > > Done now. I've added fix-request comments/labels to the above bugs and > > > rebased on top of them. New jdk changeset: > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > > > > > Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of > > > JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo > > > added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK- > > > 8132854. > > > > > > OK to push? > > > > Any more thoughts? > > > > Thanks, > > Severin > > > > This webrev lists three different bug IDs. It beats me why webrev lists other bugs. The other two, 8075573 and 8075544, were clean backports and were pushed after jdk8u-fix-yes got added. > What exactly is being pushed > here? The following 4 patches: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ Each of them has a reference to a plain patch file if you prefer to review that. Thanks, Severin From mbalao at redhat.com Fri Jul 26 16:21:08 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 26 Jul 2019 13:21:08 -0300 Subject: [8u] RFR 8201627: Kerberos sequence number issues In-Reply-To: <3ebf8120-e3d1-ac11-0bf0-2cf2b9c47e1c@redhat.com> References: <3ebf8120-e3d1-ac11-0bf0-2cf2b9c47e1c@redhat.com> Message-ID: Hi Aleksey, Thanks for having a look at this. On 7/26/19 5:10 AM, Aleksey Shipilev wrote: > Original change did this block: > http://hg.openjdk.java.net/jdk/jdk/rev/261d0ac3b09d#l5.99 > > Had to find it in the new patch, realized it is buried in "token = ps.readData()" statements. Maybe > inline "token" variable to match original change better? > Webrev.01: http://cr.openjdk.java.net/~mbalao/webrevs/8201627/8201627.webrev.01.jdk8u.jdk/ I've inlined "token". No regressions found in sun/security/krb5/auto. Would you mind pushing on my behalf? Thanks, Martin.- From shade at redhat.com Fri Jul 26 16:25:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 26 Jul 2019 18:25:12 +0200 Subject: [8u] RFR 8201627: Kerberos sequence number issues In-Reply-To: References: <3ebf8120-e3d1-ac11-0bf0-2cf2b9c47e1c@redhat.com> Message-ID: <3e7e38c2-b3c8-5f3a-18e3-a96364ca033c@redhat.com> On 7/26/19 6:21 PM, Martin Balao wrote: > Webrev.01: > http://cr.openjdk.java.net/~mbalao/webrevs/8201627/8201627.webrev.01.jdk8u.jdk/ Looks good. > Would you mind pushing on my behalf? Ping me once it has jdk8u-fix-yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Fri Jul 26 17:32:30 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 26 Jul 2019 18:32:30 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> Message-ID: <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> On 26/07/2019 16:53, Severin Gehwolf wrote: > Hi Andrew, > > On Fri, 2019-07-26 at 14:46 +0100, Andrew John Hughes wrote: >> On 25/07/2019 16:02, Severin Gehwolf wrote: >> >> snip... >> >>>> Done now. I've added fix-request comments/labels to the above bugs and >>>> rebased on top of them. New jdk changeset: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ >>>> >>>> Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of >>>> JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo >>>> added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK- >>>> 8132854. >>>> >>>> OK to push? >>> >>> Any more thoughts? >>> >>> Thanks, >>> Severin >>> >> >> This webrev lists three different bug IDs. > > It beats me why webrev lists other bugs. The other two, 8075573 and > 8075544, were clean backports and were pushed after jdk8u-fix-yes got > added. > >> What exactly is being pushed >> here? > > The following 4 patches: > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ > top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > Each of them has a reference to a plain patch file if you prefer to > review that. > > Thanks, > Severin > Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes in langtools. Are these original changes to this patch or are they backports? Is there a reason langtools needs so much more work than the others? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From adinn at redhat.com Mon Jul 29 09:19:29 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 29 Jul 2019 10:19:29 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> Message-ID: <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> On 26/07/2019 18:32, Andrew John Hughes wrote: > On 26/07/2019 16:53, Severin Gehwolf wrote: >> Hi Andrew, >> >> On Fri, 2019-07-26 at 14:46 +0100, Andrew John Hughes wrote: >>> On 25/07/2019 16:02, Severin Gehwolf wrote: >>> >>> snip... >>> >>>>> Done now. I've added fix-request comments/labels to the above bugs and >>>>> rebased on top of them. New jdk changeset: >>>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ >>>>> >>>>> Test groups definition is the JDK 9 set plus :jdk_jdi test set (part of >>>>> JDK-8198551 in later JDKs). This seems a reasonable test set. Modulo >>>>> added intrinsics testing only relevant for 9+, see JDK-8132855 and JDK- >>>>> 8132854. >>>>> >>>>> OK to push? >>>> >>>> Any more thoughts? >>>> >>>> Thanks, >>>> Severin >>>> >>> >>> This webrev lists three different bug IDs. >> >> It beats me why webrev lists other bugs. The other two, 8075573 and >> 8075544, were clean backports and were pushed after jdk8u-fix-yes got >> added. >> >>> What exactly is being pushed >>> here? >> >> The following 4 patches: >> >> jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ >> hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ >> langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ >> top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ >> >> Each of them has a reference to a plain patch file if you prefer to >> review that. >> >> Thanks, >> Severin >> > > Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes > in langtools. Are these original changes to this patch or are they > backports? Is there a reason langtools needs so much more work than the > others? The langtools Makefile changes appear to be larger because they required adding a load of definitions/macros that are already present in the Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, BUNDLE_UP_AND_EXIT etc). These changes look ok to me. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From sgehwolf at redhat.com Mon Jul 29 10:10:19 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jul 2019 12:10:19 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> Message-ID: On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote: > On 26/07/2019 18:32, Andrew John Hughes wrote: > > On 26/07/2019 16:53, Severin Gehwolf wrote: [...] > > > > > > > What exactly is being pushed > > > > here? > > > > > > The following 4 patches: > > > > > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > > hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > > > langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ > > > top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > > > > > Each of them has a reference to a plain patch file if you prefer to > > > review that. > > > > > > Thanks, > > > Severin > > > > > > > Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes > > in langtools. Are these original changes to this patch or are they > > backports? Is there a reason langtools needs so much more work than the > > others? > The langtools Makefile changes appear to be larger because they required > adding a load of definitions/macros that are already present in the > Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, > BUNDLE_UP_AND_EXIT etc). These changes look ok to me. Yes, exactly. The langools Makefile looks *very* different from jdk/hotspot. In order to get some unified status of test results across all three, these changes were needed. I've opted to make the langools Makefile look more like the ones from jdk and hotspot. Old "make test" from top-level continues to work with these changes (modulo -verbose:nopass=> summary change). Anyway, I had another look at this and made 8075546[1] another pre- requisite which makes the langtools changes slightly smaller. Updated webrevs set, thus, is: jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/ top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8075546 From sgehwolf at redhat.com Mon Jul 29 13:49:12 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jul 2019 15:49:12 +0200 Subject: [8u] RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 Message-ID: Hi, Please review this test stability improvement for JDK 8u. It brings the test in-line with jdk/jdk and, once approved, JDK 11u. The JDK 11 patch didn't apply cleanly. Only differences are: * copyright header => omitted * import statements => fixed manually * no @key randomness in JDK 8u => dropped in JDK 8 patch * String.repeat() => changed as follows diff --git a/test/java/util/zip/ZipFile/MultiThreadedReadTest.java b/test/java/util/zip/ZipFile/MultiThreadedReadTest.java --- a/test/java/util/zip/ZipFile/MultiThreadedReadTest.java +++ b/test/java/util/zip/ZipFile/MultiThreadedReadTest.java @@ -80,7 +80,11 @@ ZipOutputStream zos = new ZipOutputStream(bos)) { ZipEntry e = new ZipEntry(ZIPENTRY_NAME); e.setMethod(ZipEntry.STORED); - byte[] toWrite = "BLAH".repeat(10_000).getBytes(); + StringBuilder blahBuilder = new StringBuilder(); + for (int i = 0; i < 10_000; i++) { + blahBuilder.append("BLAH"); + } + byte[] toWrite = blahBuilder.toString().getBytes(); Bug: https://bugs.openjdk.java.net/browse/JDK-8213561 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213561/jdk8/01/webrev/ original-changeset: http://hg.openjdk.java.net/jdk/jdk/rev/12e8433e2581 Thoughts? Thanks, Severin From neugens at redhat.com Mon Jul 29 15:21:55 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 29 Jul 2019 17:21:55 +0200 Subject: Result: New JDK Committer: Andrey Petushkov Message-ID: Voting for Andrey Petushkov [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Cheers, Mario [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009606.html -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Mon Jul 29 15:32:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 29 Jul 2019 16:32:47 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> Message-ID: <493748f4-655c-c644-f789-ed7132934245@redhat.com> On 29/07/2019 11:10, Severin Gehwolf wrote: > On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote: >> On 26/07/2019 18:32, Andrew John Hughes wrote: >>> On 26/07/2019 16:53, Severin Gehwolf wrote: > [...] >>>> >>>>> What exactly is being pushed >>>>> here? >>>> >>>> The following 4 patches: >>>> >>>> jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ >>>> hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ >>>> langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ >>>> top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ >>>> >>>> Each of them has a reference to a plain patch file if you prefer to >>>> review that. >>>> >>>> Thanks, >>>> Severin >>>> >>> >>> Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes >>> in langtools. Are these original changes to this patch or are they >>> backports? Is there a reason langtools needs so much more work than the >>> others? >> The langtools Makefile changes appear to be larger because they required >> adding a load of definitions/macros that are already present in the >> Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, >> BUNDLE_UP_AND_EXIT etc). These changes look ok to me. > > Yes, exactly. The langools Makefile looks *very* different from > jdk/hotspot. In order to get some unified status of test results across > all three, these changes were needed. I've opted to make the langools > Makefile look more like the ones from jdk and hotspot. > > Old "make test" from top-level continues to work with these changes > (modulo -verbose:nopass=> summary change). > > Anyway, I had another look at this and made 8075546[1] another pre- > requisite which makes the langtools changes slightly smaller. Updated > webrevs set, thus, is: > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/ > top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8075546 > Right. That doesn't answer the question as to the origin of the changes. If I look at the langtools Makefile in OpenJDK 11, it doesn't have these changes. Should they not go there first if they are needed? Update releases are primarily for backports, so I'm dubious of anything that brings in a bunch of apparently new changes without making it clear why there are needed and why a backport is not appropriate. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Mon Jul 29 17:37:37 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 29 Jul 2019 19:37:37 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <493748f4-655c-c644-f789-ed7132934245@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> <493748f4-655c-c644-f789-ed7132934245@redhat.com> Message-ID: <77c82d6e0df86e54eeddb4922e1ffbbead9f3bcc.camel@redhat.com> On Mon, 2019-07-29 at 16:32 +0100, Andrew John Hughes wrote: > > On 29/07/2019 11:10, Severin Gehwolf wrote: > > On Mon, 2019-07-29 at 10:19 +0100, Andrew Dinn wrote: > > > On 26/07/2019 18:32, Andrew John Hughes wrote: > > > > On 26/07/2019 16:53, Severin Gehwolf wrote: > > [...] > > > > > > What exactly is being pushed > > > > > > here? > > > > > > > > > > The following 4 patches: > > > > > > > > > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > > > > hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > > > > > langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/langtools/webrev/ > > > > > top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > > > > > > > > > Each of them has a reference to a plain patch file if you prefer to > > > > > review that. > > > > > > > > > > Thanks, > > > > > Severin > > > > > > > > > > > > > Ok. HotSpot, JDK & top look fine, but there seem to be a lot of changes > > > > in langtools. Are these original changes to this patch or are they > > > > backports? Is there a reason langtools needs so much more work than the > > > > others? > > > The langtools Makefile changes appear to be larger because they required > > > adding a load of definitions/macros that are already present in the > > > Makefiles in the other trees (i.e. AWK, CAT etc, ZIP_UP_RESULTS, > > > BUNDLE_UP_AND_EXIT etc). These changes look ok to me. > > > > Yes, exactly. The langools Makefile looks *very* different from > > jdk/hotspot. In order to get some unified status of test results across > > all three, these changes were needed. I've opted to make the langools > > Makefile look more like the ones from jdk and hotspot. > > > > Old "make test" from top-level continues to work with these changes > > (modulo -verbose:nopass=> summary change). > > > > Anyway, I had another look at this and made 8075546[1] another pre- > > requisite which makes the langtools changes slightly smaller. Updated > > webrevs set, thus, is: > > > > jdk: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/04/jdk/webrev/ > > hotspot: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/03/hotspot/webrev/ > > langtools: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/05/langtools/webrev/ > > top: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8222737/02/top/webrev/ > > > > Thanks, > > Severin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8075546 > > > > Right. That doesn't answer the question as to the origin of the changes. > If I look at the langtools Makefile in OpenJDK 11, it doesn't have these > changes. Should they not go there first if they are needed? It looks like test/langtools/Makefile in JDK 11 is not used. At least make run-test-tier1 doesn't use it in JDK 11. I've just tried the following which works fine: $ rm test/langtools/Makefile $ hg status R test/langtools/Makefile $ make JAVAC_FLAGS=-g DISABLE_INTREE_EC=true LOG=debug run-test-tier1 Old make files have been removed with JDK-8217638 in JDK 13. To answer your question: I don't think these changes are needed for OpenJDK 11 as it has the "run-tests" facility (JDK-8176084) which deprecates the old way of running tests. Having said that, it seems more intrusive to try to get that facility ported to JDK 8u, than proceeding with the proposed change. JDK-8217638 suggests that old make files were kept for preserving some old workflows. Due to deprecation of "make test" from JDK 8 in JDK 9+, most of it is different from JDK 9+ onwards. For some time, both approaches seem to have kept working. I'm not sure in what way "make run-test" depends on the new build system in JDK 9. It may do. Briefly looking at the run-test patches it seems to open a can of worms. Incidentally, JDK-8170629, as one of the changes to the build/test infrastructure which happened in JDK 9 timeframe, seems to confirm that langtools is the "odd-man-out" in terms of make files and code duplication :) > Update releases are primarily for backports, so I'm dubious of anything > that brings in a bunch of apparently new changes without making it clear > why there are needed and why a backport is not appropriate. I realize that. There is a balance to strike, though. Backports-only vs. small enhancements. Considering that OpenJDK 8u will go on for some time to come it seems beneficial to have some way for developers of running a known-to-be-working set of tests. That's going to be the bar which every new contribution will have to pass. Current facility only runs jdk and langtools tests, does not print a summary, doesn't work well in CI environments, etc. The proposal preserves the old functionality, but also allows for a new "tier1" target. So, in light of the changed build system in JDK 9+, and the rather small changes in this patch (on the grand scheme of things), it seems reasonable to implement this feature in the way proposed. It's a JDK 8u *enhancement* after all. What would you propose as an alternative? Thanks, Severin From shade at redhat.com Mon Jul 29 18:30:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 29 Jul 2019 20:30:21 +0200 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <77c82d6e0df86e54eeddb4922e1ffbbead9f3bcc.camel@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> <493748f4-655c-c644-f789-ed7132934245@redhat.com> <77c82d6e0df86e54eeddb4922e1ffbbead9f3bcc.camel@redhat.com> Message-ID: <6edc291e-e7df-6caa-1955-6dfc8aa27e4b@redhat.com> On 7/29/19 7:37 PM, Severin Gehwolf wrote: > So, in light of the changed build system in JDK 9+, and the rather > small changes in this patch (on the grand scheme of things), it seems > reasonable to implement this feature in the way proposed. It's a JDK 8u > *enhancement* after all. I am with Severin here. The lack of acceptance test profile in 8u is severely impeding 8u backporting work. I personally keep Severin's patches applied at all times in my local patch queue, because that is the only way I can have 8u coverage more or less similar to what I do for 11u backports. Langtools build changes do not look bad, and they are pretty isolated from the rest of build system, which means we are not risking regressing important stuff. -- Thanks, -Aleksey From shade at redhat.com Mon Jul 29 18:33:23 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 29 Jul 2019 20:33:23 +0200 Subject: [8u] RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 In-Reply-To: References: Message-ID: On 7/29/19 3:49 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8213561 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8213561/jdk8/01/webrev/ > original-changeset: http://hg.openjdk.java.net/jdk/jdk/rev/12e8433e2581 Looks fine. -- Thanks, -Aleksey From adinn at redhat.com Tue Jul 30 08:48:00 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 30 Jul 2019 09:48:00 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: <6edc291e-e7df-6caa-1955-6dfc8aa27e4b@redhat.com> References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> <493748f4-655c-c644-f789-ed7132934245@redhat.com> <77c82d6e0df86e54eeddb4922e1ffbbead9f3bcc.camel@redhat.com> <6edc291e-e7df-6caa-1955-6dfc8aa27e4b@redhat.com> Message-ID: On 29/07/2019 19:30, Aleksey Shipilev wrote: > On 7/29/19 7:37 PM, Severin Gehwolf wrote: >> So, in light of the changed build system in JDK 9+, and the rather >> small changes in this patch (on the grand scheme of things), it seems >> reasonable to implement this feature in the way proposed. It's a JDK 8u >> *enhancement* after all. > > I am with Severin here. The lack of acceptance test profile in 8u is severely impeding 8u > backporting work. I personally keep Severin's patches applied at all times in my local patch queue, > because that is the only way I can have 8u coverage more or less similar to what I do for 11u backports. > > Langtools build changes do not look bad, and they are pretty isolated from the rest of build system, > which means we are not risking regressing important stuff. I agree that this is needed. I also understand why Andrew is loath to see changes that are not upstream. However, in this case I don't think we can avoid adding changes that cause a difference from upstream. The upstream test make system is implemented very differently, as Severin explained. He actually omitted mention of one important detail. >From jdk9 onwards it is organised in one tree rather than separate subtrees. IN consequence the code Severin is replicating in the jdk8u langtools/test make file does actually exist in upstream jdk11u but it is in a /shared/ file (test/make/TestCommon.gmk). For what loosk liek a very weird reason this shared file is not directly included in the langtools/test make file (langtools seems to expect the test process to pirate on the jdk test make process using a different path to the test files). Anyway, it is clear that this sharing (or, indeed, pirating on the jdk make process) is not an option in jdk8u because the make processes run in separate trees. So, replicating the shared code seems to be the only option. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From neugens at redhat.com Tue Jul 30 10:22:06 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Jul 2019 12:22:06 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources Message-ID: Hi all, I would like to backport the following bug into jdk8u-dev: https://bugs.openjdk.java.net/browse/JDK-8210863 The patch is trivial, apart from the usual path changes, I had to manually remove the internal Xrandr headers since the version do not match exactly: http://cr.openjdk.java.net/~neugens/JDK-8210863/webrev.00/ The original patch is here: http://hg.openjdk.java.net/jdk/jdk/rev/7d99b410be1b Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Tue Jul 30 11:40:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Jul 2019 13:40:36 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: Message-ID: On 7/30/19 12:22 PM, Mario Torre wrote: > I would like to backport the following bug into jdk8u-dev: > https://bugs.openjdk.java.net/browse/JDK-8210863 I believe we also need to backport the configure check as well then: https://bugs.openjdk.java.net/browse/JDK-8213944 -- Thanks, -Aleksey From neugens at redhat.com Tue Jul 30 11:50:05 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Jul 2019 13:50:05 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: Message-ID: Make sense, I didn't realise this was needed as this seems specific to AIX. I'll send the patch shortly. Cheers, Mario On Tue, Jul 30, 2019 at 1:40 PM Aleksey Shipilev wrote: > > On 7/30/19 12:22 PM, Mario Torre wrote: > > I would like to backport the following bug into jdk8u-dev: > > https://bugs.openjdk.java.net/browse/JDK-8210863 > > I believe we also need to backport the configure check as well then: > https://bugs.openjdk.java.net/browse/JDK-8213944 > > -- > Thanks, > -Aleksey -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Tue Jul 30 13:02:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Jul 2019 14:02:26 +0100 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: Message-ID: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> On 30/07/2019 11:22, Mario Torre wrote: > Hi all, > > I would like to backport the following bug into jdk8u-dev: > > https://bugs.openjdk.java.net/browse/JDK-8210863 > > The patch is trivial, apart from the usual path changes, I had to > manually remove the internal Xrandr headers since the version do not > match exactly: > > http://cr.openjdk.java.net/~neugens/JDK-8210863/webrev.00/ > > The original patch is here: > > http://hg.openjdk.java.net/jdk/jdk/rev/7d99b410be1b > > Cheers, > Mario > What is the motivation for this? JDK-8213944 would seem to be evidence that the removal risks breakage and OpenJDK 8u is an older JDK which may still need to be built on systems without Xrandr. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Jul 30 13:25:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Jul 2019 14:25:36 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> <493748f4-655c-c644-f789-ed7132934245@redhat.com> <77c82d6e0df86e54eeddb4922e1ffbbead9f3bcc.camel@redhat.com> <6edc291e-e7df-6caa-1955-6dfc8aa27e4b@redhat.com> Message-ID: On 30/07/2019 09:48, Andrew Dinn wrote: > On 29/07/2019 19:30, Aleksey Shipilev wrote: >> On 7/29/19 7:37 PM, Severin Gehwolf wrote: >>> So, in light of the changed build system in JDK 9+, and the rather >>> small changes in this patch (on the grand scheme of things), it seems >>> reasonable to implement this feature in the way proposed. It's a JDK 8u >>> *enhancement* after all. >> >> I am with Severin here. The lack of acceptance test profile in 8u is severely impeding 8u >> backporting work. I personally keep Severin's patches applied at all times in my local patch queue, >> because that is the only way I can have 8u coverage more or less similar to what I do for 11u backports. >> >> Langtools build changes do not look bad, and they are pretty isolated from the rest of build system, >> which means we are not risking regressing important stuff. > I agree that this is needed. I also understand why Andrew is loath to > see changes that are not upstream. However, in this case I don't think > we can avoid adding changes that cause a difference from upstream. > I wouldn't say it's as extreme as loathing, but, if a big chunk of code is being added, I just would like to know its origins, and, if they are indeed new in this patch, give them the more through examination needed. If I appear overly critical, put it down to a decade of doing such backports and having had to work out where such forks in the codebase come from, often on very tight deadlines. I'm trying to minimise potential later angst at the expense of a little more perspiration now. > The upstream test make system is implemented very differently, as > Severin explained. He actually omitted mention of one important detail. > From jdk9 onwards it is organised in one tree rather than separate > subtrees. IN consequence the code Severin is replicating in the jdk8u > langtools/test make file does actually exist in upstream jdk11u but it > is in a /shared/ file (test/make/TestCommon.gmk). For what loosk liek a > very weird reason this shared file is not directly included in the > langtools/test make file (langtools seems to expect the test process to > pirate on the jdk test make process using a different path to the test > files). Anyway, it is clear that this sharing (or, indeed, pirating on > the jdk make process) is not an option in jdk8u because the make > processes run in separate trees. So, replicating the shared code seems > to be the only option. And, thanks, this is the answer I've been searching for. The langtools additions do seem to have been copied from the other versions, which, in turn, were moved to a shared location in 9 by JDK-8170629 [0] [1] [2] [3] [4]. That makes sense and I'm fine with that. For future reference, a lot of this back-and-forth could probably have been avoided if the process to arrive at such changes had been explained from the start. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > [0] https://hg.openjdk.java.net/jdk/jdk/rev/26156e756dfa [1] https://hg.openjdk.java.net/jdk/jdk/rev/8dcc83c2d40e [2] https://hg.openjdk.java.net/jdk/jdk/rev/ccef74161219 [3] https://hg.openjdk.java.net/jdk/jdk/rev/2435ff181f94 [4] https://hg.openjdk.java.net/jdk/jdk/rev/2ac2a6ef14a6 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From adinn at redhat.com Tue Jul 30 13:45:04 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 30 Jul 2019 14:45:04 +0100 Subject: [8u] [PING?] RFR: 8222737: [TESTBUG] Allow for tier 1 like testing in OpenJDK 8u In-Reply-To: References: <674649a52fc8b31b809ced34489e96cae99f4dec.camel@redhat.com> <2d40f02648cfd46b785e5a9a01ca0c583a816415.camel@redhat.com> <9aa8cd6a-8209-ecd0-5166-9ee50b671dbb@redhat.com> <9654d1ce-e786-e8f5-0e89-2ac25511fc60@redhat.com> <8b76e3ce-0ec0-1a8a-7ec4-5e9741d08906@redhat.com> <493748f4-655c-c644-f789-ed7132934245@redhat.com> <77c82d6e0df86e54eeddb4922e1ffbbead9f3bcc.camel@redhat.com> <6edc291e-e7df-6caa-1955-6dfc8aa27e4b@redhat.com> Message-ID: <9756241c-e58c-4df2-7599-609840760583@redhat.com> On 30/07/2019 14:25, Andrew John Hughes wrote: > On 30/07/2019 09:48, Andrew Dinn wrote: >> I agree that this is needed. I also understand why Andrew is loath to >> see changes that are not upstream. However, in this case I don't think >> we can avoid adding changes that cause a difference from upstream. > > I wouldn't say it's as extreme as loathing, but, if a big chunk of code > is being added, I just would like to know its origins, and, if they are > indeed new in this patch, give them the more through examination needed. I am sure it's not that extreme! Loath != loathe. It means reluctant or unwilling ;-). Apologies for the confusion. A-and ... I fully understand why you /are/ unwilling. It' is entirely the correct default. > If I appear overly critical, put it down to a decade of doing such > backports and having had to work out where such forks in the codebase > come from, often on very tight deadlines. I'm trying to minimise > potential later angst at the expense of a little more perspiration now. Oh, I don't think you are over-critical or even over-cautious. Over-experienced at having to unravel other people's conflations of different concerns is definitely nearer the truth. >> The upstream test make system is implemented very differently, as >> Severin explained. He actually omitted mention of one important detail. >> From jdk9 onwards it is organised in one tree rather than separate >> subtrees. IN consequence the code Severin is replicating in the jdk8u >> langtools/test make file does actually exist in upstream jdk11u but it >> is in a /shared/ file (test/make/TestCommon.gmk). For what loosk liek a >> very weird reason this shared file is not directly included in the >> langtools/test make file (langtools seems to expect the test process to >> pirate on the jdk test make process using a different path to the test >> files). Anyway, it is clear that this sharing (or, indeed, pirating on >> the jdk make process) is not an option in jdk8u because the make >> processes run in separate trees. So, replicating the shared code seems >> to be the only option. > > And, thanks, this is the answer I've been searching for. The langtools > additions do seem to have been copied from the other versions, which, in > turn, were moved to a shared location in 9 by JDK-8170629 [0] [1] [2] > [3] [4]. That makes sense and I'm fine with that. Ok, good. I'm glad to know I can shed some light on the matter as well as shade ... err, I mean as well as make things more obscure ... ;-) > For future reference, a lot of this back-and-forth could probably have > been avoided if the process to arrive at such changes had been explained > from the start. Sure, although archaeology is by nature a somewhat grubby and confusing science, especially while people are still digging. Anyway, we finally arrived at a proper account which, I think, is all we need to allow this change to be pushed. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From zgu at redhat.com Tue Jul 30 14:50:55 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 30 Jul 2019 10:50:55 -0400 Subject: [8u] RFR 8217785: Padding ParallelTaskTerminator::_offered_termination variable Message-ID: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> I would like backport the patch to JDK8u. This minor fix improves termination latency for multiple GC threads. The patch does not apply cleanly to 8u, mainly due to missing macro DEFINE_PAD_MINUS_SIZE, (which introduced by DK-8049737) and different data type for _offered_termination variable. Original bug: https://bugs.openjdk.java.net/browse/JDK-8217785 Original webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785/webrev.00/ 8u backport: Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.00/ Thanks, -Zhengyu From shade at redhat.com Tue Jul 30 14:52:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Jul 2019 16:52:39 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> References: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> Message-ID: <45afd1d4-c340-f6d3-7537-7dfecff6fd51@redhat.com> On 7/30/19 3:02 PM, Andrew John Hughes wrote: > What is the motivation for this? JDK-8213944 would seem to be evidence > that the removal risks breakage and OpenJDK 8u is an older JDK which may > still need to be built on systems without Xrandr. Do we know such the system? Given this is already done in 11u, this would mean such a system could not build 11u already, and so would require updates. Also, the issue itself has "8-bp" label, which suggests Oracle would consider it for backports too. We can, of course, wait for that to happen. -Aleksey From neugens at redhat.com Tue Jul 30 14:55:38 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Jul 2019 16:55:38 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> References: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> Message-ID: On Tue, Jul 30, 2019 at 3:02 PM Andrew John Hughes wrote: > > > > On 30/07/2019 11:22, Mario Torre wrote: > > Hi all, > > > > I would like to backport the following bug into jdk8u-dev: > > > > https://bugs.openjdk.java.net/browse/JDK-8210863 > > > > The patch is trivial, apart from the usual path changes, I had to > > manually remove the internal Xrandr headers since the version do not > > match exactly: > > > > http://cr.openjdk.java.net/~neugens/JDK-8210863/webrev.00/ > > > > The original patch is here: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/7d99b410be1b > > > > Cheers, > > Mario > > > > What is the motivation for this? JDK-8213944 would seem to be evidence > that the removal risks breakage and OpenJDK 8u is an older JDK which may > still need to be built on systems without Xrandr. If an older distribution doesn't support xrandr (which I doubt since this extensions is quite old) then it would not work anyway, as there's no implementation in this patch, just the header files. I think such cases would be covered by JDK-8213944 more appropriately, rather than fallback at runtime. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From shade at redhat.com Tue Jul 30 14:58:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Jul 2019 16:58:22 +0200 Subject: [8u] RFR 8217785: Padding ParallelTaskTerminator::_offered_termination variable In-Reply-To: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> References: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> Message-ID: <5ae9d536-b65f-7152-139e-f94cc8d682ca@redhat.com> On 7/30/19 4:50 PM, Zhengyu Gu wrote: > 8u backport: > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.00/ I believe most of 8u code uses just this: char _pad_before[DEFAULT_CACHE_LINE_SIZE] ... char _pad_after[DEFAULT_CACHE_LINE_SIZE] Therefore, I see no need in doing new defines, which also have potential to leak into global symbols, especially from the frequently used header like taskqueue.hpp. The change becomes three-liner then. You need to do #include "utilities/globalDefinitions.hpp" and two new field definitions. -- Thanks, -Aleksey From neugens at redhat.com Tue Jul 30 14:59:40 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 30 Jul 2019 16:59:40 +0200 Subject: RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources In-Reply-To: References: <53aa9481-9134-700b-22cd-6526725015af@redhat.com> Message-ID: On Tue, Jul 30, 2019 at 4:55 PM Mario Torre wrote: > > On Tue, Jul 30, 2019 at 3:02 PM Andrew John Hughes > wrote: > > > > > > > > On 30/07/2019 11:22, Mario Torre wrote: > > > Hi all, > > > > > > I would like to backport the following bug into jdk8u-dev: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8210863 > > > > > > The patch is trivial, apart from the usual path changes, I had to > > > manually remove the internal Xrandr headers since the version do not > > > match exactly: > > > > > > http://cr.openjdk.java.net/~neugens/JDK-8210863/webrev.00/ > > > > > > The original patch is here: > > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/7d99b410be1b > > > > > > Cheers, > > > Mario > > > > > > > What is the motivation for this? JDK-8213944 would seem to be evidence > > that the removal risks breakage and OpenJDK 8u is an older JDK which may > > still need to be built on systems without Xrandr. > > If an older distribution doesn't support xrandr (which I doubt since > this extensions is quite old) then it would not work anyway, as > there's no implementation in this patch, just the header files. > > I think such cases would be covered by JDK-8213944 more appropriately, > rather than fallback at runtime. I didn't answer your question. I don't mind not pushing this patch or holding it, the only reason why I did the backport is that is for consistency with the Oracle JDK and because it has the redhat-interest label, if the patch isn't necessary I suggest to remove the label. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From stooke at redhat.com Tue Jul 30 16:18:59 2019 From: stooke at redhat.com (Simon Tooke) Date: Tue, 30 Jul 2019 12:18:59 -0400 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS Message-ID: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> Hello all, I would like to backport the following bug into jdk8u-dev: The patch is trivial, apart from the usual path changes. I omitted one file change that was only a line ending difference, and fixed the copyright dates. bug: https://bugs.openjdk.java.net/browse/JDK-8215756 jdk8u patch:? http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u/ Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 Thanks for your time, -Simon --- Simon Tooke Principle Software Engineer, Red Hat Canada?? From shade at redhat.com Tue Jul 30 16:29:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Jul 2019 18:29:36 +0200 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> Message-ID: <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> On 7/30/19 6:18 PM, Simon Tooke wrote: > The patch is trivial, apart from the usual path changes. > I omitted one file change that was only a line ending difference, and fixed the copyright dates. Why omit it? > bug: https://bugs.openjdk.java.net/browse/JDK-8215756 > > jdk8u patch:? http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u/ > Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 Backport looks good, modulo newline omission. Again, if the patch applies cleanly, you don't need RFC/RFR, just do jdk8u-fix-request and "Fix Request" comments. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Jul 30 17:01:33 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Jul 2019 18:01:33 +0100 Subject: [RFR 8u] 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider In-Reply-To: <2e63e365-fbf5-d783-a4aa-b25d76aa283d@redhat.com> References: <6b0eb467-5ff4-2d4a-f5ee-4fe2ddebfd69@redhat.com> <2e63e365-fbf5-d783-a4aa-b25d76aa283d@redhat.com> Message-ID: On 26/07/2019 16:17, Martin Balao wrote: > Hi Aleksey, > > On 7/26/19 4:58 AM, Aleksey Shipilev wrote: >> >>> JDK patch applies cleanly, except for P11Key.java part (which requires >>> some reordering) and paths. >> >> I assume this means no actual code changes, and just changing the order (of what? methods?) >> somewhere. I cannot spot the difference against upstream change, though. >> > > Actually, this should have applied cleanly... hmm. Anyways, thanks! > > Martin.- > FWIW, it didn't because of: @@ -237,6 +237,7 @@ - refList.add(this); + refSet.add(this); + // TBD: run at some interval and not every time? drainRefQueueBounded(); } as 8u does not have 8098580: drainRefQueueBounds() puts pressure on pool.size() Anyway, pushed now. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Jul 30 17:11:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 30 Jul 2019 18:11:13 +0100 Subject: [8u] RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 In-Reply-To: References: Message-ID: <96dc74a1-15a8-835b-643f-59cd9623aa8b@redhat.com> On 29/07/2019 14:49, Severin Gehwolf wrote: > * no @key randomness in JDK 8u => dropped in JDK 8 patch What gives you this idea? https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3949b2469facdc6b4 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Tue Jul 30 17:17:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 30 Jul 2019 19:17:08 +0200 Subject: [8u] RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 In-Reply-To: <96dc74a1-15a8-835b-643f-59cd9623aa8b@redhat.com> References: <96dc74a1-15a8-835b-643f-59cd9623aa8b@redhat.com> Message-ID: <8884fd82-3104-3c2c-873d-77022b2ab1cd@redhat.com> On 7/30/19 7:11 PM, Andrew John Hughes wrote: > On 29/07/2019 14:49, Severin Gehwolf wrote: >> * no @key randomness in JDK 8u => dropped in JDK 8 patch > > What gives you this idea? > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3949b2469facdc6b4 Andrew is technically correct, but I think this bit is irrelevant for this backport, as original change removes that @key as well (and for reason, it is not using Random anymore): http://hg.openjdk.java.net/jdk/jdk/rev/12e8433e2581#l1.14 -Aleksey From sgehwolf at redhat.com Tue Jul 30 17:22:56 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 30 Jul 2019 19:22:56 +0200 Subject: [8u] RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1 In-Reply-To: <8884fd82-3104-3c2c-873d-77022b2ab1cd@redhat.com> References: <96dc74a1-15a8-835b-643f-59cd9623aa8b@redhat.com> <8884fd82-3104-3c2c-873d-77022b2ab1cd@redhat.com> Message-ID: <6b004d173cf30168de7055d0a5224229fbf7fe57.camel@redhat.com> On Tue, 2019-07-30 at 19:17 +0200, Aleksey Shipilev wrote: > On 7/30/19 7:11 PM, Andrew John Hughes wrote: > > On 29/07/2019 14:49, Severin Gehwolf wrote: > > > * no @key randomness in JDK 8u => dropped in JDK 8 patch > > > > What gives you this idea? > > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/3949b2469facdc6b4 > > Andrew is technically correct, but I think this bit is irrelevant for this backport, as original > change removes that @key as well (and for reason, it is not using Random anymore): > http://hg.openjdk.java.net/jdk/jdk/rev/12e8433e2581#l1.14 Right. Sorry for stating this wrongly. It didn't apply because @randomness was never been added to the JDK 8 version of the test. Thanks, Severin From stooke at redhat.com Tue Jul 30 19:39:46 2019 From: stooke at redhat.com (Simon Tooke) Date: Tue, 30 Jul 2019 15:39:46 -0400 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> Message-ID: On 7/30/2019 12:29 PM, Aleksey Shipilev wrote: > On 7/30/19 6:18 PM, Simon Tooke wrote: >> The patch is trivial, apart from the usual path changes. >> I omitted one file change that was only a line ending difference, and fixed the copyright dates. > Why omit it? Because it's not in my usual workflow (translation: lazy) to verify newline correctness in incoming patches.? It probably should be. I can add that file patch back, but, for example, one of the other file patches doesn't apply cleanly (after fixing paths), and it's due to chunks that only update newlines (in code that's not there in JDK8). I'm happy to add back the one newline fix, but since the patch needed modification anyways, I limited the original scope.? Just let me know a preference. -s > >> bug: https://bugs.openjdk.java.net/browse/JDK-8215756 >> >> jdk8u patch:? http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u/ >> Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 > Backport looks good, modulo newline omission. > > Again, if the patch applies cleanly, you don't need RFC/RFR, just do jdk8u-fix-request and "Fix > Request" comments. > From zgu at redhat.com Tue Jul 30 23:01:34 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 30 Jul 2019 19:01:34 -0400 Subject: [8u] RFR 8217785: Padding ParallelTaskTerminator::_offered_termination variable In-Reply-To: <5ae9d536-b65f-7152-139e-f94cc8d682ca@redhat.com> References: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> <5ae9d536-b65f-7152-139e-f94cc8d682ca@redhat.com> Message-ID: <65f82d86-9713-bf40-defb-7c67a45c5c7e@redhat.com> Hi Aleksey, Thanks for reviewing. Webrev is updated according to your comments. Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.01/index.html Thanks, -Zhengyu On 7/30/19 10:58 AM, Aleksey Shipilev wrote: > On 7/30/19 4:50 PM, Zhengyu Gu wrote: >> 8u backport: >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.00/ > > I believe most of 8u code uses just this: > > char _pad_before[DEFAULT_CACHE_LINE_SIZE] > ... > char _pad_after[DEFAULT_CACHE_LINE_SIZE] > > Therefore, I see no need in doing new defines, which also have potential to leak into global > symbols, especially from the frequently used header like taskqueue.hpp. The change becomes > three-liner then. You need to do #include "utilities/globalDefinitions.hpp" and two new field > definitions. > From shade at redhat.com Wed Jul 31 06:40:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 08:40:01 +0200 Subject: [8u] RFR 8217785: Padding ParallelTaskTerminator::_offered_termination variable In-Reply-To: <65f82d86-9713-bf40-defb-7c67a45c5c7e@redhat.com> References: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> <5ae9d536-b65f-7152-139e-f94cc8d682ca@redhat.com> <65f82d86-9713-bf40-defb-7c67a45c5c7e@redhat.com> Message-ID: <3debc415-76d0-6c15-92ae-7ff26f7aeddd@redhat.com> On 7/31/19 1:01 AM, Zhengyu Gu wrote: > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.01/index.html Looks better. Original change does not change the volatility of the field, the backport should also leave it alone. Drop the "volatile" qualifier. -- Thanks, -Aleksey From shade at redhat.com Wed Jul 31 09:02:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 11:02:39 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> Message-ID: <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> On 7/16/19 9:25 AM, Andrew John Hughes wrote: > On 15/07/2019 09:27, Aleksey Shipilev wrote: >> On 7/2/19 9:53 PM, Aleksey Shipilev wrote: >>> Original RFE: >>> https://bugs.openjdk.java.net/browse/JDK-8214687 >>> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 >>> >>> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: >>> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: >>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ > > Objects.checkIndex is simply a wrapper around Preconditions.checkIndex: > > public static > int checkIndex(int index, int length) { > return Preconditions.checkIndex(index, length, null); > } > > which is in 8u. Probably worth adding the 2-argument version to > Preconditions. Getting back to this. Since we have moved Preconditions to private location in 8u, using it is impossible for this patch. So, I would keep the webrev as is: https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 It is approved for 8u and 11u push, so if there are no other comments, I would push the fix shortly. -- Thanks, -Aleksey From OGATAK at jp.ibm.com Wed Jul 31 09:30:55 2019 From: OGATAK at jp.ibm.com (Kazunori Ogata) Date: Wed, 31 Jul 2019 18:30:55 +0900 Subject: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: Support AES intrinsics on Big Endian In-Reply-To: References: Message-ID: Ping. May I get review for the almost clean backport? Regards, Ogata Kazunori Ogata/Japan/IBM wrote on 2019/07/24 17:48:23: > From: Kazunori Ogata/Japan/IBM > To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net > Date: 2019/07/24 17:48 > Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: > Support AES intrinsics on Big Endian > > Hi, > > May I get review for backport of 8188868: PPC64: Support AES intrinsics on > Big Endian? > > The original patch itself can be applied cleanly (besides difference of > the source directory structure). However, one chunk failed because the > code just after the patched code was modified, so I manually applied the > chunk and renewed the patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188868 > Webrev: http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8188868/webrev.02/ > > This backport is low risk and affects only PPC64 only. I verified there > was no degradation in "make test" results and SPECjbb 2015 ran fine. The > intrinsics added in this changeset improved max jOPS by 5% and critical jOPS by 4%. > > Regards, > Ogata From chengjingwei1 at huawei.com Wed Jul 31 09:43:53 2019 From: chengjingwei1 at huawei.com (chengjingwei) Date: Wed, 31 Jul 2019 17:43:53 +0800 Subject: [8u] Request for backporting some issues affecting hotspot-compiler Message-ID: <8aae0a4b-a1f9-ed8b-bb42-c3dc868c5ca1@huawei.com> Hi, all Would someone help to approve the backport of the following issues? - Issue list: JDK-8202952 JDK-8134883 - Details: JDK-8202952: Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8202952 Patch is clean:[Yes] JDK13 Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/80b55cf3a804 JDK-8134883 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8134883 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/338c42ecdaf1 These issues are decreasing the stability of our applications. They are always reproducible with jdk built from the latest jdk8u master repo. From chengjingwei1 at huawei.com Wed Jul 31 09:46:14 2019 From: chengjingwei1 at huawei.com (chengjingwei) Date: Wed, 31 Jul 2019 17:46:14 +0800 Subject: [8u] Request for backporting a series of issues affecting core-libs Message-ID: Hi, all Would someone help to approve the backport of the following issues? - Issue list: JDK-8151788 JDK-8026049 JDK-8149469 JDK-8149469 - Details: JDK-8151788 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8151788 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3b503af253a4 JDK-8026049 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8026049 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/662f01f35702 JDK-8151163 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8151163 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f9dcefa42da3 JDK-8149469 Reproduced on 8u:[Yes] Bug: https://bugs.openjdk.java.net/browse/JDK-8149469 Patch is clean:[Yes] JDK9 Changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/5e0fd2cdcd55 These issues are decreasing the stability of our applications. They are always reproducible with jdk built from the latest jdk8u master repo. From chengjingwei1 at huawei.com Wed Jul 31 09:47:46 2019 From: chengjingwei1 at huawei.com (chengjingwei) Date: Wed, 31 Jul 2019 17:47:46 +0800 Subject: [8u] Request for backporting JDK-8131600 Message-ID: Hi, all Would someone help to approve the backport of JDK-8131600 to 8u? Bug: https://bugs.openjdk.java.net/browse/JDK-8131600 Here is the discussion on this issue: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-July/014176.html This issue decreases the stability of our applications. It's always reproducible with jdk built from the latest jdk8u master repo. From shade at redhat.com Wed Jul 31 09:58:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 11:58:55 +0200 Subject: [8u] Request for backporting some issues affecting hotspot-compiler In-Reply-To: <8aae0a4b-a1f9-ed8b-bb42-c3dc868c5ca1@huawei.com> References: <8aae0a4b-a1f9-ed8b-bb42-c3dc868c5ca1@huawei.com> Message-ID: <80cbc814-f51b-b4f0-65c7-508f78003acf@redhat.com> On 7/31/19 11:43 AM, chengjingwei wrote: > Would someone help to approve the backport of the following issues? You have to follow the process outlined here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix At very least, do not lump multiple issues together, and do not use generic topic like "backporting some issues". The mail archives should be searchable by bug ID. Please start over. -- Thanks, -Aleksey From shade at redhat.com Wed Jul 31 10:00:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 12:00:59 +0200 Subject: [8u] Request for backporting a series of issues affecting core-libs In-Reply-To: References: Message-ID: On 7/31/19 11:46 AM, chengjingwei wrote: > Would someone help to approve the backport of the following issues? Same here. You have to follow the process outlined here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix At very least, do not lump multiple issues together, and do not use generic topic like "backporting some issues". The mail archives should be searchable by bug ID. Please start over. -- Thanks, -Aleksey From shade at redhat.com Wed Jul 31 10:01:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 12:01:40 +0200 Subject: [8u] Request for backporting JDK-8131600 In-Reply-To: References: Message-ID: On 7/31/19 11:47 AM, chengjingwei wrote: > Would someone help to approve the backport of JDK-8131600 to 8u? Same here. Please follow the process outlined here: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix -- Thanks, -Aleksey From chengjingwei1 at huawei.com Wed Jul 31 10:38:44 2019 From: chengjingwei1 at huawei.com (chengjingwei) Date: Wed, 31 Jul 2019 18:38:44 +0800 Subject: [8u] Request for backporting some issues affecting hotspot-compiler In-Reply-To: <80cbc814-f51b-b4f0-65c7-508f78003acf@redhat.com> References: <8aae0a4b-a1f9-ed8b-bb42-c3dc868c5ca1@huawei.com> <80cbc814-f51b-b4f0-65c7-508f78003acf@redhat.com> Message-ID: <0a0888f8-8aae-5c30-a8ff-9556bfffaa66@huawei.com> Thanks for the reminding, I'll check the guidance and do it from start over. On 2019/7/31 17:58, Aleksey Shipilev wrote: > On 7/31/19 11:43 AM, chengjingwei wrote: >> Would someone help to approve the backport of the following issues? > You have to follow the process outlined here: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > At very least, do not lump multiple issues together, and do not use generic topic like "backporting > some issues". The mail archives should be searchable by bug ID. Please start over. > From zgu at redhat.com Wed Jul 31 11:16:52 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 31 Jul 2019 07:16:52 -0400 Subject: [8u] RFR 8217785: Padding ParallelTaskTerminator::_offered_termination variable In-Reply-To: <3debc415-76d0-6c15-92ae-7ff26f7aeddd@redhat.com> References: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> <5ae9d536-b65f-7152-139e-f94cc8d682ca@redhat.com> <65f82d86-9713-bf40-defb-7c67a45c5c7e@redhat.com> <3debc415-76d0-6c15-92ae-7ff26f7aeddd@redhat.com> Message-ID: <3d8d5278-d9d2-f0db-4cea-52b21e78d904@redhat.com> On 7/31/19 2:40 AM, Aleksey Shipilev wrote: > On 7/31/19 1:01 AM, Zhengyu Gu wrote: >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.01/index.html > > Looks better. Original change does not change the volatility of the field, the backport should also > leave it alone. Drop the "volatile" qualifier. Right. Updated: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.02/index.html Thanks, -Zhengyu > From shade at redhat.com Wed Jul 31 11:21:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 13:21:10 +0200 Subject: [8u] RFR 8217785: Padding ParallelTaskTerminator::_offered_termination variable In-Reply-To: <3d8d5278-d9d2-f0db-4cea-52b21e78d904@redhat.com> References: <30fc5e62-6b3f-d1dd-b6cc-6fb68c2a3bbf@redhat.com> <5ae9d536-b65f-7152-139e-f94cc8d682ca@redhat.com> <65f82d86-9713-bf40-defb-7c67a45c5c7e@redhat.com> <3debc415-76d0-6c15-92ae-7ff26f7aeddd@redhat.com> <3d8d5278-d9d2-f0db-4cea-52b21e78d904@redhat.com> Message-ID: On 7/31/19 1:16 PM, Zhengyu Gu wrote: > On 7/31/19 2:40 AM, Aleksey Shipilev wrote: > Updated: http://cr.openjdk.java.net/~zgu/JDK-8217785-8u/webrev.02/index.html Looks good. -- Thanks, -Aleksey From shade at redhat.com Wed Jul 31 12:54:59 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 14:54:59 +0200 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: <139d1e126a3f42d187da3c80703b4ecf@azul.com> References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> Message-ID: On 7/16/19 7:42 PM, Fedor Burdun wrote: > The issue described in bugs 8031126/8030631 is still reproducible on java8. > May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? This makes sense. Is there anyone from Azul to assist you with following this checklist? https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix Thanks, -Aleksey From gnu.andrew at redhat.com Wed Jul 31 14:53:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 31 Jul 2019 15:53:48 +0100 Subject: OpenJDK 8u232-b01 EA Released Message-ID: <172894fb-f8fc-7e72-4540-a107ad2c6afe@redhat.com> I've made available an early access source bundle for 8u232, based on the tag jdk8u232-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b01-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b01-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 6da0f0ec15fd69fc8742a0b1e94a19f4b506ab883ebe6599ab084cce4efc7cdc openjdk8u232-b01-ea.tar.xz 110801fb58638c63fc09a75758f8ab5e0b94266b340e41f37643aefc9386b167 openjdk8u232-b01-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u232-b01-ea.sha256 Changes in 8u232-b01: - S6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space - S6946830: javax.crypto.Cipher.doFinal behavior differs depending on platform - S6996807: FieldReflectorKey hash code computation can be improved - S8030993: Check jdk/src/share/native/common/jni_util.c for JNI pending exceptions - S8075136: Unnecessary sign extension for byte array access - S8075544: Add tiered testing definitions to the jdk repo - S8075573: Add jdk_other and jdk_svc to jdk tier 2 test definition - S8151486: Class.forName causes memory leak - S8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X - S8168417: Pending exceptions in java.base/windows/native/libnio - S8170494: JNI exception pending in PlainDatagramSocketImpl.c - S8185900: hotspot build failed with gcc version Red Hat 4.4.7-3 - S8185979: PPC64: Implement SHA2 intrinsic - S8197930: JNI exception pending in initializeEncoding of jni_util.c - S8202353: os::readdir should use readdir instead of readdir_r - S8205587: Implicit function declaration in jni_util.c - S8210761: libjsig is being compiled without optimization - S8214002: Cannot use italic font style if the font has embedded bitmap - S8218721: C1's CEE optimization produces safepoint poll with invalid debug information - S8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth - S8219807: C2 crash in IfNode::up_one_dom(Node*, bool) - S8221304: Problem list java/awt/FontMetrics/MaxAdvanceIsMax.java - S8223219: Backport of JDK-8199552 to OpenJDK 8 leads to duplicate -fstack-protector flags, overriding --with-extra-cflags - S8225636: SA can't handle prelinked libraries - S8226392: Launcher should not enable legacy stdio streams on GNU/Linux (glibc) - S8226870: OpenJDK 8u JRE contains clhsdb and hsdb launchers - S8226928: [TESTBUG] test/java/net/NetworkInterface/IPv4Only.java fails intermittently on AIX - S8227018: CompletableFuture should not call Runtime.availableProcessors on fast path - S8228405: Incorrect format strings in PhaseIdealLoop::rc_predicate -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From andrey at azul.com Wed Jul 31 15:23:29 2019 From: andrey at azul.com (Andrey Petushkov) Date: Wed, 31 Jul 2019 15:23:29 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> Message-ID: <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> Hi Aleksey, I'll do Thanks, Andrey > On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: > > On 7/16/19 7:42 PM, Fedor Burdun wrote: >> The issue described in bugs 8031126/8030631 is still reproducible on java8. >> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? > > This makes sense. Is there anyone from Azul to assist you with following this checklist? > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > Thanks, > -Aleksey From gnu.andrew at redhat.com Wed Jul 31 15:56:59 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 31 Jul 2019 16:56:59 +0100 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> Message-ID: On 31/07/2019 10:02, Aleksey Shipilev wrote: > On 7/16/19 9:25 AM, Andrew John Hughes wrote: >> On 15/07/2019 09:27, Aleksey Shipilev wrote: >>> On 7/2/19 9:53 PM, Aleksey Shipilev wrote: >>>> Original RFE: >>>> https://bugs.openjdk.java.net/browse/JDK-8214687 >>>> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 >>>> >>>> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: >>>> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: >>>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ >> >> Objects.checkIndex is simply a wrapper around Preconditions.checkIndex: >> >> public static >> int checkIndex(int index, int length) { >> return Preconditions.checkIndex(index, length, null); >> } >> >> which is in 8u. Probably worth adding the 2-argument version to >> Preconditions. > > Getting back to this. Since we have moved Preconditions to private location in 8u, using it is > impossible for this patch. So, I would keep the webrev as is: > https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 We haven't moved anything as yet and my proposed patch leaves the class as public, so shouldn't be a blocker. The test in that patch uses Preconditions. > > It is approved for 8u and 11u push, so if there are no other comments, I would push the fix shortly. > Please don't "timeout" patches. Someone not seeing an e-mail is not the same as an ok. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Jul 31 15:59:12 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 17:59:12 +0200 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> Message-ID: On 7/30/19 9:39 PM, Simon Tooke wrote: > On 7/30/2019 12:29 PM, Aleksey Shipilev wrote: >> On 7/30/19 6:18 PM, Simon Tooke wrote: >>> The patch is trivial, apart from the usual path changes. >>> I omitted one file change that was only a line ending difference, and fixed the copyright dates. >> Why omit it? > > Because it's not in my usual workflow (translation: lazy) to verify > newline correctness in incoming patches.? It probably should be. > > I can add that file patch back, but, for example, one of the other file > patches doesn't apply cleanly (after fixing paths), and it's due to > chunks that only update newlines (in code that's not there in JDK8). If the upstream patch updates newlines, backport should follow. If hunk is not applicable because there is no code to update in 8u, hunk can be ignored. > I'm happy to add back the one newline fix, but since the patch needed > modification anyways, I limited the original scope.? Just let me know a > preference. I prefer backported patches to be as close to upstream patches as possible, including whitespace differences. This is mostly to cater for the follow-up patches to the same location that expect the shape of file to the same. There are some exceptions to this rule, but whitespace diffs is usually not the exceptional case. -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed Jul 31 16:05:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 31 Jul 2019 17:05:48 +0100 Subject: [Ping] Re: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: PPC64: Support AES intrinsics on Big Endian In-Reply-To: References: Message-ID: <2d8d8d35-c781-cc0c-2673-c8f7eea057bd@redhat.com> On 31/07/2019 10:30, Kazunori Ogata wrote: > Ping. > > May I get review for the almost clean backport? > > Regards, > Ogata > > Kazunori Ogata/Japan/IBM wrote on 2019/07/24 17:48:23: > >> From: Kazunori Ogata/Japan/IBM >> To: hotspot-compiler-dev at openjdk.java.net, jdk8u-dev at openjdk.java.net >> Date: 2019/07/24 17:48 >> Subject: [8u-dev, ppc] RFR for (almost clean) backport of 8188868: > PPC64: >> Support AES intrinsics on Big Endian >> >> Hi, >> >> May I get review for backport of 8188868: PPC64: Support AES intrinsics > on >> Big Endian? >> >> The original patch itself can be applied cleanly (besides difference of >> the source directory structure). However, one chunk failed because the >> code just after the patched code was modified, so I manually applied the > >> chunk and renewed the patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188868 >> Webrev: > http://cr.openjdk.java.net/~ogatak/jdk8u_aes_be/8188868/webrev.02/ >> >> This backport is low risk and affects only PPC64 only. I verified there >> was no degradation in "make test" results and SPECjbb 2015 ran fine. The > >> intrinsics added in this changeset improved max jOPS by 5% and critical > jOPS by 4%. >> >> Regards, >> Ogata > Sorry, I started looking at this yesterday, but didn't get chance to finish. It looks fine to me. The stubGenerator_ppc.cpp changes were a little hard to follow, but comparing the patched version with the 11u version looked ok. Good to go. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From shade at redhat.com Wed Jul 31 16:08:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 31 Jul 2019 18:08:52 +0200 Subject: [8u] RFR 8214687: Optimize Collections.nCopies().hashCode() and equals() In-Reply-To: References: <43caafb3-239a-0829-9665-71dcae9bea01@redhat.com> <1d7e6380-912e-126b-e09f-4a77e22af240@redhat.com> <41ee101b-ec08-5e17-a9cc-5fe4e646f9da@redhat.com> Message-ID: <54ca6359-d827-aa9c-7d17-c480989675a0@redhat.com> On 7/31/19 5:56 PM, Andrew John Hughes wrote: > On 31/07/2019 10:02, Aleksey Shipilev wrote: >> On 7/16/19 9:25 AM, Andrew John Hughes wrote: >>> On 15/07/2019 09:27, Aleksey Shipilev wrote: >>>> On 7/2/19 9:53 PM, Aleksey Shipilev wrote: >>>>> Original RFE: >>>>> https://bugs.openjdk.java.net/browse/JDK-8214687 >>>>> https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499 >>>>> >>>>> Patch applies with usual reshufflings. But the test parts require touchups to compile and run on 8u: >>>>> type inference is not that rich, and there is no Objects.checkIndex. 8u webrev: >>>>> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01/ >>> >>> Objects.checkIndex is simply a wrapper around Preconditions.checkIndex: >>> >>> public static >>> int checkIndex(int index, int length) { >>> return Preconditions.checkIndex(index, length, null); >>> } >>> >>> which is in 8u. Probably worth adding the 2-argument version to >>> Preconditions. >> >> Getting back to this. Since we have moved Preconditions to private location in 8u, using it is >> impossible for this patch. So, I would keep the webrev as is: >> https://cr.openjdk.java.net/~shade/8214687/webrev.8u.01 > > We haven't moved anything as yet and my proposed patch leaves the class > as public, so shouldn't be a blocker. The test in that patch uses > Preconditions. Original patch needs Objects.checkIndex: https://hg.openjdk.java.net/jdk/jdk/rev/cfceb4df2499#l2.32 What you are suggesting is changing that line to Preconditions (with new method!). What webrev suggests is replacing it with the one-liner: 91 check(0 <= index && index < n, "Index is incorrect"); Given that we are changing the code anyway, I don't see why do we need to introduce another dependency to the about-to-be-moved class, do more code that diverges 8u from later releases, instead of doing the trivial one-liner. >> It is approved for 8u and 11u push, so if there are no other comments, I would push the fix shortly. >> > > Please don't "timeout" patches. Someone not seeing an e-mail is not the > same as an ok. Err. I meant to say that if there is no other comments, I am willing to move forward with this patch fast. It had been stuck on my queue for too long :) -- Thanks, -Aleksey From stooke at redhat.com Wed Jul 31 17:12:47 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 31 Jul 2019 13:12:47 -0400 Subject: RFC: backport of JDK-8215756: Memory leaks in the AWT on macOS In-Reply-To: References: <5fe51887-894b-af74-8b80-9770f8c4e78a@redhat.com> <54e7c8cb-8c20-1559-ce7d-80772960704c@redhat.com> Message-ID: <7e5b8ed8-750e-58a6-ed12-d70d2d2a7171@redhat.com> On 7/31/2019 11:59 AM, Aleksey Shipilev wrote: > On 7/30/19 9:39 PM, Simon Tooke wrote: >> On 7/30/2019 12:29 PM, Aleksey Shipilev wrote: >>> On 7/30/19 6:18 PM, Simon Tooke wrote: >>>> The patch is trivial, apart from the usual path changes. >>>> I omitted one file change that was only a line ending difference, and fixed the copyright dates. >>> Why omit it? >> Because it's not in my usual workflow (translation: lazy) to verify >> newline correctness in incoming patches.? It probably should be. >> >> I can add that file patch back, but, for example, one of the other file >> patches doesn't apply cleanly (after fixing paths), and it's due to >> chunks that only update newlines (in code that's not there in JDK8). > If the upstream patch updates newlines, backport should follow. If hunk is not applicable because > there is no code to update in 8u, hunk can be ignored. > >> I'm happy to add back the one newline fix, but since the patch needed >> modification anyways, I limited the original scope.? Just let me know a >> preference. > I prefer backported patches to be as close to upstream patches as possible, including whitespace > differences. This is mostly to cater for the follow-up patches to the same location that expect the > shape of file to the same. There are some exceptions to this rule, but whitespace diffs is usually > not the exceptional case. Fair enough, and persuasive. Here is my revised patch: http://cr.openjdk.java.net/~stooke/webrevs/jdk8215756-jdk8u.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8215756 Original patch: http://hg.openjdk.java.net/jdk/client/rev/64e7a73195c1 -Simon >