From christoph.langer at sap.com Sun Sep 1 06:30:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 1 Sep 2019 06:30:52 +0000 Subject: [11u] RFR: 8213448 [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: References: Message-ID: Hi Jie, I approved the 11u fix. I assume you'll be happy if I also push the change for you as you aren't a committer, correct? Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 30. August 2019 14:09 > To: Jie Kang ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8213448 [TESTBUG] enhance > jfr/jvm/TestDumpOnCrash > > Hi Jie, > > this looks good to me. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Jie Kang > > Sent: Mittwoch, 28. August 2019 16:59 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR: 8213448 [TESTBUG] enhance jfr/jvm/TestDumpOnCrash > > > > Hi all, > > > > Please review this test-only backport of 8213448 to OpenJDK jdk11u-dev > > so as to get a significantly cleaner backport for JDK-8217362 [1]. The > > fix did not apply cleanly as a one-line removal to the file is missing > > from JDK-8209856 [2]. My process was to make this one-line removal, > > apply the patch, and then revert the one line removal. I have run tier > > one tests and jfr specific tests successfully. Please let me know how > > it looks and if it is appropriate to backport to 11. > > > > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.00/ > > Original Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/f0af7fd0c9ca > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213448 > > > > [1] > > Would allow a cleaner backport of: > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9#l5.1 > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > > [2] > > The missing one-line removal: > > http://hg.openjdk.java.net/jdk/jdk/rev/d7fc38d3fc8d#l19.7 > > https://bugs.openjdk.java.net/browse/JDK-8209856 From christoph.langer at sap.com Mon Sep 2 08:09:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Sep 2019 08:09:48 +0000 Subject: [11u] RFR: JDK-8205516: JFR tool In-Reply-To: References: <4ed30395e6fa7e12561de574d31e27fb7cd1f222.camel@redhat.com> <73be49c0e6abdefc7cba3e2f1f17a397eb3605e2.camel@redhat.com> Message-ID: Hi, after seeing no regressions, I've pushed these 3 changes to jdk11u-dev. Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 30. August 2019 14:36 > To: Jie Kang > Cc: jdk-updates-dev at openjdk.java.net; Severin Gehwolf > > Subject: RE: [11u] RFR: JDK-8205516: JFR tool > > Hi Jie, > > I've just added your changeset for JDK-8205516 to our test queue, along with > the follow-ups JDK-8214896 and JDK-8214925 which would both apply cleanly > from jdk/jdk. > > Depending on how the tests go, I'll push these at the beginning of next > week. > > Best regards > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Severin Gehwolf > > Sent: Freitag, 16. August 2019 13:14 > > To: Jie Kang > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] RFR: JDK-8205516: JFR tool > > > > On Wed, 2019-08-14 at 09:52 -0400, Jie Kang wrote: > > > http://cr.openjdk.java.net/~jkang/8205516/webrev.02/ > > > > Looks good. > > > > Thanks, > > Severin From shade at redhat.com Mon Sep 2 08:20:01 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 2 Sep 2019 10:20:01 +0200 Subject: [11u] RFR 8224589: Improve startup behavior of SecurityProperties In-Reply-To: References: <50fc32e3-70ba-4821-4fe4-142664e80ede@redhat.com> <7129a8b2-852f-1840-ec55-07d6808729a7@redhat.com> Message-ID: <7b10b7d5-ea5f-867f-8e03-0a4a785c3da6@redhat.com> On 8/30/19 12:05 PM, Langer, Christoph wrote: > As for this one, can we do this: http://cr.openjdk.java.net/~clanger/webrevs/8224589.11u-dev.0/ ? Looks fine to me. -- Thanks, -Aleksey From christoph.langer at sap.com Mon Sep 2 08:23:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Sep 2019 08:23:10 +0000 Subject: [11u] RFR 8224589: Improve startup behavior of SecurityProperties In-Reply-To: <7b10b7d5-ea5f-867f-8e03-0a4a785c3da6@redhat.com> References: <50fc32e3-70ba-4821-4fe4-142664e80ede@redhat.com> <7129a8b2-852f-1840-ec55-07d6808729a7@redhat.com> <7b10b7d5-ea5f-867f-8e03-0a4a785c3da6@redhat.com> Message-ID: Hi Aleksey, great, thanks for reviewing. It went well through our nightlies this weekend, so I'll push it to 11u today. Best regards Christoph > -----Original Message----- > From: Aleksey Shipilev > Sent: Montag, 2. September 2019 10:20 > To: Langer, Christoph ; Martin Balao > ; jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR 8224589: Improve startup behavior of > SecurityProperties > > On 8/30/19 12:05 PM, Langer, Christoph wrote: > > As for this one, can we do this: > http://cr.openjdk.java.net/~clanger/webrevs/8224589.11u-dev.0/ ? > > Looks fine to me. > > -- > Thanks, > -Aleksey From christoph.langer at sap.com Mon Sep 2 09:24:36 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Sep 2019 09:24:36 +0000 Subject: [11u] RFR(XS): 8221407: Windows 32bit build error in libsunmscapi/security.cpp Message-ID: Hi, please review the backport of this little change that fixes errors/warnings in the Win32 Build. There were some changes in jdk/jdk before 8221407 which have not been backported to 11u, so parts of the fixes don't apply. The change in line 1000 needed manual work since the variable name is different upstream. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221407.11u-dev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221407 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c02b8d6384ab Thanks Christoph From thomas.stuefe at gmail.com Mon Sep 2 10:57:31 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 2 Sep 2019 12:57:31 +0200 Subject: [11u] RFR(XS): 8221407: Windows 32bit build error in libsunmscapi/security.cpp In-Reply-To: References: Message-ID: Looks fine, Christoph. On Mon, Sep 2, 2019 at 11:25 AM Langer, Christoph wrote: > Hi, > > please review the backport of this little change that fixes > errors/warnings in the Win32 Build. There were some changes in jdk/jdk > before 8221407 which have not been backported to 11u, so parts of the fixes > don't apply. The change in line 1000 needed manual work since the variable > name is different upstream. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221407.11u-dev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221407 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c02b8d6384ab > > Thanks > Christoph > > From christoph.langer at sap.com Mon Sep 2 12:45:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Sep 2019 12:45:26 +0000 Subject: [11u] RFR: 8214542: JFR: Old Object Sample event slow on a deep heap in debug builds Message-ID: Hi, please help reviewing the backport of this JFR related bugfix to JDK11. Bug: https://bugs.openjdk.java.net/browse/JDK-8214542 Original Change: http://hg.openjdk.java.net/jdk/jdk13/rev/49102ba8cf14 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8214542.11u-dev.0/ The original patch did not apply cleanly. There were some rejects: http://cr.openjdk.java.net/~clanger/webrevs/8214542.11u-dev.0/8214542.rejects.patch I had to resolve the following files: src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp src/hotspot/share/jfr/leakprofiler/emitEventOperation.hpp src/hotspot/share/jfr/leakprofiler/leakProfiler.hpp src/hotspot/share/jfr/leakprofiler/startOperation.hpp src/hotspot/share/jfr/leakprofiler/stopOperation.hpp src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp src/hotspot/share/runtime/vmOperations.hpp Resolving was quite straightforward. In jdk11u-dev, the file src/hotspot/share/runtime/vmOperations.hpp is still called src/hotspot/share/runtime/vm_operations.hpp. With this patch applied, no regressions were observed in SAP's test infrastructure. So I tend to say it works. But it would be good to get this verified by somebody else who has some more knowledge in the JFR area. I'll also request the backport of JDK-8228834 and push it together with this patch because it is linked to bug JDK-8214542 as regression. It was also included in my testing. Thanks Christoph From christoph.langer at sap.com Mon Sep 2 14:07:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 2 Sep 2019 14:07:53 +0000 Subject: [11u] RFR JDK-8217362: Emergency dump does not work when disk=false is set In-Reply-To: References: Message-ID: Hi Jie, thanks for putting effort in backporting this bug. First of all, a general remark: When you bring an upstream patch to backport, can you please use the workflow to export the patch from the upstream repo (e.g. hg export -r --git > .patch) and then import it to the backport target repository (e.g. jdk11u-dev via hg qimport && hg qpush). More details can be taken out of https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix. This would make sure, the patch metadata, such as original author, description and reviewed-by comments remain intact. These are currently missing when I import the patch from your webrev. Furthermore, I agree, it would be beneficial to backport 8218935 before you do this item. So, can you request/process this before continuing with JDK-8217362? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jie Kang > Sent: Freitag, 30. August 2019 22:33 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR JDK-8217362: Emergency dump does not work when > disk=false is set > > Hi all, > > Please review this backport of 8217362 to OpenJDK jdk11u-dev. The fix > did not apply cleanly and I have described my alterations below. This > fix has been applied on top of my backport request of 8213448 [1], > which I hope will be accepted. I have run the tier one tests as well > as the reproducer described in the bug report. It does not produce a > jfr without the patch and does with the patch applied. Let me know > what you think! > > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.01/ > Original Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > Bug: https://bugs.openjdk.java.net/browse/JDK-8217362 > > Alterations: > > 1. test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java.rej > [jdk/jdk hg rev] : [openjdk bug] > d7fc38d3fc8d : 8209856: Obsolete error reporter > > A one line difference caused rejects; I manually applied the changes. > > 2. src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp.rej > 65deccd64f3a : 8218935: Make jfr strncpy uses GCC 8.x friendly > > Small differences caused rejects; I manually applied the changes. > Maybe it would be good to also backport 8218935? If maintainer's have > a stronger opinion I would appreciate it. > > 3. src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp.rej > 5d20b085d893 : 8203469: Faster safepoints > 881c5fbeb849 : 8218041: Assorted wrong/missing includes > 625a5bdde0c5 : 8210155: Lock ClassLoaderDataGraph > > Generally small changes missing; I manually applied the changes in this patch. > > [1] > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > August/001790.html > https://bugs.openjdk.java.net/browse/JDK-8213448 > > > Regards, From shade at redhat.com Mon Sep 2 15:14:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 2 Sep 2019 17:14:25 +0200 Subject: [11u] RFR 8218468: Load barrier slow path node should be MachTypeNode Message-ID: <066146d3-0a10-ffea-e5c5-fd9ea80e9b79@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8218468 https://hg.openjdk.java.net/jdk/jdk/rev/b36e68b34be3 Original change does not apply to 11u cleanly, because there is no Shenandoah. The change is already in 11.0.6-oracle, in some form. Nils, is it like below? 11u patch: diff -r cb90ceb87071 src/hotspot/share/adlc/formssel.cpp --- a/src/hotspot/share/adlc/formssel.cpp Tue Nov 06 23:03:05 2018 +0100 +++ b/src/hotspot/share/adlc/formssel.cpp Mon Sep 02 17:12:54 2019 +0200 @@ -791,4 +791,8 @@ !strcmp(_matrule->_rChild->_opType,"GetAndSetP") || !strcmp(_matrule->_rChild->_opType,"GetAndSetN") || +#if INCLUDE_ZGC + !strcmp(_matrule->_rChild->_opType,"LoadBarrierSlowReg") || + !strcmp(_matrule->_rChild->_opType,"LoadBarrierWeakSlowReg") || +#endif !strcmp(_matrule->_rChild->_opType,"CompareAndExchangeP") || !strcmp(_matrule->_rChild->_opType,"CompareAndExchangeN"))) return true; Testing: Linux x86_64, tier1, tier2 -- Thanks, -Aleksey From rob.mckenna at oracle.com Tue Sep 3 12:50:27 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 3 Sep 2019 13:50:27 +0100 Subject: [Updates Communication] 13.0.1 Critical request phase In-Reply-To: References: <20190822162407.GA6374@vimes> Message-ID: <20190903125027.GA3863@tecra> Hi Christoph, https://hg.openjdk.java.net/jdk-updates/jdk13u/rev/3baa9b8053a0 was the latest commit from jdk13u that made 13.0.1. -Rob On 30/08/19 12:42, Langer, Christoph wrote: > Hi Rob, > > can you please let us know the commit of jdk13u which was the latest one that you merged into your internal jdk13.0.1 repository? > > By knowing that, we can sync to the publicly available code level that is closest to what will eventually be the released 13.0.1 version and we can base our final testing on it. > > Thanks > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Rob McKenna > > Sent: Donnerstag, 22. August 2019 18:24 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [Updates Communication] 13.0.1 Critical request phase > > > > As we're getting into the later stages of the 13.0.1 release, from Tuesday > > on push approvals will be for 13.0.2 by default. (note: this does not > > mean that approval requests prior to that date will be approved) > > > > Rare exceptions may be made for serious regressions and p1 showstoppers. > > Please highlight cases that you feel meet those criteria in the fix > > request comment. > > > > -Rob From jkang at redhat.com Tue Sep 3 13:49:07 2019 From: jkang at redhat.com (Jie Kang) Date: Tue, 3 Sep 2019 09:49:07 -0400 Subject: [11u] RFR: 8213448 [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: References: Message-ID: On Sun, Sep 1, 2019 at 2:31 AM Langer, Christoph wrote: > > Hi Jie, > > I approved the 11u fix. I assume you'll be happy if I also push the change for you as you aren't a committer, correct? Hi Christoph, Yes that would be appreciated. I have also added an updated webrev below that maintains the proper commit message and author from jdk/jdk. I have compared the raw file to my previous webrev to be the same, as well as to the original commit to only differ with the single line ("-XX:-TransmitErrorReport") described previously. Updated webrev: http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.01/ I will make sure to do this from now on; thank you! Regards, > > Best regards > Christoph > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Freitag, 30. August 2019 14:09 > > To: Jie Kang ; jdk-updates-dev at openjdk.java.net > > Subject: RE: [11u] RFR: 8213448 [TESTBUG] enhance > > jfr/jvm/TestDumpOnCrash > > > > Hi Jie, > > > > this looks good to me. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev On > > > Behalf Of Jie Kang > > > Sent: Mittwoch, 28. August 2019 16:59 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [11u] RFR: 8213448 [TESTBUG] enhance jfr/jvm/TestDumpOnCrash > > > > > > Hi all, > > > > > > Please review this test-only backport of 8213448 to OpenJDK jdk11u-dev > > > so as to get a significantly cleaner backport for JDK-8217362 [1]. The > > > fix did not apply cleanly as a one-line removal to the file is missing > > > from JDK-8209856 [2]. My process was to make this one-line removal, > > > apply the patch, and then revert the one line removal. I have run tier > > > one tests and jfr specific tests successfully. Please let me know how > > > it looks and if it is appropriate to backport to 11. > > > > > > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.00/ > > > Original Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/f0af7fd0c9ca > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213448 > > > > > > [1] > > > Would allow a cleaner backport of: > > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9#l5.1 > > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > > > > [2] > > > The missing one-line removal: > > > http://hg.openjdk.java.net/jdk/jdk/rev/d7fc38d3fc8d#l19.7 > > > https://bugs.openjdk.java.net/browse/JDK-8209856 From christoph.langer at sap.com Tue Sep 3 14:07:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Sep 2019 14:07:01 +0000 Subject: [11u] RFR: 8213448 [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: References: Message-ID: Hi Jie, great. I added your new patch to our nightly test queue. I'll probably push it tomorrow once the test results show green. Thanks & Best regards Christoph > -----Original Message----- > From: Jie Kang > Sent: Dienstag, 3. September 2019 15:49 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8213448 [TESTBUG] enhance > jfr/jvm/TestDumpOnCrash > > On Sun, Sep 1, 2019 at 2:31 AM Langer, Christoph > wrote: > > > > Hi Jie, > > > > I approved the 11u fix. I assume you'll be happy if I also push the change for > you as you aren't a committer, correct? > > Hi Christoph, > > Yes that would be appreciated. I have also added an updated webrev > below that maintains the proper commit message and author from > jdk/jdk. I have compared the raw file to my previous webrev to be the > same, as well as to the original commit to only differ with the single > line ("-XX:-TransmitErrorReport") described previously. > > Updated webrev: > http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.01/ > > I will make sure to do this from now on; thank you! > > > Regards, > > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Freitag, 30. August 2019 14:09 > > > To: Jie Kang ; jdk-updates-dev at openjdk.java.net > > > Subject: RE: [11u] RFR: 8213448 [TESTBUG] enhance > > > jfr/jvm/TestDumpOnCrash > > > > > > Hi Jie, > > > > > > this looks good to me. > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev > On > > > > Behalf Of Jie Kang > > > > Sent: Mittwoch, 28. August 2019 16:59 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Subject: [11u] RFR: 8213448 [TESTBUG] enhance > jfr/jvm/TestDumpOnCrash > > > > > > > > Hi all, > > > > > > > > Please review this test-only backport of 8213448 to OpenJDK jdk11u- > dev > > > > so as to get a significantly cleaner backport for JDK-8217362 [1]. The > > > > fix did not apply cleanly as a one-line removal to the file is missing > > > > from JDK-8209856 [2]. My process was to make this one-line removal, > > > > apply the patch, and then revert the one line removal. I have run tier > > > > one tests and jfr specific tests successfully. Please let me know how > > > > it looks and if it is appropriate to backport to 11. > > > > > > > > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.00/ > > > > Original Changeset: > http://hg.openjdk.java.net/jdk/jdk/rev/f0af7fd0c9ca > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213448 > > > > > > > > [1] > > > > Would allow a cleaner backport of: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9#l5.1 > > > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > > > > > > [2] > > > > The missing one-line removal: > > > > http://hg.openjdk.java.net/jdk/jdk/rev/d7fc38d3fc8d#l19.7 > > > > https://bugs.openjdk.java.net/browse/JDK-8209856 From shade at redhat.com Tue Sep 3 14:28:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 3 Sep 2019 16:28:25 +0200 Subject: [11u] RFR (S) 8212673: jtreg/applications/runthese/RunThese30M.java fails in C2 with "assert(!had_error) failed: bad dominance" Message-ID: <20449474-8ae6-bc10-b5b5-0e7806ff40cc@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8212673 https://hg.openjdk.java.net/jdk/jdk/rev/bac05440d98c Note it includes the reversal of: https://bugs.openjdk.java.net/browse/JDK-8212603 https://hg.openjdk.java.net/jdk/jdk/rev/6eb876ac6827 ...and therefore does not apply cleanly to 11u. I would prefer we push this single change, without prior (obviously broken) JDK-8212603. I believe Oracle did the same, as they have 11.0.6-oracle only on this issue. qfolding both changes yields this 11u webrev: https://cr.openjdk.java.net/~shade/8212673/webrev.11u.01/ Testing: Linux x86_64 fastdebug: tier1, tier2 -- Thanks, -Aleksey From christoph.langer at sap.com Tue Sep 3 14:40:43 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Sep 2019 14:40:43 +0000 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> Message-ID: Hi Stuart, I've just reviewed the CSR and added your fix to our test queue. I'll let you know the outcome. Once the CSR is approved, will you want to push it to OpenJDK 11u-dev or shall I do it for you? I would probably restore the patch metadata of the commit in jdk/jdk then (https://hg.openjdk.java.net/jdk/jdk13/rev/7fd4446c02ee)... Thanks & Best regards Christoph > -----Original Message----- > From: Stuart Marks > Sent: Donnerstag, 29. August 2019 08:33 > To: Langer, Christoph > Cc: Peter Levart ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in > JDK 9+ > > Hi, I'm finally getting back to this. Sorry for the delay. > > I've written up a CSR for this. Can you review it please? When you've done > so, > please edit the CSR and add your OpenJDK user ID to the Reviewed By box > (scroll > most of the way to the bottom). > > https://bugs.openjdk.java.net/browse/JDK-8230331 > > I'm using this CSR to apply to both OpenJDK 11.0.x and Oracle JDK 11.0.x. The > code change is the same and all the same issues apply. Note that this change > is > quite different from the JDK 13 change, so the CSR is quite different as well. > I've included some background and the explanation I posted in this email > thread > earlier. > > The webrev is unchanged from my posting a few weeks ago: > > http://cr.openjdk.java.net/~smarks/reviews/8227368.jdk11u/webrev.0/ > > (I haven't rebased it to the very latest jdk11u-dev; I suppose it might change > somewhat, though I think it unlikely.) > > Christoph, I'd appreciate it if you could run this change through SAP's test > system. Please let me know about the results or any problems you > encounter. > > Thanks! > > s'marks > > On 8/8/19 2:54 PM, Langer, Christoph wrote: > > Hi Stuart, > > > > I think it'd be great if you could do the CSR and Peter could review it (I, > maybe, can have a look as well). > > > > When it comes to testing, I can offer our test system for OpenJDK 11u here > at SAP. > > Would the change still be the one at: > > http://cr.openjdk.java.net/~smarks/reviews/8227368.jdk11u/webrev.0/? > > (BTW: I've got the feeling that this looks slightly different now compared to > this morning??) > > > > By recognizing a backport issue targeted for 11.0.6-oracle, I take that you'll > also bring the change to the Oracle 11u release and it will be the same then? > We definitely shouldn't differ at this place... And in that case I suppose you'd > have had to file a CSR anyway since I understood Joe telling that Oracle 11u > would use the CSR process. > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: Stuart Marks > >> Sent: Donnerstag, 8. August 2019 23:31 > >> To: Peter Levart > >> Cc: Langer, Christoph ; jdk-updates- > >> dev at openjdk.java.net > >> Subject: Re: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in > >> JDK 9+ > >> > >> On 8/8/19 9:49 AM, Peter Levart wrote: > >>> Perhaps it would be best if you continue with it, since you have access to > >>> various facilities needed for this patch (JCK tests for example) and are > more > >>> acquainted with the JSR process. > >> > >> Yes, I can do this. (I think you meant CSR; JSR is a different thing!) > >> > >> Can I consider you as a reviewer? > >> > >> s'marks From shade at redhat.com Tue Sep 3 14:52:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 3 Sep 2019 16:52:50 +0200 Subject: RFR (S) 8229016: C2 scalarization crashes with assert(node->Opcode() == Op_CastP2X) failed: ConvP2XNode required Message-ID: <2e39fbb9-29bc-024b-daf0-604e1014c2d3@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8229016 https://hg.openjdk.java.net/jdk/jdk/rev/1d2ea8db7083 Patch applies cleanly, but the new test still crashes! And there is still 11.0.6-oracle backport recorded. Tobias H says we need another line from here: https://hg.openjdk.java.net/jdk/jdk/rev/e3d79743f57d#l13.7 After that, new test passes. We could consider backporting the entire JDK-8212243, but it does not apply cleanly with lots of conflicts, and resolving those would take a lot of time. I believe picking up that one-liner fix is a better idea. So, full 11u webrev: https://cr.openjdk.java.net/~shade/8229016/webrev.11u.01/ Testing: new test, tier1 -- Thanks, -Aleksey From shade at redhat.com Tue Sep 3 14:58:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 3 Sep 2019 16:58:22 +0200 Subject: [11u] RFR (S) 8229016: C2 scalarization crashes with assert(node->Opcode() == Op_CastP2X) failed: ConvP2XNode required In-Reply-To: <2e39fbb9-29bc-024b-daf0-604e1014c2d3@redhat.com> References: <2e39fbb9-29bc-024b-daf0-604e1014c2d3@redhat.com> Message-ID: <42028245-a715-6a4c-627d-8a01d3687527@redhat.com> (resending with proper subject prefix) On 9/3/19 4:52 PM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8229016 > https://hg.openjdk.java.net/jdk/jdk/rev/1d2ea8db7083 > > Patch applies cleanly, but the new test still crashes! And there is still 11.0.6-oracle backport > recorded. Tobias H says we need another line from here: > https://hg.openjdk.java.net/jdk/jdk/rev/e3d79743f57d#l13.7 > > After that, new test passes. We could consider backporting the entire JDK-8212243, but it does not > apply cleanly with lots of conflicts, and resolving those would take a lot of time. I believe > picking up that one-liner fix is a better idea. > > So, full 11u webrev: > https://cr.openjdk.java.net/~shade/8229016/webrev.11u.01/ > > Testing: new test, tier1 -- Thanks, -Aleksey From mbalao at redhat.com Tue Sep 3 16:52:12 2019 From: mbalao at redhat.com (Martin Balao) Date: Tue, 3 Sep 2019 13:52:12 -0300 Subject: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: Message-ID: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> Hi Christoph, Thanks for having a look at this one. I'm still not sure of the value of a new CSR when there are no version-specific changes, as in this case. My proposal for these cases was for the maintainer to consider the original CSR output and decide whether the backport is approved or not. Anyways, here it is the new CSR (a copy & paste of the original, with a few references to JDK-11 review thread and webrev): https://bugs.openjdk.java.net/browse/JDK-8230496 I'll rebase the proposed changeset to 8224589. Kind regards, Martin.- On 8/30/19 8:45 AM, Langer, Christoph wrote: > Hi Martin, > > review-wise this looks ok. Seems most part of the change applies cleanly, net copyright. > > As for SecurityProperties.java, you should await the landing of JDK-8224589 in jdk11u-dev. Then you won't need to do anything for it. > > Process-wise, you'll need to go through CSR review with this. Please create a backport item for this bug with fix version 11-pool and then create a CSR from that backport. You can probably largely copy and paste the content of the original CSR. Once this is reviewed, we'll approve the fix (again) for 11u. The CSR is needed to make sure no inappropriate changes in behavior get backported - though I don't think that's the case with this. > > Thanks > Christoph > From christoph.langer at sap.com Tue Sep 3 18:59:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Sep 2019 18:59:10 +0000 Subject: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> References: <57d1dd6b-3395-cb87-de91-690893332468@redhat.com> Message-ID: Hi Martin, thanks for creating the CSR. Although it seems there's not much benefit of it in this particular case, I think CSR is a review type that should be done for update releases. Maybe there are inappropriate interface changes which neither the engineer that does the backport nor a maintainer of an update release can oversee. I would hope such things get caught there. Best regards Christoph > -----Original Message----- > From: Martin Balao > Sent: Dienstag, 3. September 2019 18:52 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8215032: Support Kerberos cross-realm referrals (RFC > 6806) > > Hi Christoph, > > Thanks for having a look at this one. > > I'm still not sure of the value of a new CSR when there are no > version-specific changes, as in this case. My proposal for these cases > was for the maintainer to consider the original CSR output and decide > whether the backport is approved or not. > > Anyways, here it is the new CSR (a copy & paste of the original, with a > few references to JDK-11 review thread and webrev): > https://bugs.openjdk.java.net/browse/JDK-8230496 > > I'll rebase the proposed changeset to 8224589. > > Kind regards, > Martin.- > > > On 8/30/19 8:45 AM, Langer, Christoph wrote: > > Hi Martin, > > > > review-wise this looks ok. Seems most part of the change applies cleanly, > net copyright. > > > > As for SecurityProperties.java, you should await the landing of JDK-8224589 > in jdk11u-dev. Then you won't need to do anything for it. > > > > Process-wise, you'll need to go through CSR review with this. Please create > a backport item for this bug with fix version 11-pool and then create a CSR > from that backport. You can probably largely copy and paste the content of > the original CSR. Once this is reviewed, we'll approve the fix (again) for 11u. > The CSR is needed to make sure no inappropriate changes in behavior get > backported - though I don't think that's the case with this. > > > > Thanks > > Christoph > > From yasuenag at gmail.com Wed Sep 4 06:19:42 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 Sep 2019 15:19:42 +0900 Subject: Could not push the change to jdk13u Message-ID: <5f607680-b979-e492-5884-f3b07fed6a00@gmail.com> Hi all, I attempted to import the change [1] to jdk13u, but hg reported the error as below: ``` $ hg out : searching for changes changeset: 55600:8aa7cb25482a tag: tip user: ysuenaga date: Wed Sep 04 15:12:43 2019 +0900 summary: 8209790: SA tools not providing option to connect to debug server $ hg push : searching for changes remote: Received disconnect from 137.254.56.63 port 22:2: Corrupted MAC on input. remote: Disconnected from 137.254.56.63 port 22 abort: unexpected response: empty string ``` I tried to push it as a new commit, but it was failed with same error. hg verify seems to work fine. Do you have any idea to resolve this? Thanks, Yasumasa [1] https://hg.openjdk.java.net/jdk/jdk/rev/56e8c0a3fe9a From christoph.langer at sap.com Wed Sep 4 06:24:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 06:24:06 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Message-ID: Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn't exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph From christoph.langer at sap.com Wed Sep 4 06:41:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 06:41:20 +0000 Subject: [11u] RFR: 8213448 [TESTBUG] enhance jfr/jvm/TestDumpOnCrash In-Reply-To: References: Message-ID: And done. > -----Original Message----- > From: Langer, Christoph > Sent: Dienstag, 3. September 2019 16:07 > To: Jie Kang > Cc: jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR: 8213448 [TESTBUG] enhance > jfr/jvm/TestDumpOnCrash > > Hi Jie, > > great. I added your new patch to our nightly test queue. I'll probably push it > tomorrow once the test results show green. > > Thanks & Best regards > Christoph > > > -----Original Message----- > > From: Jie Kang > > Sent: Dienstag, 3. September 2019 15:49 > > To: Langer, Christoph > > Cc: jdk-updates-dev at openjdk.java.net > > Subject: Re: [11u] RFR: 8213448 [TESTBUG] enhance > > jfr/jvm/TestDumpOnCrash > > > > On Sun, Sep 1, 2019 at 2:31 AM Langer, Christoph > > wrote: > > > > > > Hi Jie, > > > > > > I approved the 11u fix. I assume you'll be happy if I also push the change > for > > you as you aren't a committer, correct? > > > > Hi Christoph, > > > > Yes that would be appreciated. I have also added an updated webrev > > below that maintains the proper commit message and author from > > jdk/jdk. I have compared the raw file to my previous webrev to be the > > same, as well as to the original commit to only differ with the single > > line ("-XX:-TransmitErrorReport") described previously. > > > > Updated webrev: > > http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.01/ > > > > I will make sure to do this from now on; thank you! > > > > > > Regards, > > > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: Langer, Christoph > > > > Sent: Freitag, 30. August 2019 14:09 > > > > To: Jie Kang ; jdk-updates-dev at openjdk.java.net > > > > Subject: RE: [11u] RFR: 8213448 [TESTBUG] enhance > > > > jfr/jvm/TestDumpOnCrash > > > > > > > > Hi Jie, > > > > > > > > this looks good to me. > > > > > > > > Best regards > > > > Christoph > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev bounces at openjdk.java.net> > > On > > > > > Behalf Of Jie Kang > > > > > Sent: Mittwoch, 28. August 2019 16:59 > > > > > To: jdk-updates-dev at openjdk.java.net > > > > > Subject: [11u] RFR: 8213448 [TESTBUG] enhance > > jfr/jvm/TestDumpOnCrash > > > > > > > > > > Hi all, > > > > > > > > > > Please review this test-only backport of 8213448 to OpenJDK jdk11u- > > dev > > > > > so as to get a significantly cleaner backport for JDK-8217362 [1]. The > > > > > fix did not apply cleanly as a one-line removal to the file is missing > > > > > from JDK-8209856 [2]. My process was to make this one-line removal, > > > > > apply the patch, and then revert the one line removal. I have run tier > > > > > one tests and jfr specific tests successfully. Please let me know how > > > > > it looks and if it is appropriate to backport to 11. > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8213448/webrev.00/ > > > > > Original Changeset: > > http://hg.openjdk.java.net/jdk/jdk/rev/f0af7fd0c9ca > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213448 > > > > > > > > > > [1] > > > > > Would allow a cleaner backport of: > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9#l5.1 > > > > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > > > > > > > > > [2] > > > > > The missing one-line removal: > > > > > http://hg.openjdk.java.net/jdk/jdk/rev/d7fc38d3fc8d#l19.7 > > > > > https://bugs.openjdk.java.net/browse/JDK-8209856 From christoph.langer at sap.com Wed Sep 4 07:08:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 07:08:57 +0000 Subject: Could not push the change to jdk13u In-Reply-To: <5f607680-b979-e492-5884-f3b07fed6a00@gmail.com> References: <5f607680-b979-e492-5884-f3b07fed6a00@gmail.com> Message-ID: Hi Yasumasa, I could push the change for you: http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/eea1d5a57dcd Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Yasumasa Suenaga > Sent: Mittwoch, 4. September 2019 08:20 > To: jdk-updates-dev at openjdk.java.net > Subject: Could not push the change to jdk13u > > Hi all, > > I attempted to import the change [1] to jdk13u, but hg reported the error as > below: > > ``` > $ hg out > : > searching for changes > changeset: 55600:8aa7cb25482a > tag: tip > user: ysuenaga > date: Wed Sep 04 15:12:43 2019 +0900 > summary: 8209790: SA tools not providing option to connect to debug > server > > $ hg push > : > searching for changes > remote: Received disconnect from 137.254.56.63 port 22:2: Corrupted MAC > on input. > remote: Disconnected from 137.254.56.63 port 22 > abort: unexpected response: empty string > ``` > > I tried to push it as a new commit, but it was failed with same error. > hg verify seems to work fine. > > Do you have any idea to resolve this? > > > Thanks, > > Yasumasa > > > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/56e8c0a3fe9a From yasuenag at gmail.com Wed Sep 4 07:11:37 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 4 Sep 2019 16:11:37 +0900 Subject: Could not push the change to jdk13u In-Reply-To: References: <5f607680-b979-e492-5884-f3b07fed6a00@gmail.com> Message-ID: <526f5576-8d74-edfb-3f0d-7677af39027f@gmail.com> Thanks Christoph! I will clone jdk13u again... Yasumasa On 2019/09/04 16:08, Langer, Christoph wrote: > Hi Yasumasa, > > I could push the change for you: > http://hg.openjdk.java.net/jdk-updates/jdk13u/rev/eea1d5a57dcd > > Best regards > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Yasumasa Suenaga >> Sent: Mittwoch, 4. September 2019 08:20 >> To: jdk-updates-dev at openjdk.java.net >> Subject: Could not push the change to jdk13u >> >> Hi all, >> >> I attempted to import the change [1] to jdk13u, but hg reported the error as >> below: >> >> ``` >> $ hg out >> : >> searching for changes >> changeset: 55600:8aa7cb25482a >> tag: tip >> user: ysuenaga >> date: Wed Sep 04 15:12:43 2019 +0900 >> summary: 8209790: SA tools not providing option to connect to debug >> server >> >> $ hg push >> : >> searching for changes >> remote: Received disconnect from 137.254.56.63 port 22:2: Corrupted MAC >> on input. >> remote: Disconnected from 137.254.56.63 port 22 >> abort: unexpected response: empty string >> ``` >> >> I tried to push it as a new commit, but it was failed with same error. >> hg verify seems to work fine. >> >> Do you have any idea to resolve this? >> >> >> Thanks, >> >> Yasumasa >> >> >> >> [1] https://hg.openjdk.java.net/jdk/jdk/rev/56e8c0a3fe9a From jaroslav.bachorik at datadoghq.com Wed Sep 4 10:14:52 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 4 Sep 2019 12:14:52 +0200 Subject: [11u] RFR 8208601: Introduce native oop barriers in C2 for OopHandle Message-ID: Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8208601 https://hg.openjdk.java.net/jdk/jdk12/rev/0c7040d1d1ca Backport requires JDK-8208582 . The patch does not apply cleanly due to minor differences in the context of barrierSetC2.cpp but manual resolution is extremely simple. Rej file: http://cr.openjdk.java.net/~jbachorik/8208601/barrierSetC2.cpp.rej 11u webrev: http://cr.openjdk.java.net/~jbachorik/8208601/ Testing: - tier1 - tier2 Thanks, -JB- From shade at redhat.com Wed Sep 4 10:51:21 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 4 Sep 2019 12:51:21 +0200 Subject: [11u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries Message-ID: <289d4751-75fa-b846-92e3-04a920422855@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8225425 https://hg.openjdk.java.net/jdk/jdk/rev/56df9a08ed9c This one is 11u-critical. Patch applies cleanly, but test fails to compile, because there is no URIBuilder in 11u. It was added later by JDK-8220575. I picked up the copy from there. 11u webrev: http://cr.openjdk.java.net/~shade/8225425/webrev.11u.01/ Testing: Windows 7: build, new test, tier1 (running) -- Thanks, -Aleksey From christoph.langer at sap.com Wed Sep 4 12:43:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 12:43:10 +0000 Subject: [11u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: <289d4751-75fa-b846-92e3-04a920422855@redhat.com> References: <289d4751-75fa-b846-92e3-04a920422855@redhat.com> Message-ID: Hi Aleksey, thanks for taking this item. Patch looks good to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Mittwoch, 4. September 2019 12:51 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find > dependent libraries > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8225425 > https://hg.openjdk.java.net/jdk/jdk/rev/56df9a08ed9c > > This one is 11u-critical. > > Patch applies cleanly, but test fails to compile, because there is no URIBuilder > in 11u. It was > added later by JDK-8220575. I picked up the copy from there. > > 11u webrev: > http://cr.openjdk.java.net/~shade/8225425/webrev.11u.01/ > > Testing: Windows 7: build, new test, tier1 (running) > > -- > Thanks, > -Aleksey From shade at redhat.com Wed Sep 4 13:25:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 4 Sep 2019 15:25:38 +0200 Subject: [11u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: References: <289d4751-75fa-b846-92e3-04a920422855@redhat.com> Message-ID: <4884bf4c-8c30-b800-9983-ea851278c39d@redhat.com> On 9/4/19 2:43 PM, Langer, Christoph wrote: > Hi Aleksey, > > thanks for taking this item. Patch looks good to me. Thanks. I am going to push this to jdk-updates/jdk11u soon then, right? -- Thanks, -Aleksey From christoph.langer at sap.com Wed Sep 4 13:29:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 13:29:29 +0000 Subject: [11u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: <4884bf4c-8c30-b800-9983-ea851278c39d@redhat.com> References: <289d4751-75fa-b846-92e3-04a920422855@redhat.com> <4884bf4c-8c30-b800-9983-ea851278c39d@redhat.com> Message-ID: > > thanks for taking this item. Patch looks good to me. > Thanks. I am going to push this to jdk-updates/jdk11u soon then, right? Yep, that would be great. /Christoph From shade at redhat.com Wed Sep 4 13:32:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 4 Sep 2019 15:32:50 +0200 Subject: [11u] RFR 8225425: java.lang.UnsatisfiedLinkError: net.dll: Can't find dependent libraries In-Reply-To: References: <289d4751-75fa-b846-92e3-04a920422855@redhat.com> <4884bf4c-8c30-b800-9983-ea851278c39d@redhat.com> Message-ID: <173cdb5e-9676-8677-9235-390ff7534d06@redhat.com> On 9/4/19 3:29 PM, Langer, Christoph wrote: >>> thanks for taking this item. Patch looks good to me. >> Thanks. I am going to push this to jdk-updates/jdk11u soon then, right? > Yep, that would be great. There we go: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/343f922e2fbe -- Thanks, -Aleksey From jaroslav.bachorik at datadoghq.com Wed Sep 4 13:43:46 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 4 Sep 2019 15:43:46 +0200 Subject: FW: [11u] RFR: 8214542: JFR: Old Object Sample event slow on a deep heap in debug builds In-Reply-To: References: Message-ID: Hi Christoph, the patch looks ok to me. The changes you had to do to resolve the conflicts seems harmless. For me, good to go. Cheers, -JB- > > Hi, > > > > please help reviewing the backport of this JFR related bugfix to JDK11. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214542 > > Original Change: http://hg.openjdk.java.net/jdk/jdk13/rev/49102ba8cf14 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8214542.11u-dev.0/ > > > > The original patch did not apply cleanly. There were some rejects: > http://cr.openjdk.java.net/~clanger/webrevs/8214542.11u-dev.0/8214542.rejects.patch > > > > I had to resolve the following files: > > src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp > > src/hotspot/share/jfr/leakprofiler/emitEventOperation.hpp > > src/hotspot/share/jfr/leakprofiler/leakProfiler.hpp > > src/hotspot/share/jfr/leakprofiler/startOperation.hpp > > src/hotspot/share/jfr/leakprofiler/stopOperation.hpp > > src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp > > src/hotspot/share/runtime/vmOperations.hpp > > > > Resolving was quite straightforward. In jdk11u-dev, the file > src/hotspot/share/runtime/vmOperations.hpp is still called > src/hotspot/share/runtime/vm_operations.hpp. > > > > With this patch applied, no regressions were observed in SAP?s test > infrastructure. So I tend to say it works. But it would be good to get this > verified by somebody else who has some more knowledge in the JFR area. > > > > I?ll also request the backport of JDK-8228834 and push it together with > this patch because it is linked to bug JDK-8214542 as regression. It was > also included in my testing. > > > > Thanks > > Christoph > > > From christoph.langer at sap.com Wed Sep 4 13:53:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 13:53:01 +0000 Subject: [DMARC FAILURE] [11u] RFR 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: References: Message-ID: Hi Jaroslav, when resolving barrierSetC2.cpp, you need to take into account that JDK-8218879 "Keep track of memory accesses originated from Unsafe" was already backported to jdk11u-dev. So I believe you need to add the variable unsafe to the call to kit->make_load in lines 118/119 (new). See: http://hg.openjdk.java.net/jdk/jdk/rev/e002408eb0c0 I'll add the patches for JDK-8208582, JDK-8208601 (with the added unsafe) and JDK-8210158 to our test queue and let you know the results. Please don't push until then. Thanks & Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Jaroslav Bachor?k > Sent: Mittwoch, 4. September 2019 12:15 > To: jdk-updates-dev at openjdk.java.net > Subject: [DMARC FAILURE] [11u] RFR 8208601: Introduce native oop barriers > in C2 for OopHandle > > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8208601 > https://hg.openjdk.java.net/jdk/jdk12/rev/0c7040d1d1ca > > Backport requires JDK-8208582 > . > The patch does not apply cleanly due to minor differences in the context of > barrierSetC2.cpp > but > manual resolution is extremely simple. > > Rej file: http://cr.openjdk.java.net/~jbachorik/8208601/barrierSetC2.cpp.rej > > 11u webrev: > http://cr.openjdk.java.net/~jbachorik/8208601/ > > Testing: > - tier1 > - tier2 > > Thanks, > > -JB- From matthias.baesken at sap.com Wed Sep 4 14:54:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 4 Sep 2019 14:54:16 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: Hello Christoph, the change looks good to me . However I suggest to wait a day or two for more feedback , because http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/test/jdk/sun/security/pkcs11/PKCS11Test.java.frames.html 889 @Artifact( 890 organization = "jpg.tests.jdk.nsslib", 891 name = "nsslib-windows_x64", 892 revision = "3.41-VS2017", 893 extension = "zip") 894 private static class WINDOWS_X64 { } 895 896 @Artifact( 897 organization = "jpg.tests.jdk.nsslib", 898 name = "nsslib-windows_x86", 899 revision = "3.41-VS2017", 900 extension = "zip") ? looks like everyone executing these tests on Windows needs the VS2017 runtimes , isn?t it ? Is this really true for at least the main parties working on jdk11 ? In current 11u-dev I find : toolchain_windows.m4:28:VALID_VS_VERSIONS="2017 2013 2015 2012 2010" Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 4. September 2019 08:24 To: jdk-updates-dev at openjdk.java.net Cc: security-dev > Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn?t exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph From christoph.langer at sap.com Wed Sep 4 14:59:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 4 Sep 2019 14:59:59 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: Hi Matthias, good point. What do e.g. Redhat folks say about VS2017 requirement? (@Aleksey) Or will the test also work with these artifacts if using a VS < 2017 to build the JDK? (Maybe somebody on security-dev with some experience with these tests can shed some light on this?) Thanks Christoph From: Baesken, Matthias Sent: Mittwoch, 4. September 2019 16:54 To: Langer, Christoph ; security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hello Christoph, the change looks good to me . However I suggest to wait a day or two for more feedback , because http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/test/jdk/sun/security/pkcs11/PKCS11Test.java.frames.html 889 @Artifact( 890 organization = "jpg.tests.jdk.nsslib", 891 name = "nsslib-windows_x64", 892 revision = "3.41-VS2017", 893 extension = "zip") 894 private static class WINDOWS_X64 { } 895 896 @Artifact( 897 organization = "jpg.tests.jdk.nsslib", 898 name = "nsslib-windows_x86", 899 revision = "3.41-VS2017", 900 extension = "zip") ? looks like everyone executing these tests on Windows needs the VS2017 runtimes , isn?t it ? Is this really true for at least the main parties working on jdk11 ? In current 11u-dev I find : toolchain_windows.m4:28:VALID_VS_VERSIONS="2017 2013 2015 2012 2010" Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 4. September 2019 08:24 To: jdk-updates-dev at openjdk.java.net Cc: security-dev > Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn?t exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph From christoph.langer at sap.com Thu Sep 5 10:26:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Sep 2019 10:26:53 +0000 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry Message-ID: Hi, may I please get a review for the backport of this item to jdk11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path path) that is used in the test was only introduced in JDK13. So I have to fallback to java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. Thanks Christoph From stuart.marks at oracle.com Thu Sep 5 19:59:12 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 5 Sep 2019 12:59:12 -0700 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> Message-ID: On 9/3/19 7:40 AM, Langer, Christoph wrote: > Hi Stuart, > > I've just reviewed the CSR and added your fix to our test queue. I'll let you know the outcome. > > Once the CSR is approved, will you want to push it to OpenJDK 11u-dev or shall I do it for you? I would probably restore the patch metadata of the commit in jdk/jdk then (https://hg.openjdk.java.net/jdk/jdk13/rev/7fd4446c02ee)... > > Thanks & Best regards > Christoph Hi, thanks for testing. Any results yet? Thanks also for reviewing the CSR. It's approved now. Regarding the metadata for the patch, my inclination is for me to be the author of the patch and to list Peter among the reviewers. Of course while Peter deserves the credit for finding the problem in the first place and for fixing it in JDK 13, this "backport" is significantly different from the original bugfix. More importantly, I think I should be listed as the author as an indication of responsibility for it. That is, if something were to go wrong with this patch, I'd be responsible for fixing it. Does that make sense? I can push the change myself. Is this still ok to go into 11.0.5? s'marks From christoph.langer at sap.com Fri Sep 6 06:28:39 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 06:28:39 +0000 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> Message-ID: Hi Stuart, > Hi, thanks for testing. Any results yet? I'd say it looks great ?? No issues spotted... > Thanks also for reviewing the CSR. It's approved now. > > Regarding the metadata for the patch, my inclination is for me to be the author > of the patch and to list Peter among the reviewers. Of course while Peter > deserves the credit for finding the problem in the first place and for fixing it > in JDK 13, this "backport" is significantly different from the original bugfix. > More importantly, I think I should be listed as the author as an indication of > responsibility for it. That is, if something were to go wrong with this patch, > I'd be responsible for fixing it. Does that make sense? Sure, perfect. > I can push the change myself. Is this still ok to go into 11.0.5? I would like to see this change hit the same OpenJDK release as the Oracle release. For Oracle I can see a backport item for 11.0.6-oracle (JDK-8228350). Do you intend to promote it to 11.0.5 as well? Thanks Christoph From shade at redhat.com Fri Sep 6 08:36:26 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 10:36:26 +0200 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: References: Message-ID: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> On 9/5/19 12:26 PM, Langer, Christoph wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ Backport looks good. > The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path > path) that is used in the test was only introduced in JDK13. So I have to fallback to > java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines > 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. Have you tried if the new test fails without the product patch? -- Thanks, -Aleksey From shade at redhat.com Fri Sep 6 08:47:14 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 10:47:14 +0200 Subject: [11u] RFR: Backport 8215699: -Xlog::file cannot be used with named pipe In-Reply-To: References: Message-ID: <826316ac-f357-b8c3-8eff-5c567d8e01dd@redhat.com> On 8/27/19 8:44 PM, Simon Tooke wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8215699 > modified webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8215699-jdk11u/00/ > original patch: http://hg.openjdk.java.net/jdk/jdk/rev/55cee96fefec Backport looks good. You need a sponsor, right? Tell me and I can push for you. -- Thanks, -Aleksey From shade at redhat.com Fri Sep 6 08:52:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 10:52:25 +0200 Subject: [11u] RFR Backport 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle In-Reply-To: References: Message-ID: <62617fd6-e253-92d4-0de6-75a51c61ef28@redhat.com> On 8/27/19 10:54 PM, Simon Tooke wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8220352 > > modified webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8220352-jdk11/00/ > original patch: http://hg.openjdk.java.net/jdk/jdk/rev/db545bf94fbc Backport looks good. Need a sponsor here? I can push. -- Thanks, -Aleksey From shade at redhat.com Fri Sep 6 08:55:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 10:55:53 +0200 Subject: [11u] RFR(XS): 8221407: Windows 32bit build error in libsunmscapi/security.cpp In-Reply-To: References: Message-ID: <2dacf67d-abdb-7547-86a0-7e809096546a@redhat.com> On 9/2/19 11:24 AM, Langer, Christoph wrote: > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221407.11u-dev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221407 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c02b8d6384ab Backport looks good. But I have to wonder: are the upstream changes that introduce other chunks (ignored in this backport) have a chance to be backported as well? Because if so, we would need to remember to adjust accordingly. Maybe we should backport those first? -- Thanks, -Aleksey From christoph.langer at sap.com Fri Sep 6 09:24:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 09:24:20 +0000 Subject: [11u] RFR(XS): 8221407: Windows 32bit build error in libsunmscapi/security.cpp In-Reply-To: <2dacf67d-abdb-7547-86a0-7e809096546a@redhat.com> References: <2dacf67d-abdb-7547-86a0-7e809096546a@redhat.com> Message-ID: > On 9/2/19 11:24 AM, Langer, Christoph wrote: > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221407.11u- dev.0/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221407 > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/c02b8d6384ab > > Backport looks good. > > But I have to wonder: are the upstream changes that introduce other chunks > (ignored in this backport) have a chance to be backported as well? Because if so, we would > need to remember to adjust accordingly. Maybe we should backport those first? Thanks for looking at this. It's already submitted, though. However, you're right that one needs to take care to include the fixes from this change for the other chunks, should they ever get backported. But I didn't want to pull more stuff than needed with this simple backport. Cheers Christoph From christoph.langer at sap.com Fri Sep 6 09:35:12 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 09:35:12 +0000 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> References: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> Message-ID: Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ > > Backport looks good. Thanks for reviewing this. > > The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path > > path) that is used in the test was only introduced in JDK13. So I have to fallback to > > java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines > > 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. > Have you tried if the new test fails without the product patch? Yes, I have. The failure can be reproduced. Will push it to jdk11u then. Best regards Christoph From shade at redhat.com Fri Sep 6 09:38:57 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 11:38:57 +0200 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: References: <89e7b892-cce7-8b4e-46bc-12be931e3ac4@redhat.com> Message-ID: On 9/6/19 11:35 AM, Langer, Christoph wrote: > Will push it to jdk11u then. Feels right. -- Thanks, -Aleksey From shade at redhat.com Fri Sep 6 10:00:03 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 6 Sep 2019 12:00:03 +0200 Subject: [11u] RFR: 8214542: JFR: Old Object Sample event slow on a deep heap in debug builds In-Reply-To: References: Message-ID: On 9/2/19 2:45 PM, Langer, Christoph wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8214542 > Original Change: http://hg.openjdk.java.net/jdk/jdk13/rev/49102ba8cf14 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8214542.11u-dev.0/ Ugh, this patch is way too big to be fun. I read both upstream and this patch side-by-side, and there are no blatant mistakes. Also cross-checked the patch rejects, and they seem to be reapplied correctly. Can you please build it with --disable-precompiled-headers, for my sanity? -- Thanks, -Aleksey From rwestrel at redhat.com Fri Sep 6 11:13:55 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 06 Sep 2019 13:13:55 +0200 Subject: [11u] RFR 8218468: Load barrier slow path node should be MachTypeNode In-Reply-To: <066146d3-0a10-ffea-e5c5-fd9ea80e9b79@redhat.com> References: <066146d3-0a10-ffea-e5c5-fd9ea80e9b79@redhat.com> Message-ID: <87y2z1llsc.fsf@redhat.com> > 11u patch: > > diff -r cb90ceb87071 src/hotspot/share/adlc/formssel.cpp > --- a/src/hotspot/share/adlc/formssel.cpp Tue Nov 06 23:03:05 2018 +0100 > +++ b/src/hotspot/share/adlc/formssel.cpp Mon Sep 02 17:12:54 2019 +0200 > @@ -791,4 +791,8 @@ > !strcmp(_matrule->_rChild->_opType,"GetAndSetP") || > !strcmp(_matrule->_rChild->_opType,"GetAndSetN") || > +#if INCLUDE_ZGC > + !strcmp(_matrule->_rChild->_opType,"LoadBarrierSlowReg") || > + !strcmp(_matrule->_rChild->_opType,"LoadBarrierWeakSlowReg") || > +#endif > !strcmp(_matrule->_rChild->_opType,"CompareAndExchangeP") || > !strcmp(_matrule->_rChild->_opType,"CompareAndExchangeN"))) return true; > > Testing: Linux x86_64, tier1, tier2 Looks good to me. Roland. From rwestrel at redhat.com Fri Sep 6 11:19:30 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 06 Sep 2019 13:19:30 +0200 Subject: [11u] RFR (S) 8212673: jtreg/applications/runthese/RunThese30M.java fails in C2 with "assert(!had_error) failed: bad dominance" In-Reply-To: <20449474-8ae6-bc10-b5b5-0e7806ff40cc@redhat.com> References: <20449474-8ae6-bc10-b5b5-0e7806ff40cc@redhat.com> Message-ID: <87v9u5llj1.fsf@redhat.com> > https://cr.openjdk.java.net/~shade/8212673/webrev.11u.01/ Looks good to me. Roland. From rwestrel at redhat.com Fri Sep 6 11:23:02 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 06 Sep 2019 13:23:02 +0200 Subject: [11u] RFR (S) 8229016: C2 scalarization crashes with assert(node->Opcode() == Op_CastP2X) failed: ConvP2XNode required In-Reply-To: <42028245-a715-6a4c-627d-8a01d3687527@redhat.com> References: <2e39fbb9-29bc-024b-daf0-604e1014c2d3@redhat.com> <42028245-a715-6a4c-627d-8a01d3687527@redhat.com> Message-ID: <87sgp9lld5.fsf@redhat.com> >> https://cr.openjdk.java.net/~shade/8229016/webrev.11u.01/ Looks good to me. Roland. From christoph.langer at sap.com Fri Sep 6 12:48:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 12:48:42 +0000 Subject: [11u] RFR: 8214542: JFR: Old Object Sample event slow on a deep heap in debug builds In-Reply-To: References: Message-ID: > On 9/2/19 2:45 PM, Langer, Christoph wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214542 > > Original Change: http://hg.openjdk.java.net/jdk/jdk13/rev/49102ba8cf14 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8214542.11u- > dev.0/ > > Ugh, this patch is way too big to be fun. > > I read both upstream and this patch side-by-side, and there are no blatant > mistakes. Also > cross-checked the patch rejects, and they seem to be reapplied correctly. > > Can you please build it with --disable-precompiled-headers, for my sanity? Thanks for checking this. I ran the build on linux_x86 with --disable-precompiled-headers and it succeeded. My testing doesn't show regressions so I'm gonna push this shortly. Thanks Christoph From christoph.langer at sap.com Fri Sep 6 12:54:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 6 Sep 2019 12:54:28 +0000 Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed In-Reply-To: References: Message-ID: Hi, since there?s apparently no veto on this (nor encouraging statements), I?ll go ahead and push this testfix soon. After all, it?ll just re-enable a few tests where I can?t see problems with. Should somebody run into issues with the tests because of this update, we can always disable them again. Thanks Christoph From: Langer, Christoph Sent: Mittwoch, 4. September 2019 17:00 To: Baesken, Matthias ; security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net; Aleksey Shipilev Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi Matthias, good point. What do e.g. Redhat folks say about VS2017 requirement? (@Aleksey) Or will the test also work with these artifacts if using a VS < 2017 to build the JDK? (Maybe somebody on security-dev with some experience with these tests can shed some light on this?) Thanks Christoph From: Baesken, Matthias > Sent: Mittwoch, 4. September 2019 16:54 To: Langer, Christoph >; security-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net Subject: RE: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hello Christoph, the change looks good to me . However I suggest to wait a day or two for more feedback , because http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/test/jdk/sun/security/pkcs11/PKCS11Test.java.frames.html 889 @Artifact( 890 organization = "jpg.tests.jdk.nsslib", 891 name = "nsslib-windows_x64", 892 revision = "3.41-VS2017", 893 extension = "zip") 894 private static class WINDOWS_X64 { } 895 896 @Artifact( 897 organization = "jpg.tests.jdk.nsslib", 898 name = "nsslib-windows_x86", 899 revision = "3.41-VS2017", 900 extension = "zip") ? looks like everyone executing these tests on Windows needs the VS2017 runtimes , isn?t it ? Is this really true for at least the main parties working on jdk11 ? In current 11u-dev I find : toolchain_windows.m4:28:VALID_VS_VERSIONS="2017 2013 2015 2012 2010" Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 4. September 2019 08:24 To: jdk-updates-dev at openjdk.java.net Cc: security-dev > Subject: [11u] RFR: 8204203: Many pkcs11 tests failed in Provider initialization, after compiler on Windows changed Hi, please review the backport of this testfix to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8204203 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/251090f84412 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8204203.11u.0/ The backport differs in that sun/security/tools/keytool/NssTest.java doesn?t exist in 11u and hence the changes for it were omitted. Jtreg testing over all platforms, especially Windows, shows no regressions. Thanks Christoph From hohensee at amazon.com Fri Sep 6 18:03:27 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 6 Sep 2019 18:03:27 +0000 Subject: [11u] RFR: 8229887: (zipfs) zip file corruption when replacing an existing STORED entry In-Reply-To: References: Message-ID: Looks good. Paul ?On 9/5/19, 3:28 AM, "jdk-updates-dev on behalf of Langer, Christoph" wrote: Hi, may I please get a review for the backport of this item to jdk11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8229887 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/abf6ee4c477c Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229887.11u.0/ The original patch applies cleanly but the method java.nio.file.FileSystems::newFileSystem(Path path) that is used in the test was only introduced in JDK13. So I have to fallback to java.nio.file.FileSystems:: newFileSystem(Path path, ClassLoader loader) at these places (lines 123, 163 and 195 of UpdateEntryTest). With this modification, the test passes. Thanks Christoph From aph at redhat.com Sat Sep 7 12:59:22 2019 From: aph at redhat.com (Andrew Haley) Date: Sat, 7 Sep 2019 13:59:22 +0100 Subject: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: Message-ID: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> On 8/23/19 7:06 AM, Yangfei (Felix) wrote: > Could I have a review for this backport to jdk11u-dev please? > > > > Webrev: http://cr.openjdk.java.net/~fyang/8209835-11u-backport/webrev.00/ OK, now that we've branched for the next release, this is a good time. -- 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 felix.yang at huawei.com Mon Sep 9 05:54:42 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 9 Sep 2019 05:54:42 +0000 Subject: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> References: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> Message-ID: > On 8/23/19 7:06 AM, Yangfei (Felix) wrote: > > Could I have a review for this backport to jdk11u-dev please? > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~fyang/8209835-11u-backport/webrev.00/ > > OK, now that we've branched for the next release, this is a good time. > Thanks for reviewing this. Could you please add a jdk11u-fix-yes label for 8209835 so I can do the push? Felix From aph at redhat.com Mon Sep 9 08:00:06 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Sep 2019 09:00:06 +0100 Subject: [DMARC FAILURE] [11u] RFR 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: References: Message-ID: <2a9928dd-fce6-4f1c-b652-5dd0e4971b28@redhat.com> On 9/4/19 2:53 PM, Langer, Christoph wrote: > I'll add the patches for JDK-8208582, JDK-8208601 (with the added > unsafe) and JDK-8210158 to our test queue and let you know the > results. Please don't push until then. I've looked at the Jira but it's not clear why we need this in 11u. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon Sep 9 09:02:10 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Sep 2019 09:02:10 +0000 Subject: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> Message-ID: Hi Felix, approved, label added. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Yangfei (Felix) > Sent: Montag, 9. September 2019 07:55 > To: Andrew Haley ; jdk-updates-dev at openjdk.java.net > Subject: RE: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile > operations > > > On 8/23/19 7:06 AM, Yangfei (Felix) wrote: > > > Could I have a review for this backport to jdk11u-dev please? > > > > > > > > > > > > Webrev: > > > http://cr.openjdk.java.net/~fyang/8209835-11u-backport/webrev.00/ > > > > OK, now that we've branched for the next release, this is a good time. > > > > Thanks for reviewing this. Could you please add a jdk11u-fix-yes label for > 8209835 so I can do the push? > > Felix From christoph.langer at sap.com Mon Sep 9 09:13:06 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Sep 2019 09:13:06 +0000 Subject: [DMARC FAILURE] [11u] RFR 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <2a9928dd-fce6-4f1c-b652-5dd0e4971b28@redhat.com> References: <2a9928dd-fce6-4f1c-b652-5dd0e4971b28@redhat.com> Message-ID: Hi Andrew, > > I'll add the patches for JDK-8208582, JDK-8208601 (with the added > > unsafe) and JDK-8210158 to our test queue and let you know the > > results. Please don't push until then. > > I've looked at the Jira but it's not clear why we need this in 11u. you mean why "JDK-8208601: Introduce native oop barriers in C2 for OopHandle" is needed? It is a prerequisite for "JDK-8210158: Accessorize JFR getEventWriter() intrinsics" which ought to resolve a potential JFR crash. But if only the patch for 8210158 was used, it would not compile. I think it would e.g. miss the definition of Node* access_load in graphKit.hpp. Best regards Christoph From jaroslav.bachorik at datadoghq.com Mon Sep 9 09:18:46 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 9 Sep 2019 11:18:46 +0200 Subject: [DMARC FAILURE] [11u] RFR 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: References: <2a9928dd-fce6-4f1c-b652-5dd0e4971b28@redhat.com> Message-ID: Hi, On Mon, Sep 9, 2019 at 11:13 AM Langer, Christoph wrote: > Hi Andrew, > > > > I'll add the patches for JDK-8208582, JDK-8208601 (with the added > > > unsafe) and JDK-8210158 to our test queue and let you know the > > > results. Please don't push until then. > > > > I've looked at the Jira but it's not clear why we need this in 11u. > > you mean why "JDK-8208601: Introduce native oop barriers in C2 for > OopHandle" is needed? It is a prerequisite for "JDK-8210158: Accessorize > JFR getEventWriter() intrinsics" which ought to resolve a potential JFR > crash. But if only the patch for 8210158 was used, it would not compile. I > think it would e.g. miss the definition of Node* access_load in > graphKit.hpp. > Indeed. Instead of manually tinkering around to make JDK-8210158 backport somehow working it is much better to take in JDK-8208601 and be sure that things are working as intended. Regards, -JB- > > Best regards > Christoph > > From stuart.marks at oracle.com Mon Sep 9 23:46:12 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 9 Sep 2019 16:46:12 -0700 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> Message-ID: <7dad708b-664c-121c-94b7-8eff1d5240a7@oracle.com> On 9/5/19 11:28 PM, Langer, Christoph wrote: >> Hi, thanks for testing. Any results yet? > > I'd say it looks great ?? No issues spotted... Great, thanks. >> Thanks also for reviewing the CSR. It's approved now. >> >> Regarding the metadata for the patch, my inclination is for me to be the author >> of the patch and to list Peter among the reviewers. Of course while Peter >> deserves the credit for finding the problem in the first place and for fixing it >> in JDK 13, this "backport" is significantly different from the original bugfix. >> More importantly, I think I should be listed as the author as an indication of >> responsibility for it. That is, if something were to go wrong with this patch, >> I'd be responsible for fixing it. Does that make sense? > > Sure, perfect. > >> I can push the change myself. Is this still ok to go into 11.0.5? > > I would like to see this change hit the same OpenJDK release as the Oracle release. For Oracle I can see a backport item for 11.0.6-oracle (JDK-8228350). Do you intend to promote it to 11.0.5 as well? OK, targeting both 11.0.6-openjdk and 11.0.6-oracle seems reasonable. As you noted, it looks like a backport is pending for 11.0.6-oracle. An email from Goetz L a couple weeks ago [1] says that changes pushed to [OpenJDK] jdk11u-dev will end up in 11.0.6. So it seems that I could just push this to jdk11u-dev, and then work internally to move ahead with the 11.0.6-oracle backport, and this will end up with the desired outcome. Is that right? Just making extra sure because I not too familiar with working on the OpenJDK update releases. Thanks. s'marks [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001789.html From thomas.stuefe at gmail.com Tue Sep 10 14:07:05 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 10 Sep 2019 16:07:05 +0200 Subject: [11u] RFR 8214975: No hs-err file if fatal error is raised during dynamic initialization Message-ID: Hi, I would like to bring this patch to 11u. Original Bug: https://bugs.openjdk.java.net/browse/JDK-8214975 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0de1f006d3c3 The patch fixes an rare but annoying issue which causes the VM to behave erratically if an assert or crash happens during dynamic C++ initialization. The patch is rather simple, exchanging the global-scope-C++ object wrapping the error log file handle - which needs dynamic C++ initialization - with simple int, which does not and does work always. The patch comes with a new test case. Unfortunately, the patch did not apply cleanly, since 11u is missing "8209856: Obsolete error reporter". But I found that one too big to bring to 11u. The adjustments are trivial anyway: http://cr.openjdk.java.net/~stuefe/webrevs/backports/8214975-No-hs-err-file-if-fatal-error-is-raised-during-dynamic-initialization-reject-fixes.patch Thank you, Thomas From gnu.andrew at redhat.com Tue Sep 10 16:56:31 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 10 Sep 2019 17:56:31 +0100 Subject: [11u] 11.0.6 changes can be pushed to jdk11u-dev In-Reply-To: References: Message-ID: <9e1b3b26-fece-c360-eac8-d0b933789d40@redhat.com> On 28/08/2019 11:20, Lindenmaier, Goetz wrote: > Hi, > > jdk11u-dev has been tagged with jdk-11.0.6+0. > Changes targeted to 11.0.6 can be pushed to jdk11u-dev now. > > jdk11u is dedicated for 11.0.5 rampdown. > Further changes for 11.0.5 must be requested with > jdk11u-critical-request tags, and they need to be pushed > directly to repository jdk11u. > > Thanks to ops that changed the hg updater timely! > > Best regards, > Goetz > You might want to update the wiki: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u It still suggests that 11u-dev is for 11.0.5 work & 11u is closed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue Sep 10 21:51:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 10 Sep 2019 21:51:48 +0000 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: <7dad708b-664c-121c-94b7-8eff1d5240a7@oracle.com> References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <0bb07139-762d-1f4a-690d-2ce25a20148e@oracle.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> <7dad708b-664c-121c-94b7-8eff1d5240a7@oracle.com> Message-ID: Hi Stuart, > >> I can push the change myself. Is this still ok to go into 11.0.5? > > > > I would like to see this change hit the same OpenJDK release as the Oracle > release. For Oracle I can see a backport item for 11.0.6-oracle (JDK-8228350). > Do you intend to promote it to 11.0.5 as well? > > OK, targeting both 11.0.6-openjdk and 11.0.6-oracle seems reasonable. As you > noted, it looks like a backport is pending for 11.0.6-oracle. An email from > Goetz L a couple weeks ago [1] says that changes pushed to [OpenJDK] jdk11u-dev > will end up in 11.0.6. So it seems that I could just push this to jdk11u-dev, > and then work internally to move ahead with the 11.0.6-oracle backport, and this > will end up with the desired outcome. > > Is that right? Yep, that's right. Just push it to jdk11u-dev now and it'll be in 11.0.6. Best regards Christoph From goetz.lindenmaier at sap.com Wed Sep 11 05:51:56 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 11 Sep 2019 05:51:56 +0000 Subject: [11u] 11.0.6 changes can be pushed to jdk11u-dev In-Reply-To: <9e1b3b26-fece-c360-eac8-d0b933789d40@redhat.com> References: <9e1b3b26-fece-c360-eac8-d0b933789d40@redhat.com> Message-ID: Done, thanks for the reminder! Best regards, Goetz. > -----Original Message----- > From: Andrew John Hughes > Sent: Tuesday, September 10, 2019 6:57 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] 11.0.6 changes can be pushed to jdk11u-dev > > > > On 28/08/2019 11:20, Lindenmaier, Goetz wrote: > > Hi, > > > > jdk11u-dev has been tagged with jdk-11.0.6+0. > > Changes targeted to 11.0.6 can be pushed to jdk11u-dev now. > > > > jdk11u is dedicated for 11.0.5 rampdown. > > Further changes for 11.0.5 must be requested with > > jdk11u-critical-request tags, and they need to be pushed > > directly to repository jdk11u. > > > > Thanks to ops that changed the hg updater timely! > > > > Best regards, > > Goetz > > > > You might want to update the wiki: > > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > > It still suggests that 11u-dev is for 11.0.5 work & 11u is closed. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From shade at redhat.com Wed Sep 11 09:04:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 11 Sep 2019 11:04:45 +0200 Subject: [11u] RFR 8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8216977 https://hg.openjdk.java.net/jdk/jdk/rev/8ec5ad4f5cc3 Patch does not apply cleanly to 11u, because one of the affected hunks was added in 13, with JDK-8220623. 11u webrev: https://cr.openjdk.java.net/~shade/8216977/webrev.11u.01/ There is also a follow-up testbug change, going to request that too. Testing: tier1, new test (fails without product fix, passes with it) -- Thanks, -Aleksey From stuart.marks at oracle.com Thu Sep 12 02:49:12 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 11 Sep 2019 19:49:12 -0700 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> <7dad708b-664c-121c-94b7-8eff1d5240a7@oracle.com> Message-ID: <59784cf8-3324-9d4c-b5a1-1b8aa953e6b6@oracle.com> On 9/10/19 2:51 PM, Langer, Christoph wrote: >> OK, targeting both 11.0.6-openjdk and 11.0.6-oracle seems reasonable. As you >> noted, it looks like a backport is pending for 11.0.6-oracle. An email from >> Goetz L a couple weeks ago [1] says that changes pushed to [OpenJDK] jdk11u-dev >> will end up in 11.0.6. So it seems that I could just push this to jdk11u-dev, >> and then work internally to move ahead with the 11.0.6-oracle backport, and this >> will end up with the desired outcome. >> >> Is that right? > > Yep, that's right. Just push it to jdk11u-dev now and it'll be in 11.0.6. OK, pushed. Thanks for your review and guidance on this. s'marks From mbalao at redhat.com Thu Sep 12 16:38:56 2019 From: mbalao at redhat.com (Martin Balao) Date: Thu, 12 Sep 2019 13:38:56 -0300 Subject: [RFR 11u] 8230923: SunJSSE is not properly initialized in FIPS mode from a configuration file Message-ID: <930829a4-0ba5-9b87-581a-130d02ce6c86@redhat.com> Hi, I'd like to propose a fix for 8230923 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8230923/8230923.webrev.00/ Can I have a review? Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8230923 From gnu.andrew at redhat.com Thu Sep 12 20:15:23 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Sep 2019 21:15:23 +0100 Subject: [RFR 11u] 8230923: SunJSSE is not properly initialized in FIPS mode from a configuration file In-Reply-To: <930829a4-0ba5-9b87-581a-130d02ce6c86@redhat.com> References: <930829a4-0ba5-9b87-581a-130d02ce6c86@redhat.com> Message-ID: <52e55764-4def-f46b-7dc1-785d8cc3edcf@redhat.com> On 12/09/2019 17:38, Martin Balao wrote: > Hi, > > I'd like to propose a fix for 8230923 [1]. > > Webrev.00: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8230923/8230923.webrev.00/ > > Can I have a review? > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8230923 > This appears to be a regression caused by: https://bugs.openjdk.java.net/browse/JDK-7191662 https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2f69eb7d4b90 Given that the relevant erased section there is: - if (hasArgument() == false) { - obj = provClass.newInstance(); - } else { - Constructor cons = provClass.getConstructor(CL_STRING); - obj = cons.newInstance(argument); - } your fix seems right to me and I can confirm the test fails on current jdk11 and passes with this patch. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Fri Sep 13 13:02:40 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 13 Sep 2019 13:02:40 +0000 Subject: [11u] RFR 8222154: upgrade gtest to 1.8.1 Message-ID: Hi, please review the backport of the gtest upgrade to 1.8.1 to JDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8222154 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222154.11u-dev.0/ The patch applied, apart from a little manual intervention in in make/hotspot/lib/CompileGtest.gmk where I had to find the correct place to remove the DISABLED_WARNINGS_microsoft setting. Unfortunately, on Solaris the Sun Studio SS12U4 compiler didn't completely like the patch. I had to do the following things: 1. add the +d option (disable inlining) for Solaris in make/hotspot/lib/CompileGtest.gmk, line 75, to get rid of an assertion: (../lnk/vardescr.h, line 109) 2. In test/fmw/gtest/include/gtest/internal/gtest-internal.h, the new struct CodeLocation uses a member 'file' of type std::string. SunStudio12u4 does not like it and the workaround is to convert it to const char* const. With that little tweak and removal of a few .c_str() calls, e.g. in test/fmw/gtest/include/gtest/gtest.h and test/fmw/gtest/src/gtest.cc, the thing compiles on Solaris (and also on the other platforms). We didn't spot regressions with the new gtests version, so it should be fine to pull it to 11u. Thanks Christoph From felix.yang at huawei.com Sun Sep 15 01:19:35 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sun, 15 Sep 2019 01:19:35 +0000 Subject: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> Message-ID: Hi, Thanks for the help. I was not able to push this due to bad network status. Could someone help push this please? The patch still applies to jdk11u-dev and passes tier1 test on aarch64 linux platform. Felix > Hi Felix, > > approved, label added. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Yangfei (Felix) > > Sent: Montag, 9. September 2019 07:55 > > To: Andrew Haley ; jdk-updates-dev at openjdk.java.net > > Subject: RE: RFR: [11u] 8209835: Aarch64: elide barriers on all > > volatile operations > > > > > On 8/23/19 7:06 AM, Yangfei (Felix) wrote: > > > > Could I have a review for this backport to jdk11u-dev please? > > > > > > > > > > > > > > > > Webrev: > > > > http://cr.openjdk.java.net/~fyang/8209835-11u-backport/webrev.00/ > > > > > > OK, now that we've branched for the next release, this is a good time. > > > > > > > Thanks for reviewing this. Could you please add a jdk11u-fix-yes > > label for > > 8209835 so I can do the push? > > > > Felix From christoph.langer at sap.com Sun Sep 15 05:55:32 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 15 Sep 2019 05:55:32 +0000 Subject: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> Message-ID: Hi Felix, done: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2dbf6950d6bb Best regards Christoph > -----Original Message----- > From: Yangfei (Felix) > Sent: Sonntag, 15. September 2019 03:20 > To: Langer, Christoph ; Andrew Haley > ; jdk-updates-dev at openjdk.java.net > Subject: RE: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile > operations > > Hi, > > Thanks for the help. I was not able to push this due to bad network status. > Could someone help push this please? The patch still applies to jdk11u-dev > and passes tier1 test on aarch64 linux platform. > > Felix > > > > Hi Felix, > > > > approved, label added. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev > On > > > Behalf Of Yangfei (Felix) > > > Sent: Montag, 9. September 2019 07:55 > > > To: Andrew Haley ; jdk-updates- > dev at openjdk.java.net > > > Subject: RE: RFR: [11u] 8209835: Aarch64: elide barriers on all > > > volatile operations > > > > > > > On 8/23/19 7:06 AM, Yangfei (Felix) wrote: > > > > > Could I have a review for this backport to jdk11u-dev please? > > > > > > > > > > > > > > > > > > > > Webrev: > > > > > http://cr.openjdk.java.net/~fyang/8209835-11u- > backport/webrev.00/ > > > > > > > > OK, now that we've branched for the next release, this is a good time. > > > > > > > > > > Thanks for reviewing this. Could you please add a jdk11u-fix-yes > > > label for > > > 8209835 so I can do the push? > > > > > > Felix From felix.yang at huawei.com Mon Sep 16 01:18:28 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 16 Sep 2019 01:18:28 +0000 Subject: RFR: [11u] 8209835: Aarch64: elide barriers on all volatile operations In-Reply-To: References: <5cb3317f-d5cf-47dc-0ab6-150d6d674f9a@redhat.com> Message-ID: Hi Christoph, Thanks for the help. Felix > > Hi Felix, > > done: http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2dbf6950d6bb > > Best regards > Christoph > From christoph.langer at sap.com Mon Sep 16 08:10:38 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Sep 2019 08:10:38 +0000 Subject: [11u] RFR 8214975: No hs-err file if fatal error is raised during dynamic initialization In-Reply-To: References: Message-ID: Hi Thomas, the patch looks good. I've added it to our test queue (again). Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Dienstag, 10. September 2019 16:07 > To: jdk-updates-dev at openjdk.java.net > Cc: Hotspot dev runtime > Subject: [11u] RFR 8214975: No hs-err file if fatal error is raised during > dynamic initialization > > Hi, > > I would like to bring this patch to 11u. > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8214975 > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0de1f006d3c3 > > The patch fixes an rare but annoying issue which causes the VM to behave > erratically if an assert or crash happens during dynamic C++ initialization. > > The patch is rather simple, exchanging the global-scope-C++ object wrapping > the error log file handle - which needs dynamic C++ initialization - with > simple int, which does not and does work always. The patch comes with a > new > test case. > > Unfortunately, the patch did not apply cleanly, since 11u is missing > "8209856: Obsolete error reporter". But I found that one too big to bring > to 11u. The adjustments are trivial anyway: > > http://cr.openjdk.java.net/~stuefe/webrevs/backports/8214975-No-hs-err- > file-if-fatal-error-is-raised-during-dynamic-initialization-reject-fixes.patch > > Thank you, > > Thomas From christoph.langer at sap.com Mon Sep 16 08:14:32 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Sep 2019 08:14:32 +0000 Subject: [11u] RFR 8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken In-Reply-To: References: Message-ID: Hi Aleksey, backport looks good to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Mittwoch, 11. September 2019 11:05 > To: jdk-updates-dev at openjdk.java.net > Cc: Coleen Phillimore > Subject: [11u] RFR 8216977: ShowHiddenFrames use in > java_lang_StackTraceElement::fill_in appears broken > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8216977 > https://hg.openjdk.java.net/jdk/jdk/rev/8ec5ad4f5cc3 > > Patch does not apply cleanly to 11u, because one of the affected hunks was > added in 13, with > JDK-8220623. 11u webrev: > https://cr.openjdk.java.net/~shade/8216977/webrev.11u.01/ > > There is also a follow-up testbug change, going to request that too. > > Testing: tier1, new test (fails without product fix, passes with it) > > -- > Thanks, > -Aleksey From shade at redhat.com Mon Sep 16 08:42:19 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 10:42:19 +0200 Subject: [11u] RFR 8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken In-Reply-To: References: Message-ID: <7db09f66-784a-1be8-31a3-cd1e6ef22e7c@redhat.com> On 9/16/19 10:14 AM, Langer, Christoph wrote: > backport looks good to me. Thanks, I am going to push it shortly. -- -Aleksey From shade at redhat.com Mon Sep 16 08:48:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 10:48:36 +0200 Subject: [11u] RFR 8222154: upgrade gtest to 1.8.1 In-Reply-To: References: Message-ID: On 9/13/19 3:02 PM, Langer, Christoph wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8222154 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222154.11u-dev.0/ It is hard to review, but if there are no gtest regressions on all platforms, this is good to go. -- Thanks, -Aleksey From christoph.langer at sap.com Mon Sep 16 08:50:52 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Sep 2019 08:50:52 +0000 Subject: [11u] RFR 8222154: upgrade gtest to 1.8.1 In-Reply-To: References: Message-ID: Thanks, Aleksey. It looks very green on all platforms. > -----Original Message----- > From: Aleksey Shipilev > Sent: Montag, 16. September 2019 10:49 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR 8222154: upgrade gtest to 1.8.1 > > On 9/13/19 3:02 PM, Langer, Christoph wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222154 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8222154.11u- > dev.0/ > > It is hard to review, but if there are no gtest regressions on all platforms, this > is good to go. > > -- > Thanks, > -Aleksey From shade at redhat.com Mon Sep 16 10:28:22 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 12:28:22 +0200 Subject: Heads-up: JDK-8230085 and MacOS Catalina Message-ID: Hi there, Any lucky folks on this list who have MacOS and also upgraded it to Catalina? This had recently popped in: 8230085(fs) FileStore::isReadOnly is always true on macOS Catalina https://bugs.openjdk.java.net/browse/JDK-8230085 Since it has tck-red-{7u241,8u231,11.0.5}, I am pretty sure it would end up on critical list for 8u and 11u. Anyone with MacOS is willing to take on this one? -- Thanks, -Aleksey From christoph.langer at sap.com Mon Sep 16 14:04:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 16 Sep 2019 14:04:53 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: Message-ID: Hi Aleksey, does tck-red mean, there are issues with current TCK? In other words, it can't just simply be backported before TCK has been adapted? Thanks Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Aleksey Shipilev > Sent: Montag, 16. September 2019 12:28 > To: jdk-updates-dev at openjdk.java.net > Subject: Heads-up: JDK-8230085 and MacOS Catalina > > Hi there, > > Any lucky folks on this list who have MacOS and also upgraded it to Catalina? > > This had recently popped in: > 8230085(fs) FileStore::isReadOnly is always true on macOS Catalina > https://bugs.openjdk.java.net/browse/JDK-8230085 > > Since it has tck-red-{7u241,8u231,11.0.5}, I am pretty sure it would end up on > critical list for 8u > and 11u. Anyone with MacOS is willing to take on this one? > > -- > Thanks, > -Aleksey From shade at redhat.com Mon Sep 16 14:08:11 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 16 Sep 2019 16:08:11 +0200 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: Message-ID: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> On 9/16/19 4:04 PM, Langer, Christoph wrote: > does tck-red mean, there are issues with current TCK? In other words, it can't just simply be > backported before TCK has been adapted? https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary says: "tck-red-(Rel): Used to identify TCK conformance stoppers (e.g. failure of a valid TCK test that exists in a shipped TCK)." From this and issue description it sounds like it is legit TCK failure on Catalina. -- Thanks, -Aleksey From rob.mckenna at oracle.com Mon Sep 16 14:29:29 2019 From: rob.mckenna at oracle.com (Rob McKenna) Date: Mon, 16 Sep 2019 15:29:29 +0100 Subject: [12u-communication] End of maintenance & invitation for new maintainers Message-ID: <20190916142929.GB19566@vimes> I'm sending this mail to notify the community that the current maintainers intend to step down as maintainers for the JDK 12 Updates forest [1] at the end of September. This being the case we would like to invite prospective new maintainers to step forward at this point to ensure a smooth transition should they wish to maintain this forest beyond the end of September. -Rob [1] http://hg.openjdk.java.net/jdk-updates/jdk12u From jkang at redhat.com Mon Sep 16 20:26:28 2019 From: jkang at redhat.com (Jie Kang) Date: Mon, 16 Sep 2019 16:26:28 -0400 Subject: [11u] RFR JDK-8217362: Emergency dump does not work when disk=false is set In-Reply-To: References: Message-ID: On Mon, Sep 2, 2019 at 10:08 AM Langer, Christoph wrote: > > Hi Jie, > > thanks for putting effort in backporting this bug. > > First of all, a general remark: When you bring an upstream patch to backport, can you please use the workflow to export the patch from the upstream repo (e.g. hg export -r --git > .patch) and then import it to the backport target repository (e.g. jdk11u-dev via hg qimport && hg qpush). More details can be taken out of https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix. This would make sure, the patch metadata, such as original author, description and reviewed-by comments remain intact. These are currently missing when I import the patch from your webrev. > > Furthermore, I agree, it would be beneficial to backport 8218935 before you do this item. So, can you request/process this before continuing with JDK-8217362? Hello Christoph, I have updated the webrev to include the original metadata from jdk/jdk as well as work on top the latest in jdk-updates/jdk11u-dev which now has the backport of 8218935. I tested with the reproducer, tier one tests and jfr tests. Webrev: https://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.03/ Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 Bug: https://bugs.openjdk.java.net/browse/JDK-8217362 How does it look? > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Jie Kang > > Sent: Freitag, 30. August 2019 22:33 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [11u] RFR JDK-8217362: Emergency dump does not work when > > disk=false is set > > > > Hi all, > > > > Please review this backport of 8217362 to OpenJDK jdk11u-dev. The fix > > did not apply cleanly and I have described my alterations below. This > > fix has been applied on top of my backport request of 8213448 [1], > > which I hope will be accepted. I have run the tier one tests as well > > as the reproducer described in the bug report. It does not produce a > > jfr without the patch and does with the patch applied. Let me know > > what you think! > > > > Webrev: http://cr.openjdk.java.net/~jkang/jdk-8217362/webrev.01/ > > Original Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217362 > > > > Alterations: > > > > 1. test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java.rej > > [jdk/jdk hg rev] : [openjdk bug] > > d7fc38d3fc8d : 8209856: Obsolete error reporter > > > > A one line difference caused rejects; I manually applied the changes. > > > > 2. src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp.rej > > 65deccd64f3a : 8218935: Make jfr strncpy uses GCC 8.x friendly > > > > Small differences caused rejects; I manually applied the changes. > > Maybe it would be good to also backport 8218935? If maintainer's have > > a stronger opinion I would appreciate it. > > > > 3. src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp.rej > > 5d20b085d893 : 8203469: Faster safepoints > > 881c5fbeb849 : 8218041: Assorted wrong/missing includes > > 625a5bdde0c5 : 8210155: Lock ClassLoaderDataGraph > > > > Generally small changes missing; I manually applied the changes in this patch. > > > > [1] > > http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019- > > August/001790.html > > https://bugs.openjdk.java.net/browse/JDK-8213448 > > > > > > Regards, From denghui.ddh at alibaba-inc.com Tue Sep 17 02:43:15 2019 From: denghui.ddh at alibaba-inc.com (DDH) Date: Tue, 17 Sep 2019 10:43:15 +0800 Subject: =?UTF-8?B?Rml4IHJlcXVlc3QgSkRLLTgyMjgzNTk=?= Message-ID: <8d12d70a-4929-4f8c-90c1-4c604ee72d51.denghui.ddh@alibaba-inc.com> Hi all, I plan to backports some jfr-related patches from 13,14 to 11u, and then 8u. This is my first time to contribute a fix, I choose JDK-8228359 (https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first backport fix. This patch applies cleanly to 11u, and I need to put jdk11u-fix-request label on the issue(https://bugs.openjdk.java.net/browse/JDK-8228359), but I don't have JBS user count, can you help me ? Thanks, DDH From ioi.lam at oracle.com Tue Sep 17 06:24:55 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 16 Sep 2019 23:24:55 -0700 Subject: Fix request JDK-8228359 In-Reply-To: <8d12d70a-4929-4f8c-90c1-4c604ee72d51.denghui.ddh@alibaba-inc.com> References: <8d12d70a-4929-4f8c-90c1-4c604ee72d51.denghui.ddh@alibaba-inc.com> Message-ID: Please include the bug summary (title) in the e-mail message. Otherwise it's hard to keep track of what's happening in different e-mails. Thanks And please include your full name. - Ioi On 9/16/19 7:43 PM, DDH wrote: > Hi all, > I plan to backports some jfr-related patches from 13,14 to 11u, and then 8u. This is my first time to contribute a fix, I choose JDK-8228359 (https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first backport fix. > This patch applies cleanly to 11u, and I need to put jdk11u-fix-request label on the issue(https://bugs.openjdk.java.net/browse/JDK-8228359), > but I don't have JBS user count, can you help me ? > > Thanks, > DDH From christoph.langer at sap.com Tue Sep 17 09:32:48 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Sep 2019 09:32:48 +0000 Subject: [11u] RE: Fix request JDK-8228359 Message-ID: Hi DDH, as Ioi already wrote, it would be appreciated if you could also mention the bug title somewhere and also annotate the mail subject with [11u] as I did in my reply. Then people that are monitoring jdk-updates-dev but are not interested in jdk11u know that they can probably ignore it. I see that you have already found somebody who could place the "fix request" labels and comment. As it is a trivial test bug, I approved it. Do you have a sponsor to push the fix to jdk11u-dev for you or shall I do it? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of DDH > Sent: Dienstag, 17. September 2019 04:43 > To: jdk-updates-dev at openjdk.java.net > Subject: Fix request JDK-8228359 > > Hi all, > I plan to backports some jfr-related patches from 13,14 to 11u, and then 8u. > This is my first time to contribute a fix, I choose JDK-8228359 > (https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first > backport fix. > This patch applies cleanly to 11u, and I need to put jdk11u-fix-request label > on the issue(https://bugs.openjdk.java.net/browse/JDK-8228359), > but I don't have JBS user count, can you help me ? > > Thanks, > DDH From denghui.ddh at alibaba-inc.com Tue Sep 17 09:40:37 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 17 Sep 2019 17:40:37 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFJFOiBGaXggcmVxdWVzdCBKREstODIyODM1OQ==?= In-Reply-To: References: Message-ID: Hi Christoph, Thank you for your reply, my colleague help me to put the label, but we don't have jdk11u-dev committer, so can you help me to push the fix ? At the same time, thank you for your advice, I'll be careful next time. Thanks Denghui ------------------------------------------------------------------ From:Langer, Christoph Send Time:2019?9?17?(???) 17:34 To:???(??) Cc:jdk-updates-dev at openjdk.java.net Subject:[11u] RE: Fix request JDK-8228359 Hi DDH, as Ioi already wrote, it would be appreciated if you could also mention the bug title somewhere and also annotate the mail subject with [11u] as I did in my reply. Then people that are monitoring jdk-updates-dev but are not interested in jdk11u know that they can probably ignore it. I see that you have already found somebody who could place the "fix request" labels and comment. As it is a trivial test bug, I approved it. Do you have a sponsor to push the fix to jdk11u-dev for you or shall I do it? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of DDH > Sent: Dienstag, 17. September 2019 04:43 > To: jdk-updates-dev at openjdk.java.net > Subject: Fix request JDK-8228359 > > Hi all, > I plan to backports some jfr-related patches from 13,14 to 11u, and then 8u. > This is my first time to contribute a fix, I choose JDK-8228359 > (https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first > backport fix. > This patch applies cleanly to 11u, and I need to put jdk11u-fix-request label > on the issue(https://bugs.openjdk.java.net/browse/JDK-8228359), > but I don't have JBS user count, can you help me ? > > Thanks, > DDH From christoph.langer at sap.com Tue Sep 17 09:43:13 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Sep 2019 09:43:13 +0000 Subject: [11u] RE: Fix request JDK-8228359 In-Reply-To: References: Message-ID: Hi Denghui, thanks for your reply. I?ll run the patch through our test system and once we see no issues I?ll push it tomorrow. Best Christoph From: Denghui Dong Sent: Dienstag, 17. September 2019 11:41 To: Langer, Christoph Cc: jdk-updates-dev at openjdk.java.net Subject: Re: [11u] RE: Fix request JDK-8228359 Hi Christoph, Thank you for your reply, my colleague help me to put the label, but we don't have jdk11u-dev committer, so can you help me to push the fix ? At the same time, thank you for your advice, I'll be careful next time. Thanks Denghui ------------------------------------------------------------------ From:Langer, Christoph > Send Time:2019?9?17?(???) 17:34 To:???(??) > Cc:jdk-updates-dev at openjdk.java.net > Subject:[11u] RE: Fix request JDK-8228359 Hi DDH, as Ioi already wrote, it would be appreciated if you could also mention the bug title somewhere and also annotate the mail subject with [11u] as I did in my reply. Then people that are monitoring jdk-updates-dev but are not interested in jdk11u know that they can probably ignore it. I see that you have already found somebody who could place the "fix request" labels and comment. As it is a trivial test bug, I approved it. Do you have a sponsor to push the fix to jdk11u-dev for you or shall I do it? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev > On > Behalf Of DDH > Sent: Dienstag, 17. September 2019 04:43 > To: jdk-updates-dev at openjdk.java.net > Subject: Fix request JDK-8228359 > > Hi all, > I plan to backports some jfr-related patches from 13,14 to 11u, and then 8u. > This is my first time to contribute a fix, I choose JDK-8228359 > (https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first > backport fix. > This patch applies cleanly to 11u, and I need to put jdk11u-fix-request label > on the issue(https://bugs.openjdk.java.net/browse/JDK-8228359), > but I don't have JBS user count, can you help me ? > > Thanks, > DDH From stooke at redhat.com Tue Sep 17 14:11:17 2019 From: stooke at redhat.com (Simon Tooke) Date: Tue, 17 Sep 2019 10:11:17 -0400 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: Message-ID: <43765954-3ac9-2c2f-6713-796458a9a3c8@redhat.com> On 9/16/2019 6:28 AM, Aleksey Shipilev wrote: > Hi there, > > Any lucky folks on this list who have MacOS and also upgraded it to Catalina? > > This had recently popped in: > 8230085(fs) FileStore::isReadOnly is always true on macOS Catalina > https://bugs.openjdk.java.net/browse/JDK-8230085 > > Since it has tck-red-{7u241,8u231,11.0.5}, I am pretty sure it would end up on critical list for 8u > and 11u. Anyone with MacOS is willing to take on this one? 11u: I can confirm that the patch installs cleanly and does its job, on a recent Catalina beta. I'm running it through tier1 and also will confirm it doesn't break older macOS. jdk8u: I haven't looked at.? the patch is small, it should be quick. From stooke at redhat.com Tue Sep 17 19:13:19 2019 From: stooke at redhat.com (Simon Tooke) Date: Tue, 17 Sep 2019 15:13:19 -0400 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> Message-ID: On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: > On 9/16/19 4:04 PM, Langer, Christoph wrote: >> does tck-red mean, there are issues with current TCK? In other words, it can't just simply be >> backported before TCK has been adapted? > https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary says: "tck-red-(Rel): Used to > identify TCK conformance stoppers (e.g. failure of a valid TCK test that exists in a shipped TCK)." > > From this and issue description it sounds like it is legit TCK failure on Catalina. I've now tested the fix on jdk8u and 11u on a Catalina beta, with success. I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if they are critical (not my call) then the labels should be changed accordingly. -Simon From gnu.andrew at redhat.com Tue Sep 17 20:05:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 21:05:06 +0100 Subject: Result: New OpenJDK Updates Committer: Martin Balao Message-ID: Voting for Martin Balao [0] is now closed. Yes: 11 Veto: 0 Abstain: 0 Turnout: 3.7% (11/300) According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001466.html [1] https://openjdk.java.net/bylaws#lazy-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 17 20:12:57 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 21:12:57 +0100 Subject: Results: New OpenJDK Updates Reviewer: Mario Torre Message-ID: <04095e36-a2b8-2ec6-4b28-90fcf80bc0b2@redhat.com> Voting for Mario Torre [0] is now closed. Yes: 9 Veto: 0 Abstain: 0 Invalid: 1 Turnout: 6.2% (9/145) According to the Bylaws definition of Three-Vote Consensus [1], this is sufficient to approve the nomination. [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001470.html [1] http://openjdk.java.net/bylaws#three-vote-consensus -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 17 20:54:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 21:54:36 +0100 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> Message-ID: On 17/09/2019 20:13, Simon Tooke wrote: > > On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: >> On 9/16/19 4:04 PM, Langer, Christoph wrote: >>> does tck-red mean, there are issues with current TCK? In other words, it can't just simply be >>> backported before TCK has been adapted? >> https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary says: "tck-red-(Rel): Used to >> identify TCK conformance stoppers (e.g. failure of a valid TCK test that exists in a shipped TCK)." >> >> From this and issue description it sounds like it is legit TCK failure on Catalina. > > I've now tested the fix on jdk8u and 11u on a Catalina beta, with success. > > I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if > they are critical (not my call) then the labels should be changed > accordingly. > > -Simon > If you want to request critical, you need to use the *-critical-request labels and make the case for it on the bug. In the event the issue is rejected for critical, you can always then apply for *-fix-request instead. Hope that helps, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Sep 17 20:59:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Sep 2019 21:59:13 +0100 Subject: CFV: New OpenJDK Updates Reviewer: Mario Torre In-Reply-To: References: <5e16d5d7-edda-7c44-ee71-45908852f56d@redhat.com> Message-ID: <25924b96-5e89-dca2-d15c-e30fa854e961@redhat.com> On 24/07/2019 14:06, Laurent Bourg?s wrote: > Vote: yes > > Le mar. 23 juil. 2019 ? 22:01, Andrew John Hughes a > ?crit : > >> I hereby nominate Mario Torre [0] for the role of OpenJDK 8u Reviewer. >> >> Mario already has reviewership in OpenJDK 7u & 8u, so it seems odd not >> to have him doing similar work for 11u. He does also have a sizeable >> number of OpenJDK commits, particularly in the AWT and graphics area [1]. >> >> Votes are due by 20h00 UTC on the 6th of August, 2019. >> >> Only current OpenJDK Updates Reviewers [2] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this mailing >> list. >> >> For Three-Vote Consensus voting instructions, see [3]. >> >> [0] https://openjdk.java.net/census#neugens >> [1] >> >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(neugens)+or+desc(%22neugens%40redhat.com%22))+and+not+merge() >> [2] https://openjdk.java.net/census#jdk-updates >> [3] https://openjdk.java.net/bylaws#three-vote-consensus >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> >> > I'm afraid this is a Reviewer vote, so voters are required to be 8u reviewers themselves. Hence I have to declare this vote invalid. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Wed Sep 18 09:45:21 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Sep 2019 09:45:21 +0000 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support Message-ID: Hi, please review this backport to JDK11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data to tzdata2019b, which is required for 11.0.5. This will make the JDK's timezone parser support the "vanguard" format and enables a simple backport of JDK-8228469. To make the patch applicable to jdk11u, I had to manually do all the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk. Furthermore there were some rejects which were easy to resolve in: make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> Copyright year make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> Copyright year and import statements src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java -> Copyright year With the patch applied all regression testing shows still green (both, jtreg and TCK). Thanks Christoph From christoph.langer at sap.com Wed Sep 18 10:01:45 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Sep 2019 10:01:45 +0000 Subject: [11u] RFR 8229773: Resolve permissions for code source URLs lazily Message-ID: Hi, please review the backport for JDK-8229773: Resolve permissions for code source URLs lazily to OpenJDK11 updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/1b6806340400 The patch did not apply cleanly and I had to resolve src/java.base/share/classes/java/lang/System.java: imports and the hunk about "// ensure the default file system is initialized" src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java: import statements With these modifications, the patch applies and regression testing does not show findings. Thanks Christoph From christoph.langer at sap.com Wed Sep 18 13:03:58 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 18 Sep 2019 13:03:58 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> Message-ID: Hi Simon, > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Simon Tooke > Sent: Dienstag, 17. September 2019 21:13 > To: jdk-updates-dev at openjdk.java.net; Aleksey Shipilev > > Subject: Re: Heads-up: JDK-8230085 and MacOS Catalina > > > On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: > > On 9/16/19 4:04 PM, Langer, Christoph wrote: > >> does tck-red mean, there are issues with current TCK? In other words, it > can't just simply be > >> backported before TCK has been adapted? > > https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary says: > "tck-red-(Rel): Used to > > identify TCK conformance stoppers (e.g. failure of a valid TCK test that > exists in a shipped TCK)." > > > > From this and issue description it sounds like it is legit TCK failure on > Catalina. > > I've now tested the fix on jdk8u and 11u on a Catalina beta, with success. > > I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if > they are critical (not my call) then the labels should be changed > accordingly. Thanks for doing this work. I'll approve it for jdk11u-dev, add the patch to our test queue and will submit it tomorrow once we don't see a regression (which I'm quite sure of). As for jdk11u-critical (11.0.5), I would currently not request this. I don't see this patch backported to any other October update release so far. In case Oracle decides to do so or other reasons come up why it should be part of 11.0.5, we could still promote it to jdk11u in the next days. Best regards Christoph From stooke at redhat.com Wed Sep 18 17:11:17 2019 From: stooke at redhat.com (Simon Tooke) Date: Wed, 18 Sep 2019 13:11:17 -0400 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> Message-ID: <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> On 9/17/2019 4:54 PM, Andrew John Hughes wrote: > > On 17/09/2019 20:13, Simon Tooke wrote: >> On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: >>> On 9/16/19 4:04 PM, Langer, Christoph wrote: >>>> does tck-red mean, there are issues with current TCK? In other words, it can't just simply be >>>> backported before TCK has been adapted? >>> https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary says: "tck-red-(Rel): Used to >>> identify TCK conformance stoppers (e.g. failure of a valid TCK test that exists in a shipped TCK)." >>> >>> From this and issue description it sounds like it is legit TCK failure on Catalina. >> I've now tested the fix on jdk8u and 11u on a Catalina beta, with success. >> >> I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if >> they are critical (not my call) then the labels should be changed >> accordingly. >> >> -Simon >> > If you want to request critical, you need to use the *-critical-request > labels and make the case for it on the bug. In the event the issue is > rejected for critical, you can always then apply for *-fix-request instead. > > Hope that helps, Sure, I'll do that.? I noticed that Christoph has already decided it's not critical for 11u, though, so I won't be surprised if it gets rejected. Thanks, -simon From claes.redestad at oracle.com Wed Sep 18 17:16:23 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 18 Sep 2019 19:16:23 +0200 Subject: [11u] RFR 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: Looks ok to me! /Claes On 2019-09-18 12:01, Langer, Christoph wrote: > Hi, > > please review the backport for JDK-8229773: Resolve permissions for code source URLs lazily to OpenJDK11 updates. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u-dev.0/ > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/1b6806340400 > > The patch did not apply cleanly and I had to resolve > src/java.base/share/classes/java/lang/System.java: imports and the hunk about "// ensure the default file system is initialized" > src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java: import statements > > With these modifications, the patch applies and regression testing does not show findings. > > Thanks > Christoph > From hohensee at amazon.com Wed Sep 18 17:56:28 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 18 Sep 2019 17:56:28 +0000 Subject: RFA Backport CSR to 11u: 8231194: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Message-ID: <4A7D9E4F-0D48-4C31-B092-55E03A45E0D1@amazon.com> Please review/approve an 11u CSR backport request. https://bugs.openjdk.java.net/browse/JDK-8231194 Original issue: https://bugs.openjdk.java.net/browse/JDK-8207266 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8230311 11u backport issue: https://bugs.openjdk.java.net/browse/JDK-8231193 Email threads: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-August/029011.html https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029033.html Thanks, Paul From hohensee at amazon.com Thu Sep 19 00:38:26 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 19 Sep 2019 00:38:26 +0000 Subject: RFA Backport CSR to 11u: 8231194: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread In-Reply-To: <4A7D9E4F-0D48-4C31-B092-55E03A45E0D1@amazon.com> References: <4A7D9E4F-0D48-4C31-B092-55E03A45E0D1@amazon.com> Message-ID: <64BC7D9E-E79D-43B1-98F0-BE75B84EF7A9@amazon.com> Please belay this, there?s a problem with the original patch. Thanks, From: "Hohensee, Paul" Date: Wednesday, September 18, 2019 at 10:56 AM To: OpenJDK Serviceability Cc: "jdk-updates-dev at openjdk.java.net" Subject: RFA Backport CSR to 11u: 8231194: ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread Please review/approve an 11u CSR backport request. https://bugs.openjdk.java.net/browse/JDK-8231194 Original issue: https://bugs.openjdk.java.net/browse/JDK-8207266 Original CSR: https://bugs.openjdk.java.net/browse/JDK-8230311 11u backport issue: https://bugs.openjdk.java.net/browse/JDK-8231193 Email threads: https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-August/029011.html https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029033.html Thanks, Paul From jaroslav.bachorik at datadoghq.com Thu Sep 19 09:17:39 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 19 Sep 2019 11:17:39 +0200 Subject: [11u] Intended JFR related backports Message-ID: Hi all, this is a heads-up for the intended JFR related backports. The main issue is JDK-8225797: OldObjectSample event creates unexpected amount of checkpoint data However, due to major differences between the dev and 11u also the following ports are required (in the order they are to be applied): - JDK-8209850: Allow NamedThreads to use GlobalCounter critical sections (clean apply) - JDK-8209976: Improve iteration over non-JavaThreads (1-line change to resolve conflicts) - JDK-8210024: JFR calls virtual is_Java_thread from ~Thread() (1-line change to resolve conflicts) - JDK-8214850: Rename vm_operations.?pp files to vmOperations.?pp files (simple change to resolve conflicts) - JDK-8209802: Garbage collectors should register JFR types themselves to avoid build errors (slightly more involved changes to resolve conflicts) At the moment I am waiting for the resolution of JDK-8231081 and will post RFRs only once that issue is resolved and I can include it in the backport set. Cheers, -JB- From christoph.langer at sap.com Thu Sep 19 09:19:20 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Sep 2019 09:19:20 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> Message-ID: Hi, I can see that Oracle has backported the change to their January update branches just last night. I'll ask if they have any plans to ship this already with the October patches. Independent of that, I think we can decide for the OpenJDK releases to have it already in October. What do people think? (Looping in aph...) Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Simon Tooke > Sent: Mittwoch, 18. September 2019 19:11 > To: Andrew John Hughes ; jdk-updates- > dev at openjdk.java.net; Aleksey Shipilev > Subject: Re: Heads-up: JDK-8230085 and MacOS Catalina > > > On 9/17/2019 4:54 PM, Andrew John Hughes wrote: > > > > On 17/09/2019 20:13, Simon Tooke wrote: > >> On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: > >>> On 9/16/19 4:04 PM, Langer, Christoph wrote: > >>>> does tck-red mean, there are issues with current TCK? In other words, > it can't just simply be > >>>> backported before TCK has been adapted? > >>> https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary > says: "tck-red-(Rel): Used to > >>> identify TCK conformance stoppers (e.g. failure of a valid TCK test that > exists in a shipped TCK)." > >>> > >>> From this and issue description it sounds like it is legit TCK failure on > Catalina. > >> I've now tested the fix on jdk8u and 11u on a Catalina beta, with success. > >> > >> I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if > >> they are critical (not my call) then the labels should be changed > >> accordingly. > >> > >> -Simon > >> > > If you want to request critical, you need to use the *-critical-request > > labels and make the case for it on the bug. In the event the issue is > > rejected for critical, you can always then apply for *-fix-request instead. > > > > Hope that helps, > > Sure, I'll do that.? I noticed that Christoph has already decided it's > not critical for 11u, though, so I won't be surprised if it gets rejected. > > Thanks, > > -simon > From christoph.langer at sap.com Thu Sep 19 10:37:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Sep 2019 10:37:29 +0000 Subject: [11u] RFR 8229773: Resolve permissions for code source URLs lazily In-Reply-To: References: Message-ID: Thanks for the review, Claes. > -----Original Message----- > From: Claes Redestad > Sent: Mittwoch, 18. September 2019 19:16 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: core-libs-dev > Subject: Re: [11u] RFR 8229773: Resolve permissions for code source URLs > lazily > > Looks ok to me! > > /Claes > > On 2019-09-18 12:01, Langer, Christoph wrote: > > Hi, > > > > please review the backport for JDK-8229773: Resolve permissions for code > source URLs lazily to OpenJDK11 updates. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229773 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8229773.11u- > dev.0/ > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/1b6806340400 > > > > The patch did not apply cleanly and I had to resolve > > src/java.base/share/classes/java/lang/System.java: imports and the hunk > about "// ensure the default file system is initialized" > > src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java: > import statements > > > > With these modifications, the patch applies and regression testing does not > show findings. > > > > Thanks > > Christoph > > From goetz.lindenmaier at sap.com Thu Sep 19 12:23:14 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Sep 2019 12:23:14 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> Message-ID: Hi, the change touches only mac files, except for removal of a 'private' from a method. So it should not break any other platform. Catalina is to be released in October: https://www.apple.com/macos/catalina/ If we deliver the fix only in January, people have to deal with the issue until then. Thus I would not object against pushing this to 11.0.5. The only thing I'm not aware of is the importance of this fix. Does isReadOnly() being true imply that you can not write to any file any more? This would make 11.0.5 unusable on Catalina. Or is this just an interface rarely used? Best regards, Goetz > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Donnerstag, 19. September 2019 11:19 > To: Simon Tooke ; Andrew John Hughes > ; jdk-updates-dev at openjdk.java.net; Aleksey > Shipilev ; Andrew Haley > Subject: [CAUTION] RE: Heads-up: JDK-8230085 and MacOS Catalina > > Hi, > > I can see that Oracle has backported the change to their January update > branches just last night. I'll ask if they have any plans to ship this already with > the October patches. > > Independent of that, I think we can decide for the OpenJDK releases to have it > already in October. What do people think? (Looping in aph...) > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Simon Tooke > > Sent: Mittwoch, 18. September 2019 19:11 > > To: Andrew John Hughes ; jdk-updates- > > dev at openjdk.java.net; Aleksey Shipilev > > Subject: Re: Heads-up: JDK-8230085 and MacOS Catalina > > > > > > On 9/17/2019 4:54 PM, Andrew John Hughes wrote: > > > > > > On 17/09/2019 20:13, Simon Tooke wrote: > > >> On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: > > >>> On 9/16/19 4:04 PM, Langer, Christoph wrote: > > >>>> does tck-red mean, there are issues with current TCK? In other words, > > it can't just simply be > > >>>> backported before TCK has been adapted? > > >>> https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary > > says: "tck-red-(Rel): Used to > > >>> identify TCK conformance stoppers (e.g. failure of a valid TCK test that > > exists in a shipped TCK)." > > >>> > > >>> From this and issue description it sounds like it is legit TCK failure on > > Catalina. > > >> I've now tested the fix on jdk8u and 11u on a Catalina beta, with success. > > >> > > >> I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if > > >> they are critical (not my call) then the labels should be changed > > >> accordingly. > > >> > > >> -Simon > > >> > > > If you want to request critical, you need to use the *-critical-request > > > labels and make the case for it on the bug. In the event the issue is > > > rejected for critical, you can always then apply for *-fix-request instead. > > > > > > Hope that helps, > > > > Sure, I'll do that.? I noticed that Christoph has already decided it's > > not critical for 11u, though, so I won't be surprised if it gets rejected. > > > > Thanks, > > > > -simon > > From christoph.langer at sap.com Thu Sep 19 12:37:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Sep 2019 12:37:14 +0000 Subject: [11u] RFR(XS) 8231247: (zipfs) Test failure in jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807 Message-ID: Hi, due to a flaw in our testing system, I just discovered that the test jdk/nio/zipfs/InvalidZipHeaderTests.java from JDK-8222807 would not work in JDK11 after the backport was pushed. The required FileSystems::newFileSystem method was only added in JDK13. Please review this small fix to make it work: diff -r 9283080c1e8b -r 7c846f723590 test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java --- a/test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java Thu Jul 18 10:25:49 2019 +0200 +++ b/test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java Thu Sep 19 13:26:10 2019 +0100 @@ -80,7 +80,7 @@ public void walkInvalidHeaderTest(String startPath, List expectedPaths) throws IOException { try (FileSystem zipfs = - FileSystems.newFileSystem(Path.of(INVALID_JAR_FILE))) { + FileSystems.newFileSystem(Path.of(INVALID_JAR_FILE), null)) { List result = walk(zipfs.getPath(startPath)) .map(f -> f.toString()).collect(Collectors.toList()); assertTrue(result.equals(expectedPaths), Thanks Christoph From goetz.lindenmaier at sap.com Thu Sep 19 13:05:27 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Sep 2019 13:05:27 +0000 Subject: [11u] RFR(XS) 8231247: (zipfs) Test failure in jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807 In-Reply-To: References: Message-ID: Hi Christoph, change look good, thanks for fixing this! Is this a tier1 test? Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Langer, Christoph > Sent: Donnerstag, 19. September 2019 14:37 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR(XS) 8231247: (zipfs) Test failure in > jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807 > > Hi, > > due to a flaw in our testing system, I just discovered that the test > jdk/nio/zipfs/InvalidZipHeaderTests.java from JDK-8222807 would not work in > JDK11 after the backport was pushed. The required > FileSystems::newFileSystem method was only added in JDK13. > > Please review this small fix to make it work: > > diff -r 9283080c1e8b -r 7c846f723590 > test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java > --- a/test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java Thu Jul 18 10:25:49 > 2019 +0200 > +++ b/test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java Thu Sep 19 13:26:10 > 2019 +0100 > @@ -80,7 +80,7 @@ > public void walkInvalidHeaderTest(String startPath, List > expectedPaths) > throws IOException { > try (FileSystem zipfs = > - FileSystems.newFileSystem(Path.of(INVALID_JAR_FILE))) { > + FileSystems.newFileSystem(Path.of(INVALID_JAR_FILE), null)) { > List result = walk(zipfs.getPath(startPath)) > .map(f -> f.toString()).collect(Collectors.toList()); > assertTrue(result.equals(expectedPaths), > > Thanks > Christoph From christoph.langer at sap.com Thu Sep 19 13:18:29 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Sep 2019 13:18:29 +0000 Subject: [11u] RFR(XS) 8231247: (zipfs) Test failure in jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807 In-Reply-To: References: Message-ID: Hi Goetz, thanks for reviewing this. The test is tier2. Best regards Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 19. September 2019 15:05 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR(XS) 8231247: (zipfs) Test failure in > jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807 > > Hi Christoph, > > change look good, thanks for fixing this! > Is this a tier1 test? > > Best regards, > Goetz. > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Donnerstag, 19. September 2019 14:37 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR(XS) 8231247: (zipfs) Test failure in > > jdk/nio/zipfs/InvalidZipHeaderTests.java after backport of JDK-8222807 > > > > Hi, > > > > due to a flaw in our testing system, I just discovered that the test > > jdk/nio/zipfs/InvalidZipHeaderTests.java from JDK-8222807 would not work > in > > JDK11 after the backport was pushed. The required > > FileSystems::newFileSystem method was only added in JDK13. > > > > Please review this small fix to make it work: > > > > diff -r 9283080c1e8b -r 7c846f723590 > > test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java > > --- a/test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java Thu Jul 18 10:25:49 > > 2019 +0200 > > +++ b/test/jdk/jdk/nio/zipfs/InvalidZipHeaderTests.java Thu Sep 19 > 13:26:10 > > 2019 +0100 > > @@ -80,7 +80,7 @@ > > public void walkInvalidHeaderTest(String startPath, List > > expectedPaths) > > throws IOException { > > try (FileSystem zipfs = > > - FileSystems.newFileSystem(Path.of(INVALID_JAR_FILE))) { > > + FileSystems.newFileSystem(Path.of(INVALID_JAR_FILE), null)) > { > > List result = walk(zipfs.getPath(startPath)) > > .map(f -> f.toString()).collect(Collectors.toList()); > > assertTrue(result.equals(expectedPaths), > > > > Thanks > > Christoph From matthias.baesken at sap.com Fri Sep 20 08:06:57 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 20 Sep 2019 08:06:57 +0000 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: Hello Christoph, looks good to me ! Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 18. September 2019 11:45 To: jdk-updates-dev at openjdk.java.net Cc: i18n-dev at openjdk.java.net Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support Hi, please review this backport to JDK11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data to tzdata2019b, which is required for 11.0.5. This will make the JDK?s timezone parser support the ?vanguard? format and enables a simple backport of JDK-8228469. To make the patch applicable to jdk11u, I had to manually do all the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk. Furthermore there were some rejects which were easy to resolve in: make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> Copyright year make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> Copyright year and import statements src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java -> Copyright year With the patch applied all regression testing shows still green (both, jtreg and TCK). Thanks Christoph From christoph.langer at sap.com Fri Sep 20 09:39:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Sep 2019 09:39:35 +0000 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: Thank you, Matthias. From: Baesken, Matthias Sent: Freitag, 20. September 2019 10:07 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net Cc: i18n-dev at openjdk.java.net Subject: RE: [11u] RFR: 8212970: TZ database in "vanguard" format support Hello Christoph, looks good to me ! Best regards, Matthias From: Langer, Christoph Sent: Mittwoch, 18. September 2019 11:45 To: jdk-updates-dev at openjdk.java.net Cc: i18n-dev at openjdk.java.net Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support Hi, please review this backport to JDK11 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data to tzdata2019b, which is required for 11.0.5. This will make the JDK?s timezone parser support the ?vanguard? format and enables a simple backport of JDK-8228469. To make the patch applicable to jdk11u, I had to manually do all the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk. Furthermore there were some rejects which were easy to resolve in: make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> Copyright year make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> Copyright year and import statements src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java -> Copyright year With the patch applied all regression testing shows still green (both, jtreg and TCK). Thanks Christoph From peter.levart at gmail.com Fri Sep 20 10:18:43 2019 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 20 Sep 2019 12:18:43 +0200 Subject: [11u]: RFR JDK-8227368: EnumSet.class serialization broken in JDK 9+ In-Reply-To: <59784cf8-3324-9d4c-b5a1-1b8aa953e6b6@oracle.com> References: <303c01ae-c5a1-49f7-a9dd-2b0f4a6a2577@gmail.com> <740f6756-178d-bae8-d100-c82b0ed216a0@oracle.com> <9be5eebe-f8b4-90a7-3299-ff69958b20e6@oracle.com> <8daade20-9912-8468-0e82-03b94234019c@gmail.com> <06fc7d1d-799f-f574-7222-a45db7a44b7e@oracle.com> <3b416229-4511-3b0e-4f66-114318b8ba46@oracle.com> <7dad708b-664c-121c-94b7-8eff1d5240a7@oracle.com> <59784cf8-3324-9d4c-b5a1-1b8aa953e6b6@oracle.com> Message-ID: On 9/12/19 4:49 AM, Stuart Marks wrote: > > > On 9/10/19 2:51 PM, Langer, Christoph wrote: >>> OK, targeting both 11.0.6-openjdk and 11.0.6-oracle seems >>> reasonable. As you >>> noted, it looks like a backport is pending for 11.0.6-oracle. An >>> email from >>> Goetz L a couple weeks ago [1] says that changes pushed to [OpenJDK] >>> jdk11u-dev >>> will end up in 11.0.6. So it seems that I could just push this to >>> jdk11u-dev, >>> and then work internally to move ahead with the 11.0.6-oracle >>> backport, and this >>> will end up with the desired outcome. >>> >>> Is that right? >> >> Yep, that's right. Just push it to jdk11u-dev now and it'll be in >> 11.0.6. > > OK, pushed. Thanks for your review and guidance on this. > > s'marks > Great to see this moved forward. Thanks Stuart and others. We'll be able to cross-serialize EnumSet.class again in 2020... Regards, Peter From christoph.langer at sap.com Fri Sep 20 15:08:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Sep 2019 15:08:27 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> Message-ID: Hi, generally, I prefer to align with Oracle. So, I'll hold back the push until next Tuesday (24th of September) which is the last open day for 11u before 11.0.5 CPU work starts. If I don't get any input that changes things until then, I'll push it to jdk11u-dev (11.0.6) after Tuesday. Best regards Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 19. September 2019 14:23 > To: Langer, Christoph ; Simon Tooke > ; Andrew John Hughes ; > jdk-updates-dev at openjdk.java.net; Aleksey Shipilev ; > Andrew Haley > Subject: RE: Heads-up: JDK-8230085 and MacOS Catalina > > Hi, > > the change touches only mac files, except for removal of a 'private' > from a method. So it should not break any other platform. > Catalina is to be released in October: > https://www.apple.com/macos/catalina/ > If we deliver the fix only in January, people have to > deal with the issue until then. Thus I would not object against > pushing this to 11.0.5. > > The only thing I'm not aware of is the importance of this fix. > Does isReadOnly() being true imply that you can not write to > any file any more? This would make 11.0.5 unusable on Catalina. > Or is this just an interface rarely used? > > Best regards, > Goetz > > > > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Langer, Christoph > > Sent: Donnerstag, 19. September 2019 11:19 > > To: Simon Tooke ; Andrew John Hughes > > ; jdk-updates-dev at openjdk.java.net; Aleksey > > Shipilev ; Andrew Haley > > Subject: [CAUTION] RE: Heads-up: JDK-8230085 and MacOS Catalina > > > > Hi, > > > > I can see that Oracle has backported the change to their January update > > branches just last night. I'll ask if they have any plans to ship this already > with > > the October patches. > > > > Independent of that, I think we can decide for the OpenJDK releases to > have it > > already in October. What do people think? (Looping in aph...) > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: jdk-updates-dev > On > > > Behalf Of Simon Tooke > > > Sent: Mittwoch, 18. September 2019 19:11 > > > To: Andrew John Hughes ; jdk-updates- > > > dev at openjdk.java.net; Aleksey Shipilev > > > Subject: Re: Heads-up: JDK-8230085 and MacOS Catalina > > > > > > > > > On 9/17/2019 4:54 PM, Andrew John Hughes wrote: > > > > > > > > On 17/09/2019 20:13, Simon Tooke wrote: > > > >> On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: > > > >>> On 9/16/19 4:04 PM, Langer, Christoph wrote: > > > >>>> does tck-red mean, there are issues with current TCK? In other > words, > > > it can't just simply be > > > >>>> backported before TCK has been adapted? > > > >>> https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary > > > says: "tck-red-(Rel): Used to > > > >>> identify TCK conformance stoppers (e.g. failure of a valid TCK test > that > > > exists in a shipped TCK)." > > > >>> > > > >>> From this and issue description it sounds like it is legit TCK failure on > > > Catalina. > > > >> I've now tested the fix on jdk8u and 11u on a Catalina beta, with > success. > > > >> > > > >> I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if > > > >> they are critical (not my call) then the labels should be changed > > > >> accordingly. > > > >> > > > >> -Simon > > > >> > > > > If you want to request critical, you need to use the *-critical-request > > > > labels and make the case for it on the bug. In the event the issue is > > > > rejected for critical, you can always then apply for *-fix-request instead. > > > > > > > > Hope that helps, > > > > > > Sure, I'll do that.? I noticed that Christoph has already decided it's > > > not critical for 11u, though, so I won't be surprised if it gets rejected. > > > > > > Thanks, > > > > > > -simon > > > From martinrb at google.com Fri Sep 20 15:11:25 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Sep 2019 08:11:25 -0700 Subject: [11u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: References: Message-ID: (not a review) At Google, we decided to stay on rearguard format tzdata files for all our jdks. One reason for that was being able to easily support older jdk versions with the same data files. Vanguard still seems riskier to me than rearguard. Of course, eventually we'll need to switch to vanguard, and this backport will make that possible earlier. Another pitfall when backporting to jdk8 is that there are two copies of all the tzdata files in the repo. On Wed, Sep 18, 2019 at 2:46 AM Langer, Christoph wrote: > Hi, > > please review this backport to JDK11 updates: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8212970.11u-dev.0/ > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 > > This backport is prerequisite to JDK-8228469: (tz) Upgrade time-zone data > to tzdata2019b, which is required for 11.0.5. This will make the JDK's > timezone parser support the "vanguard" format and enables a simple backport > of JDK-8228469. > > To make the patch applicable to jdk11u, I had to manually do all the > deletions in test/jdk/sun/util/calendar/zi/tzdata and > test/jdk/sun/util/calendar/zi/tzdata_jdk. > > Furthermore there were some rejects which were easy to resolve in: > make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesCompiler.java -> > Copyright year > make/jdk/src/classes/build/tools/tzdb/TzdbZoneRulesProvider.java -> > Copyright year and import statements > src/java.base/share/classes/java/time/zone/Ser.java -> Copyright year > src/java.base/share/classes/java/time/zone/ZoneOffsetTransitionRule.java > -> Copyright year > > With the patch applied all regression testing shows still green (both, > jtreg and TCK). > > Thanks > Christoph > > From andrew_m_leonard at uk.ibm.com Sun Sep 22 20:47:04 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Sun, 22 Sep 2019 21:47:04 +0100 Subject: JDK-8228466 : HarfBuzz 2.3.1 upgrade fails on AIX.... Is this fixed for jdk13 ? Message-ID: Hi Christoph, Do you know if this is fixed for jdk13? I sort of assumed when it was fixed in jdk12u that jdk & jdk13 had the fix? but we're seeing what looks like the same failure on jdk13 AIX. https://bugs.openjdk.java.net/browse/JDK-8228466 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From christoph.langer at sap.com Mon Sep 23 10:16:32 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 23 Sep 2019 10:16:32 +0000 Subject: JDK-8228466 : HarfBuzz 2.3.1 upgrade fails on AIX.... Is this fixed for jdk13 ? In-Reply-To: References: Message-ID: Hi Andrew, these fixes were specific to JDK12 (and probably lower releases). They only popped up due to the older compilers used with JDK12. As for AIX: We (SAP) build JDK13 and newer with XlC/clang++ 16.1 For 12(and 11) we used(use) XlC 12.1. As for Solaris: For JDK12 and higher the requirement is SolStudio 12u6. We only saw this problem and requested the fix because at SAP we've always built OpenJDK12 internally with SS12u4 since it always worked and we never changed the build environment. The compiler requirements for the OpenJDK releases are collected here: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms HTH, Best regards Christoph From: Andrew Leonard Sent: Sonntag, 22. September 2019 22:47 To: jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: JDK-8228466 : HarfBuzz 2.3.1 upgrade fails on AIX.... Is this fixed for jdk13 ? Hi Christoph, Do you know if this is fixed for jdk13? I sort of assumed when it was fixed in jdk12u that jdk & jdk13 had the fix? but we're seeing what looks like the same failure on jdk13 AIX. https://bugs.openjdk.java.net/browse/JDK-8228466 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From andrew_m_leonard at uk.ibm.com Mon Sep 23 11:51:59 2019 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 23 Sep 2019 12:51:59 +0100 Subject: JDK-8228466 : HarfBuzz 2.3.1 upgrade fails on AIX.... Is this fixed for jdk13 ? In-Reply-To: References: Message-ID: Hi Christoph, Thanks for the info, it helps a lot, I checked the build log and you're right we were trying to build with xLC13.1! Regards Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com From: "Langer, Christoph" To: Andrew Leonard , "jdk-updates-dev at openjdk.java.net" Date: 23/09/2019 11:19 Subject: RE: JDK-8228466 : HarfBuzz 2.3.1 upgrade fails on AIX.... Is this fixed for jdk13 ? Hi Andrew, these fixes were specific to JDK12 (and probably lower releases). They only popped up due to the older compilers used with JDK12. As for AIX: We (SAP) build JDK13 and newer with XlC/clang++ 16.1 For 12(and 11) we used(use) XlC 12.1. As for Solaris: For JDK12 and higher the requirement is SolStudio 12u6. We only saw this problem and requested the fix because at SAP we?ve always built OpenJDK12 internally with SS12u4 since it always worked and we never changed the build environment. The compiler requirements for the OpenJDK releases are collected here: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms HTH, Best regards Christoph From: Andrew Leonard Sent: Sonntag, 22. September 2019 22:47 To: jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: JDK-8228466 : HarfBuzz 2.3.1 upgrade fails on AIX.... Is this fixed for jdk13 ? Hi Christoph, Do you know if this is fixed for jdk13? I sort of assumed when it was fixed in jdk12u that jdk & jdk13 had the fix? but we're seeing what looks like the same failure on jdk13 AIX. https://bugs.openjdk.java.net/browse/JDK-8228466 Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From jaroslav.bachorik at datadoghq.com Mon Sep 23 14:13:06 2019 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 23 Sep 2019 16:13:06 +0200 Subject: Fix request JDK-8228359 In-Reply-To: References: <8d12d70a-4929-4f8c-90c1-4c604ee72d51.denghui.ddh@alibaba-inc.com> Message-ID: Hi DDH, you will need 'Fix request' section which will describe why the backport is required for a particular version. I can help you in getting all that data into JBS but will need your input. Cheers, -JB- On Tue, Sep 17, 2019 at 8:28 AM Ioi Lam wrote: > Please include the bug summary (title) in the e-mail message. Otherwise > it's hard to keep track of what's happening in different e-mails. Thanks > > And please include your full name. > > - Ioi > > On 9/16/19 7:43 PM, DDH wrote: > > Hi all, > > I plan to backports some jfr-related patches from 13,14 to 11u, and > then 8u. This is my first time to contribute a fix, I choose JDK-8228359 ( > https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first > backport fix. > > This patch applies cleanly to 11u, and I need to put > jdk11u-fix-request label on the issue( > https://bugs.openjdk.java.net/browse/JDK-8228359), > > but I don't have JBS user count, can you help me ? > > > > Thanks, > > DDH > > From denghui.ddh at alibaba-inc.com Tue Sep 24 08:29:10 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Tue, 24 Sep 2019 16:29:10 +0800 Subject: =?UTF-8?B?UmU6IEZpeCByZXF1ZXN0IEpESy04MjI4MzU5?= In-Reply-To: References: <8d12d70a-4929-4f8c-90c1-4c604ee72d51.denghui.ddh@alibaba-inc.com> , Message-ID: <82773e32-c4bc-4822-8035-768b311767af.denghui.ddh@alibaba-inc.com> Hi JB, Christoph has helped me, thank you. Cheers, Denghui Dong ------------------------------------------------------------------ From:Jaroslav Bachor?k Send Time:2019?9?23?(???) 22:14 To:Ioi Lam Cc:jdk-updates-dev Subject:Re: Fix request JDK-8228359 Hi DDH, you will need 'Fix request' section which will describe why the backport is required for a particular version. I can help you in getting all that data into JBS but will need your input. Cheers, -JB- On Tue, Sep 17, 2019 at 8:28 AM Ioi Lam wrote: > Please include the bug summary (title) in the e-mail message. Otherwise > it's hard to keep track of what's happening in different e-mails. Thanks > > And please include your full name. > > - Ioi > > On 9/16/19 7:43 PM, DDH wrote: > > Hi all, > > I plan to backports some jfr-related patches from 13,14 to 11u, and > then 8u. This is my first time to contribute a fix, I choose JDK-8228359 ( > https://hg.openjdk.java.net/jdk/jdk13/rev/36a842b472e8)as my first > backport fix. > > This patch applies cleanly to 11u, and I need to put > jdk11u-fix-request label on the issue( > https://bugs.openjdk.java.net/browse/JDK-8228359), > > but I don't have JBS user count, can you help me ? > > > > Thanks, > > DDH > > From christoph.langer at sap.com Tue Sep 24 12:54:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 12:54:03 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> Message-ID: Hi, as per the latest discussion in the bug (https://bugs.openjdk.java.net/browse/JDK-8230085), we have agreed to bring this patch down to OpenJDK 11.0.5 and 8u232. So I've pushed it to jdk11u now (http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/ee7128cf507a). With this submit, the public part of OpenJDK 11.0.5 is done and all publicly known fixes that are contained in Oracle's 11.0.5 release have been backported, as per https://bugs.openjdk.java.net/issues/?filter=36515, which is empty now. ?? Thanks to all people that were involved in this effort! Best regards Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 20. September 2019 17:08 > To: Lindenmaier, Goetz ; Simon Tooke > ; Andrew John Hughes ; > jdk-updates-dev at openjdk.java.net; Aleksey Shipilev ; > Andrew Haley > Subject: RE: Heads-up: JDK-8230085 and MacOS Catalina > > Hi, > > generally, I prefer to align with Oracle. > > So, I'll hold back the push until next Tuesday (24th of September) which is > the last open day for 11u before 11.0.5 CPU work starts. If I don't get any > input that changes things until then, I'll push it to jdk11u-dev (11.0.6) after > Tuesday. > > Best regards > Christoph > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Donnerstag, 19. September 2019 14:23 > > To: Langer, Christoph ; Simon Tooke > > ; Andrew John Hughes > ; > > jdk-updates-dev at openjdk.java.net; Aleksey Shipilev > ; > > Andrew Haley > > Subject: RE: Heads-up: JDK-8230085 and MacOS Catalina > > > > Hi, > > > > the change touches only mac files, except for removal of a 'private' > > from a method. So it should not break any other platform. > > Catalina is to be released in October: > > https://www.apple.com/macos/catalina/ > > If we deliver the fix only in January, people have to > > deal with the issue until then. Thus I would not object against > > pushing this to 11.0.5. > > > > The only thing I'm not aware of is the importance of this fix. > > Does isReadOnly() being true imply that you can not write to > > any file any more? This would make 11.0.5 unusable on Catalina. > > Or is this just an interface rarely used? > > > > Best regards, > > Goetz > > > > > > > > > > > > > -----Original Message----- > > > From: jdk-updates-dev > On > > > Behalf Of Langer, Christoph > > > Sent: Donnerstag, 19. September 2019 11:19 > > > To: Simon Tooke ; Andrew John Hughes > > > ; jdk-updates-dev at openjdk.java.net; > Aleksey > > > Shipilev ; Andrew Haley > > > Subject: [CAUTION] RE: Heads-up: JDK-8230085 and MacOS Catalina > > > > > > Hi, > > > > > > I can see that Oracle has backported the change to their January update > > > branches just last night. I'll ask if they have any plans to ship this already > > with > > > the October patches. > > > > > > Independent of that, I think we can decide for the OpenJDK releases to > > have it > > > already in October. What do people think? (Looping in aph...) > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev > > On > > > > Behalf Of Simon Tooke > > > > Sent: Mittwoch, 18. September 2019 19:11 > > > > To: Andrew John Hughes ; jdk-updates- > > > > dev at openjdk.java.net; Aleksey Shipilev > > > > Subject: Re: Heads-up: JDK-8230085 and MacOS Catalina > > > > > > > > > > > > On 9/17/2019 4:54 PM, Andrew John Hughes wrote: > > > > > > > > > > On 17/09/2019 20:13, Simon Tooke wrote: > > > > >> On 9/16/2019 10:08 AM, Aleksey Shipilev wrote: > > > > >>> On 9/16/19 4:04 PM, Langer, Christoph wrote: > > > > >>>> does tck-red mean, there are issues with current TCK? In other > > words, > > > > it can't just simply be > > > > >>>> backported before TCK has been adapted? > > > > >>> > https://wiki.openjdk.java.net/display/HotSpot/JBS+Label+Dictionary > > > > says: "tck-red-(Rel): Used to > > > > >>> identify TCK conformance stoppers (e.g. failure of a valid TCK test > > that > > > > exists in a shipped TCK)." > > > > >>> > > > > >>> From this and issue description it sounds like it is legit TCK failure on > > > > Catalina. > > > > >> I've now tested the fix on jdk8u and 11u on a Catalina beta, with > > success. > > > > >> > > > > >> I've applied jdk8u-fix-request and jdk11u-fix-request labels, but if > > > > >> they are critical (not my call) then the labels should be changed > > > > >> accordingly. > > > > >> > > > > >> -Simon > > > > >> > > > > > If you want to request critical, you need to use the *-critical-request > > > > > labels and make the case for it on the bug. In the event the issue is > > > > > rejected for critical, you can always then apply for *-fix-request > instead. > > > > > > > > > > Hope that helps, > > > > > > > > Sure, I'll do that.? I noticed that Christoph has already decided it's > > > > not critical for 11u, though, so I won't be surprised if it gets rejected. > > > > > > > > Thanks, > > > > > > > > -simon > > > > From christoph.langer at sap.com Tue Sep 24 13:39:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 13:39:28 +0000 Subject: [11u] RFR: 8220528: [AIX] Fix basic Xinerama and Xrender functionality Message-ID: Hi, please help reviewing this backport of the fix for AIX Xinerama/Xrender basic functionality to JDK11 Updates. Bug: https://bugs.openjdk.java.net/browse/JDK-8220528 Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/0223b7b8a1c5 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8220528.11u-dev.0/ The patch did not apply cleanly. I had to manually resolve the part around line 125 because the 11u version defines another function for Solaris that didn't exist any more in the head version. Furthermore I needed to fix the #ifdef in line 1641 (new) to explicitly refer Solaris. Otherwise it would not build on AIX. Thanks Christoph From christoph.langer at sap.com Tue Sep 24 13:59:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 13:59:27 +0000 Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible Message-ID: Hi, please help reviewing the backport of test fix 8227642: [TESTBUG] Make docker tests podman compatible. Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/ Applying the patch rejected the hunk in test/lib/jdk/test/lib/Platform.java. I, however, only had to place it correctly in the jdk11u-dev version of the file. The patch is prerequisite to backporting "8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage" which we regularly see failing in our 11u regression testing. Thanks Christoph From sgehwolf at redhat.com Tue Sep 24 14:12:27 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 24 Sep 2019 16:12:27 +0200 Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: References: Message-ID: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com> Hi Christoph, On Tue, 2019-09-24 at 13:59 +0000, Langer, Christoph wrote: > Hi, > > please help reviewing the backport of test fix 8227642: [TESTBUG] > Make docker tests podman compatible. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 > Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/ Looks good. Please also backport JDK-8228434[1] as otherwise we risk breaking the jdk/net/Sockets/Test.java test. Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8228434 From christoph.langer at sap.com Tue Sep 24 14:21:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 14:21:26 +0000 Subject: [11u] RFR: 8231318: Several compiler/aot tests fail for JDK11 on Windows when only MSVC 2017 is installed Message-ID: Hi, Please review this fix to make several aot tests work in JDK11 on Windows hosts where only MSVC 2017 is installed. It actually is a backport of the changes to src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java from both the Graal updates of JDK-8206992 and JDK-8218074. Bug: https://bugs.openjdk.java.net/browse/JDK-8231318 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8231318.11u-dev.0/ Original Changes: http://hg.openjdk.java.net/jdk/jdk/rev/091c0d22e735#l89.1 (JDK-8206992) http://hg.openjdk.java.net/jdk/jdk/rev/84f10bbf993f#l3.1 (JDK-8218074) With this patch applied the test cases mentioned in the bug description pass on Windows systems where we only have MSVC 2017. Thanks Christoph From christoph.langer at sap.com Tue Sep 24 14:37:28 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 24 Sep 2019 14:37:28 +0000 Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com> References: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com> Message-ID: Hi Severin, thanks for review and this hint. I've just created a backport patch and will run it through our nightlies. Will probably send out an RFR tomorrow. Interestingly we didn't encounter issues in jdk/net/Sockets/Test.java with 8227642 applied. But in any case, adding 8228434 will be better. Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Dienstag, 24. September 2019 16:12 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: hotspot-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman > compatible > > Hi Christoph, > > On Tue, 2019-09-24 at 13:59 +0000, Langer, Christoph wrote: > > Hi, > > > > please help reviewing the backport of test fix 8227642: [TESTBUG] > > Make docker tests podman compatible. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 > > Webrev: > > http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/ > > Looks good. > > Please also backport JDK-8228434[1] as otherwise we risk breaking the > jdk/net/Sockets/Test.java test. > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8228434 From sgehwolf at redhat.com Tue Sep 24 15:00:15 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 24 Sep 2019 17:00:15 +0200 Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: References: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com> Message-ID: <99b51af63b3a6b8040c0eb881c7c2a483bac88ad.camel@redhat.com> Hi Christoph, On Tue, 2019-09-24 at 14:37 +0000, Langer, Christoph wrote: > Hi Severin, > > thanks for review and this hint. I've just created a backport patch > and will run it through our nightlies. Will probably send out an RFR > tomorrow. > > Interestingly we didn't encounter issues in jdk/net/Sockets/Test.java > with 8227642 applied. But in any case, adding 8228434 will be better. On second thought, it looks like the OpenJDK 11u version of jdk/net/Sockets/Test.java doesn't use Platform (jdk/jdk's version does). So we are probably good at this point. No need for 8228434 in JDK 11u, AFAICS. Usages of Platform + running with a SecurityManager triggers the problem. OpenJDK 11 seems OK. Thanks, Severin > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Dienstag, 24. September 2019 16:12 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman > > compatible > > > > Hi Christoph, > > > > On Tue, 2019-09-24 at 13:59 +0000, Langer, Christoph wrote: > > > Hi, > > > > > > please help reviewing the backport of test fix 8227642: [TESTBUG] > > > Make docker tests podman compatible. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227642 > > > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/709913d8ace9 > > > Webrev: > > > http://cr.openjdk.java.net/~clanger/webrevs/8227642.11u-dev.0/ > > > > Looks good. > > > > Please also backport JDK-8228434[1] as otherwise we risk breaking the > > jdk/net/Sockets/Test.java test. > > > > Thanks, > > Severin > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8228434 From vladimir.kozlov at oracle.com Tue Sep 24 23:08:13 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 24 Sep 2019 16:08:13 -0700 Subject: [11u] RFR: 8231318: Several compiler/aot tests fail for JDK11 on Windows when only MSVC 2017 is installed In-Reply-To: References: Message-ID: <0fc98950-9c4c-ac77-9172-41b36c19e857@oracle.com> Looks good. Thanks, Vladimir On 9/24/19 7:21 AM, Langer, Christoph wrote: > Hi, > > Please review this fix to make several aot tests work in JDK11 on Windows hosts where only MSVC 2017 is installed. It actually is a backport of the changes to src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java from both the Graal updates of JDK-8206992 and JDK-8218074. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231318 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8231318.11u-dev.0/ > > Original Changes: > http://hg.openjdk.java.net/jdk/jdk/rev/091c0d22e735#l89.1 (JDK-8206992) > http://hg.openjdk.java.net/jdk/jdk/rev/84f10bbf993f#l3.1 (JDK-8218074) > > With this patch applied the test cases mentioned in the bug description pass on Windows systems where we only have MSVC 2017. > > Thanks > Christoph > From goetz.lindenmaier at sap.com Wed Sep 25 05:58:44 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Sep 2019 05:58:44 +0000 Subject: [11u notice]: jdk11u closed now Message-ID: Hi, Tag jdk-11.0.5+9 was pushed. jdk11u is closed now. Please don't push to jdk11u any more. The closed security changes for 11.0.5 will be prepared on top of this tag. Best regards, Goetz. See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u From christoph.langer at sap.com Wed Sep 25 11:49:27 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 Sep 2019 11:49:27 +0000 Subject: [11u] RFR: 8231318: Several compiler/aot tests fail for JDK11 on Windows when only MSVC 2017 is installed In-Reply-To: <0fc98950-9c4c-ac77-9172-41b36c19e857@oracle.com> References: <0fc98950-9c4c-ac77-9172-41b36c19e857@oracle.com> Message-ID: Thanks, Vladimir. > -----Original Message----- > From: Vladimir Kozlov > Sent: Mittwoch, 25. September 2019 01:08 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: Re: [11u] RFR: 8231318: Several compiler/aot tests fail for JDK11 on > Windows when only MSVC 2017 is installed > > Looks good. > > Thanks, > Vladimir > > On 9/24/19 7:21 AM, Langer, Christoph wrote: > > Hi, > > > > Please review this fix to make several aot tests work in JDK11 on Windows > hosts where only MSVC 2017 is installed. It actually is a backport of the > changes to > src/jdk.aot/share/classes/jdk.tools.jaotc/src/jdk/tools/jaotc/Linker.java > from both the Graal updates of JDK-8206992 and JDK-8218074. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231318 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8231318.11u- > dev.0/ > > > > Original Changes: > > http://hg.openjdk.java.net/jdk/jdk/rev/091c0d22e735#l89.1 (JDK-8206992) > > http://hg.openjdk.java.net/jdk/jdk/rev/84f10bbf993f#l3.1 (JDK-8218074) > > > > With this patch applied the test cases mentioned in the bug description > pass on Windows systems where we only have MSVC 2017. > > > > Thanks > > Christoph > > From christoph.langer at sap.com Wed Sep 25 14:18:42 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 Sep 2019 14:18:42 +0000 Subject: [11u] RFR: 8227642: [TESTBUG] Make docker tests podman compatible In-Reply-To: <99b51af63b3a6b8040c0eb881c7c2a483bac88ad.camel@redhat.com> References: <77bcf5e42163eda9969fefa6f819f594024c31fd.camel@redhat.com> <99b51af63b3a6b8040c0eb881c7c2a483bac88ad.camel@redhat.com> Message-ID: Hi Severin, > > Interestingly we didn't encounter issues in jdk/net/Sockets/Test.java > > with 8227642 applied. But in any case, adding 8228434 will be better. > > On second thought, it looks like the OpenJDK 11u version of > jdk/net/Sockets/Test.java doesn't use Platform (jdk/jdk's version > does). So we are probably good at this point. No need for 8228434 in > JDK 11u, AFAICS. Usages of Platform + running with a SecurityManager > triggers the problem. OpenJDK 11 seems OK. OK, that explains it. However, I think it's beneficial to take JDK-8228434 together with JDK-8227642. I ran a backport of it through our nightlies and the results still look good. Will send out an RFR shortly. Best regards Christoph From christoph.langer at sap.com Wed Sep 25 14:36:19 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 25 Sep 2019 14:36:19 +0000 Subject: [11u] RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 Message-ID: Hi, please review the backport of this test fix which shall be brought to JDK11 updates together with "JDK-8227642 [TESTBUG] Make docker tests podman compatible". The reported test failure would not occur in JDK11u, but this change does no harm and can help to avoid issues should other test changes be backported that rely on this fix. After applying the original patch, I had to resolve test/jdk/TEST.ROOT manually and also had to manually fit the hunk in test/lib/jdk/test/lib/Platform.java. Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/07e998f8f816 11u-Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228434.11u-dev.0/ Thanks Christoph From sgehwolf at redhat.com Wed Sep 25 14:51:38 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 25 Sep 2019 16:51:38 +0200 Subject: [11u] RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 In-Reply-To: References: Message-ID: <64233910dfdc15594bdad1d983915bdb6d6592c4.camel@redhat.com> On Wed, 2019-09-25 at 14:36 +0000, Langer, Christoph wrote: > Hi, > > please review the backport of this test fix which shall be brought to > JDK11 updates together with ?JDK-8227642 [TESTBUG] Make docker tests > podman compatible?. > > The reported test failure would not occur in JDK11u, but this change > does no harm and can help to avoid issues should other test changes > be backported that rely on this fix. > > After applying the original patch, I had to resolve > test/jdk/TEST.ROOT manually and also had to manually fit the hunk in > test/lib/jdk/test/lib/Platform.java. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228434 > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/07e998f8f816 > 11u-Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228434.11u-dev.0/ Looks fine. Thanks, Severin From denghui.ddh at alibaba-inc.com Thu Sep 26 07:46:08 2019 From: denghui.ddh at alibaba-inc.com (=?UTF-8?B?6JGj55m76L6JKOWNk+aYgik=?=) Date: Thu, 26 Sep 2019 15:46:08 +0800 Subject: =?UTF-8?B?WzExdV0gUkZSIDgyMTczNjI6IEVtZXJnZW5jeSBkdW1wIGRvZXMgbm90IHdvcmsgd2hlbiBk?= =?UTF-8?B?aXNrPWZhbHNlIGlzIHNldA==?= In-Reply-To: <4e821d09-ad80-4750-8bbd-bdeadfb085c2.> References: <4e821d09-ad80-4750-8bbd-bdeadfb085c2.> Message-ID: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> Hi all, 11u has the same problem. Please review this backport, original patch doesn't apply cleanly caused by Hunk FAILED in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8217362 http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java Thanks, Denghui Dong From shade at redhat.com Thu Sep 26 09:38:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 26 Sep 2019 11:38:41 +0200 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> Message-ID: On 9/24/19 2:54 PM, Langer, Christoph wrote: > With this submit, the public part of OpenJDK 11.0.5 is done and all publicly known fixes that > are contained in Oracle's 11.0.5 release have been backported, as per > https://bugs.openjdk.java.net/issues/?filter=36515, which is empty now. ?? Thanks to all people > that were involved in this effort! We might want to get the additional test into 11.0.6 / 8u242 too: https://bugs.openjdk.java.net/browse/JDK-8231254 -- Thanks, -Aleksey From ramanand.patil at oracle.com Thu Sep 26 09:45:46 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 26 Sep 2019 02:45:46 -0700 (PDT) Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support Message-ID: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> Hi all, Please review this backport to JDK13 updates: Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 Webrev: http://cr.openjdk.java.net/~rpatil/8212970/webrev.00/ Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 The patch from jdk14 was not applied cleanly. Here is the change summary: - All the deletions in test/jdk/sun/util/calendar/zi/tzdata and test/jdk/sun/util/calendar/zi/tzdata_jdk are done manually. - The original patch(jdk14) had tzdata2019a vanguard format, but since the jdk13u is already patched with tzdata2019b rearguard format, in this patch tzdata files used are from tzdata2019b vanguard format. Post this backport, it will be easy to backport future tzdata versions starting tzdata2019c(JDK-8231098). All the related tests including JCK are passed. Regards, Ramanand. From christoph.langer at sap.com Thu Sep 26 09:47:15 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 26 Sep 2019 09:47:15 +0000 Subject: Heads-up: JDK-8230085 and MacOS Catalina In-Reply-To: References: <2a63c759-c96f-cda6-1ca5-2e23241c510a@redhat.com> <0b4fdc73-3981-7bdc-9df0-e1a534d8695d@redhat.com> Message-ID: Hi Aleksey, yes, I agree. Feel free to do the backport ?? Thanks Christoph > -----Original Message----- > From: Aleksey Shipilev > Sent: Donnerstag, 26. September 2019 11:39 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Cc: Lindenmaier, Goetz ; Simon Tooke > ; Andrew John Hughes ; > Andrew Haley > Subject: Re: Heads-up: JDK-8230085 and MacOS Catalina > > On 9/24/19 2:54 PM, Langer, Christoph wrote: > > With this submit, the public part of OpenJDK 11.0.5 is done and all publicly > known fixes that > > are contained in Oracle's 11.0.5 release have been backported, as per > > https://bugs.openjdk.java.net/issues/?filter=36515, which is empty now. > ?? Thanks to all people > > that were involved in this effort! > > We might want to get the additional test into 11.0.6 / 8u242 too: > https://bugs.openjdk.java.net/browse/JDK-8231254 > > -- > Thanks, > -Aleksey From jkang at redhat.com Thu Sep 26 12:48:57 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 26 Sep 2019 08:48:57 -0400 Subject: [11u] RFR 8217362: Emergency dump does not work when disk=false is set In-Reply-To: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> References: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> Message-ID: On Thu, Sep 26, 2019 at 3:46 AM ???(??) wrote: > > Hi all, > 11u has the same problem. Please review this backport, original patch doesn't apply cleanly caused by Hunk FAILED > in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217362 > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java Hi, Looks like I forgot to update the bug and there was a duplicate of work [1] :( That's my fault, sorry for this mistake. In any case, the changes are identical to mine so I think it looks okay, but should include the original commit metadata like author and message. Of course I am not a reviewer so another will need to look. [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001883.html Regards, > > Thanks, > Denghui Dong From denghui.ddh at alibaba-inc.com Thu Sep 26 13:31:21 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 26 Sep 2019 21:31:21 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUiA4MjE3MzYyOiBFbWVyZ2VuY3kgZHVtcCBkb2VzIG5vdCB3b3JrIHdo?= =?UTF-8?B?ZW4gZGlzaz1mYWxzZSBpcyBzZXQ=?= In-Reply-To: References: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com>, Message-ID: <7c2a9819-9559-470b-8226-e42f0bd0b164.denghui.ddh@alibaba-inc.com> Hi Jie Kang, I'm sorry that I didn't browse the previous mail. By the way, I think that my webrev has already included the original commit information, right ? Thanks, Denghui Dong ------------------------------------------------------------------ From:Jie Kang Send Time:2019?9?26?(???) 20:50 To:???(??) Cc:jdk-updates-dev Subject:Re: [11u] RFR 8217362: Emergency dump does not work when disk=false is set On Thu, Sep 26, 2019 at 3:46 AM ???(??) wrote: > > Hi all, > 11u has the same problem. Please review this backport, original patch doesn't apply cleanly caused by Hunk FAILED > in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > > 11u-webrev: > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217362 > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java Hi, Looks like I forgot to update the bug and there was a duplicate of work [1] :( That's my fault, sorry for this mistake. In any case, the changes are identical to mine so I think it looks okay, but should include the original commit metadata like author and message. Of course I am not a reviewer so another will need to look. [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001883.html Regards, > > Thanks, > Denghui Dong From jkang at redhat.com Thu Sep 26 13:45:33 2019 From: jkang at redhat.com (Jie Kang) Date: Thu, 26 Sep 2019 09:45:33 -0400 Subject: [11u] RFR 8217362: Emergency dump does not work when disk=false is set In-Reply-To: <7c2a9819-9559-470b-8226-e42f0bd0b164.denghui.ddh@alibaba-inc.com> References: <610de40c-95b4-4c64-9696-c6fd84815382.denghui.ddh@alibaba-inc.com> <7c2a9819-9559-470b-8226-e42f0bd0b164.denghui.ddh@alibaba-inc.com> Message-ID: Hey Denghui Dong, No worries, that is 100% my fault, not yours. Ah, I didn't see the information inside the patch file: http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/jdk11u-dev.patch but I do see it in the individual diffs. I was thinking it might be easier to push your patch if the .patch file has the commit data; this makes it so $ hg import works smoothly. But, maybe there is a better way to grab the patch + info from webrev that I'm not familiar with. Regards, On Thu, Sep 26, 2019 at 9:31 AM Denghui Dong wrote: > > Hi Jie Kang, > I'm sorry that I didn't browse the previous mail. > By the way, I think that my webrev has already included the original commit information, right ? > > Thanks, > Denghui Dong > > ------------------------------------------------------------------ > From:Jie Kang > Send Time:2019?9?26?(???) 20:50 > To:???(??) > Cc:jdk-updates-dev > Subject:Re: [11u] RFR 8217362: Emergency dump does not work when disk=false is set > > On Thu, Sep 26, 2019 at 3:46 AM ???(??) wrote: > > > > Hi all, > > 11u has the same problem. Please review this backport, original patch doesn't apply cleanly caused by Hunk FAILED > > in test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java and src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp > > > > 11u-webrev: > > http://cr.openjdk.java.net/~wzhuo/8217362/webrev.00/ > > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8217362 > > http://hg.openjdk.java.net/jdk/jdk/rev/3cabb47758c9 > > > > Testing: test/jdk/jdk/jfr/jvm/TestDumpOnCrash.java > > > Hi, > > Looks like I forgot to update the bug and there was a duplicate of > work [1] :( That's my fault, sorry for this mistake. > > In any case, the changes are identical to mine so I think it looks > okay, but should include the original commit metadata like author and > message. Of course I am not a reviewer so another will need to look. > > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-September/001883.html > > Regards, > > > > > Thanks, > > Denghui Dong From denghui.ddh at alibaba-inc.com Thu Sep 26 15:02:49 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 26 Sep 2019 23:02:49 +0800 Subject: =?UTF-8?B?WzExdV0gUkZSIDgxODU1MjU6IEFkZCBKRlIgZXZlbnQgZm9yIERpY3Rpb25hcnlTaXplcw==?= Message-ID: <26f8d18c-17d7-45a1-adeb-f4cef393f61f.denghui.ddh@alibaba-inc.com> Hi all, Please review this backport, original patch doesn't apply cleanly, because SymbolTable has made some changes in upstream (I think it's not necessary to backport those changes) and class ClassLoaderDataGraph is located in different files. 11u-webrev: http://cr.openjdk.java.net/~wzhuo/8185525/webrev.00/ Original bug: https://bugs.openjdk.java.net/browse/JDK-8185525 http://hg.openjdk.java.net/jdk/jdk/rev/865ec913f916 Testing: test/jdk/jdk/jfr/event/runtime/TestTableStatisticsEvent.java Thanks, Denghui Dong From ramanand.patil at oracle.com Fri Sep 27 08:58:23 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 27 Sep 2019 01:58:23 -0700 (PDT) Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> Message-ID: <285975f8-b183-4e33-bc2b-58115b676ff2@default> Adding i18n group. Regards, Ramanand. > -----Original Message----- > From: Ramanand Patil > Sent: Thursday, September 26, 2019 3:16 PM > To: jdk-updates-dev at openjdk.java.net > Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support > > Hi all, > Please review this backport to JDK13 updates: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 > Webrev: http://cr.openjdk.java.net/~rpatil/8212970/webrev.00/ > Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 > > The patch from jdk14 was not applied cleanly. Here is the change summary: > - All the deletions in test/jdk/sun/util/calendar/zi/tzdata and > test/jdk/sun/util/calendar/zi/tzdata_jdk are done manually. > - The original patch(jdk14) had tzdata2019a vanguard format, but > since the jdk13u is already patched with tzdata2019b rearguard format, in > this patch tzdata files used are from tzdata2019b vanguard format. > Post this backport, it will be easy to backport future tzdata versions starting > tzdata2019c(JDK-8231098). > > All the related tests including JCK are passed. > > > Regards, > Ramanand. From naoto.sato at oracle.com Fri Sep 27 16:14:35 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 27 Sep 2019 09:14:35 -0700 Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support In-Reply-To: <285975f8-b183-4e33-bc2b-58115b676ff2@default> References: <91d56aa4-bb65-4aea-b8f5-6e5aa2d79989@default> <285975f8-b183-4e33-bc2b-58115b676ff2@default> Message-ID: Looks good to me. Naoto On 9/27/19 1:58 AM, Ramanand Patil wrote: > Adding i18n group. > > > Regards, > Ramanand. > >> -----Original Message----- >> From: Ramanand Patil >> Sent: Thursday, September 26, 2019 3:16 PM >> To: jdk-updates-dev at openjdk.java.net >> Subject: [13u] RFR: 8212970: TZ database in "vanguard" format support >> >> Hi all, >> Please review this backport to JDK13 updates: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212970 >> Webrev: http://cr.openjdk.java.net/~rpatil/8212970/webrev.00/ >> Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/99d2dd7b84a8 >> >> The patch from jdk14 was not applied cleanly. Here is the change summary: >> - All the deletions in test/jdk/sun/util/calendar/zi/tzdata and >> test/jdk/sun/util/calendar/zi/tzdata_jdk are done manually. >> - The original patch(jdk14) had tzdata2019a vanguard format, but >> since the jdk13u is already patched with tzdata2019b rearguard format, in >> this patch tzdata files used are from tzdata2019b vanguard format. >> Post this backport, it will be easy to backport future tzdata versions starting >> tzdata2019c(JDK-8231098). >> >> All the related tests including JCK are passed. >> >> >> Regards, >> Ramanand. From sgehwolf at redhat.com Mon Sep 30 11:48:48 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Sep 2019 13:48:48 +0200 Subject: [11u] 8215913: [Test_bug]java/util/Locale/LocaleProvidersRun.java failed on de_DE and ja_JP locale. Message-ID: <20b83df9a70a1f6651a6b56f89cf3c05766409a6.camel@redhat.com> Hi, Please review this test stabilization patch. The issue doesn't actually reproduce in 11u without this patch: diff --git a/test/jdk/java/util/Locale/LocaleProviders.sh b/test/jdk/java/util/Locale/LocaleProviders.sh --- a/test/jdk/java/util/Locale/LocaleProviders.sh +++ b/test/jdk/java/util/Locale/LocaleProviders.sh @@ -352,7 +352,7 @@ # testing 8027289 fix, if the platform format default is zh_CN # this assumes Windows' currency symbol for zh_CN is \u00A5, the yen # (yuan) sign. -if [ "${DEFFMTLANG}" = "zh" ] && [ "${DEFFMTCTRY}" = "CN" ]; then +if [ ! "${DEFFMTLANG}" = "en" ] && [ ! "${DEFFMTCTRY}" = "CN" ]; then METHODNAME=bug8027289Test PREFLIST=JRE,HOST PARAM1=FFE5 With it it does, since the test is actually called (and fails) with de_DE locale. The patch didn't apply cleanly due to copyright hunk fails (upper bound year is already at 2019) and LocaleProvidersRun.java being LocaleProviders.sh in JDK 11u. It's one of the Oracle JDK 11 partity patches, if that helps gauge why I'm proposing this. Personally, I wouldn't backport it, but I thought to get some feedback whether we want this or not. Bug: https://bugs.openjdk.java.net/browse/JDK-8215913 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8215913/01/webrev/ Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/76f7dbf458fe Thoughts? Thanks, Severin From sgehwolf at redhat.com Mon Sep 30 15:24:49 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Sep 2019 17:24:49 +0200 Subject: [11u] RFR: 8215449: Several tests failing when jtreg run with -vmoption:--illegal-access=deny Message-ID: <25825d9b67725f1e2dd5e6e447e8c9f47b3b485e.camel@redhat.com> Hi, Please review this Oracle JDK 11 partity patch. Some tests are failing in JDK 11u when VM option --illegal-access=deny is being used. The only test as mentioned in JDK-8215449 which also fails in JDK 11u is RacyHandler.java. Other tests' status is as follows: * LocaleProvider.sh (equiv of LocaleProvidersRun.java) doesn't fail with ?--illegal-access=deny * CanHandleClassFilesTest.java doesn't exist in JDK 11u and isn't appropriate. JDK-8207954 added that test, which makes no sense for JDK 11u. However, I've noticed that other tests are failing in tier1 with -- illegal-access=deny. Due to the above and those failures I've done these changes to the original patch: * ReflectionCallerCacheTest.java fails with --illegal-access=deny in OpenJDK 11u. Added 'java.base/java.lang.reflect:+open' to @modules tag so that the test passes in JDK 11u as well. Requires JDK-8208364 * Drop hunk to LocaleProvidersRun.java as it doesn't apply JDK 11u. * Omit changes to CanHandleClassFilesTest.java as it doesn't apply to JDK 11. Bug: https://bugs.openjdk.java.net/browse/JDK-8215449 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8215449/03/webrev/ Original changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9dd0a2fdec24 Testing: Relevant tests fail prior with option --illegal-access=deny and pass after. I'll also backport JDK-8210789 and JDK-8208364. JDK-8210789 applies cleanly and fixes T8152616.java failure with --illegal-access=deny. JDK-8208364 is a pre-requisite of this patch. It also applies cleanly. Thoughts? Thanks, Severin From bourges.laurent at gmail.com Mon Sep 30 16:13:20 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 30 Sep 2019 18:13:20 +0200 Subject: Bad push for JDK-8230728: Thin stroked shapes are not rendered if affine transform has flip bit Message-ID: Hi, I pushed by mistake on the jdk11u (11.0.5) repository, not on jdk11u-dev ! Sorry, sorry, sorry. Previously I only had to deal with 10u, 12u... See https://bugs.openjdk.java.net/browse/JDK-8231621 How can I (or you) revert that changeset ? What is the process ? PS: I will get rid of my local copy jdk11u (master), I already retrieved the jdk11u-dev to use instead. Thanks for your help, Laurent From sgehwolf at redhat.com Mon Sep 30 16:53:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 30 Sep 2019 18:53:02 +0200 Subject: [11u] RFR: 8228687: [TESTBUG] exclude Container tests from hotspot_misc group Message-ID: <37688aafbaab92740bb043efda894b78db56e5dd.camel@redhat.com> Hi, Could I please get a review of this trivial test bug fix? It brings OpenJDK 11u one step closer to what's in Oracle JDK 11.0.6. The patch from JDK head didn't apply cleanly as JDK-8217666 isn't in OpenJDK 11. I've recreated the patch manually. Bug: https://bugs.openjdk.java.net/browse/JDK-8228687 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228687/01/webrev/ Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/a26bc1847594 Testing: On a system with docker properly configured used jtreg -l to list tests for hotspot_misc group before[1] and after[2] Thoughts? Thanks, Severin [1] $ jtreg -l -dir:./test/hotspot/jtreg/ :hotspot_misc | grep containers containers/cgroup/PlainRead.java containers/docker/DockerBasicTest.java containers/docker/TestCPUAwareness.java containers/docker/TestCPUSets.java containers/docker/TestJFREvents.java containers/docker/TestJFRNetworkEvents.java containers/docker/TestMemoryAwareness.java containers/docker/TestMisc.java [2]