From sgehwolf at redhat.com Tue Sep 1 08:06:20 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 01 Sep 2020 10:06:20 +0200 Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <6adda6d77994f1a3dde60e9bb375ad80979bc7a8.camel@redhat.com> Message-ID: <976f2e74908041f1f29ee8c7597e46d4ac84ff91.camel@redhat.com> On Mon, 2020-08-31 at 17:32 +0000, Langer, Christoph wrote: > Hi Severin, > > > I had a look at this for 11u approval and this jumped out at me: > > > > src/jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProvider > > Service.java > > > > 107 synchronized (LOCK) { > > 108 Iterator iterator = providers.iterator(); > > 109 while (result == null && iterator.hasNext()) { > > 110 result = iterator.next().lookupEndpoints(url, envCopy) > > 111 .filter(r -> r.getEndpoints().isEmpty()) > > 112 .orElse(null); > > 113 } > > > > Line 111 inverses the filter from the original change[1]. This looks > > wrong. > > Oops, you're right. I believe the nightlies would have shown this regression, but anyway, thanks for spotting it. > > Here's the fix: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.2/ Looks good! Cheers, Severin From goetz.lindenmaier at sap.com Tue Sep 1 08:47:43 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Sep 2020 08:47:43 +0000 Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: <6adda6d77994f1a3dde60e9bb375ad80979bc7a8.camel@redhat.com> Message-ID: Yes, this is even better ?? Best geotz. -----Original Message----- From: Langer, Christoph Sent: Montag, 31. August 2020 19:32 To: Severin Gehwolf ; Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect Hi Severin, > I had a look at this for 11u approval and this jumped out at me: > > src/jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProvider > Service.java > > 107 synchronized (LOCK) { > 108 Iterator iterator = providers.iterator(); > 109 while (result == null && iterator.hasNext()) { > 110 result = iterator.next().lookupEndpoints(url, envCopy) > 111 .filter(r -> r.getEndpoints().isEmpty()) > 112 .orElse(null); > 113 } > > Line 111 inverses the filter from the original change[1]. This looks > wrong. Oops, you're right. I believe the nightlies would have shown this regression, but anyway, thanks for spotting it. Here's the fix: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.2/ Thanks Christoph From jaroslav.bachorik at datadoghq.com Tue Sep 1 08:52:50 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 1 Sep 2020 10:52:50 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces Message-ID: I would like to request a backport of this fix improving the hashing function and reducing the chance of conflict in storing JFR stacktrace data. JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/11u/ The patch applies almost cleanly with only hunk offset. Tier1 and JFR tests were executed to check for any regressions and all expected tests passed. Cheers, -JB- From shade at redhat.com Tue Sep 1 09:22:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 11:22:12 +0200 Subject: [11u] RFR (XS) 8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails In-Reply-To: References: Message-ID: <0888af6c-ac74-f0ec-56c8-add47e0a59f2@redhat.com> On 8/31/20 2:20 PM, Lindenmaier, Goetz wrote: > Hi Alexey, > > The change looks good to me. Thanks; already tagged, got approval, and pushed. -- -Aleksey From shade at redhat.com Tue Sep 1 09:47:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 11:47:08 +0200 Subject: [11u] RFR 8249192: MonitorInfo stores raw oops across safepoints Message-ID: <52b3da24-c528-31c8-59c7-072eb59e304d@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8249192 https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d The bulk of the patch applies exactly, but some hunks need adjustments. *) In jvmtiEnvBase.cpp, the hunk removing "ResourceMark rm(current_thread)" cannot be applied, because "current_thread" is added with JDK-8247729: https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 ...I just removed the ResourceMark by hand. *) In deoptimization.cpp, there is no eliminate_locks yet -- it is refactored out of "if (EliminateLocks)" branch later with JDK-8226705: https://hg.openjdk.java.net/jdk/jdk/rev/408c445d04e8#l21.162 https://hg.openjdk.java.net/jdk/jdk/rev/408c445d04e8#l21.59 ...so I put the HandleMark in the old place. Note it has a follow-up JDK-8251118, which needs to be backported too. Since the whole thing has a non-zero risk, it targets 11.0.10. 11u webrev: https://cr.openjdk.java.net/~shade/8249192/webrev.11u.01/ Testing: tier{1,2,3} with and without Shenandoah [which seems to find some of these bugs] -- Thanks, -Aleksey From shade at redhat.com Tue Sep 1 09:50:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 11:50:34 +0200 Subject: [11u] RFR 8251118: BiasedLocking::preserve_marks should not have a HandleMark Message-ID: <3dca7054-f6c3-4de3-4ef8-60d73b3b1f5a@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8251118 https://hg.openjdk.java.net/jdk/jdk/rev/abb125b87e74 This is a follow-up for JDK-8249192. The change is trivial, but it needs some adjustments in the test code: the test package was not introduced yet, so "gc." needs to be dropped. 11u patch: diff -r db0da07618e0 src/hotspot/share/runtime/biasedLocking.cpp --- a/src/hotspot/share/runtime/biasedLocking.cpp Thu Jul 23 21:10:52 2020 +0200 +++ b/src/hotspot/share/runtime/biasedLocking.cpp Tue Sep 01 11:50:02 2020 +0200 @@ -800,3 +800,2 @@ ResourceMark rm(cur); - HandleMark hm(cur); diff -r db0da07618e0 src/hotspot/share/runtime/vframe.hpp --- a/src/hotspot/share/runtime/vframe.hpp Thu Jul 23 21:10:52 2020 +0200 +++ b/src/hotspot/share/runtime/vframe.hpp Tue Sep 01 11:50:02 2020 +0200 @@ -32,3 +32,3 @@ #include "runtime/frame.hpp" -#include "runtime/handles.inline.hpp" +#include "runtime/handles.hpp" #include "runtime/stackValue.hpp" diff -r db0da07618e0 test/hotspot/jtreg/gc/TestFullGCALot.java --- a/test/hotspot/jtreg/gc/TestFullGCALot.java Thu Jul 23 21:10:52 2020 +0200 +++ b/test/hotspot/jtreg/gc/TestFullGCALot.java Tue Sep 01 11:50:02 2020 +0200 @@ -26,3 +26,3 @@ * @key gc - * @bug 4187687 8187819 + * @bug 4187687 8187819 8251118 * @summary Ensure no access violation when using FullGCALot @@ -30,2 +30,3 @@ * @run main/othervm -XX:NewSize=10m -XX:+FullGCALot -XX:FullGCALotInterval=120 TestFullGCALot + * @run main/othervm -XX:NewSize=10m -XX:+FullGCALot -XX:FullGCALotInterval=120 -XX:+UseBiasedLocking TestFullGCALot */ Testing: tier{1,2,3} with and without Shenandoah; affected test -- Thanks, -Aleksey From shade at redhat.com Tue Sep 1 10:03:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 12:03:42 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: Message-ID: On 9/1/20 10:52 AM, Jaroslav Bachor?k wrote: > I would like to request a backport of this fix improving the hashing > function and reducing the chance of conflict in storing JFR stacktrace > data. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 > Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/11u/ I have the same concern here as for 8u backport [1]. There are two places where the hash code is computed. While 11u backport matches what mainline does, and this is acceptable, this raises a question if mainline really needs to have those two hash codes computed the same way. And if so, does backporting the only one of the computations break anything? -- Thanks, -Aleksey [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012603.html From jaroslav.bachorik at datadoghq.com Tue Sep 1 10:45:43 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 1 Sep 2020 12:45:43 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: Message-ID: On Tue, Sep 1, 2020 at 12:03 PM Aleksey Shipilev wrote: > > On 9/1/20 10:52 AM, Jaroslav Bachor?k wrote: > > I would like to request a backport of this fix improving the hashing > > function and reducing the chance of conflict in storing JFR stacktrace > > data. > > > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8250928 > > Webrev: http://cr.openjdk.java.net/~jbachorik/8250928/11u/ > > I have the same concern here as for 8u backport [1]. > > There are two places where the hash code is computed. While 11u backport matches what mainline does, > and this is acceptable, this raises a question if mainline really needs to have those two hash codes > computed the same way. And if so, does backporting the only one of the computations break anything? Hm, this makes me wonder why the hash computation was not updated in both places in the mainline. With what we have now there the hash for the same stack trace object would be different depending on whether it is calculated in 'record_thread' or 'record_safe' method. This does not sound right to me. Perhaps, the mainline should be fixed to use the 'improved' calculation in both places first? -JB- > > -- > Thanks, > -Aleksey > > [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012603.html > From shade at redhat.com Tue Sep 1 10:48:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Sep 2020 12:48:03 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: Message-ID: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> On 9/1/20 12:45 PM, Jaroslav Bachor?k wrote: > Perhaps, the mainline should be fixed to use the 'improved' > calculation in both places first? Yes, that would be my guess. The backport to both 8u and 11u does not look safe until that peculiarity is resolved, either by additional patch, or justification why it is fine. -- Thanks, -Aleksey From jaroslav.bachorik at datadoghq.com Tue Sep 1 10:57:04 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 1 Sep 2020 12:57:04 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> Message-ID: On Tue, Sep 1, 2020 at 12:48 PM Aleksey Shipilev wrote: > > On 9/1/20 12:45 PM, Jaroslav Bachor?k wrote: > > Perhaps, the mainline should be fixed to use the 'improved' > > calculation in both places first? > > Yes, that would be my guess. The backport to both 8u and 11u does not look safe until that > peculiarity is resolved, either by additional patch, or justification why it is fine. Yes. I totally agree. Thanks for catching this early! -JB- > > -- > Thanks, > -Aleksey > From goetz.lindenmaier at sap.com Tue Sep 1 11:20:56 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 1 Sep 2020 11:20:56 +0000 Subject: [11u] RFR: 8241797: Add some tests to the problem list Message-ID: Hi, I need a review to downport this 11.0.10-Oracle change: http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_t_ProblemList-jdk11/01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8241797 https://hg.openjdk.java.net/jdk/jdk/rev/82da85888515 Best regards, Goetz. From zgu at redhat.com Tue Sep 1 14:20:18 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 1 Sep 2020 10:20:18 -0400 Subject: [11u] RFR 8212226: SurfaceManager throws "Invalid Image variant" for MultiResolutionImage (Windows) Message-ID: <0c10c4b9-a0d7-cbe3-2307-9c7762423190@redhat.com> I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. The original patch does not apply cleanly. However, the only conflict is the copyright year of SunGraphics2D.java. --- SunGraphics2D.java +++ SunGraphics2D.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2020, 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 The original bug: https://bugs.openjdk.java.net/browse/JDK-8212226 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/228f79238630 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8212226-11u/webrev.00/ Test: MultiResolutionImageSelectionTest.java on Windows and Linux Thanks, -Zhengyu From goetz.lindenmaier at sap.com Wed Sep 2 05:40:36 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 05:40:36 +0000 Subject: [11u] RFR(XS): 8252415: Bump update version for OpenJDK: jdk-11.0.10 In-Reply-To: <7d2878b8-3c15-11af-cc23-461f298db58a@redhat.com> References: <7d2878b8-3c15-11af-cc23-461f298db58a@redhat.com> Message-ID: Hi Aleksey, Thanks for the review ! Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev > Sent: Thursday, August 27, 2020 10:08 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR(XS): 8252415: Bump update version for OpenJDK: jdk- > 11.0.10 > > On 8/27/20 10:05 AM, Lindenmaier, Goetz wrote: > > to start development of jdk-11.0.10, we need to bump > > the version: > > http://cr.openjdk.java.net/~goetz/wr20/8252415-version_11.0.10-jdk11/ > > Sure thing. Looks good. > > -- > Thanks, > -Aleksey From goetz.lindenmaier at sap.com Wed Sep 2 07:23:08 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 07:23:08 +0000 Subject: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported Message-ID: Hi, We see test jdk/nio/zipfs/ReleaseDeflater.java failing on Windows 64-bit since "8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" was downported. java.lang.IllegalArgumentException: Illegal character in opaque part at index 11: jar:file:C:\\jvmtests\\output_ .... \\jdk\\nio\\zipfs\\ReleaseDeflater\\ReleaseDeflaterTest.zip at java.base/java.net.URI.create(URI.java:883) at ReleaseDeflater.main(ReleaseDeflater.java:51) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) https://bugs.openjdk.java.net/browse/JDK-8234011 https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 I would assume this is a problem with the test, looking at the change. Does someone have an idea how to fix this? Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Sep 2 08:58:47 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 08:58:47 +0000 Subject: [11u] RFR: 8217429: WebSocket over authenticating proxy fails to send Upgrade headers Message-ID: Hi I downport this for 11.0.10-Oracle parity. http://cr.openjdk.java.net/~goetz/wr20/8217429-websocket_headers-jdk11/01/ I had to add include of HttpRequestImpl in Utils.java to make it compile. http://cr.openjdk.java.net/~goetz/wr20/8217429-websocket_headers-jdk11/01/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java.udiff.html Please review. Original change: https://bugs.openjdk.java.net/browse/JDK-8217429 http://hg.openjdk.java.net/jdk/jdk/rev/41fa3e6f2785 Best regards, Goetz From goetz.lindenmaier at sap.com Wed Sep 2 09:27:04 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 09:27:04 +0000 Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <097300d2-5517-7565-b2de-345c153187da@redhat.com> References: <097300d2-5517-7565-b2de-345c153187da@redhat.com> Message-ID: Hi Zhengyu, I had a look at your downport. Does it make sense to add 8213843 to the @bug line in the test? That change is not downported to 11 yet, and I'm even not sure whether the issue fixed by that bug affects 11. Besides that it looks fine. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Zhengyu Gu > Sent: Wednesday, August 26, 2020 5:32 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are > truncated > > I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. > > The original patch does not apply cleanly, but conflicts are minor. > > 1) PopupFactory.java > Copyright year > > 2) StalePreferredSize.java > Imports, @bug, @module and run lines > > They are easy to fix manually. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8213535 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/71df50d2926b > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8213535-11u/webrev.00/ > > Thanks, > > -Zhengyu From goetz.lindenmaier at sap.com Wed Sep 2 09:46:03 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 09:46:03 +0000 Subject: [11u] RFR 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <52b3da24-c528-31c8-59c7-072eb59e304d@redhat.com> References: <52b3da24-c528-31c8-59c7-072eb59e304d@redhat.com> Message-ID: Hi Aleksey, The downport looks good. One could fear that the HandleMark in deoptimization.cpp is forgotten in case of a downport of 8226705. But a downport of this change is most unlikely I guess. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Aleksey Shipilev > Sent: Tuesday, September 1, 2020 11:47 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8249192: MonitorInfo stores raw oops across safepoints > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8249192 > https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d > > The bulk of the patch applies exactly, but some hunks need adjustments. > > *) In jvmtiEnvBase.cpp, the hunk removing "ResourceMark > rm(current_thread)" cannot be applied, > because "current_thread" is added with JDK-8247729: > https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 > > ...I just removed the ResourceMark by hand. > > *) In deoptimization.cpp, there is no eliminate_locks yet -- it is refactored > out of "if > (EliminateLocks)" branch later with JDK-8226705: > https://hg.openjdk.java.net/jdk/jdk/rev/408c445d04e8#l21.162 > https://hg.openjdk.java.net/jdk/jdk/rev/408c445d04e8#l21.59 > > ...so I put the HandleMark in the old place. > > Note it has a follow-up JDK-8251118, which needs to be backported too. > Since the whole thing has a > non-zero risk, it targets 11.0.10. > > 11u webrev: > https://cr.openjdk.java.net/~shade/8249192/webrev.11u.01/ > > Testing: tier{1,2,3} with and without Shenandoah [which seems to find some > of these bugs] > > -- > Thanks, > -Aleksey From goetz.lindenmaier at sap.com Wed Sep 2 09:48:05 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 09:48:05 +0000 Subject: [11u] RFR 8251118: BiasedLocking::preserve_marks should not have a HandleMark In-Reply-To: <3dca7054-f6c3-4de3-4ef8-60d73b3b1f5a@redhat.com> References: <3dca7054-f6c3-4de3-4ef8-60d73b3b1f5a@redhat.com> Message-ID: Hi Aleksey, Looks good. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Aleksey Shipilev > Sent: Tuesday, September 1, 2020 11:51 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8251118: BiasedLocking::preserve_marks should not have > a HandleMark > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8251118 > https://hg.openjdk.java.net/jdk/jdk/rev/abb125b87e74 > > This is a follow-up for JDK-8249192. The change is trivial, but it needs some > adjustments in the > test code: the test package was not introduced yet, so "gc." needs to be > dropped. > > 11u patch: > > diff -r db0da07618e0 src/hotspot/share/runtime/biasedLocking.cpp > --- a/src/hotspot/share/runtime/biasedLocking.cpp Thu Jul 23 21:10:52 > 2020 +0200 > +++ b/src/hotspot/share/runtime/biasedLocking.cpp Tue Sep 01 11:50:02 > 2020 +0200 > @@ -800,3 +800,2 @@ > ResourceMark rm(cur); > - HandleMark hm(cur); > > diff -r db0da07618e0 src/hotspot/share/runtime/vframe.hpp > --- a/src/hotspot/share/runtime/vframe.hpp Thu Jul 23 21:10:52 2020 > +0200 > +++ b/src/hotspot/share/runtime/vframe.hpp Tue Sep 01 11:50:02 2020 > +0200 > @@ -32,3 +32,3 @@ > #include "runtime/frame.hpp" > -#include "runtime/handles.inline.hpp" > +#include "runtime/handles.hpp" > #include "runtime/stackValue.hpp" > diff -r db0da07618e0 test/hotspot/jtreg/gc/TestFullGCALot.java > --- a/test/hotspot/jtreg/gc/TestFullGCALot.java Thu Jul 23 21:10:52 2020 > +0200 > +++ b/test/hotspot/jtreg/gc/TestFullGCALot.java Tue Sep 01 11:50:02 2020 > +0200 > @@ -26,3 +26,3 @@ > * @key gc > - * @bug 4187687 8187819 > + * @bug 4187687 8187819 8251118 > * @summary Ensure no access violation when using FullGCALot > @@ -30,2 +30,3 @@ > * @run main/othervm -XX:NewSize=10m -XX:+FullGCALot - > XX:FullGCALotInterval=120 TestFullGCALot > + * @run main/othervm -XX:NewSize=10m -XX:+FullGCALot - > XX:FullGCALotInterval=120 > -XX:+UseBiasedLocking TestFullGCALot > */ > > Testing: tier{1,2,3} with and without Shenandoah; affected test > > -- > Thanks, > -Aleksey From goetz.lindenmaier at sap.com Wed Sep 2 09:51:18 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 09:51:18 +0000 Subject: [11u] RFR 8212226: SurfaceManager throws "Invalid Image variant" for MultiResolutionImage (Windows) In-Reply-To: <0c10c4b9-a0d7-cbe3-2307-9c7762423190@redhat.com> References: <0c10c4b9-a0d7-cbe3-2307-9c7762423190@redhat.com> Message-ID: Hi Zhengyu, The downport looks good. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Zhengyu Gu > Sent: Tuesday, September 1, 2020 4:20 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8212226: SurfaceManager throws "Invalid Image variant" > for MultiResolutionImage (Windows) > > I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. > > The original patch does not apply cleanly. However, the only conflict is > the copyright year of SunGraphics2D.java. > > --- SunGraphics2D.java > +++ SunGraphics2D.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1996, 2020, 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 > > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8212226 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/228f79238630 > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8212226-11u/webrev.00/ > > Test: > MultiResolutionImageSelectionTest.java on Windows and Linux > > Thanks, > > -Zhengyu From goetz.lindenmaier at sap.com Wed Sep 2 10:45:51 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 10:45:51 +0000 Subject: [11u] RFR: 8241797: Add some tests to the problem list In-Reply-To: References: Message-ID: Sorry, broken link: http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_to_ProblemList-jdk11/01/ Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Lindenmaier, Goetz > Sent: Tuesday, September 1, 2020 1:21 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR: 8241797: Add some tests to the problem list > > Hi, > > I need a review to downport this 11.0.10-Oracle change: > > http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_t_ProblemList- > jdk11/01/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8241797 > https://hg.openjdk.java.net/jdk/jdk/rev/82da85888515 > > Best regards, > Goetz. From matthias.baesken at sap.com Wed Sep 2 10:51:56 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 Sep 2020 10:51:56 +0000 Subject: [11u] RFR: 8217429: WebSocket over authenticating proxy fails to send Upgrade headers Message-ID: Hi G?tz , the backport looks good to me . Best regards, Matthias >Hi > >I downport this for 11.0.10-Oracle parity. >http://cr.openjdk.java.net/~goetz/wr20/8217429-websocket_headers-jdk11/01/ > >I had to add include of HttpRequestImpl in Utils.java to make it compile. >http://cr.openjdk.java.net/~goetz/wr20/8217429-websocket_headers-jdk11/01/src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java.udiff.html > >Please review. > >Original change: >https://bugs.openjdk.java.net/browse/JDK-8217429 >http://hg.openjdk.java.net/jdk/jdk/rev/41fa3e6f2785 From matthias.baesken at sap.com Wed Sep 2 10:56:27 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 Sep 2020 10:56:27 +0000 Subject: [11u] RFR: 8241797: Add some tests to the problem list Message-ID: Hi, the change looks trivial and good to me . Best regards, Matthias >Sorry, broken link: >http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_to_ProblemList-jdk11/01/ > >Best regards, > Goetz. > > I need a review to downport this 11.0.10-Oracle change: > > http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_t_ProblemList- > jdk11/01/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8241797 > https://hg.openjdk.java.net/jdk/jdk/rev/82da85888515 > From matthias.baesken at sap.com Wed Sep 2 11:21:21 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 2 Sep 2020 11:21:21 +0000 Subject: [11u] RFR: 8213400: Support choosing group name in keytool keypair generation Message-ID: Hi G?tz , >I would like to downport this for parity with 11.0.10-oracle. >I had to resolve the code, especially CertAndKeyGen. >There already is a downport of the CSR which I will reuse. >Please review: >http://cr.openjdk.java.net/~goetz/wr20/8213400-keytool_keypair-jdk11/01/ > >Orig change: >https://bugs.openjdk.java.net/browse/JDK-8213400 >http://hg.openjdk.java.net/jdk/jdk/rev/ddcbc20e8c6a Why do you need this import ? http://cr.openjdk.java.net/~goetz/wr20/8213400-keytool_keypair-jdk11/01/src/java.base/share/classes/sun/security/tools/keytool/Main.java.frames.html 38 import java.security.NoSuchProviderException; It seems to be removed in the jdk/jdk change . Otherwise looks good . If you really need this import keep it, otherwise remove , no new webrev needed . Best regards, Matthias From goetz.lindenmaier at sap.com Wed Sep 2 13:08:57 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Sep 2020 13:08:57 +0000 Subject: [11u] RFR: 8213400: Support choosing group name in keytool keypair generation In-Reply-To: References: Message-ID: Hi Matthias, You are right, I should have removed that include. Fixed. Thanks, Goetz. From: Baesken, Matthias Sent: Wednesday, September 2, 2020 1:21 PM To: jdk-updates-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: re: [11u] RFR: 8213400: Support choosing group name in keytool keypair generation Hi G?tz , >I would like to downport this for parity with 11.0.10-oracle. >I had to resolve the code, especially CertAndKeyGen. >There already is a downport of the CSR which I will reuse. >Please review: >http://cr.openjdk.java.net/~goetz/wr20/8213400-keytool_keypair-jdk11/01/ > >Orig change: >https://bugs.openjdk.java.net/browse/JDK-8213400 >http://hg.openjdk.java.net/jdk/jdk/rev/ddcbc20e8c6a Why do you need this import ? http://cr.openjdk.java.net/~goetz/wr20/8213400-keytool_keypair-jdk11/01/src/java.base/share/classes/sun/security/tools/keytool/Main.java.frames.html 38 import java.security.NoSuchProviderException; It seems to be removed in the jdk/jdk change . Otherwise looks good . If you really need this import keep it, otherwise remove , no new webrev needed . Best regards, Matthias From zgu at redhat.com Wed Sep 2 13:36:13 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 Sep 2020 09:36:13 -0400 Subject: [11u] RFR 8212226: SurfaceManager throws "Invalid Image variant" for MultiResolutionImage (Windows) In-Reply-To: References: <0c10c4b9-a0d7-cbe3-2307-9c7762423190@redhat.com> Message-ID: Thanks, Goetz. -Zhengyu On 9/2/20 5:51 AM, Lindenmaier, Goetz wrote: > Hi Zhengyu, > > The downport looks good. > > Best regards, > Goetz. > >> -----Original Message----- >> From: jdk-updates-dev On Behalf >> Of Zhengyu Gu >> Sent: Tuesday, September 1, 2020 4:20 PM >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u] RFR 8212226: SurfaceManager throws "Invalid Image variant" >> for MultiResolutionImage (Windows) >> >> I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. >> >> The original patch does not apply cleanly. However, the only conflict is >> the copyright year of SunGraphics2D.java. >> >> --- SunGraphics2D.java >> +++ SunGraphics2D.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights >> reserved. >> + * Copyright (c) 1996, 2020, 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 >> >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8212226 >> The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/228f79238630 >> >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8212226-11u/webrev.00/ >> >> Test: >> MultiResolutionImageSelectionTest.java on Windows and Linux >> >> Thanks, >> >> -Zhengyu > From shade at redhat.com Wed Sep 2 16:53:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Sep 2020 18:53:19 +0200 Subject: [11u] RFR 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <52b3da24-c528-31c8-59c7-072eb59e304d@redhat.com> Message-ID: On 9/2/20 11:46 AM, Lindenmaier, Goetz wrote: > The downport looks good. Thanks, tagged. -- -Aleksey From shade at redhat.com Wed Sep 2 16:53:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Sep 2020 18:53:33 +0200 Subject: [11u] RFR 8251118: BiasedLocking::preserve_marks should not have a HandleMark In-Reply-To: References: <3dca7054-f6c3-4de3-4ef8-60d73b3b1f5a@redhat.com> Message-ID: On 9/2/20 11:48 AM, Lindenmaier, Goetz wrote: > Looks good. Thanks, tagged. -- -Aleksey From shade at redhat.com Wed Sep 2 17:09:07 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Sep 2020 19:09:07 +0200 Subject: [11u] RFR (XS) 8251949: ZGC: Set explicit heap size for compiler/gcbarriers tests In-Reply-To: References: Message-ID: <7263b7a2-7d5c-bd4c-0987-77a4a1b9715f@redhat.com> On 8/19/20 4:23 PM, Aleksey Shipilev wrote: > 11u-specific bug: > https://bugs.openjdk.java.net/browse/JDK-8251949 > > I suggested doing that in jdk/jdk initially, and then backport, but Per suggested it is best to do > in 11u specifically. > > 11u webrev: > https://cr.openjdk.java.net/~shade/8251949/webrev.11u.01/ Friendly reminder: the absence of this still makes at least mine tier1 runs unclean. :) -- Thanks, -Aleksey From zgu at redhat.com Wed Sep 2 18:12:03 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 Sep 2020 14:12:03 -0400 Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: <097300d2-5517-7565-b2de-345c153187da@redhat.com> Message-ID: <99689ebe-c3bb-3d99-e1f0-24877b03576e@redhat.com> Hi Goetz, On 9/2/20 5:27 AM, Lindenmaier, Goetz wrote: > Hi Zhengyu, > > I had a look at your downport. > > Does it make sense to add 8213843 to the @bug line in the test? Right, I will remove it. > That change is not downported to 11 yet, and I'm even not sure > whether the issue fixed by that bug affects 11. > I backported it blindly, I don't have HiDPI display to verify it :-( Should I just drop this backport? What do you think? Thanks, -Zhengyu > Besides that it looks fine. > > Best regards, > Goetz. > >> -----Original Message----- >> From: jdk-updates-dev On Behalf >> Of Zhengyu Gu >> Sent: Wednesday, August 26, 2020 5:32 PM >> To: jdk-updates-dev at openjdk.java.net >> Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are >> truncated >> >> I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. >> >> The original patch does not apply cleanly, but conflicts are minor. >> >> 1) PopupFactory.java >> Copyright year >> >> 2) StalePreferredSize.java >> Imports, @bug, @module and run lines >> >> They are easy to fix manually. >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8213535 >> The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/71df50d2926b >> >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8213535-11u/webrev.00/ >> >> Thanks, >> >> -Zhengyu > From gnu.andrew at redhat.com Thu Sep 3 03:19:44 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 3 Sep 2020 04:19:44 +0100 Subject: [11u] RFR: JDK-8252258: JDK-8242154 changes the default vendor Message-ID: <20200903031944.GA1438092@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8252258 Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8252258/webrev.01/ This is an 11u only fix. JDK-4947890 was partially backported during the 11.0.8 cycle, causing a regression in the default vendor name. In the partial backport, under the bug JDK-8242154 [0], the default defines for VENDOR, VENDOR_URL and VENDOR_URL_BUG are removed from System.c. However, only the default values for VENDOR_URL and VENDOR_URL_BUG are transferred to make/autoconf/version-numbers. The result is that the default vendor changes from "Oracle Corporation" in 11.0.7 to "N/A" in 11.0.8: With a local build of 11.0.7-ga: $ ~/builder/11u/images/jdk/bin/java -version openjdk version "11.0.7-internal" 2020-04-14 OpenJDK Runtime Environment (fastdebug build 11.0.7-internal+0-adhoc.ahughes.jdk11) OpenJDK 64-Bit Server VM (fastdebug build 11.0.7-internal+0-adhoc.ahughes.jdk11, mixed mode) $ ~/builder/11u/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep java.vendor java.vendor = Oracle Corporation java.vendor.url = http://java.oracle.com/ java.vendor.url.bug = http://bugreport.java.com/bugreport/ With the system install of 11.0.8-ga: $ /usr/lib/jvm/java-11-openjdk/bin/java -version openjdk version "11.0.8" 2020-07-14 LTS OpenJDK Runtime Environment 18.9 (build 11.0.8+10-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode, sharing) $ /usr/lib/jvm/java-11-openjdk/bin/java -XshowSettings:properties -version 2>&1 | grep java.vendor java.vendor = N/A java.vendor.url = https://openjdk.java.net/ java.vendor.url.bug = https://bugreport.java.com/bugreport/ java.vendor.version = 18.9 I don't believe we should be changing these defaults in a maintenance release. The webrev linked above changes COMPANY_NAME to "Oracle Corporation" to resume the previous behaviour and I intend to flag this as jdk11-critical-request once reviewed, as it's a regression. [0] https://bugs.openjdk.java.net/browse/JDK-8242154 -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From goetz.lindenmaier at sap.com Thu Sep 3 07:01:32 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Sep 2020 07:01:32 +0000 Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are truncated In-Reply-To: <99689ebe-c3bb-3d99-e1f0-24877b03576e@redhat.com> References: <097300d2-5517-7565-b2de-345c153187da@redhat.com> <99689ebe-c3bb-3d99-e1f0-24877b03576e@redhat.com> Message-ID: Hi Zhengyu > > Does it make sense to add 8213843 to the @bug line in the test? > Right, I will remove it. Ok. > > That change is not downported to 11 yet, and I'm even not sure > > whether the issue fixed by that bug affects 11. > > I backported it blindly, I don't have HiDPI display to verify it :-( > Should I just drop this backport? What do you think? My comment referred to 8213843. That one is not downported to 11. This one (8213535) I would bring to 11. Best regards, Geotz > > Thanks, > > -Zhengyu > > > > Besides that it looks fine. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: jdk-updates-dev On > Behalf > >> Of Zhengyu Gu > >> Sent: Wednesday, August 26, 2020 5:32 PM > >> To: jdk-updates-dev at openjdk.java.net > >> Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are > >> truncated > >> > >> I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. > >> > >> The original patch does not apply cleanly, but conflicts are minor. > >> > >> 1) PopupFactory.java > >> Copyright year > >> > >> 2) StalePreferredSize.java > >> Imports, @bug, @module and run lines > >> > >> They are easy to fix manually. > >> > >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8213535 > >> The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/71df50d2926b > >> > >> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8213535- > 11u/webrev.00/ > >> > >> Thanks, > >> > >> -Zhengyu > > From goetz.lindenmaier at sap.com Thu Sep 3 09:06:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Sep 2020 09:06:24 +0000 Subject: [11u] RFR: 8217429: WebSocket over authenticating proxy fails to send Upgrade headers In-Reply-To: References: Message-ID: Thanks, Matthias! Best, Goetz > -----Original Message----- > From: Baesken, Matthias > Sent: Wednesday, September 2, 2020 12:52 PM > To: jdk-updates-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8217429: WebSocket over authenticating proxy fails > to send Upgrade headers > > Hi G?tz , the backport looks good to me . > > Best regards, Matthias > > >Hi > > > >I downport this for 11.0.10-Oracle parity. > >http://cr.openjdk.java.net/~goetz/wr20/8217429-websocket_headers- > jdk11/01/ > > > >I had to add include of HttpRequestImpl in Utils.java to make it compile. > >http://cr.openjdk.java.net/~goetz/wr20/8217429-websocket_headers- > jdk11/01/src/java.net.http/share/classes/jdk/internal/net/http/common/Util > s.java.udiff.html > > > >Please review. > > > >Original change: > >https://bugs.openjdk.java.net/browse/JDK-8217429 > >http://hg.openjdk.java.net/jdk/jdk/rev/41fa3e6f2785 > > > From goetz.lindenmaier at sap.com Thu Sep 3 09:08:58 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Sep 2020 09:08:58 +0000 Subject: [11u] RFR: 8241797: Add some tests to the problem list In-Reply-To: References: Message-ID: Thanks! Beset regards, Goetz. > -----Original Message----- > From: Baesken, Matthias > Sent: Wednesday, September 2, 2020 12:56 PM > To: jdk-updates-dev at openjdk.java.net > Cc: Lindenmaier, Goetz > Subject: RE: [11u] RFR: 8241797: Add some tests to the problem list > > Hi, the change looks trivial and good to me . > > Best regards, Matthias > > > >Sorry, broken link: > >http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_to_ProblemList- > jdk11/01/ > > > >Best regards, > > Goetz. > > > > > I need a review to downport this 11.0.10-Oracle change: > > > > http://cr.openjdk.java.net/~goetz/wr20/8241797-Add_t_ProblemList- > > jdk11/01/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8241797 > > https://hg.openjdk.java.net/jdk/jdk/rev/82da85888515 > > From zgu at redhat.com Thu Sep 3 12:04:56 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 3 Sep 2020 08:04:56 -0400 Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are truncated In-Reply-To: References: <097300d2-5517-7565-b2de-345c153187da@redhat.com> <99689ebe-c3bb-3d99-e1f0-24877b03576e@redhat.com> Message-ID: On 9/3/20 3:01 AM, Lindenmaier, Goetz wrote: > Hi Zhengyu > >>> Does it make sense to add 8213843 to the @bug line in the test? >> Right, I will remove it. > Ok. > >>> That change is not downported to 11 yet, and I'm even not sure >>> whether the issue fixed by that bug affects 11. >> >> I backported it blindly, I don't have HiDPI display to verify it :-( >> Should I just drop this backport? What do you think? > > My comment referred to 8213843. That one is not downported to > 11. Ah, thanks for the clarification. Updated (removed bug id 8213843) http://cr.openjdk.java.net/~zgu/JDK-8213535-11u/webrev.01/ -Zhengyu > > This one (8213535) I would bring to 11. > > Best regards, > Geotz > > >> >> Thanks, >> >> -Zhengyu >> >> >>> Besides that it looks fine. >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: jdk-updates-dev On >> Behalf >>>> Of Zhengyu Gu >>>> Sent: Wednesday, August 26, 2020 5:32 PM >>>> To: jdk-updates-dev at openjdk.java.net >>>> Subject: [11u] RFR 8213535: Windows HiDPI html lightweight tooltips are >>>> truncated >>>> >>>> I would like to backport this to 11u for parity with Oracle 11.0.10-oracle. >>>> >>>> The original patch does not apply cleanly, but conflicts are minor. >>>> >>>> 1) PopupFactory.java >>>> Copyright year >>>> >>>> 2) StalePreferredSize.java >>>> Imports, @bug, @module and run lines >>>> >>>> They are easy to fix manually. >>>> >>>> The original bug: https://bugs.openjdk.java.net/browse/JDK-8213535 >>>> The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/71df50d2926b >>>> >>>> 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8213535- >> 11u/webrev.00/ >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>> > From vkempik at azul.com Thu Sep 3 12:28:06 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 3 Sep 2020 12:28:06 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes Message-ID: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> Hello Please review these backports of JDK-8209061:Move G1 serviceability functionality to G1MonitoringSupport and JDK-8209062:Clean up G1MonitoringSupport to jdk11u These backports are prerequestes for JDK-8207200 which we can see in the wild with jdk8 and jdk11. JDK-8209061 and JDK-8209062 applies mostly clean, very few places where it wasn?t clean due to surrounding code or code layout. after these two, JDK-8207200 applies cleanly. Testing: tier1. The webrevs: http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ All mentioned bugs: https://bugs.openjdk.java.net/browse/JDK-8209062 https://bugs.openjdk.java.net/browse/JDK-8209061 https://bugs.openjdk.java.net/browse/JDK-8207200 Original changesets: 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 Thanks, Vladimir From jaroslav.bachorik at datadoghq.com Thu Sep 3 13:04:38 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 3 Sep 2020 15:04:38 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> Message-ID: I have opened and fixed https://bugs.openjdk.java.net/browse/JDK-8252754 to do the hash code calculation consistently. I would prefer including both parts in one backport if possible. Any thoughts? Thanks, -JB- On Tue, Sep 1, 2020 at 12:57 PM Jaroslav Bachor?k wrote: > > On Tue, Sep 1, 2020 at 12:48 PM Aleksey Shipilev wrote: > > > > On 9/1/20 12:45 PM, Jaroslav Bachor?k wrote: > > > Perhaps, the mainline should be fixed to use the 'improved' > > > calculation in both places first? > > > > Yes, that would be my guess. The backport to both 8u and 11u does not look safe until that > > peculiarity is resolved, either by additional patch, or justification why it is fine. > > Yes. I totally agree. Thanks for catching this early! > > -JB- > > > > > -- > > Thanks, > > -Aleksey > > From goetz.lindenmaier at sap.com Thu Sep 3 13:50:46 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Sep 2020 13:50:46 +0000 Subject: [11u] RFR: 8248226: TestCloneAccessStressGCM fails with -XX:-ReduceBulkZeroing Message-ID: Hi I am downporting this for parity with 11.0.10-oracle. I had to resolve due to different context. In the original, no offset is passed to AllocateNode::Ideal_allocation() http://cr.openjdk.java.net/~goetz/wr20/8248226-BulkZeroing-jdk11/01/index.html Please review. https://bugs.openjdk.java.net/browse/JDK-8248226 https://hg.openjdk.java.net/jdk/jdk/rev/ae002489df78 Best regards, Goetz. From goetz.lindenmaier at sap.com Thu Sep 3 14:20:44 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Sep 2020 14:20:44 +0000 Subject: [11u] RFR: 8249672: Include microcode revision in features_string on x86 Message-ID: Hi I am downporting this for parity with 11.0.10-oracle. The format string in vm_version_x86 if formatted differently in 11, so I had to resolve. I copied some of the line breaks from the source, it really makes The code more readable. http://cr.openjdk.java.net/~goetz/wr20/8249672-x86_microcode_vers-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8249672 https://hg.openjdk.java.net/jdk/jdk/rev/931c949e05e4 Best regards, Goetz. From jaroslav.bachorik at datadoghq.com Thu Sep 3 17:00:58 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 3 Sep 2020 19:00:58 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> Message-ID: Hearing no objections, here is a new webrev: http://cr.openjdk.java.net/~jbachorik/8250928/11u/01/webrev -JB- On Thu, Sep 3, 2020 at 3:04 PM Jaroslav Bachor?k wrote: > > I have opened and fixed > https://bugs.openjdk.java.net/browse/JDK-8252754 to do the hash code > calculation consistently. > > I would prefer including both parts in one backport if possible. Any thoughts? > > Thanks, > > -JB- > > On Tue, Sep 1, 2020 at 12:57 PM Jaroslav Bachor?k > wrote: > > > > On Tue, Sep 1, 2020 at 12:48 PM Aleksey Shipilev wrote: > > > > > > On 9/1/20 12:45 PM, Jaroslav Bachor?k wrote: > > > > Perhaps, the mainline should be fixed to use the 'improved' > > > > calculation in both places first? > > > > > > Yes, that would be my guess. The backport to both 8u and 11u does not look safe until that > > > peculiarity is resolved, either by additional patch, or justification why it is fine. > > > > Yes. I totally agree. Thanks for catching this early! > > > > -JB- > > > > > > > > -- > > > Thanks, > > > -Aleksey > > > From volker.simonis at gmail.com Fri Sep 4 08:10:21 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Sep 2020 10:10:21 +0200 Subject: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported In-Reply-To: References: Message-ID: Hi Goetz, yes, this is a test problem caused by the way we construct the URI from a Path. This part of the test had to be changed for the downport because the original patch used a version of FileSystems.newFileSystem(..) which directly takes a Path argument and is not available in jdk11. I think the fix would be similar to https://bugs.openjdk.java.net/browse/JDK-8186227. I'll take a look. Thanks for finding this, Volker On Wed, Sep 2, 2020 at 9:23 AM Lindenmaier, Goetz wrote: > > Hi, > > We see test jdk/nio/zipfs/ReleaseDeflater.java failing on Windows 64-bit since > "8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" was downported. > > java.lang.IllegalArgumentException: Illegal character in opaque part at index 11: jar:file:C:\\jvmtests\\output_ .... \\jdk\\nio\\zipfs\\ReleaseDeflater\\ReleaseDeflaterTest.zip > at java.base/java.net.URI.create(URI.java:883) > at ReleaseDeflater.main(ReleaseDeflater.java:51) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > https://bugs.openjdk.java.net/browse/JDK-8234011 > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 > > I would assume this is a problem with the test, looking at the change. > Does someone have an idea how to fix this? > > Best regards, > Goetz. From goetz.lindenmaier at sap.com Fri Sep 4 08:33:48 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 4 Sep 2020 08:33:48 +0000 Subject: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported In-Reply-To: References: Message-ID: Hi Volker That sounds good, thanks for investigating! Best regards, Goetz -----Original Message----- From: Volker Simonis Sent: Freitag, 4. September 2020 10:10 To: Lindenmaier, Goetz Cc: jdk-updates-dev at openjdk.java.net Subject: Re: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported Hi Goetz, yes, this is a test problem caused by the way we construct the URI from a Path. This part of the test had to be changed for the downport because the original patch used a version of FileSystems.newFileSystem(..) which directly takes a Path argument and is not available in jdk11. I think the fix would be similar to https://bugs.openjdk.java.net/browse/JDK-8186227. I'll take a look. Thanks for finding this, Volker On Wed, Sep 2, 2020 at 9:23 AM Lindenmaier, Goetz wrote: > > Hi, > > We see test jdk/nio/zipfs/ReleaseDeflater.java failing on Windows 64-bit since > "8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" was downported. > > java.lang.IllegalArgumentException: Illegal character in opaque part at index 11: jar:file:C:\\jvmtests\\output_ .... \\jdk\\nio\\zipfs\\ReleaseDeflater\\ReleaseDeflaterTest.zip > at java.base/java.net.URI.create(URI.java:883) > at ReleaseDeflater.main(ReleaseDeflater.java:51) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > https://bugs.openjdk.java.net/browse/JDK-8234011 > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 > > I would assume this is a problem with the test, looking at the change. > Does someone have an idea how to fix this? > > Best regards, > Goetz. From volker.simonis at gmail.com Fri Sep 4 13:40:13 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Sep 2020 15:40:13 +0200 Subject: RFR(XS): 8252804: [test] Fix 'ReleaseDeflater.java' test after downport of 8234011 Message-ID: Hi, can I please have a review for this trivial test fix which was introduced with the downport of "JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" [1]. The downport [2] contained the test "test/jdk/jdk/nio/zipfs/ReleaseDeflater.java" which had to be slightly modified for the downport. These modifications made him fail on Windows. http://cr.openjdk.java.net/~simonis/webrevs/2020/8252804 https://bugs.openjdk.java.net/browse/JDK-8252804 Do you want me to bring this to 11.0.9 with a "jdk11u-critical-request"? Thank you and best regards, Volker [1] https://hg.openjdk.java.net/jdk/jdk/rev/fe87a92570db [2] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 From volker.simonis at gmail.com Fri Sep 4 13:42:11 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Sep 2020 15:42:11 +0200 Subject: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported In-Reply-To: References: Message-ID: The fix is trivial and out for review now: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003769.html Do you want me to bring this to 11.0.9 with a "jdk11u-critical-request"? Best regards, Volker On Fri, Sep 4, 2020 at 10:33 AM Lindenmaier, Goetz wrote: > > Hi Volker > > That sounds good, thanks for investigating! > > Best regards, > Goetz > > -----Original Message----- > From: Volker Simonis > Sent: Freitag, 4. September 2020 10:10 > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported > > Hi Goetz, > > yes, this is a test problem caused by the way we construct the URI > from a Path. This part of the test had to be changed for the downport > because the original patch used a version of > FileSystems.newFileSystem(..) which directly takes a Path argument and > is not available in jdk11. > > I think the fix would be similar to > https://bugs.openjdk.java.net/browse/JDK-8186227. I'll take a look. > > Thanks for finding this, > Volker > > On Wed, Sep 2, 2020 at 9:23 AM Lindenmaier, Goetz > wrote: > > > > Hi, > > > > We see test jdk/nio/zipfs/ReleaseDeflater.java failing on Windows 64-bit since > > "8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" was downported. > > > > java.lang.IllegalArgumentException: Illegal character in opaque part at index 11: jar:file:C:\\jvmtests\\output_ .... \\jdk\\nio\\zipfs\\ReleaseDeflater\\ReleaseDeflaterTest.zip > > at java.base/java.net.URI.create(URI.java:883) > > at ReleaseDeflater.main(ReleaseDeflater.java:51) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > > https://bugs.openjdk.java.net/browse/JDK-8234011 > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 > > > > I would assume this is a problem with the test, looking at the change. > > Does someone have an idea how to fix this? > > > > Best regards, > > Goetz. From hohensee at amazon.com Fri Sep 4 13:47:11 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 4 Sep 2020 13:47:11 +0000 Subject: RFR(XS): 8252804: [test] Fix 'ReleaseDeflater.java' test after downport of 8234011 Message-ID: Lgtm. Paul ?On 9/4/20, 6:41 AM, "jdk-updates-dev on behalf of Volker Simonis" wrote: Hi, can I please have a review for this trivial test fix which was introduced with the downport of "JDK-8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" [1]. The downport [2] contained the test "test/jdk/jdk/nio/zipfs/ReleaseDeflater.java" which had to be slightly modified for the downport. These modifications made him fail on Windows. http://cr.openjdk.java.net/~simonis/webrevs/2020/8252804 https://bugs.openjdk.java.net/browse/JDK-8252804 Do you want me to bring this to 11.0.9 with a "jdk11u-critical-request"? Thank you and best regards, Volker [1] https://hg.openjdk.java.net/jdk/jdk/rev/fe87a92570db [2] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 From volker.simonis at gmail.com Fri Sep 4 13:50:01 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Sep 2020 15:50:01 +0200 Subject: RFR(XS): 8252804: [test] Fix 'ReleaseDeflater.java' test after downport of 8234011 In-Reply-To: References: Message-ID: Thanks, Paul. On Fri, Sep 4, 2020 at 3:47 PM Hohensee, Paul wrote: > > Lgtm. > > Paul > > ?On 9/4/20, 6:41 AM, "jdk-updates-dev on behalf of Volker Simonis" wrote: > > Hi, > > can I please have a review for this trivial test fix which was > introduced with the downport of "JDK-8234011: (zipfs) Memory leak in > ZipFileSystem.releaseDeflater()" [1]. The downport [2] contained the > test "test/jdk/jdk/nio/zipfs/ReleaseDeflater.java" which had to be > slightly modified for the downport. These modifications made him fail > on Windows. > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8252804 > https://bugs.openjdk.java.net/browse/JDK-8252804 > > Do you want me to bring this to 11.0.9 with a "jdk11u-critical-request"? > > Thank you and best regards, > Volker > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/fe87a92570db > [2] https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 > From goetz.lindenmaier at sap.com Fri Sep 4 15:11:58 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 4 Sep 2020 15:11:58 +0000 Subject: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported In-Reply-To: References: Message-ID: Yes, I think we should bring it to 11.0.9. It's just a test fix ... so it won't break anything. Best regards, Goetz. -----Original Message----- From: Volker Simonis Sent: Freitag, 4. September 2020 15:42 To: Lindenmaier, Goetz Cc: jdk-updates-dev at openjdk.java.net Subject: Re: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported The fix is trivial and out for review now: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003769.html Do you want me to bring this to 11.0.9 with a "jdk11u-critical-request"? Best regards, Volker On Fri, Sep 4, 2020 at 10:33 AM Lindenmaier, Goetz wrote: > > Hi Volker > > That sounds good, thanks for investigating! > > Best regards, > Goetz > > -----Original Message----- > From: Volker Simonis > Sent: Freitag, 4. September 2020 10:10 > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported > > Hi Goetz, > > yes, this is a test problem caused by the way we construct the URI > from a Path. This part of the test had to be changed for the downport > because the original patch used a version of > FileSystems.newFileSystem(..) which directly takes a Path argument and > is not available in jdk11. > > I think the fix would be similar to > https://bugs.openjdk.java.net/browse/JDK-8186227. I'll take a look. > > Thanks for finding this, > Volker > > On Wed, Sep 2, 2020 at 9:23 AM Lindenmaier, Goetz > wrote: > > > > Hi, > > > > We see test jdk/nio/zipfs/ReleaseDeflater.java failing on Windows 64-bit since > > "8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" was downported. > > > > java.lang.IllegalArgumentException: Illegal character in opaque part at index 11: jar:file:C:\\jvmtests\\output_ .... \\jdk\\nio\\zipfs\\ReleaseDeflater\\ReleaseDeflaterTest.zip > > at java.base/java.net.URI.create(URI.java:883) > > at ReleaseDeflater.main(ReleaseDeflater.java:51) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > > https://bugs.openjdk.java.net/browse/JDK-8234011 > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 > > > > I would assume this is a problem with the test, looking at the change. > > Does someone have an idea how to fix this? > > > > Best regards, > > Goetz. From volker.simonis at gmail.com Fri Sep 4 15:36:33 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Sep 2020 17:36:33 +0200 Subject: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported In-Reply-To: References: Message-ID: OK, no problem. The change has been reviewed and I've put the jdk11u-fix-request and jdk11u-critical-request flags on the JBS issue. Now it's up to you as you are the maintainers :) On Fri, Sep 4, 2020 at 5:12 PM Lindenmaier, Goetz wrote: > > Yes, I think we should bring it to 11.0.9. > It's just a test fix ... so it won't break anything. > > Best regards, > Goetz. > > -----Original Message----- > From: Volker Simonis > Sent: Freitag, 4. September 2020 15:42 > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported > > The fix is trivial and out for review now: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003769.html > > Do you want me to bring this to 11.0.9 with a "jdk11u-critical-request"? > > Best regards, > Volker > > On Fri, Sep 4, 2020 at 10:33 AM Lindenmaier, Goetz > wrote: > > > > Hi Volker > > > > That sounds good, thanks for investigating! > > > > Best regards, > > Goetz > > > > -----Original Message----- > > From: Volker Simonis > > Sent: Freitag, 4. September 2020 10:10 > > To: Lindenmaier, Goetz > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] Test failing since downport of 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() was downported > > > > Hi Goetz, > > > > yes, this is a test problem caused by the way we construct the URI > > from a Path. This part of the test had to be changed for the downport > > because the original patch used a version of > > FileSystems.newFileSystem(..) which directly takes a Path argument and > > is not available in jdk11. > > > > I think the fix would be similar to > > https://bugs.openjdk.java.net/browse/JDK-8186227. I'll take a look. > > > > Thanks for finding this, > > Volker > > > > On Wed, Sep 2, 2020 at 9:23 AM Lindenmaier, Goetz > > wrote: > > > > > > Hi, > > > > > > We see test jdk/nio/zipfs/ReleaseDeflater.java failing on Windows 64-bit since > > > "8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater()" was downported. > > > > > > java.lang.IllegalArgumentException: Illegal character in opaque part at index 11: jar:file:C:\\jvmtests\\output_ .... \\jdk\\nio\\zipfs\\ReleaseDeflater\\ReleaseDeflaterTest.zip > > > at java.base/java.net.URI.create(URI.java:883) > > > at ReleaseDeflater.main(ReleaseDeflater.java:51) > > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > > > > https://bugs.openjdk.java.net/browse/JDK-8234011 > > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/cb299db4a569 > > > > > > I would assume this is a problem with the test, looking at the change. > > > Does someone have an idea how to fix this? > > > > > > Best regards, > > > Goetz. From gnu.andrew at redhat.com Fri Sep 4 16:10:24 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Sep 2020 17:10:24 +0100 Subject: Additional Labels for Backport Work In-Reply-To: References: <20200821190945.GD31221@stopbrexit> <987fb3f8-573f-28e6-fe89-df519780aad9@redhat.com> Message-ID: <20200904161024.GA1550354@stopbrexit> On 22:03 Thu 27 Aug , Jesper Wilhelmsson wrote: > > On 27 Aug 2020, at 21:58, Martin Balao wrote: > > > > On 8/27/20 1:48 PM, Mario Torre wrote: > >> After a brief discussion today, it occurred to me that we can create > >> backport bugs manually and assign them directly, wouldn't this be a > >> better approach to track who is working on a specific backport? > > > > Yes, I thought about this idea some time ago and discussing with Andrew > > (@gnu_andrew) he raised a valid concern: end-up with lots of backport > > bug duplicates when those manually created are not automatically > > resolved when pushing the fix -and new ones being created-. We would > > need to know exactly how to manually create bugs that are then resolved > > when pushing. But then we need to rely on everybody getting it right. > > I've seen duplicates already when manually creating backport bugs for CSRs. > > For an 8u backport set the fixVersion to 8-pool to have hg updater resolve the issue. This should be standard practice for all bugs/backports in update releases. Always set fixVersion to X-pool unless you know for sure what release you need it to go into and are requesting that the fix should be included in the release in the rampdown phase. > > /Jesper > Except it doesn't seem to work with OpenJDK 8u at present e.g. https://bugs.openjdk.java.net/browse/JDK-8160768 JDK-8251269 should have been resolved, but JDK-8252535 was created instead. I've mailed ops about this. I think it may be because '8u' is still the Oracle proprietary fork for 8, and openjdk8u is the open version. With 11u, it's the other way around (11.0.7 and 11.0.7-oracle, for example), so hopefully things work as expected there. I went the label route instead because it's less prone to error, easier to correct if errors do occur and intended to be transient (applied when you start work and removed when finished). Also the main bug ID is the one to refer to and use in changesets. I wouldn't like to see the additional confusion of backport IDs being used in mailing list posts and commits. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From gnu.andrew at redhat.com Fri Sep 4 16:15:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Sep 2020 17:15:07 +0100 Subject: Additional Labels for Backport Work In-Reply-To: References: <20200821190945.GD31221@stopbrexit> Message-ID: <20200904161507.GC1550354@stopbrexit> On 15:45 Thu 27 Aug , Volker Simonis wrote: > Hi, > > As two of the corresponding three 8u and 11u maintainers are actually > overlapping, I wonder if these new rules already automatically apply > to the 11u updates process as well or do they require an additional > approval of the 11u lead maintainer (Andrew H.)? > > I'd personally welcome the use of the new tags in 11u. > > Best regards, > Volker > Missed the replies to this thread as they moved off the 8u-dev list. As the one maintainer who doesn't overlap, I can only suggest what the maintainers in 11u want to do, based on what we're doing in 8u :) Best regards, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From gnu.andrew at redhat.com Fri Sep 4 16:15:44 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 4 Sep 2020 17:15:44 +0100 Subject: [11u] RFR: JDK-8252258: JDK-8242154 changes the default vendor In-Reply-To: <20200903031944.GA1438092@stopbrexit> References: <20200903031944.GA1438092@stopbrexit> Message-ID: <20200904161544.GD1550354@stopbrexit> On 04:19 Thu 03 Sep , Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8252258 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8252258/webrev.01/ > > This is an 11u only fix. > > JDK-4947890 was partially backported during the 11.0.8 cycle, > causing a regression in the default vendor name. > > In the partial backport, under the bug JDK-8242154 [0], > the default defines for VENDOR, VENDOR_URL and VENDOR_URL_BUG > are removed from System.c. However, only the default values > for VENDOR_URL and VENDOR_URL_BUG are transferred to > make/autoconf/version-numbers. > > The result is that the default vendor changes from > "Oracle Corporation" in 11.0.7 to "N/A" in 11.0.8: > > With a local build of 11.0.7-ga: > > $ ~/builder/11u/images/jdk/bin/java -version > openjdk version "11.0.7-internal" 2020-04-14 > OpenJDK Runtime Environment (fastdebug build 11.0.7-internal+0-adhoc.ahughes.jdk11) > OpenJDK 64-Bit Server VM (fastdebug build 11.0.7-internal+0-adhoc.ahughes.jdk11, mixed mode) > > $ ~/builder/11u/images/jdk/bin/java -XshowSettings:properties -version 2>&1 | grep java.vendor > java.vendor = Oracle Corporation > java.vendor.url = http://java.oracle.com/ > java.vendor.url.bug = http://bugreport.java.com/bugreport/ > > With the system install of 11.0.8-ga: > > $ /usr/lib/jvm/java-11-openjdk/bin/java -version > openjdk version "11.0.8" 2020-07-14 LTS > OpenJDK Runtime Environment 18.9 (build 11.0.8+10-LTS) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode, sharing) > > $ /usr/lib/jvm/java-11-openjdk/bin/java -XshowSettings:properties -version 2>&1 | grep java.vendor > java.vendor = N/A > java.vendor.url = https://openjdk.java.net/ > java.vendor.url.bug = https://bugreport.java.com/bugreport/ > java.vendor.version = 18.9 > > I don't believe we should be changing these defaults in a maintenance > release. The webrev linked above changes COMPANY_NAME to "Oracle > Corporation" to resume the previous behaviour and I intend to flag > this as jdk11-critical-request once reviewed, as it's a regression. > > [0] https://bugs.openjdk.java.net/browse/JDK-8242154 > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > 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 Ping? -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From christoph.langer at sap.com Mon Sep 7 02:43:57 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 7 Sep 2020 02:43:57 +0000 Subject: [11u] RFR: JDK-8252258: JDK-8242154 changes the default vendor In-Reply-To: <20200903031944.GA1438092@stopbrexit> References: <20200903031944.GA1438092@stopbrexit> Message-ID: Hi Andrew, thanks for spotting this and creating the fix. While I think, N/A is the better default for OpenJDK, compared to Oracle Corporation, I have to admit that that's not something that should be changed during a release lifecycle. So, LGTM. And, I agree, this should go into 11.0.9. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Hughes > Sent: Donnerstag, 3. September 2020 05:20 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: JDK-8252258: JDK-8242154 changes the default vendor > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252258 > Webrev: > https://cr.openjdk.java.net/~andrew/openjdk11/8252258/webrev.01/ > > This is an 11u only fix. > > JDK-4947890 was partially backported during the 11.0.8 cycle, > causing a regression in the default vendor name. > > In the partial backport, under the bug JDK-8242154 [0], > the default defines for VENDOR, VENDOR_URL and VENDOR_URL_BUG > are removed from System.c. However, only the default values > for VENDOR_URL and VENDOR_URL_BUG are transferred to > make/autoconf/version-numbers. > > The result is that the default vendor changes from > "Oracle Corporation" in 11.0.7 to "N/A" in 11.0.8: > > With a local build of 11.0.7-ga: > > $ ~/builder/11u/images/jdk/bin/java -version > openjdk version "11.0.7-internal" 2020-04-14 > OpenJDK Runtime Environment (fastdebug build 11.0.7-internal+0- > adhoc.ahughes.jdk11) > OpenJDK 64-Bit Server VM (fastdebug build 11.0.7-internal+0- > adhoc.ahughes.jdk11, mixed mode) > > $ ~/builder/11u/images/jdk/bin/java -XshowSettings:properties -version > 2>&1 | grep java.vendor > java.vendor = Oracle Corporation > java.vendor.url = http://java.oracle.com/ > java.vendor.url.bug = http://bugreport.java.com/bugreport/ > > With the system install of 11.0.8-ga: > > $ /usr/lib/jvm/java-11-openjdk/bin/java -version > openjdk version "11.0.8" 2020-07-14 LTS > OpenJDK Runtime Environment 18.9 (build 11.0.8+10-LTS) > OpenJDK 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode, sharing) > > $ /usr/lib/jvm/java-11-openjdk/bin/java -XshowSettings:properties -version > 2>&1 | grep java.vendor > java.vendor = N/A > java.vendor.url = https://openjdk.java.net/ > java.vendor.url.bug = https://bugreport.java.com/bugreport/ > java.vendor.version = 18.9 > > I don't believe we should be changing these defaults in a maintenance > release. The webrev linked above changes COMPANY_NAME to "Oracle > Corporation" to resume the previous behaviour and I intend to flag > this as jdk11-critical-request once reviewed, as it's a regression. > > [0] https://bugs.openjdk.java.net/browse/JDK-8242154 > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > 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 From shade at redhat.com Mon Sep 7 08:05:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Sep 2020 10:05:37 +0200 Subject: [11u] RFR 8239477: jdk/jfr/jcmd/TestJcmdStartStopDefault.java fails -XX:+VerifyOops with "verify_oop: rsi: broken oop" In-Reply-To: References: Message-ID: <07a07c67-cad3-4c14-cf79-abcc3114f4d0@redhat.com> This seems to have fallen through the cracks: On 7/31/20 12:53 PM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8239477 > https://hg.openjdk.java.net/jdk/jdk/rev/1dfb43020070 > > CIs that run testing -XX:+VerifyOops with 11u fail without this. > > 11u fix is a bit different, because the context is a bit different around this line: > __ branch(lir_cond_equal, T_OBJECT, L_end->label()); > > 11u webrev: > http://cr.openjdk.java.net/~shade/8239477/webrev.11u.01/ > > Testing: affected test (used to fail, now it passes); tier{1,2}; jdk_jfr -- Thanks, -Aleksey From shade at redhat.com Mon Sep 7 08:17:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Sep 2020 10:17:52 +0200 Subject: [15u] RFR (S) 8252648: Shenandoah: name gang tasks consistently Message-ID: <4596e8a6-cb7e-fec0-54fe-6663ad2196ec@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8252648 https://hg.openjdk.java.net/jdk/jdk/rev/1a839c572dfd There is a little conflict around ShenandoahConcurrentWeakRootsEvacUpdateTask definition, resolved by hand. 15u webrev: https://cr.openjdk.java.net/~shade/8252648/webrev.15u.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From shade at redhat.com Mon Sep 7 11:29:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Sep 2020 13:29:22 +0200 Subject: [11u] RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize option Message-ID: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8252660 https://hg.openjdk.java.net/jdk/jdk/rev/6ab9279c0e99 The patch does not apply cleanly to 11u, because there are conflicts in APIs. I had to resolve these: *) There is no Atomic::store(&size_t, size_t), replaced with OrderAccess::release_store_fence, as in other places in 11u. *) There is no global SoftMaxHeapSize, replaced it with ShenandoahSoftMaxHeapSize and added relevant verifications to make new Shenandoah tests pass. 11u webrev: https://cr.openjdk.java.net/~shade/8252660/webrev.11u.01/ Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah -- Thanks, -Aleksey From aph at redhat.com Tue Sep 8 09:12:05 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Sep 2020 10:12:05 +0100 Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com> <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com> Message-ID: On 28/08/2020 17:19, Doerr, Martin wrote: > 1. Some people assume that all of Oracle's 11u changes should get > integrated into the open version. > 2. Others only want to take them on demand with a good reason. > > I think there are good arguments for and against both ones. > Personally, I think approach 1. is better at the beginning of an > updates branch while it may be reasonable to switch at some point of > time. > At the moment, I still prefer to stay in sync with Oracle as far as > we can. > > Regarding this change, I don't see a high risk. > What it basically does is that it reuses better code which is > already used by C2 for C1 and JVMCI compilers. So there's no > substantial new code. > It's tested by GraalVM and by our internal testing. There are no > known issues with it. > > So I'd rather vote for taking it. OK for this particular change. Please go ahead. On the wider point: A while ago I announced that we should not continue to independently approve backports that had already been approved by Oracle. My reasoning was that they'd done the work of balancing risk and reward, and that for us to do it again when the decision would almost inevitably be the same was not a good use of our time. After some very noisy protests which insisted that this project must continue to approve backports independently, I relented. But there is no point retaining that right if we're never going to use it! We should keep a close watch on Oracle backports for a while to try to understand what their criteria are, and whether those criteria are a good fit for our mission. If we see a significant number of minor performance tweaks and "cleanups" we should reconsider our policy. -- 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 goetz.lindenmaier at sap.com Tue Sep 8 12:01:38 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Sep 2020 12:01:38 +0000 Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com> <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com> Message-ID: Hi > On the wider point: > > A while ago I announced that we should not continue to independently > approve backports that had already been approved by Oracle. My > reasoning was that they'd done the work of balancing risk and reward, > and that for us to do it again when the decision would almost > inevitably be the same was not a good use of our time. After some very > noisy protests which insisted that this project must continue to > approve backports independently, I relented. But there is no point > retaining that right if we're never going to use it! I would appreciate this a lot, as it would reduce the effort of downporting considerably. Thanks! > We should keep a close watch on Oracle backports for a while to try to > understand what their criteria are, and whether those criteria are a > good fit for our mission. If we see a significant number of minor > performance tweaks and "cleanups" we should reconsider our policy. One possibility to watch what Oracle is doing is that maintainers have an eye on the according filters of 11.0.x-oracle changes and flag them jdk11u-fix-no ad-hoc, before someone starts to actually work and downport the bug. Others, that also have an opinion on this, could also watch the filter and then add comments why they recommend not to downport the change. Then again, if someone has a concrete interest to downport, besides the motivation that Oracle downported it, this can be discussed. In the case of this change, it required a close look at the coding, which is why I had asked Martin to address it. Martin is an expert in this area. The objections came just after he had completed his work. I's really not helpful if a change is turned down just after all the work is done. This could be avoided by above approach. Great it is approved. Best regards, Goetz. > > -- > 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 neugens at redhat.com Tue Sep 8 12:27:41 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 8 Sep 2020 14:27:41 +0200 Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com> <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com> Message-ID: On Tue, Sep 8, 2020 at 2:02 PM Lindenmaier, Goetz wrote: > In the case of this change, it required a close look at the coding, > which is why I had asked Martin to address it. Martin is an > expert in this area. The objections came just after he had completed > his work. I's really not helpful if a change is turned down just after > all the work is done. This could be avoided by above approach. > Great it is approved. The way I see it is that although the maintainer can say no at any time, since they are not reviewing the patch their "no" usually happens later in the game anyway, so some amount of work has been done, I think the backporter (and reviewer) should be responsible to apply the first line of filtering. But this brings up an interesting point, we rarely discuss patches, your proposal seems to be a step in the right direction since it forces maintainer's attention earlier, but I think there's an element of planification still missing, also, we don't want to overload the mantainer's time, this needs to be a share effort from the ground up. Regarding the backporting in general, I do think we're backporting too much, I think we had a slowdown in 8u which is good, but 11u is still getting a lot of attention, we should slow the pace there too, imho. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From aph at redhat.com Tue Sep 8 13:18:17 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Sep 2020 14:18:17 +0100 Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com> <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com> Message-ID: <9ffe38f1-85dc-c2fd-613f-3a97f7354a32@redhat.com> On 08/09/2020 13:01, Lindenmaier, Goetz wrote: > One possibility to watch what Oracle is doing is that maintainers have > an eye on the according filters of 11.0.x-oracle changes and flag them > jdk11u-fix-no ad-hoc, before someone starts to actually work and > downport the bug. Looks good to me. But we'd first have to agree on the principle of not backporting some patches, and the criteria by which we'd decide. -- 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 Tue Sep 8 14:30:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 15:30:39 +0100 Subject: [11u] RFR: JDK-8252258: JDK-8242154 changes the default vendor In-Reply-To: References: <20200903031944.GA1438092@stopbrexit> Message-ID: <20200908143039.GB1846517@stopbrexit> On 02:43 Mon 07 Sep , Langer, Christoph wrote: > Hi Andrew, > > thanks for spotting this and creating the fix. > > While I think, N/A is the better default for OpenJDK, compared to Oracle Corporation, I have to admit that that's not something that should be changed during a release lifecycle. So, LGTM. And, I agree, this should go into 11.0.9. > > Cheers > Christoph > Thanks for the review. I agree N/A is the right change for future JDKs (14 and up), but yes, changing it in a release JDK caused some surprise here, as we've tended to rely on these defaults for maximum compatibility. I'll flag with jdk11u-critical-request. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From gnu.andrew at redhat.com Tue Sep 8 16:57:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Sep 2020 17:57:26 +0100 Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: References: Message-ID: <20200908165726.GH1846517@stopbrexit> On 09:31 Mon 31 Aug , Langer, Christoph wrote: > Hi, > > may I please have a review for the backport of test fix JDK-8151678 "com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect" as follow-up for JDK-8160768 (Add capability to custom resolve host/domain names within the default JNDI LDAP provider). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8151678 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/1def54255e93 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8151678.11u.0/ > > I had the following Rejects: > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.java: > needed manual resolve, also copyright year was different > LdapDnsProviderService.java: > File is in a different location in 11u, so I needed to manually resolve it: > java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java -> jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderService.java > ProblemList.txt: > Needed a manual resolve > > Thanks > Christoph > The only reason the copyright years were different here is because, for some reason, they were altered in the backport of JDK-8160768. This, in turn, has caused some confusion in reviewing this patch for 8u [0] [1], because the copyright changes are needed in 15u & 8u, but not 11u. Can we please not include additional changes in backports, unless necessary? [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012634.html [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-September/012651.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From shade at redhat.com Wed Sep 9 07:10:49 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 9 Sep 2020 09:10:49 +0200 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints Message-ID: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8249192 https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d 15u variant: https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, where removed "ResourceMark rm" does not have "current_thread" argument yet. It was added later with JDK-8247729: https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 Testing: tier{1,2} with and without Shenandoah [which seems to find some of these bugs] -- Thanks, -Aleksey From aph at redhat.com Wed Sep 9 08:23:41 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Sep 2020 09:23:41 +0100 Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: <9ffe38f1-85dc-c2fd-613f-3a97f7354a32@redhat.com> References: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com> <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com> <9ffe38f1-85dc-c2fd-613f-3a97f7354a32@redhat.com> Message-ID: On 08/09/2020 14:18, Andrew Haley wrote: > On 08/09/2020 13:01, Lindenmaier, Goetz wrote: >> One possibility to watch what Oracle is doing is that maintainers have >> an eye on the according filters of 11.0.x-oracle changes and flag them >> jdk11u-fix-no ad-hoc, before someone starts to actually work and >> downport the bug. > > Looks good to me. But we'd first have to agree on the principle of > not backporting some patches, and the criteria by which we'd decide. Thinking about this some more: it really should be a reviewer's job to object if a patch is likely to fail a risk-vs-reward test. Every patch should be considered carefully in this way. It's hard for inexperienced contributors to be able to make such judgements, so they should ask on the list if it isn't clear. But we can say this much: crashes and Java language specification failures will always qualify for fixes; performance improvements, especially small performance improvements, not so much. Compatibility bugs which break communications protocols must be fixed. Updates for new versions of communication protocols and new ciphers, probably. There's a wide grey area in between, it's true. -- 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 adinn at redhat.com Wed Sep 9 09:38:29 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 9 Sep 2020 10:38:29 +0100 Subject: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: <17a295cc-cea0-8534-f5bb-f667376e81d4@redhat.com> <4137e474-cf95-b380-1fd5-ca71f1313d22@redhat.com> <9ffe38f1-85dc-c2fd-613f-3a97f7354a32@redhat.com> Message-ID: On 09/09/2020 09:23, Andrew Haley wrote: > Thinking about this some more: it really should be a reviewer's job to > object if a patch is likely to fail a risk-vs-reward test. Every patch > should be considered carefully in this way. It's hard for > inexperienced contributors to be able to make such judgements, so they > should ask on the list if it isn't clear. I agree. Indeed, I have already been doing that for some of the more complex patches. Another couple of things that should really be agreed between the backporter and a reviewer when a patch is complex or has wider-reaching side-effects than jst fixing the bug itself is whether 1) to limit the backport to some subset of the upstream change or even 2) to come up with a custom change that fixes the problem in a different way. That may involve the backporter asking for an early review of a preliminary patch. There's /nothing wrong/ with doing that. > But we can say this much: crashes and Java language specification > failures will always qualify for fixes; performance improvements, > especially small performance improvements, not so much. Compatibility > bugs which break communications protocols must be fixed. Updates for > new versions of communication protocols and new ciphers, probably. > > There's a wide grey area in between, it's true. Yes, and that is where reviewers can and should be brought in to help clarify things. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From goetz.lindenmaier at sap.com Wed Sep 9 15:49:22 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Sep 2020 15:49:22 +0000 Subject: [11u] Sconpe of Review ... was RFR(S): 8241234: Unify monitor enter/exit runtime entries. Message-ID: Hi, It is pointless to ask reviewers to judge the risk because reviews are only done if the change had to be adapted. There are complex changes that just apply clean and thus are downported without review. Judging the risk is clearly a thing of the downporter. This is formulated in Rule 1 of Oracles's Updates description : http://openjdk.java.net/projects/jdk-updates/approval.html , and also mentioned in step 6 of jdk11us description: https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix This is supposed to help the maintainer to decide about the risk. The major task of the review is to make sure the downported change is correct, i.e. has the same effect on 11 as the original one. Nevertheless, if there is a reviewer and he feels bad about a change, he should communicate his concerns! Best regards, Goetz. > -----Original Message----- > From: Andrew Dinn > Sent: Wednesday, September 9, 2020 11:38 AM > To: Andrew Haley ; Lindenmaier, Goetz > ; Doerr, Martin ; > 'Severin Gehwolf' ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Cc: Langer, Christoph > Subject: Re: [11u] RFR(S): 8241234: Unify monitor enter/exit runtime entries. > > On 09/09/2020 09:23, Andrew Haley wrote: > > Thinking about this some more: it really should be a reviewer's job to > > object if a patch is likely to fail a risk-vs-reward test. Every patch > > should be considered carefully in this way. It's hard for > > inexperienced contributors to be able to make such judgements, so they > > should ask on the list if it isn't clear. > > I agree. Indeed, I have already been doing that for some of the more > complex patches. > > Another couple of things that should really be agreed between the > backporter and a reviewer when a patch is complex or has wider-reaching > side-effects than jst fixing the bug itself is whether 1) to limit the > backport to some subset of the upstream change or even 2) to come up > with a custom change that fixes the problem in a different way. That may > involve the backporter asking for an early review of a preliminary > patch. There's /nothing wrong/ with doing that. > > > But we can say this much: crashes and Java language specification > > failures will always qualify for fixes; performance improvements, > > especially small performance improvements, not so much. Compatibility > > bugs which break communications protocols must be fixed. Updates for > > new versions of communication protocols and new ciphers, probably. > > > > There's a wide grey area in between, it's true. > Yes, and that is where reviewers can and should be brought in to help > clarify things. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Wed Sep 9 16:04:50 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Sep 2020 17:04:50 +0100 Subject: [11u] Sconpe of Review ... was RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: Message-ID: <876ec4a1-0228-6c4d-b6eb-c8c67d442ef7@redhat.com> On 09/09/2020 16:49, Lindenmaier, Goetz wrote: > It is pointless to ask reviewers to judge the risk > because reviews are only done if the change had to be adapted. That's an excellent point. In such a case, approvals are the only time risk is considered. However, if a patch applies cleanly I suppose it's probably less risky. Although in some cases that in't true. > There are complex changes that just apply clean and thus are > downported without review. > > Judging the risk is clearly a thing of the downporter. This is > formulated in Rule 1 of Oracles's Updates description : > http://openjdk.java.net/projects/jdk-updates/approval.html , and > also mentioned in step 6 of jdk11us description: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > This is supposed to help the maintainer to decide about the risk. Yes, of course the person doing the porting must consider the risk. But so should the person reviewing it. > The major task of the review is to make sure the downported change > is correct, i.e. has the same effect on 11 as the original one.# I disagree. Just like a review of a change to head, the reviewer must consider whether the justification put forward by the submitter is sufficient. > Nevertheless, if there is a reviewer and he feels bad about a > change, he should communicate his concerns! Yes, that should happen. It's everybody's duty, all the time, to consider risk. We owe our users no less than that. -- 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 joserz at linux.ibm.com Wed Sep 9 16:37:33 2020 From: joserz at linux.ibm.com (joserz at linux.ibm.com) Date: Wed, 9 Sep 2020 13:37:33 -0300 Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new byte-reverse instructions Message-ID: <20200909163733.GA422344@pacoca> Hello team! I'd like to backport the following patchset to 11u. It doesn't apply perfectly due to some positional changes and a copyright update. Please, let me know if you prefer another webrev addressing this backport. Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8248190 Thank you very much, Jose R Ziviani From adinn at redhat.com Thu Sep 10 09:46:26 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 10 Sep 2020 10:46:26 +0100 Subject: [11u] Sconpe of Review ... was RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: Message-ID: <835d5832-04a6-cbf5-7a7f-6495abf8658f@redhat.com> On 09/09/2020 16:49, Lindenmaier, Goetz wrote: > It is pointless to ask reviewers to judge the risk > because reviews are only done if the change had to be adapted. > There are complex changes that just apply clean and thus are > downported without review. I think you have very much overstated your case in that opening line. If a patch needs adapting in anything other than a trivial manner then it cannot be a bad thing for the reviewer to consider the risk involved. That benefit cannot be removed by the fact that some changes bypass the review process. It might be diminished, of course. But by the same token, if a complex patch does not need adapting then it might still be a good thing for the maintainer who is going to approve or disapprove it to consider the risk. Indeed, I hope that this consideration is foremost in the maintainers' minds. Either way, it's far from /pointless/ for reviewers or maintainers to consider risks and where they think it important negotiate the details with the downporter. Likewise if the downporter is unsure then they really ought to initiate such a dialogue. Such actiuon might well be redundant in many cases but I am sure those will be easy to spot. > Judging the risk is clearly a thing of the downporter. This is formulated > in Rule 1 of Oracles's Updates > description : http://openjdk.java.net/projects/jdk-updates/approval.html , > and also mentioned in step 6 of jdk11us description: > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > This is supposed to help the maintainer to decide about the risk. That would be fine if every downporter was happy and able to make the assessment. However, there are definitely going to be cases where that is not so. I'm not sure why you are stating the requirements here in such absolute terms. Note that in my previous post I did not recommend that /all/ responsibility be shifted to the reviewer or maintainer. I recommended that reviewers consider helping downporters with complex backports, including those that might benefit from trimming or re-implementing a fix. > The major task of the review is to make sure the downported change > is correct, i.e. has the same effect on 11 as the original one. > Nevertheless, if there is a reviewer and he feels bad about a > change, he should communicate his concerns! I think it is misguided to separate the decision as to correctness from concerns over the risk associated with a change. My experience is that cases where it is hard to foresee all the consequences of downporting a change are far from rare. For a lot of complex changes -- and even some simple ones -- a 100% foolproof assessment of correctness is never going to be available. In such cases the risk of breaking something really ought to be factored in by the reviewer because s/he can only speak to the /likely/ correctness (as opposed to /absolute/ correctness) of the patch. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From martin.doerr at sap.com Thu Sep 10 09:54:04 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 10 Sep 2020 09:54:04 +0000 Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new byte-reverse instructions In-Reply-To: <20200909163733.GA422344@pacoca> References: <20200909163733.GA422344@pacoca> Message-ID: Hi Jose, if manual adaptation/integration is needed we also need to review the backport webrev (except trivial differences like in copyright headers). Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of joserz at linux.ibm.com > Sent: Mittwoch, 9. September 2020 18:38 > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net > Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new > byte-reverse instructions > > Hello team! > > I'd like to backport the following patchset to 11u. It doesn't apply perfectly > due to some positional changes and a copyright update. > Please, let me know if you prefer another webrev addressing this backport. > > Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8248190 > > Thank you very much, > > Jose R Ziviani From zgu at redhat.com Thu Sep 10 13:52:09 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 10 Sep 2020 09:52:09 -0400 Subject: [11u] RFR 8250665: Wrong translation for the month name of May in ar_JO,LB,SY Message-ID: I would like to backport this patch to 11u for parity with Oracle 11.0.10. The original patch does not apply cleanly. But conflicts are only limited to Copyright and bug Id lines of LocaleDataTest.java. The original bug: https://bugs.openjdk.java.net/browse/JDK-8250665 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9aa999666ccc 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8250665-11u/webrev.00/ Test: jdk_text Thanks, -Zhengyu From suenaga at oss.nttdata.com Fri Sep 11 00:25:41 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Sep 2020 09:25:41 +0900 Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host OS In-Reply-To: <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com> References: <4a75d2b8-7980-a90b-8142-333c402ea0da@gmail.com> <6a36d15f-07f3-a895-ed1a-06e872396d80@oss.nttdata.com> <56fd7f5f-a610-5699-a5aa-c119756d2023@oss.nttdata.com> Message-ID: <97fdf61a-06d4-1fdd-d028-561cea7f965e@oss.nttdata.com> Hi all, I think this change for 11u is ready to review. I haven't heard any problems on jdk/jdk. Could you review it? >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>> Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>> webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK-8250598/jdk11u/webrev.00/ Thanks, Yasumasa On 2020/08/31 20:02, Yasumasa Suenaga wrote: > Hi Christoph, > > JDK 11 is LTS version, so we might see hs_err logs which relates to this fix in production system. It is the reason why I want to backport it to 11.0.9 if possible. > > OTOH it is not so critical and JDK 11 will enter rampdown, I understand that we have to be careful. > I will comply the timing when "jdk11u-fix-yes" is added to JBS. > > > Thanks, > > Yasumasa > > > On 2020/08/31 19:04, Langer, Christoph wrote: >> Hi Yasumasa, >> >> is there any specific reason why it should be part of 11.0.9? >> >> Without having more detailed knowledge of the matter, I'd say it's cautious enough to postpone this backport to 11.0.10, given that we're about to enter rampdown... >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: jdk-updates-dev On >>> Behalf Of Yasumasa Suenaga >>> Sent: Freitag, 28. August 2020 10:02 >>> To: Baesken, Matthias ; Yasumasa Suenaga >>> ; jdk-updates-dev at openjdk.java.net >>> Subject: Re: [11u] RFR: 8250598: Hyper-V is detected in spite of running on >>> host OS >>> >>> Hi Matthias, >>> >>> On 2020/08/28 16:22, Baesken, Matthias wrote: >>>> Hi Yasumasa ,I suggest to let the? change? "rest"? in? jdk/jdk for? a couple of >>> weeks? before? going for downports . >>>> (not saying that downporting it is a bad thing) >>> >>> I understand what you say, but I want to backport it to 11.0.9 if possible. >>> 11.0.9 will enter rampdown in 1 Sep... >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Best regards, Matthias >>>> >>>> -----Original Message----- >>>> From: Yasumasa Suenaga >>>> Sent: Freitag, 28. August 2020 02:55 >>>> To: jdk-updates-dev at openjdk.java.net >>>> Cc: Baesken, Matthias >>>> Subject: [11u] RFR: 8250598: Hyper-V is detected in spite of running on host >>> OS >>>> >>>> Hi all, >>>> >>>> Please approve backport of JDK-8250598: >>>> >>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8250598 >>>> ????? Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/80c95309a924 >>>> ????? webrev for 11u: http://cr.openjdk.java.net/~ysuenaga/JDK- >>> 8250598/jdk11u/webrev.00/ >>>> >>>> The patch does not apply cleanly on 11u due to additional enhancements to >>> x86 / x86_64 processors. >>>> So I've prepared another webrev for 11u. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> From joserz at linux.ibm.com Fri Sep 11 01:20:40 2020 From: joserz at linux.ibm.com (joserz at linux.ibm.com) Date: Thu, 10 Sep 2020 22:20:40 -0300 Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new byte-reverse instructions In-Reply-To: References: <20200909163733.GA422344@pacoca> Message-ID: <20200911012040.GA518622@pacoca> Hello Martin, Here is my new webrev. https://cr.openjdk.java.net/~mhorie/8248190/jdk11u/webrev.00/ (Thanks again, Michi) 8<---------------------------------------------------------------------- Some evidences in a Power10 emulator: $ openjdk/jdk11u-dev/build/jdk/bin/java -Xcomp -XX:CompileThreshold=1 -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintOptoAssembly -XX:-UseSIGTRAP -XX:+UseByteReverseInstructions ReverseBytes | grep 'BRD\|BRH\|BRW\|EXTSH' ... 054 BRW R17, R18 070 BRD R14, R14 080 BRH R14, R15 EXTSH R14, R14 0a0 BRH R17, R15 $ openjdk/jdk11u-dev/build/jdk/bin/java -XX:+Verbose -XX:PowerArchitecturePPC64=10 -version dscr value was 0x10 Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes vpmsumb mfdscr vsx ldbrx stdbrx sha darn brw L1_data_cache_line_size=128 ContendedPaddingWidth 128 openjdk version "11.0.10-internal" 2021-01-19 OpenJDK Runtime Environment (slowdebug build 11.0.10-internal+0-adhoc.ziviani.jdk11u-dev) OpenJDK 64-Bit Server VM (slowdebug build 11.0.10-internal+0-adhoc.ziviani.jdk11u-dev, mixed mode) 8<---------------------------------------------------------------------- Thank you very much! Jose On Thu, Sep 10, 2020 at 09:54:04AM +0000, Doerr, Martin wrote: > Hi Jose, > > if manual adaptation/integration is needed we also need to review the backport webrev (except trivial differences like in copyright headers). > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of joserz at linux.ibm.com > > Sent: Mittwoch, 9. September 2020 18:38 > > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > dev at openjdk.java.net > > Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new > > byte-reverse instructions > > > > Hello team! > > > > I'd like to backport the following patchset to 11u. It doesn't apply perfectly > > due to some positional changes and a copyright update. > > Please, let me know if you prefer another webrev addressing this backport. > > > > Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248190 > > > > Thank you very much, > > > > Jose R Ziviani From goetz.lindenmaier at sap.com Fri Sep 11 06:05:54 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 11 Sep 2020 06:05:54 +0000 Subject: [11u] Sconpe of Review ... was RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: <835d5832-04a6-cbf5-7a7f-6495abf8658f@redhat.com> References: <835d5832-04a6-cbf5-7a7f-6495abf8658f@redhat.com> Message-ID: Hi Andrew, Sorry I didn't mean to offend you. But this thread is about optimizing the rules for changes Oracle downported to 11. The majority of these changes are not reviewed. See the example I assembled below. So I just wanted to point to the existing rules, which say the maintainer must judge the risk. This is a mandatory step in the process. A review is not mandatory. Obviously, any useful input is welcome to make the decision of the maintainer more easy, or to spot overseen risks. The point of this discussion here is under which criteria Oracle changes should not be downported, see also Andrew H's last post: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003785.html Best regards, Goetz. I checked a snapshot of 19 changes I did for 11.0.9 (see below): 12 applied clean. 3 had a review because of Copyright/context conflicts. 4 had a review because I had to touch code. clean https://bugs.openjdk.java.net/browse/JDK-8248472: javax/management/MBeanServer/OldMBeanServerTest fails with AssertionError code https://bugs.openjdk.java.net/browse/JDK-8248471: [aarch64] assert(false) failed: wrong size of mach node code https://bugs.openjdk.java.net/browse/JDK-8248469: java.net HTTP/2 client does not decrease stream count when receives 204 response clean https://bugs.openjdk.java.net/browse/JDK-8248229: 2020-04-24 public suffix list update v ff6fcea code, relevant https://bugs.openjdk.java.net/browse/JDK-8248213: TestEliminateArrayCopy fails with -XX:+StressReflectiveCode clean https://bugs.openjdk.java.net/browse/JDK-8248210: TestClone crashes with "all collected exceptions must come from the same place" clean https://bugs.openjdk.java.net/browse/JDK-8248209: C1 assert(known_holder == NULL || (known_holder->is_instance_klass() && (!known_holder->is_interface() ... copyright https://bugs.openjdk.java.net/browse/JDK-8248208: Possible NPE in ENC-PA-REP search in AS-REQ clean https://bugs.openjdk.java.net/browse/JDK-8248207: Minimal fastdebug build broken after JDK-8245801 clean https://bugs.openjdk.java.net/browse/JDK-8248206: StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!" clean https://bugs.openjdk.java.net/browse/JDK-8248204: Enhance BaseLdapServer to support starttls extended request clean https://bugs.openjdk.java.net/browse/JDK-8248203: [macos] macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs context https://bugs.openjdk.java.net/browse/JDK-8248202: Jconsole can't connect to itself clean https://bugs.openjdk.java.net/browse/JDK-8248201: java.rmi.NoSuchObjectException: no such object in table clean https://bugs.openjdk.java.net/browse/JDK-8248197: Choose the default SecureRandom algo based on registration ordering clean https://bugs.openjdk.java.net/browse/JDK-8248196: SSLSocket.getSession() doesn't close connection for timeout/ interrupts context https://bugs.openjdk.java.net/browse/JDK-8248141: HttpConnection not returned to the pool after 204 response code https://bugs.openjdk.java.net/browse/JDK-8246690: Tools should warn if weak algorithms are used before restricting them clean https://bugs.openjdk.java.net/browse/JDK-8248002: Test javax/swing/border/TestTitledBorderLeak.java should be marked as headful > -----Original Message----- > From: Andrew Dinn > Sent: Thursday, September 10, 2020 11:46 AM > To: Lindenmaier, Goetz ; Andrew Haley > ; Doerr, Martin ; 'Severin > Gehwolf' ; 'hotspot-compiler- > dev at openjdk.java.net' ; jdk- > updates-dev at openjdk.java.net > Cc: Langer, Christoph > Subject: Re: [11u] Sconpe of Review ... was RFR(S): 8241234: Unify monitor > enter/exit runtime entries. > > On 09/09/2020 16:49, Lindenmaier, Goetz wrote: > > It is pointless to ask reviewers to judge the risk > > because reviews are only done if the change had to be adapted. > > There are complex changes that just apply clean and thus are > > downported without review. > > I think you have very much overstated your case in that opening line. If > a patch needs adapting in anything other than a trivial manner then it > cannot be a bad thing for the reviewer to consider the risk involved. > That benefit cannot be removed by the fact that some changes bypass the > review process. > > It might be diminished, of course. But by the same token, if a complex > patch does not need adapting then it might still be a good thing for the > maintainer who is going to approve or disapprove it to consider the > risk. Indeed, I hope that this consideration is foremost in the > maintainers' minds. > > Either way, it's far from /pointless/ for reviewers or maintainers to > consider risks and where they think it important negotiate the details > with the downporter. Likewise if the downporter is unsure then they > really ought to initiate such a dialogue. Such actiuon might well be > redundant in many cases but I am sure those will be easy to spot. > > > Judging the risk is clearly a thing of the downporter. This is formulated > > in Rule 1 of Oracles's Updates > > description : http://openjdk.java.net/projects/jdk-updates/approval.html , > > and also mentioned in step 6 of jdk11us description: > > > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > This is supposed to help the maintainer to decide about the risk. > > That would be fine if every downporter was happy and able to make the > assessment. However, there are definitely going to be cases where that > is not so. > > I'm not sure why you are stating the requirements here in such absolute > terms. Note that in my previous post I did not recommend that /all/ > responsibility be shifted to the reviewer or maintainer. I recommended > that reviewers consider helping downporters with complex backports, > including those that might benefit from trimming or re-implementing a fix. > > > The major task of the review is to make sure the downported change > > is correct, i.e. has the same effect on 11 as the original one. > > Nevertheless, if there is a reviewer and he feels bad about a > > change, he should communicate his concerns! > I think it is misguided to separate the decision as to correctness from > concerns over the risk associated with a change. My experience is that > cases where it is hard to foresee all the consequences of downporting a > change are far from rare. For a lot of complex changes -- and even some > simple ones -- a 100% foolproof assessment of correctness is never going > to be available. In such cases the risk of breaking something really > ought to be factored in by the reviewer because s/he can only speak to > the /likely/ correctness (as opposed to /absolute/ correctness) of the > patch. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Fri Sep 11 09:57:13 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Sep 2020 10:57:13 +0100 Subject: [11u] Sconpe of Review ... was RFR(S): 8241234: Unify monitor enter/exit runtime entries. In-Reply-To: References: <835d5832-04a6-cbf5-7a7f-6495abf8658f@redhat.com> Message-ID: <4a14cee1-1457-dbe9-48e5-5bcfab4b467e@redhat.com> Hi Goetz, On 11/09/2020 07:05, Lindenmaier, Goetz wrote: > Sorry I didn't mean to offend you. Of course. I never thought otherwise and I certainly was not offended by anything you said. > But this thread is about optimizing the rules for > changes Oracle downported to 11. The majority of > these changes are not reviewed. See the example > I assembled below. > So I just wanted to point to the existing rules, which > say the maintainer must judge the risk. This is a > mandatory step in the process. A review is not > mandatory. > > Obviously, any useful input is welcome to make > the decision of the maintainer more easy, or to > spot overseen risks. I was not clear that this was your original position, specifically because of these words: "It is pointless to ask reviewers to judge the risk . . ." "Judging the risk is clearly a thing of the downporter. This is formulated in Rule 1 of Oracles's Updates . . ." It seems we are both in agreement that downporters, reviewers and maintainers all have a part to play and that any doubt is best addressed through open discussion an negotiation. > The point of this discussion here is under which > criteria Oracle changes should not be downported, see > also Andrew H's last post: > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003785.html Yes, I understood that. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From martin.doerr at sap.com Fri Sep 11 12:26:09 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 11 Sep 2020 12:26:09 +0000 Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use new byte-reverse instructions In-Reply-To: <20200911012040.GA518622@pacoca> References: <20200909163733.GA422344@pacoca> <20200911012040.GA518622@pacoca> Message-ID: Hi Jose, looks good. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: joserz at linux.ibm.com > Sent: Freitag, 11. September 2020 03:21 > To: Doerr, Martin > Cc: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > dev at openjdk.java.net; HORIE at jp.ibm.com > Subject: Re: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > new byte-reverse instructions > > Hello Martin, > > Here is my new webrev. > https://cr.openjdk.java.net/~mhorie/8248190/jdk11u/webrev.00/ > (Thanks again, Michi) > > 8<---------------------------------------------------------------------- > Some evidences in a Power10 emulator: > $ openjdk/jdk11u-dev/build/jdk/bin/java -Xcomp -XX:CompileThreshold=1 - > XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions - > XX:+PrintOptoAssembly -XX:-UseSIGTRAP -XX:+UseByteReverseInstructions > ReverseBytes | grep 'BRD\|BRH\|BRW\|EXTSH' > ... > 054 BRW R17, R18 > 070 BRD R14, R14 > 080 BRH R14, R15 > EXTSH R14, R14 > 0a0 BRH R17, R15 > > $ openjdk/jdk11u-dev/build/jdk/bin/java -XX:+Verbose - > XX:PowerArchitecturePPC64=10 -version > dscr value was 0x10 > Version: ppc64 fsqrt isel lxarxeh cmpb popcntb popcntw fcfids vand lqarx aes > vpmsumb mfdscr vsx ldbrx stdbrx sha darn brw > L1_data_cache_line_size=128 > > ContendedPaddingWidth 128 > > openjdk version "11.0.10-internal" 2021-01-19 > OpenJDK Runtime Environment (slowdebug build 11.0.10-internal+0- > adhoc.ziviani.jdk11u-dev) > OpenJDK 64-Bit Server VM (slowdebug build 11.0.10-internal+0- > adhoc.ziviani.jdk11u-dev, mixed mode) > 8<---------------------------------------------------------------------- > > Thank you very much! > > Jose > > On Thu, Sep 10, 2020 at 09:54:04AM +0000, Doerr, Martin wrote: > > Hi Jose, > > > > if manual adaptation/integration is needed we also need to review the > backport webrev (except trivial differences like in copyright headers). > > > > Best regards, > > Martin > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of joserz at linux.ibm.com > > > Sent: Mittwoch, 9. September 2020 18:38 > > > To: hotspot-compiler-dev at openjdk.java.net; jdk-updates- > > > dev at openjdk.java.net > > > Subject: [11u] RFR(M): 8248190: PPC: Enable Power10 system and use > new > > > byte-reverse instructions > > > > > > Hello team! > > > > > > I'd like to backport the following patchset to 11u. It doesn't apply > perfectly > > > due to some positional changes and a copyright update. > > > Please, let me know if you prefer another webrev addressing this > backport. > > > > > > Webrev: https://cr.openjdk.java.net/~mhorie/8248190/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248190 > > > > > > Thank you very much, > > > > > > Jose R Ziviani From shade at redhat.com Mon Sep 14 07:29:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 Sep 2020 09:29:14 +0200 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> Message-ID: <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> On 9/9/20 9:10 AM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8249192 > https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d > > 15u variant: > https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ > > It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, where removed "ResourceMark rm" > does not have "current_thread" argument yet. It was added later with JDK-8247729: > https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 > > Testing: tier{1,2} with and without Shenandoah [which seems to find some of these bugs] Um. I see there is a "backport" to 15.0.2 already: https://bugs.openjdk.java.net/browse/JDK-8251485 ...yet there is no changeset at all: https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251485 What's up with that? Rob, Thomas? -- Thanks, -Aleksey From david.holmes at oracle.com Mon Sep 14 07:51:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Sep 2020 17:51:01 +1000 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> Message-ID: <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> Hi Aleksey, On 14/09/2020 5:29 pm, Aleksey Shipilev wrote: > On 9/9/20 9:10 AM, Aleksey Shipilev wrote: >> Original bug: >> ??? https://bugs.openjdk.java.net/browse/JDK-8249192 >> ??? https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d >> >> 15u variant: >> ??? https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ >> >> It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, >> where removed "ResourceMark rm" >> does not have "current_thread" argument yet. It was added later with >> JDK-8247729: >> ??? https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 >> >> Testing: tier{1,2} with and without Shenandoah [which seems to find >> some of these bugs] > > Um. > > I see there is a "backport" to 15.0.2 already: > ? https://bugs.openjdk.java.net/browse/JDK-8251485 > > ...yet there is no changeset at all: > ? https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251485 > > What's up with that? Rob, Thomas? I think an oversight on our (Oracle) end. It went into the 15u CPU repo instead of the open repo. David ----- From shade at redhat.com Mon Sep 14 07:55:09 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 Sep 2020 09:55:09 +0200 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> Message-ID: <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> On 9/14/20 9:51 AM, David Holmes wrote: > Hi Aleksey, > > On 14/09/2020 5:29 pm, Aleksey Shipilev wrote: >> On 9/9/20 9:10 AM, Aleksey Shipilev wrote: >>> Original bug: >>> ??? https://bugs.openjdk.java.net/browse/JDK-8249192 >>> ??? https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d >>> >>> 15u variant: >>> ??? https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ >>> >>> It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, >>> where removed "ResourceMark rm" >>> does not have "current_thread" argument yet. It was added later with >>> JDK-8247729: >>> ??? https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 >>> >>> Testing: tier{1,2} with and without Shenandoah [which seems to find >>> some of these bugs] >> >> Um. >> >> I see there is a "backport" to 15.0.2 already: >> ? https://bugs.openjdk.java.net/browse/JDK-8251485 >> >> ...yet there is no changeset at all: >> ? https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251485 >> >> What's up with that? Rob, Thomas? > > I think an oversight on our (Oracle) end. It went into the 15u CPU repo > instead of the open repo. Ah. Well, I can push my versions of 8249192 (once reviewed here) and 8251118 to jdk-updates/jdk15u then. But it would be nice if someone from Oracle would compare the 8249192 changeset above with what is pushed to 15u CPU repo. -- Thanks, -Aleksey From per.liden at oracle.com Mon Sep 14 08:24:17 2020 From: per.liden at oracle.com (Per Liden) Date: Mon, 14 Sep 2020 10:24:17 +0200 Subject: [11u] RFR (XS) 8251949: ZGC: Set explicit heap size for compiler/gcbarriers tests In-Reply-To: <7263b7a2-7d5c-bd4c-0987-77a4a1b9715f@redhat.com> References: <7263b7a2-7d5c-bd4c-0987-77a4a1b9715f@redhat.com> Message-ID: Looks good. /Per On 9/2/20 7:09 PM, Aleksey Shipilev wrote: > On 8/19/20 4:23 PM, Aleksey Shipilev wrote: >> 11u-specific bug: >> ??? https://bugs.openjdk.java.net/browse/JDK-8251949 >> >> I suggested doing that in jdk/jdk initially, and then backport, but >> Per suggested it is best to do >> in 11u specifically. >> >> 11u webrev: >> ??? https://cr.openjdk.java.net/~shade/8251949/webrev.11u.01/ > > Friendly reminder: the absence of this still makes at least mine tier1 > runs unclean. :) > From shade at redhat.com Mon Sep 14 08:25:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 14 Sep 2020 10:25:45 +0200 Subject: [11u] RFR (XS) 8251949: ZGC: Set explicit heap size for compiler/gcbarriers tests In-Reply-To: References: <7263b7a2-7d5c-bd4c-0987-77a4a1b9715f@redhat.com> Message-ID: <1fb2abc3-4b82-ab68-75af-2bd03c11787c@redhat.com> On 9/14/20 10:24 AM, Per Liden wrote: > Looks good. Thanks, tagged. -- Thanks, -Aleksey From martin.doerr at sap.com Mon Sep 14 09:57:01 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Sep 2020 09:57:01 +0000 Subject: [11u] RFR: 8248226: TestCloneAccessStressGCM fails with -XX:-ReduceBulkZeroing In-Reply-To: References: Message-ID: Hi G?tz, looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Donnerstag, 3. September 2020 15:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8248226: TestCloneAccessStressGCM fails > with -XX:-ReduceBulkZeroing > > Hi > > I am downporting this for parity with 11.0.10-oracle. > > I had to resolve due to different context. > > In the original, no offset is passed to AllocateNode::Ideal_allocation() > > > > http://cr.openjdk.java.net/~goetz/wr20/8248226-BulkZeroing- > jdk11/01/index.html > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8248226 > > https://hg.openjdk.java.net/jdk/jdk/rev/ae002489df78 > > > > Best regards, > > Goetz. From martin.doerr at sap.com Mon Sep 14 10:06:52 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Sep 2020 10:06:52 +0000 Subject: [11u] RFR: 8249672: Include microcode revision in features_string on x86 In-Reply-To: References: Message-ID: Hi G?tz, this looks like a helpful improvement for supporters. Backport looks good. Thanks, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Donnerstag, 3. September 2020 16:21 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8249672: Include microcode revision in > features_string on x86 > > Hi > > I am downporting this for parity with 11.0.10-oracle. > > The format string in vm_version_x86 if formatted differently in 11, > so I had to resolve. > I copied some of the line breaks from the source, it really makes > The code more readable. > > http://cr.openjdk.java.net/~goetz/wr20/8249672-x86_microcode_vers- > jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8249672 > https://hg.openjdk.java.net/jdk/jdk/rev/931c949e05e4 > > Best regards, > Goetz. From christoph.langer at sap.com Mon Sep 14 11:56:27 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 14 Sep 2020 11:56:27 +0000 Subject: [11u] RFR (S): 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect In-Reply-To: <20200908165726.GH1846517@stopbrexit> References: <20200908165726.GH1846517@stopbrexit> Message-ID: Hi Andrew, > > I had the following Rejects: > > > src/java.naming/share/classes/com/sun/jndi/ldap/DefaultLdapDnsProvider.j > ava: > > needed manual resolve, also copyright year was different > > LdapDnsProviderService.java: > > File is in a different location in 11u, so I needed to manually resolve it: > > > java.naming/share/classes/com/sun/jndi/ldap/LdapDnsProviderService.java > -> > jdk.naming.ldap/share/classes/com/sun/jndi/ldap/dns/LdapDnsProviderSer > vice.java > > ProblemList.txt: > > Needed a manual resolve > > > > Thanks > > Christoph > > > > The only reason the copyright years were different here is because, > for some reason, they were altered in the backport of JDK-8160768. > This, in turn, has caused some confusion in reviewing this patch for > 8u [0] [1], because the copyright changes are needed in 15u & 8u, but > not 11u. > > Can we please not include additional changes in backports, unless necessary? Well, I'm definitely a big fan of the policy of not altering backports in any way unless absolutely necessary. However, in the case of the backport of JDK-8160768, I had to add quite some significant amount of additional code and had to reshuffle things such that updating copyright years just seemed to be the correct thing to do here. Also, why would that cause confusion in the 8u backport of JDK- 8151678? Did you take the 11u change as the base? I recall that for JDK-8160768 the backport to 11u was significantly different to the backport for 8u and 8u seemed to be more in line with its original in head jdk/jdk. Cheers Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > September/012634.html > [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020- > September/012651.html From jaroslav.bachorik at datadoghq.com Mon Sep 14 13:33:09 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 14 Sep 2020 15:33:09 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> Message-ID: Gentle ping? On Thu, Sep 3, 2020 at 7:00 PM Jaroslav Bachor?k wrote: > > Hearing no objections, here is a new webrev: > http://cr.openjdk.java.net/~jbachorik/8250928/11u/01/webrev > > -JB- > > On Thu, Sep 3, 2020 at 3:04 PM Jaroslav Bachor?k > wrote: > > > > I have opened and fixed > > https://bugs.openjdk.java.net/browse/JDK-8252754 to do the hash code > > calculation consistently. > > > > I would prefer including both parts in one backport if possible. Any thoughts? > > > > Thanks, > > > > -JB- > > > > On Tue, Sep 1, 2020 at 12:57 PM Jaroslav Bachor?k > > wrote: > > > > > > On Tue, Sep 1, 2020 at 12:48 PM Aleksey Shipilev wrote: > > > > > > > > On 9/1/20 12:45 PM, Jaroslav Bachor?k wrote: > > > > > Perhaps, the mainline should be fixed to use the 'improved' > > > > > calculation in both places first? > > > > > > > > Yes, that would be my guess. The backport to both 8u and 11u does not look safe until that > > > > peculiarity is resolved, either by additional patch, or justification why it is fine. > > > > > > Yes. I totally agree. Thanks for catching this early! > > > > > > -JB- > > > > > > > > > > > -- > > > > Thanks, > > > > -Aleksey > > > > From goetz.lindenmaier at sap.com Mon Sep 14 13:41:22 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Sep 2020 13:41:22 +0000 Subject: [11u] RFR: 8248226: TestCloneAccessStressGCM fails with -XX:-ReduceBulkZeroing In-Reply-To: References: Message-ID: Thanks for reviewing! Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Monday, September 14, 2020 11:57 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8248226: TestCloneAccessStressGCM fails with -XX:- > ReduceBulkZeroing > > Hi G?tz, > > looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Donnerstag, 3. September 2020 15:51 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8248226: TestCloneAccessStressGCM fails > > with -XX:-ReduceBulkZeroing > > > > Hi > > > > I am downporting this for parity with 11.0.10-oracle. > > > > I had to resolve due to different context. > > > > In the original, no offset is passed to AllocateNode::Ideal_allocation() > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8248226-BulkZeroing- > > jdk11/01/index.html > > > > > > > > Please review. > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8248226 > > > > https://hg.openjdk.java.net/jdk/jdk/rev/ae002489df78 > > > > > > > > Best regards, > > > > Goetz. From goetz.lindenmaier at sap.com Mon Sep 14 13:42:38 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 14 Sep 2020 13:42:38 +0000 Subject: [11u] RFR: 8249672: Include microcode revision in features_string on x86 In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing. Best regard,s Goetz > -----Original Message----- > From: Doerr, Martin > Sent: Monday, September 14, 2020 12:07 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8249672: Include microcode revision in > features_string on x86 > > Hi G?tz, > > this looks like a helpful improvement for supporters. > Backport looks good. > > Thanks, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Donnerstag, 3. September 2020 16:21 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8249672: Include microcode revision in > > features_string on x86 > > > > Hi > > > > I am downporting this for parity with 11.0.10-oracle. > > > > The format string in vm_version_x86 if formatted differently in 11, > > so I had to resolve. > > I copied some of the line breaks from the source, it really makes > > The code more readable. > > > > http://cr.openjdk.java.net/~goetz/wr20/8249672-x86_microcode_vers- > > jdk11/01/ > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8249672 > > https://hg.openjdk.java.net/jdk/jdk/rev/931c949e05e4 > > > > Best regards, > > Goetz. From hohensee at amazon.com Mon Sep 14 21:25:00 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 14 Sep 2020 21:25:00 +0000 Subject: [11u] RFR/RFA (S): 8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11 Message-ID: <57006B95-0486-4160-BB65-AD36216608C9@amazon.com> Please review this patch and CSR for 11.0.9. If approved, I propose tagging the issue with jdk11u-critical-request. Bug: https://bugs.openjdk.java.net/browse/JDK-8253134 CSR: https://bugs.openjdk.java.net/browse/JDK-8253136 Webrev: http://cr.openjdk.java.net/~phh/8253134/webrev.11u.00/ JDK-8231209, which was originally pushed to JDK 14, has been backported to 11.0.9 and 11,0.10-oracle. Those backports changed JMM_VERSION from 0x20020000 (JDK 10) to 0x20030000 (JDK 14), which introduced an incompatibility that was overlooked in the backport CSRs JDK-8247807 (11.0.9) and JDK-8248871 (11.0.10-oracle). JDK 11 users checking for JMM_VERSION == 0x20020000 will find 0x2003000 instead and possibly abort. The issue was first noticed as part of reviewing a backport of JDK-8185003 to JDK 8: see the Description in the corresponding CSR JDK-8251498. For the reasons detailed there, JMM_VERSION in JDK 11 should be reverted to 0x20020000 (JDK 10), and the @since javadoc tag for com.sun.management.ThreadMXBean.getCurrentThreadAllocatedBytes should be changed from 14 to 11.0.9. If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282. Thanks, Paul From david.holmes at oracle.com Tue Sep 15 01:29:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Sep 2020 11:29:29 +1000 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> Message-ID: On 14/09/2020 5:55 pm, Aleksey Shipilev wrote: > On 9/14/20 9:51 AM, David Holmes wrote: >> Hi Aleksey, >> >> On 14/09/2020 5:29 pm, Aleksey Shipilev wrote: >>> On 9/9/20 9:10 AM, Aleksey Shipilev wrote: >>>> Original bug: >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8249192 >>>> ???? https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d >>>> >>>> 15u variant: >>>> ???? https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ >>>> >>>> It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, >>>> where removed "ResourceMark rm" >>>> does not have "current_thread" argument yet. It was added later with >>>> JDK-8247729: >>>> ???? https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 >>>> >>>> Testing: tier{1,2} with and without Shenandoah [which seems to find >>>> some of these bugs] >>> >>> Um. >>> >>> I see there is a "backport" to 15.0.2 already: >>> ? ? https://bugs.openjdk.java.net/browse/JDK-8251485 >>> >>> ...yet there is no changeset at all: >>> ? ? https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251485 >>> >>> What's up with that? Rob, Thomas? >> >> I think an oversight on our (Oracle) end. It went into the 15u CPU repo >> instead of the open repo. > > Ah. Well, I can push my versions of 8249192 (once reviewed here) and > 8251118 to jdk-updates/jdk15u then. But it would be nice if someone from > Oracle would compare the 8249192 changeset above with what is pushed to > 15u CPU repo. They are the same. Cheers, David From shade at redhat.com Tue Sep 15 08:28:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 15 Sep 2020 10:28:39 +0200 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> Message-ID: On 9/15/20 3:29 AM, David Holmes wrote: > On 14/09/2020 5:55 pm, Aleksey Shipilev wrote: >> On 9/14/20 9:51 AM, David Holmes wrote: >>> Hi Aleksey, >>> >>> On 14/09/2020 5:29 pm, Aleksey Shipilev wrote: >>>> On 9/9/20 9:10 AM, Aleksey Shipilev wrote: >>>>> Original bug: >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8249192 >>>>> ???? https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d >>>>> >>>>> 15u variant: >>>>> ???? https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ >>>>> >>>>> It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, >>>>> where removed "ResourceMark rm" >>>>> does not have "current_thread" argument yet. It was added later with >>>>> JDK-8247729: >>>>> ???? https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 >>>>> >>>>> Testing: tier{1,2} with and without Shenandoah [which seems to find >>>>> some of these bugs] >>>> >>>> Um. >>>> >>>> I see there is a "backport" to 15.0.2 already: >>>> ? ? https://bugs.openjdk.java.net/browse/JDK-8251485 >>>> >>>> ...yet there is no changeset at all: >>>> ? ? https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251485 >>>> >>>> What's up with that? Rob, Thomas? >>> >>> I think an oversight on our (Oracle) end. It went into the 15u CPU repo >>> instead of the open repo. >> >> Ah. Well, I can push my versions of 8249192 (once reviewed here) and >> 8251118 to jdk-updates/jdk15u then. But it would be nice if someone from >> Oracle would compare the 8249192 changeset above with what is pushed to >> 15u CPU repo. > > They are the same. Thanks, I'll count that as the backport review then. Added the fix-request with the synopsis of all this mess :) -- Thanks, -Aleksey From volker.simonis at gmail.com Tue Sep 15 15:39:30 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 15 Sep 2020 17:39:30 +0200 Subject: [11u] RFR/RFA (S): 8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11 In-Reply-To: <57006B95-0486-4160-BB65-AD36216608C9@amazon.com> References: <57006B95-0486-4160-BB65-AD36216608C9@amazon.com> Message-ID: On Mon, Sep 14, 2020 at 11:25 PM Hohensee, Paul wrote: > > Please review this patch and CSR for 11.0.9. If approved, I propose tagging the issue with jdk11u-critical-request. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253134 > CSR: https://bugs.openjdk.java.net/browse/JDK-8253136 > Webrev: http://cr.openjdk.java.net/~phh/8253134/webrev.11u.00/ > > JDK-8231209, which was originally pushed to JDK 14, has been backported to 11.0.9 and 11,0.10-oracle. Those backports changed JMM_VERSION from 0x20020000 (JDK 10) to 0x20030000 (JDK 14), which introduced an incompatibility that was overlooked in the backport CSRs JDK-8247807 (11.0.9) and JDK-8248871 (11.0.10-oracle). JDK 11 users checking for JMM_VERSION == 0x20020000 will find 0x2003000 instead and possibly abort. The issue was first noticed as part of reviewing a backport of JDK-8185003 to JDK 8: see the Description in the corresponding CSR JDK-8251498. > > For the reasons detailed there, JMM_VERSION in JDK 11 should be reverted to 0x20020000 (JDK 10), and the @since javadoc tag for com.sun.management.ThreadMXBean.getCurrentThreadAllocatedBytes should be changed from 14 to 11.0.9. If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282. > This all looks good to me. I've also reviewed and endorsed the CSR. I'm only not sure about the last sentence: "If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282". Not sure if we should really do that? If somebody reads that in jdk11u he could think that the change must be in 11.0.0 and later as well, but that's not true. If somebody reads it in the 8u282 API he might think the same (and that it is in 9 & 10 but those two are hopefully not used by anybody any more), and there's no way to fix that. But I'd personally leave it as 11.0.9 in jdk11u. Best regards, Volker > Thanks, > Paul > From hohensee at amazon.com Tue Sep 15 16:32:32 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 15 Sep 2020 16:32:32 +0000 Subject: [11u] RFR/RFA (S): 8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11 Message-ID: <28D8B85C-2850-426F-9D73-AFE81F644B2E@amazon.com> Thanks for the review, Volker. You're right, I'll delete that sentence. Paul ?On 9/15/20, 8:40 AM, "Volker Simonis" wrote: On Mon, Sep 14, 2020 at 11:25 PM Hohensee, Paul wrote: > > Please review this patch and CSR for 11.0.9. If approved, I propose tagging the issue with jdk11u-critical-request. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253134 > CSR: https://bugs.openjdk.java.net/browse/JDK-8253136 > Webrev: http://cr.openjdk.java.net/~phh/8253134/webrev.11u.00/ > > JDK-8231209, which was originally pushed to JDK 14, has been backported to 11.0.9 and 11,0.10-oracle. Those backports changed JMM_VERSION from 0x20020000 (JDK 10) to 0x20030000 (JDK 14), which introduced an incompatibility that was overlooked in the backport CSRs JDK-8247807 (11.0.9) and JDK-8248871 (11.0.10-oracle). JDK 11 users checking for JMM_VERSION == 0x20020000 will find 0x2003000 instead and possibly abort. The issue was first noticed as part of reviewing a backport of JDK-8185003 to JDK 8: see the Description in the corresponding CSR JDK-8251498. > > For the reasons detailed there, JMM_VERSION in JDK 11 should be reverted to 0x20020000 (JDK 10), and the @since javadoc tag for com.sun.management.ThreadMXBean.getCurrentThreadAllocatedBytes should be changed from 14 to 11.0.9. If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282. > This all looks good to me. I've also reviewed and endorsed the CSR. I'm only not sure about the last sentence: "If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282". Not sure if we should really do that? If somebody reads that in jdk11u he could think that the change must be in 11.0.0 and later as well, but that's not true. If somebody reads it in the 8u282 API he might think the same (and that it is in 9 & 10 but those two are hopefully not used by anybody any more), and there's no way to fix that. But I'd personally leave it as 11.0.9 in jdk11u. Best regards, Volker > Thanks, > Paul > From johnc at azul.com Tue Sep 15 17:06:34 2020 From: johnc at azul.com (John Cuthbertson) Date: Tue, 15 Sep 2020 17:06:34 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes In-Reply-To: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> References: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> Message-ID: Hi Vladimir, On Sep 3, 2020, at 5:28 AM, Vladimir Kempik > wrote: Hello Please review these backports of JDK-8209061:Move G1 serviceability functionality to G1MonitoringSupport and JDK-8209062:Clean up G1MonitoringSupport to jdk11u These backports are prerequestes for JDK-8207200 which we can see in the wild with jdk8 and jdk11. JDK-8209061 and JDK-8209062 applies mostly clean, very few places where it wasn?t clean due to surrounding code or code layout. after these two, JDK-8207200 applies cleanly. Testing: tier1. The webrevs: http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ This looks good to me and matches http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec. http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ This looks good to me also and matches http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046. All mentioned bugs: https://bugs.openjdk.java.net/browse/JDK-8209062 https://bugs.openjdk.java.net/browse/JDK-8209061 https://bugs.openjdk.java.net/browse/JDK-8207200 Original changesets: 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 Thanks, Vladimir Regards, JohnC From gnu.andrew at redhat.com Wed Sep 16 03:05:36 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 04:05:36 +0100 Subject: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 Message-ID: <20200916030536.GA248929@stopbrexit> Bug: https://bugs.openjdk.java.net/browse/JDK-8222286 Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.01/ On s390 (the 31-bit architecture), calls to log2_intptr with a size_t argument are ambiguous, because there is log2_intptr(uintptr_t x) and log2_intptr(intptr_t x). This is not a problem on other architectures where size_t is the same as uintptr_t. See existing bugs for more details of the s390 situation [0] [1] [2]. The issue can be resolved by explicitly casting to uintptr_t. It is not applicable to >= 12u, as JDK-8213436 removed the problematic function in which this occurs. Ok for 11u? [0] https://bugs.openjdk.java.net/browse/JDK-8203030 [1] https://bugs.openjdk.java.net/browse/JDK-8074459 [2] https://bugs.openjdk.java.net/browse/JDK-8046938 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From aph at redhat.com Wed Sep 16 08:27:21 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Sep 2020 09:27:21 +0100 Subject: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 In-Reply-To: <20200916030536.GA248929@stopbrexit> References: <20200916030536.GA248929@stopbrexit> Message-ID: <9c8c79d5-d52b-82c2-399a-2e03732cadfd@redhat.com> On 16/09/2020 04:05, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222286 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.01/ > > On s390 (the 31-bit architecture), calls to log2_intptr with a size_t > argument are ambiguous, because there is log2_intptr(uintptr_t x) and > log2_intptr(intptr_t x). This is not a problem on other architectures > where size_t is the same as uintptr_t. See existing bugs for > more details of the s390 situation [0] [1] [2]. > > The issue can be resolved by explicitly casting to uintptr_t. > > It is not applicable to >= 12u, as JDK-8213436 removed the problematic > function in which this occurs. > > Ok for 11u? Sure, but please add a comment. "S/390: Cast to (uintptr_t): see JDK-8222286" would do. Thanks. -- 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 volker.simonis at gmail.com Wed Sep 16 08:29:08 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 16 Sep 2020 10:29:08 +0200 Subject: [11u] RFR/RFA (S): 8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11 In-Reply-To: <28D8B85C-2850-426F-9D73-AFE81F644B2E@amazon.com> References: <28D8B85C-2850-426F-9D73-AFE81F644B2E@amazon.com> Message-ID: On Tue, Sep 15, 2020 at 6:32 PM Hohensee, Paul wrote: > > Thanks for the review, Volker. You're right, I'll delete that sentence. > Thanks! I saw you've deleted the sentence in the CSR so I deleted it in the bug as well. I've also added a "jdk11u-critical-request" label now that CSR has been approved. > Paul > > ?On 9/15/20, 8:40 AM, "Volker Simonis" wrote: > > On Mon, Sep 14, 2020 at 11:25 PM Hohensee, Paul wrote: > > > > Please review this patch and CSR for 11.0.9. If approved, I propose tagging the issue with jdk11u-critical-request. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253134 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8253136 > > Webrev: http://cr.openjdk.java.net/~phh/8253134/webrev.11u.00/ > > > > JDK-8231209, which was originally pushed to JDK 14, has been backported to 11.0.9 and 11,0.10-oracle. Those backports changed JMM_VERSION from 0x20020000 (JDK 10) to 0x20030000 (JDK 14), which introduced an incompatibility that was overlooked in the backport CSRs JDK-8247807 (11.0.9) and JDK-8248871 (11.0.10-oracle). JDK 11 users checking for JMM_VERSION == 0x20020000 will find 0x2003000 instead and possibly abort. The issue was first noticed as part of reviewing a backport of JDK-8185003 to JDK 8: see the Description in the corresponding CSR JDK-8251498. > > > > For the reasons detailed there, JMM_VERSION in JDK 11 should be reverted to 0x20020000 (JDK 10), and the @since javadoc tag for com.sun.management.ThreadMXBean.getCurrentThreadAllocatedBytes should be changed from 14 to 11.0.9. If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282. > > > > This all looks good to me. I've also reviewed and endorsed the CSR. > > I'm only not sure about the last sentence: "If/when the JDK-8231209 > backport to JDK 8 is approved for openjdk8u282, the @since tag should > be changed to 8u282". Not sure if we should really do that? If > somebody reads that in jdk11u he could think that the change must be > in 11.0.0 and later as well, but that's not true. > > If somebody reads it in the 8u282 API he might think the same (and > that it is in 9 & 10 but those two are hopefully not used by anybody > any more), and there's no way to fix that. But I'd personally leave it > as 11.0.9 in jdk11u. > > Best regards, > Volker > > > Thanks, > > Paul > > > From shade at redhat.com Wed Sep 16 09:57:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 16 Sep 2020 11:57:22 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> Message-ID: <9aeafa17-0eec-7db5-7983-507065ab67c7@redhat.com> On 9/3/20 7:00 PM, Jaroslav Bachor?k wrote: > Hearing no objections, here is a new webrev: > http://cr.openjdk.java.net/~jbachorik/8250928/11u/01/webrev Let's not diverge here? Better backport JDK-8252754 as the follow-up, and push JDK-8250928 (this one) and JDK-8252754 (follow-up) together. The first variant looks fine: http://cr.openjdk.java.net/~jbachorik/8250928/11u/webrev/ ...provided it it pushed along with JDK-8252754. -- Thanks, -Aleksey From christoph.langer at sap.com Wed Sep 16 12:01:03 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 16 Sep 2020 12:01:03 +0000 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: <9aeafa17-0eec-7db5-7983-507065ab67c7@redhat.com> References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> <9aeafa17-0eec-7db5-7983-507065ab67c7@redhat.com> Message-ID: Hi, I agree to Aleksey's comments. Both should be pushed as separate commits but in one go. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Mittwoch, 16. September 2020 11:57 > To: Jaroslav Bachor?k > Cc: jdk-updates-dev > Subject: Re: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces > > On 9/3/20 7:00 PM, Jaroslav Bachor?k wrote: > > Hearing no objections, here is a new webrev: > > http://cr.openjdk.java.net/~jbachorik/8250928/11u/01/webrev > > Let's not diverge here? > > Better backport JDK-8252754 as the follow-up, and push JDK-8250928 (this > one) and JDK-8252754 > (follow-up) together. > > The first variant looks fine: > http://cr.openjdk.java.net/~jbachorik/8250928/11u/webrev/ > > ...provided it it pushed along with JDK-8252754. > > -- > Thanks, > -Aleksey From harold.seigel at oracle.com Wed Sep 16 12:20:45 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 16 Sep 2020 08:20:45 -0400 Subject: [15u] RFR (S) 8249192: MonitorInfo stores raw oops across safepoints In-Reply-To: References: <3dc236a9-2f44-8226-af1d-22fb2187a8fc@redhat.com> <471accdf-9672-0f43-114b-919b09d27e1f@redhat.com> <20a23d12-cd7a-2e8d-f6e0-28e7fb39c798@oracle.com> <7ec5082b-3bcf-2ae8-ef99-7286409d4062@redhat.com> Message-ID: <7ff73194-0ef0-84f4-fbfb-db3245152afc@oracle.com> Hi Aleksey, Since this fix was backported to JDK15-CPU, it will be in the 15.0.2 release.? You do not need to do a separate backport to JDK-15u. Thanks, Harold On 9/15/2020 4:28 AM, Aleksey Shipilev wrote: > On 9/15/20 3:29 AM, David Holmes wrote: >> On 14/09/2020 5:55 pm, Aleksey Shipilev wrote: >>> On 9/14/20 9:51 AM, David Holmes wrote: >>>> Hi Aleksey, >>>> >>>> On 14/09/2020 5:29 pm, Aleksey Shipilev wrote: >>>>> On 9/9/20 9:10 AM, Aleksey Shipilev wrote: >>>>>> Original bug: >>>>>> ????? https://bugs.openjdk.java.net/browse/JDK-8249192 >>>>>> https://hg.openjdk.java.net/jdk/jdk/rev/61f9028f360d >>>>>> >>>>>> 15u variant: >>>>>> https://cr.openjdk.java.net/~shade/8249192/webrev.15u.01/ >>>>>> >>>>>> It differs from jdk/jdk variant by a conflict in jvmtiEnvBase.cpp, >>>>>> where removed "ResourceMark rm" >>>>>> does not have "current_thread" argument yet. It was added later with >>>>>> JDK-8247729: >>>>>> https://hg.openjdk.java.net/jdk/jdk/rev/f8a9be0f9e1a#l2.82 >>>>>> >>>>>> Testing: tier{1,2} with and without Shenandoah [which seems to find >>>>>> some of these bugs] >>>>> >>>>> Um. >>>>> >>>>> I see there is a "backport" to 15.0.2 already: >>>>> ?? ? https://bugs.openjdk.java.net/browse/JDK-8251485 >>>>> >>>>> ...yet there is no changeset at all: >>>>> https://hg.openjdk.java.net/jdk-updates/jdk15u/log?rev=8251485 >>>>> >>>>> What's up with that? Rob, Thomas? >>>> >>>> I think an oversight on our (Oracle) end. It went into the 15u CPU >>>> repo >>>> instead of the open repo. >>> >>> Ah. Well, I can push my versions of 8249192 (once reviewed here) and >>> 8251118 to jdk-updates/jdk15u then. But it would be nice if someone >>> from >>> Oracle would compare the 8249192 changeset above with what is pushed to >>> 15u CPU repo. >> >> They are the same. > > Thanks, I'll count that as the backport review then. > > Added the fix-request with the synopsis of all this mess :) > From gnu.andrew at redhat.com Wed Sep 16 16:01:52 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 17:01:52 +0100 Subject: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 In-Reply-To: <9c8c79d5-d52b-82c2-399a-2e03732cadfd@redhat.com> References: <20200916030536.GA248929@stopbrexit> <9c8c79d5-d52b-82c2-399a-2e03732cadfd@redhat.com> Message-ID: <20200916160152.GF258227@stopbrexit> On 09:27 Wed 16 Sep , Andrew Haley wrote: > On 16/09/2020 04:05, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222286 > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.01/ > > > > On s390 (the 31-bit architecture), calls to log2_intptr with a size_t > > argument are ambiguous, because there is log2_intptr(uintptr_t x) and > > log2_intptr(intptr_t x). This is not a problem on other architectures > > where size_t is the same as uintptr_t. See existing bugs for > > more details of the s390 situation [0] [1] [2]. > > > > The issue can be resolved by explicitly casting to uintptr_t. > > > > It is not applicable to >= 12u, as JDK-8213436 removed the problematic > > function in which this occurs. > > > > Ok for 11u? > > Sure, but please add a comment. "S/390: Cast to (uintptr_t): see JDK-8222286" > would do. Thanks. > > -- > 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 > Sure, good idea. Added in https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.02/ Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From gnu.andrew at redhat.com Wed Sep 16 16:02:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 16 Sep 2020 17:02:49 +0100 Subject: [11u] RFR 8250665: Wrong translation for the month name of May in ar_JO,LB,SY In-Reply-To: References: Message-ID: <20200916160249.GG258227@stopbrexit> On 09:52 Thu 10 Sep , Zhengyu Gu wrote: > I would like to backport this patch to 11u for parity with Oracle 11.0.10. > > The original patch does not apply cleanly. But conflicts are only limited to > Copyright and bug Id lines of LocaleDataTest.java. > > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8250665 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9aa999666ccc > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8250665-11u/webrev.00/ > > > Test: > jdk_text > > Thanks, > > -Zhengyu > Looks good to me. Please flag for approval. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From hohensee at amazon.com Wed Sep 16 17:03:12 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 16 Sep 2020 17:03:12 +0000 Subject: [11u] RFR/RFA (S): 8253134: JMM_VERSION should remain at 0x20020000 (JDK 10) in JDK 11 In-Reply-To: References: <28D8B85C-2850-426F-9D73-AFE81F644B2E@amazon.com> Message-ID: <372C219C-2946-409D-9A83-4BEEDA8A8D99@amazon.com> Thanks, Volker! Christoph approved, so I've pushed the patch to jdk11u. ?On 9/16/20, 1:30 AM, "Volker Simonis" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Tue, Sep 15, 2020 at 6:32 PM Hohensee, Paul wrote: > > Thanks for the review, Volker. You're right, I'll delete that sentence. > Thanks! I saw you've deleted the sentence in the CSR so I deleted it in the bug as well. I've also added a "jdk11u-critical-request" label now that CSR has been approved. > Paul > > On 9/15/20, 8:40 AM, "Volker Simonis" wrote: > > On Mon, Sep 14, 2020 at 11:25 PM Hohensee, Paul wrote: > > > > Please review this patch and CSR for 11.0.9. If approved, I propose tagging the issue with jdk11u-critical-request. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8253134 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8253136 > > Webrev: http://cr.openjdk.java.net/~phh/8253134/webrev.11u.00/ > > > > JDK-8231209, which was originally pushed to JDK 14, has been backported to 11.0.9 and 11,0.10-oracle. Those backports changed JMM_VERSION from 0x20020000 (JDK 10) to 0x20030000 (JDK 14), which introduced an incompatibility that was overlooked in the backport CSRs JDK-8247807 (11.0.9) and JDK-8248871 (11.0.10-oracle). JDK 11 users checking for JMM_VERSION == 0x20020000 will find 0x2003000 instead and possibly abort. The issue was first noticed as part of reviewing a backport of JDK-8185003 to JDK 8: see the Description in the corresponding CSR JDK-8251498. > > > > For the reasons detailed there, JMM_VERSION in JDK 11 should be reverted to 0x20020000 (JDK 10), and the @since javadoc tag for com.sun.management.ThreadMXBean.getCurrentThreadAllocatedBytes should be changed from 14 to 11.0.9. If/when the JDK-8231209 backport to JDK 8 is approved for openjdk8u282, the @since tag should be changed to 8u282. > > > > This all looks good to me. I've also reviewed and endorsed the CSR. > > I'm only not sure about the last sentence: "If/when the JDK-8231209 > backport to JDK 8 is approved for openjdk8u282, the @since tag should > be changed to 8u282". Not sure if we should really do that? If > somebody reads that in jdk11u he could think that the change must be > in 11.0.0 and later as well, but that's not true. > > If somebody reads it in the 8u282 API he might think the same (and > that it is in 9 & 10 but those two are hopefully not used by anybody > any more), and there's no way to fix that. But I'd personally leave it > as 11.0.9 in jdk11u. > > Best regards, > Volker > > > Thanks, > > Paul > > > From christoph.langer at sap.com Thu Sep 17 07:43:47 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Sep 2020 07:43:47 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes In-Reply-To: References: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> Message-ID: Hi, I've just looked at approving this series of backports (JDK-8209061, JDK-8209062 and JDK-8207200). While I'm sure that JDK-8207200 fixes an important issue and I also trust your reviews of the backports, I can see that these 3 patches together mean some significant changes in the area of G1 GC. This makes me kind of hesitant to approve the backports right away. I'd like to get some assessment/reassurance of the other JDK11 maintainers (aph, sgehwolf) on whether we should admit them or not? Also, Aleksey, maybe you can give some technical advice as a gc expert if you think these backports are feasible? Another thing: Looking at JBS I can see that JDK-8208498 was marked as a blocker for JDK-8209061 and the former hasn't been backported to 11. Is that an issue? Generally, would it be possible to fix the issue of JDK-8207200 in a way that's less invasive? Please understand that I'd like to err on the side of caution here... Thanks & Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of John Cuthbertson > Sent: Dienstag, 15. September 2020 19:07 > To: Vladimir Kempik > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes > > Hi Vladimir, > > On Sep 3, 2020, at 5:28 AM, Vladimir Kempik > > wrote: > > Hello > > Please review these backports of JDK-8209061:Move G1 serviceability > functionality to G1MonitoringSupport and JDK-8209062:Clean up > G1MonitoringSupport to jdk11u > > These backports are prerequestes for JDK-8207200 which we can see in the > wild with jdk8 and jdk11. > > JDK-8209061 and JDK-8209062 applies mostly clean, very few places where it > wasn?t clean due to surrounding code or code layout. > > after these two, JDK-8207200 applies cleanly. > > Testing: tier1. > > The webrevs: > > http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ > > This looks good to me and matches > http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec. > > http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ > > This looks good to me also and matches > http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046. > > > All mentioned bugs: > https://bugs.openjdk.java.net/browse/JDK-8209062 > https://bugs.openjdk.java.net/browse/JDK-8209061 > https://bugs.openjdk.java.net/browse/JDK-8207200 > > Original changesets: > 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec > 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 > > Thanks, Vladimir > > Regards, > > JohnC From vkempik at azul.com Thu Sep 17 08:24:35 2020 From: vkempik at azul.com (Vladimir Kempik) Date: Thu, 17 Sep 2020 08:24:35 +0000 Subject: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes In-Reply-To: References: <3BBDEB11-6FE8-4F93-BCDE-155132DF935A@azul.com> Message-ID: <8E3BF025-A532-499B-9E09-9F92C5911F42@azul.com> Hello Langer >Another thing: Looking at JBS I can see that JDK-8208498 was marked as a blocker for JDK-8209061 and the former hasn't been backported to 11. Is that an issue >Generally, would it be possible to fix the issue of JDK-8207200 in a way that's less invasive? well, I have tried to make 8207200 less invasive by not including 8208498. There is a race condition in g1 monitoring which still can be see by some openjdk11 users ( commited < used) and this is the attempt to fix it. I have verified it helps at least one user. Sadly I don?t have a reproducer. Regards, Vladimir > 17 ????. 2020 ?., ? 10:43, Langer, Christoph ???????(?): > > Hi, > > I've just looked at approving this series of backports (JDK-8209061, JDK-8209062 and JDK-8207200). > > While I'm sure that JDK-8207200 fixes an important issue and I also trust your reviews of the backports, I can see that these 3 patches together mean some significant changes in the area of G1 GC. This makes me kind of hesitant to approve the backports right away. I'd like to get some assessment/reassurance of the other JDK11 maintainers (aph, sgehwolf) on whether we should admit them or not? > > Also, Aleksey, maybe you can give some technical advice as a gc expert if you think these backports are feasible? > > Another thing: Looking at JBS I can see that JDK-8208498 was marked as a blocker for JDK-8209061 and the former hasn't been backported to 11. Is that an issue? > > Generally, would it be possible to fix the issue of JDK-8207200 in a way that's less invasive? > > Please understand that I'd like to err on the side of caution here... > > Thanks & Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of John Cuthbertson >> Sent: Dienstag, 15. September 2020 19:07 >> To: Vladimir Kempik >> Cc: jdk-updates-dev at openjdk.java.net >> Subject: Re: [11u] RFR: 8209061 & 8209062: G1MonitoringSupport changes >> >> Hi Vladimir, >> >> On Sep 3, 2020, at 5:28 AM, Vladimir Kempik >> > wrote: >> >> Hello >> >> Please review these backports of JDK-8209061:Move G1 serviceability >> functionality to G1MonitoringSupport and JDK-8209062:Clean up >> G1MonitoringSupport to jdk11u >> >> These backports are prerequestes for JDK-8207200 which we can see in the >> wild with jdk8 and jdk11. >> >> JDK-8209061 and JDK-8209062 applies mostly clean, very few places where it >> wasn?t clean due to surrounding code or code layout. >> >> after these two, JDK-8207200 applies cleanly. >> >> Testing: tier1. >> >> The webrevs: >> >> http://cr.openjdk.java.net/~vkempik/8209061/webrev.00/ >> >> This looks good to me and matches >> http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec. >> >> http://cr.openjdk.java.net/~vkempik/8209062/webrev.00/ >> >> This looks good to me also and matches >> http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046. >> >> >> All mentioned bugs: >> https://bugs.openjdk.java.net/browse/JDK-8209062 >> https://bugs.openjdk.java.net/browse/JDK-8209061 >> https://bugs.openjdk.java.net/browse/JDK-8207200 >> >> Original changesets: >> 8209061: http://hg.openjdk.java.net/jdk/jdk/rev/ec014e5694ec >> 8209062: http://hg.openjdk.java.net/jdk/jdk/rev/9a5200b84046 >> >> Thanks, Vladimir >> >> Regards, >> >> JohnC From christoph.langer at sap.com Thu Sep 17 11:58:56 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 17 Sep 2020 11:58:56 +0000 Subject: [11u] RFR: 8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 Message-ID: Hi, please review a follow-up fix for JDK-8252258 [0]. After that change which restored the default vendor name of "Oracle Corporation" in a plain OpenJDK build, the test build/translations/VerifyTranslations.java started to fail. The test is an Oracle only test which incidentally got activated by the fix for JDK-8252258. That happens because the release file in the target image now contains "Oracle Corporation" as value for IMPLEMENTOR which wasn't the case before. With my proposed patch the old behavior will be restored in that case as well. If reviewed, I'd like to flag it jdk11u-critical because it should reach 11.0.9 together with JDK-8252258. Bug: https://bugs.openjdk.java.net/browse/JDK-8253283 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8253283.11u.0/ Thanks & Best regards Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8252258 From goetz.lindenmaier at sap.com Fri Sep 18 06:57:50 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 18 Sep 2020 06:57:50 +0000 Subject: [11.0.9u] Open P2 bug 8250787 Provider.put no longer registering aliases in FIPS env Message-ID: Hi, Paul, any progress on this? Can anybody rate the risk of not fixing this bug? Can anybody reproduce the bug? 7092821 that introduced this problem is only a performance optimization. If we cannot find a solution for 8250787, should we backout 7092821 from 11.0.9? Unfortunately, backing out the change does not apply clean, because, e.g., 8246613 reverted parts of it. Best regards, Goetz. From: Hohensee, Paul Sent: Monday, August 31, 2020 6:43 PM To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] Input on 8250787 Provider.put no longer registering aliases in FIPS env We?ll take a look. Thanks, Paul From: "Lindenmaier, Goetz" > Date: Monday, August 31, 2020 at 7:55 AM To: "jdk-updates-dev at openjdk.java.net" >, "Hohensee, Paul" > Subject: [11u] Input on 8250787 Provider.put no longer registering aliases in FIPS env Hi, I had a look at 8250787 Provider.put no longer registering aliases in FIPS env https://bugs.openjdk.java.net/browse/JDK-8250787 This is the last relevant open 11.0.9-oracle change in 11u. Oracle rates it P2. Unfortunately, no patch to downport exists. It is fixed only in 11 and 8 by Oracle. Apparently the problem was introduced by 1. 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck 2. https://bugs.openjdk.java.net/browse/JDK-7092821 which was downported to 11.0.7. Paul, do you maybe have an idea how to fix this? Best regards, Goetz. From jaroslav.bachorik at datadoghq.com Fri Sep 18 10:39:54 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 18 Sep 2020 12:39:54 +0200 Subject: [11u] RFR 8252754: Hash code calculation of JfrStackTrace is inconsistent Message-ID: Please review this simple backport. The patch applies cleanly with only hunk offsets adjustments. JIRA: https://bugs.openjdk.java.net/browse/JDK-8252754 Webrev: http://cr.openjdk.java.net/~jbachorik/8252754/11u/webrev/ Cheers, -JB- From jaroslav.bachorik at datadoghq.com Fri Sep 18 10:41:15 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 18 Sep 2020 12:41:15 +0200 Subject: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces In-Reply-To: References: <55caf9de-c8fc-15aa-6fb7-de42b2aabb55@redhat.com> <9aeafa17-0eec-7db5-7983-507065ab67c7@redhat.com> Message-ID: Ok, opening an RFR for JDK-8252754 backport since I had to adjust the patch's hunk offsets a bit. https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003832.html Cheers, -JB- On Wed, Sep 16, 2020 at 2:01 PM Langer, Christoph wrote: > > Hi, > > I agree to Aleksey's comments. Both should be pushed as separate commits but in one go. > > Cheers > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Aleksey Shipilev > > Sent: Mittwoch, 16. September 2020 11:57 > > To: Jaroslav Bachor?k > > Cc: jdk-updates-dev > > Subject: Re: [11u] RFR 8250928: JFR: Improve hash algorithm for stack traces > > > > On 9/3/20 7:00 PM, Jaroslav Bachor?k wrote: > > > Hearing no objections, here is a new webrev: > > > http://cr.openjdk.java.net/~jbachorik/8250928/11u/01/webrev > > > > Let's not diverge here? > > > > Better backport JDK-8252754 as the follow-up, and push JDK-8250928 (this > > one) and JDK-8252754 > > (follow-up) together. > > > > The first variant looks fine: > > http://cr.openjdk.java.net/~jbachorik/8250928/11u/webrev/ > > > > ...provided it it pushed along with JDK-8252754. > > > > -- > > Thanks, > > -Aleksey > From shade at redhat.com Fri Sep 18 10:42:40 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 18 Sep 2020 12:42:40 +0200 Subject: [11u] RFR 8252754: Hash code calculation of JfrStackTrace is inconsistent In-Reply-To: References: Message-ID: <0f7e723a-a979-41fa-b75a-566307948cfc@redhat.com> On 9/18/20 12:39 PM, Jaroslav Bachor?k wrote: > Please review this simple backport. > > The patch applies cleanly with only hunk offsets adjustments. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8252754 > Webrev: http://cr.openjdk.java.net/~jbachorik/8252754/11u/webrev/ Looks fine, thanks. -- -Aleksey From gnu.andrew at redhat.com Fri Sep 18 15:52:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 18 Sep 2020 16:52:00 +0100 Subject: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 In-Reply-To: <20200916160152.GF258227@stopbrexit> References: <20200916030536.GA248929@stopbrexit> <9c8c79d5-d52b-82c2-399a-2e03732cadfd@redhat.com> <20200916160152.GF258227@stopbrexit> Message-ID: <20200918155200.GB371187@stopbrexit> On 17:01 Wed 16 Sep , Andrew Hughes wrote: > On 09:27 Wed 16 Sep , Andrew Haley wrote: > > On 16/09/2020 04:05, Andrew Hughes wrote: > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222286 > > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.01/ > > > > > > On s390 (the 31-bit architecture), calls to log2_intptr with a size_t > > > argument are ambiguous, because there is log2_intptr(uintptr_t x) and > > > log2_intptr(intptr_t x). This is not a problem on other architectures > > > where size_t is the same as uintptr_t. See existing bugs for > > > more details of the s390 situation [0] [1] [2]. > > > > > > The issue can be resolved by explicitly casting to uintptr_t. > > > > > > It is not applicable to >= 12u, as JDK-8213436 removed the problematic > > > function in which this occurs. > > > > > > Ok for 11u? > > > > Sure, but please add a comment. "S/390: Cast to (uintptr_t): see JDK-8222286" > > would do. Thanks. > > > > -- > > 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 > > > > Sure, good idea. > > Added in https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.02/ > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > 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 Is this good to go? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From alvdavi at amazon.com Fri Sep 18 20:21:22 2020 From: alvdavi at amazon.com (David Alvarez) Date: Fri, 18 Sep 2020 13:21:22 -0700 Subject: [11.0.9u] Open P2 bug 8250787 Provider.put no longer registering aliases in FIPS env In-Reply-To: References: Message-ID: Hi Goetz, I am currently working on a patch for this. After reading the original bug, it is my take that the problem of aliases not working in this scenario is older, it is just that the JDK changed how most of these services are added in 7092821. The problem is the provider class holding two maps to keep track of services, legacyMap (for those added with put) and serviceMap (for those added with putService). When an alias is added using put, it will try to locate the original service, but only in the legacyMap. My approach is making the parseLegacyPut method search both maps [1]. I am still adding that alias to the legacyMap (instead of now moving that one to the new serviceMap). I would like to know if anyone sees a problem with this approach, but in any case, I'm preparing an RFR for this. If it does not go out today, it will on Monday. -- David [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/360916af5610/src/java.base/share/classes/java/security/Provider.java#l1191 On 2020-09-17 23:57, Lindenmaier, Goetz wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi, > > Paul, any progress on this? > > Can anybody rate the risk of not fixing this bug? > Can anybody reproduce the bug? > > 7092821 that introduced this problem is only a performance > optimization. If we cannot find a solution for 8250787, > should we backout 7092821 from 11.0.9? > > Unfortunately, backing out the change does not > apply clean, because, e.g., 8246613 reverted parts > of it. > > Best regards, > Goetz. > > From: Hohensee, Paul > Sent: Monday, August 31, 2020 6:43 PM > To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] Input on 8250787 Provider.put no longer registering aliases in FIPS env > > We?ll take a look. > > Thanks, > Paul > > From: "Lindenmaier, Goetz" > > Date: Monday, August 31, 2020 at 7:55 AM > To: "jdk-updates-dev at openjdk.java.net" >, "Hohensee, Paul" > > Subject: [11u] Input on 8250787 Provider.put no longer registering aliases in FIPS env > > Hi, > > I had a look at > 8250787 Provider.put no longer registering aliases in FIPS env > https://bugs.openjdk.java.net/browse/JDK-8250787 > > This is the last relevant open 11.0.9-oracle change in 11u. > Oracle rates it P2. > Unfortunately, no patch to downport exists. It is fixed only in 11 > and 8 by Oracle. > > Apparently the problem was introduced by > 1. 7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck > 2. https://bugs.openjdk.java.net/browse/JDK-7092821 > which was downported to 11.0.7. Paul, do you maybe have an idea how to fix this? > > Best regards, > Goetz. > > From alvdavi at amazon.com Fri Sep 18 23:00:14 2020 From: alvdavi at amazon.com (David Alvarez) Date: Fri, 18 Sep 2020 16:00:14 -0700 Subject: [11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env Message-ID: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> Hi, Please review the following patch for 8250787, a p2 present in 11.0.9-oracle we are still missing. webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8250787 The problem is related to the registration of aliases in the java.security.Provider. Provider holds two maps, one for services registered using the old Provider.put (legacyMap) method and one for holding services registered with the newer Provider.putService (serviceMap). It seems that has been the case since 1.5, but it was not a problem until recently, as the default services were still added using the old Provider.put. JDK-7092821 [1] changed that, making the default providers use Provider.putService instead of Provider.put, and uncovering this latent problem. The fix is a small one, make sure that parseLegacyPut looks into both maps when adding a new alias. Patch pases jdk tier1 and tier2 and a test is included. David -- https://bugs.openjdk.java.net/browse/JDK-7092821 From christoph.langer at sap.com Sat Sep 19 01:59:23 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 19 Sep 2020 01:59:23 +0000 Subject: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 In-Reply-To: <20200918155200.GB371187@stopbrexit> References: <20200916030536.GA248929@stopbrexit> <9c8c79d5-d52b-82c2-399a-2e03732cadfd@redhat.com> <20200916160152.GF258227@stopbrexit> <20200918155200.GB371187@stopbrexit> Message-ID: Hi, looks good to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Hughes > Sent: Freitag, 18. September 2020 17:52 > To: Andrew Haley > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 > > On 17:01 Wed 16 Sep , Andrew Hughes wrote: > > On 09:27 Wed 16 Sep , Andrew Haley wrote: > > > On 16/09/2020 04:05, Andrew Hughes wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222286 > > > > Webrev: > https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.01/ > > > > > > > > On s390 (the 31-bit architecture), calls to log2_intptr with a size_t > > > > argument are ambiguous, because there is log2_intptr(uintptr_t x) and > > > > log2_intptr(intptr_t x). This is not a problem on other architectures > > > > where size_t is the same as uintptr_t. See existing bugs for > > > > more details of the s390 situation [0] [1] [2]. > > > > > > > > The issue can be resolved by explicitly casting to uintptr_t. > > > > > > > > It is not applicable to >= 12u, as JDK-8213436 removed the problematic > > > > function in which this occurs. > > > > > > > > Ok for 11u? > > > > > > Sure, but please add a comment. "S/390: Cast to (uintptr_t): see JDK- > 8222286" > > > would do. Thanks. > > > > > > -- > > > 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 > > > > > > > Sure, good idea. > > > > Added in > https://cr.openjdk.java.net/~andrew/openjdk11/8222286/webrev.02/ > > > > Thanks, > > -- > > Andrew :) > > > > Senior Free Java Software Engineer > > OpenJDK Package Owner > > 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 > > Is this good to go? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > 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 From gnu.andrew at redhat.com Sat Sep 19 02:02:04 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 19 Sep 2020 03:02:04 +0100 Subject: [11u] RFR: JDK-8222286: Fix for JDK-8213419 is broken on s390 In-Reply-To: References: <20200916030536.GA248929@stopbrexit> <9c8c79d5-d52b-82c2-399a-2e03732cadfd@redhat.com> <20200916160152.GF258227@stopbrexit> <20200918155200.GB371187@stopbrexit> Message-ID: <20200919020204.GA401369@stopbrexit> On 01:59 Sat 19 Sep , Langer, Christoph wrote: > Hi, > > looks good to me. > > Best regards > Christoph > Thanks Christoph. Flagged for approval. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner 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 From shade at redhat.com Mon Sep 21 06:15:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 21 Sep 2020 08:15:23 +0200 Subject: [11u] RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize option In-Reply-To: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com> References: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com> Message-ID: Friendly reminder. On 9/7/20 1:29 PM, Aleksey Shipilev wrote: > Original RFE: > https://bugs.openjdk.java.net/browse/JDK-8252660 > https://hg.openjdk.java.net/jdk/jdk/rev/6ab9279c0e99 > > The patch does not apply cleanly to 11u, because there are conflicts in APIs. > > I had to resolve these: > *) There is no Atomic::store(&size_t, size_t), replaced with OrderAccess::release_store_fence, as > in other places in 11u. > *) There is no global SoftMaxHeapSize, replaced it with ShenandoahSoftMaxHeapSize and added > relevant verifications to make new Shenandoah tests pass. > > 11u webrev: > https://cr.openjdk.java.net/~shade/8252660/webrev.11u.01/ > > Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Mon Sep 21 11:48:35 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Sep 2020 11:48:35 +0000 Subject: [11u] RFR: 8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 In-Reply-To: References: Message-ID: Hi Christoph, Yes, now the java.vendor looks good, and the release file shows n/a. Reviewed. Best regards, Goetz. From: Langer, Christoph Sent: Thursday, September 17, 2020 1:59 PM To: jdk-updates-dev at openjdk.java.net; Andrew Hughes ; Lindenmaier, Goetz Cc: Zeller, Arno Subject: [11u] RFR: 8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 Hi, please review a follow-up fix for JDK-8252258 [0]. After that change which restored the default vendor name of "Oracle Corporation" in a plain OpenJDK build, the test build/translations/VerifyTranslations.java started to fail. The test is an Oracle only test which incidentally got activated by the fix for JDK-8252258. That happens because the release file in the target image now contains "Oracle Corporation" as value for IMPLEMENTOR which wasn't the case before. With my proposed patch the old behavior will be restored in that case as well. If reviewed, I'd like to flag it jdk11u-critical because it should reach 11.0.9 together with JDK-8252258. Bug: https://bugs.openjdk.java.net/browse/JDK-8253283 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8253283.11u.0/ Thanks & Best regards Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8252258 From christoph.langer at sap.com Mon Sep 21 12:06:48 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 21 Sep 2020 12:06:48 +0000 Subject: [11u] RFR: 8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 In-Reply-To: References: Message-ID: Thanks, Goetz! I've flagged the bug for 11.0.9. @Severin: Can you approve it? Cheers Christoph From: Lindenmaier, Goetz Sent: Montag, 21. September 2020 13:49 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net; Andrew Hughes Cc: Zeller, Arno Subject: RE: [11u] RFR: 8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 Hi Christoph, Yes, now the java.vendor looks good, and the release file shows n/a. Reviewed. Best regards, Goetz. From: Langer, Christoph > Sent: Thursday, September 17, 2020 1:59 PM To: jdk-updates-dev at openjdk.java.net; Andrew Hughes >; Lindenmaier, Goetz > Cc: Zeller, Arno > Subject: [11u] RFR: 8253283: [11u] Test build/translations/VerifyTranslations.java failing after JDK-8252258 Hi, please review a follow-up fix for JDK-8252258 [0]. After that change which restored the default vendor name of "Oracle Corporation" in a plain OpenJDK build, the test build/translations/VerifyTranslations.java started to fail. The test is an Oracle only test which incidentally got activated by the fix for JDK-8252258. That happens because the release file in the target image now contains "Oracle Corporation" as value for IMPLEMENTOR which wasn't the case before. With my proposed patch the old behavior will be restored in that case as well. If reviewed, I'd like to flag it jdk11u-critical because it should reach 11.0.9 together with JDK-8252258. Bug: https://bugs.openjdk.java.net/browse/JDK-8253283 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8253283.11u.0/ Thanks & Best regards Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8252258 From zgu at redhat.com Mon Sep 21 14:21:19 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 21 Sep 2020 10:21:19 -0400 Subject: [11u] RFR (S) 8252660: Shenandoah: support manageable SoftMaxHeapSize option In-Reply-To: References: <9d8aa88a-d3c6-281d-1f22-b7120c02bc8e@redhat.com> Message-ID: Good to me. Thanks, -Zhengyu On 9/21/20 2:15 AM, Aleksey Shipilev wrote: > Friendly reminder. > > On 9/7/20 1:29 PM, Aleksey Shipilev wrote: >> Original RFE: >> ??? https://bugs.openjdk.java.net/browse/JDK-8252660 >> ??? https://hg.openjdk.java.net/jdk/jdk/rev/6ab9279c0e99 >> >> The patch does not apply cleanly to 11u, because there are conflicts >> in APIs. >> >> I had to resolve these: >> ??? *) There is no Atomic::store(&size_t, size_t), replaced with >> OrderAccess::release_store_fence, as >> in other places in 11u. >> ??? *) There is no global SoftMaxHeapSize, replaced it with >> ShenandoahSoftMaxHeapSize and added >> relevant verifications to make new Shenandoah tests pass. >> >> 11u webrev: >> ??? https://cr.openjdk.java.net/~shade/8252660/webrev.11u.01/ >> >> Testing: hotspot_gc_shenandoah, tier{1,2} with Shenandoah > > From goetz.lindenmaier at sap.com Tue Sep 22 06:56:24 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Sep 2020 06:56:24 +0000 Subject: [11u] RFR: 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed Message-ID: Hi, I am downporting this for parity with 11.0.10-oracle. I had to resolve because one file is C and not C++. Also, in tc02t001.java, the deleted sleep() times differ. (The patch looks complicated but is not. The change switches position of class tc02t001Thread and class tc02t001, and webrev computed a different diff than to be seen in the repo.) http://cr.openjdk.java.net/~goetz/wr20/8224555-nsk_jvmti_test-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8224555 http://hg.openjdk.java.net/jdk/jdk13/rev/e17c9a93b505 Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Sep 22 07:34:38 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Sep 2020 07:34:38 +0000 Subject: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager Message-ID: Hi, I downport this for parity with 11.0.10-oracle. I had to fix a row of things in the makefile. - some utility functions are missing in the 11 build - I implemented the solaris build. I checked Solaris sparc works. The rest is just a plain file move, except for adding a const in hb_subset_cff_common.hh hb_serialize_cff_fdselect(). The implementation in .cc declares the argument const, and solaris fails to link without seeing the const in the header. http://cr.openjdk.java.net/~goetz/wr20/8249821-separate_harfbuzz-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8249821 https://hg.openjdk.java.net/jdk/client/rev/cda47533b1ee Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Sep 22 07:51:18 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Sep 2020 07:51:18 +0000 Subject: [11u] RFR: 8249602: C2: assert(cnt == _outcnt) failed: no insertions allowed Message-ID: Hi Only trivial resolves because of whitespace and the 'a' argument to clones() in the context. http://cr.openjdk.java.net/~goetz/wr20/8249602-C2_insertions-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8249602 https://hg.openjdk.java.net/jdk/jdk/rev/b7dda1eda100 Best regards, Goetz. From neugens at redhat.com Tue Sep 22 08:18:40 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 22 Sep 2020 10:18:40 +0200 Subject: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager In-Reply-To: References: Message-ID: Hi Goetz, Looks good to me. I'm a bit on the fence because I think this kind of changes shouldn't really be backported, but the fonts subsystems is often target for security patches and backports so I guess not having this will certainly makes future work a lot more complicated than necessary that this is a justified change, so the only question is if we want to keep this extra comment at this point or not: // Solaris does not link because the implementation in .cc specifies num_glyphs as const. Other than that, from my side is OK, you can consider it reviewed. Cheers, Mario On Tue, Sep 22, 2020 at 9:35 AM Lindenmaier, Goetz wrote: > > Hi, > > I downport this for parity with 11.0.10-oracle. > > I had to fix a row of things in the makefile. > - some utility functions are missing in the 11 build > - I implemented the solaris build. I checked Solaris sparc works. > > The rest is just a plain file move, except for adding a const > in hb_subset_cff_common.hh hb_serialize_cff_fdselect(). > The implementation in .cc declares the argument const, and > solaris fails to link without seeing the const in the header. > > http://cr.openjdk.java.net/~goetz/wr20/8249821-separate_harfbuzz-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8249821 > https://hg.openjdk.java.net/jdk/client/rev/cda47533b1ee > > Best regards, > Goetz. > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Tue Sep 22 09:12:52 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Sep 2020 09:12:52 +0000 Subject: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager In-Reply-To: References: Message-ID: Hi Mario, Thanks for reviewing. You are right, in itself, this change makes no sense for 11. But it is a prerequisite for "8250894: Provide a configure option to build and run against the platform libharfbuzz" which in my eyes is a change that makes sense for 11. It will help to adapt the VM to new os releases that come with more recent libs. > so the only question is if we want to keep > this extra comment at this point or not: > // Solaris does not link because the implementation in .cc specifies > num_glyphs as const. There are several other adptions in the file for solaris, that are commented similarly. See line 284 http://cr.openjdk.java.net/~goetz/wr20/8249821-separate_harfbuzz-jdk11/01/src/java.desktop/share/native/libharfbuzz/hb-subset-cff-common.hh.html I guess these comments help in case libharfbuzz is updated to find places where adaptions for solaris are needed. Best regards, Goetz. > -----Original Message----- > From: Mario Torre > Sent: Tuesday, September 22, 2020 10:19 AM > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager > > Hi Goetz, > > Looks good to me. > > I'm a bit on the fence because I think this kind of changes shouldn't > really be backported, but the fonts subsystems is often target for > security patches and backports so I guess not having this will > certainly makes future work a lot more complicated than necessary that > this is a justified change, so the only question is if we want to keep > this extra comment at this point or not: > > // Solaris does not link because the implementation in .cc specifies > num_glyphs as const. > > Other than that, from my side is OK, you can consider it reviewed. > > Cheers, > Mario > > On Tue, Sep 22, 2020 at 9:35 AM Lindenmaier, Goetz > wrote: > > > > Hi, > > > > I downport this for parity with 11.0.10-oracle. > > > > I had to fix a row of things in the makefile. > > - some utility functions are missing in the 11 build > > - I implemented the solaris build. I checked Solaris sparc works. > > > > The rest is just a plain file move, except for adding a const > > in hb_subset_cff_common.hh hb_serialize_cff_fdselect(). > > The implementation in .cc declares the argument const, and > > solaris fails to link without seeing the const in the header. > > > > http://cr.openjdk.java.net/~goetz/wr20/8249821-separate_harfbuzz- > jdk11/01/ > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8249821 > > https://hg.openjdk.java.net/jdk/client/rev/cda47533b1ee > > > > Best regards, > > Goetz. > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Tue Sep 22 10:35:05 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 22 Sep 2020 12:35:05 +0200 Subject: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager In-Reply-To: References: Message-ID: On Tue, Sep 22, 2020 at 11:13 AM Lindenmaier, Goetz wrote: > > Hi Mario, > > Thanks for reviewing. > > You are right, in itself, this change makes no sense for 11. > But it is a prerequisite for "8250894: Provide a configure option > to build and run against the platform libharfbuzz" > which in my eyes is a change that makes sense for 11. > It will help to adapt the VM to new os releases that come > with more recent libs. > > > so the only question is if we want to keep > > this extra comment at this point or not: > > // Solaris does not link because the implementation in .cc specifies > > num_glyphs as const. > > There are several other adptions in the file for solaris, > that are commented similarly. See line 284 > http://cr.openjdk.java.net/~goetz/wr20/8249821-separate_harfbuzz-jdk11/01/src/java.desktop/share/native/libharfbuzz/hb-subset-cff-common.hh.html > > I guess these comments help in case libharfbuzz is > updated to find places where adaptions for solaris are > needed. Yeah, I agree. My point was that those extra comments may make it more difficult to automatically apply other patches in the future (as they would differ in context), on the other hand the context is already changed anyway (either because of the extra definition or because on the keyword difference) and I do prefer the consistency, so all is good :) Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From martin.doerr at sap.com Tue Sep 22 13:10:10 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Sep 2020 13:10:10 +0000 Subject: [11u] RFR: 8249602: C2: assert(cnt == _outcnt) failed: no insertions allowed In-Reply-To: References: Message-ID: Hi G?tz, looks good. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 22. September 2020 09:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8249602: C2: assert(cnt == _outcnt) failed: no > insertions allowed > > Hi > > Only trivial resolves because of whitespace and the 'a' argument to clones() > in the context. > http://cr.openjdk.java.net/~goetz/wr20/8249602-C2_insertions-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8249602 > https://hg.openjdk.java.net/jdk/jdk/rev/b7dda1eda100 > > Best regards, > Goetz. From martin.doerr at sap.com Tue Sep 22 13:14:31 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Sep 2020 13:14:31 +0000 Subject: [11u] RFR: 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed In-Reply-To: References: Message-ID: Hi G?tz, you have additional leading whitespaces in tc02t001.c: static jint lines[] = { 48, 53, 58 }; Looks good otherwise. Don't need to see another webrev. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 22. September 2020 08:56 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8224555: > vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription > .java failed > > Hi, > > I am downporting this for parity with 11.0.10-oracle. > > I had to resolve because one file is C and not C++. > Also, in tc02t001.java, the deleted sleep() times differ. > > (The patch looks complicated but is not. The change switches > position of class tc02t001Thread and class tc02t001, > and webrev computed a different diff than to be seen in > the repo.) > > http://cr.openjdk.java.net/~goetz/wr20/8224555-nsk_jvmti_test-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8224555 > http://hg.openjdk.java.net/jdk/jdk13/rev/e17c9a93b505 > > Best regards, > Goetz. From mbalao at redhat.com Tue Sep 22 14:44:40 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 22 Sep 2020 11:44:40 -0300 Subject: [11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env In-Reply-To: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> References: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> Message-ID: Hi, Thanks for having a look at this. On Fri, Sep 18, 2020 at 8:01 PM David Alvarez wrote: > Please review the following patch for 8250787, a p2 present in > 11.0.9-oracle we are still missing. > > webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8250787 > > The problem is related to the registration of aliases in the > java.security.Provider. Provider holds two maps, one for services > registered using the old Provider.put (legacyMap) method and one for > holding services registered with the newer Provider.putService > (serviceMap). It seems that has been the case since 1.5, but it was not > a problem until recently, as the default services were still added using > the old Provider.put. JDK-7092821 [1] changed that, making the default > providers use Provider.putService instead of Provider.put, and > uncovering this latent problem. > > The fix is a small one, make sure that parseLegacyPut looks into both > maps when adding a new alias. Patch pases jdk tier1 and tier2 and a test > is included. > I've seen that entries from the legacyMap are also retrieved in 2 additional paths within Provider::parseLegacyPut. Don't we need to get the Service from the new map if the previous fails? Looks to me that these 2 additional paths are different ways of describing the alias. Thanks, Martin.- From goetz.lindenmaier at sap.com Tue Sep 22 15:38:47 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Sep 2020 15:38:47 +0000 Subject: [11u] RFR: 8224555: vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription.java failed In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing. I fixed the whitespace. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, September 22, 2020 3:15 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR: 8224555: > vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription > .java failed > > Hi G?tz, > > you have additional leading whitespaces in tc02t001.c: > static jint lines[] = { 48, 53, 58 }; > > Looks good otherwise. Don't need to see another webrev. > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Dienstag, 22. September 2020 08:56 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8224555: > > > vmTestbase/nsk/jvmti/scenarios/contention/TC02/tc02t001/TestDescription > > .java failed > > > > Hi, > > > > I am downporting this for parity with 11.0.10-oracle. > > > > I had to resolve because one file is C and not C++. > > Also, in tc02t001.java, the deleted sleep() times differ. > > > > (The patch looks complicated but is not. The change switches > > position of class tc02t001Thread and class tc02t001, > > and webrev computed a different diff than to be seen in > > the repo.) > > > > http://cr.openjdk.java.net/~goetz/wr20/8224555-nsk_jvmti_test-jdk11/01/ > > > > Please review. > > > > https://bugs.openjdk.java.net/browse/JDK-8224555 > > http://hg.openjdk.java.net/jdk/jdk13/rev/e17c9a93b505 > > > > Best regards, > > Goetz. From goetz.lindenmaier at sap.com Tue Sep 22 15:42:41 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Sep 2020 15:42:41 +0000 Subject: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager In-Reply-To: References: Message-ID: Thanks, Mario! Best regards, Goetz. > -----Original Message----- > From: Mario Torre > Sent: Tuesday, September 22, 2020 12:35 PM > To: Lindenmaier, Goetz > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8249821: Separate libharfbuzz from libfontmanager > > On Tue, Sep 22, 2020 at 11:13 AM Lindenmaier, Goetz > wrote: > > > > Hi Mario, > > > > Thanks for reviewing. > > > > You are right, in itself, this change makes no sense for 11. > > But it is a prerequisite for "8250894: Provide a configure option > > to build and run against the platform libharfbuzz" > > which in my eyes is a change that makes sense for 11. > > It will help to adapt the VM to new os releases that come > > with more recent libs. > > > > > so the only question is if we want to keep > > > this extra comment at this point or not: > > > // Solaris does not link because the implementation in .cc specifies > > > num_glyphs as const. > > > > There are several other adptions in the file for solaris, > > that are commented similarly. See line 284 > > http://cr.openjdk.java.net/~goetz/wr20/8249821-separate_harfbuzz- > jdk11/01/src/java.desktop/share/native/libharfbuzz/hb-subset-cff- > common.hh.html > > > > I guess these comments help in case libharfbuzz is > > updated to find places where adaptions for solaris are > > needed. > > Yeah, I agree. My point was that those extra comments may make it more > difficult to automatically apply other patches in the future (as they > would differ in context), on the other hand the context is already > changed anyway (either because of the extra definition or because on > the keyword difference) and I do prefer the consistency, so all is > good :) > > Cheers, > Mario > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From alvdavi at amazon.com Tue Sep 22 18:30:08 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 22 Sep 2020 11:30:08 -0700 Subject: [11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env In-Reply-To: References: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> Message-ID: Hi Martin, Thanks for taking a look. I assume you mean [1] and [2]. These are not used for registering aliases. [1] is the path used to register a new service and [2] is used to register an attribute. They both fetch the legacyMap because they can also be used to modify an existing value (either the class for an algorithm or the value of an attribute). It seems to me that registering an alias for a service you have not registered is a fairly valid scenario (and that is the one mentioned in the ticket). But I'm not sure if the other two scenarios should be considered too. In theory, only the one registering the service should be setting the class or attribute values. In any case, my opinion can be swayed if other people think we should support modifying these through the legacy api too. David -- [1] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/e872676174c7/src/java.base/share/classes/java/security/Provider.java#l1212 [2] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/e872676174c7/src/java.base/share/classes/java/security/Provider.java#l1237 On 2020-09-22 07:44, Martin Balao wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi, > > Thanks for having a look at this. > > On Fri, Sep 18, 2020 at 8:01 PM David Alvarez wrote: >> Please review the following patch for 8250787, a p2 present in >> 11.0.9-oracle we are still missing. >> >> webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8250787 >> >> The problem is related to the registration of aliases in the >> java.security.Provider. Provider holds two maps, one for services >> registered using the old Provider.put (legacyMap) method and one for >> holding services registered with the newer Provider.putService >> (serviceMap). It seems that has been the case since 1.5, but it was not >> a problem until recently, as the default services were still added using >> the old Provider.put. JDK-7092821 [1] changed that, making the default >> providers use Provider.putService instead of Provider.put, and >> uncovering this latent problem. >> >> The fix is a small one, make sure that parseLegacyPut looks into both >> maps when adding a new alias. Patch pases jdk tier1 and tier2 and a test >> is included. >> > > I've seen that entries from the legacyMap are also retrieved in 2 > additional paths within Provider::parseLegacyPut. Don't we need to get > the Service from the new map if the previous fails? Looks to me that > these 2 additional paths are different ways of describing the alias. > > Thanks, > Martin.- > From mbalao at redhat.com Tue Sep 22 19:11:00 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 22 Sep 2020 16:11:00 -0300 Subject: [11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env In-Reply-To: References: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> Message-ID: Hi David, On Tue, Sep 22, 2020 at 3:31 PM David Alvarez wrote: > These are not used for registering aliases. [1] is the path used to > register a new service and [2] is used to register an attribute. They > both fetch the legacyMap because they can also be used to modify an > existing value (either the class for an algorithm or the value of an > attribute). Thanks for your clarification. I see your point. It should be possible to have a service registered twice (same name, different impl classes eventually): once with the putService API and once with the legacy API. Same for a service attribute. But this is unsupported: we are not expecting this information to be sync. Ok, looks good to me. Thanks, Martin.- From alvdavi at amazon.com Tue Sep 22 21:54:37 2020 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 22 Sep 2020 14:54:37 -0700 Subject: [11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env In-Reply-To: References: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> Message-ID: <84113ab0-a145-baae-21b5-7a9bcc601d73@amazon.com> Hi Martin, Indeed, having a service registered twice is possible since the dual map was added. I've checked this behavior in the current version (add two services with the same algorithm, different class and then use Provider.put to add an alias). Requesting the algorithm will return the one that was registered with putService. Requesting the alias will also return the one registered with putService. However, some problems: - Enumerating all the services via getServices will return both services - The service registered with putService will have an empty aliases list - The service registered with put will have the registered alias in the aliases list The fact that you can register two services with the same name is not what this patch is fixing, but we might make the behavior a bit more consistent if we make it so we look into the serviceMap before we look into the legacyMap when we add aliases. At least, that way the service that is returned when requesting the alias will have the aliases list populated. I've created an updated webrev with this version: http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.01/ David On 2020-09-22 12:11, Martin Balao wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi David, > > On Tue, Sep 22, 2020 at 3:31 PM David Alvarez wrote: >> These are not used for registering aliases. [1] is the path used to >> register a new service and [2] is used to register an attribute. They >> both fetch the legacyMap because they can also be used to modify an >> existing value (either the class for an algorithm or the value of an >> attribute). > > Thanks for your clarification. I see your point. It should be possible > to have a service registered twice (same name, different impl classes > eventually): once with the putService API and once with the legacy > API. Same for a service attribute. But this is unsupported: we are not > expecting this information to be sync. > > Ok, looks good to me. > > Thanks, > Martin.- > From christoph.langer at sap.com Wed Sep 23 07:15:53 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 23 Sep 2020 07:15:53 +0000 Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling vector register Message-ID: Hi Nick, I'm coming back to this one. I think your mail below was intended first and foremost as an RFR mail - the question for a sponsor should have been raised afterwards. ?? In any case, the change looks correct to me. I'll run it through our test system and then sponsor it for you. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Nick Gasson > Sent: Freitag, 24. Juli 2020 07:57 > To: jdk-updates-dev at openjdk.java.net > Subject: [SUSPECTED SPAM] [11u] RFR: 8248845: AArch64: stack corruption > after spilling vector register > > Hi, > > Is anyone able to sponsor this backport for me? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248845 > Original change: https://hg.openjdk.java.net/jdk/jdk15/rev/d5be95758352 > Review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler- > dev/2020-July/038886.html > > The patch does not apply cleanly on 11u as the ScheduleAndBundle > function has been moved and renamed. I've prepared another webrev that > applies on 11u: > > http://cr.openjdk.java.net/~ngasson/8248845/webrev.11u.0/ > > Tested tier1 on AArch64. > > -- > Thanks, > Nick From shade at redhat.com Wed Sep 23 07:16:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Sep 2020 09:16:22 +0200 Subject: [11u] RFR 8250605: Linux x86_32 builds fail after JDK-8249821 Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8250605 https://hg.openjdk.java.net/jdk/jdk/rev/1a722ad6e23d Now that JDK-8249821 is backported to 11u, Linux x86_32 and ARM32 builds fail. 11u variant applies to a different file: diff -r b65a84ce3601 make/lib/Awt2dLibraries.gmk --- a/make/lib/Awt2dLibraries.gmk Tue Jul 28 09:05:36 2020 +0200 +++ b/make/lib/Awt2dLibraries.gmk Wed Sep 23 09:14:26 2020 +0200 @@ -673,11 +673,11 @@ CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBFONTMANAGER_CFLAGS), \ OPTIMIZATION := $(LIBFONTMANAGER_OPTIMIZATION), \ CFLAGS_windows = -DCC_NOEX, \ EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ WARNINGS_AS_ERRORS_xlc := false, \ - DISABLED_WARNINGS_gcc := sign-compare unused-function, \ + DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast, \ DISABLED_WARNINGS_clang := sign-compare, \ DISABLED_WARNINGS_C_solstudio := \ E_INTEGER_OVERFLOW_DETECTED \ E_ARG_INCOMPATIBLE_WITH_ARG_L \ E_ENUM_VAL_OVERFLOWS_INT_MAX, \ Testing: x86_32 build -- Thanks, -Aleksey From nick.gasson at arm.com Wed Sep 23 07:22:52 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 23 Sep 2020 15:22:52 +0800 Subject: [11u] RFR: 8248845: AArch64: stack corruption after spilling vector register In-Reply-To: References: Message-ID: <85imc59ctv.fsf@nicgas01-pc.shanghai.arm.com> Hi Christoph, On 09/23/20 15:15 pm, Langer, Christoph wrote: > > I'm coming back to this one. I think your mail below was intended first and foremost as an RFR mail - the question for a sponsor should have been raised afterwards. ?? > > In any case, the change looks correct to me. I'll run it through our test system and then sponsor it for you. > Thanks for helping with this. Sorry I messed up the process :-). -- Nick From shade at redhat.com Wed Sep 23 10:30:08 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Sep 2020 12:30:08 +0200 Subject: [11u] RFR (S) 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8245051 https://hg.openjdk.java.net/jdk/jdk/rev/497fd9f9129c The patch does not apply cleanly, because context is different. I reapplied hunks by hand. Field initializers need to follow the declaration order, as to not disturb -Wreorder. 11u variant: https://cr.openjdk.java.net/~shade/8245051/webrev.11u.01/ Testing: tier{1,2} -- Thanks, -Aleksey From rwestberg at openjdk.java.net Wed Sep 23 11:15:57 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 23 Sep 2020 11:15:57 GMT Subject: [jdk13u-dev] RFR: 8253528: Update .jcheck/conf for jdk13u-dev Message-ID: Hi all, Please review this initial jcheck configuration for use with the Skara tooling. Best regards, Robin ------------- Commit messages: - Initial jcheck Changes: https://git.openjdk.java.net/jdk13u-dev/pull/1/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=1&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253528 Stats: 27 lines in 1 file changed: 25 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/1.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/1/head:pull/1 PR: https://git.openjdk.java.net/jdk13u-dev/pull/1 From yan at openjdk.java.net Wed Sep 23 12:02:30 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 23 Sep 2020 12:02:30 GMT Subject: [jdk13u-dev] RFR: 8253528: Update .jcheck/conf for jdk13u-dev In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 10:09:20 GMT, Robin Westberg wrote: > Hi all, > > Please review this initial jcheck configuration for use with the Skara tooling. > > Best regards, > Robin Marked as reviewed by yan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/1 From yan at openjdk.java.net Wed Sep 23 12:10:05 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 23 Sep 2020 12:10:05 GMT Subject: [jdk13u-dev] RFR: 8253528: Update .jcheck/conf for jdk13u-dev In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 11:59:13 GMT, Yuri Nesterenko wrote: >> Hi all, >> >> Please review this initial jcheck configuration for use with the Skara tooling. >> >> Best regards, >> Robin > > Marked as reviewed by yan (Reviewer). Note that the first line looks rwestberg wants to merge 1 commit into openjdk:master while the link is, as expected, https://github.com/openjdk/jdk13u-dev Not a big deal though, the name of repo is everywhere ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/1 From ehelin at openjdk.java.net Wed Sep 23 12:45:38 2020 From: ehelin at openjdk.java.net (Erik Helin) Date: Wed, 23 Sep 2020 12:45:38 GMT Subject: [jdk13u-dev] RFR: 8253528: Update .jcheck/conf for jdk13u-dev In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 10:09:20 GMT, Robin Westberg wrote: > Hi all, > > Please review this initial jcheck configuration for use with the Skara tooling. > > Best regards, > Robin Looks good! ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/1 From rwestberg at openjdk.java.net Wed Sep 23 13:17:17 2020 From: rwestberg at openjdk.java.net (Robin Westberg) Date: Wed, 23 Sep 2020 13:17:17 GMT Subject: [jdk13u-dev] Integrated: 8253528: Update .jcheck/conf for jdk13u-dev In-Reply-To: References: Message-ID: On Wed, 23 Sep 2020 10:09:20 GMT, Robin Westberg wrote: > Hi all, > > Please review this initial jcheck configuration for use with the Skara tooling. > > Best regards, > Robin This pull request has now been integrated. Changeset: e13ab22b Author: Robin Westberg URL: https://git.openjdk.java.net/jdk13u-dev/commit/e13ab22b Stats: 27 lines in 1 file changed: 0 ins; 25 del; 2 mod 8253528: Update .jcheck/conf for jdk13u-dev Reviewed-by: yan, ehelin ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/1 From mbalao at redhat.com Wed Sep 23 14:26:50 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 23 Sep 2020 11:26:50 -0300 Subject: [11.0.9u] RFR (XS) 8250787: Provider.put no longer registering aliases in FIPS env In-Reply-To: <84113ab0-a145-baae-21b5-7a9bcc601d73@amazon.com> References: <06da15db-f082-17b3-d5a0-4525f8bdb622@amazon.com> <84113ab0-a145-baae-21b5-7a9bcc601d73@amazon.com> Message-ID: On Tue, Sep 22, 2020 at 7:46 PM David Alvarez wrote: > Indeed, having a service registered twice is possible since the dual map > was added. I've checked this behavior in the current version (add two > services with the same algorithm, different class and then use > Provider.put to add an alias). > > Requesting the algorithm will return the one that was registered with > putService. Requesting the alias will also return the one registered > with putService. > > However, some problems: > - Enumerating all the services via getServices will return both services > - The service registered with putService will have an empty aliases list > - The service registered with put will have the registered alias in the > aliases list Thanks for investigating these cases. > > The fact that you can register two services with the same name is not > what this patch is fixing, but we might make the behavior a bit more > consistent if we make it so we look into the serviceMap before we look > into the legacyMap when we add aliases. At least, that way the service > that is returned when requesting the alias will have the aliases list > populated. > > I've created an updated webrev with this version: > http://cr.openjdk.java.net/~alvdavi/webrevs/8250787/webrev.11u.01/ > Even if not critical, I agree that it's more consistent. Webrev.01 looks good to me. From hohensee at amazon.com Wed Sep 23 16:45:58 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 23 Sep 2020 16:45:58 +0000 Subject: [11u] RFR (S) 8245051: c1 is broken if it is compiled by gcc without -fno-lifetime-dse Message-ID: <0086D2BE-B0D9-4734-AE3B-7E7B9CE73CF8@amazon.com> Lgtm. Thanks, Paul ?On 9/23/20, 3:33 AM, "jdk-updates-dev on behalf of Aleksey Shipilev" wrote: Original bug: https://bugs.openjdk.java.net/browse/JDK-8245051 https://hg.openjdk.java.net/jdk/jdk/rev/497fd9f9129c The patch does not apply cleanly, because context is different. I reapplied hunks by hand. Field initializers need to follow the declaration order, as to not disturb -Wreorder. 11u variant: https://cr.openjdk.java.net/~shade/8245051/webrev.11u.01/ Testing: tier{1,2} -- Thanks, -Aleksey From katya at azul.com Wed Sep 23 21:09:53 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Wed, 23 Sep 2020 21:09:53 +0000 Subject: [11u] RFR: 8208677: Move inner metaspace cleaning out of class unloading Message-ID: <3f386b3bfefe471f8a7bbd73e6bb9427@azul.com> Hello, I would like to backport 8208677 to 11u as a prerequisite for 8210422. 8210422 fixes the crash described in 8251945 that is already fixed in 11.0.10-oracle. The full list of suggested prerequisites is specified in [1]. JBS: https://bugs.openjdk.java.net/browse/JDK-8208677 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/aa3bfacc912c Webrev for 11u: https://cr.openjdk.java.net/~apetushkov/8208677/webrev.00/ The patch applies almost cleanly except for the change in src/hotspot/share/code/nmethod.cpp. It is already included in 11u by 8220718. Tested with tier1; the full list of backports specified in [1] is tested with full regression. Thanks, Ekaterina [1] https://bugs.openjdk.java.net/browse/JDK-8251945?focusedCommentId=14363860&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14363860 From goetz.lindenmaier at sap.com Thu Sep 24 06:59:02 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 24 Sep 2020 06:59:02 +0000 Subject: [11u] RFR: 8249602: C2: assert(cnt == _outcnt) failed: no insertions allowed In-Reply-To: References: Message-ID: Hi Martin, Thanks for reviewing! Best regards, Goetz -----Original Message----- From: Doerr, Martin Sent: Dienstag, 22. September 2020 15:10 To: Lindenmaier, Goetz ; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8249602: C2: assert(cnt == _outcnt) failed: no insertions allowed Hi G?tz, looks good. Thanks for backporting. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 22. September 2020 09:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR: 8249602: C2: assert(cnt == _outcnt) failed: no > insertions allowed > > Hi > > Only trivial resolves because of whitespace and the 'a' argument to clones() > in the context. > http://cr.openjdk.java.net/~goetz/wr20/8249602-C2_insertions-jdk11/01/ > > Please review. > > https://bugs.openjdk.java.net/browse/JDK-8249602 > https://hg.openjdk.java.net/jdk/jdk/rev/b7dda1eda100 > > Best regards, > Goetz. From shade at redhat.com Thu Sep 24 07:06:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 24 Sep 2020 09:06:56 +0200 Subject: [11u] RFR (XS) 8253224: Shenandoah: ShenandoahStrDedupQueue destructor calls virtual num_queues() Message-ID: <004e7d93-e6f0-6215-17e6-35b08547ea58@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8253224 https://git.openjdk.java.net/jdk/commit/c781594b This is the first backport after moving to Git, so the changeset is generated with "git hg-export". It also does not apply cleanly, because the context changed a bit. 11u variant: diff -r dd09e5aaa34e src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp --- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp Fri Aug 24 09:38:11 2018 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp Thu Sep 24 09:06:32 2020 +0200 @@ -50,5 +50,5 @@ ShenandoahStrDedupQueue::~ShenandoahStrDedupQueue() { MonitorLockerEx ml(StringDedupQueue_lock, Mutex::_no_safepoint_check_flag); - for (size_t index = 0; index < num_queues(); index ++) { + for (size_t index = 0; index < num_queues_nv(); index ++) { release_buffers(queue_at(index)); } diff -r dd09e5aaa34e src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp --- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp Fri Aug 24 09:38:11 2018 +0200 +++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp Thu Sep 24 09:06:32 2020 +0200 @@ -95,7 +95,9 @@ protected: - size_t num_queues() const { return (_num_producer_queue + 2); } + size_t num_queues() const { return num_queues_nv(); } private: + inline size_t num_queues_nv() const { return (_num_producer_queue + 2); } + ShenandoahQueueBuffer* new_buffer(); Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From zgu at redhat.com Thu Sep 24 12:03:21 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 24 Sep 2020 08:03:21 -0400 Subject: [11u] RFR (XS) 8253224: Shenandoah: ShenandoahStrDedupQueue destructor calls virtual num_queues() In-Reply-To: <004e7d93-e6f0-6215-17e6-35b08547ea58@redhat.com> References: <004e7d93-e6f0-6215-17e6-35b08547ea58@redhat.com> Message-ID: Looks good. Thanks, -Zhengyu On 9/24/20 3:06 AM, Aleksey Shipilev wrote: > Original fix: > ? https://bugs.openjdk.java.net/browse/JDK-8253224 > ? https://git.openjdk.java.net/jdk/commit/c781594b > > This is the first backport after moving to Git, so the changeset is > generated with "git hg-export". It also does not apply cleanly, because > the context changed a bit. > > 11u variant: > > diff -r dd09e5aaa34e > src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp > Fri Aug 24 09:38:11 2018 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.cpp > Thu Sep 24 09:06:32 2020 +0200 > @@ -50,5 +50,5 @@ > ?ShenandoahStrDedupQueue::~ShenandoahStrDedupQueue() { > ?? MonitorLockerEx ml(StringDedupQueue_lock, > Mutex::_no_safepoint_check_flag); > -? for (size_t index = 0; index < num_queues(); index ++) { > +? for (size_t index = 0; index < num_queues_nv(); index ++) { > ???? release_buffers(queue_at(index)); > ?? } > diff -r dd09e5aaa34e > src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp > --- a/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp > Fri Aug 24 09:38:11 2018 +0200 > +++ b/src/hotspot/share/gc/shenandoah/shenandoahStrDedupQueue.hpp > Thu Sep 24 09:06:32 2020 +0200 > @@ -95,7 +95,9 @@ > > ?protected: > -? size_t num_queues() const { return (_num_producer_queue + 2); } > +? size_t num_queues() const { return num_queues_nv(); } > > ?private: > +? inline size_t num_queues_nv() const { return (_num_producer_queue + > 2); } > + > ?? ShenandoahQueueBuffer* new_buffer(); > > > Testing: hotspot_gc_shenandoah > > From maoliang.ml at alibaba-inc.com Fri Sep 25 06:42:43 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Fri, 25 Sep 2020 14:42:43 +0800 Subject: =?UTF-8?B?WzExdV0gQmFja3BvcnQgSkVQIDM0NiA6IFByb21wdGx5IFJldHVybiBVbnVzZWQgQ29tbWl0?= =?UTF-8?B?dGVkIE1lbW9yeSBmcm9tIEcx?= In-Reply-To: References: Message-ID: <6918634b-c340-495f-8c06-d09649d52755.maoliang.ml@alibaba-inc.com> Hi Developers, I would like to refresh this backport too. As Ruslan's description, this JEP provides a very convenient way to save significant memory for popular applications like Jenkins. Alibaba's JDK11 already had this feature and used it in workloads like big data engines for months. The effect of memory saving is impressive. Alibaba keeps migrating our Java applications to JDK11 and G1. We will surely maintain the quality of the feature as we continues to report/discuss issues of G1 and backport G1 bug fixes. SAP and Microsoft are interested in this feature during last discussion and willing to maintain it as well. The JEP only contains 4 small to medium patches and 6 tiny to small fixes. With communitie's review(Oracle G1 team agreed to help) and experienced JVM developers from several big companies and testing on various workloads and scenarios, I believe the quality is definitely controllable. I have been managing thousands of Java applications/millions of Java instances and helping them to upgrade JDK and GC including different types of worloads like online services, big data platforms, batch jobs, etc. It's really painful for owners of Java applications to upgrate their JDK version to a larger number, especially for those big applications with a lot of 3rd party packages. Letting JDK11 LTS have such small feature with significant effect would benifit most of users. All changes of the JEP only contains of hunderds lines of code: http://cr.openjdk.java.net/~lmao/jep346.11u/all.webrev.00/ Here are the 10 changesets needs backport and 3 of them have conflicts: 1) JDK-8071913 http://cr.openjdk.java.net/~lmao/jep346.11u/8071913.webrev.00/ 2) JDK-6490394 3) JDK-8213898 4) JDK-8212657 http://cr.openjdk.java.net/~lmao/jep346.11u/8212657.webrev.00/ 5) JDK-8215120 6) JDK-8215149 7) JDK-8215548 8) JDK-8216490 9) JDK-8218880 http://cr.openjdk.java.net/~lmao/jep346.11u/8218880.webrev.00/ 10) JDK-8212883 Tested with tier1/fastdebug. BTW, I will file an CSR for the new options added if maintainers agree. Any questions? Thanks, Liang > -----Original Message----- > From: jdk-updates-dev [mailto:jdk-updates-dev-retn at openjdk.java.net] On > Behalf Of Ruslan Synytsky > Sent: 2020?8?7? 1:00 > To: jdk-updates-dev > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > Memory from G1 > > Hi All, I would like to refresh this topic by sharing a very simple example that > demonstrates why Java looks broken without this improvement. > > Jenkins is one of the most popular CI/CD tools. Unfortunately it supports only > Java 8 and Java 11 > . If you start a > simple standalone Jenkins instance and *just sign in* inside the admin panel then > the JVM will start consuming a significant amount of memory immediately. In > my case I had the following limits: container limit > - 8G, heap limit (Xmx) - 6.5G and the memory consumption after the sign in > action got to 3G. By default all Java runtimes lower than Java 12 within Jelastic > are supplied with our Java agent (which is a workaround) that tracks memory > usage and if this agent detects a significant waste it calls full GC. After this full > GC call the memory consumption goes down to 0.5G (check the screenshot) > usage/master/images/jenkins-memory-usage-diff.png>. > If we disable our agent then the memory usage at the idle JVM will stay at 3G > forever which is a waste of resources > usage/master/images/jenkins-memory-usage-waste.png>. > If you put additional load on Jenkins the picture will look even worse. > > Usually one large host node runs hundreds of containers, and one cloud cluster > may consist of tens, hundreds or thousands of host nodes, so the issue multiplies. > And the case with Jenkins is just one of the examples. > I'm pretty sure this inefficient memory usage issue was damaging the Java brand > for many years and a lot of developers believe that Java is too heavy. Is not it a > strong reason to bring the fix to Java 11? > > Thanks > -- > Ruslan Synytsky > CEO @ Jelastic Multi-Cloud PaaS From yan at openjdk.java.net Fri Sep 25 08:49:22 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 25 Sep 2020 08:49:22 GMT Subject: [jdk13u-dev] RFR: 8253632: Bump update version for OpenJDK: jdk-13.0.6 Message-ID: <4cu-8AAB-Isf0GQv1lh809QrxcfzKs7C9YayqGwSFYM=.83b00047-e3cd-43a0-acab-b3e652a308e4@github.com> As usual, to continue development of jdk13u, we need to _bump_ some default numbers before opening the team repository for the next release. ------------- Commit messages: - 8253632: Bump update version for OpenJDK: jdk-13.0.6 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253632 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/2/head:pull/2 PR: https://git.openjdk.java.net/jdk13u-dev/pull/2 From bae at openjdk.java.net Fri Sep 25 09:50:26 2020 From: bae at openjdk.java.net (Andrew Brygin) Date: Fri, 25 Sep 2020 09:50:26 GMT Subject: [jdk13u-dev] RFR: 8253632: Bump update version for OpenJDK: jdk-13.0.6 In-Reply-To: <4cu-8AAB-Isf0GQv1lh809QrxcfzKs7C9YayqGwSFYM=.83b00047-e3cd-43a0-acab-b3e652a308e4@github.com> References: <4cu-8AAB-Isf0GQv1lh809QrxcfzKs7C9YayqGwSFYM=.83b00047-e3cd-43a0-acab-b3e652a308e4@github.com> Message-ID: <0GduGgppfa2nrHIh3KkhDef_XYNC06KeJgTQpp2P9yY=.858124cd-4f22-46e4-89e5-2147977af277@github.com> On Fri, 25 Sep 2020 08:40:50 GMT, Yuri Nesterenko wrote: > As usual, to continue development of jdk13u, we need to _bump_ some default numbers before opening the team repository > for the next release. Looks fine to me. ------------- Marked as reviewed by bae (Reviewer). PR: https://git.openjdk.java.net/jdk13u-dev/pull/2 From yan at openjdk.java.net Fri Sep 25 09:50:26 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Fri, 25 Sep 2020 09:50:26 GMT Subject: [jdk13u-dev] Integrated: 8253632: Bump update version for OpenJDK: jdk-13.0.6 In-Reply-To: <4cu-8AAB-Isf0GQv1lh809QrxcfzKs7C9YayqGwSFYM=.83b00047-e3cd-43a0-acab-b3e652a308e4@github.com> References: <4cu-8AAB-Isf0GQv1lh809QrxcfzKs7C9YayqGwSFYM=.83b00047-e3cd-43a0-acab-b3e652a308e4@github.com> Message-ID: On Fri, 25 Sep 2020 08:40:50 GMT, Yuri Nesterenko wrote: > As usual, to continue development of jdk13u, we need to _bump_ some default numbers before opening the team repository > for the next release. This pull request has now been integrated. Changeset: 4c5e889c Author: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/4c5e889c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8253632: Bump update version for OpenJDK: jdk-13.0.6 Reviewed-by: bae ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/2 From yan at azul.com Fri Sep 25 10:50:21 2020 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 25 Sep 2020 13:50:21 +0300 Subject: [13u notice] jdk13u-dev open in GitHub Message-ID: Hi all, almost as planned [1], we have completed transition of jdk13u-dev team repository to Git. Now it is in https://github.com/openjdk/jdk13u-dev and open for backports targeted for January, 2021 release (13.0.6). The master jdk13u is still in Mercurial at least until after October release (Nov 5 is estimation). The workflow for simple backports is not clear for me yet. Let's consider it work in progress. Regularly, for a backport without merge conflicts/updates it is enough to explain the need in JBS comment, set jdk13u-fix-request label there, get jdk13u-fix-yes, and push. In the new Skara workflow on GitHub [2], a review of a pull request seems always necessary. The attribution conventions also may be different and require discussion. Let's try! Thanks, --yan [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-August/003643.html [2] https://wiki.openjdk.java.net/display/SKARA From goetz.lindenmaier at sap.com Mon Sep 28 07:34:11 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 28 Sep 2020 07:34:11 +0000 Subject: jdk-15-ga tag not in jdk15u Message-ID: Hi, I would appreciate if you could pull the tag jdk-15-ga to jdk-updates/jdk15u. Without that, it's not obvious whether all changes that went into 15 are also in the 15u repo. Also, you get two heads if you pull from both repos. Thanks and best regards, Goetz. From shade at redhat.com Mon Sep 28 07:37:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 28 Sep 2020 09:37:37 +0200 Subject: [11u] RFR 8250605: Linux x86_32 builds fail after JDK-8249821 In-Reply-To: References: Message-ID: <59dd8bfb-bbf0-44a0-e00f-4a248fa24d0e@redhat.com> On 9/23/20 9:16 AM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8250605 > https://hg.openjdk.java.net/jdk/jdk/rev/1a722ad6e23d > > Now that JDK-8249821 is backported to 11u, Linux x86_32 and ARM32 builds fail. > > 11u variant applies to a different file: > > diff -r b65a84ce3601 make/lib/Awt2dLibraries.gmk > --- a/make/lib/Awt2dLibraries.gmk Tue Jul 28 09:05:36 2020 +0200 > +++ b/make/lib/Awt2dLibraries.gmk Wed Sep 23 09:14:26 2020 +0200 > @@ -673,11 +673,11 @@ > CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBFONTMANAGER_CFLAGS), \ > OPTIMIZATION := $(LIBFONTMANAGER_OPTIMIZATION), \ > CFLAGS_windows = -DCC_NOEX, \ > EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ > WARNINGS_AS_ERRORS_xlc := false, \ > - DISABLED_WARNINGS_gcc := sign-compare unused-function, \ > + DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast, \ > DISABLED_WARNINGS_clang := sign-compare, \ > DISABLED_WARNINGS_C_solstudio := \ > E_INTEGER_OVERFLOW_DETECTED \ > E_ARG_INCOMPATIBLE_WITH_ARG_L \ > E_ENUM_VAL_OVERFLOWS_INT_MAX, \ > > Testing: x86_32 build Friendly reminder. -- Thanks, -Aleksey From christoph.langer at sap.com Mon Sep 28 08:46:55 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 28 Sep 2020 08:46:55 +0000 Subject: [11u] RFR 8250605: Linux x86_32 builds fail after JDK-8249821 In-Reply-To: <59dd8bfb-bbf0-44a0-e00f-4a248fa24d0e@redhat.com> References: <59dd8bfb-bbf0-44a0-e00f-4a248fa24d0e@redhat.com> Message-ID: Hi Aleksey, looks good ?? Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Montag, 28. September 2020 09:38 > To: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR 8250605: Linux x86_32 builds fail after JDK-8249821 > > On 9/23/20 9:16 AM, Aleksey Shipilev wrote: > > Original fix: > > https://bugs.openjdk.java.net/browse/JDK-8250605 > > https://hg.openjdk.java.net/jdk/jdk/rev/1a722ad6e23d > > > > Now that JDK-8249821 is backported to 11u, Linux x86_32 and ARM32 builds > fail. > > > > 11u variant applies to a different file: > > > > diff -r b65a84ce3601 make/lib/Awt2dLibraries.gmk > > --- a/make/lib/Awt2dLibraries.gmk Tue Jul 28 09:05:36 2020 +0200 > > +++ b/make/lib/Awt2dLibraries.gmk Wed Sep 23 09:14:26 2020 +0200 > > @@ -673,11 +673,11 @@ > > CXXFLAGS := $(CXXFLAGS_JDKLIB) $(LIBFONTMANAGER_CFLAGS), \ > > OPTIMIZATION := $(LIBFONTMANAGER_OPTIMIZATION), \ > > CFLAGS_windows = -DCC_NOEX, \ > > EXTRA_HEADER_DIRS := $(LIBFONTMANAGER_EXTRA_HEADER_DIRS), \ > > WARNINGS_AS_ERRORS_xlc := false, \ > > - DISABLED_WARNINGS_gcc := sign-compare unused-function, \ > > + DISABLED_WARNINGS_gcc := sign-compare unused-function int-to- > pointer-cast, \ > > DISABLED_WARNINGS_clang := sign-compare, \ > > DISABLED_WARNINGS_C_solstudio := \ > > E_INTEGER_OVERFLOW_DETECTED \ > > E_ARG_INCOMPATIBLE_WITH_ARG_L \ > > E_ENUM_VAL_OVERFLOWS_INT_MAX, \ > > > > Testing: x86_32 build > > Friendly reminder. > > -- > Thanks, > -Aleksey From jesper.wilhelmsson at oracle.com Mon Sep 28 15:30:01 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 28 Sep 2020 17:30:01 +0200 Subject: jdk-15-ga tag not in jdk15u In-Reply-To: References: Message-ID: <9D8CEE54-97BD-4F0A-916F-F4CFBA2853D9@oracle.com> Yes, will do. /Jesper > On 28 Sep 2020, at 09:34, Lindenmaier, Goetz wrote: > > Hi, > > I would appreciate if you could pull the tag jdk-15-ga to > jdk-updates/jdk15u. > Without that, it's not obvious whether all changes > that went into 15 are also in the 15u repo. > Also, you get two heads if you pull from both repos. > > Thanks and best regards, > Goetz. From zgu at redhat.com Mon Sep 28 18:59:18 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 28 Sep 2020 14:59:18 -0400 Subject: [11u] RFR 8246381: VM crashes with "Current BasicObjectLock* below than low_mark" Message-ID: <7f04154c-1a41-224b-3758-55f5cbbb1a20@redhat.com> I would like to backport this patch to 11u for parity with Oracle 11.0.10-oracle. The original patch does not apply cleanly, due to an extra leading space of the following lines in the original patch. JRT_ENTRY(void, InterpreterRuntime::profile_method(JavaThread* thread)) + if (HAS_PENDING_EXCEPTION) { + return; + } // use UnlockFlagSaver to clear and restore the _do_not_unlock_if_synchronized // flag, in case this method triggers classloading which will call into Java. UnlockFlagSaver fs(thread); The original bug: https://bugs.openjdk.java.net/browse/JDK-8246381 The original patch: https://hg.openjdk.java.net/jdk/jdk15/rev/f8cffefd6e9b 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8246381-11u/webrev.00/ Thanks, -Zhengyu From hohensee at amazon.com Mon Sep 28 19:41:31 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 28 Sep 2020 19:41:31 +0000 Subject: [11u] RFR 8246381: VM crashes with "Current BasicObjectLock* below than low_mark" Message-ID: <353AFD2B-DF8E-470C-8497-A182B790EFF3@amazon.com> Lgtm. Paul ?On 9/28/20, 12:00 PM, "jdk-updates-dev on behalf of Zhengyu Gu" wrote: I would like to backport this patch to 11u for parity with Oracle 11.0.10-oracle. The original patch does not apply cleanly, due to an extra leading space of the following lines in the original patch. JRT_ENTRY(void, InterpreterRuntime::profile_method(JavaThread* thread)) + if (HAS_PENDING_EXCEPTION) { + return; + } // use UnlockFlagSaver to clear and restore the _do_not_unlock_if_synchronized // flag, in case this method triggers classloading which will call into Java. UnlockFlagSaver fs(thread); The original bug: https://bugs.openjdk.java.net/browse/JDK-8246381 The original patch: https://hg.openjdk.java.net/jdk/jdk15/rev/f8cffefd6e9b 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8246381-11u/webrev.00/ Thanks, -Zhengyu From yan at openjdk.java.net Tue Sep 29 10:23:54 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Tue, 29 Sep 2020 10:23:54 GMT Subject: [jdk13u-dev] RFR: 8253631: Remove unimplemented CompileBroker methods after JEP-165 Message-ID: As stated, remove declarations without any implementations. ------------- Commit messages: - 8253631: Remove unimplemented CompileBroker methods after JEP-165 Changes: https://git.openjdk.java.net/jdk13u-dev/pull/3/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=3&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253631 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk13u-dev/pull/3 From yan at azul.com Tue Sep 29 10:31:23 2020 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 29 Sep 2020 13:31:23 +0300 Subject: [jdk13u-dev] RFR: 8253631: Remove unimplemented CompileBroker methods after JEP-165 In-Reply-To: References: Message-ID: The Skara bots apparently force discussion even for seamlessly applied backport. It's one thing to fix. No reviewer in the generated by default pull request. Let see how about automatically generated backports once we merge... --yan On 29.09.2020 13:23, Yuri Nesterenko wrote: > As stated, remove declarations without any implementations. > > ------------- > > Commit messages: > - 8253631: Remove unimplemented CompileBroker methods after JEP-165 > > Changes: https://git.openjdk.java.net/jdk13u-dev/pull/3/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=3&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8253631 > Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod > Patch: https://git.openjdk.java.net/jdk13u-dev/pull/3.diff > Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/3/head:pull/3 > > PR: https://git.openjdk.java.net/jdk13u-dev/pull/3 > From martin.doerr at sap.com Tue Sep 29 13:10:33 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Sep 2020 13:10:33 +0000 Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi all, we have seen several crashes on several platforms after this change was pushed. Aarch64 example: Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, free space=2041k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x9fb0f8] ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, JfrCheckpointWriter&)+0x208 V [libjvm.so+0x9fb770] StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 V [libjvm.so+0x9fba40] ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, JfrStackTraceRepository&)+0x150 V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, Thread*)+0x160 V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 C [libpthread.so.0+0x7088] start_thread+0xb0 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008 This backport uses a different JfrStackFrame constructor (which was probably unused before): JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno) : _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} It sets _method to NULL! Should probably be: JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno, const Method* method) : _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) {} and: _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); Do you think we can fix this quickly or should we better revert this backport? Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 22. Juni 2020 14:42 > To: Jaroslav Bachor?k ; jdk-updates-dev > ; hotspot-jfr-dev dev at openjdk.java.net> > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > number 0 > > Hi Jaroslav, > > The fix looks good to me. Reviewed. > Please flag the change with jdk11u-fix-request and > add corresponding comment. > > Best regards, > Goetz > > > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaroslav Bachor?k > Sent: Donnerstag, 18. Juni 2020 17:27 > To: jdk-updates-dev ; hotspot-jfr-dev > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > Hi all, > > Could I get this simple fix reviewed? > It is fixing a regression introduced while backporting JDK-823790 and > adding a new test to prevent such regressions in the future. > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > > Thanks, > > -JB- From goetz.lindenmaier at sap.com Tue Sep 29 14:17:09 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Sep 2020 14:17:09 +0000 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 Message-ID: Hi, Any opinion on this? Planned freeze of jd11u is in 2 hours ... Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Tuesday, September 29, 2020 3:11 PM > To: Lindenmaier, Goetz ; Jaroslav Bachor?k > ; jdk-updates-dev dev at openjdk.java.net>; hotspot-jfr-dev > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > Hi all, > > we have seen several crashes on several platforms after this change was > pushed. > > Aarch64 example: > Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, > free space=2041k > Native frames: (J=compiled Java code, A=aot compiled Java code, > j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x9fb0f8] > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, > JfrCheckpointWriter&)+0x208 > V [libjvm.so+0x9fb770] > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 > V [libjvm.so+0x9fba40] > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, > JfrStackTraceRepository&)+0x150 > V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, > Thread*)+0x160 > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 > C [libpthread.so.0+0x7088] start_thread+0xb0 > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > 0x0000000000000008 > > > This backport uses a different JfrStackFrame constructor (which was > probably unused before): > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno) : > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > > It sets _method to NULL! > > Should probably be: > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno, > const Method* method) : > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > > and: > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); > > Do you think we can fix this quickly or should we better revert this backport? > > Best regards, > Martin > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Montag, 22. Juni 2020 14:42 > > To: Jaroslav Bachor?k ; jdk-updates- > dev > > ; hotspot-jfr-dev > dev at openjdk.java.net> > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > > number 0 > > > > Hi Jaroslav, > > > > The fix looks good to me. Reviewed. > > Please flag the change with jdk11u-fix-request and > > add corresponding comment. > > > > Best regards, > > Goetz > > > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Jaroslav Bachor?k > > Sent: Donnerstag, 18. Juni 2020 17:27 > > To: jdk-updates-dev ; hotspot-jfr-dev > > > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > Hi all, > > > > Could I get this simple fix reviewed? > > It is fixing a regression introduced while backporting JDK-823790 and > > adding a new test to prevent such regressions in the future. > > > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > > > > Thanks, > > > > -JB- From thomas.stuefe at gmail.com Tue Sep 29 15:01:03 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Sep 2020 17:01:03 +0200 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi Goetz, not a JFR expert, but I had a look at the code both in head and in 11u. While the fix proposed by Martin seems sufficient, I would rather roll back the initial commit. The code in question in head had been rewritten in jdk14 for https://bugs.openjdk.java.net/browse/JDK-8236743 which fixes a problem with tracing code via JFR when classes are redefined. As a side effect it also fixes the original issue fixed by 8244287 by passing the line number to the constructor. I would rather go back to a stable point and later integrate JDK-8236743. Cheers Thomas On Tue, Sep 29, 2020 at 4:18 PM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi, > > Any opinion on this? > Planned freeze of jd11u is in 2 hours ... > > Best regards, > Goetz. > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Tuesday, September 29, 2020 3:11 PM > > To: Lindenmaier, Goetz ; Jaroslav Bachor?k > > ; jdk-updates-dev > dev at openjdk.java.net>; hotspot-jfr-dev > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > Hi all, > > > > we have seen several crashes on several platforms after this change was > > pushed. > > > > Aarch64 example: > > Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, > > free space=2041k > > Native frames: (J=compiled Java code, A=aot compiled Java code, > > j=interpreted, Vv=VM code, C=native code) > > V [libjvm.so+0x9fb0f8] > > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, > > JfrCheckpointWriter&)+0x208 > > V [libjvm.so+0x9fb770] > > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 > > V [libjvm.so+0x9fba40] > > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, > > JfrStackTraceRepository&)+0x150 > > V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 > > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 > > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 > > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, > > Thread*)+0x160 > > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 > > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 > > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 > > C [libpthread.so.0+0x7088] start_thread+0xb0 > > > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > > 0x0000000000000008 > > > > > > This backport uses a different JfrStackFrame constructor (which was > > probably unused before): > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > lineno) : > > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > > > > It sets _method to NULL! > > > > Should probably be: > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > lineno, > > const Method* method) : > > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) > {} > > > > and: > > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); > > > > Do you think we can fix this quickly or should we better revert this > backport? > > > > Best regards, > > Martin > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Lindenmaier, Goetz > > > Sent: Montag, 22. Juni 2020 14:42 > > > To: Jaroslav Bachor?k ; jdk-updates- > > dev > > > ; hotspot-jfr-dev > > dev at openjdk.java.net> > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > > > number 0 > > > > > > Hi Jaroslav, > > > > > > The fix looks good to me. Reviewed. > > > Please flag the change with jdk11u-fix-request and > > > add corresponding comment. > > > > > > Best regards, > > > Goetz > > > > > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Jaroslav Bachor?k > > > Sent: Donnerstag, 18. Juni 2020 17:27 > > > To: jdk-updates-dev ; > hotspot-jfr-dev > > > > > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > > > Hi all, > > > > > > Could I get this simple fix reviewed? > > > It is fixing a regression introduced while backporting JDK-823790 and > > > adding a new test to prevent such regressions in the future. > > > > > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > > > > > > Thanks, > > > > > > -JB- > From jaroslav.bachorik at datadoghq.com Tue Sep 29 16:02:23 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 29 Sep 2020 18:02:23 +0200 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi Goetz, I support rolling back the commit. Will you do it or should I initiate the process? Regards, -JB- On Tue, Sep 29, 2020 at 5:01 PM Thomas St?fe wrote: > > Hi Goetz, > > not a JFR expert, but I had a look at the code both in head and in 11u. > > While the fix proposed by Martin seems sufficient, I would rather roll back the initial commit. The code in question in head had been rewritten in jdk14 for https://bugs.openjdk.java.net/browse/JDK-8236743 which fixes a problem with tracing code via JFR when classes are redefined. As a side effect it also fixes the original issue fixed by 8244287 by passing the line number to the constructor. I would rather go back to a stable point and later integrate JDK-8236743. > > Cheers Thomas > > > > On Tue, Sep 29, 2020 at 4:18 PM Lindenmaier, Goetz wrote: >> >> Hi, >> >> Any opinion on this? >> Planned freeze of jd11u is in 2 hours ... >> >> Best regards, >> Goetz. >> >> > -----Original Message----- >> > From: Doerr, Martin >> > Sent: Tuesday, September 29, 2020 3:11 PM >> > To: Lindenmaier, Goetz ; Jaroslav Bachor?k >> > ; jdk-updates-dev > > dev at openjdk.java.net>; hotspot-jfr-dev >> > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line number 0 >> > >> > Hi all, >> > >> > we have seen several crashes on several platforms after this change was >> > pushed. >> > >> > Aarch64 example: >> > Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, >> > free space=2041k >> > Native frames: (J=compiled Java code, A=aot compiled Java code, >> > j=interpreted, Vv=VM code, C=native code) >> > V [libjvm.so+0x9fb0f8] >> > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, >> > JfrCheckpointWriter&)+0x208 >> > V [libjvm.so+0x9fb770] >> > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 >> > V [libjvm.so+0x9fba40] >> > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, >> > JfrStackTraceRepository&)+0x150 >> > V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 >> > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 >> > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 >> > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, >> > Thread*)+0x160 >> > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 >> > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 >> > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 >> > C [libpthread.so.0+0x7088] start_thread+0xb0 >> > >> > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: >> > 0x0000000000000008 >> > >> > >> > This backport uses a different JfrStackFrame constructor (which was >> > probably unused before): >> > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno) : >> > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} >> > >> > It sets _method to NULL! >> > >> > Should probably be: >> > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno, >> > const Method* method) : >> > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) {} >> > >> > and: >> > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); >> > >> > Do you think we can fix this quickly or should we better revert this backport? >> > >> > Best regards, >> > Martin >> > >> > >> > > -----Original Message----- >> > > From: jdk-updates-dev On >> > > Behalf Of Lindenmaier, Goetz >> > > Sent: Montag, 22. Juni 2020 14:42 >> > > To: Jaroslav Bachor?k ; jdk-updates- >> > dev >> > > ; hotspot-jfr-dev > > > dev at openjdk.java.net> >> > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line >> > > number 0 >> > > >> > > Hi Jaroslav, >> > > >> > > The fix looks good to me. Reviewed. >> > > Please flag the change with jdk11u-fix-request and >> > > add corresponding comment. >> > > >> > > Best regards, >> > > Goetz >> > > >> > > >> > > -----Original Message----- >> > > From: jdk-updates-dev On >> > > Behalf Of Jaroslav Bachor?k >> > > Sent: Donnerstag, 18. Juni 2020 17:27 >> > > To: jdk-updates-dev ; hotspot-jfr-dev >> > > >> > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 >> > > >> > > Hi all, >> > > >> > > Could I get this simple fix reviewed? >> > > It is fixing a regression introduced while backporting JDK-823790 and >> > > adding a new test to prevent such regressions in the future. >> > > >> > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 >> > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ >> > > >> > > Thanks, >> > > >> > > -JB- From phh at openjdk.java.net Tue Sep 29 16:08:34 2020 From: phh at openjdk.java.net (Paul Hohensee) Date: Tue, 29 Sep 2020 16:08:34 GMT Subject: [jdk13u-dev] RFR: 8253631: Remove unimplemented CompileBroker methods after JEP-165 In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 10:17:20 GMT, Yuri Nesterenko wrote: > As stated, remove declarations without any implementations. Marked as reviewed by phh (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/3 From neugens at redhat.com Tue Sep 29 16:26:49 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 29 Sep 2020 18:26:49 +0200 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: I created a bug for this: https://bugs.openjdk.java.net/browse/JDK-8253813 I think you can use this to rollback JDK-8244287. Cheers, Mario On Tue, Sep 29, 2020 at 6:03 PM Jaroslav Bachor?k wrote: > > Hi Goetz, > > I support rolling back the commit. Will you do it or should I initiate > the process? > > Regards, > > -JB- > > On Tue, Sep 29, 2020 at 5:01 PM Thomas St?fe wrote: > > > > Hi Goetz, > > > > not a JFR expert, but I had a look at the code both in head and in 11u. > > > > While the fix proposed by Martin seems sufficient, I would rather roll back the initial commit. The code in question in head had been rewritten in jdk14 for https://bugs.openjdk.java.net/browse/JDK-8236743 which fixes a problem with tracing code via JFR when classes are redefined. As a side effect it also fixes the original issue fixed by 8244287 by passing the line number to the constructor. I would rather go back to a stable point and later integrate JDK-8236743. > > > > Cheers Thomas > > > > > > > > On Tue, Sep 29, 2020 at 4:18 PM Lindenmaier, Goetz wrote: > >> > >> Hi, > >> > >> Any opinion on this? > >> Planned freeze of jd11u is in 2 hours ... > >> > >> Best regards, > >> Goetz. > >> > >> > -----Original Message----- > >> > From: Doerr, Martin > >> > Sent: Tuesday, September 29, 2020 3:11 PM > >> > To: Lindenmaier, Goetz ; Jaroslav Bachor?k > >> > ; jdk-updates-dev >> > dev at openjdk.java.net>; hotspot-jfr-dev > >> > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line number 0 > >> > > >> > Hi all, > >> > > >> > we have seen several crashes on several platforms after this change was > >> > pushed. > >> > > >> > Aarch64 example: > >> > Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, > >> > free space=2041k > >> > Native frames: (J=compiled Java code, A=aot compiled Java code, > >> > j=interpreted, Vv=VM code, C=native code) > >> > V [libjvm.so+0x9fb0f8] > >> > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, > >> > JfrCheckpointWriter&)+0x208 > >> > V [libjvm.so+0x9fb770] > >> > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 > >> > V [libjvm.so+0x9fba40] > >> > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, > >> > JfrStackTraceRepository&)+0x150 > >> > V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 > >> > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 > >> > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 > >> > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, > >> > Thread*)+0x160 > >> > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 > >> > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 > >> > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 > >> > C [libpthread.so.0+0x7088] start_thread+0xb0 > >> > > >> > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > >> > 0x0000000000000008 > >> > > >> > > >> > This backport uses a different JfrStackFrame constructor (which was > >> > probably unused before): > >> > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno) : > >> > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > >> > > >> > It sets _method to NULL! > >> > > >> > Should probably be: > >> > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int lineno, > >> > const Method* method) : > >> > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > >> > > >> > and: > >> > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); > >> > > >> > Do you think we can fix this quickly or should we better revert this backport? > >> > > >> > Best regards, > >> > Martin > >> > > >> > > >> > > -----Original Message----- > >> > > From: jdk-updates-dev On > >> > > Behalf Of Lindenmaier, Goetz > >> > > Sent: Montag, 22. Juni 2020 14:42 > >> > > To: Jaroslav Bachor?k ; jdk-updates- > >> > dev > >> > > ; hotspot-jfr-dev >> > > dev at openjdk.java.net> > >> > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > >> > > number 0 > >> > > > >> > > Hi Jaroslav, > >> > > > >> > > The fix looks good to me. Reviewed. > >> > > Please flag the change with jdk11u-fix-request and > >> > > add corresponding comment. > >> > > > >> > > Best regards, > >> > > Goetz > >> > > > >> > > > >> > > -----Original Message----- > >> > > From: jdk-updates-dev On > >> > > Behalf Of Jaroslav Bachor?k > >> > > Sent: Donnerstag, 18. Juni 2020 17:27 > >> > > To: jdk-updates-dev ; hotspot-jfr-dev > >> > > > >> > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 > >> > > > >> > > Hi all, > >> > > > >> > > Could I get this simple fix reviewed? > >> > > It is fixing a regression introduced while backporting JDK-823790 and > >> > > adding a new test to prevent such regressions in the future. > >> > > > >> > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > >> > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > >> > > > >> > > Thanks, > >> > > > >> > > -JB- > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Tue Sep 29 16:37:37 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 29 Sep 2020 18:37:37 +0200 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi! On Tue, Sep 29, 2020 at 5:02 PM Thomas St?fe wrote: > > Hi Goetz, > > not a JFR expert, but I had a look at the code both in head and in 11u. > > While the fix proposed by Martin seems sufficient, I would rather roll back > the initial commit. The code in question in head had been rewritten in > jdk14 for https://bugs.openjdk.java.net/browse/JDK-8236743 which fixes a > problem with tracing code via JFR when classes are redefined. As a side > effect it also fixes the original issue fixed by 8244287 by passing the > line number to the constructor. I would rather go back to a stable point > and later integrate JDK-8236743. +1 Thanks, Severin > On Tue, Sep 29, 2020 at 4:18 PM Lindenmaier, Goetz < > goetz.lindenmaier at sap.com> wrote: > > > Hi, > > > > Any opinion on this? > > Planned freeze of jd11u is in 2 hours ... > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Tuesday, September 29, 2020 3:11 PM > > > To: Lindenmaier, Goetz ; Jaroslav Bachor?k > > > ; jdk-updates-dev > > dev at openjdk.java.net>; hotspot-jfr-dev > > > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > > > Hi all, > > > > > > we have seen several crashes on several platforms after this change was > > > pushed. > > > > > > Aarch64 example: > > > Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, > > > free space=2041k > > > Native frames: (J=compiled Java code, A=aot compiled Java code, > > > j=interpreted, Vv=VM code, C=native code) > > > V [libjvm.so+0x9fb0f8] > > > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, > > > JfrCheckpointWriter&)+0x208 > > > V [libjvm.so+0x9fb770] > > > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 > > > V [libjvm.so+0x9fba40] > > > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, > > > JfrStackTraceRepository&)+0x150 > > > V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 > > > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 > > > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 > > > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, > > > Thread*)+0x160 > > > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 > > > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 > > > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 > > > C [libpthread.so.0+0x7088] start_thread+0xb0 > > > > > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > > > 0x0000000000000008 > > > > > > > > > This backport uses a different JfrStackFrame constructor (which was > > > probably unused before): > > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > > lineno) : > > > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > > > > > > It sets _method to NULL! > > > > > > Should probably be: > > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > > lineno, > > > const Method* method) : > > > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) > > {} > > > > > > and: > > > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); > > > > > > Do you think we can fix this quickly or should we better revert this > > backport? > > > > > > Best regards, > > > Martin > > > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > > Behalf Of Lindenmaier, Goetz > > > > Sent: Montag, 22. Juni 2020 14:42 > > > > To: Jaroslav Bachor?k ; jdk-updates- > > > dev > > > > ; hotspot-jfr-dev > > > dev at openjdk.java.net> > > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > > > > number 0 > > > > > > > > Hi Jaroslav, > > > > > > > > The fix looks good to me. Reviewed. > > > > Please flag the change with jdk11u-fix-request and > > > > add corresponding comment. > > > > > > > > Best regards, > > > > Goetz > > > > > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev On > > > > Behalf Of Jaroslav Bachor?k > > > > Sent: Donnerstag, 18. Juni 2020 17:27 > > > > To: jdk-updates-dev ; > > hotspot-jfr-dev > > > > > > > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > > > > > Hi all, > > > > > > > > Could I get this simple fix reviewed? > > > > It is fixing a regression introduced while backporting JDK-823790 and > > > > adding a new test to prevent such regressions in the future. > > > > > > > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > > > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > > > > > > > > Thanks, > > > > > > > > -JB- > > > From jaroslav.bachorik at datadoghq.com Tue Sep 29 17:06:32 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 29 Sep 2020 19:06:32 +0200 Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several crashes Message-ID: Please, review this simple backout JIRA; https://bugs.openjdk.java.net/browse/JDK-8253813 Webrev: http://cr.openjdk.java.net/~jbachorik/8253813/00/webrev/ While the change is pretty simple it would be good if someone could try running the crashing cases before this change is pushed just to be sure the backout is addressing the crash completely. Regards, -JB- From jaroslav.bachorik at datadoghq.com Tue Sep 29 17:08:39 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 29 Sep 2020 19:08:39 +0200 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi, https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003893.html Could you give the patch a test before approving? Apparently, I can't even build successfully after my yesterday's MacOS upgrade and given the criticality of this problem I don't feel like spending time on trying to figure out what broke clang ... Cheers, -JB- On Tue, Sep 29, 2020 at 6:37 PM Severin Gehwolf wrote: > > Hi! > > On Tue, Sep 29, 2020 at 5:02 PM Thomas St?fe wrote: > > > > Hi Goetz, > > > > not a JFR expert, but I had a look at the code both in head and in 11u. > > > > While the fix proposed by Martin seems sufficient, I would rather roll back > > the initial commit. The code in question in head had been rewritten in > > jdk14 for https://bugs.openjdk.java.net/browse/JDK-8236743 which fixes a > > problem with tracing code via JFR when classes are redefined. As a side > > effect it also fixes the original issue fixed by 8244287 by passing the > > line number to the constructor. I would rather go back to a stable point > > and later integrate JDK-8236743. > > +1 > > Thanks, > Severin > > > > On Tue, Sep 29, 2020 at 4:18 PM Lindenmaier, Goetz < > > goetz.lindenmaier at sap.com> wrote: > > > > > Hi, > > > > > > Any opinion on this? > > > Planned freeze of jd11u is in 2 hours ... > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: Doerr, Martin > > > > Sent: Tuesday, September 29, 2020 3:11 PM > > > > To: Lindenmaier, Goetz ; Jaroslav Bachor?k > > > > ; jdk-updates-dev > > > dev at openjdk.java.net>; hotspot-jfr-dev > > > > > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > > > > > Hi all, > > > > > > > > we have seen several crashes on several platforms after this change was > > > > pushed. > > > > > > > > Aarch64 example: > > > > Stack: [0x0000ffff90437000,0x0000ffff90637000], sp=0x0000ffff90635520, > > > > free space=2041k > > > > Native frames: (J=compiled Java code, A=aot compiled Java code, > > > > j=interpreted, Vv=VM code, C=native code) > > > > V [libjvm.so+0x9fb0f8] > > > > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, > > > > JfrCheckpointWriter&)+0x208 > > > > V [libjvm.so+0x9fb770] > > > > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 > > > > V [libjvm.so+0x9fba40] > > > > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, > > > > JfrStackTraceRepository&)+0x150 > > > > V [libjvm.so+0x72df6c] JfrRecorderService::pre_safepoint_write()+0x3a4 > > > > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 > > > > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 > > > > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, > > > > Thread*)+0x160 > > > > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 > > > > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 > > > > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 > > > > C [libpthread.so.0+0x7088] start_thread+0xb0 > > > > > > > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > > > > 0x0000000000000008 > > > > > > > > > > > > This backport uses a different JfrStackFrame constructor (which was > > > > probably unused before): > > > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > > > lineno) : > > > > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > > > > > > > > It sets _method to NULL! > > > > > > > > Should probably be: > > > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > > > lineno, > > > > const Method* method) : > > > > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) > > > {} > > > > > > > > and: > > > > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); > > > > > > > > Do you think we can fix this quickly or should we better revert this > > > backport? > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev On > > > > > Behalf Of Lindenmaier, Goetz > > > > > Sent: Montag, 22. Juni 2020 14:42 > > > > > To: Jaroslav Bachor?k ; jdk-updates- > > > > dev > > > > > ; hotspot-jfr-dev > > > > dev at openjdk.java.net> > > > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > > > > > number 0 > > > > > > > > > > Hi Jaroslav, > > > > > > > > > > The fix looks good to me. Reviewed. > > > > > Please flag the change with jdk11u-fix-request and > > > > > add corresponding comment. > > > > > > > > > > Best regards, > > > > > Goetz > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev On > > > > > Behalf Of Jaroslav Bachor?k > > > > > Sent: Donnerstag, 18. Juni 2020 17:27 > > > > > To: jdk-updates-dev ; > > > hotspot-jfr-dev > > > > > > > > > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number 0 > > > > > > > > > > Hi all, > > > > > > > > > > Could I get this simple fix reviewed? > > > > > It is fixing a regression introduced while backporting JDK-823790 and > > > > > adding a new test to prevent such regressions in the future. > > > > > > > > > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > > > > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > > > > > > > > > > Thanks, > > > > > > > > > > -JB- > > > > > > From goetz.lindenmaier at sap.com Tue Sep 29 17:09:37 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Sep 2020 17:09:37 +0000 Subject: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line number 0 In-Reply-To: References: Message-ID: Hi everybody, Thanks for the fast replies. I used Marios bug to post a backout: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003893.html Please review (in that other thread). And I please need the approval of the critical fix request Best regards, Goetz. > -----Original Message----- > From: Severin Gehwolf > Sent: Tuesday, September 29, 2020 6:38 PM > To: Thomas St?fe > Cc: Lindenmaier, Goetz ; Doerr, Martin > ; Jaroslav Bachor?k > ; jdk-updates-dev dev at openjdk.java.net>; hotspot-jfr-dev > Subject: Re: [URGENT]: [11u] RFR 8244287: JFR: Methods samples have line > number 0 > > Hi! > > On Tue, Sep 29, 2020 at 5:02 PM Thomas St?fe > wrote: > > > > Hi Goetz, > > > > not a JFR expert, but I had a look at the code both in head and in 11u. > > > > While the fix proposed by Martin seems sufficient, I would rather roll back > > the initial commit. The code in question in head had been rewritten in > > jdk14 for https://bugs.openjdk.java.net/browse/JDK-8236743 which fixes a > > problem with tracing code via JFR when classes are redefined. As a side > > effect it also fixes the original issue fixed by 8244287 by passing the > > line number to the constructor. I would rather go back to a stable point > > and later integrate JDK-8236743. > > +1 > > Thanks, > Severin > > > > On Tue, Sep 29, 2020 at 4:18 PM Lindenmaier, Goetz < > > goetz.lindenmaier at sap.com> wrote: > > > > > Hi, > > > > > > Any opinion on this? > > > Planned freeze of jd11u is in 2 hours ... > > > > > > Best regards, > > > Goetz. > > > > > > > -----Original Message----- > > > > From: Doerr, Martin > > > > Sent: Tuesday, September 29, 2020 3:11 PM > > > > To: Lindenmaier, Goetz ; Jaroslav > Bachor?k > > > > ; jdk-updates-dev > > > dev at openjdk.java.net>; hotspot-jfr-dev dev at openjdk.java.net > > > > > > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > number 0 > > > > > > > > Hi all, > > > > > > > > we have seen several crashes on several platforms after this change > was > > > > pushed. > > > > > > > > Aarch64 example: > > > > Stack: [0x0000ffff90437000,0x0000ffff90637000], > sp=0x0000ffff90635520, > > > > free space=2041k > > > > Native frames: (J=compiled Java code, A=aot compiled Java code, > > > > j=interpreted, Vv=VM code, C=native code) > > > > V [libjvm.so+0x9fb0f8] > > > > ObjectSampleCheckpoint::write_stacktrace(JfrStackTrace const*, > > > > JfrCheckpointWriter&)+0x208 > > > > V [libjvm.so+0x9fb770] > > > > StackTraceBlobInstaller::install(ObjectSample*)+0x1b8 > > > > V [libjvm.so+0x9fba40] > > > > ObjectSampleCheckpoint::on_rotation(ObjectSampler const*, > > > > JfrStackTraceRepository&)+0x150 > > > > V [libjvm.so+0x72df6c] > JfrRecorderService::pre_safepoint_write()+0x3a4 > > > > V [libjvm.so+0x72e828] JfrRecorderService::write()+0x58 > > > > V [libjvm.so+0x72fd2c] JfrRecorderService::rotate(int)+0x3b4 > > > > V [libjvm.so+0x730628] recorderthread_entry(JavaThread*, > > > > Thread*)+0x160 > > > > V [libjvm.so+0xbb2dd0] JavaThread::thread_main_inner()+0xd8 > > > > V [libjvm.so+0xbb08fc] Thread::call_run()+0x94 > > > > V [libjvm.so+0xa21718] thread_native_entry(Thread*)+0x108 > > > > C [libpthread.so.0+0x7088] start_thread+0xb0 > > > > > > > > siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: > > > > 0x0000000000000008 > > > > > > > > > > > > This backport uses a different JfrStackFrame constructor (which was > > > > probably unused before): > > > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > > > lineno) : > > > > _method(NULL), _methodid(id), _line(lineno), _bci(bci), _type(type) {} > > > > > > > > It sets _method to NULL! > > > > > > > > Should probably be: > > > > JfrStackFrame::JfrStackFrame(const traceid& id, int bci, int type, int > > > lineno, > > > > const Method* method) : > > > > _method(method), _methodid(id), _line(lineno), _bci(bci), _type(type) > > > {} > > > > > > > > and: > > > > _frames[count] = JfrStackFrame(mid, bci, type, lineno, method); > > > > > > > > Do you think we can fix this quickly or should we better revert this > > > backport? > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev > On > > > > > Behalf Of Lindenmaier, Goetz > > > > > Sent: Montag, 22. Juni 2020 14:42 > > > > > To: Jaroslav Bachor?k ; jdk- > updates- > > > > dev > > > > > ; hotspot-jfr-dev > > > > dev at openjdk.java.net> > > > > > Subject: RE: [11u] RFR 8244287: JFR: Methods samples have line > > > > > number 0 > > > > > > > > > > Hi Jaroslav, > > > > > > > > > > The fix looks good to me. Reviewed. > > > > > Please flag the change with jdk11u-fix-request and > > > > > add corresponding comment. > > > > > > > > > > Best regards, > > > > > Goetz > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev > On > > > > > Behalf Of Jaroslav Bachor?k > > > > > Sent: Donnerstag, 18. Juni 2020 17:27 > > > > > To: jdk-updates-dev ; > > > hotspot-jfr-dev > > > > > > > > > > Subject: [11u] RFR 8244287: JFR: Methods samples have line number > 0 > > > > > > > > > > Hi all, > > > > > > > > > > Could I get this simple fix reviewed? > > > > > It is fixing a regression introduced while backporting JDK-823790 and > > > > > adding a new test to prevent such regressions in the future. > > > > > > > > > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8244287 > > > > > Webrev : http://cr.openjdk.java.net/~jbachorik/8244287/webrev/ > > > > > > > > > > Thanks, > > > > > > > > > > -JB- > > > > > From goetz.lindenmaier at sap.com Tue Sep 29 17:11:16 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Sep 2020 17:11:16 +0000 Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several crashes In-Reply-To: References: Message-ID: Looks good, just the same as mine?? It is in our testing queue. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On Behalf > Of Jaroslav Bachor?k > Sent: Tuesday, September 29, 2020 7:07 PM > To: jdk-updates-dev > Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes > several crashes > > Please, review this simple backout > > JIRA; https://bugs.openjdk.java.net/browse/JDK-8253813 > Webrev: http://cr.openjdk.java.net/~jbachorik/8253813/00/webrev/ > > While the change is pretty simple it would be good if someone could > try running the crashing cases before this change is pushed just to be > sure the backout is addressing the crash completely. > > Regards, > > -JB- From martin.doerr at sap.com Tue Sep 29 17:12:19 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Sep 2020 17:12:19 +0000 Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several crashes In-Reply-To: References: Message-ID: Hi Jaroslav, thanks for the backout. Your webrev looks good. Best regards, Martin > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaroslav Bachor?k > Sent: Dienstag, 29. September 2020 19:07 > To: jdk-updates-dev > Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several > crashes > > Please, review this simple backout > > JIRA; https://bugs.openjdk.java.net/browse/JDK-8253813 > Webrev: http://cr.openjdk.java.net/~jbachorik/8253813/00/webrev/ > > While the change is pretty simple it would be good if someone could > try running the crashing cases before this change is pushed just to be > sure the backout is addressing the crash completely. > > Regards, > > -JB- From jaroslav.bachorik at datadoghq.com Tue Sep 29 19:08:19 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 29 Sep 2020 21:08:19 +0200 Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several crashes In-Reply-To: References: Message-ID: On Tue 29. 9. 2020 at 19:11, Lindenmaier, Goetz wrote: > Looks good, just the same as mine?? > ?? > > > > It is in our testing queue. Can you push it once testing is done? Thanks, -JB- > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: jdk-updates-dev On Behalf > > > Of Jaroslav Bachor?k > > > Sent: Tuesday, September 29, 2020 7:07 PM > > > To: jdk-updates-dev > > > Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes > > > several crashes > > > > > > Please, review this simple backout > > > > > > JIRA; https://bugs.openjdk.java.net/browse/JDK-8253813 > > > Webrev: http://cr.openjdk.java.net/~jbachorik/8253813/00/webrev/ > > > > > > While the change is pretty simple it would be good if someone could > > > try running the crashing cases before this change is pushed just to be > > > sure the backout is addressing the crash completely. > > > > > > Regards, > > > > > > -JB- > > From goetz.lindenmaier at sap.com Wed Sep 30 06:37:22 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 30 Sep 2020 06:37:22 +0000 Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several crashes In-Reply-To: References: Message-ID: Hi Jaroslav, Yes, I will do so. (A few of my mails got stuck in some mail filter and never made it to the list) Our tests are green, so I?ll push it now and then push the tag. Best regards, Goetz. From: Jaroslav Bachor?k Sent: Tuesday, September 29, 2020 9:08 PM To: Lindenmaier, Goetz Cc: jdk-updates-dev Subject: Re: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes several crashes On Tue 29. 9. 2020 at 19:11, Lindenmaier, Goetz > wrote: Looks good, just the same as mine?? ?? It is in our testing queue. Can you push it once testing is done? Thanks, -JB- Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev > On Behalf > Of Jaroslav Bachor?k > Sent: Tuesday, September 29, 2020 7:07 PM > To: jdk-updates-dev > > Subject: [11u] RFR 8253813: Backout JDK-8244287 from 11u: it causes > several crashes > > Please, review this simple backout > > JIRA; https://bugs.openjdk.java.net/browse/JDK-8253813 > Webrev: http://cr.openjdk.java.net/~jbachorik/8253813/00/webrev/ > > While the change is pretty simple it would be good if someone could > try running the crashing cases before this change is pushed just to be > sure the backout is addressing the crash completely. > > Regards, > > -JB- From yan at azul.com Wed Sep 30 07:14:22 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 30 Sep 2020 10:14:22 +0300 Subject: [jdk13u-dev] RFR: 8253631: Remove unimplemented CompileBroker methods after JEP-165 In-Reply-To: References: Message-ID: <67615808-e4f0-c908-0425-4be94d59a603@azul.com> Thank you Paul! Actually this commit should be closer to the original than what we finally have. I chose it as a perfect example of immutable backport to test the workflow for update release. Skara team works on SKARA-413 issue to iron that. In the meantime, I'm going to close this Github pull request without merge and just push the imported change directly to jdk13u-dev. --yan On 29.09.2020 19:08, Paul Hohensee wrote: > On Tue, 29 Sep 2020 10:17:20 GMT, Yuri Nesterenko wrote: > >> As stated, remove declarations without any implementations. > > Marked as reviewed by phh (Reviewer). > > ------------- > > PR: https://git.openjdk.java.net/jdk13u-dev/pull/3 > From yan at openjdk.java.net Wed Sep 30 07:27:08 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 30 Sep 2020 07:27:08 GMT Subject: [jdk13u-dev] RFR: 8253631: Remove unimplemented CompileBroker methods after JEP-165 [v2] In-Reply-To: References: Message-ID: > As stated, remove declarations without any implementations. Yuri Nesterenko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. ------------- Changes: - all: https://git.openjdk.java.net/jdk13u-dev/pull/3/files - new: https://git.openjdk.java.net/jdk13u-dev/pull/3/files/2e9d2ca9..2e9d2ca9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=3&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=3&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk13u-dev/pull/3.diff Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/3/head:pull/3 PR: https://git.openjdk.java.net/jdk13u-dev/pull/3 From yan at openjdk.java.net Wed Sep 30 07:27:09 2020 From: yan at openjdk.java.net (Yuri Nesterenko) Date: Wed, 30 Sep 2020 07:27:09 GMT Subject: [jdk13u-dev] Integrated: 8253631: Remove unimplemented CompileBroker methods after JEP-165 In-Reply-To: References: Message-ID: On Tue, 29 Sep 2020 10:17:20 GMT, Yuri Nesterenko wrote: > As stated, remove declarations without any implementations. This pull request has now been integrated. Changeset: 2e9d2ca9 Author: Aleksey Shipilev Committer: Yuri Nesterenko URL: https://git.openjdk.java.net/jdk13u-dev/commit/2e9d2ca9 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod 8253631: Remove unimplemented CompileBroker methods after JEP-165 Reviewed-by: thartmann ------------- PR: https://git.openjdk.java.net/jdk13u-dev/pull/3