From alexey at azul.com Mon Dec 2 15:56:42 2019 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 2 Dec 2019 15:56:42 +0000 Subject: [8u] RFR for backport JDK-8226374: Restrict TLS signature schemes and named groups Message-ID: Hi, I?d like to request a review for the 8u backport of JDK-8226374. Original bug: https://bugs.openjdk.java.net/browse/JDK-8226374 https://hg.openjdk.java.net/jdk/jdk/rev/a93b7b28f644 Original patch can not apply cleanly, because of difference in TLS implementation. 8u webrev: http://cr.openjdk.java.net/~bae/8226374/webrev.00/ Thank you. Alexey From mbalao at redhat.com Mon Dec 2 16:44:45 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 2 Dec 2019 13:44:45 -0300 Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" In-Reply-To: References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com> <23a785bdd5604f33b2b2c1fb54ea3547@azul.com> <8791ec11a0134598b7e7d40b9e46ba1a@azul.com> Message-ID: <063b04c4-23ad-6dcf-0bfc-aaaa4a2f66a4@redhat.com> Hi Yuri, Now that 8073108 has been integrated into the 8u-dev repository [1] [2], and considering that your proposal for a 8u backport of 8130341 has been reviewed and approved, can you please push it? Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/44ef77ad417c [2] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/168c73fb6713 From stooke at redhat.com Mon Dec 2 16:44:55 2019 From: stooke at redhat.com (Simon Tooke) Date: Mon, 2 Dec 2019 11:44:55 -0500 Subject: RFR: JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u In-Reply-To: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> References: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> Message-ID: <9bf2f259-020a-c165-a329-8943b07d2f11@redhat.com> (disclaimer: I am not a reviewer) I did test Yuri's fix on macOS Catalina 10.5.1 / XCode 11.2.1, and it did fix the issue (which I reproduced) and the two included regressions tests passed.? The patch applied cleanly on 8u242-b01. I have not yet run the full regression suite, so I don't know if there are any regressions. -Simon On 2019-10-07 8:25 a.m., Yuri Nesterenko wrote: > Hi all, > > could you please review this downport of > https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? > > Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ > > There is a single digit change discovered by prr and a couple of > regression tests: > > one verifies that required shaping works as expected and another -- that > there's no obvious regression for JDK-8201801 > > > Thank you! > > --yan > > > From mbalao at redhat.com Mon Dec 2 17:05:51 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 2 Dec 2019 12:05:51 -0500 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: <7e2399fd-607b-ace0-0c00-34a72adbbb1a@redhat.com> References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> <7EEE0914-6301-4452-963B-F6A57C7F265B@oracle.com> <7e2399fd-607b-ace0-0c00-34a72adbbb1a@redhat.com> Message-ID: Hi, Ping. Can someone please have a look at this? CSR review pending: https://bugs.openjdk.java.net/browse/JDK-8230491 Patch review pending: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009945.html Approval is also pending. Thanks, Martin.- On 8/19/19 7:21 PM, Martin Balao wrote: > I've requested the JDK-11 and JDK-8 backports of 8229767 [1]. > > Can any JDK-11/JDK-8 maintainer please approve both 8229767 [1] and > 8200400 [2] backports? From hohensee at amazon.com Mon Dec 2 18:59:25 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 2 Dec 2019 18:59:25 +0000 Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" In-Reply-To: <063b04c4-23ad-6dcf-0bfc-aaaa4a2f66a4@redhat.com> References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com> <23a785bdd5604f33b2b2c1fb54ea3547@azul.com> <8791ec11a0134598b7e7d40b9e46ba1a@azul.com> <063b04c4-23ad-6dcf-0bfc-aaaa4a2f66a4@redhat.com> Message-ID: <1BDBEDB9-4761-457C-9DDE-73C5AFE53C81@amazon.com> Hi, Martin, Yuri isn't a Committer (he's a jdk9 Author), so can't push. I took the liberty of pushing it for him. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/e55d4d896e30 Thanks, Paul ?On 12/2/19, 8:45 AM, "jdk8u-dev on behalf of Martin Balao" wrote: Hi Yuri, Now that 8073108 has been integrated into the 8u-dev repository [1] [2], and considering that your proposal for a 8u backport of 8130341 has been reviewed and approved, can you please push it? Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/44ef77ad417c [2] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/168c73fb6713 From hohensee at amazon.com Mon Dec 2 19:48:55 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 2 Dec 2019 19:48:55 +0000 Subject: JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u In-Reply-To: <045CB7FE-AA43-4EF7-89B7-38C81EA1A837@amazon.com> References: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> <045CB7FE-AA43-4EF7-89B7-38C81EA1A837@amazon.com> Message-ID: <9160426E-1AA8-49E8-ADFF-CBA00AA3778B@amazon.com> There's been no response on 2d-dev, so I'm ok with going ahead with this. Paul ?On 10/8/19, 2:55 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: This looks reasonable to me based on prr's description, but I've got almost no experience in this area. I'd cross-post to 2d-dev to see what they think. They might be interested in your regression tests. Paul On 10/7/19, 5:28 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: Hi all, could you please review this downport of https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ There is a single digit change discovered by prr and a couple of regression tests: one verifies that required shaping works as expected and another -- that there's no obvious regression for JDK-8201801 Thank you! --yan From mbalao at redhat.com Mon Dec 2 20:23:30 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 2 Dec 2019 15:23:30 -0500 Subject: [8u] RFR 8055351: sun/security/provider/DSA/TestAlgParameterGenerator.java failed with interrupted! (timed out?) In-Reply-To: References: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com> Message-ID: <55f243e9-995d-1823-d227-7fc0dbe4bc01@redhat.com> Hi Andrew, On 11/28/19 1:12 AM, Andrew John Hughes wrote: > > Why is the copyright being changed here? The 8u version is already later > than the change in this patch (presumably from 8181048), so can just be > left alone. By changing it to 2019, you're creating a change unique to > 8u which will has the potential to cause problems for other backports. Thanks for having a look. I'm not sure why I bumped the copyright date here; it might have been an error as I cannot find any reasons. Webrev.01: http://cr.openjdk.java.net/~mbalao/webrevs/8055351/8055351.8u.jdk.webrev.01/ Thanks, Martin.- From hohensee at amazon.com Mon Dec 2 21:43:26 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 2 Dec 2019 21:43:26 +0000 Subject: [8u] RFR: 8218580: endpoint identification algorithm should be case-insensitive In-Reply-To: References: <7B408184-7E67-4185-A595-8C92303D2B0D@amazon.com> Message-ID: Tip rev 52170 for 8208209 is http://hg.openjdk.java.net/jdk/jdk/rev/2990f1e1c325. jdk11u rev 51320 for 820829 is http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/781b5d8f2f75. jdk8u-dev rev 13243 for 8202613 is http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/7f473886abb4. PreSharedKeyExtension.java is part of the TLS 1.3 implementation, so the hunk I identified indeed doesn't apply. Thanks, Paul ?On 11/22/19, 2:04 PM, "Verghese, Clive" wrote: Hi Paul, Thank you for reviewing the change. The hunks in the TIP were added by JBS-Issue JDK-8208209 [rev 52170]. 8208209: Improve TLS connection stability again Reviewed-by: xuelei Though the same JBS issue was not backported, similar changeset exists in JDK-8 (JDK-8202613) [rev 13244]. 8202613: Improve TLS connections stability Reviewed-by: xuelei, wetmore It looks like the hunks on line 1036 does not apply to JDK-8 Regards, Clive Verghese On 11/18/19, 3:56 PM, "Hohensee, Paul" wrote: If the code in the hunk that didn't apply is ever backported, context will be lost and incompatible code will result. Better to find the patch referenced by that hunk and backport it. Thanks, Paul On 10/31/19, 10:00 AM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi, I am requesting review for backport of JDK-8218580 Webrev : http://cr.openjdk.java.net/~phh/8218580/webrev.8u.00/ JBS Bug : https://bugs.openjdk.java.net/browse/JDK-8218580 Original Change : http://hg.openjdk.java.net/jdk/jdk/rev/c34acb3a3330 Change Set for JDK 11 : http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/148957581f5c The JBS Bug marks the issue as Introduced in 11. But checking the 8u code, it looks like the bug is effecting 8u as well. The backport to 8u did not apply cleanly. Other than the filename changes and line number changes, one of the notable changes is that only 2 of the 3 hunks applied in ClientHandshaker.java. The patch has passed tier-1 in Linux and no new regressions were found. Regards, Clive Verghese From hohensee at amazon.com Mon Dec 2 22:06:11 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 2 Dec 2019 22:06:11 +0000 Subject: [8u] RFR: 8186576: [2/2] KerberosTicket does not properly handle renewable tickets at the end of their lifetime In-Reply-To: References: Message-ID: Ping for another review pls. Thanks, Paul ?On 11/18/19, 3:48 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Lgtm. I looked at [1/2] JDK-8044500 first, and same request applies: would another reviewer also take a look please? Thanks, Paul On 11/8/19, 11:39 AM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi, Requesting review for backport of JDK-8186576. JDK-8186576 JBS Issues : https://bugs.openjdk.java.net/browse/JDK-8186576 Original Change : http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/fa7582840977 Webrev : http://cr.openjdk.java.net/~alvdavi/webrevs/8186576/webrev.8u.00/ The backport did not apply cleanly, It required changes from JDK-804450. The test case written for JDK-8186576, specifically NullRenewUntil, was requesting renewable tickets, support for which was added in JDK-8044500. Additionally parts of JDK-8044500 had already been backported. We could 1. Add the required functions and update the tests. Or 2. Backport JDK-8044500 I have backported both JDK-8044500 and JDK-8186576. Other than the usual changes to filenames and copyrights, The patches also needed minor modifications mentioned below. JDK-8186576 * Variable name change in KDC.java * Missing ?{? in the if blocks in KerberosTicket.java Regards, Clive Verghese From hohensee at amazon.com Mon Dec 2 22:06:27 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 2 Dec 2019 22:06:27 +0000 Subject: [8u] RFR 8044500: [1/2] Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes In-Reply-To: <61F3E89F-8B2E-47B2-BAB4-915967FC0C8E@amazon.com> References: <6C857F22-5223-45A5-8A3A-E184431B59A8@amazon.com> <61F3E89F-8B2E-47B2-BAB4-915967FC0C8E@amazon.com> Message-ID: Ping for another review pls. Thanks, Paul ?On 11/18/19, 3:40 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Lgtm, but would another reviewer also take a look please? Thanks, Paul On 11/8/19, 11:39 AM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi, Requesting review for backport of JDK-8044500, JBS Issue : https://bugs.openjdk.java.net/browse/JDK-8044500 Original Change : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fb5752b152d9 Webrev : http://cr.openjdk.java.net/~alvdavi/webrevs/8044500/webrev.8u.00/ This is backport is a dependency for backporting JDK-8186576. Parts of this backport have already been backported into JDK-8044500. The patch did not apply cleanly and the major difference were * Variable name changes in KDC.java * Imports in Config.java Both Tier1 and Tier2 tests in Linux x64. Regards, Clive Verghese From hohensee at amazon.com Mon Dec 2 22:34:18 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 2 Dec 2019 22:34:18 +0000 Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent In-Reply-To: References: <5CCC5140-4C75-45CD-A3A2-CC0237DD7AD9@azul.com> <7B2B9DF5-F845-42FC-949C-102B72282975@amazon.com> Message-ID: <7609F5A2-F3CB-41F2-A4A6-8B54A8F9F667@amazon.com> +1. Paul ?On 10/31/19, 4:11 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: Hi Vladimir, the patch looks good to me. --yan On 28.10.2019 12:20, Vladimir Kempik wrote: > Hello > Can anyone please take a look at this patch? > The difference between 11 and 8 is pretty simple: move one method from superclass to subclass to prevent it being compiled on every Unix system(it can?t be compiled on solaris). This code is only used on Linux so far. > > Thanks, Vladimir > > 21 ???. 2019 ?., ? 19:23, Hohensee, Paul > ???????(?): > > +jdk8u-dev > > Paul > > From: nio-dev > on behalf of Vladimir Kempik > > Date: Monday, October 21, 2019 at 2:47 AM > To: "nio-dev at openjdk.java.net" > > Subject: RFR(8u): 8229872: (fs) Increase buffer size used with getmntent > > Hello > > Please review backport of https://bugs.openjdk.java.net/browse/JDK-8229872 to 8u: > http://cr.openjdk.java.net/~vkempik/8229872/ojdk8/webrev.00/ > > Difference between 14/13/11 fix: getline is missing on solaris10, so getlinelen method was moved from UnixNativeDispatcher to LinuxNativeDispatcher. > Original fix: https://hg.openjdk.java.net/jdk/jdk/rev/2d40e6a7ce8e > > Such fix was already included into azul?s october psu for openjdk8 and passed all release cycle tests. > > Thanks, Vladimir > From felix.yang at huawei.com Tue Dec 3 06:11:08 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 3 Dec 2019 06:11:08 +0000 Subject: [8u] RFR 8167409: Invalid value passed to critical JNI function Message-ID: Hi, Please review 8u backport of 8167409. Original bug: https://bugs.openjdk.java.net/browse/JDK-8167409 http://hg.openjdk.java.net/jdk/jdk/rev/11b8ac93804c Original patch does not apply cleanly to 8u due to path differences and missing file. 8u webrev: http://cr.openjdk.java.net/~fyang/8167409-8u-backport/webrev.00/ This updated copyright years for files changed or added. Also added one shell script Test8167409.sh to run the newly added test case in the original patch. Testing: Run full jtreg test with a x86-64 release build. Newly add test case fail without the patch and pass with the patch. Thanks, Felix From yan at azul.com Tue Dec 3 06:23:35 2019 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 3 Dec 2019 09:23:35 +0300 Subject: JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u In-Reply-To: <9160426E-1AA8-49E8-ADFF-CBA00AA3778B@amazon.com> References: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> <045CB7FE-AA43-4EF7-89B7-38C81EA1A837@amazon.com> <9160426E-1AA8-49E8-ADFF-CBA00AA3778B@amazon.com> Message-ID: Great! Thank you Paul! --yan On 02.12.2019 22:48, Hohensee, Paul wrote: > There's been no response on 2d-dev, so I'm ok with going ahead with this. > > Paul > > ?On 10/8/19, 2:55 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > This looks reasonable to me based on prr's description, but I've got almost no experience in this area. I'd cross-post to 2d-dev to see what they think. They might be interested in your regression tests. > > Paul > > On 10/7/19, 5:28 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: > > Hi all, > > could you please review this downport of > https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? > > Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ > > There is a single digit change discovered by prr and a couple of > regression tests: > > one verifies that required shaping works as expected and another -- that > there's no obvious regression for JDK-8201801 > > > Thank you! > > --yan > > > > > > > From yan at azul.com Tue Dec 3 06:26:32 2019 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 3 Dec 2019 09:26:32 +0300 Subject: RFR: JDK-8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u In-Reply-To: <9bf2f259-020a-c165-a329-8943b07d2f11@redhat.com> References: <878c78ef-d14b-51f8-acff-d060143eef56@azul.com> <9bf2f259-020a-c165-a329-8943b07d2f11@redhat.com> Message-ID: <4c7181a9-1b44-e624-3709-89d84e756cce@azul.com> Thank you Simon! Sure the comprehensive testing is always good. --yan On 02.12.2019 19:44, Simon Tooke wrote: > (disclaimer: I am not a reviewer) > > I did test Yuri's fix on macOS Catalina 10.5.1 / XCode 11.2.1, and it > did fix the issue (which I reproduced) and the two included > regressions tests passed.? The patch applied cleanly on 8u242-b01. > > I have not yet run the full regression suite, so I don't know if there > are any regressions. > > -Simon > > > On 2019-10-07 8:25 a.m., Yuri Nesterenko wrote: >> Hi all, >> >> could you please review this downport of >> https://bugs.openjdk.java.net/browse/JDK-8215210 to openjdk 8u? >> >> Link to webrev: http://cr.openjdk.java.net/~yan/8215210/webrev.0/ >> >> There is a single digit change discovered by prr and a couple of >> regression tests: >> >> one verifies that required shaping works as expected and another -- that >> there's no obvious regression for JDK-8201801 >> >> >> Thank you! >> >> --yan >> >> >> From ygaevsky at azul.com Tue Dec 3 12:01:11 2019 From: ygaevsky at azul.com (Yuri Gaevsky) Date: Tue, 3 Dec 2019 12:01:11 +0000 Subject: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" In-Reply-To: <1BDBEDB9-4761-457C-9DDE-73C5AFE53C81@amazon.com> References: <990e8a14c8f6442bb4225d3b9b0f1eec@azul.com> <23a785bdd5604f33b2b2c1fb54ea3547@azul.com> <8791ec11a0134598b7e7d40b9e46ba1a@azul.com> <063b04c4-23ad-6dcf-0bfc-aaaa4a2f66a4@redhat.com> <1BDBEDB9-4761-457C-9DDE-73C5AFE53C81@amazon.com> Message-ID: Thank you very much, Paul. -Yuri -----Original Message----- From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: Monday, December 2, 2019 09:59 PM To: Martin Balao ; jdk8u-dev at openjdk.java.net; Yuri Gaevsky Subject: Re: Request for approval: JDK-8130341 "GHASH 32bit intrinsics has AEADBadTagException" Hi, Martin, Yuri isn't a Committer (he's a jdk9 Author), so can't push. I took the liberty of pushing it for him. https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/e55d4d896e30 Thanks, Paul ?On 12/2/19, 8:45 AM, "jdk8u-dev on behalf of Martin Balao" wrote: Hi Yuri, Now that 8073108 has been integrated into the 8u-dev repository [1] [2], and considering that your proposal for a 8u backport of 8130341 has been reviewed and approved, can you please push it? Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/44ef77ad417c [2] - http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/168c73fb6713 From gnu.andrew at redhat.com Tue Dec 3 22:55:53 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 3 Dec 2019 17:55:53 -0500 Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len In-Reply-To: References: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com> <260788c0-207d-8cfd-5492-8750d02e42d7@redhat.com> Message-ID: <30c915b2-2147-81ba-e7a4-f33b8da8fe46@redhat.com> On 06/11/2019 18:07, Hohensee, Paul wrote: > I found http://jperfanal.sourceforge.net/java.hprof.txt, which is a thread stack dump that references 1.0.1, is dated Dec 30, 2001, and the dump output is copyright 1998. So 1.0.1 is probably from 1998. > > I found a file format spec at http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/tip/src/share/demo/jvmti/hprof/manual.html#mozTocId848088. It's from Java 6, so 1.0.2 was supported then. I also found > > https://bugs.openjdk.java.net/browse/JDK-6305542: HPROF binary format needs to support large dumps > > for Java 6, and > > https://bugs.openjdk.java.net/browse/JDK-6313381: HPROF: agent should generate version 1.0.2 for large heaps > > which updated the hprof agent to generate 1.0.2 format files for heaps > 4gb in Java 6, and > > https://bugs.openjdk.java.net/browse/JDK-6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" > > which was shipped in 8u25 in 2014. > > So, JDKs/JREs starting with Java 6 can read 1.0.2 files, and the SA can read them starting with 8u25. I don't think we need to worry about using Java 5 to read files generated by Java 8, and the SA is good to go for 8. > > Paul > Thanks for the through research. My concern is not so much whether the format can be read, as whether it is expected on small heap dumps. JDK-6313383 also says "For compatibility it would be best if jmap continued to generate a 1.0.1 format for smaller heaps (<2GB for example).". I think this may warrant a CSR. 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 From hohensee at amazon.com Tue Dec 3 23:40:40 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 3 Dec 2019 23:40:40 +0000 Subject: [8u] RFR backport of JDK-8144732: VM_HeapDumper hits assert with bad dump_len In-Reply-To: <30c915b2-2147-81ba-e7a4-f33b8da8fe46@redhat.com> References: <78672c52-2587-4e01-98d9-350c9239fe48.denghui.ddh@alibaba-inc.com> <260788c0-207d-8cfd-5492-8750d02e42d7@redhat.com> <30c915b2-2147-81ba-e7a4-f33b8da8fe46@redhat.com> Message-ID: Thanks, Andrew. I've filed https://bugs.openjdk.java.net/browse/JDK-8235299 for the backport issue and https://bugs.openjdk.java.net/browse/JDK-8235299 for the associated CSR and assigned both to Denghui. Paul ?On 12/3/19, 2:57 PM, "Andrew Hughes" wrote: On 06/11/2019 18:07, Hohensee, Paul wrote: > I found http://jperfanal.sourceforge.net/java.hprof.txt, which is a thread stack dump that references 1.0.1, is dated Dec 30, 2001, and the dump output is copyright 1998. So 1.0.1 is probably from 1998. > > I found a file format spec at http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/tip/src/share/demo/jvmti/hprof/manual.html#mozTocId848088. It's from Java 6, so 1.0.2 was supported then. I also found > > https://bugs.openjdk.java.net/browse/JDK-6305542: HPROF binary format needs to support large dumps > > for Java 6, and > > https://bugs.openjdk.java.net/browse/JDK-6313381: HPROF: agent should generate version 1.0.2 for large heaps > > which updated the hprof agent to generate 1.0.2 format files for heaps > 4gb in Java 6, and > > https://bugs.openjdk.java.net/browse/JDK-6313383: SA: Update jmap to support HPROF binary format "JAVA PROFILE 1.0.2" > > which was shipped in 8u25 in 2014. > > So, JDKs/JREs starting with Java 6 can read 1.0.2 files, and the SA can read them starting with 8u25. I don't think we need to worry about using Java 5 to read files generated by Java 8, and the SA is good to go for 8. > > Paul > Thanks for the through research. My concern is not so much whether the format can be read, as whether it is expected on small heap dumps. JDK-6313383 also says "For compatibility it would be best if jmap continued to generate a 1.0.1 format for smaller heaps (<2GB for example).". I think this may warrant a CSR. 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 From kshefov at azul.com Wed Dec 4 11:54:17 2019 From: kshefov at azul.com (Konstantin Shefov) Date: Wed, 4 Dec 2019 11:54:17 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> Message-ID: Dear OpenJDK 8 Updates' maintainers! I am writing here to ask you to pay attention to this thread. This is a backport of VmTestbase tests from JDK 14 to JDK 8u (https://bugs.openjdk.java.net/browse/JDK-8231089). Could you take a look and write your opinion? This patch is quite a big one (adds 15 000 files to hotspot repo), but all changes are in "test" part, not VM source. The tests will be placed in a separate group in hotspot/test/TEST.groups file, so they will be run only when explicitly called. Thanks Konstantin -----Original Message----- From: jdk8u-dev On Behalf Of Liu, Xin Sent: Monday, October 14, 2019 9:55 PM To: jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hello, Reviewers, May I have attention for thread? I have separated the jumbo vmTestbase to 1+7 patches. This patch is the entrypoint in root project. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ This patch is just vmTestbase blob from jdk14+14. https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. Thanks, --lx ?On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: Hi, Konstantin, Yes, it makes sense. I prepare a webrev and include it your change. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ Can we at least push it first? Thanks, --lx On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: Hello In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: diff -r 31d7a6f35834 make/Main.gmk --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 @@ -168,10 +168,10 @@ @$(call TargetExit) test-image: start-make @$(call TargetEnter) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) @$(call TargetExit) Konstantin On 07/10/2019, 13:10, "Konstantin Shefov" wrote: Hi. Liu Xin Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. Konstantin On 07/10/2019, 10:07, "Liu, Xin" wrote: Hi, Konstantin and other reviewers, I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. $hg qapplied base updateAPIs classFileInstaller gclog nativeLibraries azul_contrib1 azul_contrib2 Could you review my changes? I didn't generate webrev because they are huge. https://cr.openjdk.java.net/~xliu/8231089/ @Konstantin, I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. I have some comments for your patches. 1) previously, you have deleted all @module. Eg. /* * @test - * @modules java.base/jdk.internal.misc:+open * @key stress gc * * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] * - * @modules java.base/jdk.internal.misc * @library /vmTestbase * /testlibrary * /test/lib @@ -40,7 +38,6 @@ * @comment generate HumongousTemplateClass and compile it to test.classes * @run driver gc.g1.unloading.bytecode.GenClassesBuilder * - * @requires vm.gc.G1 I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. 2. has you solved this issue? https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. Thanks, --lx On 9/26/19, 4:52 AM, "Konstantin Shefov" wrote: Hi, Liu Xin I have to change my previous answer about Platform.java. We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. The reasons are: 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. Regards, Konstantin -----Original Message----- From: Konstantin Shefov Sent: Thursday, September 26, 2019 12:52 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hello I have no objections against removing Platform.java and using the existing one. Konstantin -----Original Message----- From: Liu, Xin Sent: Thursday, September 26, 2019 2:24 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, I think you can also remove Platform.java in test/lib/jdk/test. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch and change vmProps.java refer to jdk.testlibrary.Platform. https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html It's because jdk.testlibrary.Platform is superset of the delete one. Thanks, --lx On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: Hi Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. The list of changes is the following: 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". With all changes provided by Liu Xin and the patch provided here we think it can be pushed. Thanks, --Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 6:30 PM To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin After applying all the patches, I have successfully built the native part, but I had to do some more changes. After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. Konstantin -----Original Message----- From: Konstantin Shefov Sent: Monday, September 23, 2019 4:47 PM To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. Java class file format has changed between JDK 8 and JDK 11+. In earlyretint.c from JDK 11+ we have the following line: "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). That is why we have to change the test here. [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation Regards, Konstantin -----Original Message----- From: Liu, Xin Sent: Monday, September 23, 2019 10:13 AM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? hi, Konstantin, I also apply your patch to the last webrev. eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ We should apply them in order. 1. base 2. apiChanges 3. classFileInstaller 4. gclog 5. native_libraries 6. azul_contrib for your patch, i keep it everything except for -Xloggc. Could you tell me why you modify from 0x21 to 0x2e? diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 @@ -89,7 +89,7 @@ jlocation loc, jint i) { jvmtiError err; jclass cls; - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; char *sigClass, *name, *sig, *generic; jvmtiLocalVariableEntry *table = NULL; jint entryCount = 0; ________________________________________ From: jdk8u-dev on behalf of Liu, Xin Sent: Saturday, September 21, 2019 4:48 AM To: Konstantin Shefov; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, As I promised, here is the refactored webrev for native compilation Hotspot: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ root: https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ so the new target 'test-image' is added. to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. Thanks, --lx From: Konstantin Shefov Date: Friday, September 20, 2019 at 11:01 AM To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, Liu Xin > I am refactoring makefiles. I plan to upload this webrev today. Fine! We will try to compile with our toolchains. >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? One example is this https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 Konstantin From: Liu, Xin Sent: Friday, September 20, 2019 8:35 PM To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Konstantin, I am refactoring makefiles. I plan to upload this webrev today. I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. Could you give me an example tests for this? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 20, 2019 at 2:26 AM To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We will use your new patches to run tests and merge my changes with yours for those tests that will not work. BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. Regards Konstantin From: "Liu, Xin" > Date: Wednesday, 18 September 2019 at 20:59 To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, thank you for updating. We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? Back to refactor, I have filed a JBS issues. https://bugs.openjdk.java.net/browse/JDK-8231089 In the meanwhile, I start splitting the commits to individual hg changesets. https://cr.openjdk.java.net/~xliu/8231089/ 1. base -> copy code from tag jdk-14+14 intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do f=${i%\:} gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f done What do you think that this approach? If I got something wrong, we can update the webtrev with yours. thanks, --lx ________________________________ From: Konstantin Shefov > Sent: Wednesday, September 18, 2019 4:56 PM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: vmTestbase/gc/lock/jni/jnilock002/TestDescription.java vmTestbase/nsk/jdb/set/set001/set001.java Konstantin From: Konstantin Shefov Sent: Wednesday, September 11, 2019 10:53 AM To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net Subject: RE: Backport vmTestbase tests to jdk8u-dev? Hi, LX Answering to your e-mail, as for what we modified in [3]: 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. I agree that there should be a series of patches to track file changes. As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. Konstantin From: Liu, Xin > Sent: Monday, September 9, 2019 11:04 PM To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, Konstantin, We are glad to work with you to get vmTestbase landed into jdk8u. Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. Back to the webrev you send. What did you modify in [3]? Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? Thanks, --lx From: Konstantin Shefov > Date: Friday, September 6, 2019 at 12:55 PM To: "jdk8u-dev at openjdk.java.net" > Cc: "Liu, Xin" > Subject: Re: Backport vmTestbase tests to jdk8u-dev? Hi, We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: 1. 3371 tests PASS (see [1]); 2. 179 tests FAIL (see [2]): reasons are being investigated. Patches we have used (contain our refactoring): 1. Hotspot folder [3] 2. Main folder [4] We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: 1. 332 test have been removed in JDK 13; 2. Only 2 test have been added in JDK 13; 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch Regards, --Konstantin From yan at azul.com Wed Dec 4 12:28:46 2019 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 4 Dec 2019 15:28:46 +0300 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> Message-ID: Hi, Liu Xin, Konstantin, as we already have and use it in Zulu, I only can say: great job. +1, list me as a reviewer. Thank you, --yan On 04.12.2019 14:54, Konstantin Shefov wrote: > Dear OpenJDK 8 Updates' maintainers! > > I am writing here to ask you to pay attention to this thread. > This is a backport of VmTestbase tests from JDK 14 to JDK 8u (https://bugs.openjdk.java.net/browse/JDK-8231089). > > Could you take a look and write your opinion? > > This patch is quite a big one (adds 15 000 files to hotspot repo), but all changes are in "test" part, not VM source. > The tests will be placed in a separate group in hotspot/test/TEST.groups file, so they will be run only when explicitly called. > > Thanks > Konstantin > > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu, Xin > Sent: Monday, October 14, 2019 9:55 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hello, Reviewers, > > May I have attention for thread? > I have separated the jumbo vmTestbase to 1+7 patches. > This patch is the entrypoint in root project. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > This patch is just vmTestbase blob from jdk14+14. > https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz > > If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. > Thanks, > --lx > > > ?On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: > > Hi, Konstantin, > > Yes, it makes sense. I prepare a webrev and include it your change. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > Can we at least push it first? > Thanks, > --lx > > On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: > > Hello > > In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: > > diff -r 31d7a6f35834 make/Main.gmk > --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 > +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 > @@ -168,10 +168,10 @@ > @$(call TargetExit) > test-image: start-make > @$(call TargetEnter) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) > @$(call TargetExit) > > Konstantin > > On 07/10/2019, 13:10, "Konstantin Shefov" wrote: > > Hi. Liu Xin > > Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. > > As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. > > Konstantin > > > On 07/10/2019, 10:07, "Liu, Xin" wrote: > > Hi, Konstantin and other reviewers, > > I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. > > > $hg qapplied > base > updateAPIs > classFileInstaller > gclog > nativeLibraries > azul_contrib1 > azul_contrib2 > > Could you review my changes? I didn't generate webrev because they are huge. > https://cr.openjdk.java.net/~xliu/8231089/ > > @Konstantin, > > I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. > I have some comments for your patches. > 1) previously, you have deleted all @module. Eg. > /* > * @test > - * @modules java.base/jdk.internal.misc:+open > * @key stress gc > * > * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. > * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] > * > - * @modules java.base/jdk.internal.misc > * @library /vmTestbase > * /testlibrary > * /test/lib > @@ -40,7 +38,6 @@ > * @comment generate HumongousTemplateClass and compile it to test.classes > * @run driver gc.g1.unloading.bytecode.GenClassesBuilder > * > - * @requires vm.gc.G1 > > I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. > It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. > > 2. has you solved this issue? > https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 > I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. > > > Thanks, > --lx > > On 9/26/19, 4:52 AM, "Konstantin Shefov" wrote: > > Hi, Liu Xin > > I have to change my previous answer about Platform.java. > We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. > > The reasons are: > 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. > 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. > 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. > > So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. > > The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. > > Regards, > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Thursday, September 26, 2019 12:52 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hello > > I have no objections against removing Platform.java and using the existing one. > > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Thursday, September 26, 2019 2:24 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > I think you can also remove Platform.java in test/lib/jdk/test. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch > and change vmProps.java refer to jdk.testlibrary.Platform. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html > > It's because jdk.testlibrary.Platform is superset of the delete one. > Thanks, > --lx > > On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: > > Hi > > Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ > > This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. > > The list of changes is the following: > 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); > 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); > 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; > 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". > > With all changes provided by Liu Xin and the patch provided here we think it can be pushed. > > Thanks, > --Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 6:30 PM > To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > After applying all the patches, I have successfully built the native part, but I had to do some more changes. > After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. > > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 4:47 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. > > As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. > Java class file format has changed between JDK 8 and JDK 11+. > In earlyretint.c from JDK 11+ we have the following line: > > "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " > > This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). > By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. > In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). > In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). > That is why we have to change the test here. > > [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep > [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation > > Regards, > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Monday, September 23, 2019 10:13 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > hi, Konstantin, > > I also apply your patch to the last webrev. > > eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ > > We should apply them in order. > 1. base > 2. apiChanges > 3. classFileInstaller > 4. gclog > 5. native_libraries > 6. azul_contrib > > for your patch, i keep it everything except for -Xloggc. > Could you tell me why you modify from 0x21 to 0x2e? > diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c > --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 > +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 > @@ -89,7 +89,7 @@ > jlocation loc, jint i) { > jvmtiError err; > jclass cls; > - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; > + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; > char *sigClass, *name, *sig, *generic; > jvmtiLocalVariableEntry *table = NULL; > jint entryCount = 0; > > ________________________________________ > From: jdk8u-dev on behalf of Liu, Xin > Sent: Saturday, September 21, 2019 4:48 AM > To: Konstantin Shefov; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > As I promised, here is the refactored webrev for native compilation > > Hotspot: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ > root: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ > so the new target 'test-image' is added. > > to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, > I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. > > Thanks, > --lx > > > > > > > From: Konstantin Shefov > Date: Friday, September 20, 2019 at 11:01 AM > To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > > I am refactoring makefiles. I plan to upload this webrev today. > Fine! We will try to compile with our toolchains. > > >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > Could you give me an example tests for this? > > One example is this > https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 > > And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. > See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 > and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 > > Konstantin > > From: Liu, Xin > Sent: Friday, September 20, 2019 8:35 PM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Konstantin, > > I am refactoring makefiles. I plan to upload this webrev today. > > I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. > >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? > > Thanks, > --lx > > From: Konstantin Shefov > > Date: Friday, September 20, 2019 at 2:26 AM > To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We will use your new patches to run tests and merge my changes with yours for those tests that will not work. > > BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. > > Regards > Konstantin > > From: "Liu, Xin" > > Date: Wednesday, 18 September 2019 at 20:59 > To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > > Hi, Konstantin, > > > > thank you for updating. > > > > We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. > > Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? > > > > Back to refactor, I have filed a JBS issues. > > https://bugs.openjdk.java.net/browse/JDK-8231089 > > In the meanwhile, I start splitting the commits to individual hg changesets. > https://cr.openjdk.java.net/~xliu/8231089/ > > 1. base -> copy code from tag jdk-14+14 > intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? > > 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. > > out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do > f=${i%\:} > gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f > done > > > What do you think that this approach? > If I got something wrong, we can update the webtrev with yours. > > thanks, > --lx > > > ________________________________ > From: Konstantin Shefov > > Sent: Wednesday, September 18, 2019 4:56 PM > To: Liu, Xin; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi > > We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: > vmTestbase/gc/lock/jni/jnilock002/TestDescription.java > vmTestbase/nsk/jdb/set/set001/set001.java > > Konstantin > > > From: Konstantin Shefov > Sent: Wednesday, September 11, 2019 10:53 AM > To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, LX > > Answering to your e-mail, as for what we modified in [3]: > > 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; > 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. > > I agree that there should be a series of patches to track file changes. > > As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. > > Konstantin > > From: Liu, Xin > > Sent: Monday, September 9, 2019 11:04 PM > To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > We are glad to work with you to get vmTestbase landed into jdk8u. > Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. > > Back to the webrev you send. What did you modify in [3]? > Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. > In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? > > Thanks, > --lx > > > From: Konstantin Shefov > > Date: Friday, September 6, 2019 at 12:55 PM > To: "jdk8u-dev at openjdk.java.net" > > Cc: "Liu, Xin" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. > > We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. > > We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: > > 1. 3371 tests PASS (see [1]); > 2. 179 tests FAIL (see [2]): reasons are being investigated. > > Patches we have used (contain our refactoring): > > 1. Hotspot folder [3] > > 2. Main folder [4] > > We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. > > We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: > > 1. 332 test have been removed in JDK 13; > 2. Only 2 test have been added in JDK 13; > 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. > From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. > > [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html > [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html > [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch > [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch > > Regards, > --Konstantin > > > > > > > > > > > > > > From hohensee at amazon.com Wed Dec 4 16:13:59 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 4 Dec 2019 16:13:59 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> Message-ID: <835E4FA2-2080-4E64-80B4-BAAC8C8BF315@amazon.com> +1 from me as well. Thanks, Paul ?On 12/4/19, 4:29 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: Hi, Liu Xin, Konstantin, as we already have and use it in Zulu, I only can say: great job. +1, list me as a reviewer. Thank you, --yan On 04.12.2019 14:54, Konstantin Shefov wrote: > Dear OpenJDK 8 Updates' maintainers! > > I am writing here to ask you to pay attention to this thread. > This is a backport of VmTestbase tests from JDK 14 to JDK 8u (https://bugs.openjdk.java.net/browse/JDK-8231089). > > Could you take a look and write your opinion? > > This patch is quite a big one (adds 15 000 files to hotspot repo), but all changes are in "test" part, not VM source. > The tests will be placed in a separate group in hotspot/test/TEST.groups file, so they will be run only when explicitly called. > > Thanks > Konstantin > > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu, Xin > Sent: Monday, October 14, 2019 9:55 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hello, Reviewers, > > May I have attention for thread? > I have separated the jumbo vmTestbase to 1+7 patches. > This patch is the entrypoint in root project. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > This patch is just vmTestbase blob from jdk14+14. > https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz > > If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. > Thanks, > --lx > > > On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: > > Hi, Konstantin, > > Yes, it makes sense. I prepare a webrev and include it your change. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > Can we at least push it first? > Thanks, > --lx > > On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: > > Hello > > In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: > > diff -r 31d7a6f35834 make/Main.gmk > --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 > +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 > @@ -168,10 +168,10 @@ > @$(call TargetExit) > test-image: start-make > @$(call TargetEnter) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) > @$(call TargetExit) > > Konstantin > > On 07/10/2019, 13:10, "Konstantin Shefov" wrote: > > Hi. Liu Xin > > Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. > > As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. > > Konstantin > > > On 07/10/2019, 10:07, "Liu, Xin" wrote: > > Hi, Konstantin and other reviewers, > > I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. > > > $hg qapplied > base > updateAPIs > classFileInstaller > gclog > nativeLibraries > azul_contrib1 > azul_contrib2 > > Could you review my changes? I didn't generate webrev because they are huge. > https://cr.openjdk.java.net/~xliu/8231089/ > > @Konstantin, > > I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. > I have some comments for your patches. > 1) previously, you have deleted all @module. Eg. > /* > * @test > - * @modules java.base/jdk.internal.misc:+open > * @key stress gc > * > * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. > * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] > * > - * @modules java.base/jdk.internal.misc > * @library /vmTestbase > * /testlibrary > * /test/lib > @@ -40,7 +38,6 @@ > * @comment generate HumongousTemplateClass and compile it to test.classes > * @run driver gc.g1.unloading.bytecode.GenClassesBuilder > * > - * @requires vm.gc.G1 > > I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. > It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. > > 2. has you solved this issue? > https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 > I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. > > > Thanks, > --lx > > On 9/26/19, 4:52 AM, "Konstantin Shefov" wrote: > > Hi, Liu Xin > > I have to change my previous answer about Platform.java. > We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. > > The reasons are: > 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. > 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. > 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. > > So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. > > The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. > > Regards, > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Thursday, September 26, 2019 12:52 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hello > > I have no objections against removing Platform.java and using the existing one. > > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Thursday, September 26, 2019 2:24 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > I think you can also remove Platform.java in test/lib/jdk/test. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch > and change vmProps.java refer to jdk.testlibrary.Platform. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html > > It's because jdk.testlibrary.Platform is superset of the delete one. > Thanks, > --lx > > On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: > > Hi > > Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ > > This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. > > The list of changes is the following: > 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); > 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); > 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; > 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". > > With all changes provided by Liu Xin and the patch provided here we think it can be pushed. > > Thanks, > --Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 6:30 PM > To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > After applying all the patches, I have successfully built the native part, but I had to do some more changes. > After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. > > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 4:47 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. > > As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. > Java class file format has changed between JDK 8 and JDK 11+. > In earlyretint.c from JDK 11+ we have the following line: > > "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " > > This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). > By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. > In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). > In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). > That is why we have to change the test here. > > [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep > [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation > > Regards, > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Monday, September 23, 2019 10:13 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > hi, Konstantin, > > I also apply your patch to the last webrev. > > eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ > > We should apply them in order. > 1. base > 2. apiChanges > 3. classFileInstaller > 4. gclog > 5. native_libraries > 6. azul_contrib > > for your patch, i keep it everything except for -Xloggc. > Could you tell me why you modify from 0x21 to 0x2e? > diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c > --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 > +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 > @@ -89,7 +89,7 @@ > jlocation loc, jint i) { > jvmtiError err; > jclass cls; > - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; > + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; > char *sigClass, *name, *sig, *generic; > jvmtiLocalVariableEntry *table = NULL; > jint entryCount = 0; > > ________________________________________ > From: jdk8u-dev on behalf of Liu, Xin > Sent: Saturday, September 21, 2019 4:48 AM > To: Konstantin Shefov; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > As I promised, here is the refactored webrev for native compilation > > Hotspot: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ > root: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ > so the new target 'test-image' is added. > > to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, > I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. > > Thanks, > --lx > > > > > > > From: Konstantin Shefov > Date: Friday, September 20, 2019 at 11:01 AM > To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > > I am refactoring makefiles. I plan to upload this webrev today. > Fine! We will try to compile with our toolchains. > > >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > Could you give me an example tests for this? > > One example is this > https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 > > And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. > See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 > and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 > > Konstantin > > From: Liu, Xin > Sent: Friday, September 20, 2019 8:35 PM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Konstantin, > > I am refactoring makefiles. I plan to upload this webrev today. > > I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. > >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? > > Thanks, > --lx > > From: Konstantin Shefov > > Date: Friday, September 20, 2019 at 2:26 AM > To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We will use your new patches to run tests and merge my changes with yours for those tests that will not work. > > BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. > > Regards > Konstantin > > From: "Liu, Xin" > > Date: Wednesday, 18 September 2019 at 20:59 > To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > > Hi, Konstantin, > > > > thank you for updating. > > > > We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. > > Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? > > > > Back to refactor, I have filed a JBS issues. > > https://bugs.openjdk.java.net/browse/JDK-8231089 > > In the meanwhile, I start splitting the commits to individual hg changesets. > https://cr.openjdk.java.net/~xliu/8231089/ > > 1. base -> copy code from tag jdk-14+14 > intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? > > 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. > > out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do > f=${i%\:} > gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f > done > > > What do you think that this approach? > If I got something wrong, we can update the webtrev with yours. > > thanks, > --lx > > > ________________________________ > From: Konstantin Shefov > > Sent: Wednesday, September 18, 2019 4:56 PM > To: Liu, Xin; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi > > We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: > vmTestbase/gc/lock/jni/jnilock002/TestDescription.java > vmTestbase/nsk/jdb/set/set001/set001.java > > Konstantin > > > From: Konstantin Shefov > Sent: Wednesday, September 11, 2019 10:53 AM > To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, LX > > Answering to your e-mail, as for what we modified in [3]: > > 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; > 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. > > I agree that there should be a series of patches to track file changes. > > As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. > > Konstantin > > From: Liu, Xin > > Sent: Monday, September 9, 2019 11:04 PM > To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > We are glad to work with you to get vmTestbase landed into jdk8u. > Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. > > Back to the webrev you send. What did you modify in [3]? > Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. > In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? > > Thanks, > --lx > > > From: Konstantin Shefov > > Date: Friday, September 6, 2019 at 12:55 PM > To: "jdk8u-dev at openjdk.java.net" > > Cc: "Liu, Xin" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. > > We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. > > We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: > > 1. 3371 tests PASS (see [1]); > 2. 179 tests FAIL (see [2]): reasons are being investigated. > > Patches we have used (contain our refactoring): > > 1. Hotspot folder [3] > > 2. Main folder [4] > > We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. > > We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: > > 1. 332 test have been removed in JDK 13; > 2. Only 2 test have been added in JDK 13; > 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. > From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. > > [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html > [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html > [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch > [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch > > Regards, > --Konstantin > > > > > > > > > > > > > > From gnu.andrew at redhat.com Wed Dec 4 16:56:39 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 4 Dec 2019 11:56:39 -0500 Subject: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value In-Reply-To: <17BE74B3-7CD5-4441-83F4-22EF3C210ED7@amazon.com> References: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.> <8025BB5B-2F5D-42F2-A075-FB30782E4205@amazon.com> <17BE74B3-7CD5-4441-83F4-22EF3C210ED7@amazon.com> Message-ID: <49d8e237-66a3-d58f-5cad-3ff6b2f4f4a5@redhat.com> On 27/11/2019 11:02, Hohensee, Paul wrote: > I?d be happy to, but https://bugs.openjdk.java.net/browse/JDK-8156028 must be tagged with ?jdk8u-fix-yes? before I can do so. > > Paul > Approved. It would help if the fix request on the bug noted the status of the review e.g. "Patch does not apply cleanly. Successfully reviewed here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010667.html" Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed Dec 4 17:00:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 04 Dec 2019 18:00:21 +0100 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> Message-ID: <379caf1c9ca9a9ff55a44983c0dd40d255c72e2a.camel@redhat.com> Hi, On Wed, 2019-12-04 at 11:54 +0000, Konstantin Shefov wrote: > Dear OpenJDK 8 Updates' maintainers! > > I am writing here to ask you to pay attention to this thread. > This is a backport of VmTestbase tests from JDK 14 to JDK 8u (https://bugs.openjdk.java.net/browse/JDK-8231089). > > Could you take a look and write your opinion? We are supportive of this backport. > This patch is quite a big one (adds 15 000 files to hotspot repo), but all changes are in "test" part, not VM source. > The tests will be placed in a separate group in hotspot/test/TEST.groups file, so they will be run only when explicitly called. Yes, timing of getting this integrated is going to be important. For 8u242 (which is already in rampdown) it's too late. We suggest to get this in early in the 8u252 cycle which is going to be tagged soon. I'll ping this thread as soon as it's ready for integration and approved. Thanks, Severin > Thanks > Konstantin > > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu, Xin > Sent: Monday, October 14, 2019 9:55 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hello, Reviewers, > > May I have attention for thread? > I have separated the jumbo vmTestbase to 1+7 patches. > This patch is the entrypoint in root project. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > This patch is just vmTestbase blob from jdk14+14. > https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz > > If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. > Thanks, > --lx > > > ?On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: > > Hi, Konstantin, > > Yes, it makes sense. I prepare a webrev and include it your change. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > Can we at least push it first? > Thanks, > --lx > > On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: > > Hello > > In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: > > diff -r 31d7a6f35834 make/Main.gmk > --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 > +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 > @@ -168,10 +168,10 @@ > @$(call TargetExit) > test-image: start-make > @$(call TargetEnter) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) > @$(call TargetExit) > > Konstantin > > On 07/10/2019, 13:10, "Konstantin Shefov" wrote: > > Hi. Liu Xin > > Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. > > As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. > > Konstantin > > > On 07/10/2019, 10:07, "Liu, Xin" wrote: > > Hi, Konstantin and other reviewers, > > I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. > > > $hg qapplied > base > updateAPIs > classFileInstaller > gclog > nativeLibraries > azul_contrib1 > azul_contrib2 > > Could you review my changes? I didn't generate webrev because they are huge. > https://cr.openjdk.java.net/~xliu/8231089/ > > @Konstantin, > > I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. > I have some comments for your patches. > 1) previously, you have deleted all @module. Eg. > /* > * @test > - * @modules java.base/jdk.internal.misc:+open > * @key stress gc > * > * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. > * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] > * > - * @modules java.base/jdk.internal.misc > * @library /vmTestbase > * /testlibrary > * /test/lib > @@ -40,7 +38,6 @@ > * @comment generate HumongousTemplateClass and compile it to test.classes > * @run driver gc.g1.unloading.bytecode.GenClassesBuilder > * > - * @requires vm.gc.G1 > > I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. > It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. > > 2. has you solved this issue? > https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 > I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. > > > Thanks, > --lx > > On 9/26/19, 4:52 AM, "Konstantin Shefov" wrote: > > Hi, Liu Xin > > I have to change my previous answer about Platform.java. > We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. > > The reasons are: > 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. > 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. > 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. > > So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. > > The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. > > Regards, > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Thursday, September 26, 2019 12:52 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hello > > I have no objections against removing Platform.java and using the existing one. > > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Thursday, September 26, 2019 2:24 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > I think you can also remove Platform.java in test/lib/jdk/test. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch > and change vmProps.java refer to jdk.testlibrary.Platform. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html > > It's because jdk.testlibrary.Platform is superset of the delete one. > Thanks, > --lx > > On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: > > Hi > > Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ > > This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. > > The list of changes is the following: > 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); > 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); > 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; > 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". > > With all changes provided by Liu Xin and the patch provided here we think it can be pushed. > > Thanks, > --Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 6:30 PM > To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > After applying all the patches, I have successfully built the native part, but I had to do some more changes. > After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. > > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 4:47 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. > > As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. > Java class file format has changed between JDK 8 and JDK 11+. > In earlyretint.c from JDK 11+ we have the following line: > > "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " > > This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). > By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. > In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). > In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). > That is why we have to change the test here. > > [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep > [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation > > Regards, > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Monday, September 23, 2019 10:13 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > hi, Konstantin, > > I also apply your patch to the last webrev. > > eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ > > We should apply them in order. > 1. base > 2. apiChanges > 3. classFileInstaller > 4. gclog > 5. native_libraries > 6. azul_contrib > > for your patch, i keep it everything except for -Xloggc. > Could you tell me why you modify from 0x21 to 0x2e? > diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c > --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 > +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 > @@ -89,7 +89,7 @@ > jlocation loc, jint i) { > jvmtiError err; > jclass cls; > - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; > + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; > char *sigClass, *name, *sig, *generic; > jvmtiLocalVariableEntry *table = NULL; > jint entryCount = 0; > > ________________________________________ > From: jdk8u-dev on behalf of Liu, Xin > Sent: Saturday, September 21, 2019 4:48 AM > To: Konstantin Shefov; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > As I promised, here is the refactored webrev for native compilation > > Hotspot: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ > root: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ > so the new target 'test-image' is added. > > to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, > I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. > > Thanks, > --lx > > > > > > > From: Konstantin Shefov > Date: Friday, September 20, 2019 at 11:01 AM > To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > > I am refactoring makefiles. I plan to upload this webrev today. > Fine! We will try to compile with our toolchains. > > >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > Could you give me an example tests for this? > > One example is this > https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 > > And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. > See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 > and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 > > Konstantin > > From: Liu, Xin > Sent: Friday, September 20, 2019 8:35 PM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Konstantin, > > I am refactoring makefiles. I plan to upload this webrev today. > > I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. > >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? > > Thanks, > --lx > > From: Konstantin Shefov > > Date: Friday, September 20, 2019 at 2:26 AM > To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We will use your new patches to run tests and merge my changes with yours for those tests that will not work. > > BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. > > Regards > Konstantin > > From: "Liu, Xin" > > Date: Wednesday, 18 September 2019 at 20:59 > To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > > Hi, Konstantin, > > > > thank you for updating. > > > > We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. > > Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? > > > > Back to refactor, I have filed a JBS issues. > > https://bugs.openjdk.java.net/browse/JDK-8231089 > > In the meanwhile, I start splitting the commits to individual hg changesets. > https://cr.openjdk.java.net/~xliu/8231089/ > > 1. base -> copy code from tag jdk-14+14 > intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? > > 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. > > out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do > f=${i%\:} > gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f > done > > > What do you think that this approach? > If I got something wrong, we can update the webtrev with yours. > > thanks, > --lx > > > ________________________________ > From: Konstantin Shefov > > Sent: Wednesday, September 18, 2019 4:56 PM > To: Liu, Xin; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi > > We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: > vmTestbase/gc/lock/jni/jnilock002/TestDescription.java > vmTestbase/nsk/jdb/set/set001/set001.java > > Konstantin > > > From: Konstantin Shefov > Sent: Wednesday, September 11, 2019 10:53 AM > To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, LX > > Answering to your e-mail, as for what we modified in [3]: > > 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; > 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. > > I agree that there should be a series of patches to track file changes. > > As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. > > Konstantin > > From: Liu, Xin > > Sent: Monday, September 9, 2019 11:04 PM > To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > We are glad to work with you to get vmTestbase landed into jdk8u. > Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. > > Back to the webrev you send. What did you modify in [3]? > Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. > In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? > > Thanks, > --lx > > > From: Konstantin Shefov > > Date: Friday, September 6, 2019 at 12:55 PM > To: "jdk8u-dev at openjdk.java.net" > > Cc: "Liu, Xin" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. > > We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. > > We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: > > 1. 3371 tests PASS (see [1]); > 2. 179 tests FAIL (see [2]): reasons are being investigated. > > Patches we have used (contain our refactoring): > > 1. Hotspot folder [3] > > 2. Main folder [4] > > We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. > > We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: > > 1. 332 test have been removed in JDK 13; > 2. Only 2 test have been added in JDK 13; > 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. > From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. > > [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html > [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html > [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch > [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch > > Regards, > --Konstantin > > > > > > > > > > > > > > From hohensee at amazon.com Wed Dec 4 17:11:32 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 4 Dec 2019 17:11:32 +0000 Subject: [8u] RFR for backport of 8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value In-Reply-To: <49d8e237-66a3-d58f-5cad-3ff6b2f4f4a5@redhat.com> References: <5a613f73-4325-4494-a36b-6b5a4dc8ec61.> <8025BB5B-2F5D-42F2-A075-FB30782E4205@amazon.com> <17BE74B3-7CD5-4441-83F4-22EF3C210ED7@amazon.com> <49d8e237-66a3-d58f-5cad-3ff6b2f4f4a5@redhat.com> Message-ID: <80DBDE00-7DF4-4A76-AD80-74BD93C4213B@amazon.com> Thanks for the approval. I'll update JBS issues as you recommend. Paul ?On 12/4/19, 8:57 AM, "Andrew Hughes" wrote: On 27/11/2019 11:02, Hohensee, Paul wrote: > I?d be happy to, but https://bugs.openjdk.java.net/browse/JDK-8156028 must be tagged with ?jdk8u-fix-yes? before I can do so. > > Paul > Approved. It would help if the fix request on the bug noted the status of the review e.g. "Patch does not apply cleanly. Successfully reviewed here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010667.html" Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Dec 4 19:13:27 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 4 Dec 2019 14:13:27 -0500 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> Message-ID: <65a1f09e-7fda-52fe-4bd3-c087f209ba20@redhat.com> On 29/08/2019 21:29, Guo, James wrote: > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8208715 > https://hg.openjdk.java.net/jdk/jdk/rev/41257a58a588 > > Original patch does not apply cleanly to 8u: > 1. java.base/unix doesn't exist. I had to move the change of java.base/unix/classes/java/lang/ProcessImpl.java > to solaris/classes/java/lang/UNIXProcess.java to make the patch work in Unix. > 2. Due to the conflict in test/java/lang/ProcessBuilder/Basic.java, I had to replace the testcase that checks > Process.waitFor(timeout, TimeUnit.MILLISECONDS) with the one in 12u[1] and add a millisElapsedSince(long startNanoTime) method for it. > > 8u webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8208715/webrev.8u.00/ > > Testing: x86_64 build, affected tests [2], tier1 > > Thanks, > James Guo > > [1] http://hg.openjdk.java.net/jdk/jdk/file/41257a58a588/test/jdk/java/lang/ProcessBuilder/Basic.java#l2410 > [2] https://bugs.openjdk.java.net/secure/attachment/78016/JI9056393.java > > > > Am I right in thinking that the additional test changes are from JDK-8029629? https://hg.openjdk.java.net/jdk/jdk/rev/8e5afc67dca87179 If so, that bug should be backported first. 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 From alvdavi at amazon.com Wed Dec 4 22:38:54 2019 From: alvdavi at amazon.com (David Alvarez) Date: Wed, 4 Dec 2019 14:38:54 -0800 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone Message-ID: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> Hi, I would like to request a backport of JDK-8223490. Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ The patch is marked as 8u241 but not yet in openjdk8u242. Patch did not apply cleanly, multiple modifications were required. jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry around and references to readdir64_r. We also don't have JDK-7153347 [2] which added multiple changes to the original findZoneInfoFile method. Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is possible these are not the only ones. This patch will be followed up by a backport of JDK-8231124 which is a follow up. I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've been able to test on an affected system, where ZoneId.systemDefault() was returning Zulu before the patch, and UTC after. Thanks, David -- [1] https://bugs.openjdk.java.net/browse/JDK-8202794 [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b [3] https://bugs.openjdk.java.net/browse/JDK-8214077 [4] https://bugs.openjdk.java.net/browse/JDK-8231124 From alvdavi at amazon.com Thu Dec 5 01:29:10 2019 From: alvdavi at amazon.com (David Alvarez) Date: Wed, 4 Dec 2019 17:29:10 -0800 Subject: [8u] [2/2] RFR backport of 8231124: Missing closedir call with JDK-8223490 Message-ID: <3aebd593-1b58-c9c7-8931-8860251ca7dd@amazon.com> Hi, Here is the review request for JDK-8231124, the follow up of JDK-8223490 [1], for which I've already sent an RFR [2] Bug: https://bugs.openjdk.java.net/browse/JDK-8231124 Original: https://hg.openjdk.java.net/jdk/jdk/rev/8a8e87e8a4fd Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8231124/webrev.8u.00/ Patch does not apply cleanly, but it still does the same as the original, ensure the check for popularZones happens before anything else. David -- [1] https://bugs.openjdk.java.net/browse/JDK-8223490 [2] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010719.html From yan at azul.com Thu Dec 5 09:41:47 2019 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 5 Dec 2019 12:41:47 +0300 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> Message-ID: Hi David, could you please consider a small change from https://bugs.openjdk.java.net/browse/JDK-8234591 ? It may be even more important for jdk8. Thanks, --yan On 05.12.2019 01:38, David Alvarez wrote: > Hi, > > I would like to request a backport of JDK-8223490. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 > Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 > Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ > > The patch is marked as 8u241 but not yet in openjdk8u242. > > Patch did not apply cleanly, multiple modifications were required. > > jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry > around and references to readdir64_r. We also don't have JDK-7153347 [2] > which added multiple changes to the original findZoneInfoFile method. > Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is > possible these are not the only ones. > > This patch will be followed up by a backport of JDK-8231124 which is a > follow up. > > I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've > been able to test on an affected system, where ZoneId.systemDefault() > was returning Zulu before the patch, and UTC after. > > Thanks, > > David > > -- > [1] https://bugs.openjdk.java.net/browse/JDK-8202794 > [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b > [3] https://bugs.openjdk.java.net/browse/JDK-8214077 > [4] https://bugs.openjdk.java.net/browse/JDK-8231124 > > > > From sreerama.naga at gmail.com Thu Dec 5 11:17:11 2019 From: sreerama.naga at gmail.com (brahmam) Date: Thu, 5 Dec 2019 16:47:11 +0530 Subject: Fwd: Seeing JNI exception in 8u232 jdk builds In-Reply-To: References: Message-ID: Hi Everyone, We are seeing the below exception during our application set up when using 8u232 alone, But it is working fine with previous version before 8u232. any idea please? 2019/12/05 16:40:45 | INFO | jvm 2 | [Dynamic-linking native method java.io.FileOutputStream.writeBytes ... JNI] 2019/12/05 16:40:45 | INFO | jvm 2 | java.lang.NullPointerException 2019/12/05 16:40:45 | INFO | jvm 2 | [Dynamic-linking native method java.lang.Throwable.getStackTraceDepth ... JNI] 2019/12/05 16:40:45 | INFO | jvm 2 | [Dynamic-linking native method java.lang.Throwable.getStackTraceElement ... JNI] 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarVerifier.processEntry(JarVerifier.java:303) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarVerifier.update(JarVerifier.java:230) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarFile.initializeVerifier(JarFile.java:383) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarFile.ensureInitialization(JarFile.java:612) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:69) 2019/12/05 16:40:45 | INFO | jvm 2 | at sun.misc.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:991) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader.defineClass(URLClassLoader.java:451) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader.access$100(URLClassLoader.java:74) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader$1.run(URLClassLoader.java:369) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader$1.run(URLClassLoader.java:363) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.security.AccessController.doPrivileged(Native Method) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader.findClass(URLClassLoader.java:362) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.lang.ClassLoader.loadClass(ClassLoader.java:418) 2019/12/05 16:40:45 | INFO | jvm 2 | at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.lang.ClassLoader.loadClass(ClassLoader.java:351) 2019/12/05 16:40:45 | INFO | jvm 2 | at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601) 2019/12/05 16:40:45 | INFO | jvm 2 | [Loaded java.util.IdentityHashMap$IdentityHashMapIterator from /opt/novell/sentinel/jdk/jre/lib/rt.jar] 2019/12/05 16:40:45 | INFO | jvm 2 | [Loaded java.util.IdentityHashMap$KeyIterator from /opt/novell/sentinel/jdk/jre/lib/rt.jar] -- Thanks & Regards, Sreeram From alvdavi at amazon.com Thu Dec 5 21:38:58 2019 From: alvdavi at amazon.com (David Alvarez) Date: Thu, 5 Dec 2019 13:38:58 -0800 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> Message-ID: Thanks for catching that one, being only in 11u and not in tip in flew under my radar. I will backport it to 8 too. David On 2019-12-05 01:41, Yuri Nesterenko wrote: > Hi David, > > could you please consider a small change from > > https://bugs.openjdk.java.net/browse/JDK-8234591 ? > It may be even more important for jdk8. > > Thanks, > --yan > > On 05.12.2019 01:38, David Alvarez wrote: >> Hi, >> >> I would like to request a backport of JDK-8223490. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 >> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 >> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ >> >> The patch is marked as 8u241 but not yet in openjdk8u242. >> >> Patch did not apply cleanly, multiple modifications were required. >> >> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry >> around and references to readdir64_r. We also don't have JDK-7153347 [2] >> which added multiple changes to the original findZoneInfoFile method. >> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is >> possible these are not the only ones. >> >> This patch will be followed up by a backport of JDK-8231124 which is a >> follow up. >> >> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've >> been able to test on an affected system, where ZoneId.systemDefault() >> was returning Zulu before the patch, and UTC after. >> >> Thanks, >> >> David >> >> -- >> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 >> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b >> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 >> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 >> >> >> >> > From alvdavi at amazon.com Thu Dec 5 21:54:24 2019 From: alvdavi at amazon.com (David Alvarez) Date: Thu, 5 Dec 2019 13:54:24 -0800 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> Message-ID: 8234591 was a clean backport. Once I get the review approval for 8223490, I'll ensure I'll add a comment when doing the jdk8u-fix-request so 8223490, 8231124 and 8234591 are all push together. I'll need a commiter to push the changes for me. For convenience, I have a copy of the 8u patch of 8234591 [1] David -- [1] http://cr.openjdk.java.net/~alvdavi/patches/8234591.8u.00.patch On 2019-12-05 13:38, David Alvarez wrote: > Thanks for catching that one, being only in 11u and not in tip in flew > under my radar. I will backport it to 8 too. > > David > > On 2019-12-05 01:41, Yuri Nesterenko wrote: >> Hi David, >> >> could you please consider a small change from >> >> https://bugs.openjdk.java.net/browse/JDK-8234591 ? >> It may be even more important for jdk8. >> >> Thanks, >> --yan >> >> On 05.12.2019 01:38, David Alvarez wrote: >>> Hi, >>> >>> I would like to request a backport of JDK-8223490. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 >>> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 >>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ >>> >>> The patch is marked as 8u241 but not yet in openjdk8u242. >>> >>> Patch did not apply cleanly, multiple modifications were required. >>> >>> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry >>> around and references to readdir64_r. We also don't have JDK-7153347 [2] >>> which added multiple changes to the original findZoneInfoFile method. >>> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is >>> possible these are not the only ones. >>> >>> This patch will be followed up by a backport of JDK-8231124 which is a >>> follow up. >>> >>> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've >>> been able to test on an affected system, where ZoneId.systemDefault() >>> was returning Zulu before the patch, and UTC after. >>> >>> Thanks, >>> >>> David >>> >>> -- >>> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 >>> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 >>> >>> >>> >>> >> From hohensee at amazon.com Thu Dec 5 22:54:19 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 5 Dec 2019 22:54:19 +0000 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> Message-ID: <43A6607D-32FC-4F63-9103-31F254666698@amazon.com> I'll push them for you. Paul ?On 12/5/19, 1:55 PM, "jdk8u-dev on behalf of David Alvarez" wrote: 8234591 was a clean backport. Once I get the review approval for 8223490, I'll ensure I'll add a comment when doing the jdk8u-fix-request so 8223490, 8231124 and 8234591 are all push together. I'll need a commiter to push the changes for me. For convenience, I have a copy of the 8u patch of 8234591 [1] David -- [1] http://cr.openjdk.java.net/~alvdavi/patches/8234591.8u.00.patch On 2019-12-05 13:38, David Alvarez wrote: > Thanks for catching that one, being only in 11u and not in tip in flew > under my radar. I will backport it to 8 too. > > David > > On 2019-12-05 01:41, Yuri Nesterenko wrote: >> Hi David, >> >> could you please consider a small change from >> >> https://bugs.openjdk.java.net/browse/JDK-8234591 ? >> It may be even more important for jdk8. >> >> Thanks, >> --yan >> >> On 05.12.2019 01:38, David Alvarez wrote: >>> Hi, >>> >>> I would like to request a backport of JDK-8223490. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 >>> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 >>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ >>> >>> The patch is marked as 8u241 but not yet in openjdk8u242. >>> >>> Patch did not apply cleanly, multiple modifications were required. >>> >>> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry >>> around and references to readdir64_r. We also don't have JDK-7153347 [2] >>> which added multiple changes to the original findZoneInfoFile method. >>> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is >>> possible these are not the only ones. >>> >>> This patch will be followed up by a backport of JDK-8231124 which is a >>> follow up. >>> >>> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've >>> been able to test on an affected system, where ZoneId.systemDefault() >>> was returning Zulu before the patch, and UTC after. >>> >>> Thanks, >>> >>> David >>> >>> -- >>> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 >>> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 >>> >>> >>> >>> >> From alvdavi at amazon.com Thu Dec 5 23:05:43 2019 From: alvdavi at amazon.com (David Alvarez) Date: Thu, 5 Dec 2019 15:05:43 -0800 Subject: [8u] RFR 8080462: Update SunPKCS11 provider with PKCS11 v2.40 support In-Reply-To: <0810bedd3dcfcfa4913c8f2bfb4e62b88e4d5daa.camel@redhat.com> References: <13bab2cf-8970-3cef-f435-a2e730c5adad@redhat.com> <0810bedd3dcfcfa4913c8f2bfb4e62b88e4d5daa.camel@redhat.com> Message-ID: <0900ef9b-f471-1a25-c9da-d7e54ec110a2@amazon.com> Also, we have 8228835 [1], fixing a memory leak introduced by 8080462. David -- [1] https://bugs.openjdk.java.net/browse/JDK-8228835 On 2019-11-29 02:56, Severin Gehwolf wrote: > Hi, > > On Tue, 2019-11-19 at 16:55 -0300, Martin Balao wrote: >> Hi, >> >> I'd like to request a review for the 8u backport of 8080462 [1]. >> >> Webrev.00: >> >> * >> http://cr.openjdk.java.net/~mbalao/webrevs/8080462/8080462.8u.jdk.webrev.00/ > > Since this backport broke 32-bit builds in jdk/jdk, could you please > also look at backporting JDK-8225695 to 8u, please? > > Thanks, > Severin > >> Differences from 11u patch [2]: >> >> * src/share/legal/pkcs11cryptotoken.md >> * Does not apply because "8169925: Organize licenses by module in >> source, JMOD file, and run-time image" [3] is not in 8u. >> >> * src/share/classes/sun/security/pkcs11/SunPKCS11.java >> * 6th and 11th hook do not apply cleanly because ECParameters location >> is "sun.security.ec.ECParameters" in 8u instead of >> "sun.security.util.ECParameters" >> * 8th hook does not apply cleanly because 8042967 [4] is not in 8u. >> >> * src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java >> * 5th hook does not apply cleanly because toString method uses a >> StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u). >> >> * src/share/classes/sun/security/pkcs11/wrapper/CK_RSA_PKCS_PSS_PARAMS.java >> * 1st hook does not apply cleanly because toString method uses a >> StringBuffer instead of a StringBuilder (8041679 [5] is not in 8u). >> >> * src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c >> * 13th hook does no apply cleanly because 8074580 [6] is not in 8u. >> Manually applied change. >> >> * src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c >> * Copyright date. >> >> * src/share/native/sun/security/pkcs11/wrapper/p11_util.c >> * Copyright date. >> >> * src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h >> * 4th hook does not apply cleanly because 6913047 was backported to 8u >> without the "//#define P11_DEBUG" line. >> >> * test/sun/security/pkcs11/MessageDigest/ByteBuffers.java >> * 1th hook does not apply cleanly because of copyright date. >> * 2nd hook do not apply cleanly because 8164639 [7], 8078334 [8], >> 8172527 [9], 8144539 [10] are not in 8u. Manually applied changes. >> >> * src/share/classes/sun/security/util/GCMParameters.java >> * HexDumpEncoder is sun.misc.HexDumpEncoder in 8u (instead of >> sun.security.util.HexDumpEncoder) >> >> * src/share/classes/sun/security/pkcs11/P11PSSSignature.java >> * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because >> 8146293 [11] has not been backported. Added a private field in >> P11PSSSignature with the constant. >> >> * test/sun/security/pkcs11/Cipher/TestKATForGCM.java >> * test/sun/security/pkcs11/Cipher/Test4512704.java >> * test/sun/security/pkcs11/Cipher/TestCICOWithGCM.java >> * test/sun/security/pkcs11/Cipher/TestCICOWithGCMAndAAD.java >> * test/sun/security/pkcs11/Cipher/TestGCMKeyAndIvCheck.java >> * test/sun/security/pkcs11/Signature/InitAgainPSS.java >> * test/sun/security/pkcs11/Signature/KeyAndParamCheckForPSS.java >> * test/sun/security/pkcs11/Signature/SigInteropPSS.java >> * test/sun/security/pkcs11/Signature/SignatureTestPSS.java >> * test/sun/security/pkcs11/Signature/TestDSA2.java >> * @library jtreg header modified to remove "/test/lib" >> * 8144539 [12] is not in 8u. Given that the test uses no arguments, I >> discarded the parameter when calling PKCS11Test::main method. >> >> * test/sun/security/pkcs11/Signature/InitAgainPSS.java >> * PSSParameterSpec.TRAILER_FIELD_BC does not exist in 8u because >> 8146293 [11] has not been backported. Added a private field in >> InitAgainPSS with the constant. >> >> * make/mapfiles/libj2pkcs11/mapfile-vers >> * Added Java_sun_security_pkcs11_wrapper_PKCS11_freeMechanism native >> method >> >> * test/sun/security/pkcs11/Signature/SigInteropPSS.java >> * "java.security.NoSuchAlgorithmException: no such algorithm: >> RSASSA-PSS for provider SunRsaSign" error. >> * This test cannot properly execute because 8146293 [11] is not in >> 8u. Manually modified to skip unless 8146293 [11] is available. >> >> >> Testing >> >> * No regressions have been observed in sun/security/pkcs11 category >> >> * All new tests (introduced by this enhancement) pass >> * Note: SigInteropPSS is skipped for the reasons previously stated >> >> Thanks, >> Martin.- >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8080462 >> [2] - https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8bac0ba1d5ce >> [3] - https://bugs.openjdk.java.net/browse/JDK-8169925 >> [4] - https://bugs.openjdk.java.net/browse/JDK-8042967 >> [5] - https://bugs.openjdk.java.net/browse/JDK-8041679 >> [6] - https://bugs.openjdk.java.net/browse/JDK-8074580 >> [7] - https://bugs.openjdk.java.net/browse/JDK-8164639 >> [8] - https://bugs.openjdk.java.net/browse/JDK-8078334 >> [9] - https://bugs.openjdk.java.net/browse/JDK-8172527 >> [10] - https://bugs.openjdk.java.net/browse/JDK-8144539 >> [11] - https://bugs.openjdk.java.net/browse/JDK-8146293 >> [12] - https://bugs.openjdk.java.net/browse/JDK-8144539 >> > From yan at azul.com Fri Dec 6 07:07:59 2019 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 6 Dec 2019 10:07:59 +0300 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <43A6607D-32FC-4F63-9103-31F254666698@amazon.com> References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> <43A6607D-32FC-4F63-9103-31F254666698@amazon.com> Message-ID: And, overall backport looks good to me. Thank you! --yan On 06.12.2019 01:54, Hohensee, Paul wrote: > I'll push them for you. > > Paul > > ?On 12/5/19, 1:55 PM, "jdk8u-dev on behalf of David Alvarez" wrote: > > 8234591 was a clean backport. Once I get the review approval for > 8223490, I'll ensure I'll add a comment when doing the jdk8u-fix-request > so 8223490, 8231124 and 8234591 are all push together. I'll need a > commiter to push the changes for me. > > For convenience, I have a copy of the 8u patch of 8234591 [1] > > David > > -- > [1] http://cr.openjdk.java.net/~alvdavi/patches/8234591.8u.00.patch > > On 2019-12-05 13:38, David Alvarez wrote: > > Thanks for catching that one, being only in 11u and not in tip in flew > > under my radar. I will backport it to 8 too. > > > > David > > > > On 2019-12-05 01:41, Yuri Nesterenko wrote: > >> Hi David, > >> > >> could you please consider a small change from > >> > >> https://bugs.openjdk.java.net/browse/JDK-8234591 ? > >> It may be even more important for jdk8. > >> > >> Thanks, > >> --yan > >> > >> On 05.12.2019 01:38, David Alvarez wrote: > >>> Hi, > >>> > >>> I would like to request a backport of JDK-8223490. > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 > >>> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 > >>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ > >>> > >>> The patch is marked as 8u241 but not yet in openjdk8u242. > >>> > >>> Patch did not apply cleanly, multiple modifications were required. > >>> > >>> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry > >>> around and references to readdir64_r. We also don't have JDK-7153347 [2] > >>> which added multiple changes to the original findZoneInfoFile method. > >>> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is > >>> possible these are not the only ones. > >>> > >>> This patch will be followed up by a backport of JDK-8231124 which is a > >>> follow up. > >>> > >>> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've > >>> been able to test on an affected system, where ZoneId.systemDefault() > >>> was returning Zulu before the patch, and UTC after. > >>> > >>> Thanks, > >>> > >>> David > >>> > >>> -- > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 > >>> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b > >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 > >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 > >>> > >>> > >>> > >>> > >> > > From volker.simonis at gmail.com Fri Dec 6 13:34:39 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 6 Dec 2019 14:34:39 +0100 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: Message-ID: Hi Iris, I've just realized that my first answer to this mail unintentionally went to you only (instead of being posted to the list). I'll therefore repost to the list, because I think this may be of interest to the others as well. Please feel free to re-post your initial answer to the list as well and sorry for the inconvenience :) On Wed, Nov 6, 2019 at 10:54 PM Iris Clark wrote: > > The TLS 1.3 protocol is rapidly gaining adoption on the Internet, and thus is > important even for legacy applications running on JDK 8. > Thanks for addressing this issue. I think it will be well perceived by the OpenJDK community. Please find further comments inline: > Backporting TLS 1.3 to JDK 8 would not, of itself, require API changes, but > API changes are required in order to backport two technologies necessary for > TLS 1.3, ALPN [1] and RSASSA-PSS [2]: > > - The TLS ALPN (Application-Layer Protocol Negotiation) extension was added > to Java SE 9 with JEP 244 (TLS Application-Layer Protocol Negotiation > Extension (ALPN)) [3]. It allows negotiation of an application-layer > protocol value during the TLS handshake which may be used during the > selection of other TLS protocol parameters. HTTP/2 [4] and other modern > network protocols use ALPN. [5,6] > > - Support for the RSASSA-PSS (RSA Signature Scheme with Appendix -- > Probabilistic Signature Scheme) algorithm was added to Java SE 11. It is > a cryptographic signature scheme used for secure data transmission which > was initially standardized as part of PKCS#1 v2.1 [7]. An API is > necessary to enable third-party provider support. [8,9] > > To enable efforts to backport TLS 1.3 to JDK 8, I'll shortly propose a > Maintenance Release of the Java SE 8 Platform JSR [0] in the JCP to backport > the ALPN and RSASSA-PSS APIs. This will require updates to the Specification, > the Reference Implementation (RI), and the TCK, which I and my colleagues at > Oracle will provide. I expect the Maintenance Release process to complete by > February 2020, in time for these changes to be merged into the April security > releases of JDK 8. > > In order to reduce risk we'd like to base the open-source RI on OpenJDK 8u40 > [10], the RI for the previous two Maintenance Releases, rather than the most > recent OpenJDK 8 update release. Which risks do you want to reduce here? It seems that basing the RI on 8u40 mainly reduces the risk of not completing the Maintenance Release process in time for the April security release. For me, the much bigger risk would be to complete the Maintenance Release process in time but fail to deliver the new standard relevant features (plus the TLS 1.3 implementation) in the subsequent OpenJDk 8u security release because this would actually make OpenJDk 8u non Java SE 8 compliant. So I'd instead propose to base the RI on the latest released update version of OpenJDK 8 at that time as that would give all downstream consumers of OpenJDK 8 the chance to easily comply to the specification changes introduced by the MR. > We propose to name this "8u41," which is a > bit odd but does convey the special nature of any RI build: It's not meant for > production use, since it's never updated with security fixes. > > If it's not too much work then we'll also contribute the changes required by > the MR to the next appropriate OpenJDK 8 release, most likely 8u252. See above. Why duplicate the work and do the changes for both, 8u40 and maybe 8u252 if you could do them just as well in 8u252 alone? > We do > not plan to contribute a backport TLS 1.3 to OpenJDK 8. This will be already be a big enough effort for the OpenJDK 8u project, so we should try to avoid the extra effort caused by the required MR changes. Thank you and best regards, Volker > > Comments? > > Iris > > [0]: https://openjdk.java.net/projects/jdk8/spec/ > [1]: https://bugs.openjdk.java.net/browse/JDK-8230977 > [2]: https://bugs.openjdk.java.net/browse/JDK-8230978 > [3]: https://openjdk.java.net/jeps/244 > [4]: https://tools.ietf.org/html/rfc7540 > [5]: https://bugs.openjdk.java.net/browse/JDK-8144093 > [6]: https://bugs.openjdk.java.net/browse/JDK-8170282 > [7]: https://tools.ietf.org/html/rfc3447 > [8]: https://bugs.openjdk.java.net/browse/JDK-8190180 > [9]: https://bugs.openjdk.java.net/browse/JDK-8206864 > [10]: https://hg.openjdk.java.net/jdk8u/jdk8u40 From xxinliu at amazon.com Fri Dec 6 18:55:30 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 6 Dec 2019 18:55:30 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <835E4FA2-2080-4E64-80B4-BAAC8C8BF315@amazon.com> References: <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> <835E4FA2-2080-4E64-80B4-BAAC8C8BF315@amazon.com> Message-ID: <213AC6B7-439C-4000-A736-E7CC71BBC1EA@amazon.com> Hi, reviewers and maintainers, We have two repos to commit. For the root repo, there's only one webrev. it adds a target ''test-image", which will build native libraries for vmtestbase tests. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ For hotspot repo, we have 8 patches. base is a special case. it's just copy from jdk14. it's too big to review. I have to treat it as blob. In order to make our change more reviewable, we split the commits into a sequence of commits using MQ. 1. base https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz 2. updateAPIs https://cr.openjdk.java.net/~xliu/8231089/updateAPIs.patch 3. classFileInstaller https://cr.openjdk.java.net/~xliu/8231089/classFileInstaller/webrev/ 4. gclog https://cr.openjdk.java.net/~xliu/8231089/gclog/webrev/ 5. nativeLibraries https://cr.openjdk.java.net/~xliu/8231089/nativeLibraries/webrev/ 6. azul_contrib1 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib.patch 7. azul_contrib2 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2.patch 8. new_targets https://cr.openjdk.java.net/~xliu/8231089/new_targets/webrev/ Please note that some are missing webrevs on purpose. It will generate a very big webrev. I think patch files are still reviewable as an alternative. Could you take a look at them and see if it's okay to check in? The last one is optional. It introduces a ProblemList which we still can't pass on x86_64 and aarch64. #cd /src/hotspot/test #make JT_HOME=/opt/jtreg PRODUCT_HOME=/build/images/j2sdk-image/ ALT_OUTPUTDIR=/build EXTRA_JTREG_OPTIONS=-exclude:ProblemList-vmTestbase.txt vmtestbase My last question is whether I should squash them if we want to check them in. Thanks, --lx ?On 12/4/19, 8:14 AM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: +1 from me as well. Thanks, Paul On 12/4/19, 4:29 AM, "jdk8u-dev on behalf of Yuri Nesterenko" wrote: Hi, Liu Xin, Konstantin, as we already have and use it in Zulu, I only can say: great job. +1, list me as a reviewer. Thank you, --yan On 04.12.2019 14:54, Konstantin Shefov wrote: > Dear OpenJDK 8 Updates' maintainers! > > I am writing here to ask you to pay attention to this thread. > This is a backport of VmTestbase tests from JDK 14 to JDK 8u (https://bugs.openjdk.java.net/browse/JDK-8231089). > > Could you take a look and write your opinion? > > This patch is quite a big one (adds 15 000 files to hotspot repo), but all changes are in "test" part, not VM source. > The tests will be placed in a separate group in hotspot/test/TEST.groups file, so they will be run only when explicitly called. > > Thanks > Konstantin > > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu, Xin > Sent: Monday, October 14, 2019 9:55 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hello, Reviewers, > > May I have attention for thread? > I have separated the jumbo vmTestbase to 1+7 patches. > This patch is the entrypoint in root project. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > This patch is just vmTestbase blob from jdk14+14. > https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz > > If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. > Thanks, > --lx > > > On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" wrote: > > Hi, Konstantin, > > Yes, it makes sense. I prepare a webrev and include it your change. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > Can we at least push it first? > Thanks, > --lx > > On 10/8/19, 3:43 AM, "Konstantin Shefov" wrote: > > Hello > > In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: > > diff -r 31d7a6f35834 make/Main.gmk > --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 > +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 > @@ -168,10 +168,10 @@ > @$(call TargetExit) > test-image: start-make > @$(call TargetEnter) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) > @$(call TargetExit) > > Konstantin > > On 07/10/2019, 13:10, "Konstantin Shefov" wrote: > > Hi. Liu Xin > > Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. > > As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. > > Konstantin > > > On 07/10/2019, 10:07, "Liu, Xin" wrote: > > Hi, Konstantin and other reviewers, > > I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. > > > $hg qapplied > base > updateAPIs > classFileInstaller > gclog > nativeLibraries > azul_contrib1 > azul_contrib2 > > Could you review my changes? I didn't generate webrev because they are huge. > https://cr.openjdk.java.net/~xliu/8231089/ > > @Konstantin, > > I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. > I have some comments for your patches. > 1) previously, you have deleted all @module. Eg. > /* > * @test > - * @modules java.base/jdk.internal.misc:+open > * @key stress gc > * > * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. > * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] > * > - * @modules java.base/jdk.internal.misc > * @library /vmTestbase > * /testlibrary > * /test/lib > @@ -40,7 +38,6 @@ > * @comment generate HumongousTemplateClass and compile it to test.classes > * @run driver gc.g1.unloading.bytecode.GenClassesBuilder > * > - * @requires vm.gc.G1 > > I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. > It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. > > 2. has you solved this issue? > https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 > I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. > > > Thanks, > --lx > > On 9/26/19, 4:52 AM, "Konstantin Shefov" wrote: > > Hi, Liu Xin > > I have to change my previous answer about Platform.java. > We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. > > The reasons are: > 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. > 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. > 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. > > So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. > > The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. > > Regards, > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Thursday, September 26, 2019 12:52 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hello > > I have no objections against removing Platform.java and using the existing one. > > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Thursday, September 26, 2019 2:24 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > I think you can also remove Platform.java in test/lib/jdk/test. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch > and change vmProps.java refer to jdk.testlibrary.Platform. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html > > It's because jdk.testlibrary.Platform is superset of the delete one. > Thanks, > --lx > > On 9/25/19, 3:20 AM, "Konstantin Shefov" wrote: > > Hi > > Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ > > This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. > > The list of changes is the following: > 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); > 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); > 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; > 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build//images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". > > With all changes provided by Liu Xin and the patch provided here we think it can be pushed. > > Thanks, > --Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 6:30 PM > To: 'Liu, Xin' ; 'jdk8u-dev at openjdk.java.net' > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > After applying all the patches, I have successfully built the native part, but I had to do some more changes. > After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. > > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 4:47 PM > To: 'Liu, Xin' ; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. > > As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. > Java class file format has changed between JDK 8 and JDK 11+. > In earlyretint.c from JDK 11+ we have the following line: > > "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " > > This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). > By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. > In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). > In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). > That is why we have to change the test here. > > [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep > [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation > > Regards, > Konstantin > > -----Original Message----- > From: Liu, Xin > Sent: Monday, September 23, 2019 10:13 AM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > hi, Konstantin, > > I also apply your patch to the last webrev. > > eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ > > We should apply them in order. > 1. base > 2. apiChanges > 3. classFileInstaller > 4. gclog > 5. native_libraries > 6. azul_contrib > > for your patch, i keep it everything except for -Xloggc. > Could you tell me why you modify from 0x21 to 0x2e? > diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c > --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 > +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 > @@ -89,7 +89,7 @@ > jlocation loc, jint i) { > jvmtiError err; > jclass cls; > - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; > + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; > char *sigClass, *name, *sig, *generic; > jvmtiLocalVariableEntry *table = NULL; > jint entryCount = 0; > > ________________________________________ > From: jdk8u-dev on behalf of Liu, Xin > Sent: Saturday, September 21, 2019 4:48 AM > To: Konstantin Shefov; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > As I promised, here is the refactored webrev for native compilation > > Hotspot: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ > root: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ > so the new target 'test-image' is added. > > to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, > I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. > > Thanks, > --lx > > > > > > > From: Konstantin Shefov > Date: Friday, September 20, 2019 at 11:01 AM > To: "Liu, Xin" , "jdk8u-dev at openjdk.java.net" > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > > I am refactoring makefiles. I plan to upload this webrev today. > Fine! We will try to compile with our toolchains. > > >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > Could you give me an example tests for this? > > One example is this > https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 > > And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. > See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 > and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 > > Konstantin > > From: Liu, Xin > Sent: Friday, September 20, 2019 8:35 PM > To: Konstantin Shefov ; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Konstantin, > > I am refactoring makefiles. I plan to upload this webrev today. > > I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. > >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? > > Thanks, > --lx > > From: Konstantin Shefov > > Date: Friday, September 20, 2019 at 2:26 AM > To: "Liu, Xin" >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We will use your new patches to run tests and merge my changes with yours for those tests that will not work. > > BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. > > Regards > Konstantin > > From: "Liu, Xin" > > Date: Wednesday, 18 September 2019 at 20:59 > To: Konstantin Shefov >, "jdk8u-dev at openjdk.java.net" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > > Hi, Konstantin, > > > > thank you for updating. > > > > We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. > > Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? > > > > Back to refactor, I have filed a JBS issues. > > https://bugs.openjdk.java.net/browse/JDK-8231089 > > In the meanwhile, I start splitting the commits to individual hg changesets. > https://cr.openjdk.java.net/~xliu/8231089/ > > 1. base -> copy code from tag jdk-14+14 > intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? > > 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. > > out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do > f=${i%\:} > gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f > done > > > What do you think that this approach? > If I got something wrong, we can update the webtrev with yours. > > thanks, > --lx > > > ________________________________ > From: Konstantin Shefov > > Sent: Wednesday, September 18, 2019 4:56 PM > To: Liu, Xin; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi > > We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: > vmTestbase/gc/lock/jni/jnilock002/TestDescription.java > vmTestbase/nsk/jdb/set/set001/set001.java > > Konstantin > > > From: Konstantin Shefov > Sent: Wednesday, September 11, 2019 10:53 AM > To: 'Liu, Xin' >; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, LX > > Answering to your e-mail, as for what we modified in [3]: > > 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; > 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. > > I agree that there should be a series of patches to track file changes. > > As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. > > Konstantin > > From: Liu, Xin > > Sent: Monday, September 9, 2019 11:04 PM > To: Konstantin Shefov >; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > We are glad to work with you to get vmTestbase landed into jdk8u. > Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. > > Back to the webrev you send. What did you modify in [3]? > Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. > In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? > > Thanks, > --lx > > > From: Konstantin Shefov > > Date: Friday, September 6, 2019 at 12:55 PM > To: "jdk8u-dev at openjdk.java.net" > > Cc: "Liu, Xin" > > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. > > We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. > > We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: > > 1. 3371 tests PASS (see [1]); > 2. 179 tests FAIL (see [2]): reasons are being investigated. > > Patches we have used (contain our refactoring): > > 1. Hotspot folder [3] > > 2. Main folder [4] > > We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. > > We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: > > 1. 332 test have been removed in JDK 13; > 2. Only 2 test have been added in JDK 13; > 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. > From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. > > [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html > [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html > [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch > [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch > > Regards, > --Konstantin > > > > > > > > > > > > > > From alvdavi at amazon.com Fri Dec 6 19:52:21 2019 From: alvdavi at amazon.com (David Alvarez) Date: Fri, 6 Dec 2019 11:52:21 -0800 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> <43A6607D-32FC-4F63-9103-31F254666698@amazon.com> Message-ID: <003ad5db-f621-582f-e64f-87053112e602@amazon.com> Thanks, If it is not too much to ask, would you mind taking a quick look to the review for JDK-8231124 [1], the first follow up? It is a very small patch and I would like to treat JDK-8223490, JDK-8231124 and JDK-8234591 as a single block David -- [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010720.html On 2019-12-05 23:07, Yuri Nesterenko wrote: > And, overall backport looks good to me. > > Thank you! > > --yan > > On 06.12.2019 01:54, Hohensee, Paul wrote: >> I'll push them for you. >> >> Paul >> >> ?On 12/5/19, 1:55 PM, "jdk8u-dev on behalf of David Alvarez" wrote: >> >> 8234591 was a clean backport. Once I get the review approval for >> 8223490, I'll ensure I'll add a comment when doing the jdk8u-fix-request >> so 8223490, 8231124 and 8234591 are all push together. I'll need a >> commiter to push the changes for me. >> >> For convenience, I have a copy of the 8u patch of 8234591 [1] >> >> David >> >> -- >> [1] http://cr.openjdk.java.net/~alvdavi/patches/8234591.8u.00.patch >> >> On 2019-12-05 13:38, David Alvarez wrote: >> > Thanks for catching that one, being only in 11u and not in tip in flew >> > under my radar. I will backport it to 8 too. >> > >> > David >> > >> > On 2019-12-05 01:41, Yuri Nesterenko wrote: >> >> Hi David, >> >> >> >> could you please consider a small change from >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8234591 ? >> >> It may be even more important for jdk8. >> >> >> >> Thanks, >> >> --yan >> >> >> >> On 05.12.2019 01:38, David Alvarez wrote: >> >>> Hi, >> >>> >> >>> I would like to request a backport of JDK-8223490. >> >>> >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 >> >>> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 >> >>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ >> >>> >> >>> The patch is marked as 8u241 but not yet in openjdk8u242. >> >>> >> >>> Patch did not apply cleanly, multiple modifications were required. >> >>> >> >>> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry >> >>> around and references to readdir64_r. We also don't have JDK-7153347 [2] >> >>> which added multiple changes to the original findZoneInfoFile method. >> >>> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is >> >>> possible these are not the only ones. >> >>> >> >>> This patch will be followed up by a backport of JDK-8231124 which is a >> >>> follow up. >> >>> >> >>> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've >> >>> been able to test on an affected system, where ZoneId.systemDefault() >> >>> was returning Zulu before the patch, and UTC after. >> >>> >> >>> Thanks, >> >>> >> >>> David >> >>> >> >>> -- >> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 >> >>> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b >> >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 >> >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 >> >>> >> >>> >> >>> >> >>> >> >> >> >> > From hohensee at amazon.com Fri Dec 6 21:13:33 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 6 Dec 2019 21:13:33 +0000 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <003ad5db-f621-582f-e64f-87053112e602@amazon.com> References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> <43A6607D-32FC-4F63-9103-31F254666698@amazon.com> <003ad5db-f621-582f-e64f-87053112e602@amazon.com> Message-ID: <02117477-236D-4F25-93A0-00A8CCDE4BE8@amazon.com> The 8231124 patch looks to be clean, so lgtm. Paul ?On 12/6/19, 11:52 AM, "Alvarez, David" wrote: Thanks, If it is not too much to ask, would you mind taking a quick look to the review for JDK-8231124 [1], the first follow up? It is a very small patch and I would like to treat JDK-8223490, JDK-8231124 and JDK-8234591 as a single block David -- [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010720.html On 2019-12-05 23:07, Yuri Nesterenko wrote: > And, overall backport looks good to me. > > Thank you! > > --yan > > On 06.12.2019 01:54, Hohensee, Paul wrote: >> I'll push them for you. >> >> Paul >> >> On 12/5/19, 1:55 PM, "jdk8u-dev on behalf of David Alvarez" wrote: >> >> 8234591 was a clean backport. Once I get the review approval for >> 8223490, I'll ensure I'll add a comment when doing the jdk8u-fix-request >> so 8223490, 8231124 and 8234591 are all push together. I'll need a >> commiter to push the changes for me. >> >> For convenience, I have a copy of the 8u patch of 8234591 [1] >> >> David >> >> -- >> [1] http://cr.openjdk.java.net/~alvdavi/patches/8234591.8u.00.patch >> >> On 2019-12-05 13:38, David Alvarez wrote: >> > Thanks for catching that one, being only in 11u and not in tip in flew >> > under my radar. I will backport it to 8 too. >> > >> > David >> > >> > On 2019-12-05 01:41, Yuri Nesterenko wrote: >> >> Hi David, >> >> >> >> could you please consider a small change from >> >> >> >> https://bugs.openjdk.java.net/browse/JDK-8234591 ? >> >> It may be even more important for jdk8. >> >> >> >> Thanks, >> >> --yan >> >> >> >> On 05.12.2019 01:38, David Alvarez wrote: >> >>> Hi, >> >>> >> >>> I would like to request a backport of JDK-8223490. >> >>> >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 >> >>> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 >> >>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ >> >>> >> >>> The patch is marked as 8u241 but not yet in openjdk8u242. >> >>> >> >>> Patch did not apply cleanly, multiple modifications were required. >> >>> >> >>> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry >> >>> around and references to readdir64_r. We also don't have JDK-7153347 [2] >> >>> which added multiple changes to the original findZoneInfoFile method. >> >>> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is >> >>> possible these are not the only ones. >> >>> >> >>> This patch will be followed up by a backport of JDK-8231124 which is a >> >>> follow up. >> >>> >> >>> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've >> >>> been able to test on an affected system, where ZoneId.systemDefault() >> >>> was returning Zulu before the patch, and UTC after. >> >>> >> >>> Thanks, >> >>> >> >>> David >> >>> >> >>> -- >> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 >> >>> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b >> >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 >> >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 >> >>> >> >>> >> >>> >> >>> >> >> >> >> > From verghese at amazon.com Fri Dec 6 23:03:01 2019 From: verghese at amazon.com (Verghese, Clive) Date: Fri, 6 Dec 2019 23:03:01 +0000 Subject: [8u] RFR backport of 8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails Message-ID: <2991D191-9F80-48AB-B6D5-2643AB9A38D8@amazon.com> Hi, I would like to request backport of JDK-8213119 to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8213119 Original: https://hg.openjdk.java.net/jdk/jdk/rev/85d7af399ef5 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8213119/webrev.8u.00/ The patch is marked as 8u241but not yet in openjdk8u 242. Patch did not apply cleanly, minor modifications were required. Other than the mismatch in Copyrights, the following hunks did not apply cleanly. In file ?test/java/awt/GraphicsDevice/CheckDisplayModes.java?, hunk 2 did not apply cleanly. In file ?macosx/native/sun/awt/CGraphicsDevice.m?, hunk 2 did not apply cleanly. The test was not present in ProblemList.txt. Validated that the test is running successfully. Regards, Clive Verghese From yan at azul.com Mon Dec 9 07:26:52 2019 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 9 Dec 2019 10:26:52 +0300 Subject: [8u] [1/2] RFR backport of 8223490: Optimize search algorithm for determining default time zone In-Reply-To: <003ad5db-f621-582f-e64f-87053112e602@amazon.com> References: <497397d0-ab89-d173-3a50-0657a9f07f37@amazon.com> <43A6607D-32FC-4F63-9103-31F254666698@amazon.com> <003ad5db-f621-582f-e64f-87053112e602@amazon.com> Message-ID: Lgtm Thanks, --yan On 06.12.2019 22:52, David Alvarez wrote: > Thanks, > > If it is not too much to ask, would you mind taking a quick look to the > review for JDK-8231124 [1], the first follow up? It is a very small > patch and I would like to treat JDK-8223490, JDK-8231124 and JDK-8234591 > as a single block > > David > > -- > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010720.html > > On 2019-12-05 23:07, Yuri Nesterenko wrote: >> And, overall backport looks good to me. >> >> Thank you! >> >> --yan >> >> On 06.12.2019 01:54, Hohensee, Paul wrote: >>> I'll push them for you. >>> >>> Paul >>> >>> ?On 12/5/19, 1:55 PM, "jdk8u-dev on behalf of David Alvarez" wrote: >>> >>> 8234591 was a clean backport. Once I get the review approval for >>> 8223490, I'll ensure I'll add a comment when doing the jdk8u-fix-request >>> so 8223490, 8231124 and 8234591 are all push together. I'll need a >>> commiter to push the changes for me. >>> >>> For convenience, I have a copy of the 8u patch of 8234591 [1] >>> >>> David >>> >>> -- >>> [1] http://cr.openjdk.java.net/~alvdavi/patches/8234591.8u.00.patch >>> >>> On 2019-12-05 13:38, David Alvarez wrote: >>> > Thanks for catching that one, being only in 11u and not in tip in flew >>> > under my radar. I will backport it to 8 too. >>> > >>> > David >>> > >>> > On 2019-12-05 01:41, Yuri Nesterenko wrote: >>> >> Hi David, >>> >> >>> >> could you please consider a small change from >>> >> >>> >> https://bugs.openjdk.java.net/browse/JDK-8234591 ? >>> >> It may be even more important for jdk8. >>> >> >>> >> Thanks, >>> >> --yan >>> >> >>> >> On 05.12.2019 01:38, David Alvarez wrote: >>> >>> Hi, >>> >>> >>> >>> I would like to request a backport of JDK-8223490. >>> >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223490 >>> >>> Original: https://hg.openjdk.java.net/jdk/jdk/rev/8ee083465318 >>> >>> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8223490/webrev.8u.00/ >>> >>> >>> >>> The patch is marked as 8u241 but not yet in openjdk8u242. >>> >>> >>> >>> Patch did not apply cleanly, multiple modifications were required. >>> >>> >>> >>> jkd8u missing JDK-8202794 [1] meant we still had the dirent64 *entry >>> >>> around and references to readdir64_r. We also don't have JDK-7153347 [2] >>> >>> which added multiple changes to the original findZoneInfoFile method. >>> >>> Nor do we have JDK-8214077 [3] that changed statbuf to a stat64. It is >>> >>> possible these are not the only ones. >>> >>> >>> >>> This patch will be followed up by a backport of JDK-8231124 which is a >>> >>> follow up. >>> >>> >>> >>> I've run Tier1 and Tier2 tests, no regressions found. Additionally, I've >>> >>> been able to test on an affected system, where ZoneId.systemDefault() >>> >>> was returning Zulu before the patch, and UTC after. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> David >>> >>> >>> >>> -- >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8202794 >>> >>> [2] http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4887534fa39b >>> >>> [3] https://bugs.openjdk.java.net/browse/JDK-8214077 >>> >>> [4] https://bugs.openjdk.java.net/browse/JDK-8231124 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >>> >>> From adinn at redhat.com Mon Dec 9 10:55:53 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 9 Dec 2019 10:55:53 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: Message-ID: Hi Volker/Iris, Firstly, thanks to Oracle for offering to update the JDK8u specs and contribute the necessary changes to re-implement the ALPN and RSASSA-PSS APIs. That said, I can see Volker's point here. Putting the changes into both 8u40 and 8u252 appears to add an extra redundant step as far as the OpenJDK project is concerned. Is there a reason why the 8u40 backport is needed? (more specifically, why does it need to be adopted as the RI?) Is there any reason for Oracle to do the 8u40 backport before backporting to 8u252 and publishing the latter changes? Of course, if the open project is provided with the relevant 8u252 changes in a timely manner then I don't suppose the answers to the above questions are critical. What dominates is the project's ability to respond in time 1) to assimilate the ALPN and RSASSA-PSS API changes and 2) to add TLS 1.3 support on top of those changes. I'll leave it to others (including my Red Hat colleagues) who are more au fait with TLS and the jdk8u schedule to comment on that issue. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 06/12/2019 13:34, Volker Simonis wrote: > Hi Iris, > > I've just realized that my first answer to this mail unintentionally > went to you only (instead of being posted to the list). I'll therefore > repost to the list, because I think this may be of interest to the > others as well. Please feel free to re-post your initial answer to the > list as well and sorry for the inconvenience :) > > On Wed, Nov 6, 2019 at 10:54 PM Iris Clark wrote: >> >> The TLS 1.3 protocol is rapidly gaining adoption on the Internet, and thus is >> important even for legacy applications running on JDK 8. >> > > Thanks for addressing this issue. I think it will be well perceived by > the OpenJDK community. Please find further comments inline: > >> Backporting TLS 1.3 to JDK 8 would not, of itself, require API changes, but >> API changes are required in order to backport two technologies necessary for >> TLS 1.3, ALPN [1] and RSASSA-PSS [2]: >> >> - The TLS ALPN (Application-Layer Protocol Negotiation) extension was added >> to Java SE 9 with JEP 244 (TLS Application-Layer Protocol Negotiation >> Extension (ALPN)) [3]. It allows negotiation of an application-layer >> protocol value during the TLS handshake which may be used during the >> selection of other TLS protocol parameters. HTTP/2 [4] and other modern >> network protocols use ALPN. [5,6] >> >> - Support for the RSASSA-PSS (RSA Signature Scheme with Appendix -- >> Probabilistic Signature Scheme) algorithm was added to Java SE 11. It is >> a cryptographic signature scheme used for secure data transmission which >> was initially standardized as part of PKCS#1 v2.1 [7]. An API is >> necessary to enable third-party provider support. [8,9] >> >> To enable efforts to backport TLS 1.3 to JDK 8, I'll shortly propose a >> Maintenance Release of the Java SE 8 Platform JSR [0] in the JCP to backport >> the ALPN and RSASSA-PSS APIs. This will require updates to the Specification, >> the Reference Implementation (RI), and the TCK, which I and my colleagues at >> Oracle will provide. I expect the Maintenance Release process to complete by >> February 2020, in time for these changes to be merged into the April security >> releases of JDK 8. >> >> In order to reduce risk we'd like to base the open-source RI on OpenJDK 8u40 >> [10], the RI for the previous two Maintenance Releases, rather than the most >> recent OpenJDK 8 update release. > > Which risks do you want to reduce here? It seems that basing the RI on > 8u40 mainly reduces the risk of not completing the Maintenance Release > process in time for the April security release. > > For me, the much bigger risk would be to complete the Maintenance > Release process in time but fail to deliver the new standard relevant > features (plus the TLS 1.3 implementation) in the subsequent OpenJDk > 8u security release because this would actually make OpenJDk 8u non > Java SE 8 compliant. > > So I'd instead propose to base the RI on the latest released update > version of OpenJDK 8 at that time as that would give all downstream > consumers of OpenJDK 8 the chance to easily comply to the > specification changes introduced by the MR. > >> We propose to name this "8u41," which is a >> bit odd but does convey the special nature of any RI build: It's not meant for >> production use, since it's never updated with security fixes. >> >> If it's not too much work then we'll also contribute the changes required by >> the MR to the next appropriate OpenJDK 8 release, most likely 8u252. > > See above. Why duplicate the work and do the changes for both, 8u40 > and maybe 8u252 if you could do them just as well in 8u252 alone? > >> We do >> not plan to contribute a backport TLS 1.3 to OpenJDK 8. > > This will be already be a big enough effort for the OpenJDK 8u > project, so we should try to avoid the extra effort caused by the > required MR changes. > > Thank you and best regards, > Volker > >> >> Comments? >> >> Iris >> >> [0]: https://openjdk.java.net/projects/jdk8/spec/ >> [1]: https://bugs.openjdk.java.net/browse/JDK-8230977 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8230978 >> [3]: https://openjdk.java.net/jeps/244 >> [4]: https://tools.ietf.org/html/rfc7540 >> [5]: https://bugs.openjdk.java.net/browse/JDK-8144093 >> [6]: https://bugs.openjdk.java.net/browse/JDK-8170282 >> [7]: https://tools.ietf.org/html/rfc3447 >> [8]: https://bugs.openjdk.java.net/browse/JDK-8190180 >> [9]: https://bugs.openjdk.java.net/browse/JDK-8206864 >> [10]: https://hg.openjdk.java.net/jdk8u/jdk8u40 > From aph at redhat.com Mon Dec 9 11:05:12 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Dec 2019 11:05:12 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: Message-ID: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> On 12/9/19 10:55 AM, Andrew Dinn wrote: > That said, I can see Volker's point here. Putting the changes into both > 8u40 and 8u252 appears to add an extra redundant step as far as the > OpenJDK project is concerned. Is there a reason why the 8u40 backport is > needed? (more specifically, why does it need to be adopted as the RI?) I think that's because it's a specification change, and all spec changes need a reference implementation. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Dec 9 11:08:39 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 9 Dec 2019 11:08:39 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> Message-ID: On 09/12/2019 11:05, Andrew Haley wrote: > On 12/9/19 10:55 AM, Andrew Dinn wrote: >> That said, I can see Volker's point here. Putting the changes into both >> 8u40 and 8u252 appears to add an extra redundant step as far as the >> OpenJDK project is concerned. Is there a reason why the 8u40 backport is >> needed? (more specifically, why does it need to be adopted as the RI?) > > I think that's because it's a specification change, and all spec changes > need a reference implementation. Well, yes, of course. But the question was why 8u40 needs to be the RI? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Mon Dec 9 11:36:23 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Dec 2019 11:36:23 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> Message-ID: <0614f2f9-ca4c-45da-6c0d-730fc21899c2@redhat.com> From aph at redhat.com Mon Dec 9 11:42:46 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 9 Dec 2019 11:42:46 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> Message-ID: <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> On 12/9/19 11:08 AM, Andrew Dinn wrote: > On 09/12/2019 11:05, Andrew Haley wrote: >> On 12/9/19 10:55 AM, Andrew Dinn wrote: >>> That said, I can see Volker's point here. Putting the changes into both >>> 8u40 and 8u252 appears to add an extra redundant step as far as the >>> OpenJDK project is concerned. Is there a reason why the 8u40 backport is >>> needed? (more specifically, why does it need to be adopted as the RI?) >> >> I think that's because it's a specification change, and all spec changes >> need a reference implementation. > > Well, yes, of course. But the question was why 8u40 needs to be the RI? Oh, I see. I think the idea is that one RI is updated with the minimal changes to go to the next. To do otherwise would require Oracle to sanctify a code base that they've never looked at. They'd have to be very brave. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Dec 9 13:53:25 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 9 Dec 2019 13:53:25 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> Message-ID: <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> On 09/12/2019 11:42, Andrew Haley wrote: > On 12/9/19 11:08 AM, Andrew Dinn wrote: >> On 09/12/2019 11:05, Andrew Haley wrote: >>> On 12/9/19 10:55 AM, Andrew Dinn wrote: >>>> That said, I can see Volker's point here. Putting the changes into both >>>> 8u40 and 8u252 appears to add an extra redundant step as far as the >>>> OpenJDK project is concerned. Is there a reason why the 8u40 backport is >>>> needed? (more specifically, why does it need to be adopted as the RI?) >>> >>> I think that's because it's a specification change, and all spec changes >>> need a reference implementation. >> >> Well, yes, of course. But the question was why 8u40 needs to be the RI? > > Oh, I see. I think the idea is that one RI is updated with the minimal changes > to go to the next. To do otherwise would require Oracle to sanctify a code base > that they've never looked at. They'd have to be very brave. :-) Ah ok, I see. So, both sets of patches are needed to make sure that the RI and the latest release are mutually in sync with the API spec and with each other. In which case the answer to Volker's question appears to be that the risk mitigation he proposes (defining the API changes and patching 8u252 before attempting to patch 8u40) is not actually a mitigation. An 8u252 which complies with an updated API spec but lacks an accompanying RI fails to be compliant by virtue of having an incomplete spec with which to comply (since compliance only exists when you have an API spec + RI). QED? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From iris.clark at oracle.com Mon Dec 9 17:27:20 2019 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 9 Dec 2019 09:27:20 -0800 (PST) Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> Message-ID: Hi. The reasoning for choosing 8u40 as the base for the RI is correct. Here's my original response to Volker: Date: Wed 11/13/2019 6:33 PM Subject: RE: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 Hi, Volker. What you write is correct: Basing the RI on 8u40 mainly reduces the risk of not completing the Maintenance Release process in time for the April security release. That?s our primary goal. Basing the RI on 8u252 would require us to validate all of the changes between 8u202 and 8u252. As I wrote in the proposal, my colleagues and I do intend to contribute the MR changes to 8u252, assuming that it?s not too much work. In the worst case, even if 8u252 does not include the ALPN and RSASSA-PSS changes, those who work on that release line or deploy compatible Java implementations based on code derived from OpenJDK would still have 120 days to make it compliant, per the License Grant section of the TCK License. Regards, Iris Currently work is underway to contribute the changes to 8u252 in time for the April 2020 release. Thanks, Iris From volker.simonis at gmail.com Mon Dec 9 19:48:41 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 9 Dec 2019 20:48:41 +0100 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> Message-ID: On Mon, Dec 9, 2019 at 2:53 PM Andrew Dinn wrote: > > On 09/12/2019 11:42, Andrew Haley wrote: > > On 12/9/19 11:08 AM, Andrew Dinn wrote: > >> On 09/12/2019 11:05, Andrew Haley wrote: > >>> On 12/9/19 10:55 AM, Andrew Dinn wrote: > >>>> That said, I can see Volker's point here. Putting the changes into both > >>>> 8u40 and 8u252 appears to add an extra redundant step as far as the > >>>> OpenJDK project is concerned. Is there a reason why the 8u40 backport is > >>>> needed? (more specifically, why does it need to be adopted as the RI?) > >>> > >>> I think that's because it's a specification change, and all spec changes > >>> need a reference implementation. > >> > >> Well, yes, of course. But the question was why 8u40 needs to be the RI? > > > > Oh, I see. I think the idea is that one RI is updated with the minimal changes > > to go to the next. To do otherwise would require Oracle to sanctify a code base > > that they've never looked at. They'd have to be very brave. :-) > Ah ok, I see. So, both sets of patches are needed to make sure that the > RI and the latest release are mutually in sync with the API spec and > with each other. > > In which case the answer to Volker's question appears to be that the > risk mitigation he proposes (defining the API changes and patching 8u252 > before attempting to patch 8u40) is not actually a mitigation. An 8u252 > which complies with an updated API spec but lacks an accompanying RI > fails to be compliant by virtue of having an incomplete spec with which > to comply (since compliance only exists when you have an API spec + RI). > QED? Sorry, but I don*t understand your reasoning. There is no "reference implementation" for a specific update release. There's a "reference implementation" per JSR. For Java SE 8 (i.e. JSR 337 - Maintenance Release 2 [1]) this is OpenJDK 1.8.0u40-b25 [2]. Every implementation which passes the TCK can act as a "reference implementation", that's up to the Spec Lead. In the JSR 337 [3], the Spec Lead states "The source code for most of the Reference Implementation will be developed in the OpenJDK Community". So obviously the Spec Lead can decide to base the "reference implementation" for "Maintenance Release 3" on OpenJDK 1.8.0u40-b25. But in contrast to previous Maintenance Releases, this will be a version, that nobody wants (because it misses a bunch of fixes and features) and nobody will be able to use (because it misses even more security patches). It would also give Oracle an competitive advantage if they were the only ones who could release a MR3 compatible version of 8u252 in April because the community needs more time to port the corresponding changes from 8u40 to 8u252. And it doesn't help that (as Iris wrote) "even if [the OpenJDK version of] 8u252 does not include the ALPN and RSASSA-PSS changes, those who work on that release line or deploy compatible Java implementations based on code derived from OpenJDK would still have 120 days to make it compliant, per the License Grant section of the TCK License". We would have two versions of 8u252 where only the Oracle one would be Java SE 8 MR3 compatible, while the OpenJDK one would be still MR2 only. Summing it up, I don't think that the current OpenJDK development version has any problems passing the current Java SE 8 MR2 version of the TCK (we're all testing that regularly, right :). That's why I don't see any reasons not basing the reference implementation of Java SE 8 MR3 on it (i.e. 8u252). Basing it on 8u40 would be just a needless duplication of efforts. Fortunately, Iris just wrote in her follow-up answer that "work is underway to contribute the changes to 8u252 in time for the April 2020 release", so hopefully, both, the OpenJDK as well as Oracle JDK will be able to support the new Java SE 8 MR 3 features at the same time in April 2020. Best regards, Volker [1] https://jcp.org/aboutJava/communityprocess/mrel/jsr337/index2.html [2] http://jdk.java.net/java-se-ri/8 [3] https://www.jcp.org/en/jsr/detail?id=337 > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From adinn at redhat.com Tue Dec 10 09:57:15 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 10 Dec 2019 09:57:15 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> Message-ID: On 09/12/2019 19:48, Volker Simonis wrote: > Summing it up, I don't think that the current OpenJDK development > version has any problems passing the current Java SE 8 MR2 version of > the TCK (we're all testing that regularly, right :). That's why I > don't see any reasons not basing the reference implementation of Java > SE 8 MR3 on it (i.e. 8u252). Basing it on 8u40 would be just a > needless duplication of efforts. Well, I cannot account for what you see (or fail to see) but I believe Andrew Haley and Iris did both provide a reason (the same reason) why basing the reference implementation on 8u252 would not be straightforward for Oracle to do. It would involve them reviewing and validating all of the open changes between 8u202 and 8u252. You are at liberty to assume the work involved to be less effort than updating 8u40 as the RI but I don't see why you think you are in a position to decide that on Oracle's behalf? > Fortunately, Iris just wrote in her follow-up answer that "work is > underway to contribute the changes to 8u252 in time for the April 2020 > release", so hopefully, both, the OpenJDK as well as Oracle JDK will > be able to support the new Java SE 8 MR 3 features at the same time in > April 2020. Yes, clearly Oracle think they can deliver a verified 8u40 RI and matching 8u252 changes on time. It seems they do not think they can deliver a verified 8u252 RI on time. Since they are generously offering to plan and execute this task and since we have little reason to doubt their competence I recommend accepting their judgement here. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From fedor.burdun at azul.com Tue Dec 10 18:35:26 2019 From: fedor.burdun at azul.com (Fedor) Date: Tue, 10 Dec 2019 21:35:26 +0300 Subject: [8u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 Message-ID: <527d6e01-9176-c46f-39a1-29ced7869e4d@azul.com> Hello everybody, May I have a request backport of JDK-8231507? Bug: https://bugs.openjdk.java.net/browse/JDK-8231507 webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/ testing: jdk/test/com/sun/org/apache/xml/ jdk/test/javax/xml/crypto/dsig/ The code of library taken from jdk14 sources wasn't applied cleanly to jdk8u, so a sort of changes were done: The changes made after copying files from jdk14: http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.html (raw diff: http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.diff) Several files were deleted. The rest was taken "as is" from jdk14. Thanks, Fedor From volker.simonis at gmail.com Tue Dec 10 19:50:40 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2019 20:50:40 +0100 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> Message-ID: On Tue, Dec 10, 2019 at 10:57 AM Andrew Dinn wrote: > > On 09/12/2019 19:48, Volker Simonis wrote: > > > Summing it up, I don't think that the current OpenJDK development > > version has any problems passing the current Java SE 8 MR2 version of > > the TCK (we're all testing that regularly, right :). That's why I > > don't see any reasons not basing the reference implementation of Java > > SE 8 MR3 on it (i.e. 8u252). Basing it on 8u40 would be just a > > needless duplication of efforts. > > Well, I cannot account for what you see (or fail to see) but I believe > Andrew Haley and Iris did both provide a reason (the same reason) why > basing the reference implementation on 8u252 would not be > straightforward for Oracle to do. It would involve them reviewing and > validating all of the open changes between 8u202 and 8u252. What makes you (or Andrew Haley) believe that Oracle would have to "review and validate all of the open changes between 8u202 and 8u252" (and validate against what)? As I wrote, I'm confident (and I think you too) that the current 8u-dev (and therefore 8u252 as well) is fully Java SE 8 MR2 compatible (aka. "passes the Java SE 8 MR 2 TCK). As such, it can easily be used as a reference implementation for Java SE 8. A "reference implementation" must pass the TCK, no more, no less. > You are at > liberty to assume the work involved to be less effort than updating 8u40 > as the RI but I don't see why you think you are in a position to decide > that on Oracle's behalf? I never did that. In contrary, I explicitly said: "..obviously the Spec Lead [which is Oracle] can decide to base the "reference implementation" for "Maintenance Release 3" on OpenJDK 1.8.0u40-b25. > > > Fortunately, Iris just wrote in her follow-up answer that "work is > > underway to contribute the changes to 8u252 in time for the April 2020 > > release", so hopefully, both, the OpenJDK as well as Oracle JDK will > > be able to support the new Java SE 8 MR 3 features at the same time in > > April 2020. > Yes, clearly Oracle think they can deliver a verified 8u40 RI and > matching 8u252 changes on time. It seems they do not think they can > deliver a verified 8u252 RI on time. Since they are generously offering > to plan and execute this task and since we have little reason to doubt > their competence I recommend accepting their judgement here. > If ReadHat as Maintainer of the OpenJDK 8 Updates project is happy with how Oracle handles Java Specification updates and their implementation in the OpenJDK versus their own, proprietary implementation, I'll be silent and won't complain any more :) > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From hohensee at amazon.com Tue Dec 10 19:52:51 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Dec 2019 19:52:51 +0000 Subject: [8u] RFR backport of 8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails In-Reply-To: <2991D191-9F80-48AB-B6D5-2643AB9A38D8@amazon.com> References: <2991D191-9F80-48AB-B6D5-2643AB9A38D8@amazon.com> Message-ID: Lgtm. Paul ?On 12/6/19, 3:05 PM, "jdk8u-dev on behalf of Verghese, Clive" wrote: Hi, I would like to request backport of JDK-8213119 to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8213119 Original: https://hg.openjdk.java.net/jdk/jdk/rev/85d7af399ef5 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8213119/webrev.8u.00/ The patch is marked as 8u241but not yet in openjdk8u 242. Patch did not apply cleanly, minor modifications were required. Other than the mismatch in Copyrights, the following hunks did not apply cleanly. In file ?test/java/awt/GraphicsDevice/CheckDisplayModes.java?, hunk 2 did not apply cleanly. In file ?macosx/native/sun/awt/CGraphicsDevice.m?, hunk 2 did not apply cleanly. The test was not present in ProblemList.txt. Validated that the test is running successfully. Regards, Clive Verghese From hohensee at amazon.com Tue Dec 10 20:16:31 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Dec 2019 20:16:31 +0000 Subject: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> References: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> Message-ID: <03766CF0-CA07-47A5-AEBD-A0E451FAD87B@amazon.com> Lgtm. I'll sponsor it and tag the JBS issue with jdk8u-fix-request. Thanks, Paul ?On 12/9/19, 4:55 AM, "jdk-updates-dev on behalf of Severin Gehwolf" wrote: Hi Adam, This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the subject line. Thanks, Severin On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote: > Hey all, > > Four GPLv2 files in 8u seem to be missing the classpath exception from the > copyright section. > > Requesting reviews and a sponsor. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227715 > > Webrev: http://cr.openjdk.java.net/~afarley/8227715/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > 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 hohensee at amazon.com Tue Dec 10 20:26:54 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 10 Dec 2019 20:26:54 +0000 Subject: Seeing JNI exception in 8u232 jdk builds In-Reply-To: References: Message-ID: Can you provide us with a reproducer please? Attachments are stripped, so hopefully the reproducer is small enough to inline into an email message. If not, send me the file at hohensee at amazon.com and I'll file a JBS issue. Thanks, Paul ?On 12/5/19, 3:18 AM, "jdk8u-dev on behalf of brahmam" wrote: Hi Everyone, We are seeing the below exception during our application set up when using 8u232 alone, But it is working fine with previous version before 8u232. any idea please? 2019/12/05 16:40:45 | INFO | jvm 2 | [Dynamic-linking native method java.io.FileOutputStream.writeBytes ... JNI] 2019/12/05 16:40:45 | INFO | jvm 2 | java.lang.NullPointerException 2019/12/05 16:40:45 | INFO | jvm 2 | [Dynamic-linking native method java.lang.Throwable.getStackTraceDepth ... JNI] 2019/12/05 16:40:45 | INFO | jvm 2 | [Dynamic-linking native method java.lang.Throwable.getStackTraceElement ... JNI] 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarVerifier.processEntry(JarVerifier.java:303) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarVerifier.update(JarVerifier.java:230) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarFile.initializeVerifier(JarFile.java:383) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JarFile.ensureInitialization(JarFile.java:612) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.util.jar.JavaUtilJarAccessImpl.ensureInitialization(JavaUtilJarAccessImpl.java:69) 2019/12/05 16:40:45 | INFO | jvm 2 | at sun.misc.URLClassPath$JarLoader$2.getManifest(URLClassPath.java:991) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader.defineClass(URLClassLoader.java:451) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader.access$100(URLClassLoader.java:74) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader$1.run(URLClassLoader.java:369) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader$1.run(URLClassLoader.java:363) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.security.AccessController.doPrivileged(Native Method) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.net.URLClassLoader.findClass(URLClassLoader.java:362) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.lang.ClassLoader.loadClass(ClassLoader.java:418) 2019/12/05 16:40:45 | INFO | jvm 2 | at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352) 2019/12/05 16:40:45 | INFO | jvm 2 | at java.lang.ClassLoader.loadClass(ClassLoader.java:351) 2019/12/05 16:40:45 | INFO | jvm 2 | at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:601) 2019/12/05 16:40:45 | INFO | jvm 2 | [Loaded java.util.IdentityHashMap$IdentityHashMapIterator from /opt/novell/sentinel/jdk/jre/lib/rt.jar] 2019/12/05 16:40:45 | INFO | jvm 2 | [Loaded java.util.IdentityHashMap$KeyIterator from /opt/novell/sentinel/jdk/jre/lib/rt.jar] -- Thanks & Regards, Sreeram From sreerama.naga at gmail.com Tue Dec 10 21:38:57 2019 From: sreerama.naga at gmail.com (brahmam) Date: Wed, 11 Dec 2019 03:08:57 +0530 Subject: Seeing JNI exception in 8u232 jdk builds In-Reply-To: References: Message-ID: Hi Paul, Thank you for your response. Please ignore the issue it is not relevant with openjdk8u232 builds any more. Regards, Sreeram On Wed, 11 Dec 2019, 01:56 Hohensee, Paul, wrote: > Can you provide us with a reproducer please? Attachments are stripped, so > hopefully the reproducer is small enough to inline into an email message. > If not, send me the file at hohensee at amazon.com and I'll file a JBS issue. > > Thanks, > Paul > > From adinn at redhat.com Wed Dec 11 12:51:46 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 11 Dec 2019 12:51:46 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: <41f68ca4-2a73-14f0-db8b-b2e912e39cb4@redhat.com> <745416b4-d0c7-81ed-b6b0-d1ec61713bd8@redhat.com> <1d2f4810-3448-49f3-d3a6-e9282634b029@redhat.com> Message-ID: On 10/12/2019 19:50, Volker Simonis wrote: > What makes you (or Andrew Haley) believe that Oracle would have to > "review and validate all of the open changes between 8u202 and 8u252" > (and validate against what)? As I wrote, I'm confident (and I think > you too) that the current 8u-dev (and therefore 8u252 as well) is > fully Java SE 8 MR2 compatible (aka. "passes the Java SE 8 MR 2 TCK). > As such, it can easily be used as a reference implementation for Java > SE 8. A "reference implementation" must pass the TCK, no more, no > less. Well, at the very least there is the the fact that Iris said so. I have absolutely no reason (or desire) to question her judgement. > If ReadHat as Maintainer of the OpenJDK 8 Updates project is happy > with how Oracle handles Java Specification updates and their > implementation in the OpenJDK versus their own, proprietary > implementation, I'll be silent and won't complain any more :) I wasn't intending to speak on behalf of Red Hat, nor Andrew Haley as jdk8u maintainer. If you re-read my comment you will note that /I/ (not /we/) merely /recommended/ accepting Oracle's judgement. To me that doesn't exactly have the ring of a corporate/8u maintainer imprimatur -- but your mileage may vary. So, I'm happy to provide the above qualification. n.b. as a more general comment regarding my capacity to speak for Red Hat, the company default is that staff state what they believe to be the case and only explicitly tag it as the corporate line when it is being deliberately offered as an explicit corporate line, usually to distinguish it from one's own views. That is the rare case because at Red Hat developers have a very large say in defining what the company line is. Where such a difference of view does arise we are still at liberty to express our own differing beliefs (and, yes, we usually do ;-). Regarding what the jdk8u project decides, I am definitely not in a position to state definitively how the project will be run and my post should/could never be taken as such. Firstly, I am merely a reviewer not a (or even /the/) maintainer. Secondly, Andrew Haley leads the jdk8u project on behalf of the whole community not just Red Hat. So, even if I might have been taken to be speaking for Red Hat I still could not speak for him or the community he represents. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adam.farley at uk.ibm.com Wed Dec 11 13:40:55 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 11 Dec 2019 13:40:55 +0000 Subject: [8u] RFR: JDK-8227715: GPLv2 files missing Classpath Exception In-Reply-To: <03766CF0-CA07-47A5-AEBD-A0E451FAD87B@amazon.com> References: <1ba62e8c7f31c1c0efd7a09fe0a6beb24c63080c.camel@redhat.com> <03766CF0-CA07-47A5-AEBD-A0E451FAD87B@amazon.com> Message-ID: Thanks Paul. :) Best Regards Adam Farley IBM Runtimes "Hohensee, Paul" wrote on 10/12/2019 20:16:31: > From: "Hohensee, Paul" > To: Severin Gehwolf , Adam Farley8 > , Java Core Libs > Cc: jdk8u-dev > Date: 10/12/2019 20:16 > Subject: [EXTERNAL] Re: [8u] RFR: JDK-8227715: GPLv2 files missing > Classpath Exception > > Lgtm. I'll sponsor it and tag the JBS issue with jdk8u-fix-request. > > Thanks, > Paul > > On 12/9/19, 4:55 AM, "jdk-updates-dev on behalf of Severin Gehwolf" > sgehwolf at redhat.com> wrote: > > Hi Adam, > > This looks like an RFR for OpenJDK 8u. Adding the appropriate mailing > list (jdk8u-dev not jdk-updates-dev; bcc'ed the latter) and fixing the > subject line. > > Thanks, > Severin > > On Thu, 2019-10-03 at 15:53 +0100, Adam Farley8 wrote: > > Hey all, > > > > Four GPLv2 files in 8u seem to be missing the classpath > exception from the > > copyright section. > > > > Requesting reviews and a sponsor. > > > > Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227715&d=DwIGaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=gGc3DrrilmAIAlwaC6- > vFT21V7D84BZe_VZQIf8fkwM&s=qVamtGae0EU0YxWoCT5MRcR6UDNhj24dXGfhRbiTSRI&e= > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227715_webrev_&d=DwIGaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=gGc3DrrilmAIAlwaC6- > vFT21V7D84BZe_VZQIf8fkwM&s=zIEaw-NL_AdX8VPn2_vZwSK09tAlhYEZOPax8dOuXG8&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > 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 gnu.andrew at redhat.com Thu Dec 12 03:59:58 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 03:59:58 +0000 Subject: [8u] RFR 8055351: sun/security/provider/DSA/TestAlgParameterGenerator.java failed with interrupted! (timed out?) In-Reply-To: <55f243e9-995d-1823-d227-7fc0dbe4bc01@redhat.com> References: <53e1f498-9dad-907b-799f-bb8a2a8ab7d6@redhat.com> <55f243e9-995d-1823-d227-7fc0dbe4bc01@redhat.com> Message-ID: On 02/12/2019 20:23, Martin Balao wrote: > Hi Andrew, > > On 11/28/19 1:12 AM, Andrew John Hughes wrote: >> >> Why is the copyright being changed here? The 8u version is already later >> than the change in this patch (presumably from 8181048), so can just be >> left alone. By changing it to 2019, you're creating a change unique to >> 8u which will has the potential to cause problems for other backports. > > Thanks for having a look. I'm not sure why I bumped the copyright date > here; it might have been an error as I cannot find any reasons. > > Webrev.01: > http://cr.openjdk.java.net/~mbalao/webrevs/8055351/8055351.8u.jdk.webrev.01/ > > Thanks, > Martin.- > Thanks. Looks good. -- 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 Thu Dec 12 04:17:03 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 04:17:03 +0000 Subject: [8u] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <273b3a83-f3e5-2bc0-d7da-da3774a57287@redhat.com> References: <273b3a83-f3e5-2bc0-d7da-da3774a57287@redhat.com> Message-ID: <2257b662-e339-4777-a024-c05e7f6ff467@redhat.com> On 21/11/2019 03:50, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 8131778 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8131778/8131778.8u.hotspot.webrev.00/ > > Differences from JDK baseline patch: > > * src/cpu/x86/vm/vm_version_x86.cpp > * 2nd hook does not apply cleanly because 8134553 [2] and 8073108 [3] > are not in 8u. Note: 8073108 [3] backport to 8u is in progress [4]. > Manually applied change without further conflicts. > > This backport is necessary for feature parity between OpenJDK and Oracle > JDK. > > Testing: > > I could verify there are no regressions in x86_64: > > [martin at vmhost bin]$ ./java -XX:+UseAES -XX:UseSSE=2 > -XX:+PrintFlagsFinal -version| grep UseAES > bool UseAES := true > {product} > bool UseAESIntrinsics = false > {product} > openjdk version "1.8.0-internal-debug" > OpenJDK Runtime Environment (build > 1.8.0-internal-debug-martin_2019_11_20_15_40-b00) > OpenJDK 64-Bit Server VM (build 25.71-b00-debug, mixed mode) > > I don't have infrastructure to build and test on SPARC; but given that > there were no conflicts on SPARC part of the patch, I assume it's likely > to be okay. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8131778 > [2] - https://bugs.openjdk.java.net/browse/JDK-8134553 > [3] - https://bugs.openjdk.java.net/browse/JDK-8073108 > [4] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-November/010630.html > Looks like this patch no longer applies with 8073108 now committed. Can you please provide an updated version against current HEAD? In general, if a patch depends on an earlier patch, it is best to wait until the dependency is approved and committed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Dec 12 04:22:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 04:22:26 +0000 Subject: [8u] RFR 8133489: Better messaging for PKIX path validation matching In-Reply-To: <2c1600cb-106f-684b-6f15-ec7136121e31@redhat.com> References: <2c1600cb-106f-684b-6f15-ec7136121e31@redhat.com> Message-ID: On 18/11/2019 18:08, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 8133489 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8133489/8133489.8u.jdk.webrev.00/ > > Changes for 8u: > > * KeyUsageMatters.java > * 1st hook does not apply cleanly because "* @modules > java.base/sun.security.util" line (from the hook context) is not present > in 8u. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8133489 > Approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Dec 12 04:30:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 04:30:27 +0000 Subject: [8u] RFR 8134424: BlockDataInputStream.readUTFBody: size local StringBuffer with the given length In-Reply-To: <81afcfba-aa7b-6803-2a4f-bc47a3b87e47@azul.com> References: <81afcfba-aa7b-6803-2a4f-bc47a3b87e47@azul.com> Message-ID: <7d290eac-92c3-b787-64b7-889f5620ee24@redhat.com> On 28/11/2019 13:43, Yuri Nesterenko wrote: > Hi, > > please take a look at this request for review for OpenJDK 8 backport of > 8134424 [1]. > > Webrev is > > http://cr.openjdk.java.net/~yan/8134424/webrev.0 > > Patch applied cleanly with jdk8 specifics: path was changed. Also, > copyright date was set to 2019. > > The patch itself was discussed in > https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038684.html > > Thank you! > > --yan > > [1] https://bugs.openjdk.java.net/browse/JDK-8134424 > > Please don't alter the copyright date. The original patch is from 2016 and the target file already has a 2018 date. By altering the copyright date with this patch, you add a change not present in other versions of the patch and introduce the potential for conflicts with later backports. As is, with just path changes, this doesn't need review and can simply be approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Dec 12 04:36:36 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 04:36:36 +0000 Subject: 8u242 now in RAMPDOWN; 8u & 8u-dev FROZEN for commits Message-ID: As per the development process [0] and timeline [1], 8u242 is now in rampdown. The 8u-dev tree is frozen for commits while it transitions to 8u252 development. Please do not push any commits to 8u-dev until the all clear is given. I'm in the process of triaging the Oracle parity bugs and will approve & push any fixes that are ready to go. Any fixes still in development or review will be deferred to 8u252. I'll post a full summary when this process is complete. The 8u tree is closed for commits until jdk8u242-b05 is tested and pushed. This should happen within the next 24 hours. Once open, commits will require the jdk8u-critical-yes label. The 8u-dev tree will be re-opened once it is set to take commits for 8u252. [0] https://wiki.openjdk.java.net/display/jdk8u/Detailed+Process+Description [1] https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Dec 12 05:05:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 12 Dec 2019 05:05:52 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: References: Message-ID: <92198563-ec00-1f1e-ce63-cf5b08fa6df3@redhat.com> On 09/12/2019 10:55, Andrew Dinn wrote: > Hi Volker/Iris, > > Firstly, thanks to Oracle for offering to update the JDK8u specs and > contribute the necessary changes to re-implement the ALPN and RSASSA-PSS > APIs. > > That said, I can see Volker's point here. Putting the changes into both > 8u40 and 8u252 appears to add an extra redundant step as far as the > OpenJDK project is concerned. Is there a reason why the 8u40 backport is > needed? (more specifically, why does it need to be adopted as the RI?) > Is there any reason for Oracle to do the 8u40 backport before > backporting to 8u252 and publishing the latter changes? > > Of course, if the open project is provided with the relevant 8u252 > changes in a timely manner then I don't suppose the answers to the above > questions are critical. What dominates is the project's ability to > respond in time 1) to assimilate the ALPN and RSASSA-PSS API changes and > 2) to add TLS 1.3 support on top of those changes. I'll leave it to > others (including my Red Hat colleagues) who are more au fait with TLS > and the jdk8u schedule to comment on that issue. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > As the TLS 1.3 changes don't alter the spec, the only impetus to provide those changes is Oracle parity and so, it may be worth pushing that into the July CPU timeframe. It may be worth looking at what work can be done on TLS 1.3 before the specification changes are required in order to get a head start. The other concern regarding the specification changes is also having the relevant TCK changes deployed to those who have access to it. We equally would prefer not to be in a situation where the changes are in OpenJDK 8u252, but the TCK fails without requisite updates. 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 yan at azul.com Thu Dec 12 06:21:39 2019 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 12 Dec 2019 09:21:39 +0300 Subject: [8u] RFR 8134424: BlockDataInputStream.readUTFBody: size local StringBuffer with the given length In-Reply-To: <7d290eac-92c3-b787-64b7-889f5620ee24@redhat.com> References: <81afcfba-aa7b-6803-2a4f-bc47a3b87e47@azul.com> <7d290eac-92c3-b787-64b7-889f5620ee24@redhat.com> Message-ID: <01d27314-f3ca-4b36-8ba9-c48ff50fa1aa@azul.com> On 12.12.2019 07:30, Andrew John Hughes wrote: > > On 28/11/2019 13:43, Yuri Nesterenko wrote: >> Hi, >> >> please take a look at this request for review for OpenJDK 8 backport of >> 8134424 [1]. >> >> Webrev is >> >> http://cr.openjdk.java.net/~yan/8134424/webrev.0 >> >> Patch applied cleanly with jdk8 specifics: path was changed. Also, >> copyright date was set to 2019. >> >> The patch itself was discussed in >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038684.html >> >> Thank you! >> >> --yan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8134424 >> >> > Please don't alter the copyright date. The original patch is from 2016 > and the target file already has a 2018 date. By altering the copyright > date with this patch, you add a change not present in other versions of > the patch and introduce the potential for conflicts with later backports. > > As is, with just path changes, this doesn't need review and can simply > be approved. > > Thanks, Yes, right, thank you Andrew, I'll restore that line. --yan From navy.xliu at gmail.com Thu Dec 12 07:40:04 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Wed, 11 Dec 2019 23:40:04 -0800 Subject: does C1+CMS miss a storestore membar in jdk8u-shenandoah? Message-ID: Hi, Aarch64 & PowerPC community, I think this is only for arm and ppc because only they are use relaxed memory ordering. x86 and sparc use TSO so storestore membar doesn't matter for them. please correct me if I am wrong. I feel that C1's LIRGenerator::CardTableModRef_post_barrier(c1_LIRGenerator.cpp) misses a storestore membar for CMS on jdk8u. Could you review my observation? If I am right, I'd like to file a bug and fix it. One reference is oop.inline.hpp. CMS uses the following function: template inline void oop_store(volatile T* p, oop v) It will emit a write_mem_barrier before cardTable updates. Another reference is C2 code. GraphKit::write_barrier_post generates storeCM for CMS. // Smash zero into card if( !UseConcMarkSweepGC ) { __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release); } else { // Specialized path for CM store barrier __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, adr_type); } Actually, it's not only C1 has this bug. Template interpreter has this problem too. It only happens for aarch64. do_oop_store in templateTable_aarch64.cpp doesn't have any membar for CMS. By contrast, ppc64 does have a membar(StoreStore). (macroAssembly_ppc.cpp) // Write the card table byte. void MacroAssembler::card_table_write(jbyte* byte_map_base, Register Rtmp, Register Robj) { assert_different_registers(Robj, Rtmp, R0); load_const_optimized(Rtmp, (address)byte_map_base, R0); srdi(Robj, Robj, CardTableModRefBS::card_shift); li(R0, 0); // dirty if (UseConcMarkSweepGC) membar(Assembler::StoreStore); stbx(R0, Rtmp, Robj); } I also check the jdk11 and jdk14, c1 and template interpreter both consider concurrent_scanning case. please check out the following functions. so only jdk8u is at risk. CardTableBarrierSetC1::post_barrier CardTableBarrierSetAssembler::store_check thanks, --lx From yan at azul.com Thu Dec 12 09:23:47 2019 From: yan at azul.com (Yuri Nesterenko) Date: Thu, 12 Dec 2019 12:23:47 +0300 Subject: [8u] RFR 8134424: BlockDataInputStream.readUTFBody: size local StringBuffer with the given length In-Reply-To: <01d27314-f3ca-4b36-8ba9-c48ff50fa1aa@azul.com> References: <81afcfba-aa7b-6803-2a4f-bc47a3b87e47@azul.com> <7d290eac-92c3-b787-64b7-889f5620ee24@redhat.com> <01d27314-f3ca-4b36-8ba9-c48ff50fa1aa@azul.com> Message-ID: <9d52336a-d7c5-2d88-6cb7-7d7cb0dca805@azul.com> On 12.12.2019 09:21, Yuri Nesterenko wrote: > On 12.12.2019 07:30, Andrew John Hughes wrote: >> On 28/11/2019 13:43, Yuri Nesterenko wrote: >>> Hi, >>> >>> please take a look at this request for review for OpenJDK 8 backport of >>> 8134424 [1]. >>> >>> Webrev is >>> >>> http://cr.openjdk.java.net/~yan/8134424/webrev.0 >>> >>> Patch applied cleanly with jdk8 specifics: path was changed. Also, >>> copyright date was set to 2019. >>> >>> The patch itself was discussed in >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2016-February/038684.html >>> >>> Thank you! >>> >>> --yan >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8134424 >>> >>> >> Please don't alter the copyright date. The original patch is from 2016 >> and the target file already has a 2018 date. By altering the copyright >> date with this patch, you add a change not present in other versions of >> the patch and introduce the potential for conflicts with later backports. >> >> As is, with just path changes, this doesn't need review and can simply >> be approved. >> >> Thanks, > Yes, right, thank you Andrew, I'll restore that line. It is http://cr.openjdk.java.net/~yan/8134424/webrev.1/? now -- and Andrew, if you'd decide it should be pushed in rampdown time, you could take patch from there. Thank you! --yan From martin.doerr at sap.com Thu Dec 12 09:36:51 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 12 Dec 2019 09:36:51 +0000 Subject: does C1+CMS miss a storestore membar in jdk8u-shenandoah? In-Reply-To: References: Message-ID: Hi lx, seems like the following issue should get backported: https://bugs.openjdk.java.net/browse/JDK-8135018 Btw. I believe PPC is fine because C1 is not supported in 8u (at least not in the official repo). Best regards, Martin > -----Original Message----- > From: jdk8u-dev On Behalf Of Liu > Xin > Sent: Donnerstag, 12. Dezember 2019 08:40 > To: aarch64-port-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: does C1+CMS miss a storestore membar in jdk8u-shenandoah? > > Hi, Aarch64 & PowerPC community, > > I think this is only for arm and ppc because only they are use relaxed > memory ordering. x86 and sparc use TSO so storestore membar doesn't > matter > for them. please correct me if I am wrong. > > I feel that C1's > LIRGenerator::CardTableModRef_post_barrier(c1_LIRGenerator.cpp) misses > a > storestore membar for CMS on jdk8u. Could you review my observation? If I > am right, I'd like to file a bug and fix it. > > One reference is oop.inline.hpp. CMS uses the following function: > template inline void oop_store(volatile T* p, oop v) > It will emit a write_mem_barrier before cardTable updates. > > Another reference is C2 code. GraphKit::write_barrier_post generates > storeCM for CMS. > // Smash zero into card > if( !UseConcMarkSweepGC ) { > __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release); > } else { > // Specialized path for CM store barrier > __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, adr_type); > } > > Actually, it's not only C1 has this bug. Template interpreter has this > problem too. It only happens for aarch64. do_oop_store in > templateTable_aarch64.cpp doesn't have any membar for CMS. By contrast, > ppc64 does have a membar(StoreStore). > > (macroAssembly_ppc.cpp) > > // Write the card table byte. > void MacroAssembler::card_table_write(jbyte* byte_map_base, Register > Rtmp, > Register Robj) { > assert_different_registers(Robj, Rtmp, R0); > load_const_optimized(Rtmp, (address)byte_map_base, R0); > srdi(Robj, Robj, CardTableModRefBS::card_shift); > li(R0, 0); // dirty > if (UseConcMarkSweepGC) membar(Assembler::StoreStore); > stbx(R0, Rtmp, Robj); > } > > I also check the jdk11 and jdk14, c1 and template interpreter both > consider concurrent_scanning case. please check out the following > functions. so only jdk8u is at risk. > CardTableBarrierSetC1::post_barrier > CardTableBarrierSetAssembler::store_check > > thanks, > --lx From aph at redhat.com Thu Dec 12 10:18:38 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Dec 2019 10:18:38 +0000 Subject: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah? In-Reply-To: References: Message-ID: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> On 12/12/19 9:36 AM, Doerr, Martin wrote: > seems like the following issue should get backported: > https://bugs.openjdk.java.net/browse/JDK-8135018 > > Btw. I believe PPC is fine because C1 is not supported in 8u (at least not in the official repo). Oh yes, that's one of mine. We should backport it. -- 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 zgu at redhat.com Thu Dec 12 14:32:52 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Dec 2019 09:32:52 -0500 Subject: RFR: 8234096: Mutex rank ordering problem JVMTI LoadedClassesClosure and G1 SATB queue In-Reply-To: References: Message-ID: Looks good to me. Thanks, -Zhengyu On 11/19/19 6:56 AM, Roman Kennke wrote: > A user reported a mutex rank ordering problem between JVMTI > LoadedClassesClosure and G1's SATB queues. As far as I can tell, this is > caused by JDK-8187577: > > ClassLoaderData::loaded_classes_do() acquires the "Metaspace allocation > lock/5" and LoadedClassesClosure tries to enqueue it into G1's SATB > queue, thus attempts to acquire "SATB_Q_CBL_mon/16" > > See bug report for more details and discussion. > https://bugs.openjdk.java.net/browse/JDK-8234096 > > The bug is 8u-specific. I forward-ported the testcase to 11 and 14 (will > post that under different bug-ID asap), and could not reproduce it > there. I also analyzed the code path, and confirmed that the bug is > really not present there. > > The fix that I want to propose is simple: instead of enqueueing the oops > during loaded_classes_do() (and thus under lock), we can enqueue it > during extraction of same class-mirrors into the target array. This is > ok because there is no safepoint between the two phases. > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8234096/webrev.02/ > > Testing: The new test fails without the fix, and passes with it. > hotspot_all doesn't show regressions > > Can I please get a review for this change? > > Thanks, Roman > From akozlov at azul.com Thu Dec 12 16:27:45 2019 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 12 Dec 2019 19:27:45 +0300 Subject: [8u] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <2257b662-e339-4777-a024-c05e7f6ff467@redhat.com> References: <273b3a83-f3e5-2bc0-d7da-da3774a57287@redhat.com> <2257b662-e339-4777-a024-c05e7f6ff467@redhat.com> Message-ID: Hi, Martin, On 12.12.2019 07:17, Andrew John Hughes wrote: > > On 21/11/2019 03:50, Martin Balao wrote: >> http://cr.openjdk.java.net/~mbalao/webrevs/8131778/8131778.8u.hotspot.webrev.00/ >> > > Looks like this patch no longer applies with 8073108 now committed. Can > you please provide an updated version against current HEAD? > > In general, if a patch depends on an earlier patch, it is best to wait > until the dependency is approved and committed. > will you have a minute to update the webrev? I'm doing backports of JDK-8143925 and JDK-8146581 and now I'm on the point of sending RFRs, but they depends on this. I based my work on your initial patch. From experience, webrev/HEAD conflicts are minor ones and easy to resolve. Thanks, Anton From navy.xliu at gmail.com Thu Dec 12 19:51:17 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Thu, 12 Dec 2019 11:51:17 -0800 Subject: [aarch64-port-dev ] does C1+CMS miss a storestore membar in jdk8u-shenandoah? In-Reply-To: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> References: <2b433414-fab1-c63d-1e07-76ddd4abe298@redhat.com> Message-ID: hi, Martin and Andrew, Thank you to point out that JBS issue. I can backport and validate that. Yes, if powerpc doesn't have C1 in jdk8u, than it's safe. it's only about aarch64. thanks, --lx On Thu, Dec 12, 2019 at 2:18 AM Andrew Haley wrote: > On 12/12/19 9:36 AM, Doerr, Martin wrote: > > seems like the following issue should get backported: > > https://bugs.openjdk.java.net/browse/JDK-8135018 > > > > Btw. I believe PPC is fine because C1 is not supported in 8u (at least > not in the official repo). > > Oh yes, that's one of mine. We should backport it. > > -- > 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 alvdavi at amazon.com Thu Dec 12 21:08:31 2019 From: alvdavi at amazon.com (David Alvarez) Date: Thu, 12 Dec 2019 13:08:31 -0800 Subject: [8u] RFR 8231463: Fix runtime/RedefineTests/RedefineDoubleDelete.java test in 8u In-Reply-To: <9e98a776-3699-6125-b075-f9dfb718e7f4@redhat.com> References: <917c9bc4-41b2-7913-1100-8db1203f250e@redhat.com> <1FE9D5AB-978F-48D6-9F0A-BA57AC25A7EA@amazon.com> <9e98a776-3699-6125-b075-f9dfb718e7f4@redhat.com> Message-ID: <862039ea-8c16-dae6-cc82-d738805aaa89@amazon.com> Hi, I was running jtreg tier1 today for 8u242 and I noticed this issue reappearing. hotspot/test/runtime/RedefineTests/test8178870.sh is back in the repo. This is because 8178870 was added to openjdk8u242 [1] and to openjdk8u232 [2], but this patch was only added to openjdk8u232. When this merge [3] happens, the file popped back into existence I'll file a bug and mark it as jdk8u-critical-request so tier1 passes. David -- [1] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/cb028a891ac9 [2] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/628176d22495 [3] https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/2695509c59f8 On 2019-09-25 09:26, Zhengyu Gu wrote: > Hi Andrew, > >> >> My only worry is that the JDK I tested on is 8u222-b10, and so doesn't >> have the 8178870 patch, so are we sure this test is actually verifying >> the bug is fixed? >> > > This bug is related to JDK-8135322, does 8u222-b10 have this patch? > > Thanks, > > -Zhengyu > >> $ /usr/lib/jvm/icedtea-8/bin/java -version >> openjdk version "1.8.0_222" >> OpenJDK Runtime Environment (IcedTea 3.13.0) (Gentoo icedtea-3.13.0) >> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode) >> >> Thanks, >> From alvdavi at amazon.com Thu Dec 12 22:36:31 2019 From: alvdavi at amazon.com (David Alvarez) Date: Thu, 12 Dec 2019 14:36:31 -0800 Subject: [8u] RFR 8235850: [TESTBUG] Remove test/runtime/RedefineTests/test8178870.sh Message-ID: <8e40cc03-78d9-168e-f89a-6ed0a93f335d@amazon.com> Hi, I'm requesting a RFR for JDK-8235850. This patch does only one thing, remove test/runtime/RedefineTests/test8178870.sh. This file was added on JDK-8178870 [1] and removed in JDK-8231463 [2] (RedefineDoubleDelete.java no longer needing the use of the sh). Due to merge of jdk8u and jdk8u-dev, the file has reappeared. However, RedefineDoubleDelete.java does look good. bug: https://bugs.openjdk.java.net/browse/JDK-8235850 webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8235850/webrev.8u.00/ This is causing tier1 testing to fail for 8u242, so once reviewed I'll make it jdk8u-critical-request. - David [1] https://bugs.openjdk.java.net/browse/JDK-8178870 [2] https://bugs.openjdk.java.net/browse/JDK-8231463 From hohensee at amazon.com Fri Dec 13 00:31:04 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 13 Dec 2019 00:31:04 +0000 Subject: [8u] RFR 8235850: [TESTBUG] Remove test/runtime/RedefineTests/test8178870.sh In-Reply-To: <8e40cc03-78d9-168e-f89a-6ed0a93f335d@amazon.com> References: <8e40cc03-78d9-168e-f89a-6ed0a93f335d@amazon.com> Message-ID: Lgtm. Paul ?On 12/12/19, 2:37 PM, "jdk8u-dev on behalf of David Alvarez" wrote: Hi, I'm requesting a RFR for JDK-8235850. This patch does only one thing, remove test/runtime/RedefineTests/test8178870.sh. This file was added on JDK-8178870 [1] and removed in JDK-8231463 [2] (RedefineDoubleDelete.java no longer needing the use of the sh). Due to merge of jdk8u and jdk8u-dev, the file has reappeared. However, RedefineDoubleDelete.java does look good. bug: https://bugs.openjdk.java.net/browse/JDK-8235850 webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8235850/webrev.8u.00/ This is causing tier1 testing to fail for 8u242, so once reviewed I'll make it jdk8u-critical-request. - David [1] https://bugs.openjdk.java.net/browse/JDK-8178870 [2] https://bugs.openjdk.java.net/browse/JDK-8231463 From hohensee at amazon.com Fri Dec 13 01:09:16 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 13 Dec 2019 01:09:16 +0000 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: <65a1f09e-7fda-52fe-4bd3-c087f209ba20@redhat.com> References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> <65a1f09e-7fda-52fe-4bd3-c087f209ba20@redhat.com> Message-ID: <0FD81A71-A716-4F08-8CB1-958246023514@amazon.com> Thank you, Andrew, for your review. I've tagged 8029629 with jdk8u-fix-request: the patch applies cleanly and its patched test passes. Once 8029629 is in place, the patch for 8208715 applies cleanly and its patched test also passes, so both can be approved without further review. Paul ?On 12/4/19, 11:15 AM, "jdk8u-dev on behalf of Andrew Hughes" wrote: On 29/08/2019 21:29, Guo, James wrote: > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8208715 > https://hg.openjdk.java.net/jdk/jdk/rev/41257a58a588 > > Original patch does not apply cleanly to 8u: > 1. java.base/unix doesn't exist. I had to move the change of java.base/unix/classes/java/lang/ProcessImpl.java > to solaris/classes/java/lang/UNIXProcess.java to make the patch work in Unix. > 2. Due to the conflict in test/java/lang/ProcessBuilder/Basic.java, I had to replace the testcase that checks > Process.waitFor(timeout, TimeUnit.MILLISECONDS) with the one in 12u[1] and add a millisElapsedSince(long startNanoTime) method for it. > > 8u webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8208715/webrev.8u.00/ > > Testing: x86_64 build, affected tests [2], tier1 > > Thanks, > James Guo > > [1] http://hg.openjdk.java.net/jdk/jdk/file/41257a58a588/test/jdk/java/lang/ProcessBuilder/Basic.java#l2410 > [2] https://bugs.openjdk.java.net/secure/attachment/78016/JI9056393.java > > > > Am I right in thinking that the additional test changes are from JDK-8029629? https://hg.openjdk.java.net/jdk/jdk/rev/8e5afc67dca87179 If so, that bug should be backported first. 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 From gil at azul.com Fri Dec 13 01:14:28 2019 From: gil at azul.com (Gil Tene) Date: Fri, 13 Dec 2019 01:14:28 +0000 Subject: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 In-Reply-To: <76D4AF59-9F39-45A8-A2F5-A8CBCC000E0F@azul.com> References: <92198563-ec00-1f1e-ce63-cf5b08fa6df3@redhat.com> <76D4AF59-9F39-45A8-A2F5-A8CBCC000E0F@azul.com> Message-ID: > From: Andrew John Hughes > Subject: Re: Proposal: ALPN and RSASSA-PSS APIs for Java SE 8 and JDK 8 > Date: 12 December 2019 at 08:05:52 GMT+3 > To: Andrew Dinn , Volker Simonis , Iris Clark > Cc: jdk8u-dev > > > > On 09/12/2019 10:55, Andrew Dinn wrote: >> Hi Volker/Iris, >> >> Firstly, thanks to Oracle for offering to update the JDK8u specs and >> contribute the necessary changes to re-implement the ALPN and RSASSA-PSS >> APIs. >> >> That said, I can see Volker's point here. Putting the changes into both >> 8u40 and 8u252 appears to add an extra redundant step as far as the >> OpenJDK project is concerned. Is there a reason why the 8u40 backport is >> needed? (more specifically, why does it need to be adopted as the RI?) >> Is there any reason for Oracle to do the 8u40 backport before >> backporting to 8u252 and publishing the latter changes? >> >> Of course, if the open project is provided with the relevant 8u252 >> changes in a timely manner then I don't suppose the answers to the above >> questions are critical. What dominates is the project's ability to >> respond in time 1) to assimilate the ALPN and RSASSA-PSS API changes and >> 2) to add TLS 1.3 support on top of those changes. I'll leave it to >> others (including my Red Hat colleagues) who are more au fait with TLS >> and the jdk8u schedule to comment on that issue. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > > As the TLS 1.3 changes don't alter the spec, the only impetus to provide > those changes is Oracle parity and so, it may be worth pushing that into > the July CPU timeframe. It may be worth looking at what work can be done > on TLS 1.3 before the specification changes are required in order to get > a head start. When it comes to adding TLS 1.3 support to OpenJDK 8u, there is a good starting point in https://github.com/openjsse/openjsse . In it's current form it does not replace or change the default 8u jsse implementation. It is an optional JSSE provider (hence not needing any spec changes) and is based on a backport of the 11u TLS1.3 functionality to Java SE 8. It uses it's own namespace (org.openjsse). For a built-in support for TLS 1.3, we'd probably want to change the built-in 8u jsse provider, which will have an effect very similar to bringing the various packages under org.openjsse back to the root level and dealing with any conflicts and integration into the current namespace. As some of the Azul engineers worked on OpenJSSE and are familiar with the details involved with 8 backporting and compatibility, we'd be happy to contribute to or lead that effort. > > The other concern regarding the specification changes is also having the > relevant TCK changes deployed to those who have access to it. We equally > would prefer not to be in a situation where the changes are in OpenJDK > 8u252, but the TCK fails without requisite updates. When the spec is updated, the TCK will be too. To be compliant with the new spec MR, we'd have to pass the new TCK. But depending on how the spec and TCK are updated, it may not require the new functionality, but simply allow it. E.g. the MR2 update to JSR337 (see https://jcp.org/aboutJava/communityprocess/maintenance/jsr337/jsr337-mr2-changes.html ) relaxed the requirements on cryptographic algorithm names but did not impose additional restrictions that caused previous implememtations to become non-compliant. I am hoping that MR3 can be be similarly achieved. Iris, do you think we'd be able to add the new ALPN and RSASSA-PSS API capabilities as allowed things that are not absolutely required? ? Gil. From gnu.andrew at redhat.com Fri Dec 13 03:14:42 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 03:14:42 +0000 Subject: [8u] RFR 8173956: KeyStore regression due to default keystore being changed to PKCS12 In-Reply-To: <9069972c-26ab-07e9-c16f-d8dc7c40cb72@redhat.com> References: <9069972c-26ab-07e9-c16f-d8dc7c40cb72@redhat.com> Message-ID: <1eb5736c-d3b0-e965-cbb9-5326c08033b6@redhat.com> On 21/11/2019 21:30, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 8173956 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8173956/8173956.8u.jdk.webrev.00/ > > Differences from JDK baseline patch: > > * Path changes > > * src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java > * Copyright date. 2017 year is already there because 8181692 [2] is in > 8u already (despite being older than 8173956). > > Testing: > > * sun/security/pkcs12/MixedcaseAlias.java > * Passed > > This backport would bring parity between OpenJDK and Oracle JDK. > > Thanks, > Martin.- > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8173956 > [2] - https://bugs.openjdk.java.net/browse/JDK-8181692 > Looks fine. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 13 06:13:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 06:13:06 +0000 Subject: [8u] RFR 8185898: setRequestProperty(key, null) results in HTTP header without colon in request In-Reply-To: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com> References: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com> Message-ID: <2ebea13d-c1fd-dc38-c080-1a596531ffe1@redhat.com> On 26/11/2019 12:46, Yuri Nesterenko wrote: > Hi, > > please review this request for a backport to 8u. > > Original issue: > > ??? https://bugs.openjdk.java.net/browse/JDK-8185898 > > ??? https://hg.openjdk.java.net/jdk/jdk/rev/0211b062843d > > The patch itself applied good enough; I had to adapt the test for JDK8. > > Look for webrev here: > > ??? http://cr.openjdk.java.net/~yan/8185898/webrev.0/ > > Thank you! > > --yan > > It doesn't matter for this testcase, but List.of and Map.of create unmodifiable collections, so if they are exposed outside the scope of a single method, they should be wrapped using Collections.unmodifiableMap/List. Otherwise, looks ok. I assume the testcase passes with the 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 gnu.andrew at redhat.com Fri Dec 13 06:35:38 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 06:35:38 +0000 Subject: [8u] RFR: 8195088: [TEST_BUG] StartManagementAgent got unexpected exception In-Reply-To: <85c52e84-e827-9af1-3cec-6dff26daeda0@oracle.com> References: <85c52e84-e827-9af1-3cec-6dff26daeda0@oracle.com> Message-ID: <446f1d58-eb0d-4944-55b1-5f691d566f6a@redhat.com> On 03/10/2019 00:47, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > It looks good and applies cleanly. > So, I'm not sure you really need a review for this. > > Thanks, > Serguei > > On 10/1/19 06:01, Severin Gehwolf wrote: >> Hi, >> >> Please review this OpenJDK 8u vs. Oracle JDK 8 parity patch. I wasn't >> sure whether I need review for this one as the bug in question is a JDK >> 8-only bug and the patch applies as-is. Anyway, here it is: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8195088 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8195088/01/webrev/ >> >> Testing: StartManagementAgent.java test fails prior and passes after >> this patch. >> >> Thoughts? >> >> Thanks, >> Severin >> > What "applies cleanly"? As far as I can see, this is part of JDK-8165736. As the rest of 8165736 is not being applied, then yes, it needs review. Approved. I'll push it as part of b05. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 13 06:58:04 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 06:58:04 +0000 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> Message-ID: <488ed500-8998-83d1-1721-e43cbf5e74ef@redhat.com> On 05/08/2019 17:58, Martin Balao wrote: > Hi, > > I'd like to request a review for the jdk8u backport of JDK-8200400 [1]: > > * > https://cr.openjdk.java.net/~mbalao/webrevs/8200400/8200400.webrev.jdk8u.jdk.00/ > > Changes: > > * Paths > > * java.security change per OS file > > * Sasl.java > * copyright date > * documentation hooks did not apply cleanly > > * Test > * @module jtreg tag removed > * @library path changed > * Asserts import changed > > Testing: > > * javax/security/sasl/Sasl/DisabledMechanisms.java passed > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8200400 > Looks good, but needs to wait on CSR JDK-8230491 being approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 13 06:58:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 06:58:09 +0000 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> Message-ID: <9f142a65-23f4-8672-5bc0-291e0888d8f9@redhat.com> On 05/08/2019 17:58, Martin Balao wrote: > Hi, > > I'd like to request a review for the jdk8u backport of JDK-8200400 [1]: > > * > https://cr.openjdk.java.net/~mbalao/webrevs/8200400/8200400.webrev.jdk8u.jdk.00/ > > Changes: > > * Paths > > * java.security change per OS file > > * Sasl.java > * copyright date > * documentation hooks did not apply cleanly > > * Test > * @module jtreg tag removed > * @library path changed > * Asserts import changed > > Testing: > > * javax/security/sasl/Sasl/DisabledMechanisms.java passed > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8200400 > Looks good, but needs to wait on CSR JDK-8230491 being approved. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 13 06:59:01 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 06:59:01 +0000 Subject: [8u] RFR 8200400: Allow Sasl mechanisms to be restricted In-Reply-To: References: <42222cb1-3643-0833-62d4-aa586e8a48c9@redhat.com> <7EEE0914-6301-4452-963B-F6A57C7F265B@oracle.com> <7e2399fd-607b-ace0-0c00-34a72adbbb1a@redhat.com> Message-ID: <42666fee-1366-9d2f-41da-83949fa5b660@redhat.com> On 02/12/2019 17:05, Martin Balao wrote: > Hi, > > Ping. > > Can someone please have a look at this? > > CSR review pending: https://bugs.openjdk.java.net/browse/JDK-8230491 I've commented on this to try to get it moving. > > Patch review pending: > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-August/009945.html Reviewed. > > Approval is also pending. Please wait until you have a reviewed patch before requesting approval. In this case, it should also wait for the approved CSR as well. > > Thanks, > Martin.- > > > On 8/19/19 7:21 PM, Martin Balao wrote: >> I've requested the JDK-11 and JDK-8 backports of 8229767 [1]. >> >> Can any JDK-11/JDK-8 maintainer please approve both 8229767 [1] and >> 8200400 [2] backports? > > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 13 07:01:13 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 07:01:13 +0000 Subject: [8u] RFR 8185898: setRequestProperty(key, null) results in HTTP header without colon in request In-Reply-To: <82ce6cda-82c6-e30d-92a9-62c2893eabbe@azul.com> References: <4a4fd001-74c5-6017-7047-b69519fb3095@azul.com> <2ebea13d-c1fd-dc38-c080-1a596531ffe1@redhat.com> <82ce6cda-82c6-e30d-92a9-62c2893eabbe@azul.com> Message-ID: <0ca408e6-8fe4-abde-a3ce-2403e1e5a0bd@redhat.com> On 13/12/2019 06:36, Yuri Nesterenko wrote: > > On 13.12.2019 09:13, Andrew John Hughes wrote: >> On 26/11/2019 12:46, Yuri Nesterenko wrote: >>> Hi, >>> >>> please review this request for a backport to 8u. >>> >>> Original issue: >>> >>> ??? https://bugs.openjdk.java.net/browse/JDK-8185898 >>> >>> ??? https://hg.openjdk.java.net/jdk/jdk/rev/0211b062843d >>> >>> The patch itself applied good enough; I had to adapt the test for JDK8. >>> >>> Look for webrev here: >>> >>> ??? http://cr.openjdk.java.net/~yan/8185898/webrev.0/ >>> >>> Thank you! >>> >>> --yan >>> >>> >> It doesn't matter for this testcase, but List.of and Map.of create >> unmodifiable collections, so if they are exposed outside the scope of a >> single method, they should be wrapped using >> Collections.unmodifiableMap/List. >> >> Otherwise, looks ok. I assume the testcase passes with the patch? >> >> Thanks, > > Thank you Andrew! > > Yes, it pass. > > Should I push now? > > --yan > 8u-dev is currently frozen [0]. I'll handle pushing as part of b05. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010755.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 13 07:04:44 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 13 Dec 2019 07:04:44 +0000 Subject: [8u] RFR 8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug In-Reply-To: <0FD81A71-A716-4F08-8CB1-958246023514@amazon.com> References: <029E8BC0-B1BC-4FED-97CA-6763D2138E36@amazon.com> <65a1f09e-7fda-52fe-4bd3-c087f209ba20@redhat.com> <0FD81A71-A716-4F08-8CB1-958246023514@amazon.com> Message-ID: <0c046f17-84ec-d051-d52e-0b4273ec30c7@redhat.com> On 13/12/2019 01:09, Hohensee, Paul wrote: > Thank you, Andrew, for your review. I've tagged 8029629 with jdk8u-fix-request: the patch applies cleanly and its patched test passes. Once 8029629 is in place, the patch for 8208715 applies cleanly and its patched test also passes, so both can be approved without further review. > > Paul > I've approved both and will push them as part of b05. 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 mbalao at redhat.com Fri Dec 13 13:39:04 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 13 Dec 2019 10:39:04 -0300 Subject: [8u] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: References: <273b3a83-f3e5-2bc0-d7da-da3774a57287@redhat.com> <2257b662-e339-4777-a024-c05e7f6ff467@redhat.com> Message-ID: <77734a18-eedd-cf23-00ae-74b6cbfa0060@redhat.com> Hi, Looks to me that now that 8073108 is in 8u-dev, 8131778 [1] applies cleanly (so there is no need for a webrev). As soon as it's approved [2], I can push if you all agree. Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk/jdk/rev/c1b52e665b47 [2] - https://bugs.openjdk.java.net/browse/JDK-8131778 On 12/12/19 1:27 PM, Anton Kozlov wrote: > Hi, Martin, > > On 12.12.2019 07:17, Andrew John Hughes wrote: >> >> On 21/11/2019 03:50, Martin Balao wrote: >>> http://cr.openjdk.java.net/~mbalao/webrevs/8131778/8131778.8u.hotspot.webrev.00/ >>> >> >> Looks like this patch no longer applies with 8073108 now committed. Can >> you please provide an updated version against current HEAD? >> >> In general, if a patch depends on an earlier patch, it is best to wait >> until the dependency is approved and committed. >> > > will you have a minute to update the webrev? > > I'm doing backports of JDK-8143925 and JDK-8146581 and now I'm on the point of sending RFRs, but they depends on this. > > I based my work on your initial patch. From experience, webrev/HEAD conflicts are minor ones and easy to resolve. > > Thanks, > Anton > > From linzang at tencent.com Mon Dec 16 10:26:03 2019 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 16 Dec 2019 10:26:03 +0000 Subject: Remove the experimental option UseCGroupMemoryLimitForHeap? Message-ID: <993656AD-5725-4094-8ED5-7562E759CC30@tencent.com> Dear All, I would like to discuss with you whether the experimental option ?UseCGroupMemoryLimitForHeap? is unnecessary now? I see there is only one place in the code using this flag, and the logic there is considering cgroup memory limit when calculating heap size, but it is duplicated with os::physical_memory() since there is same implementation for container support. So is it ok if I remove this flag? BRs, Lin From akashche at redhat.com Mon Dec 16 11:02:20 2019 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 16 Dec 2019 11:02:20 +0000 Subject: [8u] RFR: 8221246: NullPointerException within Win32ShellFolder2 In-Reply-To: References: Message-ID: On 11/11/2019 01:46 PM, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8221246 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221246 > > Original review thread: > https://mail.openjdk.java.net/pipermail/awt-dev/2019-June/015273.html > > 11u changeset: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2f95ca679634 > > 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8221246/webrev.00/ > > Patch does not apply cleanly because of the differences in import > section, all other code changes, besides imports, are left the same. Politely pinging about this backport. -- -Alex From sgehwolf at redhat.com Mon Dec 16 13:13:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 16 Dec 2019 14:13:36 +0100 Subject: Remove the experimental option UseCGroupMemoryLimitForHeap? In-Reply-To: <993656AD-5725-4094-8ED5-7562E759CC30@tencent.com> References: <993656AD-5725-4094-8ED5-7562E759CC30@tencent.com> Message-ID: <6ec82938f3a52790359bf577e5e3089a8f5bcc4d.camel@redhat.com> On Mon, 2019-12-16 at 10:26 +0000, linzang(??) wrote: > Dear All, > I would like to discuss with you whether the experimental option ?UseCGroupMemoryLimitForHeap? is unnecessary now? > I see there is only one place in the code using this flag, and the logic there is considering cgroup memory limit when calculating heap size, but it is duplicated with os::physical_memory() since there is same implementation for container support. > So is it ok if I remove this flag? It would be a compatibility concern. There are users out there which still use it. So we cannot just remove the flag and fail the VM startup if provided. Perhaps removal of code in Arguments::set_heap_size like done for JDK 11 in JDK-8194086, but still accepting the VM option could be a possibility. Perhaps also printinting a warning that the option does nothing along the way would be good to. It depends what you have in mind, but it seems - unless there is a good reason - it would be wiser to leave that code as-is. Thanks, Severin From linzang at tencent.com Mon Dec 16 15:16:48 2019 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Mon, 16 Dec 2019 15:16:48 +0000 Subject: Remove the experimental option UseCGroupMemoryLimitForHeap?(Internet mail) In-Reply-To: <6ec82938f3a52790359bf577e5e3089a8f5bcc4d.camel@redhat.com> References: <993656AD-5725-4094-8ED5-7562E759CC30@tencent.com> <6ec82938f3a52790359bf577e5e3089a8f5bcc4d.camel@redhat.com> Message-ID: <4F88C47F-35E3-4E47-8B5A-7FF8241A71EC@tencent.com> Dear Severin, Thanks for your comments! The issue I see is that if ?UseCGroupMemoryLimitForHeap? is set to true, the "if {}" codes get run twice, once in physical_memory(), and once in the "if {}". And when works in container, the result is same no matter what value the ? UseCGroupMemoryLimitForHeap? is set to. I agree it is a back port of JDK-8194086, and we should keep the flag for compatibility concern. It seems to me that there is no high risk here have those dup codes, I am just curious about whether we should omit them:) Thanks, Lin > On Dec 16, 2019, at 9:13 PM, Severin Gehwolf wrote: > > On Mon, 2019-12-16 at 10:26 +0000, linzang(??) wrote: >> Dear All, >> I would like to discuss with you whether the experimental option ?UseCGroupMemoryLimitForHeap? is unnecessary now? >> I see there is only one place in the code using this flag, and the logic there is considering cgroup memory limit when calculating heap size, but it is duplicated with os::physical_memory() since there is same implementation for container support. >> So is it ok if I remove this flag? > > It would be a compatibility concern. There are users out there which > still use it. So we cannot just remove the flag and fail the VM startup > if provided. > > Perhaps removal of code in Arguments::set_heap_size like done for JDK > 11 in JDK-8194086, but still accepting the VM option could be a > possibility. Perhaps also printinting a warning that the option does > nothing along the way would be good to. > > It depends what you have in mind, but it seems - unless there is a good > reason - it would be wiser to leave that code as-is. > > Thanks, > Severin > > > > From neugens at redhat.com Mon Dec 16 15:40:22 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 16 Dec 2019 16:40:22 +0100 Subject: [JFR backport] RFC: CSR for JFR backport suggests not leaving out the package-info Message-ID: [I'm sending this on behalf of Marcus which is not on the list] Hi all, Here is the fix for the missing package info! Jira: https://bugs.openjdk.java.net/browse/JDK-8236002 Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.0/ Kind regards, Marcus -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Dec 16 15:51:36 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 16 Dec 2019 16:51:36 +0100 Subject: [JFR backport] RFC: CSR for JFR backport suggests not leaving out the package-info In-Reply-To: References: Message-ID: Approved. Cheers, Mario On Mon, Dec 16, 2019 at 4:40 PM Mario Torre wrote: > > [I'm sending this on behalf of Marcus which is not on the list] > > Hi all, > > Here is the fix for the missing package info! > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236002 > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.0/ > > Kind regards, > Marcus > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Dec 16 16:50:08 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 16 Dec 2019 17:50:08 +0100 Subject: [JFR Backport] 8236008: Some backup files were accidentally left in the hotspot tree Message-ID: Hi all, Some files were accidentally left in the hotspot tree during the first backport patch. This patch removes them: http://cr.openjdk.java.net/~neugens/JDK-8236008/webrev.00/ Cheers, Mario P.S. This patch is meant for the incubator repository, but I still need another OpenJDK 8u reviewer to approve, thanks! -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Mon Dec 16 17:25:30 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 16 Dec 2019 12:25:30 -0500 Subject: [8u] RFR 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Message-ID: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> Hi, Please review this 8u backport, as Oracle backported this patch in 8u221 Original bug: https://bugs.openjdk.java.net/browse/JDK-8210776 Original webrev: http://cr.openjdk.java.net/~prr/8210776/ Original review thread: https://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014607.html 8u webrev: main: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/webrev.00/ corba: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/corba/webrev.00/ hotspot: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/hotspot/webrev.00/ jaxp: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxp/webrev.00/ jaxws: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxws/webrev.00/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/langtools/webrev.00/ nashorn: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/nashorn/webrev.00/ Thanks, -Zhengyu From gnu.andrew at redhat.com Mon Dec 16 17:39:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Dec 2019 17:39:47 +0000 Subject: [8u] RFR 8131778: java disables UseAES flag when using VIS=2 on sparc In-Reply-To: <77734a18-eedd-cf23-00ae-74b6cbfa0060@redhat.com> References: <273b3a83-f3e5-2bc0-d7da-da3774a57287@redhat.com> <2257b662-e339-4777-a024-c05e7f6ff467@redhat.com> <77734a18-eedd-cf23-00ae-74b6cbfa0060@redhat.com> Message-ID: <35c1dd3d-65b0-42ce-0043-6de564088a68@redhat.com> On 13/12/2019 13:39, Martin Balao wrote: > Hi, > > Looks to me that now that 8073108 is in 8u-dev, 8131778 [1] applies > cleanly (so there is no need for a webrev). As soon as it's approved > [2], I can push if you all agree. > > Thanks, > Martin.- > > -- > [1] - http://hg.openjdk.java.net/jdk/jdk/rev/c1b52e665b47 > [2] - https://bugs.openjdk.java.net/browse/JDK-8131778 > 8u-dev is currently frozen [0]. So any pushes will have to wait until the freeze is lifted. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010755.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Dec 16 18:14:26 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Dec 2019 18:14:26 +0000 Subject: [8u] RFR 8201627: Kerberos sequence number issues In-Reply-To: References: Message-ID: On 25/07/2019 22:51, Martin Balao wrote: > Hi, > > I'd like to request a review for the jdk8u backport of 8201627 [1]: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8201627/8201627.webrev.00.jdk8u.jdk/ > > Changes that were needed to the baseline patch: > > * Copyright dates > > * Paths > > * GetPropertyAction.privilegedGetProperty receives no default value in > jdk8u (InitSecContextToken.java) I think there's a case here for backporting JDK-8154231 or at least bringing over the remaining two methods for GetPropertyAction that weren't part of JDK-8181048. > > * test/sun/security/krb5/auto/BasicProc.java (several adjustments) What are these "several adjustments"? It looks to me like the refactoring in JDK-8186884 needs backporting first, as this patch seems to drag in some of those changes as well. > > * test/sun/security/krb5/auto/Basic.java (minor adjustments) > > Testing: > > * No regressions found in sun/security/krb5/auto > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8201627 > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From hohensee at amazon.com Mon Dec 16 18:29:24 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 16 Dec 2019 18:29:24 +0000 Subject: [JFR Backport] 8236008: Some backup files were accidentally left in the hotspot tree In-Reply-To: References: Message-ID: <2908BEA9-80D6-4ADD-A04F-50930690BDB9@amazon.com> Lgtm. Paul ?On 12/16/19, 8:51 AM, "jdk8u-dev on behalf of Mario Torre" wrote: Hi all, Some files were accidentally left in the hotspot tree during the first backport patch. This patch removes them: http://cr.openjdk.java.net/~neugens/JDK-8236008/webrev.00/ Cheers, Mario P.S. This patch is meant for the incubator repository, but I still need another OpenJDK 8u reviewer to approve, thanks! -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Dec 16 18:39:00 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 16 Dec 2019 19:39:00 +0100 Subject: [JFR Backport] 8236008: Some backup files were accidentally left in the hotspot tree In-Reply-To: <2908BEA9-80D6-4ADD-A04F-50930690BDB9@amazon.com> References: <2908BEA9-80D6-4ADD-A04F-50930690BDB9@amazon.com> Message-ID: Thanks! Cheers, Mario On Mon, Dec 16, 2019 at 7:29 PM Hohensee, Paul wrote: > > Lgtm. > Paul > > ?On 12/16/19, 8:51 AM, "jdk8u-dev on behalf of Mario Torre" wrote: > > Hi all, > > Some files were accidentally left in the hotspot tree during the first > backport patch. > > This patch removes them: > > http://cr.openjdk.java.net/~neugens/JDK-8236008/webrev.00/ > > Cheers, > Mario > > P.S. This patch is meant for the incubator repository, but I still > need another OpenJDK 8u reviewer to approve, thanks! > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Mon Dec 16 19:07:48 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 16 Dec 2019 19:07:48 +0000 Subject: [8u] RFR backport of 8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails In-Reply-To: <2991D191-9F80-48AB-B6D5-2643AB9A38D8@amazon.com> References: <2991D191-9F80-48AB-B6D5-2643AB9A38D8@amazon.com> Message-ID: <8fe28751-daf5-4015-4ff3-431f2ddbcc75@redhat.com> On 06/12/2019 23:03, Verghese, Clive wrote: > Hi, > > I would like to request backport of JDK-8213119 to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213119 > Original: https://hg.openjdk.java.net/jdk/jdk/rev/85d7af399ef5 > Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8213119/webrev.8u.00/ > > The patch is marked as 8u241but not yet in openjdk8u 242. > > Patch did not apply cleanly, minor modifications were required. Other than the mismatch in Copyrights, the following hunks did not apply cleanly. > > In file ?test/java/awt/GraphicsDevice/CheckDisplayModes.java?, hunk 2 did not apply cleanly. > In file ?macosx/native/sun/awt/CGraphicsDevice.m?, hunk 2 did not apply cleanly. > The test was not present in ProblemList.txt. > > Validated that the test is running successfully. > > Regards, > Clive Verghese > I see some odd whitespace differences between this patch and the 11u version: @@ -26,7 +25,7 @@ - if (thisBpp != bpp || (int)CGDisplayModeGetHeight(cRef) != h || (int)CGDisplayModeGetWidth(cRef) != w) { + int thisH = (int)CGDisplayModeGetHeight(cRef); + int thisW = (int)CGDisplayModeGetWidth(cRef); -+ if (thisBpp != bpp || thisH != h || thisW != w) { ++ if (thisBpp != bpp || thisH != h || thisW != w) { // One of the key parameters does not match continue; } so instead I did a clean backport and pushed that: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/8e8e54a1f0e3 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 verghese at amazon.com Mon Dec 16 19:15:41 2019 From: verghese at amazon.com (Verghese, Clive) Date: Mon, 16 Dec 2019 19:15:41 +0000 Subject: [8u] RFR backport of 8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails In-Reply-To: <8fe28751-daf5-4015-4ff3-431f2ddbcc75@redhat.com> References: <2991D191-9F80-48AB-B6D5-2643AB9A38D8@amazon.com> <8fe28751-daf5-4015-4ff3-431f2ddbcc75@redhat.com> Message-ID: <4AF807B8-3EE7-471F-A5CF-199C005BB5A8@amazon.com> Hi Andrew, Thank you. Regards, Clive Verghese ?On 12/16/19, 11:08 AM, "Andrew John Hughes" wrote: On 06/12/2019 23:03, Verghese, Clive wrote: > Hi, > > I would like to request backport of JDK-8213119 to 8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213119 > Original: https://hg.openjdk.java.net/jdk/jdk/rev/85d7af399ef5 > Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8213119/webrev.8u.00/ > > The patch is marked as 8u241but not yet in openjdk8u 242. > > Patch did not apply cleanly, minor modifications were required. Other than the mismatch in Copyrights, the following hunks did not apply cleanly. > > In file ?test/java/awt/GraphicsDevice/CheckDisplayModes.java?, hunk 2 did not apply cleanly. > In file ?macosx/native/sun/awt/CGraphicsDevice.m?, hunk 2 did not apply cleanly. > The test was not present in ProblemList.txt. > > Validated that the test is running successfully. > > Regards, > Clive Verghese > I see some odd whitespace differences between this patch and the 11u version: @@ -26,7 +25,7 @@ - if (thisBpp != bpp || (int)CGDisplayModeGetHeight(cRef) != h || (int)CGDisplayModeGetWidth(cRef) != w) { + int thisH = (int)CGDisplayModeGetHeight(cRef); + int thisW = (int)CGDisplayModeGetWidth(cRef); -+ if (thisBpp != bpp || thisH != h || thisW != w) { ++ if (thisBpp != bpp || thisH != h || thisW != w) { // One of the key parameters does not match continue; } so instead I did a clean backport and pushed that: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/8e8e54a1f0e3 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 alvdavi at amazon.com Mon Dec 16 21:08:58 2019 From: alvdavi at amazon.com (Alvarez, David) Date: Mon, 16 Dec 2019 21:08:58 +0000 Subject: [8u] RFR 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 In-Reply-To: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> References: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> Message-ID: I think you might have missed this one: jdk: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jdk/webrev.00/ On 16 Dec 2019, at 09:26, Zhengyu Gu wrote: ?Hi, Please review this 8u backport, as Oracle backported this patch in 8u221 Original bug: https://bugs.openjdk.java.net/browse/JDK-8210776 Original webrev: http://cr.openjdk.java.net/~prr/8210776/ Original review thread: https://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014607.html 8u webrev: main: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/webrev.00/ corba: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/corba/webrev.00/ hotspot: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/hotspot/webrev.00/ jaxp: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxp/webrev.00/ jaxws: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxws/webrev.00/ langtools: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/langtools/webrev.00/ nashorn: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/nashorn/webrev.00/ Thanks, -Zhengyu From zgu at redhat.com Mon Dec 16 22:04:19 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 16 Dec 2019 17:04:19 -0500 Subject: [8u] RFR 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 In-Reply-To: References: <86edff27-6416-0163-b0e6-83364977ecef@redhat.com> Message-ID: <868e5a71-a612-02ec-ddc2-1551c2b22e67@redhat.com> Yes, of course. Thanks, David. -Zhengyu On 12/16/19 4:08 PM, Alvarez, David wrote: > I think you might have missed this one: > jdk: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jdk/webrev.00/ > >> On 16 Dec 2019, at 09:26, Zhengyu Gu wrote: >> >> ?Hi, >> >> Please review this 8u backport, as Oracle backported this patch in 8u221 >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8210776 >> Original webrev: http://cr.openjdk.java.net/~prr/8210776/ >> Original review thread: >> https://mail.openjdk.java.net/pipermail/awt-dev/2018-November/014607.html >> >> >> 8u webrev: >> ?main: http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/webrev.00/ >> ?corba: >> http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/corba/webrev.00/ >> ?hotspot: >> http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/hotspot/webrev.00/ >> ?jaxp: >> http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxp/webrev.00/ >> ?jaxws: >> http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/jaxws/webrev.00/ >> ?langtools: >> http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/langtools/webrev.00/ >> ?nashorn: >> http://cr.openjdk.java.net/~zgu/JDK-8210776_8u/webrev.00/nashorn/webrev.00/ >> >> >> Thanks, >> >> -Zhengyu >> >> From neugens at redhat.com Mon Dec 16 22:20:03 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 16 Dec 2019 23:20:03 +0100 Subject: [JFR backport] RFC: CSR for JFR backport suggests not leaving out the package-info In-Reply-To: References: Message-ID: Hi Marcus, Can you please file another bug report? I?ll check the patch and commit in the morning. Cheers, Mario On Monday, December 16, 2019, Marcus Hirt wrote: > Hi Mario, > > There was another one. Also adding the internal one, to make it > similar to JDK 11. > http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.1/ > > Kind regards, > Marcus > > On Mon, Dec 16, 2019 at 4:52 PM Mario Torre wrote: > > > > Approved. > > > > Cheers, > > Mario > > > > On Mon, Dec 16, 2019 at 4:40 PM Mario Torre wrote: > > > > > > [I'm sending this on behalf of Marcus which is not on the list] > > > > > > Hi all, > > > > > > Here is the fix for the missing package info! > > > > > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236002 > > > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.0/ > > > > > > Kind regards, > > > Marcus > > > > > > -- > > > Mario Torre > > > Associate Manager, Software Engineering > > > Red Hat GmbH > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Tue Dec 17 03:54:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 03:54:16 +0000 Subject: [8u] RFR: 8221246: NullPointerException within Win32ShellFolder2 In-Reply-To: References: Message-ID: On 11/11/2019 13:46, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8221246 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8221246 > > Original review thread: > https://mail.openjdk.java.net/pipermail/awt-dev/2019-June/015273.html > > 11u changeset: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/2f95ca679634 > > 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8221246/webrev.00/ > > Patch does not apply cleanly because of the differences in import > section, all other code changes, besides imports, are left the same. > Looks good. Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Dec 17 05:04:29 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 05:04:29 +0000 Subject: [8u] RFR 8225141: Better handling of classes in error state by fast class initialization checks In-Reply-To: References: Message-ID: On 23/08/2019 21:32, Zhengyu Gu wrote: > I would like to backport this patch to 8u, as it is in Oracle's 8u. > > The patch does not apply cleanly, due to line shifts and different > implementation of set_initialization_state_and_notify() in 8u. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8225141 > Original webrev: http://cr.openjdk.java.net/~vlivanov/8225141/webrev.00/ > Original code review thread: > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034062.html > > > 8u Webrev: > http://cr.openjdk.java.net/~zgu/JDK-8225141-8u/webrev.00/index.html > > Thanks, > > -Zhengyu Looks good to me. Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Dec 17 05:27:27 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 05:27:27 +0000 Subject: [8u] RFR 8229420: [Redo] jstat reports incorrect values for OU for CMS GC In-Reply-To: <1a056d3e-dbd1-7a4a-e2b0-578788f586ce@redhat.com> References: <1a056d3e-dbd1-7a4a-e2b0-578788f586ce@redhat.com> Message-ID: <1a3962eb-bfd0-cc25-a347-cd24c615d90a@redhat.com> On 28/10/2019 18:47, Zhengyu Gu wrote: > Please review this 8u backport, as this CR is on Oracle's 8u backport. > > The original patch does not apply cleanly, because there are a few > general GC refactorings, as well as CMS refactorings. > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8229420 > Original code review thread: > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-August/028935.html > > > > 8u backport: http://cr.openjdk.java.net/~zgu/JDK-8229420_8u/webrev.00/ > > Test: > ?gc jtreg tests on Linux x86_64 > > > Thanks, > > -Zhengyu > Looks good. Pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Dec 17 06:09:46 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 06:09:46 +0000 Subject: [8u] RFR(xs): 8232984: Upgrading Joni License version to 2.1.16 In-Reply-To: <785fafa7ca16286bfbe8b57667a1dc4296ad60b1.camel@redhat.com> References: <785fafa7ca16286bfbe8b57667a1dc4296ad60b1.camel@redhat.com> Message-ID: <7ec11a80-8a0e-7b14-2f12-7137174fd0fd@redhat.com> On 29/11/2019 13:53, Severin Gehwolf wrote: > Hi, > > Please review this Oracle JDK feature parity patch for 8u242. Since > licenses are dealt with in 8u differently than in later releases the > JDK 11 patch didn't apply. I've manually ported it to > THIRD_PARTY_README. The intention is to push this to all 8 repositories > once reviewed. Webrev below is for top repo only. > > Pre-requisite of this patch going in is JDK-8204288[1] also getting > approved. Note: JDK-8204290 is already in jdk8u. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232984 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232984/01/webrev/ > > Thoughts? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8204288 > Looks good. Pushed to all repos. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Dec 17 06:32:47 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 06:32:47 +0000 Subject: 8u242 Rampdown: Bug Triage Message-ID: Hi all, We have reached the point of rampdown for 8u242 where work will now be deferred to 8u252, unless a critical request to include it in 8u242 is approved (see [0]). I've been going through the list of bugs which are marked as fixed in Oracle's proprietary 8u241/2 [1] to see what is still missing in OpenJDK 8u: 1. JDK-8041620: "Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend declarations within surrounding scope". No sign of a backport for 8u. 2. JDK-8056313: "TEST_BUG: java/util/Timer/NameConstructors.java fails intermittently" No sign of a backport to 8u. 3. JDK-8080462: "Update SunPKCS11 provider with PKCS11 v2.40 support" Still under review; postponed to 8u252. 4. JDK-8143925: "enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock()" No sign of a backport to 8u. 5. JDK-8146581: "Minor corrections to the patch submitted for earlier bug id - 8143925" No sign of a backport to 8u and depends on #5. 6. JDK-8148188: "Enhance the security libraries to record events of interest" Depends on JFR so one for that branch for now. 7. JDK-8171974: "Fix for R10 Register clobbering with usage of ExternalAddress" No sign of a backport to 8u. 8. JDK-8177334: "Update xmldsig implementation to Apache Santuario 2.1.1" Major backport already defered from 8u232. Postponed to 8u252. 9. JDK-8200400: "Allow Sasl mechanisms to be restricted" Waiting on CSR https://bugs.openjdk.java.net/browse/JDK-8230491 10. JDK-8201627: "Kerberos sequence number issues" Still under review; needs backports of JDK-8186884 & JDK-8154231. 11. JDK-8205507: "jdk/javax/xml/crypto/dsig/GenerationTests.java timed out" Depends on 8177334 (#9), so also deferred to 8u252. 12. JDK-8217581: "JDK 8 javadoc man page does not list correct values for -source" No sign of a backport to 8u. 13. JDK-8217878: "ENVELOPING XML signature no longer works" Depends on 8177334 (#9), so also deferred to 8u252. 14. JDK-8218605: "Startup Splash Screen of SwingSet2 flashes in smaller coordinates before appearing in the final size" No progress since 8u232. 15. JDK-8218629: "XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10" Depends on 8177334 (#8), so also deferred to 8u252. 16. JDK-8219013: "Update Apache Santuario (XML Signature) to version 2.1.3" Depends on 8177334 (#8), so also deferred to 8u252. 17. JDK-8225695: "32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)" Depends on 8080462 (#3), so also deferred to 8u252. 18. JDK-8228835: "Memory leak in PKCS11 provider when using AES GCM" Caused by 8080462 (#3), so also deferred to 8u252. 19. JDK-8229243: "SunPKCS11-Solaris provider tests failing on Solaris 11.4" Caused by 8080462 (#3), so also deferred to 8u252. 20. JDK-8229767: "Typo in java.security: Sasl.createClient and Sasl.createServer" Depends on 8200400 (#9), so deferred to 8u252. 21. JDK-8229868: "Update Apache Santuario TPRM version" Can be combined with 8219013 (#16), so deferred to 8u252. 22. JDK-8230303: "JDB hangs when running monitor command" No sign of a backport to 8u. 23. JDK-8230751: "The underline of the text doesn't display unless resizing the window with the option "-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". No patch, no sign of a fix for 8u. 24. JDK-8210776: "Upgrade X Window System 6.8.2 to the latest XWD 1.0.7" Patch not posted until 2019-12-16, deferred to 8u252. 25. JDK-8230782: "Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false" Depends on 8210776 (#24) 26. JDK-8231254: "(fs) Add test for macOS Catalina changes to protect system software" No sign of a backport to 8u. 27. JDK-8232019: "Add LuxTrust certificate updates to the existing root program" No sign of a backport to 8u. 28. JDK-8232178: "MacVolumesTest failed after upgrade to MacOS Catalina" No sign of a backport to 8u. 29. JDK-8233223: "Add Amazon Root CA certificates" No sign of a backport to 8u. Although this appears to be a long list, a number of them are related, particularly #8 and friends which have already been deferred from 8u232. Hopefully, there will be some progress on that for 8u252. The highest numbered bugs also seem to have been added to the list very late in the release cycle. Thanks to everyone who has submitted patches and/or reviews during the 8u242 development cycle. Onwards to 8u252! [0] https://wiki.openjdk.java.net/display/jdk8u/Main [1] https://bugs.openjdk.java.net/issues/?filter=37085 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Dec 17 06:42:52 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 06:42:52 +0000 Subject: 8u-dev OPEN for 8u252 commits Message-ID: All pending changes for 8u242-b05 have now been pushed. 8u-dev has been switched to openjdk8u252 and is now open for approved pushes with the jdk8u-fix-yes label. 8u is still closed for now. Once 8u242-b05 is tested, this will be open for pushes with the jdk8u-critical-yes label and b05 will be merged back into 8u-dev. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Tue Dec 17 08:03:14 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 17 Dec 2019 09:03:14 +0100 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: References: Message-ID: <6e20496025345007adc01ab5c7ae4da5b13ac384.camel@redhat.com> Hi Andrew, Thanks for the summary! Some comments below. On Tue, 2019-12-17 at 06:32 +0000, Andrew John Hughes wrote: > 23. JDK-8230751: "The underline of the text doesn't display unless > resizing the window with the option "-server -d64 -Xmixed > -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". > > No patch, no sign of a fix for 8u. Yes. I had a look at this one. Since we neither have a reproducer nor a patch (8-only bug), I've concluded to leave this one alone. If somebody has info about it, please do share! > 27. JDK-8232019: "Add LuxTrust certificate updates to the existing root > program" > > No sign of a backport to 8u. [...] > 29. JDK-8233223: "Add Amazon Root CA certificates" > > No sign of a backport to 8u. I'll prepare backports for these two. Thanks, Severin From yan at azul.com Tue Dec 17 10:32:39 2019 From: yan at azul.com (Yuri Nesterenko) Date: Tue, 17 Dec 2019 13:32:39 +0300 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: <6e20496025345007adc01ab5c7ae4da5b13ac384.camel@redhat.com> References: <6e20496025345007adc01ab5c7ae4da5b13ac384.camel@redhat.com> Message-ID: Hi colleagues, On 17.12.2019 11:03, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for the summary! Some comments below. > > On Tue, 2019-12-17 at 06:32 +0000, Andrew John Hughes wrote: >> 23. JDK-8230751: "The underline of the text doesn't display unless >> resizing the window with the option "-server -d64 -Xmixed >> -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". >> >> No patch, no sign of a fix for 8u. > Yes. I had a look at this one. Since we neither have a reproducer nor a > patch (8-only bug), I've concluded to leave this one alone. If somebody > has info about it, please do share! Trying to reproduce this one on jdk8u-dev, I started jfc/Stylepad demo on Linux and immediately run into JDK-8227662: freetype seeks to index at the end of the font data I guess it should be added here. It's all the same one-symbol fix everywhere, we already have the fix locally. For some reason I don't see a backport in the original bug but it should exist. Thanks, --yan > >> 27. JDK-8232019: "Add LuxTrust certificate updates to the existing root >> program" >> >> No sign of a backport to 8u. > [...] > >> 29. JDK-8233223: "Add Amazon Root CA certificates" >> >> No sign of a backport to 8u. > I'll prepare backports for these two. > > Thanks, > Severin From neugens at redhat.com Tue Dec 17 10:48:44 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 17 Dec 2019 11:48:44 +0100 Subject: [JFR backport] RFC: CSR for JFR backport suggests not leaving out the package-info In-Reply-To: References: Message-ID: Hi Marcus, The patch is ok, but of course the src/share/classes/jdk/jfr/package-info.java needs to be removed since we already pushed this as part of JDK-8236002. Can you please share an hg export so I'll apply and push for you? Cheers, Mario On Mon, Dec 16, 2019 at 11:20 PM Mario Torre wrote: > > Hi Marcus, > > Can you please file another bug report? > > I?ll check the patch and commit in the morning. > > Cheers, > Mario > > On Monday, December 16, 2019, Marcus Hirt wrote: >> >> Hi Mario, >> >> There was another one. Also adding the internal one, to make it >> similar to JDK 11. >> http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.1/ >> >> Kind regards, >> Marcus >> >> On Mon, Dec 16, 2019 at 4:52 PM Mario Torre wrote: >> > >> > Approved. >> > >> > Cheers, >> > Mario >> > >> > On Mon, Dec 16, 2019 at 4:40 PM Mario Torre wrote: >> > > >> > > [I'm sending this on behalf of Marcus which is not on the list] >> > > >> > > Hi all, >> > > >> > > Here is the fix for the missing package info! >> > > >> > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236002 >> > > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.0/ >> > > >> > > Kind regards, >> > > Marcus >> > > >> > > -- >> > > Mario Torre >> > > Associate Manager, Software Engineering >> > > Red Hat GmbH >> > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >> > >> > >> > >> > -- >> > Mario Torre >> > Associate Manager, Software Engineering >> > Red Hat GmbH >> > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 >> > >> > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From zgu at redhat.com Tue Dec 17 12:07:23 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 17 Dec 2019 07:07:23 -0500 Subject: [8u] RFR 8225141: Better handling of classes in error state by fast class initialization checks In-Reply-To: References: Message-ID: On 12/17/19 12:04 AM, Andrew John Hughes wrote: > > > On 23/08/2019 21:32, Zhengyu Gu wrote: >> I would like to backport this patch to 8u, as it is in Oracle's 8u. >> >> The patch does not apply cleanly, due to line shifts and different >> implementation of set_initialization_state_and_notify() in 8u. >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8225141 >> Original webrev: http://cr.openjdk.java.net/~vlivanov/8225141/webrev.00/ >> Original code review thread: >> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-May/034062.html >> >> >> 8u Webrev: >> http://cr.openjdk.java.net/~zgu/JDK-8225141-8u/webrev.00/index.html >> >> Thanks, >> >> -Zhengyu > > Looks good to me. Pushed. Thanks, Andrew -Zhengyu > > Thanks, > From neugens at redhat.com Tue Dec 17 12:32:19 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 17 Dec 2019 13:32:19 +0100 Subject: [JFR backport] RFC: CSR for JFR backport suggests not leaving out the package-info In-Reply-To: References: Message-ID: Hi Marcus, I applied your new webrev and tested and all seems to work as expected: http://cr.openjdk.java.net/~hirt/JDK-8236074/webrev.0 The patch is approved. Cheers, Mario On Tue, Dec 17, 2019 at 11:48 AM Mario Torre wrote: > > Hi Marcus, > > The patch is ok, but of course the > src/share/classes/jdk/jfr/package-info.java needs to be removed since > we already pushed this as part of JDK-8236002. Can you please share an > hg export so I'll apply and push for you? > > Cheers, > Mario > > On Mon, Dec 16, 2019 at 11:20 PM Mario Torre wrote: > > > > Hi Marcus, > > > > Can you please file another bug report? > > > > I?ll check the patch and commit in the morning. > > > > Cheers, > > Mario > > > > On Monday, December 16, 2019, Marcus Hirt wrote: > >> > >> Hi Mario, > >> > >> There was another one. Also adding the internal one, to make it > >> similar to JDK 11. > >> http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.1/ > >> > >> Kind regards, > >> Marcus > >> > >> On Mon, Dec 16, 2019 at 4:52 PM Mario Torre wrote: > >> > > >> > Approved. > >> > > >> > Cheers, > >> > Mario > >> > > >> > On Mon, Dec 16, 2019 at 4:40 PM Mario Torre wrote: > >> > > > >> > > [I'm sending this on behalf of Marcus which is not on the list] > >> > > > >> > > Hi all, > >> > > > >> > > Here is the fix for the missing package info! > >> > > > >> > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236002 > >> > > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.0/ > >> > > > >> > > Kind regards, > >> > > Marcus > >> > > > >> > > -- > >> > > Mario Torre > >> > > Associate Manager, Software Engineering > >> > > Red Hat GmbH > >> > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > >> > > >> > > >> > > >> > -- > >> > Mario Torre > >> > Associate Manager, Software Engineering > >> > Red Hat GmbH > >> > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > >> > > >> > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From akozlov at azul.com Tue Dec 17 13:56:26 2019 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 17 Dec 2019 16:56:26 +0300 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: References: Message-ID: Hi All On 17.12.2019 09:32, Andrew John Hughes wrote: > > 4. JDK-8143925: "enhancing CounterMode.crypt() for > AESCrypt.implEncryptBlock()" > > No sign of a backport to 8u. > > 5. JDK-8146581: "Minor corrections to the patch submitted for earlier > bug id - 8143925" > > No sign of a backport to 8u and depends on #5. I'm doing this, was blocked by JDK-8236067: java disables UseAES flag when using VIS=2 on sparc that was pushed recently. From epeterson at interactivebrokers.com Tue Dec 17 14:02:38 2019 From: epeterson at interactivebrokers.com (Eric Peterson) Date: Tue, 17 Dec 2019 14:02:38 +0000 Subject: [EXTERNAL] 8u242 Rampdown: Bug Triage In-Reply-To: References: Message-ID: <4D28F38F-52FA-4DCC-B1E6-A28F171A754B@interactivebrokers.com> Hi Andrew, Are any of the below open bugs for 8u242 considered to be critical security fixes? ?Eric > On Dec 17, 2019, at 1:32 AM, Andrew John Hughes wrote: > > Hi all, > > We have reached the point of rampdown for 8u242 where work will now be > deferred to 8u252, unless a critical request to include it in 8u242 is > approved (see [0]). > > I've been going through the list of bugs which are marked as fixed in > Oracle's proprietary 8u241/2 [1] to see what is still missing in OpenJDK 8u: > > 1. JDK-8041620: "Solaris Studio 12.4 C++ 5.13 change in behavior for > placing friend declarations within surrounding scope". > > No sign of a backport for 8u. > > 2. JDK-8056313: "TEST_BUG: java/util/Timer/NameConstructors.java fails > intermittently" > > No sign of a backport to 8u. > > 3. JDK-8080462: "Update SunPKCS11 provider with PKCS11 v2.40 support" > > Still under review; postponed to 8u252. > > 4. JDK-8143925: "enhancing CounterMode.crypt() for > AESCrypt.implEncryptBlock()" > > No sign of a backport to 8u. > > 5. JDK-8146581: "Minor corrections to the patch submitted for earlier > bug id - 8143925" > > No sign of a backport to 8u and depends on #5. > > 6. JDK-8148188: "Enhance the security libraries to record events of > interest" > > Depends on JFR so one for that branch for now. > > 7. JDK-8171974: "Fix for R10 Register clobbering with usage of > ExternalAddress" > > No sign of a backport to 8u. > > 8. JDK-8177334: "Update xmldsig implementation to Apache Santuario 2.1.1" > > Major backport already defered from 8u232. Postponed to 8u252. > > 9. JDK-8200400: "Allow Sasl mechanisms to be restricted" > > Waiting on CSR https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8230491&data=01%7C01%7Cepeterson%40interactivebrokers.com%7C5f57f874a0c1463fc4c008d782bb4704%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=o2wlMl0SwyzF5aurGvTLcIS%2FSq3fx8vZ2wd0640Hfu4%3D&reserved=0 > > 10. JDK-8201627: "Kerberos sequence number issues" > > Still under review; needs backports of JDK-8186884 & JDK-8154231. > > 11. JDK-8205507: "jdk/javax/xml/crypto/dsig/GenerationTests.java timed out" > > Depends on 8177334 (#9), so also deferred to 8u252. > > 12. JDK-8217581: "JDK 8 javadoc man page does not list correct values > for -source" > > No sign of a backport to 8u. > > 13. JDK-8217878: "ENVELOPING XML signature no longer works" > > Depends on 8177334 (#9), so also deferred to 8u252. > > 14. JDK-8218605: "Startup Splash Screen of SwingSet2 flashes in smaller > coordinates before appearing in the final size" > > No progress since 8u232. > > 15. JDK-8218629: "XML Digital Signature throws NAMESPACE_ERR exception > on OpenJDK 11, works 8/9/10" > > Depends on 8177334 (#8), so also deferred to 8u252. > > 16. JDK-8219013: "Update Apache Santuario (XML Signature) to version 2.1.3" > > Depends on 8177334 (#8), so also deferred to 8u252. > > 17. JDK-8225695: "32-bit build failures after JDK-8080462 (Update > SunPKCS11 provider with PKCS11 v2.40 support)" > > Depends on 8080462 (#3), so also deferred to 8u252. > > 18. JDK-8228835: "Memory leak in PKCS11 provider when using AES GCM" > > Caused by 8080462 (#3), so also deferred to 8u252. > > 19. JDK-8229243: "SunPKCS11-Solaris provider tests failing on Solaris 11.4" > > Caused by 8080462 (#3), so also deferred to 8u252. > > 20. JDK-8229767: "Typo in java.security: Sasl.createClient and > Sasl.createServer" > > Depends on 8200400 (#9), so deferred to 8u252. > > 21. JDK-8229868: "Update Apache Santuario TPRM version" > > Can be combined with 8219013 (#16), so deferred to 8u252. > > 22. JDK-8230303: "JDB hangs when running monitor command" > > No sign of a backport to 8u. > > 23. JDK-8230751: "The underline of the text doesn't display unless > resizing the window with the option "-server -d64 -Xmixed > -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". > > No patch, no sign of a fix for 8u. > > 24. JDK-8210776: "Upgrade X Window System 6.8.2 to the latest XWD 1.0.7" > > Patch not posted until 2019-12-16, deferred to 8u252. > > 25. JDK-8230782: "Robot.createScreenCapture() fails if ?awt.robot.gtk? > is set to false" > > Depends on 8210776 (#24) > > 26. JDK-8231254: "(fs) Add test for macOS Catalina changes to protect > system software" > > No sign of a backport to 8u. > > 27. JDK-8232019: "Add LuxTrust certificate updates to the existing root > program" > > No sign of a backport to 8u. > > 28. JDK-8232178: "MacVolumesTest failed after upgrade to MacOS Catalina" > > No sign of a backport to 8u. > > 29. JDK-8233223: "Add Amazon Root CA certificates" > > No sign of a backport to 8u. > > Although this appears to be a long list, a number of them are related, > particularly #8 and friends which have already been deferred from 8u232. > Hopefully, there will be some progress on that for 8u252. The highest > numbered bugs also seem to have been added to the list very late in the > release cycle. > > Thanks to everyone who has submitted patches and/or reviews during the > 8u242 development cycle. Onwards to 8u252! > > [0] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2Fjdk8u%2FMain&data=01%7C01%7Cepeterson%40interactivebrokers.com%7C5f57f874a0c1463fc4c008d782bb4704%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=osKG6gfWb5t0YnKRoEtvwZEPppzYKCpl%2B5AMP7mFLbA%3D&reserved=0 > [1] https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fissues%2F%3Ffilter%3D37085&data=01%7C01%7Cepeterson%40interactivebrokers.com%7C5f57f874a0c1463fc4c008d782bb4704%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=ZZKuTF9qzGCVrmcBZY4htpyv8e6cu3IBrhuuUQPqno8%3D&reserved=0 > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.redhat.com&data=01%7C01%7Cepeterson%40interactivebrokers.com%7C5f57f874a0c1463fc4c008d782bb4704%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=JubUHR91It8%2B2Y7ZPe6WzcdzLZuVSwqGBSHXDTO3fKw%3D&reserved=0) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fgnu_andrew&data=01%7C01%7Cepeterson%40interactivebrokers.com%7C5f57f874a0c1463fc4c008d782bb4704%7C7abd04ef837d48e69ba869d84f65a110%7C0&sdata=sdVkUAvinBa%2Byra8BZS9n6btCVcFg8mH%2FDSJqXGDf24%3D&reserved=0 > From sgehwolf at redhat.com Tue Dec 17 14:42:18 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 17 Dec 2019 15:42:18 +0100 Subject: [8u] RFR: [TESTBUG] Some ssl jtreg tests fail due to usage of a secp256k1 ECDSA certificate In-Reply-To: References: Message-ID: <31bdfe6e413e37404db17c568be9e94164ba54a1.camel@redhat.com> Hi David, On Fri, 2019-11-08 at 13:24 -0800, David Alvarez wrote: > Hi, > > Requesting review for: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8233864 > Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8233864/webrev.8u.00/ > > After 8u232, certain Tier2 jtreg ssl tests started to fail as they were > relying on a certificate based on curve secp256k1. That curve is no > longer enabled for ssl (disabled by JDK-8228825 [1]). > > The specific certificate is located in: > test/sun/security/ssl/etc/keystore > and > test/sun/security/ssl/etc/truststore > > This patch fixes those tests by recreating the certificate stores with > new certificates. The generated ECDSA certificate uses secp256r1. These > certificates are v3 instead of v1 as the originals, but we have seen no > failures caused by this. > > This change includes binary changes. A patch file with binary changes is > located here: > http://cr.openjdk.java.net/~alvdavi/patches/8233864.8u.00.patch Why is this a problem specific to 8u? I see the same cert in 11u's keystore, Serial number: 57399c1d, alias dummyecdsa. For the time being I'll remove the jdk8u-fix-request label until it's clear this is actually an 8u only problem. Thanks, Severin > Thanks, > -- > David Alvarez > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5456f24496f4#l1.18 > From sgehwolf at redhat.com Tue Dec 17 15:16:57 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 17 Dec 2019 16:16:57 +0100 Subject: [8u] RFR: fix inconsistency of backport of 8219677: "-XX:OnOutOfMemoryError" uses fork instead of vfork In-Reply-To: <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com> References: <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com> <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com> Message-ID: On Fri, 2019-11-15 at 20:08 +0000, Hohensee, Paul wrote: > Webrev: http://cr.openjdk.java.net/~phh/8234264/webrev.8u.00/ src/share/vm/utilities/vmError.cpp 1063 if (os::fork_and_exec(cmd) < 0) { 1064 out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno); 1065 } This --^ establishes pre JDK-8219677 8u backport code. In JDK 9+ line 1063 changed with JDK-6985422 which is not in JDK 8u. Looks good. Thanks, Severin From jacob.kroon at gmail.com Tue Dec 17 15:43:34 2019 From: jacob.kroon at gmail.com (Jacob Kroon) Date: Tue, 17 Dec 2019 16:43:34 +0100 Subject: Fwd: [meta-java] openjre-8: java from master/master-next crashes on startup In-Reply-To: <04a167ee-e63d-c4a3-7808-26ef5e9ed884@gmail.com> References: <04a167ee-e63d-c4a3-7808-26ef5e9ed884@gmail.com> Message-ID: Hi, I'm having a runtime error when running java built with the Yocto tools, using the meta-java layer. I get the backtrace listed below. Since I'm not that familiar with the openjdk codebase, I thought I'd check here if anyone can easily spot which fix, if any, from upstream I need to backport ? Previous versions of Yocto can build and run openjdk fine, but I suspect either gcc 9 or newer glibc exposes the problem. Apologies in advance if this is not the correct forum to ask this question. Cheers, Jacob ---------- Forwarded message --------- From: Jacob Kroon Date: Sun, Oct 13, 2019 at 11:33 AM Subject: [meta-java] openjre-8: java from master/master-next crashes on startup To: Hi, For me, this has been the status for quite a while now. First of all, openjre-8 from master/master-next doesn't build on my Fedora 30 box, I've been using the patch attached to this mail to get it to build. Secondly, java always crashes on startup here: > #0 Node::Node (this=0x805fa88, req=3) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/node.cpp:327 > #1 0xb7499b63 in RegionNode::RegionNode (required=3, this=0x805fa88) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/cfgnode.hpp:73 > #2 LoopNode::LoopNode (backedge=0x0, entry=0x0, this=0x805fa88) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/loopnode.hpp:88 > #3 RootNode::RootNode (this=0x805fa88) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/rootnode.hpp:37 > #4 Compile::Init (this=0x977feaf8, aliaslevel=0) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/compile.cpp:1079 > #5 0xb74a02c5 in Compile::Compile (this=0x977feaf8, ci_env=0x977ff188, > generator=0xb7895270 , > stub_function=0xb7897070 "U\211\345WVS\350\245+\237\377\201\303\205\217\062", > stub_name=0xb7a0a62f "_new_instance_Java", is_fancy_jump=0, pass_tls=true, > save_arg_registers=false, return_pc=false) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/compile.cpp:1012 > #6 0xb789587b in OptoRuntime::generate_stub (env=0x977ff188, > gen=0xb7895270 , > C_function=0xb7897070 "U\211\345WVS\350\245+\237\377\201\303\205\217\062", name=0xb7a0a62f "_new_instance_Java", > is_fancy_jump=0, pass_tls=true, save_argument_registers=false, return_pc=false) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/runtime.cpp:181 > #7 0xb7895a5f in OptoRuntime::generate (env=0x977ff188) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/runtime.cpp:147 > #8 0xb7417de9 in C2Compiler::init_c2_runtime () > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/runtime/thread.hpp:1854 > #9 0xb7417e35 in C2Compiler::initialize (this=0xb706b180) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/opto/c2compiler.cpp:102 > #10 0xb74a508c in CompileBroker::init_compiler_runtime () > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/compiler/compileBroker.cpp:1674 > #11 0xb74ab6ed in CompileBroker::compiler_thread_loop () > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/compiler/compileBroker.cpp:1772 > #12 0xb79238d5 in compiler_thread_entry (thread=0xb7079400, __the_thread__=0xb7079400) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/runtime/thread.cpp:3230 > #13 0xb792d782 in JavaThread::thread_main_inner (this=0xb7079400) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/share/vm/runtime/thread.hpp:1035 > #14 0xb7820ce4 in java_start (thread=0xb7079400) > at /usr/src/debug/openjre-8/172b11-r0/jdk8u-33d274a7dda0/hotspot/src/os/linux/vm/os_linux.cpp:790 > #15 0x4121244c in start_thread (arg=) at pthread_create.c:479 > #16 0x4113bd56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108 The Node::Node() constructor uses an IDX_INIT() macro: > #define IDX_INIT(req) this->Init((req), (Compile*) this->_out) and Node::Init() does: > 297 inline int Node::Init(int req, Compile* C) { > 298 assert(Compile::current() == C, "must use operator new(Compile*)"); > 299 int idx = C->next_unique(); and here, this->_out = C = null, which I think leads to a segfault on line 299. I've tried looking at upstream jdk8u but can't find anything. Does anyone have an idea of whats going on here, or if I should raise the issue to openjdk ml ? Cheers, Jacob From gnu.andrew at redhat.com Tue Dec 17 17:00:16 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 17 Dec 2019 17:00:16 +0000 Subject: [EXTERNAL] 8u242 Rampdown: Bug Triage In-Reply-To: <4D28F38F-52FA-4DCC-B1E6-A28F171A754B@interactivebrokers.com> References: <4D28F38F-52FA-4DCC-B1E6-A28F171A754B@interactivebrokers.com> Message-ID: On 17/12/2019 14:02, Eric Peterson wrote: > Hi Andrew, > > Are any of the below open bugs for 8u242 considered to be critical security fixes? > > ?Eric > > Security fixes are private until the embargo is lifted on 2020-01-14. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Tue Dec 17 19:30:04 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 17 Dec 2019 20:30:04 +0100 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program Message-ID: Hi, Could I please get a review of this OpenJDK 8u backport of 8232019. The JDK 11 patch did not apply cleanly for a couple of reasons: 1. 8u still has the binary blob for cacerts (JDK-8193255 not backported, yet). Instead, I've updated to the revision in jdk11u, performed a build and copied the cacerts binary to 8u. 2. JDK-8225392 not present in 8u, which added the checksum to VerifyCACerts.java. Thus, the 8u backport does not include this hunk. @bug annotation modified manually for the same reason. Everything else is the same. Bug: https://bugs.openjdk.java.net/browse/JDK-8232019 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/ Testing: sun/security/lib/cacerts/VerifyCACerts.java and security/infra/java/security/cert/CertPathValidator/certification Pass, except for ActalisCA.java which is problem-listed and still broken in HEAD (JDK-8224768) Thoughts? If reviewed, I'll try to get this in 8u242 via the critical fix request label workflow. Thanks, Severin From sgehwolf at redhat.com Tue Dec 17 19:38:52 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 17 Dec 2019 20:38:52 +0100 Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates Message-ID: Hi, Could I please get a review of this OpenJDK 8u backport of 8233223 which depends on 8u backport of 8232019[1]. The JDK 11u patch did not apply cleanly for a couple of reasons: 1. 8u still has the binary blob for cacerts (JDK-8193255 not?backported, yet). Instead, I've updated to the revision in jdk11u, performed a build and copied the cacerts binary to 8u. 2. JDK-8225392 not present in 8u, which added the checksum to VerifyCACerts.java. Thus, the 8u backport does not include this?hunk. 3. JDK-8234245 not present in 8u. 4. Due to 2) and 3) above @bug annotation modified manually for these reasons. Everything else is the same. Bug: https://bugs.openjdk.java.net/browse/JDK-8233223 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/ Testing: sun/security/lib/cacerts/VerifyCACerts.java and security/infra/java/security/cert/CertPathValidator/certification Pass, except for ActalisCA.java which is problem-listed and still broken in HEAD (JDK-8224768) Thoughts? Once reviewed, I'll try to get this into 8u242 via the critical fix request label workflow. Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html From hohensee at amazon.com Tue Dec 17 20:27:52 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 17 Dec 2019 20:27:52 +0000 Subject: [8u] RFR: fix inconsistency of backport of 8219677: "-XX:OnOutOfMemoryError" uses fork instead of vfork In-Reply-To: References: <60ECAA2C-35B4-4A2A-BAAA-A5F277B77BA2@amazon.com> <7FB7EB92-81E7-4806-8958-A624876542B8@amazon.com> Message-ID: <7CF12A58-851E-4AA4-96D7-A2F7667C784D@amazon.com> Thanks for your review and approval, Severin. Pushed. ?On 12/17/19, 7:17 AM, "Severin Gehwolf" wrote: On Fri, 2019-11-15 at 20:08 +0000, Hohensee, Paul wrote: > Webrev: http://cr.openjdk.java.net/~phh/8234264/webrev.8u.00/ src/share/vm/utilities/vmError.cpp 1063 if (os::fork_and_exec(cmd) < 0) { 1064 out.print_cr("os::fork_and_exec failed: %s (%d)", strerror(errno), errno); 1065 } This --^ establishes pre JDK-8219677 8u backport code. In JDK 9+ line 1063 changed with JDK-6985422 which is not in JDK 8u. Looks good. Thanks, Severin From akozlov at azul.com Tue Dec 17 20:48:12 2019 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 17 Dec 2019 23:48:12 +0300 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: References: Message-ID: Hi Andrew, On 17.12.2019 16:56, Anton Kozlov wrote: >> 4. JDK-8143925: "enhancing CounterMode.crypt() for >> AESCrypt.implEncryptBlock()" >> 5. JDK-8146581: "Minor corrections to the patch submitted for earlier >> bug id - 8143925" > > I'm doing this, was blocked by > > JDK-8236067: java disables UseAES flag when using VIS=2 on sparc > > that was pushed recently. > Sorry, I missed some details. 8236067 was pushed to jdk8u directly [1], bypassing jdk8-dev. By [2] I should not propose RFRs for 8143925 and 8146581 that depends on 8236067, unless labeling "critical-request" later. But these issues are intrinsic so it's unlikely they need a "critical". It looks like I need to wait until release of 8u242, jdk8u merge into jdk8u-dev, and only then send out patches. Right? Thanks, Anton 1: https://bugs.openjdk.java.net/browse/JDK-8236067 2: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010752.html From alvdavi at amazon.com Tue Dec 17 21:51:55 2019 From: alvdavi at amazon.com (David Alvarez) Date: Tue, 17 Dec 2019 13:51:55 -0800 Subject: [8u] RFR: [TESTBUG] Some ssl jtreg tests fail due to usage of a secp256k1 ECDSA certificate In-Reply-To: <31bdfe6e413e37404db17c568be9e94164ba54a1.camel@redhat.com> References: <31bdfe6e413e37404db17c568be9e94164ba54a1.camel@redhat.com> Message-ID: <71d86080-af7c-885d-8d84-25ca34c548d2@amazon.com> Hi Severin, You're right the same cert is in 11u, but I don't think it is being used anymore. The same certificate store contains another certificate with alias ecdsasecp256r1 serial number 46646443, and that one is being used for the two jtreg tests I mentioned in the bug that fail. As the alias indicates, the certificate is based on curve secp256r1, that was not disabled. That certificate was added by 8196584: TLS 1.3 Implementation [1]. David -- [1] https://bugs.openjdk.java.net/browse/JDK-8196584 On 2019-12-17 06:42, Severin Gehwolf wrote: > Hi David, > > On Fri, 2019-11-08 at 13:24 -0800, David Alvarez wrote: >> Hi, >> >> Requesting review for: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8233864 >> Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8233864/webrev.8u.00/ >> >> After 8u232, certain Tier2 jtreg ssl tests started to fail as they were >> relying on a certificate based on curve secp256k1. That curve is no >> longer enabled for ssl (disabled by JDK-8228825 [1]). >> >> The specific certificate is located in: >> test/sun/security/ssl/etc/keystore >> and >> test/sun/security/ssl/etc/truststore >> >> This patch fixes those tests by recreating the certificate stores with >> new certificates. The generated ECDSA certificate uses secp256r1. These >> certificates are v3 instead of v1 as the originals, but we have seen no >> failures caused by this. >> >> This change includes binary changes. A patch file with binary changes is >> located here: >> http://cr.openjdk.java.net/~alvdavi/patches/8233864.8u.00.patch > > Why is this a problem specific to 8u? I see the same cert in 11u's > keystore, Serial number: 57399c1d, alias dummyecdsa. > > For the time being I'll remove the jdk8u-fix-request label until it's > clear this is actually an 8u only problem. > > Thanks, > Severin > >> Thanks, >> -- >> David Alvarez >> >> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5456f24496f4#l1.18 >> > From hohensee at amazon.com Wed Dec 18 00:38:32 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 18 Dec 2019 00:38:32 +0000 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: References: Message-ID: <42702E67-9C28-493E-8BB8-DB41BD3B7DD9@amazon.com> Comments on four of these: 1. JDK-8041620: "Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend declarations within surrounding scope". Just deletes an unused C++ class. Can be deferred to 8u252. 2. JDK-8056313: "TEST_BUG: java/util/Timer/NameConstructors.java fails intermittently" Test fix. Can be deferred to 8u252. 4. JDK-8143925: "enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock()" This is a performance enhancement, but the patch strictly speaking depends on previous patches such as the one for 8140779. The latter, however, is not tagged as backported by Oracle, so the Oracle 8143925 backport has been customized to avoid it. Imo too risky for 8u242. 7. JDK-8171974: "Fix for R10 Register clobbering with usage of ExternalAddress" Appears to be a fix for 8150767, which is another performance enhancement that's not tagged as backported to 8u. 8150767 depends on 8143925 (#4 above). Paul ?On 12/16/19, 10:35 PM, "jdk8u-dev on behalf of Andrew John Hughes" wrote: Hi all, We have reached the point of rampdown for 8u242 where work will now be deferred to 8u252, unless a critical request to include it in 8u242 is approved (see [0]). I've been going through the list of bugs which are marked as fixed in Oracle's proprietary 8u241/2 [1] to see what is still missing in OpenJDK 8u: 1. JDK-8041620: "Solaris Studio 12.4 C++ 5.13 change in behavior for placing friend declarations within surrounding scope". No sign of a backport for 8u. 2. JDK-8056313: "TEST_BUG: java/util/Timer/NameConstructors.java fails intermittently" No sign of a backport to 8u. 3. JDK-8080462: "Update SunPKCS11 provider with PKCS11 v2.40 support" Still under review; postponed to 8u252. 4. JDK-8143925: "enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock()" No sign of a backport to 8u. 5. JDK-8146581: "Minor corrections to the patch submitted for earlier bug id - 8143925" No sign of a backport to 8u and depends on #5. 6. JDK-8148188: "Enhance the security libraries to record events of interest" Depends on JFR so one for that branch for now. 7. JDK-8171974: "Fix for R10 Register clobbering with usage of ExternalAddress" No sign of a backport to 8u. 8. JDK-8177334: "Update xmldsig implementation to Apache Santuario 2.1.1" Major backport already defered from 8u232. Postponed to 8u252. 9. JDK-8200400: "Allow Sasl mechanisms to be restricted" Waiting on CSR https://bugs.openjdk.java.net/browse/JDK-8230491 10. JDK-8201627: "Kerberos sequence number issues" Still under review; needs backports of JDK-8186884 & JDK-8154231. 11. JDK-8205507: "jdk/javax/xml/crypto/dsig/GenerationTests.java timed out" Depends on 8177334 (#9), so also deferred to 8u252. 12. JDK-8217581: "JDK 8 javadoc man page does not list correct values for -source" No sign of a backport to 8u. 13. JDK-8217878: "ENVELOPING XML signature no longer works" Depends on 8177334 (#9), so also deferred to 8u252. 14. JDK-8218605: "Startup Splash Screen of SwingSet2 flashes in smaller coordinates before appearing in the final size" No progress since 8u232. 15. JDK-8218629: "XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10" Depends on 8177334 (#8), so also deferred to 8u252. 16. JDK-8219013: "Update Apache Santuario (XML Signature) to version 2.1.3" Depends on 8177334 (#8), so also deferred to 8u252. 17. JDK-8225695: "32-bit build failures after JDK-8080462 (Update SunPKCS11 provider with PKCS11 v2.40 support)" Depends on 8080462 (#3), so also deferred to 8u252. 18. JDK-8228835: "Memory leak in PKCS11 provider when using AES GCM" Caused by 8080462 (#3), so also deferred to 8u252. 19. JDK-8229243: "SunPKCS11-Solaris provider tests failing on Solaris 11.4" Caused by 8080462 (#3), so also deferred to 8u252. 20. JDK-8229767: "Typo in java.security: Sasl.createClient and Sasl.createServer" Depends on 8200400 (#9), so deferred to 8u252. 21. JDK-8229868: "Update Apache Santuario TPRM version" Can be combined with 8219013 (#16), so deferred to 8u252. 22. JDK-8230303: "JDB hangs when running monitor command" No sign of a backport to 8u. 23. JDK-8230751: "The underline of the text doesn't display unless resizing the window with the option "-server -d64 -Xmixed -Dswing.defaultlaf=com.sun.java.swing.plaf.gtk.GTKLookAndFeel". No patch, no sign of a fix for 8u. 24. JDK-8210776: "Upgrade X Window System 6.8.2 to the latest XWD 1.0.7" Patch not posted until 2019-12-16, deferred to 8u252. 25. JDK-8230782: "Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false" Depends on 8210776 (#24) 26. JDK-8231254: "(fs) Add test for macOS Catalina changes to protect system software" No sign of a backport to 8u. 27. JDK-8232019: "Add LuxTrust certificate updates to the existing root program" No sign of a backport to 8u. 28. JDK-8232178: "MacVolumesTest failed after upgrade to MacOS Catalina" No sign of a backport to 8u. 29. JDK-8233223: "Add Amazon Root CA certificates" No sign of a backport to 8u. Although this appears to be a long list, a number of them are related, particularly #8 and friends which have already been deferred from 8u232. Hopefully, there will be some progress on that for 8u252. The highest numbered bugs also seem to have been added to the list very late in the release cycle. Thanks to everyone who has submitted patches and/or reviews during the 8u242 development cycle. Onwards to 8u252! [0] https://wiki.openjdk.java.net/display/jdk8u/Main [1] https://bugs.openjdk.java.net/issues/?filter=37085 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 denghui.ddh at alibaba-inc.com Wed Dec 18 06:37:40 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 18 Dec 2019 14:37:40 +0800 Subject: =?UTF-8?B?Wzh1XSBbSkZSXSBSRlI6IDgyMzYxNjA6IE1pc3NpbmcgVGhyZWFkQ3Jhc2hQcm90ZWN0aW9u?= =?UTF-8?B?IGZvciBKRlIgaW4gc2lnbmFsIGhhbmRsZXI=?= Message-ID: Hi all, Please help review the following changeset: Jira: https://bugs.openjdk.java.net/browse/JDK-8236160 Webrev: http://cr.openjdk.java.net/~ddong/8236160/webrev.00/hotspot.changeset Summary: JFR thread sampler uses ThreadCrashProtection to protect thread crash, so it's necessary to call ThreadCrashProtection::check_crash_protection in signal handler. And a more elegant way is to merge ThreadCrashProtection and WatcherThreadCrashProtection, but this changeset didn't do that. Thanks, Denghui Dong From gnu.andrew at redhat.com Wed Dec 18 14:19:21 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 18 Dec 2019 14:19:21 +0000 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: References: Message-ID: <94c88c0e-2bac-6de9-cb2e-b805eeb04147@redhat.com> On 17/12/2019 20:48, Anton Kozlov wrote: > Hi Andrew, > > On 17.12.2019 16:56, Anton Kozlov wrote: >>> 4. JDK-8143925: "enhancing CounterMode.crypt() for >>> AESCrypt.implEncryptBlock()" >>> 5. JDK-8146581: "Minor corrections to the patch submitted for earlier >>> bug id - 8143925" >> >> I'm doing this, was blocked by >> >> JDK-8236067: java disables UseAES flag when using VIS=2 on sparc >> >> that was pushed recently. >> > > Sorry, I missed some details. 8236067 was pushed to jdk8u directly [1], bypassing jdk8-dev. By [2] I should not propose RFRs for 8143925 and 8146581 that depends on 8236067, unless labeling "critical-request" later. But these issues are intrinsic so it's unlikely they need a "critical". > > It looks like I need to wait until release of 8u242, jdk8u merge into jdk8u-dev, and only then send out patches. Right? > > Thanks, > Anton > > 1: https://bugs.openjdk.java.net/browse/JDK-8236067 > 2: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010752.html > No, you don't need to wait as long as that. Changes for jdk8u will be merged back to 8u-dev once b05 is tested and tagged (I'm working on that now, so hopefully later today or tomorrow). See https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010801.html I pushed them straight to 8u because otherwise they'd have been resolved as 8u252 in the bug database :/ Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Dec 18 14:51:02 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 18 Dec 2019 14:51:02 +0000 Subject: 8u242 Rampdown: Bug Triage In-Reply-To: <42702E67-9C28-493E-8BB8-DB41BD3B7DD9@amazon.com> References: <42702E67-9C28-493E-8BB8-DB41BD3B7DD9@amazon.com> Message-ID: <2bb9b5ec-29bc-5416-c7dd-a00c3e7aba12@redhat.com> On 18/12/2019 00:38, Hohensee, Paul wrote: > Comments on four of these: > > 1. JDK-8041620: "Solaris Studio 12.4 C++ 5.13 change in behavior for > placing friend declarations within surrounding scope". > > Just deletes an unused C++ class. Can be deferred to 8u252. > > 2. JDK-8056313: "TEST_BUG: java/util/Timer/NameConstructors.java fails > intermittently" > > Test fix. Can be deferred to 8u252. > > 4. JDK-8143925: "enhancing CounterMode.crypt() for > AESCrypt.implEncryptBlock()" > > This is a performance enhancement, but the patch strictly speaking depends on previous patches such as the one for 8140779. The latter, however, is not tagged as backported by Oracle, so the Oracle 8143925 backport has been customized to avoid it. Imo too risky for 8u242. > > 7. JDK-8171974: "Fix for R10 Register clobbering with usage of > ExternalAddress" > > Appears to be a fix for 8150767, which is another performance enhancement that's not tagged as backported to 8u. 8150767 depends on 8143925 (#4 above). > > Paul > Sorry, I should have been more explicit in my summary. Everything is now deferred to 8u252, unless an 8u-critical-request is made. I mentioned that explicitly for those Oracle-u241/2 bugs that actually had posted patches, but it should also be assumed for other patches still pending & anything in Oracle-u241/2 that hasn't even made an appearance on the lists, as they're at an even earlier stage in the process. 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 snazarkin at azul.com Wed Dec 18 14:54:18 2019 From: snazarkin at azul.com (Sergey Nazarkin) Date: Wed, 18 Dec 2019 14:54:18 +0000 Subject: [8u] 8236178: Debug build failed after 8236058 Message-ID: Hi! I?ve created critical bug [1] since debug build is broken after one of latest changeset [2]. Please consider to include it into u242 diff -r 9ef81b9152f1 src/share/vm/oops/instanceKlass.cpp --- a/src/share/vm/oops/instanceKlass.cpp Fri Nov 13 18:14:41 2015 +0300 +++ b/src/share/vm/oops/instanceKlass.cpp Wed Dec 18 14:25:28 2019 +0300 @@ -3605,7 +3605,7 @@ bool good_state = is_shared() ? (_init_state <= state) : (_init_state < state); assert(good_state || state == allocated, "illegal state transition"); - set_initialization_state_and_notify_implassert(_init_thread == NULL, "should be cleared before state change"); + assert(_init_thread == NULL, "should be cleared before state change"); _init_state = (u1)state; } #endif Sergey Nazarkin [1] https://bugs.openjdk.java.net/browse/JDK-8236178 [2] https://bugs.openjdk.java.net/browse/JDK-8236058 From marcus.hirt at datadoghq.com Mon Dec 16 20:37:39 2019 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 16 Dec 2019 21:37:39 +0100 Subject: [JFR backport] RFC: CSR for JFR backport suggests not leaving out the package-info In-Reply-To: References: Message-ID: Hi Mario, There was another one. Also adding the internal one, to make it similar to JDK 11. http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.1/ Kind regards, Marcus On Mon, Dec 16, 2019 at 4:52 PM Mario Torre wrote: > > Approved. > > Cheers, > Mario > > On Mon, Dec 16, 2019 at 4:40 PM Mario Torre wrote: > > > > [I'm sending this on behalf of Marcus which is not on the list] > > > > Hi all, > > > > Here is the fix for the missing package info! > > > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236002 > > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236002/webrev.0/ > > > > Kind regards, > > Marcus > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > From neugens at redhat.com Wed Dec 18 16:02:17 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 18 Dec 2019 17:02:17 +0100 Subject: [RFC] 8236174: Update javadoc since tags in the jfr backport Message-ID: <4faecebe5e5718c4b0d2f774451201a5c8c7d751.camel@redhat.com> Again from Marcus: Jira: https://bugs.openjdk.java.net/browse/JDK-8236174 Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236174/webrev.0/ I tested the patch and is approved. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Wed Dec 18 16:29:40 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 18 Dec 2019 16:29:40 +0000 Subject: [RFC] 8236174: Update javadoc since tags in the jfr backport In-Reply-To: <4faecebe5e5718c4b0d2f774451201a5c8c7d751.camel@redhat.com> References: <4faecebe5e5718c4b0d2f774451201a5c8c7d751.camel@redhat.com> Message-ID: On 18/12/2019 16:02, Mario Torre wrote: > Again from Marcus: > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236174 > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236174/webrev.0/ > > I tested the patch and is approved. > > Cheers, > Mario > Are these classes documented publicly? If not, I suggest not backporting this, otherwise it'll just create backport headaches. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From neugens at redhat.com Wed Dec 18 16:33:40 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 18 Dec 2019 17:33:40 +0100 Subject: [RFC] 8236174: Update javadoc since tags in the jfr backport In-Reply-To: References: <4faecebe5e5718c4b0d2f774451201a5c8c7d751.camel@redhat.com> Message-ID: Hi Andrew, Yes, those are the JFR classes, they are public. The CSR mentioned that: "The backport of the API looks appropriate for the goals of the project". On the other hand, you have a point that there is not some discrepancy between 8 and later version whose javadocs says those classes were introduced in 9. Perhaps we should not have the since updated... Any ideas? I already pushed but we can rollback the patch if necessary. Cheers, Mario On Wed, Dec 18, 2019 at 5:29 PM Andrew John Hughes wrote: > > > > On 18/12/2019 16:02, Mario Torre wrote: > > Again from Marcus: > > > > Jira: https://bugs.openjdk.java.net/browse/JDK-8236174 > > Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236174/webrev.0/ > > > > I tested the patch and is approved. > > > > Cheers, > > Mario > > > > Are these classes documented publicly? > > If not, I suggest not backporting this, otherwise it'll just create > backport headaches. > -- > 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 > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Wed Dec 18 16:37:25 2019 From: neugens at redhat.com (Mario Torre) Date: Wed, 18 Dec 2019 17:37:25 +0100 Subject: [RFC] 8236174: Update javadoc since tags in the jfr backport In-Reply-To: References: <4faecebe5e5718c4b0d2f774451201a5c8c7d751.camel@redhat.com> Message-ID: On Wed, Dec 18, 2019 at 5:33 PM Mario Torre wrote: > > Hi Andrew, > > Yes, those are the JFR classes, they are public. > > The CSR mentioned that: "The backport of the API looks appropriate for > the goals of the project". > > On the other hand, you have a point that there is not some discrepancy "There is *now* some discrepancy"... Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From adinn at redhat.com Wed Dec 18 17:16:52 2019 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 18 Dec 2019 17:16:52 +0000 Subject: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler In-Reply-To: References: Message-ID: Hi Denghui, On 18/12/2019 06:37, Denghui Dong wrote: > Hi all, > Please help review the following changeset: > Jira: https://bugs.openjdk.java.net/browse/JDK-8236160 > Webrev: http://cr.openjdk.java.net/~ddong/8236160/webrev.00/hotspot.changeset > Summary: > JFR thread sampler uses ThreadCrashProtection to protect thread crash, so it's necessary to call > ThreadCrashProtection::check_crash_protection in signal handler. > And a more elegant way is to merge ThreadCrashProtection and WatcherThreadCrashProtection, but this changeset didn't do that. I'm not clear why you are calling both os::WatcherThreadCrashProtection::check_crash_protection(sig, t); and os::ThreadCrashProtection::check_crash_protection(sig, t); Is it not possible simply to rely on os::ThreadCrashProtection alone as happens updtream? I am assuming that you have already back-ported class os::ThreadCrashProtection to the JFR incubator repo? Did you need to change it's behaviour in any way in order to do that? Does that have anything to do with why your are calling both routines? Also, how have you tested this patch? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Wed Dec 18 18:49:39 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 18 Dec 2019 19:49:39 +0100 Subject: [8u] 8236178: Debug build failed after 8236058 In-Reply-To: References: Message-ID: <251840ea0a6d356136d5c2cac71a86ae842d691a.camel@redhat.com> Hi, On Wed, 2019-12-18 at 14:54 +0000, Sergey Nazarkin wrote: > Hi! > > I?ve created critical bug [1] since debug build is broken after one of latest changeset [2]. Please consider to include it into u242 > > diff -r 9ef81b9152f1 src/share/vm/oops/instanceKlass.cpp > --- a/src/share/vm/oops/instanceKlass.cpp Fri Nov 13 18:14:41 2015 +0300 > +++ b/src/share/vm/oops/instanceKlass.cpp Wed Dec 18 14:25:28 2019 +0300 > @@ -3605,7 +3605,7 @@ > bool good_state = is_shared() ? (_init_state <= state) > : (_init_state < state); > assert(good_state || state == allocated, "illegal state transition"); > - set_initialization_state_and_notify_implassert(_init_thread == NULL, "should be cleared before state change"); > + assert(_init_thread == NULL, "should be cleared before state change"); > _init_state = (u1)state; > } > #endif This looks good to me. It's what the JDK 11u code[i] has as well. Not sure why the backport for 8u was different. Thanks, Severin [i] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/ae96767b40ff/src/hotspot/share/oops/instanceKlass.cpp#l3684 > > Sergey Nazarkin > > [1] https://bugs.openjdk.java.net/browse/JDK-8236178 > [2] https://bugs.openjdk.java.net/browse/JDK-8236058 > From volker.simonis at gmail.com Wed Dec 18 21:27:20 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Dec 2019 22:27:20 +0100 Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates In-Reply-To: References: Message-ID: Hi Severin, not strictly a 8u "Reviewer" yet, but I've looked at your changes (this one and 8232019) nevertheless :) They both look good, except that I can not verify the new "cacert" file because it is not in the patch (because it is binary). Not sure if it is necessary to upload the whole file to cr.openjdk.java.net as well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and security/infra/java/security/cert/CertPathValidator/certification both pass, then everything seems to be fine. So thumbs up from me (for both, this one and 8232019). Best regards, Volker On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf wrote: > > Hi, > > Could I please get a review of this OpenJDK 8u backport of 8233223 > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not > apply cleanly for a couple of reasons: > > 1. 8u still has the binary blob for cacerts (JDK-8193255 > not backported, yet). Instead, I've updated to the revision in > jdk11u, performed a build and copied the cacerts binary to 8u. > 2. JDK-8225392 not present in 8u, which added the checksum to > VerifyCACerts.java. Thus, the 8u backport does not include > this hunk. > 3. JDK-8234245 not present in 8u. > 4. Due to 2) and 3) above @bug annotation modified manually for these > reasons. > > Everything else is the same. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/ > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > security/infra/java/security/cert/CertPathValidator/certification > Pass, except for ActalisCA.java which is problem-listed and still > broken in HEAD (JDK-8224768) > > Thoughts? > > Once reviewed, I'll try to get this into 8u242 via the critical fix > request label workflow. > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html > From denghui.ddh at alibaba-inc.com Thu Dec 19 02:52:49 2019 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 19 Dec 2019 10:52:49 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gW0pGUl0gUkZSOiA4MjM2MTYwOiBNaXNzaW5nIFRocmVhZENyYXNoUHJvdGVj?= =?UTF-8?B?dGlvbiBmb3IgSkZSIGluIHNpZ25hbCBoYW5kbGVy?= In-Reply-To: References: , Message-ID: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> Hi Andrew, Thanks for the reply. As I said in my last message, merging os::ThreadCrashProtection and os::WatcherThreadCrashProtection is a more elegant way, actually this work was done by JDK-8183925(Decouple crash protection from watcher thread), but it's not JFR-related. And the first patch of JFR-backport use os::ThreadCrashProtection to protect jfr thread sampler crash, but miss check_crash_protection in the signal handler, so I made the changeset. Do you think we should backport JDK-8183925 to jdk8u-jfr-incubator? Best Regards, Denghui Dong ------------------------------------------------------------------ From:Andrew Dinn Send Time:2019?12?19?(???) 01:17 To:???(??) ; jdk8u-dev Subject:Re: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler Hi Denghui, On 18/12/2019 06:37, Denghui Dong wrote: > Hi all, > Please help review the following changeset: > Jira: https://bugs.openjdk.java.net/browse/JDK-8236160 > Webrev: http://cr.openjdk.java.net/~ddong/8236160/webrev.00/hotspot.changeset > Summary: > JFR thread sampler uses ThreadCrashProtection to protect thread crash, so it's necessary to call > ThreadCrashProtection::check_crash_protection in signal handler. > And a more elegant way is to merge ThreadCrashProtection and WatcherThreadCrashProtection, but this changeset didn't do that. I'm not clear why you are calling both os::WatcherThreadCrashProtection::check_crash_protection(sig, t); and os::ThreadCrashProtection::check_crash_protection(sig, t); Is it not possible simply to rely on os::ThreadCrashProtection alone as happens updtream? I am assuming that you have already back-ported class os::ThreadCrashProtection to the JFR incubator repo? Did you need to change it's behaviour in any way in order to do that? Does that have anything to do with why your are calling both routines? Also, how have you tested this patch? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Thu Dec 19 10:09:46 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 19 Dec 2019 11:09:46 +0100 Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates In-Reply-To: References: Message-ID: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com> Hi Volker, On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote: > Hi Severin, > > not strictly a 8u "Reviewer" yet, but I've looked at your changes > (this one and 8232019) nevertheless :) Thanks for the review! > They both look good, except that I can not verify the new "cacert" > file because it is not in the patch (because it is binary). Not sure > if it is necessary to upload the whole file to cr.openjdk.java.net as > well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and > security/infra/java/security/cert/CertPathValidator/certification both > pass, then everything seems to be fine. FWIW the raw download of the webrev's cacerts file should have the binary blob: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts And for 8232019: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts Thanks, Severin > So thumbs up from me (for both, this one and 8232019). > > Best regards, > Volker > > On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this OpenJDK 8u backport of 8233223 > > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not > > apply cleanly for a couple of reasons: > > > > 1. 8u still has the binary blob for cacerts (JDK-8193255 > > not backported, yet). Instead, I've updated to the revision in > > jdk11u, performed a build and copied the cacerts binary to 8u. > > 2. JDK-8225392 not present in 8u, which added the checksum to > > VerifyCACerts.java. Thus, the 8u backport does not include > > this hunk. > > 3. JDK-8234245 not present in 8u. > > 4. Due to 2) and 3) above @bug annotation modified manually for these > > reasons. > > > > Everything else is the same. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/ > > > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > > security/infra/java/security/cert/CertPathValidator/certification > > Pass, except for ActalisCA.java which is problem-listed and still > > broken in HEAD (JDK-8224768) > > > > Thoughts? > > > > Once reviewed, I'll try to get this into 8u242 via the critical fix > > request label workflow. > > > > Thanks, > > Severin > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html > > From adinn at redhat.com Thu Dec 19 13:52:42 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 19 Dec 2019 13:52:42 +0000 Subject: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection for JFR in signal handler In-Reply-To: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> References: <118431b6-0858-4e80-bb91-c9bf4730d264.denghui.ddh@alibaba-inc.com> Message-ID: <13cb4350-11ac-7906-8287-528a26a4b5a0@redhat.com> On 19/12/2019 02:52, Denghui Dong wrote: > Hi?Andrew, > ? Thanks for the reply. > ??As?I?said?in?my?last message, merging os::ThreadCrashProtection?and > os::WatcherThreadCrashProtection is a more elegant way, > actually this work was done by > JDK-8183925(Decouple?crash?protection?from?watcher?thread), but it's not > JFR-related. > ? And the first patch of JFR-backport use?os::ThreadCrashProtection to > protect jfr thread sampler crash, but miss?check_crash_protection in the > signal handler, > so I made the changeset. > ? Do you think?we?should?backport?JDK-8183925 to?jdk8u-jfr-incubator? I'm still not at all clear what you /have/ backported. Your patch inserts calls to os::ThreadCrashProtection::check_crash_protection(sig, t); into the code that calls os::WatcherThreadCrashProtection::check_crash_protection() If you have not already backported JDK-8183925 then how can those calls be valid? Have you just backported some of the patch? For example, have you added os::ThreadCrashProtection to jdk8u-jfr-incubator without removing WatcherThreadCrashProtection? If so then why woudld you not instead simply backport all of JDK-8183925? regards, Andrew Dinn ----------- > ------------------------------------------------------------------ > From:Andrew Dinn > Send Time:2019?12?19?(???) 01:17 > To:???(??) ; jdk8u-dev > > Subject:Re: [8u] [JFR] RFR: 8236160: Missing ThreadCrashProtection > for JFR in signal handler > > Hi?Denghui, > > On?18/12/2019?06:37,?Denghui?Dong?wrote: > >?Hi?all, > >???Please?help?review?the?following?changeset: > >?Jira:?https://bugs.openjdk.java.net/browse/JDK-8236160 > >?Webrev:?http://cr.openjdk.java.net/~ddong/8236160/webrev.00/hotspot.changeset > >?Summary: > >?JFR?thread?sampler?uses?ThreadCrashProtection?to?protect?thread?crash,?so?it's?necessary?to?call > >?ThreadCrashProtection::check_crash_protection?in?signal?handler. > >?And?a?more?elegant?way?is?to?merge?ThreadCrashProtection?and?WatcherThreadCrashProtection,?but?this?changeset?didn't?do?that. > I'm?not?clear?why?you?are?calling?both > > ??os::WatcherThreadCrashProtection::check_crash_protection(sig,?t); > > and > > ??os::ThreadCrashProtection::check_crash_protection(sig,?t); > > Is?it?not?possible?simply?to?rely?on?os::ThreadCrashProtection?alone?as > happens?updtream? > > I?am?assuming?that?you?have?already?back-ported?class > os::ThreadCrashProtection?to?the?JFR?incubator?repo??Did?you?need?to > change?it's?behaviour?in?any?way?in?order?to?do?that??Does?that?have > anything?to?do?with?why?your?are?calling?both?routines? > > Also,?how?have?you?tested?this?patch? > > regards, > > > Andrew?Dinn > ----------- > Senior?Principal?Software?Engineer > Red?Hat?UK?Ltd > Registered?in?England?and?Wales?under?Company?Registration?No.?03798903 > Directors:?Michael?Cunningham,?Michael?("Mike")?O'Neill > From christoph.langer at sap.com Thu Dec 19 13:55:11 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 13:55:11 +0000 Subject: Open JDK 8 Road Map In-Reply-To: References: Message-ID: Hi Joshi, the right list for this question is rather jdk8u-dev at o.j.n, so I'm sending my response there and put jdk-updates-dev on bcc. Since RedHat is the maintainer of OpenJDK8 and OpenJDK11, I guess you can bear with their statements about support. You can find this article: https://access.redhat.com/articles/1299013 So I assume, as long as RedHat supports OpenJDK 8, you can be quite sure that there will be periodic security updates. HTH Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Dheeraj Joshi > Sent: Dienstag, 20. August 2019 07:14 > To: jdk-updates-dev at openjdk.java.net > Subject: Open JDK 8 Road Map > > How long Open JDK 8 is supported by https://openjdk.java.net/ > We are currently analyzing impact of upgrading from Java 8 to Java 11. We > need to know for how long JDK 8 will get periodic security upgrades and > general patches for JDK 8 from https://openjdk.java.net/? > > Is there a Road map available for public viewing? > > Kind Regards > Dheeraj Joshi From christoph.langer at sap.com Thu Dec 19 17:04:46 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 17:04:46 +0000 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: References: Message-ID: Hi Severin, this looks good - when VerifyCACerts passes, everything is correct. We shall definitely try to backport "JDK-8193255: Root Certificates should be stored in text format and assembled at build time" somehow, to have easier certificate backports. Cheers Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Severin Gehwolf > Sent: Dienstag, 17. Dezember 2019 20:30 > To: jdk8u-dev > Cc: security-dev > Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing > root program > > Hi, > > Could I please get a review of this OpenJDK 8u backport of 8232019. The > JDK 11 patch did not apply cleanly for a couple of reasons: > > 1. 8u still has the binary blob for cacerts (JDK-8193255 not > backported, yet). Instead, I've updated to the revision in jdk11u, > performed a build and copied the cacerts binary to 8u. > 2. JDK-8225392 not present in 8u, which added the checksum to > VerifyCACerts.java. Thus, the 8u backport does not include this > hunk. @bug annotation modified manually for the same reason. > > Everything else is the same. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8232019/jdk8/01/webrev/ > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > security/infra/java/security/cert/CertPathValidator/certification > Pass, except for ActalisCA.java which is problem-listed and still > broken in HEAD (JDK-8224768) > > Thoughts? > > If reviewed, I'll try to get this in 8u242 via the critical fix request > label workflow. > > Thanks, > Severin From christoph.langer at sap.com Thu Dec 19 17:05:14 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 17:05:14 +0000 Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates In-Reply-To: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com> References: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com> Message-ID: Hi Severin, same here, looks good - when VerifyCACerts passes, everything is correct. Cheers Christoph > -----Original Message----- > From: security-dev On Behalf Of > Severin Gehwolf > Sent: Donnerstag, 19. Dezember 2019 11:10 > To: Volker Simonis > Cc: jdk8u-dev ; security-dev dev at openjdk.java.net> > Subject: Re: [8u] RFR: 8233223: Add Amazon Root CA certificates > > Hi Volker, > > On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote: > > Hi Severin, > > > > not strictly a 8u "Reviewer" yet, but I've looked at your changes > > (this one and 8232019) nevertheless :) > > Thanks for the review! > > > They both look good, except that I can not verify the new "cacert" > > file because it is not in the patch (because it is binary). Not sure > > if it is necessary to upload the whole file to cr.openjdk.java.net as > > well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and > > security/infra/java/security/cert/CertPathValidator/certification both > > pass, then everything seems to be fine. > > FWIW the raw download of the webrev's cacerts file should have the > binary blob: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8233223/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts > > And for 8232019: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8232019/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts > > Thanks, > Severin > > > So thumbs up from me (for both, this one and 8232019). > > > > Best regards, > > Volker > > > > On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf > wrote: > > > Hi, > > > > > > Could I please get a review of this OpenJDK 8u backport of 8233223 > > > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not > > > apply cleanly for a couple of reasons: > > > > > > 1. 8u still has the binary blob for cacerts (JDK-8193255 > > > not backported, yet). Instead, I've updated to the revision in > > > jdk11u, performed a build and copied the cacerts binary to 8u. > > > 2. JDK-8225392 not present in 8u, which added the checksum to > > > VerifyCACerts.java. Thus, the 8u backport does not include > > > this hunk. > > > 3. JDK-8234245 not present in 8u. > > > 4. Due to 2) and 3) above @bug annotation modified manually for these > > > reasons. > > > > > > Everything else is the same. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8233223/jdk8/01/webrev/ > > > > > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > > > security/infra/java/security/cert/CertPathValidator/certification > > > Pass, except for ActalisCA.java which is problem-listed and still > > > broken in HEAD (JDK-8224768) > > > > > > Thoughts? > > > > > > Once reviewed, I'll try to get this into 8u242 via the critical fix > > > request label workflow. > > > > > > Thanks, > > > Severin > > > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019- > December/010813.html > > > From gil at azul.com Thu Dec 19 17:35:49 2019 From: gil at azul.com (Gil Tene) Date: Thu, 19 Dec 2019 17:35:49 +0000 Subject: Open JDK 8 Road Map In-Reply-To: References: Message-ID: Sent from my iPad On Dec 19, 2019, at 6:07 AM, Langer, Christoph wrote: ?Hi Joshi, the right list for this question is rather jdk8u-dev at o.j.n, so I'm sending my response there and put jdk-updates-dev on bcc. Since RedHat is the maintainer of OpenJDK8 and OpenJDK11, I guess you can bear with their statements about support. You can find this article: https://access.redhat.com/articles/1299013 So I assume, as long as RedHat supports OpenJDK 8, you can be quite sure that there will be periodic security updates. This needs some correction IMO. Saying that ?RedHat is the maintainer of OpenJDK8 and OpenJDK11? would be a mis-statement of the situation. OpenJDK 8 and 11 are maintained through a community effort. There is no official or specific Red Hat position, stewardship, or control of these projects. AFAIK Andrew Haley, a Red Hat employee and a significant OpenJDK contributor with a long history of OSS leadership is the project lead for OpenJDK 8u and and the lead maintainer for 11u. A multitude of engineers from various companies (including significant work by teams at Red Hat, Azul, Amazon, SAP, and several others) as well as individuals, regularly contribute to and coordinate on update work on the upstream OpenJDK 8 and 11 source code projects, with multiple downstream binary distributions being built and offered at various places. Binary distributions of OpenJDK typically make curation choices on contents and packaging, perform extensive platform testing and verification, and may include various modifications not included in the upstream OpenJDK 8u and 11u source code. Red Hat?s distribution of a OpenJDK is one of those distributions. It differs in some specific ways from the upstream source code in (described in e.g. https://access.redhat.com/solutions/2489791 ) and, like other binary distributions, the source code for it is separately available elsewhere (not as part of the OpenJDK project). Per the link mentioned ( https://access.redhat.com/articles/1299013 ) the Red Hat distribution is commercially supported specifically on RHEL and on Windows, with updates available for certain timelines under support entitlements. The binaries for such updates may also be available for download without a support contract, but that is probably detailed elsewhere. Other distributions are available under commercial support, as well as for Free download, with varying statements about the length of time they are expected to continue to do so. E.g. the timeline for Zulu Community support can be found at https://www.azul.com/products/zulu-community/ , and includes support for a wide range of JDK versions, Linux variants, CPU types, and packaging mechanisms. Corretto, Liberia, Dragonwell, and Adopt are other OpenJDK distributions that come to mind (and there are several others as well). It is likely fair to assume that as long as at least one binary distribution exists that employs engineers to regularly maintain and update the distribution, the sources for such updates will be freely available, and that most of the changes will likely end up upstream in the OpenJDK 8u and 11u source code projects. We all seem to happily work together to coordinate work on an agreed upon upstream version when it comes to the bulk of bug fixes, backports, and security fixes, with downstream differences being mostly a matter of curation choices. But there is no one company who owns or controls the maintenance of OpenJDK 8u or 11u source code projects, and the limits on time that one company or organization?s statements suggest about their plans to continue providing downstream distributions and updates should not be interpreted as statements about project?s plans or commitments, or about what other downstream distributions may or may not end up doing. Specifically, the link specific provided would suggest Red Hat?s commitment to 8u lasts to June 2023, while the Zulu Community link shows March 2026 for 8u. And I?m sure there are several other dates one can dig up. This is all ?a good thing (TM)?. It?s a lively and active community. HTH Christoph -----Original Message----- From: jdk-updates-dev On Behalf Of Dheeraj Joshi Sent: Dienstag, 20. August 2019 07:14 To: jdk-updates-dev at openjdk.java.net Subject: Open JDK 8 Road Map How long Open JDK 8 is supported by https://openjdk.java.net/ We are currently analyzing impact of upgrading from Java 8 to Java 11. We need to know for how long JDK 8 will get periodic security upgrades and general patches for JDK 8 from https://openjdk.java.net/? Is there a Road map available for public viewing? Kind Regards Dheeraj Joshi From christoph.langer at sap.com Thu Dec 19 18:12:22 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 18:12:22 +0000 Subject: Open JDK 8 Road Map In-Reply-To: References: Message-ID: Hi Gil, Ok, yes, I was just too lazy to write up such a long text and wanted to point to RedHat?s statements as the ?least common denominator? for a support timeline of OpenJDK8. ?? But of course, as you say, it?s all a community effort with various parties involved. And nobody can, as of now, say how long OpenJDK8 and/or OpenJDK11 will eventually be supported. So, thank you for bringing up the whole picture here and correcting a possible misconception that could be taken out of my initial mail. Cheers Christoph From: Gil Tene Sent: Donnerstag, 19. Dezember 2019 18:36 To: Langer, Christoph Cc: Dheeraj Joshi ; jdk8u-dev Subject: Re: Open JDK 8 Road Map Sent from my iPad On Dec 19, 2019, at 6:07 AM, Langer, Christoph > wrote: ?Hi Joshi, the right list for this question is rather jdk8u-dev at o.j.n, so I'm sending my response there and put jdk-updates-dev on bcc. Since RedHat is the maintainer of OpenJDK8 and OpenJDK11, I guess you can bear with their statements about support. You can find this article: https://access.redhat.com/articles/1299013 So I assume, as long as RedHat supports OpenJDK 8, you can be quite sure that there will be periodic security updates. This needs some correction IMO. Saying that ?RedHat is the maintainer of OpenJDK8 and OpenJDK11? would be a mis-statement of the situation. OpenJDK 8 and 11 are maintained through a community effort. There is no official or specific Red Hat position, stewardship, or control of these projects. AFAIK Andrew Haley, a Red Hat employee and a significant OpenJDK contributor with a long history of OSS leadership is the project lead for OpenJDK 8u and and the lead maintainer for 11u. A multitude of engineers from various companies (including significant work by teams at Red Hat, Azul, Amazon, SAP, and several others) as well as individuals, regularly contribute to and coordinate on update work on the upstream OpenJDK 8 and 11 source code projects, with multiple downstream binary distributions being built and offered at various places. Binary distributions of OpenJDK typically make curation choices on contents and packaging, perform extensive platform testing and verification, and may include various modifications not included in the upstream OpenJDK 8u and 11u source code. Red Hat?s distribution of a OpenJDK is one of those distributions. It differs in some specific ways from the upstream source code in (described in e.g. https://access.redhat.com/solutions/2489791 ) and, like other binary distributions, the source code for it is separately available elsewhere (not as part of the OpenJDK project). Per the link mentioned ( https://access.redhat.com/articles/1299013 ) the Red Hat distribution is commercially supported specifically on RHEL and on Windows, with updates available for certain timelines under support entitlements. The binaries for such updates may also be available for download without a support contract, but that is probably detailed elsewhere. Other distributions are available under commercial support, as well as for Free download, with varying statements about the length of time they are expected to continue to do so. E.g. the timeline for Zulu Community support can be found at https://www.azul.com/products/zulu-community/ , and includes support for a wide range of JDK versions, Linux variants, CPU types, and packaging mechanisms. Corretto, Liberia, Dragonwell, and Adopt are other OpenJDK distributions that come to mind (and there are several others as well). It is likely fair to assume that as long as at least one binary distribution exists that employs engineers to regularly maintain and update the distribution, the sources for such updates will be freely available, and that most of the changes will likely end up upstream in the OpenJDK 8u and 11u source code projects. We all seem to happily work together to coordinate work on an agreed upon upstream version when it comes to the bulk of bug fixes, backports, and security fixes, with downstream differences being mostly a matter of curation choices. But there is no one company who owns or controls the maintenance of OpenJDK 8u or 11u source code projects, and the limits on time that one company or organization?s statements suggest about their plans to continue providing downstream distributions and updates should not be interpreted as statements about project?s plans or commitments, or about what other downstream distributions may or may not end up doing. Specifically, the link specific provided would suggest Red Hat?s commitment to 8u lasts to June 2023, while the Zulu Community link shows March 2026 for 8u. And I?m sure there are several other dates one can dig up. This is all ?a good thing (TM)?. It?s a lively and active community. HTH Christoph -----Original Message----- From: jdk-updates-dev > On Behalf Of Dheeraj Joshi Sent: Dienstag, 20. August 2019 07:14 To: jdk-updates-dev at openjdk.java.net Subject: Open JDK 8 Road Map How long Open JDK 8 is supported by https://openjdk.java.net/ We are currently analyzing impact of upgrading from Java 8 to Java 11. We need to know for how long JDK 8 will get periodic security upgrades and general patches for JDK 8 from https://openjdk.java.net/? Is there a Road map available for public viewing? Kind Regards Dheeraj Joshi From gnu.andrew at redhat.com Thu Dec 19 19:29:45 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 19 Dec 2019 19:29:45 +0000 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: References: Message-ID: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> On 17/12/2019 19:30, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this OpenJDK 8u backport of 8232019. The > JDK 11 patch did not apply cleanly for a couple of reasons: > > 1. 8u still has the binary blob for cacerts (JDK-8193255 not > backported, yet). Instead, I've updated to the revision in jdk11u, > performed a build and copied the cacerts binary to 8u. > 2. JDK-8225392 not present in 8u, which added the checksum to > VerifyCACerts.java. Thus, the 8u backport does not include this > hunk. @bug annotation modified manually for the same reason. > > Everything else is the same. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/ > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > security/infra/java/security/cert/CertPathValidator/certification > Pass, except for ActalisCA.java which is problem-listed and still > broken in HEAD (JDK-8224768) > > Thoughts? > > If reviewed, I'll try to get this in 8u242 via the critical fix request > label workflow. > > Thanks, > Severin > Going on this & the similar Amazon fix, I'd say we should backport JDK-8193255 & JDK-8225392 first. The previous updates which alter a binary file have been pretty much unreviewable and, if there's a better solution to that, I'd rather we had it sooner rather than later. Likewise, judging by the comment on JDK-8234245, I'd say that needs to be applied between the LuxTrust & Amazon ones: "This fixes an issue after JDK-8232019, so it needs to be included. Patch applies cleanly." Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Thu Dec 19 19:32:06 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Thu, 19 Dec 2019 19:32:06 +0000 Subject: [RFC] 8236174: Update javadoc since tags in the jfr backport In-Reply-To: References: <4faecebe5e5718c4b0d2f774451201a5c8c7d751.camel@redhat.com> Message-ID: On 18/12/2019 16:33, Mario Torre wrote: > Hi Andrew, > > Yes, those are the JFR classes, they are public. > > The CSR mentioned that: "The backport of the API looks appropriate for > the goals of the project". > > On the other hand, you have a point that there is not some discrepancy > between 8 and later version whose javadocs says those classes were > introduced in 9. Perhaps we should not have the since updated... Any > ideas? I already pushed but we can rollback the patch if necessary. > > Cheers, > Mario > > On Wed, Dec 18, 2019 at 5:29 PM Andrew John Hughes > wrote: >> >> >> >> On 18/12/2019 16:02, Mario Torre wrote: >>> Again from Marcus: >>> >>> Jira: https://bugs.openjdk.java.net/browse/JDK-8236174 >>> Webrev: http://cr.openjdk.java.net/~hirt/JDK-8236174/webrev.0/ >>> >>> I tested the patch and is approved. >>> >>> Cheers, >>> Mario >>> >> >> Are these classes documented publicly? >> >> If not, I suggest not backporting this, otherwise it'll just create >> backport headaches. >> -- >> 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 >> > > If they're public, then fixing it is the right thing to do. Backports will just have to work around it. I was concerned that it was being done for classes for which Javadocs will never actually be generated, which applies to a few methods added within the JDK codebase where I've left the @since as it was in the backport. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Thu Dec 19 20:13:45 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 19 Dec 2019 21:13:45 +0100 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> References: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> Message-ID: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> Hi Andrew, On Thu, 2019-12-19 at 19:29 +0000, Andrew John Hughes wrote: > > On 17/12/2019 19:30, Severin Gehwolf wrote: > > Hi, > > > > Could I please get a review of this OpenJDK 8u backport of 8232019. The > > JDK 11 patch did not apply cleanly for a couple of reasons: > > > > 1. 8u still has the binary blob for cacerts (JDK-8193255 not > > backported, yet). Instead, I've updated to the revision in jdk11u, > > performed a build and copied the cacerts binary to 8u. > > 2. JDK-8225392 not present in 8u, which added the checksum to > > VerifyCACerts.java. Thus, the 8u backport does not include this > > hunk. @bug annotation modified manually for the same reason. > > > > Everything else is the same. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/ > > > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > > security/infra/java/security/cert/CertPathValidator/certification > > Pass, except for ActalisCA.java which is problem-listed and still > > broken in HEAD (JDK-8224768) > > > > Thoughts? > > > > If reviewed, I'll try to get this in 8u242 via the critical fix request > > label workflow. > > > > Thanks, > > Severin > > > > Going on this & the similar Amazon fix, I'd say we should backport > JDK-8193255 & JDK-8225392 first. The previous updates which alter a > binary file have been pretty much unreviewable and, if there's a better > solution to that, I'd rather we had it sooner rather than later. I agree with you that we should backport JDK-8193255. Question is when would be a good time to do this. Given that there would be some benefit for these to go into 8u242 if possible I'm not sure we should do JDK- 8193255 right now. After all, we've accepted this situation of having the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 - which brought this in - was integrated in 8u222. The risk of a backport of JDK-8193255 seems higher (the build system in 8u is different, there is a bug tail) than accepting these backports with the binary blob updates. Note that the backports as-is have been reviewed by Christoph Langer, Volker Simonis and internally by Martin Balao. So, it looks like there are the following options: 1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is. 2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK- 8233223 to 8u242. 3. Defer backports of 2) to 8u252 with the caveat that we won't have certain certificates as compared to Oracle JDK. I'm leaning towards option 1) or 3). Slight preference for 1) > Likewise, judging by the comment on JDK-8234245, I'd say that needs to > be applied between the LuxTrust & Amazon ones: > > "This fixes an issue after JDK-8232019, so it needs to be included. > Patch applies cleanly." Not sure what caused JDK-8234245. It might be that it was caused by the list of certs in the keystore not being ordered at first (fixed by JDK- 8225392?). Thanks, Severin From christoph.langer at sap.com Thu Dec 19 20:51:35 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Dec 2019 20:51:35 +0000 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> References: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> Message-ID: Hi, Just FWIW: JDK-8234245 fixed an issue where a wrong checksum was used in the test update that came with JDK-8232019. So, both can probably marked fixed with one change (e.g. adding both bugs to the submit message...) Cheers Christoph > -----Original Message----- > From: jdk8u-dev On Behalf Of > Severin Gehwolf > Sent: Donnerstag, 19. Dezember 2019 21:14 > To: Andrew John Hughes ; jdk8u-dev dev at openjdk.java.net> > Cc: security-dev > Subject: Re: [8u] RFR: 8232019: Add LuxTrust certificate updates to the > existing root program > > Hi Andrew, > > On Thu, 2019-12-19 at 19:29 +0000, Andrew John Hughes wrote: > > > > On 17/12/2019 19:30, Severin Gehwolf wrote: > > > Hi, > > > > > > Could I please get a review of this OpenJDK 8u backport of 8232019. The > > > JDK 11 patch did not apply cleanly for a couple of reasons: > > > > > > 1. 8u still has the binary blob for cacerts (JDK-8193255 not > > > backported, yet). Instead, I've updated to the revision in jdk11u, > > > performed a build and copied the cacerts binary to 8u. > > > 2. JDK-8225392 not present in 8u, which added the checksum to > > > VerifyCACerts.java. Thus, the 8u backport does not include this > > > hunk. @bug annotation modified manually for the same reason. > > > > > > Everything else is the same. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232019 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK- > 8232019/jdk8/01/webrev/ > > > > > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > > > security/infra/java/security/cert/CertPathValidator/certification > > > Pass, except for ActalisCA.java which is problem-listed and still > > > broken in HEAD (JDK-8224768) > > > > > > Thoughts? > > > > > > If reviewed, I'll try to get this in 8u242 via the critical fix request > > > label workflow. > > > > > > Thanks, > > > Severin > > > > > > > Going on this & the similar Amazon fix, I'd say we should backport > > JDK-8193255 & JDK-8225392 first. The previous updates which alter a > > binary file have been pretty much unreviewable and, if there's a better > > solution to that, I'd rather we had it sooner rather than later. > > I agree with you that we should backport JDK-8193255. Question is when > would be a good time to do this. Given that there would be some benefit > for these to go into 8u242 if possible I'm not sure we should do JDK- > 8193255 right now. After all, we've accepted this situation of having > the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 - > which brought this in - was integrated in 8u222. > > The risk of a backport of JDK-8193255 seems higher (the build system in > 8u is different, there is a bug tail) than accepting these backports > with the binary blob updates. Note that the backports as-is have been > reviewed by Christoph Langer, Volker Simonis and internally by Martin > Balao. > > So, it looks like there are the following options: > 1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is. > 2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK- > 8233223 to 8u242. > 3. Defer backports of 2) to 8u252 with the caveat that we won't have > certain certificates as compared to Oracle JDK. > > I'm leaning towards option 1) or 3). Slight preference for 1) > > > Likewise, judging by the comment on JDK-8234245, I'd say that needs to > > be applied between the LuxTrust & Amazon ones: > > > > "This fixes an issue after JDK-8232019, so it needs to be included. > > Patch applies cleanly." > > Not sure what caused JDK-8234245. It might be that it was caused by the > list of certs in the keystore not being ordered at first (fixed by JDK- > 8225392?). > > Thanks, > Severin From akozlov at azul.com Fri Dec 20 01:33:49 2019 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 20 Dec 2019 04:33:49 +0300 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 Message-ID: Hi, please review a backport of JDK-8143925: http://cr.openjdk.java.net/~akozlov/8143925/hotspot.00/ http://cr.openjdk.java.net/~akozlov/8143925/jdk.00/ and of JDK-8146581: http://cr.openjdk.java.net/~akozlov/8146581/webrev.00/ Adjustments for JDK-8143925 are hotspot: * vm_version_aarch64.cpp is missing * assembler_x86.[ch]pp - xorb and added instructions encoding with AVX-1 * stubRoutines_x86.hpp, vm_version_x86.cpp - no CRC32C intrinsic - no generate_CRC32C_table - no UseCRC32CIntrinsics * stubRoutines_x86_{32,64}.hpp - code_size2 increased accrodingly * stubGenerator_x86_{32,64}.cpp - remove AVX-512 related code * vmSymbols.cpp, c2compiler.cpp, library_call.cpp - adjustments for intrinsics framework, parameter to Node::operator new() * TestAESBase.java, TestAESMain.java - different path jdk: * CounterMode.java - no @HotSpotIntrinsicCandidate, use existing range check utils For JDK-8146581: * vm_version_x86.cpp - no CRC32C intrinsic Thanks, Anton From gnu.andrew at redhat.com Fri Dec 20 07:42:12 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 20 Dec 2019 07:42:12 +0000 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> References: <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> Message-ID: <21aecc8e-9b20-fe08-fc7d-8bb2fba69ad7@redhat.com> On 19/12/2019 20:13, Severin Gehwolf wrote: snip... >>> >> >> Going on this & the similar Amazon fix, I'd say we should backport >> JDK-8193255 & JDK-8225392 first. The previous updates which alter a >> binary file have been pretty much unreviewable and, if there's a better >> solution to that, I'd rather we had it sooner rather than later. > > I agree with you that we should backport JDK-8193255. Question is when > would be a good time to do this. Given that there would be some benefit > for these to go into 8u242 if possible I'm not sure we should do JDK- > 8193255 right now. After all, we've accepted this situation of having > the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 - > which brought this in - was integrated in 8u222. > > The risk of a backport of JDK-8193255 seems higher (the build system in > 8u is different, there is a bug tail) than accepting these backports > with the binary blob updates. Note that the backports as-is have been > reviewed by Christoph Langer, Volker Simonis and internally by Martin > Balao. > > So, it looks like there are the following options: > 1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is. > 2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK- > 8233223 to 8u242. > 3. Defer backports of 2) to 8u252 with the caveat that we won't have > certain certificates as compared to Oracle JDK. > > I'm leaning towards option 1) or 3). Slight preference for 1) > >> Likewise, judging by the comment on JDK-8234245, I'd say that needs to >> be applied between the LuxTrust & Amazon ones: >> >> "This fixes an issue after JDK-8232019, so it needs to be included. >> Patch applies cleanly." > > Not sure what caused JDK-8234245. It might be that it was caused by the > list of certs in the keystore not being ordered at first (fixed by JDK- > 8225392?). > > Thanks, > Severin > There's an option #4: 4. Propose these backports for 8u242 and do the correct backports, with JDK-8193255 and friends, in 8u252. 8193255 is sensitive to the status of cacerts at the time it is applied. It needs to be backported with cacerts containing the same certificates as it did when applied in later versions, so that the textual replacements match. By applying these backports in 8u252, we'd complicate the 8193255 backport further by having to effectively include backports of the Amazon & LuxTrust updates in it. So what I'd suggest is: 1. Do the full backport series in 8u252 from 8193255 on. 2. Create a separate bug for 8u242 to add the new certificates and apply for jdk8u-critical-request for that. When the two are merged together, the webrev changes in 8u242 should be the same as those in 8u252, and the changed cacerts binary can just be deleted. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 20 07:53:41 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 20 Dec 2019 07:53:41 +0000 Subject: [8u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: References: Message-ID: <6e2b303a-d429-fff3-81ab-2bf8b6638ac3@redhat.com> On 04/11/2019 18:41, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 8215032 [1]. > > CSR for 8u requested here [2]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8215032/8215032.jdk8u.jdk.webrev.00/ > > Changes from 11u patch [3]: > > * File paths > > * java.security changes need to be populated through the different > java.security- files > > * Copyright dates > * KerberosPrincipal.java > * Checksum.java > * Config.java > * KrbAsRep.java > * KrbTgsRep.java > * PAData.java > * KrbTgsReq.java > > * Failing hooks because of the context (no actual code changes) > * KrbAsReq.java > * Manually added "import java.util.Arrays;" > * EncKDCRepPart.java > * 8u has "" tags because 8132130 was not backported to 8u > * Manually replaced the structure adding "encrypted-pa-data [12] > SEQUENCE OF PA-DATA OPTIONAL" > * KDC.java > * Indentation issues > > * KrbTgsReq.java > * "Arrays" already imported (introduced in 6355584 and not removed > since then) > > * ReferralsTest.java > * @library jtreg header removed > > Testing: > > * No regressions found in sun/security/krb5 > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8215032 > [2] - https://bugs.openjdk.java.net/browse/JDK-8233512 > [3] - http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/f2b580a5721c > Looks good to me. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Fri Dec 20 09:13:54 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Fri, 20 Dec 2019 09:13:54 +0000 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 In-Reply-To: <dafabc7e-e6c0-5b2a-999e-ddbe337c1d12@azul.com> References: <dafabc7e-e6c0-5b2a-999e-ddbe337c1d12@azul.com> Message-ID: <d25598e9-1bd6-f824-2f02-5c953f9921bd@redhat.com> On 20/12/2019 01:33, Anton Kozlov wrote: > Hi, > > please review a backport of JDK-8143925: > > http://cr.openjdk.java.net/~akozlov/8143925/hotspot.00/ > http://cr.openjdk.java.net/~akozlov/8143925/jdk.00/ > > and of JDK-8146581: > > http://cr.openjdk.java.net/~akozlov/8146581/webrev.00/ > Please keep to one bug review per thread for simplicity. > Adjustments for JDK-8143925 are > hotspot: > * vm_version_aarch64.cpp is missing > * assembler_x86.[ch]pp - xorb and added instructions encoding with AVX-1 > * stubRoutines_x86.hpp, vm_version_x86.cpp - no CRC32C intrinsic > - no generate_CRC32C_table > - no UseCRC32CIntrinsics > * stubRoutines_x86_{32,64}.hpp - code_size2 increased accrodingly > * stubGenerator_x86_{32,64}.cpp - remove AVX-512 related code > * vmSymbols.cpp, c2compiler.cpp, library_call.cpp - adjustments for intrinsics framework, parameter to Node::operator new() > * TestAESBase.java, TestAESMain.java - different path > jdk: > * CounterMode.java - no @HotSpotIntrinsicCandidate, use existing range check utils > Looks good to me, though I think this warrants a second review from someone more familiar with the HotSpot side. > For JDK-8146581: > * vm_version_x86.cpp - no CRC32C intrinsic > > Thanks, > Anton > Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Fri Dec 20 09:38:02 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Dec 2019 10:38:02 +0100 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: <21aecc8e-9b20-fe08-fc7d-8bb2fba69ad7@redhat.com> References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com> <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> <21aecc8e-9b20-fe08-fc7d-8bb2fba69ad7@redhat.com> Message-ID: <4e12d11cf3f3c7bdde176426049ec8fb011405e4.camel@redhat.com> On Fri, 2019-12-20 at 07:42 +0000, Andrew John Hughes wrote: > > On 19/12/2019 20:13, Severin Gehwolf wrote: > > snip... > > > > > > > Going on this & the similar Amazon fix, I'd say we should backport > > > JDK-8193255 & JDK-8225392 first. The previous updates which alter a > > > binary file have been pretty much unreviewable and, if there's a better > > > solution to that, I'd rather we had it sooner rather than later. > > > > I agree with you that we should backport JDK-8193255. Question is when > > would be a good time to do this. Given that there would be some benefit > > for these to go into 8u242 if possible I'm not sure we should do JDK- > > 8193255 right now. After all, we've accepted this situation of having > > the binary blob for all of 8u222 and 8u232. Note that JDK-8189131 - > > which brought this in - was integrated in 8u222. > > > > The risk of a backport of JDK-8193255 seems higher (the build system in > > 8u is different, there is a bug tail) than accepting these backports > > with the binary blob updates. Note that the backports as-is have been > > reviewed by Christoph Langer, Volker Simonis and internally by Martin > > Balao. > > > > So, it looks like there are the following options: > > 1. Accept backports of JDK-8232019 and JDK-8233223 into 8u242 as is. > > 2. Backport JDK-8193255, JDK-8225392, JDK-8234245, JDK-8232019 and JDK- > > 8233223 to 8u242. > > 3. Defer backports of 2) to 8u252 with the caveat that we won't have > > certain certificates as compared to Oracle JDK. > > > > I'm leaning towards option 1) or 3). Slight preference for 1) > > > > > Likewise, judging by the comment on JDK-8234245, I'd say that needs to > > > be applied between the LuxTrust & Amazon ones: > > > > > > "This fixes an issue after JDK-8232019, so it needs to be included. > > > Patch applies cleanly." > > > > Not sure what caused JDK-8234245. It might be that it was caused by the > > list of certs in the keystore not being ordered at first (fixed by JDK- > > 8225392?). > > > > Thanks, > > Severin > > > > There's an option #4: > > 4. Propose these backports for 8u242 and do the correct backports, with > JDK-8193255 and friends, in 8u252. OK. > 8193255 is sensitive to the status of cacerts at the time it is applied. > It needs to be backported with cacerts containing the same certificates > as it did when applied in later versions, so that the textual > replacements match. By applying these backports in 8u252, we'd > complicate the 8193255 backport further by having to effectively include > backports of the Amazon & LuxTrust updates in it. > > So what I'd suggest is: > > 1. Do the full backport series in 8u252 from 8193255 on. > 2. Create a separate bug for 8u242 to add the new certificates and apply > for jdk8u-critical-request for that. Can you clarify why a separate bug for 8u242 would be needed? Why can't we just use 8232019 and 8233223? I'd include mentioning 8232019 and 8233223 for the backport of 8193255 for it to be clear that it has been taken care of those additional cert updates. The 8193255 backport would only start once 8u242 backports got merged back into jdk8u-dev. At no point we'd miss inclusion of those. Saves creation of extra bugs. Thanks, Severin > When the two are merged together, the webrev changes in 8u242 should be > the same as those in 8u252, and the changed cacerts binary can just be > deleted. > > Thanks, From aph at redhat.com Fri Dec 20 11:02:26 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 20 Dec 2019 12:02:26 +0100 Subject: Open JDK 8 Road Map In-Reply-To: <F8757C0D-E71C-4951-81F2-3C5CE00B1C75@azul.com> References: <DB8PR02MB55472D4EEB4F15F7DBD059CB8A520@DB8PR02MB5547.eurprd02.prod.outlook.com> <F8757C0D-E71C-4951-81F2-3C5CE00B1C75@azul.com> Message-ID: <55fe96af-81c6-7ad9-f875-87645c0c1456@redhat.com> On 12/19/19 5:35 PM, Gil Tene wrote: > It is likely fair to assume that as long as at least one binary distribution exists > that employs engineers to regularly maintain and update the distribution, the > sources for such updates will be freely available, and that most of the changes > will likely end up upstream in the OpenJDK 8u and 11u source code projects. Not necessarily. It's quite possible that, for example, some distributor will continue to provide binaries to customers with long-term support contracts but neither make them widely available nor push the source code changes to the upstream project. It also partly depends on for how long the JCK continues to be available. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sreerama.naga at gmail.com Fri Dec 20 15:08:23 2019 From: sreerama.naga at gmail.com (brahmam) Date: Fri, 20 Dec 2019 20:38:23 +0530 Subject: Any openjdk tool available to create tzdb.dat Message-ID: <CAFVT4hZR7CHVm_=-HK8tgdSMZ4ZKWu+UqObzQk54nyOTuL4koA@mail.gmail.com> Hi Group, Is any tool available from openjdk to create tzdb.dat file from time zone database(ex:tzdata2019c.tar.gz) ? Here looking for creating the tzdb.dat file and use in the jdk, without using any tzupdater tools. Thanks in advance! Regards, Sreeram From martinrb at google.com Fri Dec 20 15:44:22 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Dec 2019 07:44:22 -0800 Subject: Any openjdk tool available to create tzdb.dat In-Reply-To: <CAFVT4hZR7CHVm_=-HK8tgdSMZ4ZKWu+UqObzQk54nyOTuL4koA@mail.gmail.com> References: <CAFVT4hZR7CHVm_=-HK8tgdSMZ4ZKWu+UqObzQk54nyOTuL4koA@mail.gmail.com> Message-ID: <CA+kOe08NFJD4+BucLXO-H_oU4Pi2V8Drh52RDCnbANrtVBNYvg@mail.gmail.com> A jdk image includes a tzdb.dat, so the openjdk build process must know how to generate this file. You could dig into the makefiles to extract the details, or you could use the jdk build itself as a black box to generate tzdb.dat (we do that). On Fri, Dec 20, 2019 at 7:09 AM brahmam <sreerama.naga at gmail.com> wrote: > Hi Group, > > Is any tool available from openjdk to create tzdb.dat file from time zone > database(ex:tzdata2019c.tar.gz) ? Here looking for creating the tzdb.dat > file and use in the jdk, without using any tzupdater tools. > > Thanks in advance! > > Regards, > Sreeram > From sreerama.naga at gmail.com Fri Dec 20 16:03:45 2019 From: sreerama.naga at gmail.com (brahmam) Date: Fri, 20 Dec 2019 21:33:45 +0530 Subject: Any openjdk tool available to create tzdb.dat In-Reply-To: <CA+kOe08NFJD4+BucLXO-H_oU4Pi2V8Drh52RDCnbANrtVBNYvg@mail.gmail.com> References: <CAFVT4hZR7CHVm_=-HK8tgdSMZ4ZKWu+UqObzQk54nyOTuL4koA@mail.gmail.com> <CA+kOe08NFJD4+BucLXO-H_oU4Pi2V8Drh52RDCnbANrtVBNYvg@mail.gmail.com> Message-ID: <CAFVT4haEc4Le+sSfyrc8vH51xQg6a2qxJ=RVhh1j0WfGOL1bqA@mail.gmail.com> Hi Martin, Thank you for your response. Could you please guide me how I can use the jdk build to generate tzdb.dat? Regards, Sreeram On Fri, 20 Dec 2019, 21:14 Martin Buchholz, <martinrb at google.com> wrote: > A jdk image includes a tzdb.dat, so the openjdk build process must know > how to generate this file. > You could dig into the makefiles to extract the details, or you could use > the jdk build itself as a black box to generate tzdb.dat (we do that). > > On Fri, Dec 20, 2019 at 7:09 AM brahmam <sreerama.naga at gmail.com> wrote: > >> Hi Group, >> >> Is any tool available from openjdk to create tzdb.dat file from time zone >> database(ex:tzdata2019c.tar.gz) ? Here looking for creating the tzdb.dat >> file and use in the jdk, without using any tzupdater tools. >> >> Thanks in advance! >> >> Regards, >> Sreeram >> > From martinrb at google.com Fri Dec 20 16:08:11 2019 From: martinrb at google.com (Martin Buchholz) Date: Fri, 20 Dec 2019 08:08:11 -0800 Subject: Any openjdk tool available to create tzdb.dat In-Reply-To: <CAFVT4haEc4Le+sSfyrc8vH51xQg6a2qxJ=RVhh1j0WfGOL1bqA@mail.gmail.com> References: <CAFVT4hZR7CHVm_=-HK8tgdSMZ4ZKWu+UqObzQk54nyOTuL4koA@mail.gmail.com> <CA+kOe08NFJD4+BucLXO-H_oU4Pi2V8Drh52RDCnbANrtVBNYvg@mail.gmail.com> <CAFVT4haEc4Le+sSfyrc8vH51xQg6a2qxJ=RVhh1j0WfGOL1bqA@mail.gmail.com> Message-ID: <CA+kOe08yxNqRNzP-f-1z+_BzeqAta8hh-YenEiBOak=NXn-YkQ@mail.gmail.com> make/data/tzdata contains tzdata source files, e.g. make/data/tzdata/africa Just replace all of those source files and rebuild. (but yes, tzupdater should be open-sourced) On Fri, Dec 20, 2019 at 8:03 AM brahmam <sreerama.naga at gmail.com> wrote: > Hi Martin, > > Thank you for your response. > > Could you please guide me how I can use the jdk build to generate tzdb.dat? > > Regards, > Sreeram > > On Fri, 20 Dec 2019, 21:14 Martin Buchholz, <martinrb at google.com> wrote: > >> A jdk image includes a tzdb.dat, so the openjdk build process must know >> how to generate this file. >> You could dig into the makefiles to extract the details, or you could use >> the jdk build itself as a black box to generate tzdb.dat (we do that). >> >> On Fri, Dec 20, 2019 at 7:09 AM brahmam <sreerama.naga at gmail.com> wrote: >> >>> Hi Group, >>> >>> Is any tool available from openjdk to create tzdb.dat file from time zone >>> database(ex:tzdata2019c.tar.gz) ? Here looking for creating the tzdb.dat >>> file and use in the jdk, without using any tzupdater tools. >>> >>> Thanks in advance! >>> >>> Regards, >>> Sreeram >>> >> From sgehwolf at redhat.com Fri Dec 20 17:06:52 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Dec 2019 18:06:52 +0100 Subject: [8u] RFR 8218553: Enhance keystore load debug output In-Reply-To: <af4ce540-37c3-88de-fe4d-4a20cf480789@redhat.com> References: <af4ce540-37c3-88de-fe4d-4a20cf480789@redhat.com> Message-ID: <ed63116b563c0f1db14af7aa9a80f4db381e2249.camel@redhat.com> Hi Martin, On Thu, 2019-08-22 at 12:59 -0300, Martin Balao wrote: > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8218553/webrev.8218553.jdk8u.jdk.00/ Looks OK to me. Thanks, Severin From akozlov at azul.com Fri Dec 20 17:18:25 2019 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 20 Dec 2019 20:18:25 +0300 Subject: [8u] RFR: 8143925 : enhancing CounterMode.crypt() for AESCrypt.implEncryptBlock() + 8146581 : Minor corrections to the patch submitted for earlier bug id - 8143925 In-Reply-To: <d25598e9-1bd6-f824-2f02-5c953f9921bd@redhat.com> References: <dafabc7e-e6c0-5b2a-999e-ddbe337c1d12@azul.com> <d25598e9-1bd6-f824-2f02-5c953f9921bd@redhat.com> Message-ID: <95d7dae6-215e-3fdf-276b-b1e516fbb2b1@azul.com> On 20.12.2019 12:13, Andrew John Hughes wrote: >> please review a backport of JDK-8143925: >> and of JDK-8146581: > > Please keep to one bug review per thread for simplicity. Thanks, we'll do next time. These seemed to be closely related, so I decided that it would be OK. > Looks good to me, though I think this warrants a second review from > someone more familiar with the HotSpot side. OK, waiting for another review before requesting push. Thanks, Anton From hohensee at amazon.com Fri Dec 20 19:35:32 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 20 Dec 2019 19:35:32 +0000 Subject: CFV: New JDK 8 Updates Reviewer: Volker Simonis Message-ID: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project Reviewer. Volker was one of the authors of the PPC port, is Member of the build, hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on the jdk and jdk updates projects, a Committer on the jdk 8 updates project [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing more jdk8u reviews lately, and it would expedite things for him to have Reviewer status. Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the voting period by 4 days to a total of 18 to account for the holidays. Only current JDK 8 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]. Paul Hohensee [0] http://openjdk.java.net/census#simonis [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simonis)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis at gmail.com%22))+and+not+merge() [2] http://openjdk.java.net/census#jdk8u [3] http://openjdk.java.net/projects/#reviewer-vote From martin.doerr at sap.com Fri Dec 20 21:56:06 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 20 Dec 2019 21:56:06 +0000 Subject: New JDK 8 Updates Reviewer: Volker Simonis In-Reply-To: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> References: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> Message-ID: <AM0PR0202MB32977BF92B4C1A6B2F689C0F9A2D0@AM0PR0202MB3297.eurprd02.prod.outlook.com> Vote: yes Best regards, Martin > -----Original Message----- > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of > Hohensee, Paul > Sent: Freitag, 20. Dezember 2019 20:36 > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net> > Subject: CFV: New JDK 8 Updates Reviewer: Volker > Simonis > > I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project > Reviewer. > > Volker was one of the authors of the PPC port, is Member of the build, > hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on > the jdk and jdk updates projects, a Committer on the jdk 8 updates project > [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing > more jdk8u reviews lately, and it would expedite things for him to have > Reviewer status. > > Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the > voting period by 4 days to a total of 18 to account for the holidays. > > Only current JDK 8 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]. > > Paul Hohensee > > [0] http://openjdk.java.net/census#simonis > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simoni > s)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis@ > gmail.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#reviewer-vote > From akozlov at azul.com Fri Dec 20 23:41:13 2019 From: akozlov at azul.com (Anton Kozlov) Date: Sat, 21 Dec 2019 02:41:13 +0300 Subject: [8u] RFR: JDK-8171974: Fix for R10 Register clobbering with usage of ExternalAddress Message-ID: <471a8d9c-1806-da89-63ba-75e47761a99a@azul.com> Hi, Please review backport of JDK-8171974: Fix for R10 Register clobbering with usage of ExternalAddress http://cr.openjdk.java.net/~akozlov/8171974/ Changes are: * resolve conflits, manually apply changes in macroAssembler_x86.[ch]pp * omit changes to macroAssembler_x86_sha.cpp Thanks, Anton From ebaron at redhat.com Fri Dec 20 23:41:50 2019 From: ebaron at redhat.com (Elliott Baron) Date: Fri, 20 Dec 2019 18:41:50 -0500 Subject: [8u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: <527d6e01-9176-c46f-39a1-29ced7869e4d@azul.com> References: <527d6e01-9176-c46f-39a1-29ced7869e4d@azul.com> Message-ID: <b8841983-a8bf-9d86-0c81-3ff528e966b9@redhat.com> Hi Fedor, On 2019-12-10 1:35 p.m., Fedor wrote: > Hello everybody, > > May I have a request backport of JDK-8231507? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231507 > webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/ > testing:? jdk/test/com/sun/org/apache/xml/ jdk/test/javax/xml/crypto/dsig/ > > The code of library taken from jdk14 sources wasn't applied cleanly to > jdk8u, so a sort of changes were done: > > The changes made after copying files from jdk14: > http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.html > (raw diff: > http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.diff) > > > Several files were deleted. > The rest was taken "as is" from jdk14. > This changeset appears to include parts of several dependent changes along with it. I recognize "8177334: Update xmldsig implementation to Apache Santuario 2.1.1" and some of its dependencies, since I've been working on a backport for this. If it's not possible to propose each of these additional changes for review individually, would you be able to list these dependencies that you have included in this changeset? It would also be helpful if you could provide an explanation for any modifications you had to make to these fixes to arrive at your 8u backport. (Note: I'm not an 8u reviewer, just interested in getting this backported as well) Thanks, Elliott From sreerama.naga at gmail.com Sat Dec 21 02:13:04 2019 From: sreerama.naga at gmail.com (brahmam) Date: Sat, 21 Dec 2019 07:43:04 +0530 Subject: Any openjdk tool available to create tzdb.dat In-Reply-To: <CA+kOe08yxNqRNzP-f-1z+_BzeqAta8hh-YenEiBOak=NXn-YkQ@mail.gmail.com> References: <CAFVT4hZR7CHVm_=-HK8tgdSMZ4ZKWu+UqObzQk54nyOTuL4koA@mail.gmail.com> <CA+kOe08NFJD4+BucLXO-H_oU4Pi2V8Drh52RDCnbANrtVBNYvg@mail.gmail.com> <CAFVT4haEc4Le+sSfyrc8vH51xQg6a2qxJ=RVhh1j0WfGOL1bqA@mail.gmail.com> <CA+kOe08yxNqRNzP-f-1z+_BzeqAta8hh-YenEiBOak=NXn-YkQ@mail.gmail.com> Message-ID: <CAFVT4hYJJ+iRx-b0-8i8AeEuu3TcZ5DVqcxqkiwmmd_vR6PC-w@mail.gmail.com> Thank you Martin.. On Fri, 20 Dec 2019, 21:38 Martin Buchholz, <martinrb at google.com> wrote: > make/data/tzdata contains tzdata source files, e.g. > > make/data/tzdata/africa > > Just replace all of those source files and rebuild. > > (but yes, tzupdater should be open-sourced) > > On Fri, Dec 20, 2019 at 8:03 AM brahmam <sreerama.naga at gmail.com> wrote: > >> Hi Martin, >> >> Thank you for your response. >> >> Could you please guide me how I can use the jdk build to generate >> tzdb.dat? >> >> Regards, >> Sreeram >> >> On Fri, 20 Dec 2019, 21:14 Martin Buchholz, <martinrb at google.com> wrote: >> >>> A jdk image includes a tzdb.dat, so the openjdk build process must know >>> how to generate this file. >>> You could dig into the makefiles to extract the details, or you could >>> use the jdk build itself as a black box to generate tzdb.dat (we do that). >>> >>> On Fri, Dec 20, 2019 at 7:09 AM brahmam <sreerama.naga at gmail.com> wrote: >>> >>>> Hi Group, >>>> >>>> Is any tool available from openjdk to create tzdb.dat file from time >>>> zone >>>> database(ex:tzdata2019c.tar.gz) ? Here looking for creating the tzdb.dat >>>> file and use in the jdk, without using any tzupdater tools. >>>> >>>> Thanks in advance! >>>> >>>> Regards, >>>> Sreeram >>>> >>> From mbalao at redhat.com Sat Dec 21 02:58:57 2019 From: mbalao at redhat.com (Martin Balao) Date: Fri, 20 Dec 2019 23:58:57 -0300 Subject: [8u] RFR 8215032: Support Kerberos cross-realm referrals (RFC 6806) In-Reply-To: <6E33BD80-951A-45FE-BAE4-51A3483131FA@oracle.com> References: <e93ccd62-7d5d-ab09-b6e9-5651946f3368@redhat.com> <6E33BD80-951A-45FE-BAE4-51A3483131FA@oracle.com> Message-ID: <82661fb2-f53b-e02c-d39c-50f4cbe0c132@redhat.com> Hi Max, On 12/13/19 11:30 PM, Weijun Wang wrote: > I thought you wanted to make the new constant in KerberosPrincipal non public. > Thanks for the reminder. We will need to backport "8233944: Make KerberosPrincipal.KRB_NT_ENTERPRISE field package private" [1] to 8u as well. Regards, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8233944 From mbalao at redhat.com Sat Dec 21 05:41:35 2019 From: mbalao at redhat.com (Martin Balao) Date: Sat, 21 Dec 2019 02:41:35 -0300 Subject: [8u] RFR 8201627: Kerberos sequence number issues In-Reply-To: <f4a33c2b-baca-b18b-c0db-319648af7889@redhat.com> References: <b910c68d-003a-3d38-4a82-a7ec7e2540c1@redhat.com> <f4a33c2b-baca-b18b-c0db-319648af7889@redhat.com> Message-ID: <f7e64f21-8d13-d551-574c-75750840b83d@redhat.com> Hello Andrew, Thanks for having a look. On 12/16/19 3:14 PM, Andrew John Hughes wrote: > > I think there's a case here for backporting JDK-8154231 or at least > bringing over the remaining two methods for GetPropertyAction that > weren't part of JDK-8181048. > What finally introduces a default value argument for privilegedGetProperty seems to be 8155775 [1] [2], that depends on 8154231 [3] [4]. If you are okay with the approach taken for 8181048 (cherry picking from 8155775 and 8154231 and including them as part of 8181048), I can propose to have privilegedGetProperty with a default value argument and privilegedGetProperties as part of the 8u backport of 8201627. privilegedGetProperties is not used by 8201627 though. >> >> * test/sun/security/krb5/auto/BasicProc.java (several adjustments) > > What are these "several adjustments"? It looks to me like the > refactoring in JDK-8186884 needs backporting first, as this patch seems > to drag in some of those changes as well. > 8186884 is far from applying cleanly to 8u. I've not analyzed all the dependencies, but have seen many hook failures. In Basic.java, what happens is that jtreg run header has the old way of specifying a custom NameService to resolve domains: -Dsun.net.spi.nameservice.provider.1=ns,mock instead of -Djdk.net.hosts.file=TestHosts. I duplicated the run jtreg header to add -Dsun.security.krb5.acceptor.sequence.number.nonmutual=zero parameter. The @bug jtreg header hook does not apply cleanly because 8194486 is not in 8u. In BasicProc.java, the jtreg header hook does not apply cleanly because of some patches missing in 8u: 8186884 and 8194486. The other changes -probably because of the lack of 8186884 in 8u- are intended to keep the semantics. For example, for "client" I added a request to have mutual authentication, removed the "Token" variable, sent the wrapped message and the message integrity code (MIC). I can continue describing all the changes but would be easier to compare file vs file. If it helps, no regressions were introduced to the sun/security/krb5 test category (116 / 116 passes). My concern is that all 8155775, 8154231, 8186884 and possible 8186884-dependencies are quite big patches not critical for Jan 2020 CPU. 8201627 is critical though. I've tagged 8201627 with jdk8u-critical-request label. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8155775 [2] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/930d3aef37ee#l51.32 [3] - https://bugs.openjdk.java.net/browse/JDK-8154231 [4] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/50d4d6b772d1#l51.1 From mbalao at redhat.com Sat Dec 21 05:58:33 2019 From: mbalao at redhat.com (Martin Balao) Date: Sat, 21 Dec 2019 02:58:33 -0300 Subject: [8u] RFR: 8232019: Add LuxTrust certificate updates to the existing root program In-Reply-To: <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> References: <c9ba17b20a628bf8aca81fa65fc04575f4ecaa3d.camel@redhat.com> <84cf7325-dd23-33c3-2894-4f36d28253c6@redhat.com> <7c45d25459425dd76f5db8fa028ec3da1bc82d14.camel@redhat.com> Message-ID: <916b791a-e269-7f02-a584-17139c9c735d@redhat.com> On 12/19/19 5:13 PM, Severin Gehwolf wrote: > Note that the backports as-is have been > reviewed by Christoph Langer, Volker Simonis and internally by Martin > Balao. > Right. I've reviewed this patch internally and looked good to me. I'm not a 8u reviewer though. From volker.simonis at gmail.com Sat Dec 21 15:06:46 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 21 Dec 2019 16:06:46 +0100 Subject: [8u] RFR: 8233223: Add Amazon Root CA certificates In-Reply-To: <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com> References: <a202effdf64894e81ea44cdabdb46335f9872274.camel@redhat.com> <CA+3eh12RpEdOkkHRQRzdQEdFOxvHztbi1pNw3gnuvNQWf1HOJg@mail.gmail.com> <45d8287c19bc71e8438deac2a38deecee2670444.camel@redhat.com> Message-ID: <CA+3eh13Un9oAWn_Wh7PBizGnDm4-5V3w0xfntfpUDo-FipWULw@mail.gmail.com> On Thu, Dec 19, 2019 at 11:09 AM Severin Gehwolf <sgehwolf at redhat.com> wrote: > > Hi Volker, > > On Wed, 2019-12-18 at 22:27 +0100, Volker Simonis wrote: > > Hi Severin, > > > > not strictly a 8u "Reviewer" yet, but I've looked at your changes > > (this one and 8232019) nevertheless :) > > Thanks for the review! > > > They both look good, except that I can not verify the new "cacert" > > file because it is not in the patch (because it is binary). Not sure > > if it is necessary to upload the whole file to cr.openjdk.java.net as > > well? If you say that sun/security/lib/cacerts/VerifyCACerts.java and > > security/infra/java/security/cert/CertPathValidator/certification both > > pass, then everything seems to be fine. > > FWIW the raw download of the webrev's cacerts file should have the > binary blob: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts > Yes, you're right. Didn't thought about that. I've now downloaded it and can confirm that, as you wrote, all the relevant tests except ActalisCA.java pass. So, still thumbs up from me :) Regards, Volker > And for 8232019: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8232019/jdk8/01/webrev/raw_files/new/src/share/lib/security/cacerts > > Thanks, > Severin > > > So thumbs up from me (for both, this one and 8232019). > > > > Best regards, > > Volker > > > > On Tue, Dec 17, 2019 at 8:39 PM Severin Gehwolf <sgehwolf at redhat.com> wrote: > > > Hi, > > > > > > Could I please get a review of this OpenJDK 8u backport of 8233223 > > > which depends on 8u backport of 8232019[1]. The JDK 11u patch did not > > > apply cleanly for a couple of reasons: > > > > > > 1. 8u still has the binary blob for cacerts (JDK-8193255 > > > not backported, yet). Instead, I've updated to the revision in > > > jdk11u, performed a build and copied the cacerts binary to 8u. > > > 2. JDK-8225392 not present in 8u, which added the checksum to > > > VerifyCACerts.java. Thus, the 8u backport does not include > > > this hunk. > > > 3. JDK-8234245 not present in 8u. > > > 4. Due to 2) and 3) above @bug annotation modified manually for these > > > reasons. > > > > > > Everything else is the same. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233223 > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233223/jdk8/01/webrev/ > > > > > > Testing: sun/security/lib/cacerts/VerifyCACerts.java and > > > security/infra/java/security/cert/CertPathValidator/certification > > > Pass, except for ActalisCA.java which is problem-listed and still > > > broken in HEAD (JDK-8224768) > > > > > > Thoughts? > > > > > > Once reviewed, I'll try to get this into 8u242 via the critical fix > > > request label workflow. > > > > > > Thanks, > > > Severin > > > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-December/010813.html > > > > From christoph.langer at sap.com Sun Dec 22 09:55:03 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 22 Dec 2019 09:55:03 +0000 Subject: New JDK 8 Updates Reviewer: Volker Simonis In-Reply-To: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> References: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> Message-ID: <AM6PR02MB498429A6A3E2A43B3B1243848A2F0@AM6PR02MB4984.eurprd02.prod.outlook.com> Vote: yes /Christoph > -----Original Message----- > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of > Hohensee, Paul > Sent: Freitag, 20. Dezember 2019 20:36 > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net> > Subject: [DMARC FAILURE] CFV: New JDK 8 Updates Reviewer: Volker > Simonis > > I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project > Reviewer. > > Volker was one of the authors of the PPC port, is Member of the build, > hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on > the jdk and jdk updates projects, a Committer on the jdk 8 updates project > [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing > more jdk8u reviews lately, and it would expedite things for him to have > Reviewer status. > > Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the > voting period by 4 days to a total of 18 to account for the holidays. > > Only current JDK 8 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]. > > Paul Hohensee > > [0] http://openjdk.java.net/census#simonis > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simoni > s)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis@ > gmail.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#reviewer-vote > From aph at redhat.com Sun Dec 22 12:22:45 2019 From: aph at redhat.com (Andrew Haley) Date: Sun, 22 Dec 2019 13:22:45 +0100 Subject: New JDK 8 Updates Reviewer: Volker Simonis In-Reply-To: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> References: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> Message-ID: <70c6991d-683e-70a0-dcb4-e6721bfb2d49@redhat.com> Vote: yes > -----Original Message----- > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of > Hohensee, Paul > Sent: Freitag, 20. Dezember 2019 20:36 > To: 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net> > Subject: CFV: New JDK 8 Updates Reviewer: Volker > Simonis > > I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project > Reviewer. > > Volker was one of the authors of the PPC port, is Member of the build, > hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on > the jdk and jdk updates projects, a Committer on the jdk 8 updates project > [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing > more jdk8u reviews lately, and it would expedite things for him to have > Reviewer status. > > Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the > voting period by 4 days to a total of 18 to account for the holidays. > > Only current JDK 8 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]. > > Paul Hohensee > > [0] http://openjdk.java.net/census#simonis > [1] > https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simoni > s)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis@ > gmail.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#reviewer-vote > From yan at azul.com Mon Dec 23 06:41:46 2019 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 23 Dec 2019 09:41:46 +0300 Subject: CFV: New JDK 8 Updates Reviewer: Volker Simonis In-Reply-To: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> References: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> Message-ID: <db877667-1a1c-46b1-a04e-d386d7211e3c@azul.com> Vote: yes --yan On 20.12.2019 22:35, Hohensee, Paul wrote: > I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project Reviewer. > > Volker was one of the authors of the PPC port, is Member of the build, hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on the jdk and jdk updates projects, a Committer on the jdk 8 updates project [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing more jdk8u reviews lately, and it would expedite things for him to have Reviewer status. > > Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the voting period by 4 days to a total of 18 to account for the holidays. > > Only current JDK 8 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]. > > Paul Hohensee > > [0] http://openjdk.java.net/census#simonis > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simonis)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis at gmail.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#reviewer-vote > > From mbalao at redhat.com Mon Dec 23 14:35:59 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 23 Dec 2019 11:35:59 -0300 Subject: [8u] RFR 8201627: Kerberos sequence number issues In-Reply-To: <f7e64f21-8d13-d551-574c-75750840b83d@redhat.com> References: <b910c68d-003a-3d38-4a82-a7ec7e2540c1@redhat.com> <f4a33c2b-baca-b18b-c0db-319648af7889@redhat.com> <f7e64f21-8d13-d551-574c-75750840b83d@redhat.com> Message-ID: <c4f6d1fb-fb39-37d0-0b5f-68768fac19ff@redhat.com> On 12/21/19 2:41 AM, Martin Balao wrote: > > On 12/16/19 3:14 PM, Andrew John Hughes wrote: >> >> I think there's a case here for backporting JDK-8154231 or at least >> bringing over the remaining two methods for GetPropertyAction that >> weren't part of JDK-8181048. >> > > What finally introduces a default value argument for > privilegedGetProperty seems to be 8155775 [1] [2], that depends on > 8154231 [3] [4]. If you are okay with the approach taken for 8181048 > (cherry picking from 8155775 and 8154231 and including them as part of > 8181048), I can propose to have privilegedGetProperty with a default > value argument and privilegedGetProperties as part of the 8u backport of > 8201627. privilegedGetProperties is not used by 8201627 though. > What I mean is something like this: http://cr.openjdk.java.net/~mbalao/webrevs/8201627/8201627.webrev.02.jdk8u.jdk/ From gnu.andrew at redhat.com Wed Dec 25 02:47:20 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 25 Dec 2019 02:47:20 +0000 Subject: [8u] 8236178: Debug build failed after 8225141 In-Reply-To: <251840ea0a6d356136d5c2cac71a86ae842d691a.camel@redhat.com> References: <C0CB03CA-3A3E-496A-9BEF-395D0555F419@azul.com> <251840ea0a6d356136d5c2cac71a86ae842d691a.camel@redhat.com> Message-ID: <5aa36290-b0b3-7930-1213-8623549526b4@redhat.com> On 18/12/2019 18:49, Severin Gehwolf wrote: > Hi, > > On Wed, 2019-12-18 at 14:54 +0000, Sergey Nazarkin wrote: >> Hi! >> >> I?ve created critical bug [1] since debug build is broken after one of latest changeset [2]. Please consider to include it into u242 >> >> diff -r 9ef81b9152f1 src/share/vm/oops/instanceKlass.cpp >> --- a/src/share/vm/oops/instanceKlass.cpp Fri Nov 13 18:14:41 2015 +0300 >> +++ b/src/share/vm/oops/instanceKlass.cpp Wed Dec 18 14:25:28 2019 +0300 >> @@ -3605,7 +3605,7 @@ >> bool good_state = is_shared() ? (_init_state <= state) >> : (_init_state < state); >> assert(good_state || state == allocated, "illegal state transition"); >> - set_initialization_state_and_notify_implassert(_init_thread == NULL, "should be cleared before state change"); >> + assert(_init_thread == NULL, "should be cleared before state change"); >> _init_state = (u1)state; >> } >> #endif > > This looks good to me. It's what the JDK 11u code[i] has as well. Not > sure why the backport for 8u was different. > > Thanks, > Severin > > [i] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/ae96767b40ff/src/hotspot/share/oops/instanceKlass.cpp#l3684 > >> >> Sergey Nazarkin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8236178 >> [2] https://bugs.openjdk.java.net/browse/JDK-8236058 >> > There is a set_initialization_state_and_notify_impl function in that file: void InstanceKlass::set_initialization_state_and_notify_impl(instanceKlassHandle this_oop, ClassState state, TRAPS) { oop init_lock = this_oop->init_lock(); if (init_lock != NULL) { ObjectLocker ol(init_lock, THREAD); this_oop->set_init_state(state); this_oop->fence_and_clear_init_lock(); ol.notify_all(CHECK); } else { assert(init_lock != NULL, "The initialization state should never be set twice"); this_oop->set_init_state(state); } } so maybe the intention was to call that before the assert, and the two somehow got munged together. It doesn't look like the right place for such a call though. Maybe Zhengyu can enlighten us. 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 fedor.burdun at azul.com Thu Dec 26 12:24:47 2019 From: fedor.burdun at azul.com (Fedor) Date: Thu, 26 Dec 2019 15:24:47 +0300 Subject: [8u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: <b8841983-a8bf-9d86-0c81-3ff528e966b9@redhat.com> References: <527d6e01-9176-c46f-39a1-29ced7869e4d@azul.com> <b8841983-a8bf-9d86-0c81-3ff528e966b9@redhat.com> Message-ID: <4cea8f6c-a3bb-3e29-8444-d529316fc7e1@azul.com> Hi Elliott, The library itself looked to me as solid thing, so I decided to downport it as one piece. Moreover, it seems it is easier and more clear than to do this work applying all patches that touched the library code. For example, as far as I remember there was a lot of changes, updating javadoc and fixing compilation warnings, and these changes were updating not only the library code but a big chunk of irrelevant to us Java classes in addition. Because of that, all of potentially relevant patches should be updated to not touch code outside the library (for example public api that may break jdk8u compliance) Being more specific, what was done during backport of the library I can describe in next steps: 1) copied library files from jdk11/14 to jdk8 to appropriate packages: - src/share/classes/org/jcp/xml/dsig/internal - src/share/classes/com/sun/org/apache/xml/internal 2) removed files that was removed due to update to 2.1.4 in jdk11 3) fixed several compilation issues: - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java left untouched - updated Logger calls: Log.debug(...) => Log.log(logging.level.FINE,...) - updated imports where it was required - NodeSetData<?> => NodeSetData - toNodeSet method - PSSParameterSpec.TRAILER_FIELD_BC => PSSParameterSpec.DEFAULT.getTrailerField() 4) fixed tests: - removed usage of several crypto algorithms from GenerationTests.java since they are not provided in jdk8 If I didn't forget something that is all. All modifications done over jdk11u version (steps 3,4) can be found in this (http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.html) diff.h Thanks, Fedor On 21.12.2019 2:41, Elliott Baron wrote: > Hi Fedor, > > On 2019-12-10 1:35 p.m., Fedor wrote: >> Hello everybody, >> >> May I have a request backport of JDK-8231507? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231507 >> webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/ >> testing:? jdk/test/com/sun/org/apache/xml/ >> jdk/test/javax/xml/crypto/dsig/ >> >> The code of library taken from jdk14 sources wasn't applied cleanly to >> jdk8u, so a sort of changes were done: >> >> The changes made after copying files from jdk14: >> http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.html >> (raw diff: >> http://cr.openjdk.java.net/~fijiol/8231507/webrev.8u.00/compare/with-14.diff) >> >> >> Several files were deleted. >> The rest was taken "as is" from jdk14. >> > > This changeset appears to include parts of several dependent changes > along with it. I recognize "8177334: Update xmldsig implementation to > Apache Santuario 2.1.1" and some of its dependencies, since I've been > working on a backport for this. If it's not possible to propose each of > these additional changes for review individually, would you be able to > list these dependencies that you have included in this changeset? It > would also be helpful if you could provide an explanation for any > modifications you had to make to these fixes to arrive at your 8u backport. > > (Note: I'm not an 8u reviewer, just interested in getting this > backported as well) > > Thanks, > Elliott From dheeraj.madhu at gmail.com Thu Dec 19 14:12:51 2019 From: dheeraj.madhu at gmail.com (Dheeraj Joshi) Date: Thu, 19 Dec 2019 19:42:51 +0530 Subject: Open JDK 8 Road Map In-Reply-To: <DB8PR02MB55472D4EEB4F15F7DBD059CB8A520@DB8PR02MB5547.eurprd02.prod.outlook.com> References: <CAPrd8CjSd5CM9G4PVGQcE5hR5wm3dbJgUFb8JTJ4eypq1oPJOQ@mail.gmail.com> <DB8PR02MB55472D4EEB4F15F7DBD059CB8A520@DB8PR02MB5547.eurprd02.prod.outlook.com> Message-ID: <CAPrd8Ch4dgYwNirwNXifqkDtCGoSmMt8shTmZC2UaUqqsJjDaA@mail.gmail.com> Thanks for the reply. We are current upgrading to JDK 11. But lot of issues. Hopefully we will upgrade soon and don't have to worry about JDK 8 updates. On Thu, 19 Dec, 2019, 7:25 pm Langer, Christoph, <christoph.langer at sap.com> wrote: > Hi Joshi, > > the right list for this question is rather jdk8u-dev at o.j.n, so I'm > sending my response there and put jdk-updates-dev on bcc. > > Since RedHat is the maintainer of OpenJDK8 and OpenJDK11, I guess you can > bear with their statements about support. You can find this article: > https://access.redhat.com/articles/1299013 > > So I assume, as long as RedHat supports OpenJDK 8, you can be quite sure > that there will be periodic security updates. > > HTH > Christoph > > > > > -----Original Message----- > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On > > Behalf Of Dheeraj Joshi > > Sent: Dienstag, 20. August 2019 07:14 > > To: jdk-updates-dev at openjdk.java.net > > Subject: Open JDK 8 Road Map > > > > How long Open JDK 8 is supported by https://openjdk.java.net/ > > We are currently analyzing impact of upgrading from Java 8 to Java 11. We > > need to know for how long JDK 8 will get periodic security upgrades and > > general patches for JDK 8 from https://openjdk.java.net/? > > > > Is there a Road map available for public viewing? > > > > Kind Regards > > Dheeraj Joshi > From christoph.langer at sap.com Sat Dec 28 17:05:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 28 Dec 2019 17:05:08 +0000 Subject: RFR: 8233995: java.vm.vendor (and potentially other properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8 In-Reply-To: <AM6PR02MB48013C99B07ACFF47D74C82D8A760@AM6PR02MB4801.eurprd02.prod.outlook.com> References: <AM6PR02MB48014BBA1F11354453D3F5208A770@AM6PR02MB4801.eurprd02.prod.outlook.com> <82775c10-59ed-4471-0ab3-99e995c00e11@redhat.com> <AM6PR02MB48013C99B07ACFF47D74C82D8A760@AM6PR02MB4801.eurprd02.prod.outlook.com> Message-ID: <AM6PR02MB4984A70A3B80062CA63D19838A250@AM6PR02MB4984.eurprd02.prod.outlook.com> Hi Andrew, I've finally gotten back to this and spent some more cycles. Here is a new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8233995.8u.1/ I'm now passing COMPANY_NAME, VENDOR_URL, VENDOR_URL_BUG, VENDOR_URL_VM_BUG and VERSION_CFLAGS via MAKE_ARGS in make/windows/makefiles/defs.make. I needed to add some logic for converting VERSION_CFLAGS into a value that can be passed as argument to the nmake call and would then also be consumable by the VS C++ compiler. The elegant thing of doing it so is that I don't need to duplicate the logic for creating VERSION_CFLAGS from spec.gmk in make/windows/makefiles/vm.make. I also removed the common amendment of CXX_FLAGS with VENDOR defines in make/windows/makefiles/vm.make and I would pass VERSION_CFLAGS only to the compilation of vm_version.cpp and arguments.cpp as it is done on the other platforms. I furthermore fixed the value of VENDOR in generated file local.make (done in make/windows/build.make) and I also corrected the value of HS_COMPANY in the RC flags for creating jvm.dll in make/windows/makefiles/compile.make. Cheers Christoph > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 13. November 2019 23:40 > To: Andrew John Hughes <gnu.andrew at redhat.com>; jdk8u- > dev at openjdk.java.net > Subject: RE: RFR: 8233995: java.vm.vendor (and potentially other > properties/fields) not correctly set in Windows/Hotspot build of OpenJDK8 > > Hi Andrew, > > thanks for looking into my webrev. > > > Indeed, the build system did change in OpenJDK 9 with "JDK-8150601: > > Remove the old Hotspot build system". As JDK-8189761: COMPANY_NAME, > > IMPLEMENTOR, BUNDLE_VENDOR, VENDOR, but no configure flag" > occurred > > later than this, the HotSpot parts of the 8189761 had to be constructed > > from scratch when I backported it. Not having access to Windows myself, > > I'm reliant on others to test the changes there and report breakage. > > Ah, I didn't do that bug-archeology. Good to know. > > > Looking over this patch, and comparing with what we do for > > AIX/Solaris/BSD/Linux in 8189761, I have two questions: > > > > 1. We echo the values of VENDOR, VENDOR_URL, VENDOR_URL_BUG and > > VENDOR_URL_VM_BUG to local.make in build.make, in much the same > way > > as > > buildtree.make does for the other platforms. Any idea why that is not > > sufficient and these need to be also added to defs.make? If the > > build.make variables aren't being set, that has an impact for other > > variables too. I notice ZIPEXE is in both places, with no checks in the > > defs.make case: > > > > hotspot/make/windows/build.make: @ if "$(ZIPEXE)" NEQ "" echo > > ZIPEXE=$(ZIPEXE) >> $@ > > hotspot/make/windows/makefiles/defs.make:MAKE_ARGS += > > ZIPEXE=$(ZIPEXE) > > > > If possible, it would be better to fix the underlying issue rather than > > papering over it. > > Well, for Unix-ish builds, "make buildtree.make ..." gets called (e.g. from > hotspot/make/linux/Makefile) and buildtree.mak includes spec.gmk and > hence has access to all values. > For Windows, however, we hand over to nmake. "nmake build.make ..." gets > called from hotspot/make/Makefile and build.make does not include > spec.gmk - it probably can't since nmake/gnumake have different syntax. > Hence, the only way to pass arguments to build.make is via MAKE_ARGS in > defs.make. > > I don't see an easy fix here... > > The handling of ZIPEXE seems correct, too. > > > 2. The checks added in vm.make are done by configure for the other > > builds and assembled into VERSION_CFLAGS. To avoid duplication in > > vm.make, is it possible to just use VERSION_CFLAGS there as the other > > systems do? If Windows can't handle the -D syntax that uses, maybe a > > better solution is to setup VERSION_WINFLAGS in the same place with the > > correct syntax? > > Hm, maybe we can try to pass VERSION_CFLAGS via MAKE_ARGS and use it > in vm.make. I'll give it a try. Stay tuned... > > Best regards > Christoph From gnu.andrew at redhat.com Mon Dec 30 04:00:34 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 30 Dec 2019 04:00:34 +0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <A1CC3280-56E7-401E-9291-E6482E1E7573@amazon.com> References: <ebf393a3577d4e89a15ce2cfb2792f66@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <FC2006E2-3CCD-42B1-AB0E-5B8205B8E352@amazon.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <dc6cfa1e6cbc40acb974174a32d94299@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <a3560fa94ef54884ade4393f3384f873@azul.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <BD4DB915-EA83-4D75-A6E6-43045EEF9373@amazon.com> <D79CBEAE-6E45-42F5-B7ED-8B87C35B7AD7@azul.com> <EBFA549F-E8F3-4B49-AAC4-654352302783@azul.com> <EF51DA0D-AB32-45F6-A72B-6C13EA093D19@amazon.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> <be40512fd96a47a588815eb3287cdac2@azul.com> <b5e68e07-5aff-78bb-0cdc-113322653114@azul.com> <835E4FA2-2080-4E64-80B4-BAAC8C8BF315@amazon.com> <213AC6B7-439C-4000-A736-E7CC71BBC1EA@amazon.com> <A1CC3280-56E7-401E-9291-E6482E1E7573@amazon.com> Message-ID: <1ef26053-69ca-23f0-72c3-255bc6be99b6@redhat.com> On 29/12/2019 19:35, Liu, Xin wrote: > Hi, Maintainers, > > I put answers inline. > > Please provide the following info for this work: > 1. Prepare patches for all affected repositories. List the repositories > affected. Send a link to patches which apply to current jdk8u-dev > HEAD. > we will touch two repos. > a) jdk8u-dev repo: > 1. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > b) jdk8u-dev/hotspot > 1. base https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz > 2. updateAPIs https://cr.openjdk.java.net/~xliu/8231089/updateAPIs.patch > 3. classFileInstaller https://cr.openjdk.java.net/~xliu/8231089/classFileInstaller/webrev/ > 4. gclog https://cr.openjdk.java.net/~xliu/8231089/gclog/webrev/ > 5. nativeLibraries https://cr.openjdk.java.net/~xliu/8231089/nativeLibraries/webrev/ > 6. azul_contrib1 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib.patch > 7. azul_contrib2 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2.patch > 8. new_targets https://cr.openjdk.java.net/~xliu/8231089/new_targets/01/webrev/ > Where does all this originate from? JDK-8231089 seems to be a freshly created bug rather than an issue resolved in later JDK versions being backported. > 2. Tell us on which platforms and architectures you've built/run those > tests. > I ran on linux_x86-64 and linux_aarch64. > > 3. Send a diff stat of the patches. This is to ensure only test > directories are being touched. > Please refer to the attachment vmTestbase.status.zip. it enlists all changed files. > I understand your concern. That's our intention too. I prefer to keep the file layout intact. It's because it would be easier to update vmTestbase in the future. > > 4. Provide instructions as to how these tests can be run. > Please refer to the script attached. Two functions are provided. > apply_vmTestbase apply patches. > run_vmTestbase kicks off vmTestbase test. > > 5. The patch should eventually get pushed under a single bug, JDK- > 8231089. That means adding vmTestbase code should be a single big > commit when pushed. So please squash any changes you may have. > Sure. I will do that. The reason I'd like to keep mq format now because it's easy to modify commits. > > 6. The commit message should perhaps also mention "JDK-8199257: > [TESTBUG] Open source VM testbase metaspace tests" as it also > includes those? An eventual push would then list a backport of this > bug. > Yes, it includes. I copy vmTestbase blob from jdk-14+14. I also double-check the log. It includes those metaspace changes. > > For test stats, so far, it passed 3480 tests and I put 82 tests in a ProblemList(https://cr.openjdk.java.net/~xliu/8231089/new_targets/01/webrev/test/ProblemList-vmTestbase.txt.html) > Why is JDK-8199257 not the patch being backported here? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Dec 30 04:16:35 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 30 Dec 2019 04:16:35 +0000 Subject: [8u] RFR: backport of 8231507: Update Apache Santuario (XML Signature) to version 2.1.4 In-Reply-To: <4cea8f6c-a3bb-3e29-8444-d529316fc7e1@azul.com> References: <527d6e01-9176-c46f-39a1-29ced7869e4d@azul.com> <b8841983-a8bf-9d86-0c81-3ff528e966b9@redhat.com> <4cea8f6c-a3bb-3e29-8444-d529316fc7e1@azul.com> Message-ID: <9f546a63-c60a-dd19-49c3-42cad5f28923@redhat.com> On 26/12/2019 12:24, Fedor wrote: > Hi Elliott, > > The library itself looked to me as solid thing, so I decided to downport > it as one piece. > Moreover, it seems it is easier and more clear than to do this work > applying all patches that touched the library code. > For example, as far as I remember there was a lot of changes, updating > javadoc and fixing compilation warnings, and these changes were updating > not only the library code but a big chunk of irrelevant to us Java > classes in addition. > Because of that, all of potentially relevant patches should be updated > to not touch code outside the library (for example public api that may > break jdk8u compliance) > > Being more specific, what was done during backport of the library I can > describe in next steps: > 1) copied library files from jdk11/14 to jdk8 to appropriate packages: > ?- src/share/classes/org/jcp/xml/dsig/internal > ?- src/share/classes/com/sun/org/apache/xml/internal A backport of an issue, x, should be completed by applying the changeset for that issue in later OpenJDK versions to 8u. That may require other changes and the decision to backport them or workaround this has to be made on a case by case basis. Copying over files like this results in numerous changes from a variety of bugs being brought over, which, in some cases, may be partial because they touch files outside the subset being copied. The only case I believe warrants that kind of action is in backporting work developed outside the main OpenJDK trees (e.g. the PPC or AArch64 ports) where the majority of changes don't have associated bug IDs and are significantly different between JDK versions. Even then, it is preferable to move to a bug-by-bug basis as soon as possible. Taking the quick option initially ends up creating more work and headaches for others later on, when they then have to try and deal with sourcing changes and the inevitable partial backports. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Dec 30 05:02:09 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 30 Dec 2019 05:02:09 +0000 Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> References: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> Message-ID: <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> On 06/11/2019 18:39, Martin Balao wrote: > Hi, > > I'd like to propose the 8u backport of 8165996 [1]. This have been > proposed long time ago but I've now rebased the work and bumped the > webrev version to 02. > > Webrev.02: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.02/ > > Differences with JDK baseline patch [2]: > > * TestNssDbSqlite.java > * @modules jtreg header removed > * Added a check to avoid errors when initialization fails (proposed by > @coffeys) I don't see this in the main OpenJDK repository. It should be added there first, not proposed in a backport. > * Removed white space in "initializeProvider" method signature > > * PKCS11Test.java > * Change does not apply to 8u: no "distro" function in PKCS11Test > * This was apparently introduced by 8133318 to solve issues in > Solaris SPARC 11.1 and earlier > I don't think this should simply be dropped on the floor. I backported both this bug & JDK-8133318 myself some time ago [0] [1] [2] so I'll look at bringing the pre-requisites upstream so this can be backported fully. > Testing: > > * No regression found in sun/security/pkcs11 > > Note: a followup fix (8195607) will be proposed after this one. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8165996 > [2] - http://hg.openjdk.java.net/jdk/jdk/rev/55b9b1e184c6 > [0] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3337 [1] https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3506 [2] https://icedtea.classpath.org//hg/icedtea8-forest/jdk?cmd=changeset;node=252ab42bb0dd Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Dec 30 05:16:15 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 30 Dec 2019 05:16:15 +0000 Subject: OpenJDK 8u242 b01 to b05 EA Released Message-ID: <f96767b4-5225-bae5-f92e-087b27677538@redhat.com> I've made available early access source bundles for 8u242, based on the tags jdk8u242-b01, jdk8u242-b02, jdk8u242-b04, jdk8u242-b05. I've omitted jdk8u242-b03 as this ended up unintentionally empty. * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b01-ea.tar.xz * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b02-ea.tar.xz * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b04-ea.tar.xz * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b05-ea.tar.xz The tarballs are accompanied by digital signatures available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b01-ea.tar.xz.sig * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b02-ea.tar.xz.sig * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b04-ea.tar.xz.sig * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b05-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: db06056018d8c765bb49b96944a141925fc31f89dc8728ad20a44449f8d45aab openjdk8u242-b01-ea.tar.xz 2f650e0330afd566617832ab0e4393b96b11a98a8316542fd69f565af37d96dc openjdk8u242-b01-ea.tar.xz.sig 542751eafa7416c9f272fcab9476fca40fe533691273cb44dc6d28a028f0f09b openjdk8u242-b02-ea.tar.xz c9d5d9617a0a81176556c8700426c4a9f10c5a9c82dcc3a6d86a43ea6d16c63f openjdk8u242-b02-ea.tar.xz.sig dacb0b9d6c72144310084c1d0e80154935f3e67dc776b50ce100eb129be2e6e8 openjdk8u242-b04-ea.tar.xz 02b1028f74b28bb5113b84c93750ab0634d6b5d70b2981ab991625666d73c0ac openjdk8u242-b04-ea.tar.xz.sig 8fdadc102e9348e14d3cd594eb3036a15c9a403792f2e505878a131a781f60ba openjdk8u242-b05-ea.tar.xz 979e706f51112cb7f9746591fbeee7c051cb90f2d0f6cd8d2470041b6ccc82eb openjdk8u242-b05-ea.tar.xz.sig They are listed at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b01-ea.sha256 * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b02-ea.sha256 * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b04-ea.sha256 * https://openjdk-sources.osci.io/openjdk8/openjdk8u242-b05-ea.sha256 Changes in 8u242-b01: - S8010500: [parfait] Possible null pointer dereference at hotspot/src/share/vm/opto/loopnode.hpp - S8067429: java.lang.VerifyError: Inconsistent stackmap frames at branch target - S8073154: NULL-pointer dereferencing in LIR_OpProfileType::print_instr - S8077707: jdk9 b58 cannot run any graphical application on Win 8 with JAWS running - S8132249: Clean up JAB debugging code - S8133951: Zero interpreter asserts in stubRoutines.cpp - S8134739: compiler/loopopts/superword/TestVectorizationWithInvariant crashes in loop opts - S8212071: Need to set the FreeType LCD Filter to reduce fringing. - S8230238: Add another regression test for JDK-8134739 - S8230813: Add JDK-8010500 to compiler/loopopts/superword/TestFuzzPreLoop.java bug list - S8231398: Add time tracing for gc log rotation at safepoint cleanup - S8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Changes in 8u242-b02: - S8057986: freetype code to get glyph outline does not handle initial control point properly - S8068736: Avoid synchronization on Executable/Field.declaredAnnotations - S8073347: javadoc of Formattable messed up by JDK-8019857 - S8206173: MallocSiteTable::initialize() doesn't take function descriptors into account - S8213568: Typo in java/awt/GraphicsEnvironment/LoadLock/GE_init5.java - S8218558: NMT stack traces in output should show mt component for virtual memory allocations - S8225101: Crash at sun.awt.X11.XlibWrapper.XkbGetUpdatedMap when change keybord map - S8228888: C2 compilation fails with assert "m has strange control" - S8229020: Failure on CPUs allowing loads reordering: assert(_tasks[t] == 1) failed: What else? - S8229169: False failure of GenericTaskQueue::pop_local on architectures with weak memory model - S8230363: C2: Let ConnectionGraph::not_global_escape(Node* n) return false if n is not in the CG - S8231887: ComodoCA.java fails because certificate was revoked Changes in 8u242-b04: - S8048556: Unnecessary GCLocker-initiated young GCs - S8073108: Use x86 and SPARC CPU instructions for GHASH acceleration - S8130341: GHASH 32bit intrinsics has AEADBadTagException - S8139178: Wrong fontMetrics when printing in Landscape (OpenJDK) - S8146238: [macosx] Java2D Queue Flusher crash on OSX after switching between user accounts - S8196681: Java Access Bridge logging and debug flags dynamically controlled - S8204288: Matching the end of a string followed by an empty greedy regex and a word boundary fails - S8204290: Add check to limit number of capture groups - S8219914: Change the environment variable for Java Access Bridge logging to have a directory. - S8225505: ctrl-F1 does not show the tooltip of a menu item (JMenuItems) Changes in 8u242-b05: - S8029629: java/lang/ProcessBuilder/Basic.java fails intermittently - S8055351: sun/security/provider/DSA/TestAlgParameterGenerator.java failed with interrupted! (timed out?) - S8131778: java disables UseAES flag when using VIS=2 on sparc - S8133489: Better messaging for PKIX path validation matching - S8134424: BlockDataInputStream.readUTFBody: size local StringBuffer with the given length - S8156028: G1YoungGenSizer _adaptive_size not correct when setting NewSize and MaxNewSize to the same value - S8170641: sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails with timeout - S8173956: KeyStore regression due to default keystore being changed to PKCS12 - S8185898: setRequestProperty(key, null) results in HTTP header without colon in request - S8189762: [TESTBUG] Create tests for JDK-8146115 container awareness and resource configuration - S8194653: Deadlock involving FileSystems.getDefault and System.loadLibrary call - S8195088: [TEST_BUG] StartManagementAgent got unexpected exception - S8195667: ProblemList PKCS11 tests Secmod/AddTrustedCert.java and tls/TestKeyMaterial.java due to JDK-8180837 - S8198649: Switch AWT/Swing's default GTK version to 3 - S8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug - S8213119: [macos] java/awt/GraphicsDevice/CheckDisplayModes.java fails - S8215210: [macos] Hangul text does not shape to the precomposed form on JDK8u - S8216401: Allow "file:" URLs in Class-Path of local JARs - S8221172: SunEC specific test is not limited to SunEC - S8221246: NullPointerException within Win32ShellFolder2 - S8222496: [8u] Switch on GTK3 as a default GTK L&F in client-libs - S8223490: Optimize search algorithm for determining default time zone - S8225141: Better handling of classes in error state in fast class initialization checks - S8229420: [Redo] jstat reports incorrect values for OU for CMS GC - S8231124: Missing closedir call with JDK-8223490 - S8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call - S8232984: Upgrading Joni License version to 2.1.16 - S8233886: TEST_BUG jdk/java/net/CookieHandler/B6791927.java hit hardcoded expiration date - S8234591: [11u] Build with old C compiler broken by 8223490 - S8236178: Debug build failed after 8236058 -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Mon Dec 30 05:20:22 2019 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Mon, 30 Dec 2019 05:20:22 +0000 Subject: 8u242 FREEZE Imminent; 1st of January, 2020 Message-ID: <03771404-e942-e95e-2198-e5d24e37fb13@redhat.com> The release of 8u242 is coming up on the 14th of January, 2020 [0]. To prepare for this, I plan to freeze 8u after the 1st of January, 2020, so that embargoed security changes can be applied on top and releases prepared in time for the unembargo on the 14th. A final tag, jdk8u242-b06, will be made at the time of the freeze. If you'd like a change to still be considered for 8u242, please mark it as jdk8u-critical-request ONCE REVIEWED (if necessary). [0] https://www.oracle.com/security-alerts/ 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 mbalao at redhat.com Mon Dec 30 13:52:34 2019 From: mbalao at redhat.com (Martin Balao) Date: Mon, 30 Dec 2019 10:52:34 -0300 Subject: [8u] RFR 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite In-Reply-To: <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> References: <2ea4f241-f47e-73df-741c-3889b9e2d87a@redhat.com> <9b04fc7b-752b-784a-ee98-0ec42c8351b2@redhat.com> Message-ID: <27be5aad-5ec6-6dce-c5ac-f7f2330770e0@redhat.com> On 12/30/19 2:02 AM, Andrew John Hughes wrote: > > > On 06/11/2019 18:39, Martin Balao wrote: >> Hi, >> >> I'd like to propose the 8u backport of 8165996 [1]. This have been >> proposed long time ago but I've now rebased the work and bumped the >> webrev version to 02. >> >> Webrev.02: >> >> * >> http://cr.openjdk.java.net/~mbalao/webrevs/8165996/8165996.jdk8u.jdk.webrev.02/ >> >> Differences with JDK baseline patch [2]: >> >> * TestNssDbSqlite.java >> * @modules jtreg header removed >> * Added a check to avoid errors when initialization fails (proposed by >> @coffeys) > > I don't see this in the main OpenJDK repository. It should be added > there first, not proposed in a backport. > I've now noticed that this has been fixed by JDK-8206258 [1] [2]. We should remove the 'sunPKCS11NSSProvider == null' check from Webrev.02 8u backport, and look at backporting JDK-8206258 after JDK-8165996. -- [1] - https://bugs.openjdk.java.net/browse/JDK-8206258 [2] - http://hg.openjdk.java.net/jdk/jdk11/rev/f095e3bc2d41 From adinn at redhat.com Tue Dec 31 11:44:46 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 Dec 2019 11:44:46 +0000 Subject: CFV: New JDK 8 Updates Reviewer: Volker Simonis In-Reply-To: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> References: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> Message-ID: <84f09c22-c4cd-25f1-7ff2-cd354970b70b@redhat.com> Vote: yes On 20/12/2019 19:35, Hohensee, Paul wrote: > I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project Reviewer. > > Volker was one of the authors of the PPC port, is Member of the build, hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on the jdk and jdk updates projects, a Committer on the jdk 8 updates project [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing more jdk8u reviews lately, and it would expedite things for him to have Reviewer status. > > Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the voting period by 4 days to a total of 18 to account for the holidays. > > Only current JDK 8 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]. > > Paul Hohensee > > [0] http://openjdk.java.net/census#simonis > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simonis)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis at gmail.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#reviewer-vote > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From neugens.limasoftware at gmail.com Tue Dec 31 15:43:46 2019 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Tue, 31 Dec 2019 16:43:46 +0100 Subject: CFV: New JDK 8 Updates Reviewer: Volker Simonis In-Reply-To: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> References: <EF73A21F-B437-4F2B-85BF-F05D3643B51A@amazon.com> Message-ID: <CAGUMyaTAKSf0EuF2oHgSPHxMMOvV9WMcQC-TzvrdWFk9J_Pm=g@mail.gmail.com> Vote: Yes, Cheers, Mario Il giorno ven 20 dic 2019 alle ore 20:38 Hohensee, Paul <hohensee at amazon.com> ha scritto: > > I hereby nominate Volker Simonis (simonis) to be a JDK 8 Updates Project Reviewer. > > Volker was one of the authors of the PPC port, is Member of the build, hotspot, openjdk members, porters, and vulnerability groups, a Reviewer on the jdk and jdk updates projects, a Committer on the jdk 8 updates project [0], and has contributed 198 changesets [1] to openjdk since 2008. He?s doing more jdk8u reviews lately, and it would expedite things for him to have Reviewer status. > > Votes are due by 7 January 2020, 18:00 U.S. Pacific time. I?ve extended the voting period by 4 days to a total of 18 to account for the holidays. > > Only current JDK 8 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]. > > Paul Hohensee > > [0] http://openjdk.java.net/census#simonis > [1] https://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(simonis)+or+desc(%22volker.simonis at sap.com%22)+or+desc(%22volker.simonis at gmail.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#reviewer-vote > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From xxinliu at amazon.com Sun Dec 29 19:36:12 2019 From: xxinliu at amazon.com (Liu, Xin) Date: Sun, 29 Dec 2019 19:36:12 -0000 Subject: Backport vmTestbase tests to jdk8u-dev? In-Reply-To: <213AC6B7-439C-4000-A736-E7CC71BBC1EA@amazon.com> References: <ebf393a3577d4e89a15ce2cfb2792f66@azul.com> <9ba7e7af9a1645c4831610327c96f22b@azul.com> <51653b0b3223448bbe2f9186d11556af@azul.com> <1568829532868.82475@amazon.com> <0CFA2C19-FD39-4DDF-99E8-FB5B43936AFE@azul.com> <48213D1C-7CE4-41E9-B799-1E8A199846A0@amazon.com> <104bc421591046c8a4e7c2edcb962d81@azul.com> <FC2006E2-3CCD-42B1-AB0E-5B8205B8E352@amazon.com> <1569222717555.22304@amazon.com> <58139b1e7a454e8ca48d4046001cf7b5@azul.com> <dc6cfa1e6cbc40acb974174a32d94299@azul.com> <7478c13cb1ca4d1293fc8ab5b300ff04@azul.com> <5C06C673-6E83-4049-99E5-FD268F08B7C7@amazon.com> <a3560fa94ef54884ade4393f3384f873@azul.com> <9967a21b81f740f68272d4dbbe3390b5@azul.com> <BD4DB915-EA83-4D75-A6E6-43045EEF9373@amazon.com> <D79CBEAE-6E45-42F5-B7ED-8B87C35B7AD7@azul.com> <EBFA549F-E8F3-4B49-AAC4-654352302783@azul.com> <EF51DA0D-AB32-45F6-A72B-6C13EA093D19@amazon.com> <8CF2F830-82A3-4D17-96F2-B1910A0588F1@amazon.com> <be40512fd96a47a588815eb3287cdac2@azul.com> <b5e68e07-5aff-78bb-0cdc-113322653114@azul.com> <835E4FA2-2080-4E64-80B4-BAAC8C8BF315@amazon.com> <213AC6B7-439C-4000-A736-E7CC71BBC1EA@amazon.com> Message-ID: <A1CC3280-56E7-401E-9291-E6482E1E7573@amazon.com> Hi, Maintainers, I put answers inline. Please provide the following info for this work: 1. Prepare patches for all affected repositories. List the repositories affected. Send a link to patches which apply to current jdk8u-dev HEAD. we will touch two repos. a) jdk8u-dev repo: 1. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ b) jdk8u-dev/hotspot 1. base https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz 2. updateAPIs https://cr.openjdk.java.net/~xliu/8231089/updateAPIs.patch 3. classFileInstaller https://cr.openjdk.java.net/~xliu/8231089/classFileInstaller/webrev/ 4. gclog https://cr.openjdk.java.net/~xliu/8231089/gclog/webrev/ 5. nativeLibraries https://cr.openjdk.java.net/~xliu/8231089/nativeLibraries/webrev/ 6. azul_contrib1 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib.patch 7. azul_contrib2 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2.patch 8. new_targets https://cr.openjdk.java.net/~xliu/8231089/new_targets/01/webrev/ 2. Tell us on which platforms and architectures you've built/run those tests. I ran on linux_x86-64 and linux_aarch64. 3. Send a diff stat of the patches. This is to ensure only test directories are being touched. Please refer to the attachment vmTestbase.status.zip. it enlists all changed files. I understand your concern. That's our intention too. I prefer to keep the file layout intact. It's because it would be easier to update vmTestbase in the future. 4. Provide instructions as to how these tests can be run. Please refer to the script attached. Two functions are provided. apply_vmTestbase apply patches. run_vmTestbase kicks off vmTestbase test. 5. The patch should eventually get pushed under a single bug, JDK- 8231089. That means adding vmTestbase code should be a single big commit when pushed. So please squash any changes you may have. Sure. I will do that. The reason I'd like to keep mq format now because it's easy to modify commits. 6. The commit message should perhaps also mention "JDK-8199257: [TESTBUG] Open source VM testbase metaspace tests" as it also includes those? An eventual push would then list a backport of this bug. Yes, it includes. I copy vmTestbase blob from jdk-14+14. I also double-check the log. It includes those metaspace changes. For test stats, so far, it passed 3480 tests and I put 82 tests in a ProblemList(https://cr.openjdk.java.net/~xliu/8231089/new_targets/01/webrev/test/ProblemList-vmTestbase.txt.html) Here is Konstantin's report stats. I might have some slightly different patches from his. I will work with Konstantin to unify it. [quote] I'd like to provide some information about platforms and architectures I've built/run the tests. The following Platforms have been tested: Linux-x86_64 Linux-aarch64 (ARMv8) Linux-aarch32 (ARMv7) Linux-ppc32 (Power PC 32-bit) Linux-ppc64 (Power PC 64-bit) Total number of tests is 3,533. Maximum failures number was 21 (mostly JDI tests). [/quote] Thanks, --lx ?On 12/6/19, 10:57 AM, "jdk8u-dev on behalf of Liu, Xin" <jdk8u-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote: Hi, reviewers and maintainers, We have two repos to commit. For the root repo, there's only one webrev. it adds a target ''test-image", which will build native libraries for vmtestbase tests. https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ For hotspot repo, we have 8 patches. base is a special case. it's just copy from jdk14. it's too big to review. I have to treat it as blob. In order to make our change more reviewable, we split the commits into a sequence of commits using MQ. 1. base https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz 2. updateAPIs https://cr.openjdk.java.net/~xliu/8231089/updateAPIs.patch 3. classFileInstaller https://cr.openjdk.java.net/~xliu/8231089/classFileInstaller/webrev/ 4. gclog https://cr.openjdk.java.net/~xliu/8231089/gclog/webrev/ 5. nativeLibraries https://cr.openjdk.java.net/~xliu/8231089/nativeLibraries/webrev/ 6. azul_contrib1 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib.patch 7. azul_contrib2 https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2.patch 8. new_targets https://cr.openjdk.java.net/~xliu/8231089/new_targets/webrev/ Please note that some are missing webrevs on purpose. It will generate a very big webrev. I think patch files are still reviewable as an alternative. Could you take a look at them and see if it's okay to check in? The last one is optional. It introduces a ProblemList which we still can't pass on x86_64 and aarch64. #cd /src/hotspot/test #make JT_HOME=/opt/jtreg PRODUCT_HOME=/build/images/j2sdk-image/ ALT_OUTPUTDIR=/build EXTRA_JTREG_OPTIONS=-exclude:ProblemList-vmTestbase.txt vmtestbase My last question is whether I should squash them if we want to check them in. Thanks, --lx On 12/4/19, 8:14 AM, "jdk8u-dev on behalf of Hohensee, Paul" <jdk8u-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote: +1 from me as well. Thanks, Paul On 12/4/19, 4:29 AM, "jdk8u-dev on behalf of Yuri Nesterenko" <jdk8u-dev-bounces at openjdk.java.net on behalf of yan at azul.com> wrote: Hi, Liu Xin, Konstantin, as we already have and use it in Zulu, I only can say: great job. +1, list me as a reviewer. Thank you, --yan On 04.12.2019 14:54, Konstantin Shefov wrote: > Dear OpenJDK 8 Updates' maintainers! > > I am writing here to ask you to pay attention to this thread. > This is a backport of VmTestbase tests from JDK 14 to JDK 8u (https://bugs.openjdk.java.net/browse/JDK-8231089). > > Could you take a look and write your opinion? > > This patch is quite a big one (adds 15 000 files to hotspot repo), but all changes are in "test" part, not VM source. > The tests will be placed in a separate group in hotspot/test/TEST.groups file, so they will be run only when explicitly called. > > Thanks > Konstantin > > -----Original Message----- > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of Liu, Xin > Sent: Monday, October 14, 2019 9:55 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hello, Reviewers, > > May I have attention for thread? > I have separated the jumbo vmTestbase to 1+7 patches. > This patch is the entrypoint in root project. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > This patch is just vmTestbase blob from jdk14+14. > https://cr.openjdk.java.net/~xliu/8231089/base.patch.tar.gz > > If reviewers allow me to push this two patches, we can review other changes and let remaining patches trickle in. > Thanks, > --lx > > > On 10/8/19, 10:49 AM, "jdk8u-dev on behalf of Liu, Xin" <jdk8u-dev-bounces at openjdk.java.net on behalf of xxinliu at amazon.com> wrote: > > Hi, Konstantin, > > Yes, it makes sense. I prepare a webrev and include it your change. > https://cr.openjdk.java.net/~xliu/8231089/root/webrev/ > > Can we at least push it first? > Thanks, > --lx > > On 10/8/19, 3:43 AM, "Konstantin Shefov" <kshefov at azul.com> wrote: > > Hello > > In order to speed up vmTestbase's native part compilation we have to change target test-image in make/Main.gmk a bit: > > diff -r 31d7a6f35834 make/Main.gmk > --- a/make/Main.gmk Thu Sep 26 16:41:02 2019 +0300 > +++ b/make/Main.gmk Tue Oct 08 13:40:57 2019 +0300 > @@ -168,10 +168,10 @@ > @$(call TargetExit) > test-image: start-make > @$(call TargetEnter) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk build-test-hotspot-jtreg-native) > - ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j1 MAKEFLAGS= SPEC=$(SPEC) \ > + ($(CD) $(SRC_ROOT)/hotspot/test && $(BUILD_LOG_WRAPPER) $(MAKE) -j$(JOBS) MAKEFLAGS= SPEC=$(SPEC) \ > JT_HOME=$(JT_HOME) PRODUCT_HOME=$(JDK_IMAGE_DIR) ALT_OUTPUTDIR=$(OUTPUT_ROOT) CONCURRENCY=$(JOBS) \ > -f JtregNativeHotspot.gmk test-image-hotspot-jtreg-native) > @$(call TargetExit) > > Konstantin > > On 07/10/2019, 13:10, "Konstantin Shefov" <kshefov at azul.com> wrote: > > Hi. Liu Xin > > Removing @modules is indeed not mandatory, it just strange to have this tag in JDK 8. > > As for G1 GC tests, G1 GC in JDK8 has not been in production state yet, so it is expected that some tests from JDK 14 are failing against JDK 8. We have 4 tests failing, but we have not looked deeply into them yet. > > Konstantin > > > On 07/10/2019, 10:07, "Liu, Xin" <xxinliu at amazon.com> wrote: > > Hi, Konstantin and other reviewers, > > I used hg/mq to reformat those 7 patches. It's a very useful tool to manage commits in hg. I can jump back and modify what I comitted. > > > $hg qapplied > base > updateAPIs > classFileInstaller > gclog > nativeLibraries > azul_contrib1 > azul_contrib2 > > Could you review my changes? I didn't generate webrev because they are huge. > https://cr.openjdk.java.net/~xliu/8231089/ > > @Konstantin, > > I move some changes to updateAPIs and gclog from your patches. It's you who identified and solved that problems. I just try to collect one kind of problem into one patch. It's easier for reviewers. > I have some comments for your patches. > 1) previously, you have deleted all @module. Eg. > /* > * @test > - * @modules java.base/jdk.internal.misc:+open > * @key stress gc > * > * @summary converted from VM Testbase gc/g1/unloading/tests/unloading_anonclassloader_inMemoryCompilation_keep_class. > * VM Testbase keywords: [gc, stress, stressopt, nonconcurrent, javac] > * > - * @modules java.base/jdk.internal.misc > * @library /vmTestbase > * /testlibrary > * /test/lib > @@ -40,7 +38,6 @@ > * @comment generate HumongousTemplateClass and compile it to test.classes > * @run driver gc.g1.unloading.bytecode.GenClassesBuilder > * > - * @requires vm.gc.G1 > > I don't think it's mandatory. Jtreg automatically ignores unknown annotations like @module. if you don't modify it, your patch will be dramatically smaller. > It's easy to review and reduce conflicts for future merges. I also added property vm.gc.G1, which returns true unconditionally. > > 2. has you solved this issue? > https://gist.github.com/navyxliu/856ac2feab41591ec9220fb259d83072 > I still can't pass some tests under vmTestbase/gc/g1/unloading. They all failed with the same error code. it looks that G1GC unloaded some classes. > > > Thanks, > --lx > > On 9/26/19, 4:52 AM, "Konstantin Shefov" <kshefov at azul.com> wrote: > > Hi, Liu Xin > > I have to change my previous answer about Platform.java. > We cannot just remove it and change vmProps.java refer to jdk.testlibrary.Platform. > > The reasons are: > 1) There is no jdk.testlibrary.Platform class. We have com.oracle.java.testlibrary.Platform instead. > 2) com.oracle.java.testlibrary.Platform is NOT a superset of jdk.test.lib.Platform - it contains less methods. > 3) A lot of tests fail to compile because of absent methods in com.oracle.java.testlibrary.Platform. > > So if we want to get rid of "hostspot/test/test/lib" folder, we have to merge new methods into hotspot/test/testlibrary/com/oracle/java/testlibrary folder. > > The other solution is to leave everything as is, so use the "azul_contrib2" patch exactly as we provided it. > > Regards, > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Thursday, September 26, 2019 12:52 PM > To: 'Liu, Xin' <xxinliu at amazon.com>; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hello > > I have no objections against removing Platform.java and using the existing one. > > Konstantin > > -----Original Message----- > From: Liu, Xin <xxinliu at amazon.com> > Sent: Thursday, September 26, 2019 2:24 AM > To: Konstantin Shefov <kshefov at azul.com>; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > I think you can also remove Platform.java in test/lib/jdk/test. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/test/lib/jdk/test/lib/Platform.java.patch > and change vmProps.java refer to jdk.testlibrary.Platform. > https://cr.openjdk.java.net/~xliu/8231089/azul_contrib2/webrev/test/jtreg-ext/requires/VMProps.java.udiff.html > > It's because jdk.testlibrary.Platform is superset of the delete one. > Thanks, > --lx > > On 9/25/19, 3:20 AM, "Konstantin Shefov" <kshefov at azul.com> wrote: > > Hi > > Here is one more patch from Azul side: http://cr.openjdk.java.net/~kshefov/vmTestbase_8_azul_contrib_2/webrev/ > > This patch is supposed to be applied just after "azul_contrib" patch sent by Liu Xin. > > The list of changes is the following: > 1) Removed unused code from hotspot/test/test/lib folder (we ran all tests after that, nothing breaks); > 2) Fixed some tests so they work with JDK 8 (they used JDK 13 API, so had to refactor); > 3) Removed tests that test "Compact String" feature, which is not available in JDK 8; > 4) Made a small change in test/JtregNativeHotspot.gmk file so that now native test libs are automatically copied to jdk8u-dev/build/<YOUR_BUILD_NAME>/images/test directory exactly as it is done in JDK 11+. In JDK 8 "TEST_IMAGE_DIR" variable is not defined, so it was replaced by "$(IMAGES_OUTPUTDIR)/test". > > With all changes provided by Liu Xin and the patch provided here we think it can be pushed. > > Thanks, > --Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 6:30 PM > To: 'Liu, Xin' <xxinliu at amazon.com>; 'jdk8u-dev at openjdk.java.net' <jdk8u-dev at openjdk.java.net> > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > After applying all the patches, I have successfully built the native part, but I had to do some more changes. > After all tests run, I will prepare one more patch "azul_contrib_2" and send it here. > > Konstantin > > -----Original Message----- > From: Konstantin Shefov > Sent: Monday, September 23, 2019 4:47 PM > To: 'Liu, Xin' <xxinliu at amazon.com>; jdk8u-dev at openjdk.java.net > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > Thank you for combining our patch with yours, we will test the whole chain of patches to work at our side. > > As an answer to your question about modification from 0x21 to 0x2e at earlyretint.c. > Java class file format has changed between JDK 8 and JDK 11+. > In earlyretint.c from JDK 11+ we have the following line: > > "jlocation loc_exp = (i == 0) ? 0x21 : 0xd; " > > This "loc_exp" is an expected location of instruction inside a java method (see and [1] and [2]). > By the test scenario we breakpoint inside countDownBoolean(I)V method after checkPoint()V method. > In Java 8 the number of instruction before which we breakpoint is 0x2e (hex) and 46 (decimal). > In Java 11+ the number of instruction before which we breakpoint is 0x21 (hex) and 33 (decimal). > That is why we have to change the test here. > > [1] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#SingleStep > [2] https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#jlocation > > Regards, > Konstantin > > -----Original Message----- > From: Liu, Xin <xxinliu at amazon.com> > Sent: Monday, September 23, 2019 10:13 AM > To: Konstantin Shefov <kshefov at azul.com>; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > hi, Konstantin, > > I also apply your patch to the last webrev. > > eventually, JDK-8231089 consists of 6 patches. now I think it's easier to review it. https://cr.openjdk.java.net/~xliu/8231089/ > > We should apply them in order. > 1. base > 2. apiChanges > 3. classFileInstaller > 4. gclog > 5. native_libraries > 6. azul_contrib > > for your patch, i keep it everything except for -Xloggc. > Could you tell me why you modify from 0x21 to 0x2e? > diff -r 95eb898ada95 -r 6c35ac679aa8 test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c > --- a/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:30:08 2019 +0300 > +++ b/test/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.c Thu Sep 19 17:35:58 2019 +0300 > @@ -89,7 +89,7 @@ > jlocation loc, jint i) { > jvmtiError err; > jclass cls; > - jlocation loc_exp = (i == 0) ? 0x21 : 0xd; > + jlocation loc_exp = (i == 0) ? 0x2e : 0xd; > char *sigClass, *name, *sig, *generic; > jvmtiLocalVariableEntry *table = NULL; > jint entryCount = 0; > > ________________________________________ > From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> on behalf of Liu, Xin <xxinliu at amazon.com> > Sent: Saturday, September 21, 2019 4:48 AM > To: Konstantin Shefov; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > As I promised, here is the refactored webrev for native compilation > > Hotspot: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/hotspot/webrev/ > root: > https://cr.openjdk.java.net/~xliu/8231089/native_libraries/root/webrev/ > so the new target 'test-image' is added. > > to fix https://gist.github.com/navyxliu/bacd47891b17ac8d33d04708b648b531, > I added "LDFLAGS_SUFFIX := $$(LIBCXX), " to TestFilesCompilation.gmk. > > Thanks, > --lx > > > > > > > From: Konstantin Shefov <kshefov at azul.com> > Date: Friday, September 20, 2019 at 11:01 AM > To: "Liu, Xin" <xxinliu at amazon.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net> > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, Liu Xin > > > I am refactoring makefiles. I plan to upload this webrev today. > Fine! We will try to compile with our toolchains. > > >> BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > Could you give me an example tests for this? > > One example is this > https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/ConflictingDefaultsTest.java#L329 > > And most of vmTestbase/vm/runtime/defmeth tests seem to test JVM spec in some way. > See here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L50 > and here https://github.com/navyxliu/corretto-8/blob/vmTestbase/src/hotspot/test/vmTestbase/vm/runtime/defmeth/BasicTest.java#L134 > > Konstantin > > From: Liu, Xin <xxinliu at amazon.com> > Sent: Friday, September 20, 2019 8:35 PM > To: Konstantin Shefov <kshefov at azul.com>; jdk8u-dev at openjdk.java.net > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Konstantin, > > I am refactoring makefiles. I plan to upload this webrev today. > > I found that you have solved almost all problems. I can help to troubleshoot the remaining tests. > >BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > Could you give me an example tests for this? > > Thanks, > --lx > > From: Konstantin Shefov <kshefov at azul.com<mailto:kshefov at azul.com>> > Date: Friday, September 20, 2019 at 2:26 AM > To: "Liu, Xin" <xxinliu at amazon.com<mailto:xxinliu at amazon.com>>, "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>> > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We will use your new patches to run tests and merge my changes with yours for those tests that will not work. > > BTW, some tests are extensions to JCK and check JVM Specification. The Specification in Java 14 has changed from that in Java 8. > > I see your webrevs do not contain native part build scripts for now. We have to address this problem so the scripts should work for older GCC versions also. > > Regards > Konstantin > > From: "Liu, Xin" <xxinliu at amazon.com<mailto:xxinliu at amazon.com>> > Date: Wednesday, 18 September 2019 at 20:59 > To: Konstantin Shefov <kshefov at azul.com<mailto:kshefov at azul.com>>, "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>> > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > > Hi, Konstantin, > > > > thank you for updating. > > > > We care about x86_64 and aarch64 as well. You ran more tests than us. we never run all vmTestbase. > > Previously, I used a ProblemList.txt file to screen Problem and move on. Do you plan to fix all problems before we check in? > > > > Back to refactor, I have filed a JBS issues. > > https://bugs.openjdk.java.net/browse/JDK-8231089 > > In the meanwhile, I start splitting the commits to individual hg changesets. > https://cr.openjdk.java.net/~xliu/8231089/ > > 1. base -> copy code from tag jdk-14+14 > intact commit for vmTestbase and testlib 2. make apiChanges for ProcessUtils and Unsafe Could you review it? > > 3. ClassFileInstaller needs /testlibrary it's because ClassFileInstaller is in /test/testlibrary. I use this script to install @library /testlibrary for all tests. > > out=$(grep "ClassFileInstaller" -R vmTestbase | awk '{print $1}') for i in $out; do > f=${i%\:} > gsed -i 's/@library \/vmTestbase/&\n * \/testlibrary/' $f > done > > > What do you think that this approach? > If I got something wrong, we can update the webtrev with yours. > > thanks, > --lx > > > ________________________________ > From: Konstantin Shefov <kshefov at azul.com<mailto:kshefov at azul.com>> > Sent: Wednesday, September 18, 2019 4:56 PM > To: Liu, Xin; jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net> > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi > > We ran the tests against x86_64 Ubuntu Linux and there are just the same failed tests as it was with Arm64 Ubuntu Linux plus 2 more tests: > vmTestbase/gc/lock/jni/jnilock002/TestDescription.java > vmTestbase/nsk/jdb/set/set001/set001.java > > Konstantin > > > From: Konstantin Shefov > Sent: Wednesday, September 11, 2019 10:53 AM > To: 'Liu, Xin' <xxinliu at amazon.com<mailto:xxinliu at amazon.com>>; jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net> > Subject: RE: Backport vmTestbase tests to jdk8u-dev? > > Hi, LX > > Answering to your e-mail, as for what we modified in [3]: > > 1. API changes (Process, Unsafe), Xloggc option, that were not in your patches; > 2. In a file hotspot/test/JtregNativeHotspot.gmk we changed "-lpthread" option to "-pthread" to prevent compilation error. > > I agree that there should be a series of patches to track file changes. > > As for investigation of failures: do you have the same? We ran against Arm64 platform, but we can try against x86-64 too. > > Konstantin > > From: Liu, Xin <xxinliu at amazon.com<mailto:xxinliu at amazon.com>> > Sent: Monday, September 9, 2019 11:04 PM > To: Konstantin Shefov <kshefov at azul.com<mailto:kshefov at azul.com>>; jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net> > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, Konstantin, > > We are glad to work with you to get vmTestbase landed into jdk8u. > Our original intent is get design reviewed by the jdk8u maintainer. After then, we can proceed to refactor it. We can work together to refactor it. we plan to do it anyway. > > Back to the webrev you send. What did you modify in [3]? > Ideally, we can should have a series of patches. The first one should be intact vmTestbase code from the tip of JDK. All we changes should come after it and be reviewed by this mail-list. > In addition to refactoring, we can also offer help to figure out those failed cases. What do you think? > > Thanks, > --lx > > > From: Konstantin Shefov <kshefov at azul.com<mailto:kshefov at azul.com>> > Date: Friday, September 6, 2019 at 12:55 PM > To: "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>> > Cc: "Liu, Xin" <xxinliu at amazon.com<mailto:xxinliu at amazon.com>> > Subject: Re: Backport vmTestbase tests to jdk8u-dev? > > Hi, > > We at Azul think it is a good idea to backport vmTestbase tests to OpenJDK 8. > > We have used patches you suggested, done some refactoring to enable more tests to work with JDK 8. > > We have run all 3550 tests from "vmTestbase" folder against Zulu 8 at ARM64 platform: > > 1. 3371 tests PASS (see [1]); > 2. 179 tests FAIL (see [2]): reasons are being investigated. > > Patches we have used (contain our refactoring): > > 1. Hotspot folder [3] > > 2. Main folder [4] > > We plan to investigate causes of those 177 failures, purify unused code from hotspot/test/test/lib/jdk, and run the tests against different platforms. > > We also compared vmTestbase from JDK 11 with that from JDK 13, we found out: > > 1. 332 test have been removed in JDK 13; > 2. Only 2 test have been added in JDK 13; > 3. Tests that remained were modified, but these modifications mostly are copyright years, or output format, or API changes. > From the above results we can tell that vmTestbase does not grow. It looks like that tests are been removed from there or transferred somewhere else. > > [1] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/passed_tests.html > [2] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/failed_tests.html > [3] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_hotspot.patch > [4] http://cr.openjdk.java.net/~kshefov/vmTestbase_8_backport/vmTestbase_root.patch > > Regards, > --Konstantin > > > > > > > > > > > > > >