From kevin.walls at oracle.com Wed Jul 1 09:33:06 2020 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 1 Jul 2020 10:33:06 +0100 Subject: [8u] RFR 8240295: hs_err elapsed time in seconds is not accurate enough In-Reply-To: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com> References: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com> Message-ID: Hi Zhengyu, In later JVM's there is more information printed on the same line, so there's the extra space. In 8u, "elapsed.." is the start of the line, so you don't want to use the extra space. Thanks Kevin On 29/06/2020 19:08, Zhengyu Gu wrote: > I would like to backport this patch to 11u for parity with Oracle 8u271. > > The original patch does not apply cleanly. > > There is one conflict, where 8u (unpatched) misses leading space on > following message: > > st->print_cr(" elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, > eldays, elhours, elmins, elsecs); > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8240295 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/8a14919d365d > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8243029-8u/webrev.00/ > > Thanks, > > -Zhengyu > From zgu at redhat.com Wed Jul 1 11:20:12 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 1 Jul 2020 07:20:12 -0400 Subject: [8u] RFR 8240295: hs_err elapsed time in seconds is not accurate enough In-Reply-To: References: <1e07e622-9719-5c2f-899d-f44b908bf48c@redhat.com> Message-ID: <8d96f4f5-46b8-5c4e-31d5-500f4d3cd869@redhat.com> Hi Kevin, Thanks for reviewing. Unfortunately, I pushed backport with extra space. I will try to push a fix. -Zhengyu On 7/1/20 5:33 AM, Kevin Walls wrote: > Hi Zhengyu, > > In later JVM's there is more information printed on the same line, so > there's the extra space. > > In 8u, "elapsed.." is the start of the line, so you don't want to use > the extra space. > > Thanks > Kevin > > > On 29/06/2020 19:08, Zhengyu Gu wrote: >> I would like to backport this patch to 11u for parity with Oracle 8u271. >> >> The original patch does not apply cleanly. >> >> There is one conflict, where 8u (unpatched) misses leading space on >> following message: >> >> st->print_cr(" elapsed time: %d seconds (%dd %dh %dm %ds)", eltime, >> eldays, elhours, elmins, elsecs); >> >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8240295 >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/8a14919d365d >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8243029-8u/webrev.00/ >> >> Thanks, >> >> -Zhengyu >> > From zgu at redhat.com Wed Jul 1 23:59:25 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 1 Jul 2020 19:59:25 -0400 Subject: [8u] RFR(T) 8248643: Remove extra leading space in JDK-8240295 8u backport Message-ID: Hi, Please review this trivial change that removes extra leading space in JDK-8240295 backport. Kevin pointed out 8u should not follow later version, where more information printed on the same line [1]. Bug: https://bugs.openjdk.java.net/browse/JDK-8248643 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8240295/webrev.00/ [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012066.html Thanks, -Zhengyu From maoliang.ml at alibaba-inc.com Thu Jul 2 02:30:34 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Thu, 02 Jul 2020 10:30:34 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgQmFja3BvcnQgODA1NzAwMzogTGFyZ2UgcmVmZXJlbmNlIGFycmF5cyBjYXVz?= =?UTF-8?B?ZSBleHRyZW1lbHkgbG9uZyBzeW5jaHJvbml6YXRpb24gdGltZXM=?= Message-ID: <834cb33e-c7d4-4768-8798-8b6bf01f4eb1.maoliang.ml@alibaba-inc.com> Hi, I'm requesting the backport of 8057003 into 8u. As the description in the bug, it's a serious G1 issue which leads to 10X longer concurrent mark time and hang the Java threads for seconds. We encounter the problem in several applications. Since G1 is widely used in 8u, we need to fix it. Original bug: https://bugs.openjdk.java.net/browse/JDK-8057003 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd The JDK9 patch did not apply cleanly. Although it is not a small patch, I didn't change much except some assertions. One assertion in taskqueue.hpp is removed. It should be ok because it's no longer there as well since JDK9. 8u webrev: http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ Testing: gc/g1, specjbb2015 with fastdebug Could someone please have a look and sponsor? Thanks, Liang From kevin.walls at oracle.com Thu Jul 2 10:02:53 2020 From: kevin.walls at oracle.com (Kevin Walls) Date: Thu, 2 Jul 2020 11:02:53 +0100 Subject: [8u] RFR(T) 8248643: Remove extra leading space in JDK-8240295 8u backport In-Reply-To: References: Message-ID: Hi Zhengyu, Looks good 8-) Thanks Kevin On 02/07/2020 00:59, Zhengyu Gu wrote: > Hi, > > Please review this trivial change that removes extra leading space in > JDK-8240295 backport. > > Kevin pointed out 8u should not follow later version, where more > information printed on the same line [1]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248643 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8240295/webrev.00/ > > [1] > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012066.html > > Thanks, > > -Zhengyu > From thomas.schatzl at oracle.com Thu Jul 2 11:23:00 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 2 Jul 2020 13:23:00 +0200 Subject: [8u] RFR(T) 8248643: Remove extra leading space in JDK-8240295 8u backport In-Reply-To: References: Message-ID: Hi, On 02.07.20 12:02, Kevin Walls wrote: > Hi Zhengyu, > > Looks good 8-) +1 - and trivial. Thomas From zgu at redhat.com Thu Jul 2 20:54:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 2 Jul 2020 16:54:45 -0400 Subject: [8u] RFR(T) 8248643: Remove extra leading space in JDK-8240295 8u backport In-Reply-To: References: Message-ID: Hi Kevin and Thomas, Thanks for reviewing. Pushed. -Zhengyu On 7/2/20 7:23 AM, Thomas Schatzl wrote: > Hi, > > On 02.07.20 12:02, Kevin Walls wrote: >> Hi Zhengyu, >> >> Looks good 8-) > > +1? -? and trivial. > > Thomas > From sgehwolf at redhat.com Fri Jul 3 07:50:11 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 Jul 2020 09:50:11 +0200 Subject: [8u] RFR(T) 8248643: Remove extra leading space in JDK-8240295 8u backport In-Reply-To: References: Message-ID: Hi Zhengyu, On Thu, 2020-07-02 at 16:54 -0400, Zhengyu Gu wrote: > Hi Kevin and Thomas, > > Thanks for reviewing. Pushed. Please seek for jdk8u-fix-yes approval before you push next time (same process for 8u-only bugs than for backports). Thanks, Severin From sgehwolf at redhat.com Fri Jul 3 08:16:04 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 Jul 2020 10:16:04 +0200 Subject: [8u] RFR (S) 8046274: Removing dependency on jakarta-regexp In-Reply-To: <01a43b4b-c5a1-dc6e-5d17-d0f5fcd2a0ec@redhat.com> References: <01a43b4b-c5a1-dc6e-5d17-d0f5fcd2a0ec@redhat.com> Message-ID: <70bee23c67975ae7f4a5c61ada6629b234ab9eaa.camel@redhat.com> On Fri, 2020-03-27 at 12:23 +0100, Aleksey Shipilev wrote: > Original change: > https://bugs.openjdk.java.net/browse/JDK-8046274 > https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/bfc9ec1a816b > > Patch does not apply cleanly to 8u, because paths are different. I have removed > src/com/sun/org/apache/regexp/ by hand. Reapplied THIRD_PARTY_README by hand. InstructionFinder.java > change applies after reshuffling. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8046274/webrev.8u.01/ > > Testing: java/xml tests, tier1 This looks good to me. Please be sure to push THIRD_PARTY_README changes to all 8 repositories once you've got approval. Thanks, Severin From akashche at redhat.com Mon Jul 6 10:53:54 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 6 Jul 2020 11:53:54 +0100 Subject: [8u] RFR: 8191678: [TESTBUG] Add keyword headful in java/awt and javax tests. Message-ID: Hi, Please review the backport of JDK-8191678 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8191678 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/50d61f4b5d1a 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8191678/webrev.00/ This change adds "headful" keyword to a number of client tests. Only a single test (FocusTransitionTest) from this patch is present in 8u - only changes to it are backported. Testing: checked that changed test can be selected with "headful" keyword. -- -Alex From akashche at redhat.com Mon Jul 6 10:53:28 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 6 Jul 2020 11:53:28 +0100 Subject: [8u] RFR: 8185500: [TESTBUG] Add keywords headful/printer in java/awt and javax tests. Message-ID: <37e50eaf-79ee-48d6-dc8a-2d03dc70073d@redhat.com> Hi, Please review the backport of JDK-8185500 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8185500 10 change: https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/b762aafa34e3 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8185500/webrev.00 This change adds "headful" and "printer" keywords to a number of client test, 129 tests are changed in jdk10, 63 of them are present in 8u. Patch is altered for 8u leaving only the tests that are present, some tests also have required changes to jtreg tags section and copyright year. There are no changes to test code itself. Testing: checked that modified tests can be selected correctly with "headful" and "printer" keywords: Before: $ jtreg [...] -l @list.txt Tests found: 63 After: $ jtreg [...] -l -k:headful @list.txt Tests found: 53 $ jtreg [...] -l -k:printer @list.txt Tests found: 10 $ jtreg [...] -l -k:"(headful|printer)" @list.txt Tests found: 63 Note, some tests include "os.family" requirement, so the numbers above may differ. -- -Alex From maoliang.ml at alibaba-inc.com Mon Jul 6 12:33:11 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Mon, 06 Jul 2020 20:33:11 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgQmFja3BvcnQgODA1NzAwMzogTGFyZ2UgcmVmZXJlbmNlIGFycmF5cyBjYXVz?= =?UTF-8?B?ZSBleHRyZW1lbHkgbG9uZyBzeW5jaHJvbml6YXRpb24gdGltZXM=?= Message-ID: Hi, Could someone please help? Thanks, Liang ------------------------------------------------------------------ From:MAO, Liang Send Time:2020 Jul. 2 (Thu.) 10:30 To:jdk8u-dev Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Hi, I'm requesting the backport of 8057003 into 8u. As the description in the bug, it's a serious G1 issue which leads to 10X longer concurrent mark time and hang the Java threads for seconds. We encounter the problem in several applications. Since G1 is widely used in 8u, we need to fix it. Original bug: https://bugs.openjdk.java.net/browse/JDK-8057003 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd The JDK9 patch did not apply cleanly. Although it is not a small patch, I didn't change much except some assertions. One assertion in taskqueue.hpp is removed. It should be ok because it's no longer there as well since JDK9. 8u webrev: http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ Testing: gc/g1, specjbb2015 with fastdebug Could someone please have a look and sponsor? Thanks, Liang From mbalao at redhat.com Mon Jul 6 20:45:33 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 6 Jul 2020 17:45:33 -0300 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> Message-ID: <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> Hello Alexey, Apologies for the delay. I was busy with the upcoming CPU, but my expectation is that we can finish the TLS 1.3 work without any other interruption now. Comments inline. Thanks, Martin.- -- On 6/16/20 3:07 PM, Alexey Bakhtin wrote: >> * Do we have tests covering this functionality? >> >> * CipherSuite.java >> > Yes. The tests are located in sun/security/krb5/auto directory > It is part of JDK-8245681 subtask. > Also, some regular ciphersuite tests also test TLS_KRB cipher suites > Ok. >> * With the previous comments in mind, please have a look at the other >> KRB5 ciphersuites added. > > Sure. All TLS_KRB5 cipher suites are updated accordingly Ok. Please keep in your backlog the CSR documentation of this change; so any user affected knows why and what's the backward-compatibility workaround for 'disabled by default' ciphers. >> * ClientHello.java >> >> * I've seen there is a copyright line addition. If you want to keep it >> there, please get approval from 8u maintainers because I'm not sure of >> the policy there. >> * Same comment for SSLKeyExchange.java, SSLSessionImpl.java and >> ServerHello.java >> * This comment does not apply to new files, which look okay to me > I've added copyrights to the files with new TLS_KRB5 code, not a backport. > But sure, I?ll check if it is possible to add copyright lines to these files > Ok, I talked to one of the 8u maintainers and as long as there are significant/original changes into the file, a new copyright line added should be fine. I'll leave this judgement up to you or to anyone else who want to participate; I'd rather focus on more technical stuff for this review. >> * I suggest to be explicit in what we import, instead of "java.security.*? > OK. Added explicit declaration Ok, thanks. >> >> * I've seen a double-spacing in "} else if (suite.keyExchange == >> K_KRB5 ||? > Fixed Ok. >> >> * Are changes needed for previous versions of the protocol? TLS 1.1, >> TLS 1.0, etc. >> > T12ClientHelloConsumer is used for TLSv1.2 and prior protocol versions. > I think it is right place for all non-TLSv1.3 protocols That's right. My fault. > >> * I suggest to follow the pattern. Create a new condition of type "if >> (resumingSession && ..." instead of hooking "Validate that the cached >> cipher suite" one > > OK. Updated the code to follow the pattern. > Ok. >> >> * No gain in inserting a newline after ?return? > Fixed. Ok. >> * ServerHello.java >> >> * Are changes needed for previous versions of the protocol? TLS 1.1, >> TLS 1.0, etc. > > T12ServerHelloConsumer is used for TLSv1.2 and prior protocol versions. > I think it is right place for all non-TLSv1.3 protocols You're right. >> >> * HandshakeContext.java >> >> * I suggest to move sun/security/ssl/krb5/* files to sun/security/ssl >> so we can keep HandshakeContext and other classes visibility unchanged. >> This change will probably eliminate the need to add getMajor and >> getMinor methods in ProtocolVersion, as well as changing valueOf method >> visibility. >> > Separation of the Kerberos functionality was done intentionally. > JDK8 compact profile1 does not include Kerberos API and implementation. > So, such separation allows to detect Kerberos presence at runtime > and support TLS_KRB cipher suites if implementation exist only. > Also, this is a reason we have different classes: KerberosClientKeyExchange, > KerberosClientKeyExchangeImpl and KrbClientKeyExchange > We can not merge them together without breaking compact profile. > I?ll try to make KrbClientKeyExchange more similar to template but > proxy and delegation classes are still required. > This issue and listed below are not included in updated webrev. > Oh, good point! Hmm... let me give this some more thought, because I still find it confusing. Thanks, Martin.- From felix.yang at huawei.com Tue Jul 7 03:22:20 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 Jul 2020 03:22:20 +0000 Subject: RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read Message-ID: Hi, We were witnessing random JVM crash that triggers in our production environment. We were running an aarch64 jdk8u release build with -XX:+UseConcMarkSweepGC. We see three different crash logs as reported on the issue. Debugging show that this caused by missing memory fences in CMS for systems with weak memory model like aarch64. The overall procedure in CMS promotion looks like: ConcurrentMarkSweepGeneration::par_promote { HeapWord* obj_ptr = ps->lab.alloc(alloc_sz); |---> CFLS_LAB::alloc |--->FreeChunk::markNotFree oop obj = oop(obj_ptr); OrderAccess::storestore(); obj->set_mark(m); OrderAccess::storestore(); // Finally, install the klass pointer (this should be volatile). OrderAccess::storestore(); obj->set_klass(old->klass()); ...... void markNotFree() { // Set _prev (klass) to null before (if) clearing the mark word below _prev = NULL; #ifdef _LP64 if (UseCompressedOops) { OrderAccess::storestore(); set_mark(markOopDesc::prototype()); } #endif assert(!is_free(), "Error"); } From the first crash log on the issue, the crash site was in CompactibleFreeListSpace::block_size. We found that it's possible on aarch64 (Reference [1]) that the klass load may be scheduled before the free chunk check in CompactibleFreeListSpace::block_size(). Then we may have an invalid non-null klass, which leads to the crash. Same issue exists in CompactibleFreeListSpace::block_is_obj(), which leads to the other two crashes. Webrev for jdk8u-dev: http://cr.openjdk.java.net/~fyang/8248851/webrev.00/ JTreg tested on x86_64-linux-gnu &aarch64-linux-gnu with jdk8u release builds. Comments? Thanks, Felix [1] Reference: armv8 architecture reference manual K11.6.1 This restriction applies only when the data value returned by a read is used as a data value to calculate the address of a subsequent read or write. It does not apply if the data value returned by a read determines the condition flags values, and the values of the flags are used for condition code evaluation to determine the address of a subsequent read, either through conditional execution or the evaluation of a branch. This is called a control dependency. From aph at redhat.com Tue Jul 7 08:42:19 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Jul 2020 09:42:19 +0100 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: Message-ID: On 07/07/2020 04:22, Yangfei (Felix) wrote: > Webrev for jdk8u-dev: > http://cr.openjdk.java.net/~fyang/8248851/webrev.00/ JTreg tested on > x86_64-linux-gnu &aarch64-linux-gnu with jdk8u release builds. > Comments? That looks right. I was thinking of arguing that you only need loadload here, but other parts of the same function use acquire, so we might as well be consistent. I'd lose this line: // Bugfix for systems with weak memory model (AARCH64). It doesn't add anything, and it may mislead people into thinking that it's AArch64 specific. Looking at the code, it seems like all the casting to volatile was an earlier attempt to fix the same bug. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Tue Jul 7 11:48:00 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 7 Jul 2020 11:48:00 +0000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, July 7, 2020 4:42 PM > To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' > > Cc: hotspot-gc-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > fences between free chunk check and klass read > > On 07/07/2020 04:22, Yangfei (Felix) wrote: > > > Webrev for jdk8u-dev: > > http://cr.openjdk.java.net/~fyang/8248851/webrev.00/ JTreg tested on > > x86_64-linux-gnu &aarch64-linux-gnu with jdk8u release builds. > > Comments? > > That looks right. I was thinking of arguing that you only need loadload here, > but other parts of the same function use acquire, so we might as well be > consistent. > > I'd lose this line: > > // Bugfix for systems with weak memory model (AARCH64). > > It doesn't add anything, and it may mislead people into thinking that it's > AArch64 specific. Looking at the code, it seems like all the casting to volatile > was an earlier attempt to fix the same bug. Good suggestion. I have prepared a new webrev with the line removed: http://cr.openjdk.java.net/~fyang/8248851/webrev.01/ Does it look better? Thanks, Felix From andrew_m_leonard at uk.ibm.com Tue Jul 7 15:13:09 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Tue, 7 Jul 2020 16:13:09 +0100 Subject: VS2010 end of support July2020 Message-ID: Hi, I notice from the Microsoft VS support page : https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing that VS2010 is out of support this month? Is there plans to support VS2017 for jdk8, I don't see any obvious bug stating that? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From kim.barrett at oracle.com Tue Jul 7 13:28:02 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Jul 2020 09:28:02 -0400 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: Message-ID: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> > On Jul 7, 2020, at 7:48 AM, Yangfei (Felix) wrote: > > Hi, > >> -----Original Message----- >> From: Andrew Haley [mailto:aph at redhat.com] >> Sent: Tuesday, July 7, 2020 4:42 PM >> To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' >> >> Cc: hotspot-gc-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory >> fences between free chunk check and klass read >> >> On 07/07/2020 04:22, Yangfei (Felix) wrote: >> >>> Webrev for jdk8u-dev: >>> http://cr.openjdk.java.net/~fyang/8248851/webrev.00/ JTreg tested on >>> x86_64-linux-gnu &aarch64-linux-gnu with jdk8u release builds. >>> Comments? >> >> That looks right. I was thinking of arguing that you only need loadload here, >> but other parts of the same function use acquire, so we might as well be >> consistent. >> >> I'd lose this line: >> >> // Bugfix for systems with weak memory model (AARCH64). >> >> It doesn't add anything, and it may mislead people into thinking that it's >> AArch64 specific. Looking at the code, it seems like all the casting to volatile >> was an earlier attempt to fix the same bug. > > Good suggestion. > I have prepared a new webrev with the line removed: http://cr.openjdk.java.net/~fyang/8248851/webrev.01/ > Does it look better? > > Thanks, > Felix This change seems needed, but is it sufficient? Seems like there should be a corresponding release/storestore/something for the correspnding writes; is it there? (I haven't looked at CMS for quite a while, so no longer sure where to look.) This issue seems to persist all the way until CMS removal in JDK 14. Also, there's the closely related JDK-8160369 (JDK 9), which doesn't appear to have been backported to JDK 8. From aph at redhat.com Tue Jul 7 15:16:18 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Jul 2020 16:16:18 +0100 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: Message-ID: On 07/07/2020 12:48, Yangfei (Felix) wrote: > I have prepared a new webrev with the line removed: http://cr.openjdk.java.net/~fyang/8248851/webrev.01/ > Does it look better? Thanks, that's good. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Tue Jul 7 15:32:50 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 7 Jul 2020 15:32:50 +0000 Subject: OperatingSystemMXBean backport to OpenJDK 8u261 Message-ID: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> Hi, Kyle, 8u261 is the designation for Oracle's 8u July 2020 release. Their 8u repos are private, and they do not post their patches. The equivalent OpenJDK 8u release designation is "openjdk8u262". In this case, Oracle has done a backport, but there is no OpenJDK backport (yet). Thanks, Paul ?On 7/7/20, 8:15 AM, "jdk8u-dev on behalf of Kyle Liberti" wrote: Hi all, I was looking at the "OperatingSystemMXBean should be made container aware" issue here [1] and noticed that the patch was listed to be backported to openjdk 8u261 [2] However, I can't seem to find the commit or patch in the OpenJDK 8 source [3] [4] - Was the OperatingSystemMXBean patch [1] backported to OpenJDK 8? - Is 8u261 a real version? I can't seem to find the release in the OpenJDK source tags All the best, Kyle [1] https://bugs.openjdk.java.net/browse/JDK-8226575 [2] https://bugs.openjdk.java.net/browse/JDK-8242287 [3] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ [4] http://hg.openjdk.java.net/jdk8u/jdk8u/ From sgehwolf at redhat.com Tue Jul 7 15:58:54 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 07 Jul 2020 17:58:54 +0200 Subject: OperatingSystemMXBean backport to OpenJDK 8u261 In-Reply-To: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> References: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> Message-ID: Hi, I'm working on an OpenJDK 8u backport of this. It requires some process work (CSR), and for 8u, container metrics code needs to be backported first. Thanks, Severin On Tue, 2020-07-07 at 15:32 +0000, Hohensee, Paul wrote: > Hi, Kyle, > > 8u261 is the designation for Oracle's 8u July 2020 release. Their 8u > repos are private, and they do not post their patches. The equivalent > OpenJDK 8u release designation is "openjdk8u262". In this case, > Oracle has done a backport, but there is no OpenJDK backport (yet). > > Thanks, > Paul > > ?On 7/7/20, 8:15 AM, "jdk8u-dev on behalf of Kyle Liberti" wrote: > > Hi all, > > I was looking at the "OperatingSystemMXBean should be made container aware" > issue here [1] and noticed that the patch was listed to be backported to > openjdk 8u261 [2] However, I can't seem to find the commit or patch in the > OpenJDK 8 source [3] [4] > > - Was the OperatingSystemMXBean patch [1] backported to OpenJDK 8? > - Is 8u261 a real version? I can't seem to find the release in the > OpenJDK source tags > > All the best, > > Kyle > > [1] https://bugs.openjdk.java.net/browse/JDK-8226575 > [2] https://bugs.openjdk.java.net/browse/JDK-8242287 > [3] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ > [4] http://hg.openjdk.java.net/jdk8u/jdk8u/ > From aph at redhat.com Tue Jul 7 16:16:34 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Jul 2020 17:16:34 +0100 Subject: OperatingSystemMXBean backport to OpenJDK 8u261 In-Reply-To: References: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> Message-ID: <9c876a0a-190c-782d-af57-bac73e4b435c@redhat.com> On 07/07/2020 16:58, Severin Gehwolf wrote: > I'm working on an OpenJDK 8u backport of this. It requires some process > work (CSR), and for 8u, container metrics code needs to be backported > first. I would have thought that, given Oracle have decided to ship it, the CSR should already have happened. -- 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 sgehwolf at redhat.com Tue Jul 7 17:07:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 07 Jul 2020 19:07:18 +0200 Subject: OperatingSystemMXBean backport to OpenJDK 8u261 In-Reply-To: <9c876a0a-190c-782d-af57-bac73e4b435c@redhat.com> References: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> <9c876a0a-190c-782d-af57-bac73e4b435c@redhat.com> Message-ID: <7433c321e67944fb37af509e8924f2ea5208b3d7.camel@redhat.com> On Tue, 2020-07-07 at 17:16 +0100, Andrew Haley wrote: > On 07/07/2020 16:58, Severin Gehwolf wrote: > > I'm working on an OpenJDK 8u backport of this. It requires some process > > work (CSR), and for 8u, container metrics code needs to be backported > > first. > > I would have thought that, given Oracle have decided to ship it, > the CSR should already have happened. Yes, this is one of the changes which puzzels me. I've asked where the CSR is for 8u[1], but got no response unfortunately :( Maybe the call was to not do a CSR since only the behavior of the methods changed? To be on the safe side, I've submitted this one (waiting for CSR review): https://bugs.openjdk.java.net/browse/JDK-8248804 If you could help shed some light on this, I'd appreciate it. Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8242287 From bob.vandette at oracle.com Tue Jul 7 17:31:54 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 7 Jul 2020 13:31:54 -0400 Subject: OperatingSystemMXBean backport to OpenJDK 8u261 In-Reply-To: <7433c321e67944fb37af509e8924f2ea5208b3d7.camel@redhat.com> References: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> <9c876a0a-190c-782d-af57-bac73e4b435c@redhat.com> <7433c321e67944fb37af509e8924f2ea5208b3d7.camel@redhat.com> Message-ID: <2D52946D-4ED3-4981-834F-63CD511E1621@oracle.com> We only updated the existing APIs in JDK 8 and JDK 11 rather than add the new APIs. This is why there wasn?t a CSR for JDK 8. The CSR for JDK 11 just approved the concept of existing API implementation behavior changes with the only requirement being a release note. Since the CSR wasn?t strictly required, we only did the document update for JDK 8. Bob. > On Jul 7, 2020, at 1:07 PM, Severin Gehwolf wrote: > > On Tue, 2020-07-07 at 17:16 +0100, Andrew Haley wrote: >> On 07/07/2020 16:58, Severin Gehwolf wrote: >>> I'm working on an OpenJDK 8u backport of this. It requires some process >>> work (CSR), and for 8u, container metrics code needs to be backported >>> first. >> >> I would have thought that, given Oracle have decided to ship it, >> the CSR should already have happened. > > Yes, this is one of the changes which puzzels me. I've asked where the > CSR is for 8u[1], but got no response unfortunately :( Maybe the call > was to not do a CSR since only the behavior of the methods changed? > > To be on the safe side, I've submitted this one (waiting for CSR > review): > https://bugs.openjdk.java.net/browse/JDK-8248804 > > If you could help shed some light on this, I'd appreciate it. > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8242287 > From zgu at redhat.com Tue Jul 7 17:38:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Jul 2020 13:38:45 -0400 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call Message-ID: Hi, I would like to backport this patch to 8u for the parity of Oracle 8u271. The original patch does not apply cleanly, as 8u code diverged from jdk9. Original bug: https://bugs.openjdk.java.net/browse/JDK-6424123 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5217fa82f1a4 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-6424123-8u/webrev.00/ Test: tier1 on Linux 86_64 Thanks, -Zhengyu From zgu at redhat.com Tue Jul 7 18:56:09 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Jul 2020 14:56:09 -0400 Subject: [8u] RFR 8248924: JDK-8056964 8u backport is not accurate Message-ID: <787a465c-863b-5a31-d83b-7852f663765c@redhat.com> Please review this small patch that fixes inaccurate backport of JDK-8056964. Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248924/webrev.00/ Test: tier1 on Linux 86_64 Thanks, -Zhengyu From felix.yang at huawei.com Wed Jul 8 02:49:17 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 8 Jul 2020 02:49:17 +0000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> Message-ID: Hi, > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Tuesday, July 7, 2020 9:28 PM > To: Yangfei (Felix) > Cc: Andrew Haley ; jdk8u-dev at openjdk.java.net; > hotspot-gc-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > fences between free chunk check and klass read > Cut... > > > > Good suggestion. > > I have prepared a new webrev with the line removed: > > http://cr.openjdk.java.net/~fyang/8248851/webrev.01/ > > Does it look better? > > > > Thanks, > > Felix > > This change seems needed, but is it sufficient? Seems like there should be a > corresponding release/storestore/something for the correspnding writes; is > it there? (I haven't looked at CMS for quite a while, so no longer sure where > to look.) Yes, I think it's there. As mention in my first mail, the logic in markNotFree: void markNotFree() { // Set _prev (klass) to null before (if) clearing the mark word below _prev = NULL; <========== Write klass (= NULL) #ifdef _LP64 if (UseCompressedOops) { OrderAccess::storestore(); <========== StoreStore barrier set_mark(markOopDesc::prototype()); <========== Write marking not free } #endif assert(!is_free(), "Error"); } > This issue seems to persist all the way until CMS removal in JDK 14. Since CMS is deprecated from JDK9, I am not sure if it's appropriate to fix this issue for those JDK9+ versions. > Also, there's the closely related JDK-8160369 (JDK 9), which doesn't appear to > have been backported to JDK 8. Yeah, we also noticed that and was looking into it to see the possibility of a 8u backport. Thanks, Felix From hubert.debordeaux at thalesgroup.com Wed Jul 8 09:44:15 2020 From: hubert.debordeaux at thalesgroup.com (DEBORDEAUX Hubert) Date: Wed, 8 Jul 2020 09:44:15 +0000 Subject: SunPKCS11 connection lost after Decrypt doFinal In-Reply-To: <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com> References: <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com> <073918b1-75d1-305e-5054-c663aa360306@oracle.com> <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com> Message-ID: Hello, Do you know when this fix will be available in JDK 8? build 272 or higher? Once available, we will be able to update our build pipeline and test it with our network HSMs. Thanks, Regards, Hubert -----Original Message----- From: jdk8u-dev On Behalf Of Andrew Hughes Sent: Thursday, June 18, 2020 18:49 To: Valerie Peng ; jdk8u-dev at openjdk.java.net Subject: Re: SunPKCS11 connection lost after Decrypt doFinal On 17/06/2020 05:24, Valerie Peng wrote: > Well, JDK-8235215 is relevant to JDK-6946830 but not a duplicate of it. > > I should have added a duplicate-of-issue link to make it clear - > JDK-8235215 is closed as a duplicate of JDK-8236512. > > Sorry for the confusion and hope all is clear now. > > Thanks, > Valerie > Thanks, Valerie. Yes, it is now. I'll look into backporting 8236512. -- 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 aph at redhat.com Wed Jul 8 09:48:09 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Jul 2020 10:48:09 +0100 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> Message-ID: <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> On 08/07/2020 09:41, Kim Barrett wrote: >> Since CMS is deprecated from JDK9, I am not sure if it's appropriate to fix this issue for those JDK9+ versions. > Deprecated != unsupported. > Yes, it must be done. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kliberti at redhat.com Tue Jul 7 16:06:10 2020 From: kliberti at redhat.com (Kyle Liberti) Date: Tue, 7 Jul 2020 12:06:10 -0400 Subject: OperatingSystemMXBean backport to OpenJDK 8u261 In-Reply-To: References: <501C63CA-9AA8-4920-92D4-9879C75148A3@amazon.com> Message-ID: Hi Paul, Severin, Thanks for the information! I'll track the openjdk8u262 release for the changes. All the best, Kyle On Tue, Jul 7, 2020 at 11:59 AM Severin Gehwolf wrote: > Hi, > > I'm working on an OpenJDK 8u backport of this. It requires some process > work (CSR), and for 8u, container metrics code needs to be backported > first. > > Thanks, > Severin > > On Tue, 2020-07-07 at 15:32 +0000, Hohensee, Paul wrote: > > Hi, Kyle, > > > > 8u261 is the designation for Oracle's 8u July 2020 release. Their 8u > > repos are private, and they do not post their patches. The equivalent > > OpenJDK 8u release designation is "openjdk8u262". In this case, > > Oracle has done a backport, but there is no OpenJDK backport (yet). > > > > Thanks, > > Paul > > > > ?On 7/7/20, 8:15 AM, "jdk8u-dev on behalf of Kyle Liberti" < > jdk8u-dev-retn at openjdk.java.net on behalf of kliberti at redhat.com> wrote: > > > > Hi all, > > > > I was looking at the "OperatingSystemMXBean should be made container > aware" > > issue here [1] and noticed that the patch was listed to be > backported to > > openjdk 8u261 [2] However, I can't seem to find the commit or patch > in the > > OpenJDK 8 source [3] [4] > > > > - Was the OperatingSystemMXBean patch [1] backported to OpenJDK 8? > > - Is 8u261 a real version? I can't seem to find the release in the > > OpenJDK source tags > > > > All the best, > > > > Kyle > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8226575 > > [2] https://bugs.openjdk.java.net/browse/JDK-8242287 > > [3] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/ > > [4] http://hg.openjdk.java.net/jdk8u/jdk8u/ > > > > From kim.barrett at oracle.com Wed Jul 8 08:41:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Jul 2020 04:41:03 -0400 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> Message-ID: <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> > On Jul 7, 2020, at 10:49 PM, Yangfei (Felix) wrote: >> >> This change seems needed, but is it sufficient? Seems like there should be a >> corresponding release/storestore/something for the correspnding writes; is >> it there? (I haven't looked at CMS for quite a while, so no longer sure where >> to look.) > > Yes, I think it's there. As mention in my first mail, the logic in markNotFree: > > void markNotFree() { > // Set _prev (klass) to null before (if) clearing the mark word below > _prev = NULL; <========== Write klass (= NULL) > #ifdef _LP64 > if (UseCompressedOops) { > OrderAccess::storestore(); <========== StoreStore barrier > set_mark(markOopDesc::prototype()); <========== Write marking not free > } > #endif > assert(!is_free(), "Error"); > } OK, I think I see what?s going on here. Change looks good. >> This issue seems to persist all the way until CMS removal in JDK 14. > > Since CMS is deprecated from JDK9, I am not sure if it's appropriate to fix this issue for those JDK9+ versions. Deprecated != unsupported. From neugens at redhat.com Wed Jul 8 12:39:30 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 8 Jul 2020 14:39:30 +0200 Subject: [RFR]: JDK-8196196: Headful tests should not be run in headless mode Message-ID: Hi all, I would like to have a review for the following bug since it doesn't apply cleanly: https://bugs.openjdk.java.net/browse/JDK-8196196 I had to rework a number of them, for example a couple of tests don't exist in JDK8u while other had test code changes that didn't apply to 8u. The new webrev is here: http://cr.openjdk.java.net/~neugens/8196196/webrev.00/ 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 Jul 8 15:37:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Jul 2020 16:37:42 +0100 Subject: [8u] RFR 8248924: JDK-8056964 8u backport is not accurate In-Reply-To: <787a465c-863b-5a31-d83b-7852f663765c@redhat.com> References: <787a465c-863b-5a31-d83b-7852f663765c@redhat.com> Message-ID: On 07/07/2020 19:56, Zhengyu Gu wrote: > Please review this small patch that fixes inaccurate backport of > JDK-8056964. > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248924/webrev.00/ > > Test: > ? tier1 on Linux 86_64 > > Thanks, > > -Zhengyu > In what way is it not accurate? 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 Jul 8 15:41:48 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Jul 2020 16:41:48 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: References: Message-ID: <0d844672-7127-d7fe-5765-cf87f13690ad@redhat.com> On 07/07/2020 18:38, Zhengyu Gu wrote: > Hi, > > I would like to backport this patch to 8u for the parity of Oracle 8u271. > > The original patch does not apply cleanly, as 8u code diverged from jdk9. > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-6424123 > Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/5217fa82f1a4 > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-6424123-8u/webrev.00/ > > Test: > ? tier1 on Linux 86_64 > > Thanks, > > -Zhengyu > I already backported this: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011526.html In the end, we decided not to go ahead with this and workaround it for JDK-8076475: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011539.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 Jul 8 16:46:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Jul 2020 17:46:39 +0100 Subject: [8u] TLS 1.3: fallback scheme for the new SunJSSE engine In-Reply-To: <3217278f-d7d9-7a8a-1506-904973b0976b@redhat.com> References: <828504cf-47d4-283d-5910-b7e0edfc23eb@redhat.com> <2c8386ac-acbe-7eae-853f-4cd6d3955a68@redhat.com> <1F1915CC-9110-461D-8F3C-F5D6394D2F33@azul.com> <7dab1baa-6dca-bf8a-1ced-6c639df85467@redhat.com> <8daa7c35-1280-5822-d820-3bfe58d29241@redhat.com> <329CCBFE-ED75-4287-8DCC-E5DD4CB75BB1@azul.com> <0f5d213c-f479-b29f-33ca-057430ba6fec@redhat.com> <8451478a-8610-0460-9b09-43763e51d006@redhat.com> <3217278f-d7d9-7a8a-1506-904973b0976b@redhat.com> Message-ID: <274dbb9a-7fa5-cefe-1d84-421b2a643973@redhat.com> On 16/06/2020 05:22, Martin Balao wrote: snip... >> >> My suggestion would be to follow the JFR route: >> >> 1. Now: Setup a TLS incubator tree and apply the patches there. >> >> 2. Monday, August 24th, 2020: Decide whether to merge the incubator tree >> into 8u-dev before rampdown on Friday, 28th. >> >> 3. Assuming it is integrated, test TLS 1.3 in 8u272 during September. >> >> The benefits of this are: >> >> 1. You can handle the commit policy for the incubator (just reviews, no >> need for individual approvals) >> >> 2. One single approval can be used to merge TLS 1.3 in rampdown week. >> >> 3. Merging just before rampdown makes your proposal feasible, assuming >> low traffic during rampdown. > > I'm okay with this approach. > > Thanks, > Martin.- > I haven't seen anything further on this. Is this the approach being adopted? 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 zgu at redhat.com Wed Jul 8 17:48:15 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Jul 2020 13:48:15 -0400 Subject: [8u] RFR 8248924: JDK-8056964 8u backport is not accurate In-Reply-To: References: <787a465c-863b-5a31-d83b-7852f663765c@redhat.com> Message-ID: <5df7aab2-d750-50e6-aa37-33de18f30c04@redhat.com> On 7/8/20 11:37 AM, Andrew Hughes wrote: > > > On 07/07/2020 19:56, Zhengyu Gu wrote: >> Please review this small patch that fixes inaccurate backport of >> JDK-8056964. >> >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248924/webrev.00/ >> >> Test: >> ? tier1 on Linux 86_64 >> >> Thanks, >> >> -Zhengyu >> > > In what way is it not accurate? JDK-8056964 original patch uses os::strdup_check_oom() to copy value, but the backport converted to strdup(). There are a couple of differences between the two calls. 1) os::strdup_check_oom() memory is tracked by NMT 2) when fail to allocate memory, os::strdup_check_oom() results OOM and exit VM, while strdup() returns NULL. Thanks, -Zhengyu > > Thanks, > From zgu at redhat.com Wed Jul 8 17:56:39 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Jul 2020 13:56:39 -0400 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <0d844672-7127-d7fe-5765-cf87f13690ad@redhat.com> References: <0d844672-7127-d7fe-5765-cf87f13690ad@redhat.com> Message-ID: <6f52dd7f-c72a-1e28-29c9-48549f970242@redhat.com> Hi Andrew, > I already backported this: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011526.html > > In the end, we decided not to go ahead with this and workaround it for > JDK-8076475: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011539.html At that time, this was *not* a parity backport, but now, it is. Should we reconsider it? Thanks, -Zhengyu > > Thanks, > From zgu at redhat.com Wed Jul 8 18:10:26 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Jul 2020 14:10:26 -0400 Subject: [8u] RFR 8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate Message-ID: <5574400a-750f-155a-dfae-6c7f80dc8d90@redhat.com> I would like to backport this patch to 8u for parity with Oracle 8u271. The original patch does not apply cleanly. But the conflicts are minors: 1) Copyright line does not match. 2) Last block is under Universe::heap() != NULL check in 8u, while original version does not have such check. Original bug: https://bugs.openjdk.java.net/browse/JDK-8231779 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/fcbd54a2c2d9 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231779-8u/webrev.00/ Test: tier1 on Linux 86_64 Thanks, -Zhengyu From gnu.andrew at redhat.com Wed Jul 8 21:47:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Jul 2020 22:47:56 +0100 Subject: SunPKCS11 connection lost after Decrypt doFinal In-Reply-To: References: <115412fa-7001-feb3-b4d7-e92d64790792@redhat.com> <073918b1-75d1-305e-5054-c663aa360306@oracle.com> <14993a7d-4f12-35df-50b8-bc5d9b3e7a90@redhat.com> Message-ID: <6db875b2-399b-d8fa-8756-aee0a0ddb67d@redhat.com> On 08/07/2020 10:44, DEBORDEAUX Hubert wrote: > Hello, > Do you know when this fix will be available in JDK 8? > build 272 or higher? > Once available, we will be able to update our build pipeline and test it with our network HSMs. > > Thanks, > Regards, > Hubert > It'll be at least 8u272 as 8u262 is already in freeze for release. I'll look into it once that release is out of the way. 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 Jul 8 21:52:18 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Jul 2020 22:52:18 +0100 Subject: [8u] RFR 8248924: JDK-8056964 8u backport is not accurate In-Reply-To: <5df7aab2-d750-50e6-aa37-33de18f30c04@redhat.com> References: <787a465c-863b-5a31-d83b-7852f663765c@redhat.com> <5df7aab2-d750-50e6-aa37-33de18f30c04@redhat.com> Message-ID: <2810a1e7-064a-2528-f2e5-2d1db7e69318@redhat.com> On 08/07/2020 18:48, Zhengyu Gu wrote: > > > On 7/8/20 11:37 AM, Andrew Hughes wrote: >> >> >> On 07/07/2020 19:56, Zhengyu Gu wrote: >>> Please review this small patch that fixes inaccurate backport of >>> JDK-8056964. >>> >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8248924/webrev.00/ >>> >>> Test: >>> ?? tier1 on Linux 86_64 >>> >>> Thanks, >>> >>> -Zhengyu >>> >> >> In what way is it not accurate? > > JDK-8056964 original patch uses os::strdup_check_oom() to copy value, > but the backport converted to strdup(). > > There are a couple of differences between the two calls. > > 1) os::strdup_check_oom() memory is tracked by NMT > 2) when fail to allocate memory, os::strdup_check_oom() results OOM and > exit VM, while strdup() returns NULL. > > Thanks, > > -Zhengyu > Right. Well, it makes sense that it was changed, given strdup_check_oom doesn't currently exist in 8u i.e. this depends on the other backport you posted, JDK-6424123 being present first. There are a number of cases of these conversions (we did one for JDK-8076475, as I mentioned in the other thread, and I referred to ones for previous fixes in that review). I would consider reverting these conversions to be part of a backport of 6424123, rather than a separate fix i.e. such a backport should look at all instances of os::strdup to see if they need to be changed. It seems odd to file a bug for a method not being used, when said method does not currently exist in 8u. 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 Jul 8 21:53:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Jul 2020 22:53:42 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <6f52dd7f-c72a-1e28-29c9-48549f970242@redhat.com> References: <0d844672-7127-d7fe-5765-cf87f13690ad@redhat.com> <6f52dd7f-c72a-1e28-29c9-48549f970242@redhat.com> Message-ID: <639b6fc7-8eb3-0b2f-00c1-534c9fe13ee0@redhat.com> On 08/07/2020 18:56, Zhengyu Gu wrote: > Hi Andrew, > >> I already backported this: >> >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011526.html >> >> In the end, we decided not to go ahead with this and workaround it for >> JDK-8076475: >> >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011539.html > > At that time, this was *not* a parity backport, but now, it is. Should > we reconsider it? > > Thanks, > > -Zhengyu > >> >> Thanks, >> > To my mind, that doesn't really change anything from a technical standpoint, but I'll leave the final say to Andrew Haley. 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 zgu at redhat.com Thu Jul 9 00:00:58 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 8 Jul 2020 20:00:58 -0400 Subject: [8u] RFR 8248924: JDK-8056964 8u backport is not accurate In-Reply-To: <2810a1e7-064a-2528-f2e5-2d1db7e69318@redhat.com> References: <787a465c-863b-5a31-d83b-7852f663765c@redhat.com> <5df7aab2-d750-50e6-aa37-33de18f30c04@redhat.com> <2810a1e7-064a-2528-f2e5-2d1db7e69318@redhat.com> Message-ID: >> > > Right. Well, it makes sense that it was changed, given strdup_check_oom > doesn't currently exist in 8u i.e. this depends on the other backport > you posted, JDK-6424123 being > present first. > > There are a number of cases of these conversions (we did one for > JDK-8076475, as I mentioned in the other thread, and I referred to ones > for previous fixes in that review). I would consider reverting these > conversions to be part of a backport of 6424123, rather than a separate > fix i.e. such a backport should look at all instances of os::strdup to > see if they need to be changed. > > It seems odd to file a bug for a method not being used, when said method > does not currently exist in 8u. Yes, it has dependency on JDK-8248924. I was under impression that parity backport is pretty certain, unless it presents significant risk, which does not seem to be the case here. Thanks, -Zhengyu > > Thanks, > From gnu.andrew at redhat.com Thu Jul 9 03:02:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 9 Jul 2020 04:02:34 +0100 Subject: [8u] RFR 8151834: Test SmallPrimeExponentP.java times out intermittently In-Reply-To: <7201b370-802b-986f-599e-c97dd101313c@redhat.com> References: <7201b370-802b-986f-599e-c97dd101313c@redhat.com> Message-ID: <1fef4dca-5cb2-d14f-d08b-93e494f40672@redhat.com> On 20/04/2020 21:24, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 8151834 [1]. This > backport would bring parity with Oracle's JDK. Risk is minimal as only a > test is affected. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8151834/8151834.webrev.jdk8u.jdk.00/ > > Main line patch does not apply cleanly because: > > * test/sun/security/mscapi/SmallPrimeExponentP.java > * 3rd hook > * 8u does not have "@key intermittent" line added by 8151835 [2] [3] > * backporting 8151835 is not necessary because "@key intermittent" > will be removed by 8151834 (it was added to make clear that the test was > intermittently failing, and that's what's being fixed) > * "@modules java.base/sun.security.x509" and > "java.base/sun.security.tools.keytool" lines were not available in 8u > because the test was not modules-aware. It won't be modules-aware > anyways but these lines (which will be added by 8151834) are harmless. > > Testing: > > * test/sun/security/mscapi/SmallPrimeExponentP.java > * Passed (tested on Windows) > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8151834 > [2] - https://bugs.openjdk.java.net/browse/JDK-8151835 > [3] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/927f20de2cc1 > I agree it would be ridiculous to backport JDK-8151835, just to remove it again with this backport :-) I would omit the @modules lines. It makes no sense to add them to 8u. Otherwise, looks good. 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 Thu Jul 9 03:07:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 9 Jul 2020 04:07:42 +0100 Subject: [8u] RFR 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one In-Reply-To: <813dd8da-18ed-cdc1-c82a-185f3395890e@redhat.com> References: <813dd8da-18ed-cdc1-c82a-185f3395890e@redhat.com> Message-ID: <4bc25a43-7418-9657-d631-6337a2484424@redhat.com> On 21/04/2020 20:49, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of 8241888 [1]. For > further information on why it's desirable to have this in JDK-8, have a > look at the 8u-CSR [2] (already approved). > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8241888/8241888.webrev.jdk8u.jdk.00/ > > Main line patch does not apply cleanly because we need to propagate > java.security change across all java.security-os files. There is nothing > OS-specific in 8241888 so this change applies to all of them. > > Testing: > > * Tests in sun/security/validator passed. > * Executed my own internal test to make sure that both the Security > property and the replacement of the System property work fine > * Note: no new tests have been proposed as part of the main line patch > because it's a trivial change and SecurityProperties functionality > (basis for this patch) is already covered by tests. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8241888 > [2] - https://bugs.openjdk.java.net/browse/JDK-8243285 > Looks good to me. Identical to 11u, except that the java.security change is duplicated for the multiple variants in 8u. 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 aph at redhat.com Thu Jul 9 07:43:44 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Jul 2020 08:43:44 +0100 Subject: VS2010 end of support July2020 In-Reply-To: References: Message-ID: <8b2776eb-e9d3-271d-167e-e739bc54387f@redhat.com> On 07/07/2020 16:13, Andrew Leonard wrote: > I notice from the Microsoft VS support page : > https://docs.microsoft.com/en-us/visualstudio/releases/2019/servicing > that VS2010 is out of support this month? > Is there plans to support VS2017 for jdk8, I don't see any obvious bug > stating that? I haven't seen anything. We'll have to add it to our TODO list. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu Jul 9 16:46:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 9 Jul 2020 17:46:22 +0100 Subject: [RFR] [8u262] New JavaTimeSupplementary localisation for 'in' installed in wrong package Message-ID: <1981bc13-54f4-3b6d-81a7-933db7ef24db@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8248715 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8248715/webrev.01/ When JavaTimeSupplementary_in.java was backported to 8u in JDK-8244843, the package was not altered to match the 8u system of sun.text.resources.${locale}. Thus, it ends up in sun.text.resources.ext instead. This, in turn, means it ends up alone in rt.jar, while other locale data is filtered into ext/localedata.jar. The fix is simple. Once reviewed, I intend to also include this in the CPU patch set for 8u262 GA. 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 Thu Jul 9 17:02:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 09 Jul 2020 19:02:45 +0200 Subject: [RFR] [8u262] New JavaTimeSupplementary localisation for 'in' installed in wrong package In-Reply-To: <1981bc13-54f4-3b6d-81a7-933db7ef24db@redhat.com> References: <1981bc13-54f4-3b6d-81a7-933db7ef24db@redhat.com> Message-ID: <5ece2f1fd500a899b10f1f8e95f31cd96217c5e2.camel@redhat.com> On Thu, 2020-07-09 at 17:46 +0100, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248715 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8248715/webrev.01/ Looks good to me. Incidentally I've had the same patch myself but didn't yet post if for review. All the better, I've closed JDK-8248867 as a duplicate. > When JavaTimeSupplementary_in.java was backported to 8u in JDK-8244843, > the package was not altered to match the 8u system of > sun.text.resources.${locale}. Thus, it ends up in sun.text.resources.ext > instead. > > This, in turn, means it ends up alone in rt.jar, while other locale data > is filtered into ext/localedata.jar. > > The fix is simple. Once reviewed, I intend to also include this in the > CPU patch set for 8u262 GA. Sounds good. Thanks, Severin From gnu.andrew at redhat.com Thu Jul 9 17:12:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 9 Jul 2020 18:12:35 +0100 Subject: [RFR] [8u262] New JavaTimeSupplementary localisation for 'in' installed in wrong package In-Reply-To: <5ece2f1fd500a899b10f1f8e95f31cd96217c5e2.camel@redhat.com> References: <1981bc13-54f4-3b6d-81a7-933db7ef24db@redhat.com> <5ece2f1fd500a899b10f1f8e95f31cd96217c5e2.camel@redhat.com> Message-ID: <843b285a-f087-97c0-3470-0106a046d0a7@redhat.com> On 09/07/2020 18:02, Severin Gehwolf wrote: > On Thu, 2020-07-09 at 17:46 +0100, Andrew Hughes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8248715 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8248715/webrev.01/ > > Looks good to me. > > Incidentally I've had the same patch myself but didn't yet post if for > review. All the better, I've closed JDK-8248867 as a duplicate. > Yes, I've been distracted from posting mine for nearly a week... It was even uploaded, I just never wrote the e-mail. >> When JavaTimeSupplementary_in.java was backported to 8u in JDK-8244843, >> the package was not altered to match the 8u system of >> sun.text.resources.${locale}. Thus, it ends up in sun.text.resources.ext >> instead. >> >> This, in turn, means it ends up alone in rt.jar, while other locale data >> is filtered into ext/localedata.jar. >> >> The fix is simple. Once reviewed, I intend to also include this in the >> CPU patch set for 8u262 GA. > > Sounds good. > Thanks. > Thanks, > Severin > -- 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 zgu at redhat.com Thu Jul 9 20:38:08 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 9 Jul 2020 16:38:08 -0400 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: <03a72153-58ac-4c26-55a7-f09fa25c63d7@redhat.com> Hi, I would like to backport this patch to 8u for parity with Oracle 8u261. The original patch does not apply cleanly. Other than a couple of minor conflicts: 1) Comments in InitialDirContext.java did not apply cleanly 2) Unpatched CheckConfigs.policy files did not match I made following modification for 8u: 1) Removed module-info.java section, it does not apply to 8u. 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the code with ArrayList. 3) Removed @modules annotation in LdapDnsProviderTest.java Additional, I need to modify langtools to get javac to take com.sun.jndi.ldap.spi package and complain about it. Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ 8u langtools webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ Test: jdk_other on Linux x86_64 Thanks, -Zhengyu From felix.yang at huawei.com Fri Jul 10 11:43:54 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 10 Jul 2020 11:43:54 +0000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Wednesday, July 8, 2020 5:48 PM > To: Kim Barrett ; Yangfei (Felix) > > Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > fences between free chunk check and klass read > > On 08/07/2020 09:41, Kim Barrett wrote: > >> Since CMS is deprecated from JDK9, I am not sure if it's appropriate to fix > this issue for those JDK9+ versions. > > Deprecated != unsupported. > > > > Yes, it must be done. Thanks. CCing to jdk-updates-dev. I have prepared another two webrevs for jdk11u and jdk13u: Jdk11u-dev: http://cr.openjdk.java.net/~fyang/8248851-11u/ Jdk13u-dev: http://cr.openjdk.java.net/~fyang/8248851-13u/ The only difference lies in copyright year update. Both tiere1-3 tested on aarch64-linux-gnu. I will put jdk11u-fix-request and jdk13u-fix-request label on the issue if they are good. I have also prepared a new webrev for jdk8u incorporating copyright year update: Jdk8u-dev: http://cr.openjdk.java.net/~fyang/8248851-8u/ Thanks, Felix From Martijn.Verburg at microsoft.com Fri Jul 10 21:04:52 2020 From: Martijn.Verburg at microsoft.com (Martijn Verburg) Date: Fri, 10 Jul 2020 21:04:52 +0000 Subject: [EXTERNAL] Re: VS2010 end of support July2020 In-Reply-To: <8b2776eb-e9d3-271d-167e-e739bc54387f@redhat.com> References: , <8b2776eb-e9d3-271d-167e-e739bc54387f@redhat.com> Message-ID: Hi Andrew(s), We intend on helping here, let me know if there's a bug ID or place we should collaborate. (I've CC'd Derek Keeler (our build/infra lead) into this thread so we can coordinate). Cheers, Martijn ________________________________ From: jdk8u-dev on behalf of Andrew Haley Sent: Thursday, July 9, 2020 08:43 To: Andrew Leonard ; jdk8u-dev at openjdk.java.net Subject: [EXTERNAL] Re: VS2010 end of support July2020 On 07/07/2020 16:13, Andrew Leonard wrote: > I notice from the Microsoft VS support page : > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fvisualstudio%2Freleases%2F2019%2Fservicing&data=02%7C01%7Cmartijn.verburg%40microsoft.com%7C6726ab2b3207474767a308d823dc2ba7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298775821932388&sdata=lY9drI759xazDAQLQaC93FwmwA9GRZdurJgiPGQt5Qs%3D&reserved=0 > that VS2010 is out of support this month? > Is there plans to support VS2017 for jdk8, I don't see any obvious bug > stating that? I haven't seen anything. We'll have to add it to our TODO list. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cmartijn.verburg%40microsoft.com%7C6726ab2b3207474767a308d823dc2ba7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637298775821932388&sdata=LstbU5grwKcwbiddcR%2BKUdnkpJLG0b8mkCXE6KkQ5%2Fw%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Fri Jul 10 23:51:03 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 10 Jul 2020 23:51:03 +0000 Subject: RFR (M): 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double Message-ID: <0FDFDF99-CDA7-4356-A57C-4460AAB86C87@amazon.com> Please review a proposed backport from jdk9 to jdk8u that fixes a serviceability issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8061616 Original jdk patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd Original hotspot patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1bac07f399ac jdk webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.jdk.01/ hotspot webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.hotspot.01/ Other than a few context and copyright date differences, the only change is testing InitialRAMPercentage rather than CompileThresholdScaling. The latter doesn?t exist in jdk8. Passed: jdk/ test/com/sun/management/HotSpotDiagnosticMXBean hotspot/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java Thanks, Paul From zgu at redhat.com Mon Jul 13 16:07:46 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 13 Jul 2020 12:07:46 -0400 Subject: [8u] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: <2839b24f-a29c-3f4a-edef-97a9ac3bc06a@redhat.com> References: <2839b24f-a29c-3f4a-edef-97a9ac3bc06a@redhat.com> Message-ID: <0de21e03-72db-cf4f-3217-e7c105e7d243@redhat.com> On 6/29/20 3:55 PM, Zhengyu Gu wrote: > Hi, > > I would like to backport this patch to 8u for Oracle 8u271 parity. > > The original patch does not apply cleanly. > > LdapCtx.java: > 8u does not have 'reconnect' member, so removing the variable lines do > not apply. > > Reconnect.java: > Uses try-catch-with-resource statement, which does not exist in 8u. > Converted to try-catch-finally. try-with-resource here works find. Updated: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.01/ Thanks, -Zhengyu > Uses 'var' language feature, which does not exist in 8u. Converted > accordingly. > > BaseLdapServer.java: > The same issues as Reconnect.java, fixed accordingly. > Uses System.Logger, which does not exist in 8u. Converted to > java.util.logging.Logger. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8217606 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.00/ > > Test: > ? test/com/sun/jndi/ldap/LdapCtx/Reconnect.java > > Thanks, > > -Zhengyu > > > > From hohensee at amazon.com Mon Jul 13 17:19:37 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 13 Jul 2020 17:19:37 +0000 Subject: [8u] 8217606: LdapContext#reconnect always opens a new connection Message-ID: <8867F36A-8DE6-4138-8FAC-044C2F60E3BE@amazon.com> There's an extra blank line in your version just before the try/catch, and looks like you added a finally clause in BaseLdapServer.handleConnection(). The latter is a good reliability addition, but I'd fix it in upstream and backport it separately. Thanks, Paul ?On 7/13/20, 9:11 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: On 6/29/20 3:55 PM, Zhengyu Gu wrote: > Hi, > > I would like to backport this patch to 8u for Oracle 8u271 parity. > > The original patch does not apply cleanly. > > LdapCtx.java: > 8u does not have 'reconnect' member, so removing the variable lines do > not apply. > > Reconnect.java: > Uses try-catch-with-resource statement, which does not exist in 8u. > Converted to try-catch-finally. try-with-resource here works find. Updated: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.01/ Thanks, -Zhengyu > Uses 'var' language feature, which does not exist in 8u. Converted > accordingly. > > BaseLdapServer.java: > The same issues as Reconnect.java, fixed accordingly. > Uses System.Logger, which does not exist in 8u. Converted to > java.util.logging.Logger. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8217606 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.00/ > > Test: > test/com/sun/jndi/ldap/LdapCtx/Reconnect.java > > Thanks, > > -Zhengyu > > > > From zgu at redhat.com Mon Jul 13 18:02:02 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 13 Jul 2020 14:02:02 -0400 Subject: [8u] 8217606: LdapContext#reconnect always opens a new connection In-Reply-To: <8867F36A-8DE6-4138-8FAC-044C2F60E3BE@amazon.com> References: <8867F36A-8DE6-4138-8FAC-044C2F60E3BE@amazon.com> Message-ID: Hi Paul, Thanks for reviewing. On 7/13/20 1:19 PM, Hohensee, Paul wrote: > There's an extra blank line in your version just before the try/catch, Fixed. and looks like you added a finally clause in BaseLdapServer.handleConnection(). Original version has: ... // automatically when `socket.close()` is called beforeConnectionHandled(socket); try (socket) { OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream(); byte[] inBuffer = new byte[1024]; ... 8u complains about: try(socket), I converted to try/catch/finally. So, it is not a new addition. updated: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.02/ Thanks, -Zhengyu The latter is a good reliability addition, but I'd fix it in upstream and backport it separately. > > Thanks, > Paul > > ?On 7/13/20, 9:11 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > On 6/29/20 3:55 PM, Zhengyu Gu wrote: > > Hi, > > > > I would like to backport this patch to 8u for Oracle 8u271 parity. > > > > The original patch does not apply cleanly. > > > > LdapCtx.java: > > 8u does not have 'reconnect' member, so removing the variable lines do > > not apply. > > > > Reconnect.java: > > Uses try-catch-with-resource statement, which does not exist in 8u. > > Converted to try-catch-finally. > try-with-resource here works find. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.01/ > > Thanks, > > -Zhengyu > > > Uses 'var' language feature, which does not exist in 8u. Converted > > accordingly. > > > > BaseLdapServer.java: > > The same issues as Reconnect.java, fixed accordingly. > > Uses System.Logger, which does not exist in 8u. Converted to > > java.util.logging.Logger. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8217606 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 > > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.00/ > > > > Test: > > test/com/sun/jndi/ldap/LdapCtx/Reconnect.java > > > > Thanks, > > > > -Zhengyu > > > > > > > > > > From hohensee at amazon.com Mon Jul 13 20:51:17 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 13 Jul 2020 20:51:17 +0000 Subject: [8u] 8217606: LdapContext#reconnect always opens a new connection Message-ID: <7B1F637E-3DCC-42DA-8437-71A87CC10C0F@amazon.com> You're right, my bad. I'd forgot that try-with-resources will close its argument if necessary, so http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.01/ is correct. Thanks, Paul ?On 7/13/20, 11:06 AM, "Zhengyu Gu" wrote: Hi Paul, Thanks for reviewing. On 7/13/20 1:19 PM, Hohensee, Paul wrote: > There's an extra blank line in your version just before the try/catch, Fixed. and looks like you added a finally clause in BaseLdapServer.handleConnection(). Original version has: ... // automatically when `socket.close()` is called beforeConnectionHandled(socket); try (socket) { OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream(); byte[] inBuffer = new byte[1024]; ... 8u complains about: try(socket), I converted to try/catch/finally. So, it is not a new addition. updated: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.02/ Thanks, -Zhengyu The latter is a good reliability addition, but I'd fix it in upstream and backport it separately. > > Thanks, > Paul > > On 7/13/20, 9:11 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: > > On 6/29/20 3:55 PM, Zhengyu Gu wrote: > > Hi, > > > > I would like to backport this patch to 8u for Oracle 8u271 parity. > > > > The original patch does not apply cleanly. > > > > LdapCtx.java: > > 8u does not have 'reconnect' member, so removing the variable lines do > > not apply. > > > > Reconnect.java: > > Uses try-catch-with-resource statement, which does not exist in 8u. > > Converted to try-catch-finally. > try-with-resource here works find. > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.01/ > > Thanks, > > -Zhengyu > > > Uses 'var' language feature, which does not exist in 8u. Converted > > accordingly. > > > > BaseLdapServer.java: > > The same issues as Reconnect.java, fixed accordingly. > > Uses System.Logger, which does not exist in 8u. Converted to > > java.util.logging.Logger. > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8217606 > > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 > > > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8217606-8u/webrev.00/ > > > > Test: > > test/com/sun/jndi/ldap/LdapCtx/Reconnect.java > > > > Thanks, > > > > -Zhengyu > > > > > > > > > > From hohensee at amazon.com Mon Jul 13 21:27:37 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 13 Jul 2020 21:27:37 +0000 Subject: [8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider Message-ID: <30EE84DA-76C1-4A33-95FA-18D57117E2E1@amazon.com> The webrev looks it's corrupted. E.g., it includes the changes from 8217606, and not the InitialDirContext.java and CheckConfigs.policy changes you mention. Paul ?On 7/9/20, 1:39 PM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: Hi, I would like to backport this patch to 8u for parity with Oracle 8u261. The original patch does not apply cleanly. Other than a couple of minor conflicts: 1) Comments in InitialDirContext.java did not apply cleanly 2) Unpatched CheckConfigs.policy files did not match I made following modification for 8u: 1) Removed module-info.java section, it does not apply to 8u. 2) LdapDnsProvider.java and LdapDnsProviderResult.java use APIs (List.copyOf() and List.of()) that do not exist in jdk8. Rewrote the code with ArrayList. 3) Removed @modules annotation in LdapDnsProviderTest.java Additional, I need to modify langtools to get javac to take com.sun.jndi.ldap.spi package and complain about it. Original bug: https://bugs.openjdk.java.net/browse/JDK-8160768 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a 8u jdk webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/jdk/webrev.00/ 8u langtools webrev: http://cr.openjdk.java.net/~zgu/JDK-8160768-8u/langtools/webev.00/ Test: jdk_other on Linux x86_64 Thanks, -Zhengyu From jdowland at redhat.com Mon Jul 13 21:46:27 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Mon, 13 Jul 2020 22:46:27 +0100 Subject: [8u] RFR: 8226697: Several tests which need the @key headful keyword are missing it. Message-ID: <20200713214627.y2xw3lju3sce52co@qusp> Hello Please review this backport of JDK-8226697 to 8u (my first): Bug: https://bugs.openjdk.java.net/browse/JDK-8226697 (why is it marked resolved? I can't find it applied to jdk8u or jdk8u-dev) jdk change: https://hg.openjdk.java.net/jdk/jdk/rev/e7671524d4e2 8u patch: attached (if you would prefer a webrev please ask) Best wishes -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: 8226697_jdk8u.patch Type: text/x-diff Size: 1671 bytes Desc: not available URL: From zgu at redhat.com Tue Jul 14 12:47:53 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Jul 2020 08:47:53 -0400 Subject: [8u] RFR 8243138: Enhance BaseLdapServer to support starttls extended request Message-ID: <44430764-4423-ac3b-1566-bbd77eb06c2a@redhat.com> I would like to backport this patch for parity with Oracle 8u271. The original patch does not apply cleanly, but conflicts are minors [1]. 1) JDK-8217606 backport converted jdk9 style try-with-resource to try-catch-finally, that caused the first conflict. 2) jdk8 does not support 'var' language feature. Original bug: https://bugs.openjdk.java.net/browse/JDK-8243138 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/df5a2fb15971 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8243138-8u/webrev.00/ Test: jdk_other Thanks, -Zhengyu [1] diff -r 19be2797f698 -r a78123a1f329 test/com/sun/jndi/ldap/lib/BaseLdapServer.java --- a/test/com/sun/jndi/ldap/lib/BaseLdapServer.java Thu Apr 23 16:36:05 2020 +0800 +++ b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java Tue Jun 30 10:37:07 2020 -0400 @@ -119,6 +119,7 @@ // No need to close socket's streams separately, they will be closed // automatically when `socket.close()` is called beforeConnectionHandled(socket); + ConnWrapper connWrapper = new ConnWrapper(socket); try { OutputStream out = socket.getOutputStream(); InputStream in = socket.getInputStream(); @@ -154,7 +155,7 @@ } handleRequestEx(socket, new LdapMessage(request), out, connWrapper); if (connWrapper.updateRequired()) { - var wrapper = connWrapper.getWrapper(); + Socket wrapper = connWrapper.getWrapper(); in = wrapper.getInputStream(); out = wrapper.getOutputStream(); connWrapper.clearFlag(); From zgu at redhat.com Tue Jul 14 13:53:55 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Jul 2020 09:53:55 -0400 Subject: [8u] RFR: 8226697: Several tests which need the @key headful keyword are missing it. In-Reply-To: <20200713214627.y2xw3lju3sce52co@qusp> References: <20200713214627.y2xw3lju3sce52co@qusp> Message-ID: Backport looks good. -Zhengyu On 7/13/20 5:46 PM, Jonathan Dowland wrote: > Hello > > Please review this backport of JDK-8226697 to 8u (my first): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226697 > (why is it marked resolved? I can't find it applied to jdk8u > or jdk8u-dev) > > jdk change: https://hg.openjdk.java.net/jdk/jdk/rev/e7671524d4e2 > > 8u patch: attached (if you would prefer a webrev please ask) > > > Best wishes > From sgehwolf at redhat.com Tue Jul 14 14:09:29 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 14 Jul 2020 16:09:29 +0200 Subject: [8u] RFR: 8226697: Several tests which need the @key headful keyword are missing it. In-Reply-To: <20200713214627.y2xw3lju3sce52co@qusp> References: <20200713214627.y2xw3lju3sce52co@qusp> Message-ID: <5d1d6c3e427df389513db533dee2857e8f0a5406.camel@redhat.com> Hi Jon, On Mon, 2020-07-13 at 22:46 +0100, Jonathan Dowland wrote: > Hello > > Please review this backport of JDK-8226697 to 8u (my first): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226697 > (why is it marked resolved? I can't find it applied to jdk8u > or jdk8u-dev) It's marked resolved for JDK 14 (the JDK development version at the time). Backport bugs show up via "Backports" links. In all cases, "Fix Version" is an important field. For OpenJDK 11 backports there is - in this case - 11.0.9-oracle and 11.0.9. The former is for OpenJDK 11u, the latter is for Oracle JDK which doesn't show the commits publicly. For OpenJDK 8 the versions are, for example, 8u271 and openjdk8u272. The former is for Oracle JDK 8 (again no public commits) and the latter for OpenJDK 8u. Since there is no backport bug with Fix Version openjdk8uXXX, it's not fixed in OpenJDK 8u (yet). > jdk change: https://hg.openjdk.java.net/jdk/jdk/rev/e7671524d4e2 > > 8u patch: attached (if you would prefer a webrev please ask) The patch looks good. Next time, please explain whether the JDK 14 patch applied cleanly (after changing the paths to files) and/or what modifications you had to do to make it apply. That's helpful for reviewing the patch. Note that if it applies cleanly it might be that you wouldn't need a review (just the appropriate label in Jira). Thanks, Severin From jdowland at redhat.com Tue Jul 14 14:50:07 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Tue, 14 Jul 2020 15:50:07 +0100 Subject: [8u] RFR: 6574989: TEST_BUG: javax/sound/sampled/Clip/bug5070081.java fails sometimes Message-ID: <20200714145007.qf6g54wworbr54df@qusp> Hello, Please review this "backport" of JDK-6574989 to 8u, for parity with Oracle 8u271. Bug: https://bugs.openjdk.java.net/browse/JDK-6574989 jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/0f4994564ae6 webrev (I needed the practice generating one): https://jmtd.net/tmp/JDK-6574989/ The patch applies cleanly to jdk8u-dev without path changes, and the test builds and runs post patching with java(1) built from jdk8u-dev, so I suppose label jdk8u-fix-request is sufficient? However, on my system (Linux/amd64; the original report description states "fails sometimes on windows platforms"), both pre and post patch, the test consistently fails. I'm not sure whether that warrants further investigation, or whether that should block backporting the patch. Thank you, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From gnu.andrew at redhat.com Tue Jul 14 16:33:47 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 14 Jul 2020 17:33:47 +0100 Subject: [RFR] jdk8u262-b10 Message-ID: Here are the jdk8u262-b10 changes (the security patches) for the jdk8u repository: Webrevs: https://cr.openjdk.java.net/~andrew/openjdk8/8u262/ jdk8u262-b10 is also tagged as jdk8u262-ga. Changes in jdk8u262-b10: - JDK-8230613: Better ASCII conversions - JDK-8231800: Better listing of arrays - JDK-8232014: Expand DTD support - JDK-8233255: Better Swing Buttons - JDK-8234032: Improve basic calendar services - JDK-8234042: Better factory production of certificates - JDK-8234418: Better parsing with CertificateFactory - JDK-8234836: Improve serialization handling - JDK-8236191: Enhance OID processing - JDK-8237117: Better ForkJoinPool behavior - JDK-8237592: Enhance certificate verification - JDK-8238002: Better matrix operations - JDK-8238804: Enhance key handling process - JDK-8238843: Enhanced font handing - JDK-8238920: Better Buffer support - JDK-8238925: Enhance WAV file playback - JDK-8240119: Less Affine Transformations - JDK-8240482: Improved WAV file playback - JDK-8241379: Update JCEKS support - JDK-8241522: Manifest improved jar headers redux - JDK-8242136: Better XML namespace handling - JDK-8248715: New JavaTimeSupplementary localisation for 'in' installed in wrong package Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Tue Jul 14 16:47:05 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Jul 2020 18:47:05 +0200 Subject: [RFR] jdk8u262-b10 In-Reply-To: References: Message-ID: <429070a2-1e47-9553-ba6f-63195ec19910@redhat.com> On 7/14/20 6:33 PM, Andrew Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/openjdk8/8u262/ corba: hotspot: jaxws: langtools: nashorn: root: Looks trivial and good. jaxp: Looks good. jdk: *) Not sure what the change in make/lib/Awt2dLibraries.gmk is. Does it really relate to 8238002: Better matrix operations? > Ok to push? Yes, except the jdk thing above. -- Thanks, -Aleksey From zgu at redhat.com Tue Jul 14 16:51:10 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Jul 2020 12:51:10 -0400 Subject: [8u] RFR 8047765: Generate blacklist.certs in build Message-ID: I would like to backport this patch to 8u, for parity with Oracle 8u271. The original patch does not apply cleanly. Only conflicts were failing to remove following two files: BlacklistedCertsConverter.java blacklisted.certs.pem Original bug: https://bugs.openjdk.java.net/browse/JDK-8047765 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fd7630919a9d 8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8047765-8u/weberv.00/ Test: jdk_security Thanks, -Zhengyu From gnu.andrew at redhat.com Tue Jul 14 16:54:23 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 14 Jul 2020 17:54:23 +0100 Subject: [RFR] jdk8u262-b10 In-Reply-To: <429070a2-1e47-9553-ba6f-63195ec19910@redhat.com> References: <429070a2-1e47-9553-ba6f-63195ec19910@redhat.com> Message-ID: On 14/07/2020 17:47, Aleksey Shipilev wrote: > On 7/14/20 6:33 PM, Andrew Hughes wrote: >> Webrevs: https://cr.openjdk.java.net/~andrew/openjdk8/8u262/ > > corba: > hotspot: > jaxws: > langtools: > nashorn: > root: > Looks trivial and good. > > jaxp: > Looks good. > > jdk: > > *) Not sure what the change in make/lib/Awt2dLibraries.gmk is. Does it really relate to 8238002: > Better matrix operations? > >> Ok to push? > > Yes, except the jdk thing above. > Ha, I didn't think you were around to do the review... :P The jdk thing should be fixed now, dirty local repo I'm afraid from building our RPMs (Severin caught it on IRC) 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 shade at redhat.com Tue Jul 14 17:01:56 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Jul 2020 19:01:56 +0200 Subject: [RFR] jdk8u262-b10 In-Reply-To: References: <429070a2-1e47-9553-ba6f-63195ec19910@redhat.com> Message-ID: On 7/14/20 6:54 PM, Andrew Hughes wrote: >> jdk: >> >> *) Not sure what the change in make/lib/Awt2dLibraries.gmk is. Does it really relate to 8238002: >> Better matrix operations? >> >>> Ok to push? >> >> Yes, except the jdk thing above. >> > The jdk thing should be fixed now, dirty local repo I'm afraid from > building our RPMs (Severin caught it on IRC) Either way it is fine, as long we know that hunk should / shouldn't go in. -- Thanks, -Aleksey From gnu.andrew at redhat.com Tue Jul 14 17:09:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 14 Jul 2020 18:09:39 +0100 Subject: [RFR] jdk8u262-b10 In-Reply-To: References: <429070a2-1e47-9553-ba6f-63195ec19910@redhat.com> Message-ID: <7f534ef9-b6c6-1bde-87e1-9870884e8b85@redhat.com> On 14/07/2020 18:01, Aleksey Shipilev wrote: > On 7/14/20 6:54 PM, Andrew Hughes wrote: >>> jdk: >>> >>> *) Not sure what the change in make/lib/Awt2dLibraries.gmk is. Does it really relate to 8238002: >>> Better matrix operations? >>> >>>> Ok to push? >>> >>> Yes, except the jdk thing above. >>> >> The jdk thing should be fixed now, dirty local repo I'm afraid from >> building our RPMs (Severin caught it on IRC) > > Either way it is fine, as long we know that hunk should / shouldn't go in. > It's gone. For now. I'll finally try and get that (system LCMS support) in 8u separately after this CPU is over. It conflicted with the CPU changes, so I had to redo the backport in the RPM :/ 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 Tue Jul 14 17:10:57 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 14 Jul 2020 18:10:57 +0100 Subject: [8u] RFR 8047765: Generate blacklist.certs in build In-Reply-To: References: Message-ID: <513ad5e9-bc66-29b4-e488-d382319f28a2@redhat.com> On 14/07/2020 17:51, Zhengyu Gu wrote: > I would like to backport this patch to 8u, for parity with Oracle 8u271. > > The original patch does not apply cleanly. Only conflicts were failing > to remove following two files: > > BlacklistedCertsConverter.java > blacklisted.certs.pem > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8047765 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fd7630919a9d > > 8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8047765-8u/weberv.00/ > > Test: > ?jdk_security > > Thanks, > > -Zhengyu > I was looking at this one when we added keystore generation, but decided the backport wasn't worth the trouble. No real reason not to do it though. It shouldn't be a removal of those files, but a move; only src/share/lib/security/blacklisted.certs is actually removed. Is it possible to attach a 'hg diff --git' of this patch to check this is correct? The webrev version doesn't do that. $ grep 'rename' 8047765.11u rename from jdk/src/share/lib/security/blacklisted.certs.pem rename to jdk/make/data/blacklistedcertsconverter/blacklisted.certs.pem rename from jdk/src/share/lib/security/BlacklistedCertsConverter.java rename to jdk/make/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java 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 mbalao at redhat.com Tue Jul 14 17:12:41 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 14 Jul 2020 14:12:41 -0300 Subject: [RFR] jdk8u262-b10 In-Reply-To: References: Message-ID: On Tue, Jul 14, 2020 at 1:36 PM Andrew Hughes wrote: > Changes in jdk8u262-b10: > - JDK-8230613: Better ASCII conversions > - JDK-8231800: Better listing of arrays > - JDK-8232014: Expand DTD support > - JDK-8233255: Better Swing Buttons > - JDK-8234032: Improve basic calendar services > - JDK-8234042: Better factory production of certificates > - JDK-8234418: Better parsing with CertificateFactory > - JDK-8234836: Improve serialization handling > - JDK-8236191: Enhance OID processing > - JDK-8237117: Better ForkJoinPool behavior > - JDK-8237592: Enhance certificate verification > - JDK-8238002: Better matrix operations > - JDK-8238804: Enhance key handling process > - JDK-8238843: Enhanced font handing > - JDK-8238920: Better Buffer support > - JDK-8238925: Enhance WAV file playback > - JDK-8240119: Less Affine Transformations > - JDK-8240482: Improved WAV file playback > - JDK-8241379: Update JCEKS support > - JDK-8241522: Manifest improved jar headers redux > - JDK-8242136: Better XML namespace handling > - JDK-8248715: New JavaTimeSupplementary localisation for 'in' > installed in wrong package I've reviewed the 8u backports of these bugs separately -in the context of the VG- and they look good to me. From zgu at redhat.com Tue Jul 14 18:14:50 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 14 Jul 2020 14:14:50 -0400 Subject: [8u] RFR 8047765: Generate blacklist.certs in build In-Reply-To: <513ad5e9-bc66-29b4-e488-d382319f28a2@redhat.com> References: <513ad5e9-bc66-29b4-e488-d382319f28a2@redhat.com> Message-ID: <9015eb9a-7f6b-50f4-8cb8-dc3dbc471f5b@redhat.com> Hi Andrew, > > I was looking at this one when we added keystore generation, but decided > the backport wasn't worth the trouble. No real reason not to do it though. > > It shouldn't be a removal of those files, but a move; only > src/share/lib/security/blacklisted.certs is actually removed. > > Is it possible to attach a 'hg diff --git' of this patch to check this > is correct? The webrev version doesn't do that.I downloaded patch from http://hg.openjdk.java.net/jdk9/jdk9/jdk/raw-rev/fd7630919a9d. Apparently, it converted renaming to deleting and adding. Exported the patch from jdk9u directly. Updated: http://cr.openjdk.java.net/~zgu/JDK-8047765-8u/webrev.01/ > > $ grep 'rename' 8047765.11u > rename from jdk/src/share/lib/security/blacklisted.certs.pem > rename to jdk/make/data/blacklistedcertsconverter/blacklisted.certs.pem > rename from jdk/src/share/lib/security/BlacklistedCertsConverter.java > rename to > jdk/make/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java [zgu at localhost patches]$ grep 'rename' JDK-8047765-blacklist_certs rename from src/share/lib/security/blacklisted.certs.pem rename to make/data/blacklistedcertsconverter/blacklisted.certs.pem rename from src/share/lib/security/BlacklistedCertsConverter.java rename to make/src/classes/build/tools/blacklistedcertsconverter/BlacklistedCertsConverter.java Thanks, -Zhengyu > > Thanks, > From mbalao at redhat.com Wed Jul 15 00:28:49 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 14 Jul 2020 21:28:49 -0300 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> Message-ID: <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> On 7/6/20 5:45 PM, Martin Balao wrote: > > Oh, good point! Hmm... let me give this some more thought, because I > still find it confusing. > Hi, I'd like to propose Webrev.02: * http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.02/ Diff between Webrev.01 and Webrev.02: * http://cr.openjdk.java.net/~mbalao/webrevs/8245474/v2.patch The main driver behind Webrev.02 was to align the Kerberos Key Exchange implementation to the new TLS engine, while addressing the Java 8 SE Embedded compatibility concerns you raised in response to my previous Webrev.00 comments. Other improvements were also included as part of this change. For reviewing purposes, I suggest to apply a 'new implementation' approach instead of trying to track changes to old TLS-Kerberos vestiges. The most relevant classes in the new design are: * KrbClientKeyExchange::KrbClientKeyExchangeProducer * Used by TLS clients to produce a Kerberos Client Key Exchange message, which contains the encrypted pre-master key for a TLS server. Encryption is done with the Kerberos ticket session key. * This class is analogous to RSAClientKeyExchange::RSAClientKeyExchangeProducer * KrbClientKeyExchange::KrbClientKeyExchangeConsumer * Used by TLS servers to receive a Kerberos Client Key Exchange message, which contains the encrypted pre-master key from a TLS client. Decryption is done with the Kerberos ticket session key. * This class is analogous to RSAClientKeyExchange::RSAClientKeyExchangeConsumer * KrbClientKeyExchange::KrbClientKeyExchangeMessage * Kerberos Client Key Exchange message, used by the TLS client to create a new message and by the TLS server to decode a message coming from the network stream. * Messages have information such as the encrypted pre-master secret, the decrypted pre-master secret, the Kerberos local principal and the Kerberos remote principal * All the Kerberos-specific processing is done by the sun.security.ssl.krb5.KrbClientKeyExchangeHelperImpl helper class (through the KrbClientKeyExchangeHelper interface), dynamically loaded when available * Processing includes getting Kerberos tickets and using the Kerberos session key to encrypt or decrypt the pre-master secret * This class is analogous to RSAClientKeyExchange::RSAClientKeyExchangeMessage * KrbClientKeyExchangeHelper * Interface to expose Kerberos-specific functionality to TLS code. This class has no analogous class in other key exchange schemes. * KrbClientKeyExchangeHelperImpl * Implementation of the KrbClientKeyExchangeHelper interface from the Kerberos side. This class has no analogous class in other key exchange schemes. * KrbKeyExchange::KrbPossessionGenerator * For a Kerberos cipher-suite to be usable by a TLS server, the Service credentials must be retrieved. In other words, the TLS server must be able to authenticate against a KDC. In Webrev.01, a Kerberos cipher-suite was considered available without checking this condition. This was a regression from previous functionality in the old TLS engine. Credentials are held as a possession, in a KrbKeyExchange::KrbServiceCreds instance which is added to the Server Handshake Context. It's tempting to think that KrbKeyExchange::KrbServiceCreds should inherit from SSLCredentials (instead of SSLPossession), but server possessions is used to decide whether or not a ciphersuite is available. See T12ServerHelloProducer::chooseCipherSuite method (ServerHello.java). * KrbKeyExchange::KrbServiceCreds * Service credentials used by the TLS Server. These credentials contain the Kerberos session key used to decrypt the pre-master secret, sent by the TLS client. See KrbKeyExchange::KrbPossessionGenerator. * KrbKeyExchange::KrbPremasterSecret * Class that represents the pre-master secret. Has methods to create a new secret instance or to decode and validate a secret received from a network stream. As a consequence of the new design, we no longer need to expose TLS interfaces, classes, fields or methods to Kerberos-specific classes. There is a strict separation with the goal of processing TLS stuff on the TLS side only. In example, the pre-master secret validation happens on the TLS side and there is no need for Kerberos classes to access the ProtocolVersion class, ProtocolVersion::minor field, ProtocolVersion::major field or ProtocolVersion::compare method -which remain package-private-. In addition to these changes, I analyzed how the Kerberos Client Key Exchange functionality was coupled to the previous TLS engine and how that is addressed now: * KRB5 + TLS 1.2 (or below) * When Key Exchange is KRB5, no server Certificate message is received (Client side) * Ok: the client consumes the ServerHello message in T12ServerHelloConsumer::consume (ServerHello.java). When establishing a new session, the SSL Key Exchange instance (ke) is obtained and ke.getRelatedHandshakers is called to push handshake consumers to the list. Execution goes to SSLKeyExchange::getRelatedHandshakers method. SSLKeyExchange::getRelatedHandshakers calls ::getRelatedHandshakers methods for 'authentication' and 'key agreement' instances. Given that SSLKeyExchange::SSLKeyExKRB5EXPORT.KE is assigned to an SSLKeyExchange instance that has X509Authentication authentication = null, a Certificate consumer is not returned there. Note: X509Authentication::getRelatedHandshakers is the method that returns both a SSLHandshake.CERTIFICATE and a CERTIFICATE_REQUEST consumer. T12KeyAgreement::getRelatedHandshakers method, on the other side, gets called but does not return a CERTIFICATE or a CERTIFICATE_REQUEST consumer. * When key Exchange is KRB5, no server Certificate Request message is received (Client side) * Ok: for the same reason that a Certificate consumer is not pushed to the list. * When Key Exchange is KRB5, no server Server Key Exchange message is received (Client side) * OK: In T12KeyAgreement::getHandshakeConsumers, a SERVER_KEY_EXCHANGE consumer is not returned for KRB Key Exchange. This is called from SSLKeyExchange::getHandshakeConsumers, which is in turn called from ServerKeyExchangeConsumer::consume (ServerKeyExchange.java). A SERVER_KEY_EXCHANGE consumer may still be pushed to the list -or, in other words, ServerKeyExchangeConsumer::consume may still be called-. Why? T12KeyAgreement::getRelatedHandshakers may return a SERVER_KEY_EXCHANGE because possessionGenerator != null for KRB Key Exchange. T12KeyAgreement::getRelatedHandshakers is called from SSLKeyExchange::getRelatedHandshakers, which is in turn called from T12ServerHelloConsumer::consume for new SSL sessions. The reason why this is okay is because once ServerKeyExchangeConsumer::consume gets called, no SERVER_KEY_EXCHANGE consume is found associated to the Key Exchange and a "Unexpected ServerKeyExchange handshake message." exception is finally thrown. In the previous TLS engine, ClientHandshaker::processMessage method has a 'HandshakeMessage.ht_server_key_exchange' switch-case scenario in which an exception is thrown if Key Exchange is K_KRB5 or K_KRB5_EXPORT. * Server does not send Certificate message when Key Exchange is KRB5 (Server side) * OK: a Certificate producer is never pushed to the list of producers because SSLKeyExchange::SSLKeyExKRB5EXPORT.KE is assigned to an SSLKeyExchange instance that has X509Authentication authentication = null. X509Authentication::getHandshakeProducers (called from SSLKeyExchange::getHandshakeProducers) is the method that would return a SSLHandshake.CERTIFICATE producer. SSLKeyExchange::getHandshakeProducers also calls T12KeyAgreement::getHandshakeProducers but no CERTIFICATE producer is returned from there. SSLKeyExchange::getHandshakeProducers is called from T12ServerHelloProducer::produce (ServerHello.java), which gets the producers from the SSL Key Exchange instance through a 'ke.getHandshakeProducers' call. * No Server Key Exchange sent for KRB5 Key Exchange (Server side) * OK: for KRB Key Exchange (server side), T12KeyAgreement::getHandshakeProducers does not return any SERVER_KEY_EXCHANGE producer. This is called from SSLKeyExchange::getHandshakeProducers, which is in turn called from T12ServerHelloProducer::produce ('ke.getHandshakeProducers(shc)' call). SSLKeyExchange::getHandshakeProducers does not call X509Authentication::getHandshakeProducers because SSLKeyExchange::SSLKeyExKRB5EXPORT.KE is assigned to an SSLKeyExchange instance that has X509Authentication authentication = null. * Server sends a CertificateRequest message only if Key Exchange is not KRB5 (Server side) * OK: The server can add a CertificateRequest producer to the list in T12ServerHelloProducer::produce. To decide that, it calls SSLKeyExchange::getRelatedHandshakers and expects a CERTIFICATE producer to be received. SSLKeyExchange::SSLKeyExKRB5EXPORT.KE is assigned to an SSLKeyExchange instance that has X509Authentication authentication = null, so X509Authentication::getRelatedHandshakers is not called from SSLKeyExchange::getRelatedHandshakers. SSLKeyExchange::getRelatedHandshakers then calls T12KeyAgreement::getRelatedHandshakers. T12KeyAgreement::getRelatedHandshakers does not return a CERTIFICATE handshake producer. * Server tries to set the KRB5 key exchange if setupKerberosKeys succeeds * OK: When the server decides whether or not the KRB key exchange is available, KrbKeyExchange::KrbPossessionGenerator::createPossession is called and performs what was done by setupKerberosKeys in the old TLS engine. Only after succeeding is that the KRB ciphersuites are considered available. This was fixed from Webrev.01. * Client Hello processing (Server side) * Session resumption * "// validate subject identity" logic in ServerHandshaker.java * OK: verified in T12ClientHelloConsumer::consume (new TLS engine) * Changed SSL log from "session" to "ssl,handshake,verbose" which seems a better fit for the context * Server Hello processing (Client side) * Session resumption * "// validate subject identity" logic in ClientHandshaker.java * OK: verified in T12ServerHelloConsumer::consume (new TLS engine) * SSL log changes as in Client Hello processing * Client Key Exchange Message (send after Server Hello Done - Client side) * KerberosClientKeyExchange -> send logic * Ok: KrbClientKeyExchange::KrbClientKeyExchangeMessage has the sending logic * Calculate keys with preMasterSecret * Ok: the pre-master secret is held in KrbKeyExchange::KrbPremasterSecret, and KrbKeyExchange::KrbPremasterSecret::createPremasterSecret method generates the pre-master secret * Server receives a ht_client_key_exchange when Key Exchange is KRB5 (Server side) * KerberosClientKeyExchange -> receive logic * Server gets the preMasterSecret to calculate keys * Ok: When Key Exchange is KRB5, the KrbClientKeyExchange::krbHandshakeConsumer consumer will handle the incoming message. This consumer was returned by SSLKeyExchange::getHandshakeConsumers, that calls T12KeyAgreement::getHandshakeConsumers. KrbClientKeyExchange::KrbClientKeyExchangeMessage has the message decode logic. * Calling getPeerCertificates, getPeerCertificateChain or getCertificateChain on a SSLSession where Key Exchange is KRB5, throws an exception * OK: I implemented the check in SSLSessionImpl.java for a more descriptive exception message. * Calling getPeerPrincipal on a SSLSession where keyExchange is KRB5 should return a non-null peerPrincipal * OK: implemented in SSLSessionImpl.java. Minor doc change. I believe the "cipherSuite.keyExchange == K_KRB5*" check is not needed because peerPrincipal shouldn't be set for non KRB5 key exchanges and peerCerts should be null for KRB5 (no CertificateMessage allowed); no need for a redundant -product- run-time check. * Calling getLocalPrincipal on a SSLSession where keyExchange is KRB5 should return a localPrincipal (may be null) * OK: implemented in SSLSessionImpl.java. Minor doc change. I believe the "cipherSuite.keyExchange == K_KRB5*" check is not needed because localPrincipal shouldn't be set for non KRB5 key exchanges and localCerts should be null for KRB5 (no CertificateMessage allowed); no need for a redundant -product- run-time check. I'd appreciate if you can have a look, given your knowledge after working on Webrev.00 and Webrev.01. I guess we might still need an independent Reviewer here to proceed, once you are okay with the changes. NOTE 1: I'll be revieweing this myself one more time, but wanted to share it ahead of time for you to start looking at the changes, as there are many. NOTE 2: Tests were not run. This should not be a problem as test MUST pass in next steps. If you have them ready, I'd appreciate any feedback on that front :-) Thanks, Martin.- From gnu.andrew at redhat.com Wed Jul 15 14:45:25 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 15 Jul 2020 15:45:25 +0100 Subject: OpenJDK 8u262 Released Message-ID: <84698ae5-d44f-8b91-4bba-a9217069325c@redhat.com> We are pleased to announce the release of OpenJDK 8u262. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u262-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u262-ga.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 4fef6b372fa5b48bda830c4f4e6488dd13727d52adc58b1f5f5dd08683a5e54a openjdk8u262-ga.tar.xz 3a399481bdc1edd5d3a7a6ed90170525d19d4785343b9a9a5f2800bf4d3fdc1e openjdk8u262-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u262-ga.sha256 New in release OpenJDK 8u262 (2020-07-14): =========================================== Live versions of these release notes can be found at: * https://bitly.com/oj8u262 * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u262.txt * New features - JDK-8223147: JFR Backport * Security fixes - JDK-8028431, CVE-2020-14579: NullPointerException in DerValue.equals(DerValue) - JDK-8028591, CVE-2020-14578: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() - JDK-8230613: Better ASCII conversions - JDK-8231800: Better listing of arrays - JDK-8232014: Expand DTD support - JDK-8233255: Better Swing Buttons - JDK-8234032: Improve basic calendar services - JDK-8234042: Better factory production of certificates - JDK-8234418: Better parsing with CertificateFactory - JDK-8234836: Improve serialization handling - JDK-8236191: Enhance OID processing - JDK-8237117, CVE-2020-14556: Better ForkJoinPool behavior - JDK-8237592, CVE-2020-14577: Enhance certificate verification - JDK-8238002, CVE-2020-14581: Better matrix operations - JDK-8238804: Enhance key handling process - JDK-8238842: AIOOBE in GIFImageReader.initializeStringTable - JDK-8238843: Enhanced font handing - JDK-8238920, CVE-2020-14583: Better Buffer support - JDK-8238925: Enhance WAV file playback - JDK-8240119, CVE-2020-14593: Less Affine Transformations - JDK-8240482: Improved WAV file playback - JDK-8241379: Update JCEKS support - JDK-8241522: Manifest improved jar headers redux - JDK-8242136, CVE-2020-14621: Better XML namespace handling * Other changes - JDK-4949105: Access Bridge lacks html tags parsing - JDK-7147060: com/sun/org/apache/xml/internal/security/transforms/ClassLoaderTest.java doesn't run in agentvm mode - JDK-8003209: JFR events for network utilization - JDK-8030680: 292 cleanup from default method code assessment - JDK-8035633: TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently - JDK-8037866: Replace the Fun class in tests with lambdas - JDK-8041626: Shutdown tracing event - JDK-8041915: Move 8 awt tests to OpenJDK regression tests tree - JDK-8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null - JDK-8076475: Misuses of strncpy/strncat - JDK-8130737: AffineTransformOp can't handle child raster with non-zero x-offset - JDK-8141056: Erroneous assignment in HeapRegionSet.cpp - JDK-8146612: C2: Precedence edges specification violated - JDK-8148886: SEGV in sun.java2d.marlin.Renderer._endRendering - JDK-8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates - JDK-8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format - JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" - JDK-8165675: Trace event for thread park has incorrect unit for timeout - JDK-8171934: ObjectSizeCalculator.getEffectiveMemoryLayoutSpecification() does not recognize OpenJDK's HotSpot VM - JDK-8172559: [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java - JDK-8176182: 4 security tests are not run - JDK-8178374: Problematic ByteBuffer handling in CipherSpi.bufferCrypt method - JDK-8178910: Problemlist sample tests - JDK-8181841: A TSA server returns timestamp with precision higher than milliseconds - JDK-8183925: Decouple crash protection from watcher thread - JDK-8191393: Random crashes during cfree+0x1c - JDK-8195817: JFR.stop should require name of recording - JDK-8195818: JFR.start should increase autogenerated name by one - JDK-8195819: Remove recording=x from jcmd JFR.check output - JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE - JDK-8199712: Flight Recorder - JDK-8202578: Revisit location for class unload events - JDK-8202835: jfr/event/os/TestSystemProcess.java fails on missing events - JDK-8203287: Zero fails to build after JDK-8199712 (Flight Recorder) - JDK-8203346: JFR: Inconsistent signature of jfr_add_string_constant - JDK-8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording - JDK-8203921: JFR thread sampling is missing fixes from JDK-8194552 - JDK-8203929: Limit amount of data for JFR.dump - JDK-8205516: JFR tool - JDK-8207392: [PPC64] Implement JFR profiling - JDK-8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it - JDK-8209960: -Xlog:jfr* doesn't work with the JFR - JDK-8210024: JFR calls virtual is_Java_thread from ~Thread() - JDK-8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 - JDK-8211239: Build fails without JFR: empty JFR events signatures mismatch - JDK-8212232: Wrong metadata for the configuration of the cutoff for old object sample events - JDK-8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions - JDK-8213421: Line number information for execution samples always 0 - JDK-8213617: JFR should record the PID of the recorded process - JDK-8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. - JDK-8213914: [TESTBUG] Several JFR VM events are not covered by tests - JDK-8213917: [TESTBUG] Shutdown JFR event is not covered by test - JDK-8213966: The ZGC JFR events should be marked as experimental - JDK-8214542: JFR: Old Object Sample event slow on a deep heap in debug builds - JDK-8214750: Unnecessary

tags in jfr classes - JDK-8214896: JFR Tool left files behind - JDK-8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError - JDK-8214925: JFR tool fails to execute - JDK-8215175: Inconsistencies in JFR event metadata - JDK-8215237: jdk.jfr.Recording javadoc does not compile - JDK-8215284: Reduce noise induced by periodic task getFileSize() - JDK-8215355: Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1) - JDK-8215362: JFR GTest JfrTestNetworkUtilization fails - JDK-8215771: The jfr tool should pretty print reference chains - JDK-8216064: -XX:StartFlightRecording:settings= doesn't work properly - JDK-8216486: Possibility of integer overflow in JfrThreadSampler::run() - JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp - JDK-8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps - JDK-8216578: Remove unused/obsolete method in JFR code - JDK-8216995: Clean up JFR command line processing - JDK-8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT - JDK-8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent - JDK-8218935: Make jfr strncpy uses GCC 8.x friendly - JDK-8220293: Deadlock in JFR string pool - JDK-8223689: Add JFR Thread Sampling Support - JDK-8223690: Add JFR BiasedLock Event Support - JDK-8223691: Add JFR G1 Region Type Change Event Support - JDK-8223692: Add JFR G1 Heap Summary Event Support - JDK-8224172: assert(jfr_is_event_enabled(id)) failed: invariant - JDK-8224475: JTextPane does not show images in HTML rendering - JDK-8225068: Remove DocuSign root certificate that is expiring in May 2020 - JDK-8225069: Remove Comodo root certificate that is expiring in May 2020 - JDK-8226253: JAWS reports wrong number of radio buttons when buttons are hidden. - JDK-8226779: [TESTBUG] Test JFR API from Java agent - JDK-8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys - JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory - JDK-8227269: Slow class loading when running with JDWP - JDK-8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" - JDK-8229366: JFR backport allows unchecked writing to memory - JDK-8229401: Fix JFR code cache test failures - JDK-8229708: JFR backport code does not initialize - JDK-8229873: 8229401 broke jdk8u-jfr-incubator - JDK-8229888: (zipfs) Updating an existing zip file does not preserve original permissions - JDK-8229899: Make java.io.File.isInvalid() less racy - JDK-8230448: [test] JFRSecurityTestSuite.java is failing on Windows - JDK-8230597: Update GIFlib library to the 5.2.1 - JDK-8230707: JFR related tests are failing - JDK-8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in early return - JDK-8230782: Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false - JDK-8230856: Java_java_net_NetworkInterface_getByName0 on unix misses ReleaseStringUTFChars in early return - JDK-8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout - JDK-8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 - JDK-8231995: two jtreg tests failed after 8229366 is fixed - JDK-8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing - JDK-8233623: Add classpath exception to copyright in EventHandlerProxyCreator.java file - JDK-8233880: Support compilers with multi-digit major version numbers - JDK-8236002: CSR for JFR backport suggests not leaving out the package-info - JDK-8236008: Some backup files were accidentally left in the hotspot tree - JDK-8236074: Missed package-info - JDK-8236174: Should update javadoc since tags - JDK-8236996: Incorrect Roboto font rendering on Windows with subpixel antialiasing - JDK-8238076: Fix OpenJDK 7 Bootstrap Broken by JFR Backport - JDK-8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 - JDK-8238590: Enable JFR by default during compilation in 8u - JDK-8239055: Wrong implementation of VMState.hasListener - JDK-8239476: JDK-8238589 broke windows build by moving OrderedPair - JDK-8239479: minimal1 and zero builds are failing - JDK-8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed - JDK-8239867: correct over use of INCLUDE_JFR macro - JDK-8240375: Disable JFR by default for July 2020 release - JDK-8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges - JDK-8241444: Metaspace::_class_vsm not initialized if compressed class pointers are disabled - JDK-8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set - JDK-8241750: x86_32 build failure after JDK-8227269 - JDK-8241902: AIX Build broken after integration of JDK-8223147 (JFR Backport) - JDK-8242788: Non-PCH build is broken after JDK-8191393 - JDK-8242883: Incomplete backport of JDK-8078268: backport test part - JDK-8243059: Build fails when --with-vendor-name contains a comma - JDK-8243474: [TESTBUG] removed three tests of 0 bytes - JDK-8243539: Copyright info (Year) should be updated for fix of 8241638 - JDK-8243541: (tz) Upgrade time-zone data to tzdata2020a - JDK-8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in - JDK-8244461: [JDK 8u] Build fails with glibc 2.32 - JDK-8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result - JDK-8244777: ClassLoaderStats VM Op uses constant hash value - JDK-8244843: JapanEraNameCompatTest fails - JDK-8245167: Top package in method profiling shows null in JMC - JDK-8246223: Windows build fails after JDK-8227269 - JDK-8246703: [TESTBUG] Add test for JDK-8233197 - JDK-8248399: Build installs jfr binary when JFR is disabled - JDK-8248715: New JavaTimeSupplementary localisation for 'in' installed in wrong package Notes on individual issues: =========================== hotspot/jfr: JDK-8240687: JDK Flight Recorder Integrated to OpenJDK 8u ========================================================= OpenJDK 8u now contains the backport of JEP 328: Flight Recorder (https://openjdk.java.net/jeps/328) from later versions of OpenJDK. JFR is a low-overhead framework to collect and provide data helpful to troubleshoot the performance of the OpenJDK runtime and of Java applications. It consists of a new API to define custom events under the jdk.jfr namespace and a JMX interface to interact with the framework. The recording can also be initiated with the application startup using the -XX:+FlightRecorder flag or via jcmd. JFR replaces the +XX:EnableTracing feature introduced in JEP 167, providing a more efficient way to retrieve the same information. For compatibility reasons, +XX:EnableTracing is still accepted, however no data will be printed. For this initial release, JFR is not built by default. Downstream distributions need to pass the --enable-jfr flag at configure time to enable it. hotspot/runtime: JDK-8205622: JFR Start Failure After AppCDS Archive Created with JFR StartFlightRecording ============================================================ JFR will be disabled with a warning message if it is enabled during CDS dumping. The user will see the following warning message: OpenJDK 64-Bit Server VM warning: JFR will be disabled during CDS dumping if JFR is enabled during CDS dumping such as in the following command line: $ java -Xshare:dump -XX:StartFlightRecording=dumponexit=true security-libs/java.security: JDK-8244167: Removal of Comodo Root CA Certificate ================================================== The following expired Comodo root CA certificate was removed from the `cacerts` keystore: + alias name "addtrustclass1ca [jdk]" Distinguished Name: CN=AddTrust Class 1 CA Root, OU=AddTrust TTP Network, O=AddTrust AB, C=SE JDK-8244166: Removal of DocuSign Root CA Certificate ==================================================== The following expired DocuSign root CA certificate was removed from the `cacerts` keystore: + alias name "keynectisrootca [jdk]" Distinguished Name: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR security-libs/javax.crypto:pkcs11: JDK-8240191: Allow SunPKCS11 initialization with NSS when external FIPS modules are present in the Security Modules Database ========================================================== The SunPKCS11 security provider can now be initialized with NSS when FIPS-enabled external modules are configured in the Security Modules Database (NSSDB). Prior to this change, the SunPKCS11 provider would throw a RuntimeException with the message: "FIPS flag set for non-internal module" when such a library was configured for NSS in non-FIPS mode. This change allows the JDK to work properly with recent NSS releases on GNU/Linux operating systems when the system-wide FIPS policy is turned on. Further information can be found in JDK-8238555. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From aph at redhat.com Wed Jul 15 14:46:08 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Jul 2020 15:46:08 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <639b6fc7-8eb3-0b2f-00c1-534c9fe13ee0@redhat.com> References: <0d844672-7127-d7fe-5765-cf87f13690ad@redhat.com> <6f52dd7f-c72a-1e28-29c9-48549f970242@redhat.com> <639b6fc7-8eb3-0b2f-00c1-534c9fe13ee0@redhat.com> Message-ID: <0517227f-130d-6379-ad72-e87bf37523bd@redhat.com> On 08/07/2020 22:53, Andrew Hughes wrote: > > On 08/07/2020 18:56, Zhengyu Gu wrote: >> >>> I already backported this: >>> >>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011526.html >>> >>> In the end, we decided not to go ahead with this and workaround it for >>> JDK-8076475: >>> >>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011539.html >> >> At that time, this was *not* a parity backport, but now, it is. Should >> we reconsider it? > > To my mind, that doesn't really change anything from a technical > standpoint, but I'll leave the final say to Andrew Haley. Hmm. Once strdup() has failed, the whole program is basically dead in the water, and throwing an OutOfMemoryError only delays the inevitable. It might even be argued that a VM error is more informative than an OutOfMemoryError, because then the problem doesn't look like heap exhaustion. The fact that this is now a parity backport does swing me more to saying "yes", but this is an extensive change and that makes me nervous, so I'm leaning towards "no". I am aware that I'm swithering here, but it's a genuine dilemma: neither course of action is great. -- 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 Wed Jul 15 18:39:55 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 15 Jul 2020 14:39:55 -0400 Subject: [8u] 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD Message-ID: <86af138b-c678-bb1c-4eda-56f7aba47844@redhat.com> I would like to backport this patch to 8u, for parity with Oracle 8u271. Original patch applies cleanly. However, it failed to build, cause it expects sun.security.krb5.Config.getBooleanObject(String... keys) to be public method, while 8u and only 8u, it declares as private. Apparently, the method was partially backported and made it private. Original bug: https://bugs.openjdk.java.net/browse/JDK-8239385 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/142d090cab77 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8239385-8u/webrev.00/ Test: jdk_security Thanks, -Zhengyu From mbalao at redhat.com Wed Jul 15 20:02:58 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 15 Jul 2020 17:02:58 -0300 Subject: [8u] 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <86af138b-c678-bb1c-4eda-56f7aba47844@redhat.com> References: <86af138b-c678-bb1c-4eda-56f7aba47844@redhat.com> Message-ID: Hi, On 7/15/20 3:39 PM, Zhengyu Gu wrote: > I would like to backport this patch to 8u, for parity with Oracle 8u271. > > Original patch applies cleanly. > > However, it failed to build, cause it expects > sun.security.krb5.Config.getBooleanObject(String... keys) to be public > method, while 8u and only 8u, it declares as private. Apparently, the > method was partially backported and made it private. > Yes, indeed. They introduced getBooleanObject method with the backport of 8077102 and made it private for some reason. This class is an internal class so keeping it public wouldn't have affected the public API. getBooleanObject was originally introduced by 8029995 and was public. Your backport looks good to me. I believe we will need a CSR before having the approval. Thanks, Martin.- From gnu.andrew at redhat.com Wed Jul 15 21:09:08 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 15 Jul 2020 22:09:08 +0100 Subject: [8u] 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: References: <86af138b-c678-bb1c-4eda-56f7aba47844@redhat.com> Message-ID: <71658fc4-3fa6-7f98-1183-a8f1b00d582c@redhat.com> On 15/07/2020 21:02, Martin Balao wrote: > Hi, > > On 7/15/20 3:39 PM, Zhengyu Gu wrote: >> I would like to backport this patch to 8u, for parity with Oracle 8u271. >> >> Original patch applies cleanly. >> >> However, it failed to build, cause it expects >> sun.security.krb5.Config.getBooleanObject(String... keys) to be public >> method, while 8u and only 8u, it declares as private. Apparently, the >> method was partially backported and made it private. >> > > Yes, indeed. They introduced getBooleanObject method with the backport > of 8077102 and made it private for some reason. This class is an > internal class so keeping it public wouldn't have affected the public > API. getBooleanObject was originally introduced by 8029995 and was public. > > Your backport looks good to me. Yes, the backport of 8077102 to 8u is a mess. It brings in this method from 8029995 and alters its signature. Given that, I don't see any harm in fixing it here. The rest of the backport is clean. > > I believe we will need a CSR before having the approval. I agree. > > Thanks, > Martin.- > Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From hohensee at amazon.com Wed Jul 15 21:38:31 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 15 Jul 2020 21:38:31 +0000 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Message-ID: <9B258C2F-0DBD-45EF-AAF4-E4BA6367D144@amazon.com> Lgtm, except, why you need to remove the assert from taskqueue.hpp? oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the serial collector is the only collector being compiled into Hotspot, so with your change the assert only gets compiled for that case. Is a taskqueue ever instantiated for that case? Thanks, Paul ?On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" wrote: Hi, Could someone please help? Thanks, Liang ------------------------------------------------------------------ From:MAO, Liang Send Time:2020 Jul. 2 (Thu.) 10:30 To:jdk8u-dev Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Hi, I'm requesting the backport of 8057003 into 8u. As the description in the bug, it's a serious G1 issue which leads to 10X longer concurrent mark time and hang the Java threads for seconds. We encounter the problem in several applications. Since G1 is widely used in 8u, we need to fix it. Original bug: https://bugs.openjdk.java.net/browse/JDK-8057003 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd The JDK9 patch did not apply cleanly. Although it is not a small patch, I didn't change much except some assertions. One assertion in taskqueue.hpp is removed. It should be ok because it's no longer there as well since JDK9. 8u webrev: http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ Testing: gc/g1, specjbb2015 with fastdebug Could someone please have a look and sponsor? Thanks, Liang From mbalao at redhat.com Wed Jul 15 21:51:48 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 15 Jul 2020 18:51:48 -0300 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: References: Message-ID: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> Hi, On 5/21/20 11:19 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u One question: why do we need to include TLS 1.3 when retrieving the list of client enabled ciphersuites to assign CustomizedTLSContext::clientDefaultCipherSuites field? Thanks, Martin.- From maoliang.ml at alibaba-inc.com Thu Jul 16 02:27:12 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Thu, 16 Jul 2020 10:27:12 +0800 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times In-Reply-To: <9B258C2F-0DBD-45EF-AAF4-E4BA6367D144@amazon.com> References: <9B258C2F-0DBD-45EF-AAF4-E4BA6367D144@amazon.com> Message-ID: <004401d65b18$9d5da0f0$d818e2d0$@alibaba-inc.com> Hi Paul, In order to partially iterate the object array, the task queue will not only have oop but also "array slice" which is not oop. But inserting G1 specific code into taskqueue.hpp as below seems a little bit hacking: + assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null"); In JDK9, the oops_do() is already replaced by a common general iterate() which won't have that assertion. Do you think changing the assertion as below is better? -assert((*t)->is_oop_or_null(), "Not an oop or null"); +assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Liang > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: 2020?7?16? 5:39 > To: Liang Mao ; jdk8u-dev dev at openjdk.java.net> > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks > like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the > serial collector is the only collector being compiled into Hotspot, so with your > change the assert only gets compiled for that case. Is a taskqueue ever > instantiated for that case? > > Thanks, > Paul > > ?On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time and > hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small patch, I > didn't change much except some assertions. One assertion in taskqueue.hpp > is removed. It should be ok because it's no longer there as well since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > From sdamakoudis9 at gmail.com Thu Jul 16 04:25:47 2020 From: sdamakoudis9 at gmail.com (Stelios Damakoudis) Date: Thu, 16 Jul 2020 07:25:47 +0300 Subject: jdk8u-dev Digest, Vol 80, Issue 25 In-Reply-To: References: Message-ID: ???? ???, 16 ???? 2020, 00:40 ? ??????? ??????: > Send jdk8u-dev mailing list submissions to > jdk8u-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.openjdk.java.net/mailman/listinfo/jdk8u-dev > or, via email, send a message with subject or body 'help' to > jdk8u-dev-request at openjdk.java.net > > You can reach the person managing the list at > jdk8u-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of jdk8u-dev digest..." > > > Today's Topics: > > 1. [8u] 8239385: KerberosTicket client name refers wrongly to > sAMAccountName in AD (Zhengyu Gu) > 2. Re: [8u] 8239385: KerberosTicket client name refers wrongly > to sAMAccountName in AD (Martin Balao) > 3. Re: [8u] 8239385: KerberosTicket client name refers wrongly > to sAMAccountName in AD (Andrew Hughes) > 4. RE: [8u] RFR Backport 8057003: Large reference arrays cause > extremely long synchronization times (Hohensee, Paul) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 15 Jul 2020 14:39:55 -0400 > From: Zhengyu Gu > To: jdk8u-dev > Subject: [8u] 8239385: KerberosTicket client name refers wrongly to > sAMAccountName in AD > Message-ID: <86af138b-c678-bb1c-4eda-56f7aba47844 at redhat.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I would like to backport this patch to 8u, for parity with Oracle 8u271. > > Original patch applies cleanly. > > However, it failed to build, cause it expects > sun.security.krb5.Config.getBooleanObject(String... keys) to be public > method, while 8u and only 8u, it declares as private. Apparently, the > method was partially backported and made it private. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8239385 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/142d090cab77 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8239385-8u/webrev.00/ > > Test: > jdk_security > > Thanks, > > -Zhengyu > > > > ------------------------------ > > Message: 2 > Date: Wed, 15 Jul 2020 17:02:58 -0300 > From: Martin Balao > To: jdk8u-dev at openjdk.java.net, Zhengyu Gu > Subject: Re: [8u] 8239385: KerberosTicket client name refers wrongly > to sAMAccountName in AD > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi, > > On 7/15/20 3:39 PM, Zhengyu Gu wrote: > > I would like to backport this patch to 8u, for parity with Oracle 8u271. > > > > Original patch applies cleanly. > > > > However, it failed to build, cause it expects > > sun.security.krb5.Config.getBooleanObject(String... keys) to be public > > method, while 8u and only 8u, it declares as private. Apparently, the > > method was partially backported and made it private. > > > > Yes, indeed. They introduced getBooleanObject method with the backport > of 8077102 and made it private for some reason. This class is an > internal class so keeping it public wouldn't have affected the public > API. getBooleanObject was originally introduced by 8029995 and was public. > > Your backport looks good to me. > > I believe we will need a CSR before having the approval. > > Thanks, > Martin.- > > > > ------------------------------ > > Message: 3 > Date: Wed, 15 Jul 2020 22:09:08 +0100 > From: Andrew Hughes > To: Martin Balao , jdk8u-dev at openjdk.java.net, > Zhengyu Gu > Subject: Re: [8u] 8239385: KerberosTicket client name refers wrongly > to sAMAccountName in AD > Message-ID: <71658fc4-3fa6-7f98-1183-a8f1b00d582c at redhat.com> > Content-Type: text/plain; charset="utf-8" > > On 15/07/2020 21:02, Martin Balao wrote: > > Hi, > > > > On 7/15/20 3:39 PM, Zhengyu Gu wrote: > >> I would like to backport this patch to 8u, for parity with Oracle 8u271. > >> > >> Original patch applies cleanly. > >> > >> However, it failed to build, cause it expects > >> sun.security.krb5.Config.getBooleanObject(String... keys) to be public > >> method, while 8u and only 8u, it declares as private. Apparently, the > >> method was partially backported and made it private. > >> > > > > Yes, indeed. They introduced getBooleanObject method with the backport > > of 8077102 and made it private for some reason. This class is an > > internal class so keeping it public wouldn't have affected the public > > API. getBooleanObject was originally introduced by 8029995 and was > public. > > > > Your backport looks good to me. > > Yes, the backport of 8077102 to 8u is a mess. It brings in this method > from 8029995 and alters its signature. Given that, I don't see any harm > in fixing it here. The rest of the backport is clean. > > > > > I believe we will need a CSR before having the approval. > > I agree. > > > > > Thanks, > > Martin.- > > > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > ------------------------------ > > Message: 4 > Date: Wed, 15 Jul 2020 21:38:31 +0000 > From: "Hohensee, Paul" > To: Liang Mao , jdk8u-dev > > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause > extremely long synchronization times > Message-ID: <9B258C2F-0DBD-45EF-AAF4-E4BA6367D144 at amazon.com> > Content-Type: text/plain; charset="utf-8" > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that > looks like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only > when the serial collector is the only collector being compiled into > Hotspot, so with your change the assert only gets compiled for that case. > Is a taskqueue ever instantiated for that case? > > Thanks, > Paul > > ?On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" < > jdk8u-dev-retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> > wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > Subject:[8u] RFR Backport 8057003: Large reference arrays cause > extremely long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in > the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time > and hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small > patch, I > didn't change much except some assertions. One assertion in > taskqueue.hpp > is removed. It should be ok because it's no longer there as well > since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > > > > End of jdk8u-dev Digest, Vol 80, Issue 25 > ***************************************** > From alexey at azul.com Thu Jul 16 04:51:22 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 16 Jul 2020 04:51:22 +0000 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> Message-ID: <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> Hello Martin, > > One question: why do we need to include TLS 1.3 when retrieving the list > of client enabled ciphersuites to assign > CustomizedTLSContext::clientDefaultCipherSuites field? > TLS1.3 cipher suites should be enabled, otherwise we can not switch to TLSv1.3 protocol with SSLSocket.setEnabledProtocols() or SSLSocket.setSSLParameters(). TLS1.3 cipher suites will be disabled and handshake fails because of no appropriate protocol + cipher suite. Regards Alexey > Thanks, > Martin.- > From mbalao at redhat.com Thu Jul 16 07:30:40 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 16 Jul 2020 04:30:40 -0300 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> Message-ID: <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> On 7/16/20 1:51 AM, Alexey Bakhtin wrote: >> One question: why do we need to include TLS 1.3 when retrieving the list >> of client enabled ciphersuites to assign >> CustomizedTLSContext::clientDefaultCipherSuites field? >> > TLS1.3 cipher suites should be enabled, otherwise we can not switch to TLSv1.3 protocol with SSLSocket.setEnabledProtocols() or SSLSocket.setSSLParameters(). TLS1.3 cipher suites will be disabled and handshake fails because of no appropriate protocol + cipher suite. > I see your point but looks a bit confusing to me that TLS 1.3 ciphersuites would be enabled in the client's default Context when the protocol is not. Even if these ciphersuites are not offered to the TLS server in the handshake -which I guess you already verified-, I'd have expected a more consistent context state there. If we look at TLS 1.3, 1.2, 1.1, etc. contexts, there is a direct relationship between protocols and ciphersuites enabled: no ciphersuite from a greater-only protocol is included in the context. In other words, the ciphersuite must 'support' one of the protocols to be in the context. We would be making an (arbitrary) exception for the client's default context only. If the application enables a protocol dynamically -by means of SSLSocket/SSLEngine::setEnabledProtocols or SSLSocket/SSLEngine::setSSLParameters-, then it will probably want to modify the ciphersuites as well -by means of SSLSocket/SSLEngine::setEnabledCipherSuites or SSLSocket/SSLEngine::setSSLParameters-. But the assumption then is that it wants a more custom or manual configuration, and diverges from the context's default. What do you think? Have you seen any other downside beyond ::setEnabledProtocols and ::setSSLParameters? Thanks, Martin.- From felix.yang at huawei.com Thu Jul 16 09:01:48 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 16 Jul 2020 09:01:48 +0000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> Message-ID: Ping ... Could someone please take another look? Especially the two webrevs for 11u & 13u. Thanks, Felix > -----Original Message----- > From: Yangfei (Felix) > Sent: Friday, July 10, 2020 7:44 PM > To: 'Andrew Haley' ; Kim Barrett > > Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > aarch64-port-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: RE: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > fences between free chunk check and klass read > > Hi, > > > -----Original Message----- > > From: Andrew Haley [mailto:aph at redhat.com] > > Sent: Wednesday, July 8, 2020 5:48 PM > > To: Kim Barrett ; Yangfei (Felix) > > > > Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > > aarch64-port-dev at openjdk.java.net > > Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > > fences between free chunk check and klass read > > > > On 08/07/2020 09:41, Kim Barrett wrote: > > >> Since CMS is deprecated from JDK9, I am not sure if it's > > >> appropriate to fix > > this issue for those JDK9+ versions. > > > Deprecated != unsupported. > > > > > > > Yes, it must be done. Thanks. > > CCing to jdk-updates-dev. > > I have prepared another two webrevs for jdk11u and jdk13u: > Jdk11u-dev: http://cr.openjdk.java.net/~fyang/8248851-11u/ > Jdk13u-dev: http://cr.openjdk.java.net/~fyang/8248851-13u/ > > The only difference lies in copyright year update. Both tiere1-3 tested on > aarch64-linux-gnu. > I will put jdk11u-fix-request and jdk13u-fix-request label on the issue if they > are good. > > I have also prepared a new webrev for jdk8u incorporating copyright year > update: > Jdk8u-dev: http://cr.openjdk.java.net/~fyang/8248851-8u/ > > Thanks, > Felix > From david.holmes at oracle.com Thu Jul 16 09:16:04 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Jul 2020 19:16:04 +1000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> Message-ID: <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> Hi Felix, Seems to me that you want OrderAccess::loadload() barriers to order the loads, not OrderAccess::acquire(). You should only use acquire semantics to pair with a corresponding release operation. Cheers, David On 16/07/2020 7:01 pm, Yangfei (Felix) wrote: > Ping ... > Could someone please take another look? Especially the two webrevs for 11u & 13u. > > Thanks, > Felix > >> -----Original Message----- >> From: Yangfei (Felix) >> Sent: Friday, July 10, 2020 7:44 PM >> To: 'Andrew Haley' ; Kim Barrett >> >> Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; >> aarch64-port-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net >> Subject: RE: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory >> fences between free chunk check and klass read >> >> Hi, >> >>> -----Original Message----- >>> From: Andrew Haley [mailto:aph at redhat.com] >>> Sent: Wednesday, July 8, 2020 5:48 PM >>> To: Kim Barrett ; Yangfei (Felix) >>> >>> Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; >>> aarch64-port-dev at openjdk.java.net >>> Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory >>> fences between free chunk check and klass read >>> >>> On 08/07/2020 09:41, Kim Barrett wrote: >>>>> Since CMS is deprecated from JDK9, I am not sure if it's >>>>> appropriate to fix >>> this issue for those JDK9+ versions. >>>> Deprecated != unsupported. >>>> >>> >>> Yes, it must be done. Thanks. >> >> CCing to jdk-updates-dev. >> >> I have prepared another two webrevs for jdk11u and jdk13u: >> Jdk11u-dev: http://cr.openjdk.java.net/~fyang/8248851-11u/ >> Jdk13u-dev: http://cr.openjdk.java.net/~fyang/8248851-13u/ >> >> The only difference lies in copyright year update. Both tiere1-3 tested on >> aarch64-linux-gnu. >> I will put jdk11u-fix-request and jdk13u-fix-request label on the issue if they >> are good. >> >> I have also prepared a new webrev for jdk8u incorporating copyright year >> update: >> Jdk8u-dev: http://cr.openjdk.java.net/~fyang/8248851-8u/ >> >> Thanks, >> Felix >> > From alexey at azul.com Thu Jul 16 10:25:51 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 16 Jul 2020 10:25:51 +0000 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> Message-ID: Hello Martin, TLSv1.3, 1.2 and 1.1 contexts are different because of we selected highest protocol explicitly, so return cipher suites for these protocol set only. My approach requires less configuration from application point of view. However you are right, this approach could be also misleading if default cipher and protocol set not match each other. Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v1/ Regards Alexey > On 16 Jul 2020, at 10:30, Martin Balao wrote: > > On 7/16/20 1:51 AM, Alexey Bakhtin wrote: >>> One question: why do we need to include TLS 1.3 when retrieving the list >>> of client enabled ciphersuites to assign >>> CustomizedTLSContext::clientDefaultCipherSuites field? >>> >> TLS1.3 cipher suites should be enabled, otherwise we can not switch to TLSv1.3 protocol with SSLSocket.setEnabledProtocols() or SSLSocket.setSSLParameters(). TLS1.3 cipher suites will be disabled and handshake fails because of no appropriate protocol + cipher suite. >> > > I see your point but looks a bit confusing to me that TLS 1.3 > ciphersuites would be enabled in the client's default Context when the > protocol is not. Even if these ciphersuites are not offered to the TLS > server in the handshake -which I guess you already verified-, I'd have > expected a more consistent context state there. > > If we look at TLS 1.3, 1.2, 1.1, etc. contexts, there is a direct > relationship between protocols and ciphersuites enabled: no ciphersuite > from a greater-only protocol is included in the context. In other words, > the ciphersuite must 'support' one of the protocols to be in the > context. We would be making an (arbitrary) exception for the client's > default context only. > > If the application enables a protocol dynamically -by means of > SSLSocket/SSLEngine::setEnabledProtocols or > SSLSocket/SSLEngine::setSSLParameters-, then it will probably want to > modify the ciphersuites as well -by means of > SSLSocket/SSLEngine::setEnabledCipherSuites or > SSLSocket/SSLEngine::setSSLParameters-. But the assumption then is that > it wants a more custom or manual configuration, and diverges from the > context's default. > > What do you think? > > Have you seen any other downside beyond ::setEnabledProtocols and > ::setSSLParameters? > > Thanks, > Martin.- > From zgu at redhat.com Thu Jul 16 12:42:28 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Jul 2020 08:42:28 -0400 Subject: [8u] RFR(T) 8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public Message-ID: Please review this trivial patch that makes sun.security.krb5.Config.getBooleanObject(String... keys) a public method. The method was introduced by JDK-8029995 in jdk9, as a public method, but made a private method by JDK-8029995 8u backport. This blocks JDK-8239385 8u backport. Bug: https://bugs.openjdk.java.net/browse/JDK-8249610 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249610/webrev.00/ Test: jdk_security Thanks, -Zhengyu From zgu at redhat.com Thu Jul 16 13:17:57 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Jul 2020 09:17:57 -0400 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <0517227f-130d-6379-ad72-e87bf37523bd@redhat.com> References: <0d844672-7127-d7fe-5765-cf87f13690ad@redhat.com> <6f52dd7f-c72a-1e28-29c9-48549f970242@redhat.com> <639b6fc7-8eb3-0b2f-00c1-534c9fe13ee0@redhat.com> <0517227f-130d-6379-ad72-e87bf37523bd@redhat.com> Message-ID: <5674f205-0a37-7f52-67f4-a29b399eee19@redhat.com> >> >> To my mind, that doesn't really change anything from a technical >> standpoint, but I'll leave the final say to Andrew Haley. > > Hmm. Once strdup() has failed, the whole program is basically dead in > the water, and throwing an OutOfMemoryError only delays the > inevitable. It might even be argued that a VM error is more > informative than an OutOfMemoryError, because then the problem doesn't > look like heap exhaustion. > > The fact that this is now a parity backport does swing me more to > saying "yes", but this is an extensive change and that makes me > nervous, so I'm leaning towards "no". I am aware that I'm swithering > here, but it's a genuine dilemma: neither course of action is great. > So, it it a rejection? Another drawback for not backporting parity bugs, is making future backports harder. Thanks, -Zhengyu From zgu at redhat.com Thu Jul 16 13:33:30 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Jul 2020 09:33:30 -0400 Subject: [8u] 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD In-Reply-To: <71658fc4-3fa6-7f98-1183-a8f1b00d582c@redhat.com> References: <86af138b-c678-bb1c-4eda-56f7aba47844@redhat.com> <71658fc4-3fa6-7f98-1183-a8f1b00d582c@redhat.com> Message-ID: <88d7d361-0178-bd6a-edad-2d8dce1cfd1a@redhat.com> >> >> I believe we will need a CSR before having the approval. > > I agree. Filed https://bugs.openjdk.java.net/browse/JDK-8249610, so this backport will be clean. Thanks, -Zhengyu > >> >> Thanks, >> Martin.- >> > > Thanks, > From aph at redhat.com Thu Jul 16 13:43:15 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 16 Jul 2020 14:43:15 +0100 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> Message-ID: <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> On 16/07/2020 10:16, David Holmes wrote: > Seems to me that you want OrderAccess::loadload() barriers to order the > loads, not OrderAccess::acquire(). You should only use acquire semantics > to pair with a corresponding release operation. I agree, but it's unlikely to matter in practice. Having said that, I'm strongly of the opinion that if you see a naked StoreStore it may well be a bug, or at least you've got something very hard to analyse. I know of a few cases (e.g. zeroing an object) where this isn't true. https://www.hboehm.info/c++mm/no_write_fences.html, etc. But that's an argument for another day. -- 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 shade at redhat.com Thu Jul 16 14:05:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 16 Jul 2020 16:05:52 +0200 Subject: [8u] RFR (XS) 8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout In-Reply-To: <3df900f7-5300-ffbc-7c09-203664d3bbcb@redhat.com> References: <2f9c5aab-e053-84e3-bdf4-168b1e2cc521@redhat.com> <3df900f7-5300-ffbc-7c09-203664d3bbcb@redhat.com> Message-ID: <17397f78-4b19-0d6e-6bf4-b9d5b397846d@redhat.com> On 6/15/20 5:36 PM, Zhengyu Gu wrote: > I reviewed this patch, could you please request for an approval? Right. Sorry for late reply here, added the tags paraphernalia. -- Thanks, -Aleksey From hohensee at amazon.com Thu Jul 16 14:30:07 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 16 Jul 2020 14:30:07 +0000 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Message-ID: <75FC11DA-FFAA-4979-8963-0E1257DD8265@amazon.com> Using #ifndef INCLUDE_ALL_GCS is also a hack. :) I looked for uses of GenericTaskQueue::oops_do() in G1 and could find only one, in ConcurrentMark::verify_no_cset_oops(). In that context, it invokes VerifyNoCSetOopsClosure::do_object_work(), which is updated by the original patch. But, JDK 9 has two asserts rather than JDK 8?s single assert. The first JDK 9 assert is the G1-specific equivalent to the assert in TaskQueue::oops_do(). So, I'd add the first JDK 9 assert to your patch?s VerifyNoCSetOopsClosure::do_object_work(), vis guarantee(G1CMObjArrayProcessor::is_array_slice(obj) || obj->is_oop(), "Non-oop " PTR_FORMAT ", phase: %s, info: %d", p2i(obj), _phase, _info); and change the assert in TaskQueue::oops_do() to what you suggest (with a comment), vis // G1 does its own checking assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Paul ?On 7/15/20, 7:28 PM, "Liang Mao" wrote: Hi Paul, In order to partially iterate the object array, the task queue will not only have oop but also "array slice" which is not oop. But inserting G1 specific code into taskqueue.hpp as below seems a little bit hacking: + assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null"); In JDK9, the oops_do() is already replaced by a common general iterate() which won't have that assertion. Do you think changing the assertion as below is better? -assert((*t)->is_oop_or_null(), "Not an oop or null"); +assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Liang > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: 2020?7?16? 5:39 > To: Liang Mao ; jdk8u-dev dev at openjdk.java.net> > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks > like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the > serial collector is the only collector being compiled into Hotspot, so with your > change the assert only gets compiled for that case. Is a taskqueue ever > instantiated for that case? > > Thanks, > Paul > > On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time and > hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small patch, I > didn't change much except some assertions. One assertion in taskqueue.hpp > is removed. It should be ok because it's no longer there as well since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > From alexey at azul.com Thu Jul 16 14:49:55 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 16 Jul 2020 14:49:55 +0000 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> Message-ID: <6068C815-4030-4794-8497-801F09D256D5@azul.com> Changes in the default client cipher suites also requires fixes in the following tests: - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java - javax/net/ssl/SSLSocket/Tls13PacketSize.java - javax/net/ssl/Stapling/HttpsUrlConnClient.java - javax/net/ssl/Stapling/SSLEngineWithStapling.java - javax/net/ssl/Stapling/SSLSocketWithStapling.java - javax/net/ssl/Stapling/StapleEnableProps.java - javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java - javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java These tests do not update list of supported cipher suites for the TLSv1.3 protocol The fix could be simple : add -Djdk.tls.client.protocols="TLSv1.3,TLSv1.2,TLSv1.1,TLSv1,SSLv3? in the test run notation It should be done as part of test subtask JDK-8245681 Regards Alexey > On 16 Jul 2020, at 13:25, Alexey Bakhtin wrote: > > Hello Martin, > > TLSv1.3, 1.2 and 1.1 contexts are different because of we selected highest protocol explicitly, so return cipher suites for these protocol set only. > My approach requires less configuration from application point of view. > However you are right, this approach could be also misleading if default cipher and protocol set not match each other. > > Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v1/ > > > Regards > Alexey > From sgehwolf at redhat.com Thu Jul 16 15:48:36 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 Jul 2020 17:48:36 +0200 Subject: [8u] RFR: 8203357: Container Metrics Message-ID: Hi, Please review this OpenJDK 8u backport of the Java Metrics classes which are in later JDKs. It is a pre-requisite for JDK-8226575 an Oracle JDK parity issue. Implementations of the interface are provided for Linux only and, thus, are compiled for Linux only. This backport differs from the original JDK 11 change in the following way: * MetricsTester: Arrays.compare() => Arrays.equals(). Arrays.compare() is JDK 9+ only. * JDK-8223147: JFR Backport, brought in test library code included in the JDK 11 changeset. I've only done the needed adjustments to the relevant files in the test libary. Many were already present. * For this backport I've not included changes to the Launcher to support -XshowSettings:system (as in later JDKs). Bug: https://bugs.openjdk.java.net/browse/JDK-8203357 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/01/webrev/ Testing: Included docker tests on Linux x86_64. All pass. Though, they are in dire need of reliability improvements which I'll work on as a follow-up. Thanks, Severin From sgehwolf at redhat.com Thu Jul 16 17:11:14 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 Jul 2020 19:11:14 +0200 Subject: OpenJDK 8u262 Released In-Reply-To: <84698ae5-d44f-8b91-4bba-a9217069325c@redhat.com> References: <84698ae5-d44f-8b91-4bba-a9217069325c@redhat.com> Message-ID: On Wed, 2020-07-15 at 15:45 +0100, Andrew Hughes wrote: > We are pleased to announce the release of OpenJDK 8u262. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u262-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u262-ga.tar.xz.sig > > This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F The binaries to go with this are here: https://adoptopenjdk.net/upstream.html?variant=openjdk8&jvmVariant=hotspot Thanks, Severin From gnu.andrew at redhat.com Thu Jul 16 18:06:20 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 16 Jul 2020 19:06:20 +0100 Subject: [8u] RFR(T) 8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public In-Reply-To: References: Message-ID: <9e77edc8-dd43-9740-1428-230347830b8a@redhat.com> On 16/07/2020 13:42, Zhengyu Gu wrote: > Please review this trivial patch that makes > sun.security.krb5.Config.getBooleanObject(String... keys) a public method. > > The method was introduced by JDK-8029995 in jdk9, as a public method, > but made a private method by JDK-8029995 8u backport. > > This blocks JDK-8239385 8u backport. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8249610 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249610/webrev.00/ > > Test: > ? jdk_security > > Thanks, > > -Zhengyu > If you want 8239385 to be clean, this one needs to just make the access change, and not alter the copyright :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Thu Jul 16 18:10:21 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Jul 2020 14:10:21 -0400 Subject: [8u] RFR(T) 8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public In-Reply-To: <9e77edc8-dd43-9740-1428-230347830b8a@redhat.com> References: <9e77edc8-dd43-9740-1428-230347830b8a@redhat.com> Message-ID: <9c093979-e375-fb4a-c1d1-5a72c428561b@redhat.com> On 7/16/20 2:06 PM, Andrew Hughes wrote: > > > On 16/07/2020 13:42, Zhengyu Gu wrote: >> Please review this trivial patch that makes >> sun.security.krb5.Config.getBooleanObject(String... keys) a public method. >> >> The method was introduced by JDK-8029995 in jdk9, as a public method, >> but made a private method by JDK-8029995 8u backport. >> >> This blocks JDK-8239385 8u backport. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8249610 >> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249610/webrev.00/ >> >> Test: >> ? jdk_security >> >> Thanks, >> >> -Zhengyu >> > > If you want 8239385 to be clean, this one needs to just make the access > change, and not alter the copyright :-) Okay, I will revert copyright change. Can I count this as a review? Thanks, -Zhengyu > > Thanks, > From gnu.andrew at redhat.com Thu Jul 16 18:15:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 16 Jul 2020 19:15:11 +0100 Subject: [8u] RFR(T) 8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public In-Reply-To: <9c093979-e375-fb4a-c1d1-5a72c428561b@redhat.com> References: <9e77edc8-dd43-9740-1428-230347830b8a@redhat.com> <9c093979-e375-fb4a-c1d1-5a72c428561b@redhat.com> Message-ID: <60cb1d4f-5f19-2a22-6050-de97bd5c714f@redhat.com> On 16/07/2020 19:10, Zhengyu Gu wrote: > > > On 7/16/20 2:06 PM, Andrew Hughes wrote: >> >> >> On 16/07/2020 13:42, Zhengyu Gu wrote: >>> Please review this trivial patch that makes >>> sun.security.krb5.Config.getBooleanObject(String... keys) a public >>> method. >>> >>> The method was introduced by JDK-8029995 in jdk9, as a public method, >>> but made a private method by JDK-8029995 8u backport. >>> >>> This blocks JDK-8239385 8u backport. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8249610 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8249610/webrev.00/ >>> >>> Test: >>> ?? jdk_security >>> >>> Thanks, >>> >>> -Zhengyu >>> >> >> If you want 8239385 to be clean, this one needs to just make the access >> change, and not alter the copyright :-) > > Okay, I will revert copyright change. > > Can I count this as a review? > > Thanks, > > -Zhengyu > >> >> Thanks, >> > Yeah, Martin & I effectively already reviewed this in the 8239385 thread. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Thu Jul 16 18:32:08 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 16 Jul 2020 14:32:08 -0400 Subject: [8u] RFR(T) 8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public In-Reply-To: <60cb1d4f-5f19-2a22-6050-de97bd5c714f@redhat.com> References: <9e77edc8-dd43-9740-1428-230347830b8a@redhat.com> <9c093979-e375-fb4a-c1d1-5a72c428561b@redhat.com> <60cb1d4f-5f19-2a22-6050-de97bd5c714f@redhat.com> Message-ID: <2cdcd7f7-4aee-08fd-e2b8-30afed69451f@redhat.com> >>>> >>> >>> If you want 8239385 to be clean, this one needs to just make the access >>> change, and not alter the copyright :-) >> >> Okay, I will revert copyright change. >> >> Can I count this as a review? >> >> Thanks, >> >> -Zhengyu >> >>> >>> Thanks, >>> >> > > Yeah, Martin & I effectively already reviewed this in the 8239385 thread. Thanks, -Zhengyu > > Thanks, > From hohensee at amazon.com Thu Jul 16 18:50:21 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 16 Jul 2020 18:50:21 +0000 Subject: [8u] RFO (Request For Opinion) 7092821: Backport to jdk8u: JDK-7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck Message-ID: <1264110E-69AF-4945-8183-3284FD5FD001@amazon.com> One of our engineers would like to backport this patch because it improves performance, but it includes far more than just the changes to Provider.java necessary to get the performance improvement. In the context of moving to TLS 1.3, Martin referred to 7092821 in https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011763.html ?The classes/sun/security/ssl/SunJSSE.java file was not deleted -even though it has been modified by 8196584- and is an exception too. The reason is that this file includes changes from 7092821, which escape sun/security/ssl and would be better handled separately. We could have done file-replacement here and created a new Step to remove them, but it is probably not worth the effort. Note that 7092821 is required for parity with Oracle's JDK and will be introduced later. At some point in the future, there should be almost no differences with JDK 11.0.7's SunJSSE.java file.? Amazon has been running with just the changes to Provider.java for some time with no issues. Is there interest in a partial backport of just those changes? If not, is now the time to do a complete backport? Thanks, Paul From gnu.andrew at redhat.com Thu Jul 16 19:08:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 16 Jul 2020 20:08:16 +0100 Subject: [8u] RFO (Request For Opinion) 7092821: Backport to jdk8u: JDK-7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck In-Reply-To: <1264110E-69AF-4945-8183-3284FD5FD001@amazon.com> References: <1264110E-69AF-4945-8183-3284FD5FD001@amazon.com> Message-ID: On 16/07/2020 19:50, Hohensee, Paul wrote: > One of our engineers would like to backport this patch because it improves performance, but it includes far more than just the changes to Provider.java necessary to get the performance improvement. In the context of moving to TLS 1.3, Martin referred to 7092821 in > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011763.html > > > ?The classes/sun/security/ssl/SunJSSE.java file was not deleted -even > though it has been modified by 8196584- and is an exception too. The > reason is that this file includes changes from 7092821, which escape > sun/security/ssl and would be better handled separately. We could have > done file-replacement here and created a new Step to remove them, but it > is probably not worth the effort. Note that 7092821 is required for > parity with Oracle's JDK and will be introduced later. At some point in > the future, there should be almost no differences with JDK 11.0.7's > SunJSSE.java file.? > > Amazon has been running with just the changes to Provider.java for some time with no issues. Is there interest in a partial backport of just those changes? If not, is now the time to do a complete backport? > > Thanks, > Paul > > For the OpenJDK 11.0.8 release, we had to include a last minute regression fix (JDK-8248505) for a bug (JDK-8246613) which itself was a late regression fix for JDK-7092821. With that in mind, I'd like this to be out in the wild longer before it is considered for a stable JDK like 8u. The experience with 11u suggests that, even though 7092821 went into 12u, its full impact wasn't felt until it was in an LTS JDK (11u). In general, I think there should be a very good case (certainly greater than parity) for including a performance enhancement in a stable release. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From david.holmes at oracle.com Thu Jul 16 22:30:20 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2020 08:30:20 +1000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> Message-ID: On 16/07/2020 11:43 pm, Andrew Haley wrote: > On 16/07/2020 10:16, David Holmes wrote: >> Seems to me that you want OrderAccess::loadload() barriers to order the >> loads, not OrderAccess::acquire(). You should only use acquire semantics >> to pair with a corresponding release operation. > > I agree, but it's unlikely to matter in practice. In terms of what underlying hardware barriers get used, no it won't (likely) matter in practice. But from a code understandability perspective it matters very much IMHO. We have been actively trying to ensure that the right OrderAccess APIs are used, in the right way and only where actually needed. An acquire without a corresponding release shows a lack of understanding and leads to confusion for other developers. If you need ordered loads then use a loadload() barrier. If the loads need to be ordered you need to ensure there are not corresponding writes that also need to be ordered - which may show where release() is missing. > Having said that, I'm strongly of the opinion that if you see a naked > StoreStore it may well be a bug, or at least you've got something very > hard to analyse. I know of a few cases (e.g. zeroing an object) where > this isn't true. > > https://www.hboehm.info/c++mm/no_write_fences.html, etc. > > But that's an argument for another day. Indeed :) Cheers, David From felix.yang at huawei.com Fri Jul 17 03:05:03 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 17 Jul 2020 03:05:03 +0000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> Message-ID: Hi, Thanks for the suggestions. It makes sense to me. BTW: OrderAccess::loadload() and OrderAccess::acquire() both map to the same instruction for aarch64: dmb ishld. Updated webrev: http://cr.openjdk.java.net/~fyang/8248851-8u/webrev.01/ http://cr.openjdk.java.net/~fyang/8248851-11u/webrev.01/ http://cr.openjdk.java.net/~fyang/8248851-13u/webrev.01/ Performed the same test as before, result looks good. Does it look better? Felix > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, July 17, 2020 6:30 AM > To: Andrew Haley ; Yangfei (Felix) > ; Kim Barrett > Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > aarch64-port-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > fences between free chunk check and klass read > > On 16/07/2020 11:43 pm, Andrew Haley wrote: > > On 16/07/2020 10:16, David Holmes wrote: > >> Seems to me that you want OrderAccess::loadload() barriers to order > >> the loads, not OrderAccess::acquire(). You should only use acquire > >> semantics to pair with a corresponding release operation. > > > > I agree, but it's unlikely to matter in practice. > > In terms of what underlying hardware barriers get used, no it won't > (likely) matter in practice. > > But from a code understandability perspective it matters very much IMHO. > We have been actively trying to ensure that the right OrderAccess APIs are > used, in the right way and only where actually needed. An acquire without a > corresponding release shows a lack of understanding and leads to confusion > for other developers. If you need ordered loads then use a > loadload() barrier. If the loads need to be ordered you need to ensure there > are not corresponding writes that also need to be ordered - which may show > where release() is missing. > > > Having said that, I'm strongly of the opinion that if you see a naked > > StoreStore it may well be a bug, or at least you've got something very > > hard to analyse. I know of a few cases (e.g. zeroing an object) where > > this isn't true. > > > > https://www.hboehm.info/c++mm/no_write_fences.html, etc. > > > > But that's an argument for another day. > > Indeed :) > > Cheers, > David From david.holmes at oracle.com Fri Jul 17 04:51:35 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Jul 2020 14:51:35 +1000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> Message-ID: Hi Felix, On 17/07/2020 1:05 pm, Yangfei (Felix) wrote: > Hi, > > Thanks for the suggestions. It makes sense to me. > BTW: OrderAccess::loadload() and OrderAccess::acquire() both map to the same instruction for aarch64: dmb ishld. > Updated webrev: > http://cr.openjdk.java.net/~fyang/8248851-8u/webrev.01/ > http://cr.openjdk.java.net/~fyang/8248851-11u/webrev.01/ > http://cr.openjdk.java.net/~fyang/8248851-13u/webrev.01/ > > Performed the same test as before, result looks good. > Does it look better? It certainly looks better to me. (This code still puzzles me somewhat but I'm not going to expend more time trying to understand it more broadly.) Thanks, David ----- > Felix > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Friday, July 17, 2020 6:30 AM >> To: Andrew Haley ; Yangfei (Felix) >> ; Kim Barrett >> Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; >> aarch64-port-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net >> Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory >> fences between free chunk check and klass read >> >> On 16/07/2020 11:43 pm, Andrew Haley wrote: >>> On 16/07/2020 10:16, David Holmes wrote: >>>> Seems to me that you want OrderAccess::loadload() barriers to order >>>> the loads, not OrderAccess::acquire(). You should only use acquire >>>> semantics to pair with a corresponding release operation. >>> >>> I agree, but it's unlikely to matter in practice. >> >> In terms of what underlying hardware barriers get used, no it won't >> (likely) matter in practice. >> >> But from a code understandability perspective it matters very much IMHO. >> We have been actively trying to ensure that the right OrderAccess APIs are >> used, in the right way and only where actually needed. An acquire without a >> corresponding release shows a lack of understanding and leads to confusion >> for other developers. If you need ordered loads then use a >> loadload() barrier. If the loads need to be ordered you need to ensure there >> are not corresponding writes that also need to be ordered - which may show >> where release() is missing. >> >>> Having said that, I'm strongly of the opinion that if you see a naked >>> StoreStore it may well be a bug, or at least you've got something very >>> hard to analyse. I know of a few cases (e.g. zeroing an object) where >>> this isn't true. >>> >>> https://www.hboehm.info/c++mm/no_write_fences.html, etc. >>> >>> But that's an argument for another day. >> >> Indeed :) >> >> Cheers, >> David > From maoliang.ml at alibaba-inc.com Fri Jul 17 06:56:14 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Fri, 17 Jul 2020 14:56:14 +0800 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times In-Reply-To: <75FC11DA-FFAA-4979-8963-0E1257DD8265@amazon.com> References: <75FC11DA-FFAA-4979-8963-0E1257DD8265@amazon.com> Message-ID: <008d01d65c07$5d18c840$174a58c0$@alibaba-inc.com> Hi Paul, Thanks very much for your detailed review! I just upload the latest change. Could you please help to push if you are ok with it? http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.01/ Thanks, Liang From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: 2020?7?16? 22:30 To: Liang Mao ; 'jdk8u-dev' Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Using #ifndef INCLUDE_ALL_GCS is also a hack. :) I looked for uses of GenericTaskQueue::oops_do() in G1 and could find only one, in ConcurrentMark::verify_no_cset_oops(). In that context, it invokes VerifyNoCSetOopsClosure::do_object_work(), which is updated by the original patch. But, JDK 9 has two asserts rather than JDK 8?s single assert. The first JDK 9 assert is the G1-specific equivalent to the assert in TaskQueue::oops_do(). So, I'd add the first JDK 9 assert to your patch?s VerifyNoCSetOopsClosure::do_object_work(), vis guarantee(G1CMObjArrayProcessor::is_array_slice(obj) || obj->is_oop(), "Non-oop " PTR_FORMAT ", phase: %s, info: %d", p2i(obj), _phase, _info); and change the assert in TaskQueue::oops_do() to what you suggest (with a comment), vis // G1 does its own checking assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Paul ?On 7/15/20, 7:28 PM, "Liang Mao" > wrote: Hi Paul, In order to partially iterate the object array, the task queue will not only have oop but also "array slice" which is not oop. But inserting G1 specific code into taskqueue.hpp as below seems a little bit hacking: + assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null"); In JDK9, the oops_do() is already replaced by a common general iterate() which won't have that assertion. Do you think changing the assertion as below is better? -assert((*t)->is_oop_or_null(), "Not an oop or null"); +assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Liang > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: 2020?7?16? 5:39 > To: Liang Mao >; jdk8u-dev dev at openjdk.java.net > > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks > like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the > serial collector is the only collector being compiled into Hotspot, so with your > change the assert only gets compiled for that case. Is a taskqueue ever > instantiated for that case? > > Thanks, > Paul > > On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com > wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > > Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time and > hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small patch, I > didn't change much except some assertions. One assertion in taskqueue.hpp > is removed. It should be ok because it's no longer there as well since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > From felix.yang at huawei.com Fri Jul 17 08:40:58 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 17 Jul 2020 08:40:58 +0000 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> Message-ID: Hi, Thanks for reviewing this and the great comments. I have put fix-request labels and accompanying comments on this issue for these three repos. Felix > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Friday, July 17, 2020 12:52 PM > To: Yangfei (Felix) ; Andrew Haley > ; Kim Barrett > Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > aarch64-port-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > fences between free chunk check and klass read > > Hi Felix, > > On 17/07/2020 1:05 pm, Yangfei (Felix) wrote: > > Hi, > > > > Thanks for the suggestions. It makes sense to me. > > BTW: OrderAccess::loadload() and OrderAccess::acquire() both map to > the same instruction for aarch64: dmb ishld. > > Updated webrev: > > http://cr.openjdk.java.net/~fyang/8248851-8u/webrev.01/ > > http://cr.openjdk.java.net/~fyang/8248851-11u/webrev.01/ > > http://cr.openjdk.java.net/~fyang/8248851-13u/webrev.01/ > > > > Performed the same test as before, result looks good. > > Does it look better? > > It certainly looks better to me. (This code still puzzles me somewhat but I'm > not going to expend more time trying to understand it more broadly.) > > Thanks, > David > ----- > > > Felix > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Friday, July 17, 2020 6:30 AM > >> To: Andrew Haley ; Yangfei (Felix) > >> ; Kim Barrett > >> Cc: jdk8u-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; > >> aarch64-port-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net > >> Subject: Re: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory > >> fences between free chunk check and klass read > >> > >> On 16/07/2020 11:43 pm, Andrew Haley wrote: > >>> On 16/07/2020 10:16, David Holmes wrote: > >>>> Seems to me that you want OrderAccess::loadload() barriers to order > >>>> the loads, not OrderAccess::acquire(). You should only use acquire > >>>> semantics to pair with a corresponding release operation. > >>> > >>> I agree, but it's unlikely to matter in practice. > >> > >> In terms of what underlying hardware barriers get used, no it won't > >> (likely) matter in practice. > >> > >> But from a code understandability perspective it matters very much IMHO. > >> We have been actively trying to ensure that the right OrderAccess > >> APIs are used, in the right way and only where actually needed. An > >> acquire without a corresponding release shows a lack of understanding > >> and leads to confusion for other developers. If you need ordered > >> loads then use a > >> loadload() barrier. If the loads need to be ordered you need to > >> ensure there are not corresponding writes that also need to be > >> ordered - which may show where release() is missing. > >> > >>> Having said that, I'm strongly of the opinion that if you see a > >>> naked StoreStore it may well be a bug, or at least you've got > >>> something very hard to analyse. I know of a few cases (e.g. zeroing > >>> an object) where this isn't true. > >>> > >>> https://www.hboehm.info/c++mm/no_write_fences.html, etc. > >>> > >>> But that's an argument for another day. > >> > >> Indeed :) > >> > >> Cheers, > >> David > > From zgu at redhat.com Fri Jul 17 13:50:37 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 17 Jul 2020 09:50:37 -0400 Subject: [8u] RFR 8246193: Possible NPE in ENC-PA-REP search in AS-REQ Message-ID: Hi, I would like to backport this to 8u for parity with Oracle 8u271. Original patch did not apply cleanly. The only conflict was copyright line of KDC.java. However, the new test (AlwaysEncPaReq.java) used new feature, introduced by JDK-8134577 from jdk9, which is not in jdk8u. Therefore, I implemented FakeNameService in test to replace file based DNS lookup mechanism in original test. Original bug: https://bugs.openjdk.java.net/browse/JDK-8246193 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/7136c4d29901 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8246193-8u/webrev.00/ Test: jdk_security (includes new test) Thanks, -Zhengyu From sgehwolf at redhat.com Fri Jul 17 14:07:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 Jul 2020 16:07:45 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware Message-ID: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> Hi, Please review this OpenJDK 8u backport for OperatingSystemMXBean's container awareness which has been backported to Oracle JDK (parity bug). This backport depends on JDK-8203357[1] for Metrics.java which is being used in this patch. Changes as compared to the JDK 11 patch were: * SubSystem.java: 8217338: [Containers] Improve systemd slice memory limit support not being there => getLongValueMatchingLine() missing => dropped * OperatingSystemImpl.java: Introduced Java methods which internally call the native methods. Renamed native methods to 0 * Tests were actually done to the hotspot code in later JDKs, thus, for this backport the tests are in the hotspot portion of the webrev (separate repo). * Other than that, it's just the native bits which are in different files in JDK 8. Bug: https://bugs.openjdk.java.net/browse/JDK-8226575 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 Testing: Included docker tests on Linux x86_64. jdk_management tests and tier 1 tests. No regressions noted. If somebody could test this on Windows/Mac, I'd appreciate it. Thanks, Severin [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html From hohensee at amazon.com Fri Jul 17 14:46:38 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 17 Jul 2020 14:46:38 +0000 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Message-ID: <7C96E000-B255-4A5C-8CA1-8084308FB9E2@amazon.com> I?d change the oops_do() comment to // G1 does its own checking because the assert has a general G1 check (i.e., UseG1GC) rather than a specific one. All uses of oops_do() by G1 will have to do their own checks, not just the array slice case that your current comment says. Other than that, lgtm. I?ll sponsor the patch and add a ?reviewed? comment to the issue. Thanks, Paul From: Liang Mao Date: Thursday, July 16, 2020 at 11:58 PM To: "Hohensee, Paul" , 'jdk8u-dev' Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Hi Paul, Thanks very much for your detailed review! I just upload the latest change. Could you please help to push if you are ok with it? http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.01/ Thanks, Liang From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: 2020?7?16? 22:30 To: Liang Mao ; 'jdk8u-dev' Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Using #ifndef INCLUDE_ALL_GCS is also a hack. :) I looked for uses of GenericTaskQueue::oops_do() in G1 and could find only one, in ConcurrentMark::verify_no_cset_oops(). In that context, it invokes VerifyNoCSetOopsClosure::do_object_work(), which is updated by the original patch. But, JDK 9 has two asserts rather than JDK 8?s single assert. The first JDK 9 assert is the G1-specific equivalent to the assert in TaskQueue::oops_do(). So, I'd add the first JDK 9 assert to your patch?s VerifyNoCSetOopsClosure::do_object_work(), vis guarantee(G1CMObjArrayProcessor::is_array_slice(obj) || obj->is_oop(), "Non-oop " PTR_FORMAT ", phase: %s, info: %d", p2i(obj), _phase, _info); and change the assert in TaskQueue::oops_do() to what you suggest (with a comment), vis // G1 does its own checking assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Paul On 7/15/20, 7:28 PM, "Liang Mao" > wrote: Hi Paul, In order to partially iterate the object array, the task queue will not only have oop but also "array slice" which is not oop. But inserting G1 specific code into taskqueue.hpp as below seems a little bit hacking: + assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null"); In JDK9, the oops_do() is already replaced by a common general iterate() which won't have that assertion. Do you think changing the assertion as below is better? -assert((*t)->is_oop_or_null(), "Not an oop or null"); +assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Liang > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: 2020?7?16? 5:39 > To: Liang Mao >; jdk8u-dev dev at openjdk.java.net> > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks > like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the > serial collector is the only collector being compiled into Hotspot, so with your > change the assert only gets compiled for that case. Is a taskqueue ever > instantiated for that case? > > Thanks, > Paul > > On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > > Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time and > hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small patch, I > didn't change much except some assertions. One assertion in taskqueue.hpp > is removed. It should be ok because it's no longer there as well since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > From akozlov at azul.com Fri Jul 17 17:46:44 2020 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 17 Jul 2020 20:46:44 +0300 Subject: [8u] Regression after JDK-8237117: Better ForkJoinPool behavior Message-ID: [another attempt without attachments] Hi, backport of JDK-8237117 [1] apparently introduces a regression. It was found during runs of running lucene-solr 8.2.0 [2]. The problem reproduces on a simpler example (can be found in attachments to JDK-8249677) on openjdk8u262-b10[3], but doesn't reproduce on openjdk8u252-b09[4]. When I comment out line [5], the lucene-solr test and the provided reproducer passes. The change original version is [6]. Newer JDKs have two package private constructors ForkJoinWorkerThread, that call base protected constructor and then initialize inherited ACC to the INNOCUOUS_ACC. When users subclass ForkJoinWorkerThread, they are free to provide any ACC, which is by default is the current ACC. Same was in 8u until backport of JDK-8237117, which changes default ACC to INNOCUOUS_ACC instead of the current one. The backport in 8u is also inconsistent with one in jdk11u[7], which does not change ACC in the protected constructor. The reproducer also passes on openjdk11.0.8 [8], which do have own backport of the original patch. Please discuss. It doesn't look the 8u backport is correct. I've opened JDK-8249677 to track the issue Thanks, Anton [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe [2] https://github.com/apache/lucene-solr/commit/31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe [3] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b10 [4] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u252-b09 [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe#l1.19 [6] https://hg.openjdk.java.net/jdk/jdk/rev/50d5266f275f [7] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/0e9eb367df7a/src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l92 [8] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.8%2B10 From sgehwolf at redhat.com Fri Jul 17 17:57:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 17 Jul 2020 19:57:42 +0200 Subject: [8u] RFR: 8078450: Implement consistent process for quarantine of tests Message-ID: <6e7bc811f4d3c33dba54427580df319de5838988.camel@redhat.com> Hi, Please review this test-only patch which introduces a ProblemList.txt for the hotspot tests to 8u. My goal with this would be to problem list rtm tests in hotspot to get a cleaner tier1 run. The original patch doesn't apply as it was done in JDK 9 with a different set of tests (where @ignore keyword is removed) and because the test setup is slightly differnt in OpenJDK 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8078450 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8078450/jdk8/01/webrev/ original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1b0d8f3d0bb3 Testing: make test TEST="hotspot_tier1" before and after. No difference. Thoughts? Thanks, Severin From akozlov at azul.com Fri Jul 17 17:32:12 2020 From: akozlov at azul.com (Anton Kozlov) Date: Fri, 17 Jul 2020 20:32:12 +0300 Subject: [8u] Regression after JDK-8237117: Better ForkJoinPool behavior Message-ID: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> Hi, backport of JDK-8237117 [1] apparently introduces a regression. It was found during runs of running lucene-solr 8.2.0 [2]. The problem reproduces on a simpler example (in attach) on openjdk8u262-b10[3], but doesn't reproduce on openjdk8u252-b09[4]. When I comment out line [5], the lucene-solr test and the provided reproducer passes. The change original version is [6]. Newer JDKs have two package private constructors ForkJoinWorkerThread, that call base protected constructor and then initialize inherited ACC to the INNOCUOUS_ACC. When users subclass ForkJoinWorkerThread, they are free to provide any ACC, which is by default is the current ACC. Same was in 8u until backport of JDK-8237117, which changes default ACC to INNOCUOUS_ACC instead of the current one. The backport in 8u is also inconsistent with one in jdk11u[7], which does not change ACC in the protected constructor. The reproducer also passes on openjdk11.0.8 [8], which do have own backport of the original patch. Please discuss. It doesn't look the 8u backport is correct. I've opened JDK-8249677 to track the issue Thanks, Anton [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe [2] https://github.com/apache/lucene-solr/commit/31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe [3] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b10 [4] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u252-b09 [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe#l1.19 [6] https://hg.openjdk.java.net/jdk/jdk/rev/50d5266f275f [7] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/0e9eb367df7a/src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l92 [8] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.8%2B10 From andrey at azul.com Fri Jul 17 18:44:47 2020 From: andrey at azul.com (Andrey Petushkov) Date: Fri, 17 Jul 2020 21:44:47 +0300 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> Message-ID: <1e60b154-8c09-91d2-65c7-c4f283b0f407@azul.com> Hi Severin, The code being backported seem to have a bug and will result in a regression if being integrated. The problem is that, to my understanding it's legal that only some of known controllers are mounted (at least man says they can be mounted individually). This creates a situation that Metrics gets "active" and populated with some of SubSystems, but not all. As a result OperatingSystemImpl considers containerMetrics available and uses it as a source. The SubSystem code is written the way that it returns 0 for any value if a respective subsystem is missing. At the same time OperatingSystemImpl typically uses >=0 as a sanity check of a value returned from Metrics. Effectively preventing from falling back to native implementation for the actual value and returning 0 instead of actual value The problem actually exhibited by GetTotalPhysicalMemorySize test ran on Raspbian Stretch which happen to have cgroup fs but not /sys/fs/cgroup/memory That's not the problem of a backport and of course should be discussed with upstream developers. It just happened that we've found it with a backport so letting you know Regards, Andrey On 17.07.2020 17:07, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > container awareness which has been backported to Oracle JDK (parity > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > being used in this patch. > > Changes as compared to the JDK 11 patch were: > > * SubSystem.java: 8217338: [Containers] Improve systemd slice memory > limit support not being there => getLongValueMatchingLine() missing > => dropped > * OperatingSystemImpl.java: Introduced Java methods which internally > call the native methods. Renamed native methods to 0 > * Tests were actually done to the hotspot code in later JDKs, thus, > for this backport the tests are in the hotspot portion of the webrev > (separate repo). > * Other than that, it's just the native bits which are in different > files in JDK 8. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226575 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 > > Testing: Included docker tests on Linux x86_64. jdk_management tests and > tier 1 tests. No regressions noted. > > If somebody could test this on Windows/Mac, I'd appreciate it. > > Thanks, > Severin > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html From alexey at azul.com Fri Jul 17 20:32:19 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 17 Jul 2020 20:32:19 +0000 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> Message-ID: Hello Martin, Thank you for updated review It looks much cleaner then my version. I didn?t finish review yet but I was able to build and test it with sun/security/ssl/krb5/auto jtreg tests For now I?ve found just two issues: 1. You have updated the list of classes in the sun/security/ssl/krb5 package. These classes are the bridge to JGSS/KRB5 implementation. The compact profile 1 does not include JGSS/KRB5 implementation, so build scripts verifies references to removed packages. Exceptions are described in the make/data/checkdeps/refs.allowed script. This script should be updated with new class names. Otherwise it fails during profiles creation. 2. Three kerberos test failed because of server can not select KRB5 cipher suite. It happens because of server principal name is not specified (it?s allowed behaviour). As result implementation does not create possession and corresponding cipher suite is not selected. I suggest to create possession even if no serverPrincipal returned, similar to original implementation. The code could be update like following in the KrbKeyExchange.java: @@ -91,7 +91,6 @@ final class KrbKeyExchange { } return null; } - return new KrbServiceCreds(serviceCreds); } } } catch (PrivilegedActionException e) { @@ -100,8 +99,9 @@ final class KrbKeyExchange { SSLLogger.fine("Attempt to obtain Kerberos key failed: " + e.toString()); } + return null; } - return null; + return (serviceCreds != null)?new KrbServiceCreds(serviceCreds):null; } } With these changes all sun/security/ssl/krb5/auto test passed. Regards Alexey > On 15 Jul 2020, at 03:28, Martin Balao wrote: > > On 7/6/20 5:45 PM, Martin Balao wrote: >> >> Oh, good point! Hmm... let me give this some more thought, because I >> still find it confusing. >> > > Hi, > > I'd like to propose Webrev.02: > > * http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.02/ > From preethi.s at hcl.com Wed Jul 15 05:34:27 2020 From: preethi.s at hcl.com (Preethi Selvaraju) Date: Wed, 15 Jul 2020 05:34:27 +0000 Subject: jdk8u in Solaris 10 build errors with enable-jfr=yes Message-ID: Hi Team, Have pulled latest jdk8u content from http://hg.openjdk.java.net/jdk8u/jdk8u/. When I build in Solaris 10, getting the below error with -enable-jfr=yes. Compiling /export/home/preethi/jdk8u15_7/hotspot/src/share/vm/services/attachListener.cpp "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 50: Error: r8 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 51: Error: r9 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 52: Error: r10 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 53: Error: r11 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 57: Error: r11 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 58: Error: r10 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 59: Error: r9 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 60: Error: r8 is not defined. 8 Error(s) detected. gmake[6]: *** [assembler_solaris_x86.o] Error 2 gmake[6]: *** Waiting for unfinished jobs.... gmake[5]: *** [the_vm] Error 2 gmake[4]: *** [product] Error 2 gmake[3]: *** [generic_build2] Error 2 gmake[2]: *** [product] Error 2 gmake[1]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/hotspot/_hotspot.timestamp] Error 2 gmake: *** [hotspot-only] Error 2 OS: Solaris 10 /etc/release: Solaris version: Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 bash-3.2# isainfo -b 64 Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 32 Tools summary: * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode) (at /jdk1.7.0_241) * Toolchain: solstudio (Oracle Solaris Studio) * C Compiler: Version 5.13 (at /opt/solarisstudio12.4/bin/cc) * C++ Compiler: Version 5.13 (at /opt/solarisstudio12.4/bin/CC) Build performance summary: * Cores to use: 5 * Memory limit: 32723 MB 1) Do we always need to enable jfr ie, --enable-jfr=yes. If I don't give this option/give as no, compilation errors am getting and not proceeding further. "/export/home/preethi/openjdk8u/hotspot/src/share/vm/runtime/thread.hpp", line 202: Warning: Identifier expected instead of "}". 1 Warning(s) detected. 2) "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", commented out r8,r9,r10 and r11. After that, below errors: "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 54: (struct) tag redeclared: _XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 57: identifier redeclared: XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 54: (struct) tag redeclared: _XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 57: identifier redeclared: XLinearGradient current : struct _XLinearGradient {..} previous: struct _XLinearGradient {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 189 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 61: (struct) tag redeclared: _XCircle "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 65: identifier redeclared: XCircle current : struct _XCircle {..} previous: struct _XCircle {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 150 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 67: (struct) tag redeclared: _XRadialGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 70: identifier redeclared: XRadialGradient current : struct _XRadialGradient {..} previous: struct _XRadialGradient {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 194 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 332: warning: declaration can not follow a statement "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 820: warning: declaration can not follow a statement "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 821: warning: declaration can not follow a statement cc: acomp failed for /export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c gmake[2]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/libawt_xawt/XRBackendNative.o] Error 2 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [libs-only] Error 2 gmake: *** [jdk-only] Error 2 ? After commenting out XLinearGradient, XCircle and XRadialGradient structures in "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", finally I end up with the below error: "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c", line 329: warning: declaration can not follow a statement ld: warning: mapfile: text segment: section '.text%_init' does not appear in any input file ld: warning: mapfile: text segment: section '.text%init64IO' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%setPathEnvironment' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%Java_java_io_FileSystem_getFileSystem' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_io_UnixFileSystem_canonicalize' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_ClassLoader_findLoadedClass' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Float_floatToIntBits' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Double_doubleToLongBits' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Shutdown_halt' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_util_logging_FileHandler_lockFile' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_util_logging_FileHandler_unlockFile' does not appear in any input file ld: warning: mapfile: text segment: section '.text%readLOC' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%huft_build' does not appear in mapfile specified input file(s) Undefined first referenced symbol in file _IO_stdin_used /export/home/preethi/jdk8u15_7/jdk/make/mapfiles/launchers/mapfile-x86 __xargv /opt/solarisstudio12.4/lib/compilers/crt1x.o (symbol has no version assigned) __xargc /opt/solarisstudio12.4/lib/compilers/crt1x.o (symbol has no version assigned) ld: fatal: symbol referencing errors. No output written to /export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/java_objs/java gmake[2]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/java_objs/java] Error 2 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [launchers-only] Error 2 gmake: *** [jdk-only] Error 2 All the tools(X11, cups, cups_dev,freetype), I've installed from opencsw. ? ld path as /usr/ccs/bin/ld ? vi /opt/solarisstudio12.4/lib/compilers/CC-gcc/gcc_version.map $mapfile_version 2 ? /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1514 Can you help me what is going wrong in this? Do I need to install/configure anything else. If this is not the right forum to ask, kindly excuse and point me the right direction. Regards, Preethi ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ From preethi.s at hcl.com Fri Jul 17 10:03:09 2020 From: preethi.s at hcl.com (Preethi Selvaraju) Date: Fri, 17 Jul 2020 10:03:09 +0000 Subject: jdk8u in Solaris 10 build errors with enable-jfr=yes In-Reply-To: References: Message-ID: Hi Team, In the same Solaris 10 system, tried to build latest jdk8u for 64-bit, it's working fine. As far as I know, if we give -with-target-bits=32, it should work fine for 32-bit also. I've tried with Solaris studio 12.3 and Solaris studio 12.4. Please do help me, if it is not the right forum, if possible, Kindly point out the correct mailing list. Regards, Preethi From: Preethi Selvaraju Sent: Wednesday, July 15, 2020 11:04 AM To: jdk8u-dev at openjdk.java.net Subject: jdk8u in Solaris 10 build errors with enable-jfr=yes Hi Team, Have pulled latest jdk8u content from http://hg.openjdk.java.net/jdk8u/jdk8u/. When I build in Solaris 10, getting the below error with -enable-jfr=yes. Compiling /export/home/preethi/jdk8u15_7/hotspot/src/share/vm/services/attachListener.cpp "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 50: Error: r8 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 51: Error: r9 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 52: Error: r10 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 53: Error: r11 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 57: Error: r11 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 58: Error: r10 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 59: Error: r9 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 60: Error: r8 is not defined. 8 Error(s) detected. gmake[6]: *** [assembler_solaris_x86.o] Error 2 gmake[6]: *** Waiting for unfinished jobs.... gmake[5]: *** [the_vm] Error 2 gmake[4]: *** [product] Error 2 gmake[3]: *** [generic_build2] Error 2 gmake[2]: *** [product] Error 2 gmake[1]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/hotspot/_hotspot.timestamp] Error 2 gmake: *** [hotspot-only] Error 2 OS: Solaris 10 /etc/release: Solaris version: Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 bash-3.2# isainfo -b 64 Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 32 Tools summary: * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode) (at /jdk1.7.0_241) * Toolchain: solstudio (Oracle Solaris Studio) * C Compiler: Version 5.13 (at /opt/solarisstudio12.4/bin/cc) * C++ Compiler: Version 5.13 (at /opt/solarisstudio12.4/bin/CC) Build performance summary: * Cores to use: 5 * Memory limit: 32723 MB 1) Do we always need to enable jfr ie, --enable-jfr=yes. If I don't give this option/give as no, compilation errors am getting and not proceeding further. "/export/home/preethi/openjdk8u/hotspot/src/share/vm/runtime/thread.hpp", line 202: Warning: Identifier expected instead of "}". 1 Warning(s) detected. 2) "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", commented out r8,r9,r10 and r11. After that, below errors: "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 54: (struct) tag redeclared: _XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 57: identifier redeclared: XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 54: (struct) tag redeclared: _XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 57: identifier redeclared: XLinearGradient current : struct _XLinearGradient {..} previous: struct _XLinearGradient {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 189 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 61: (struct) tag redeclared: _XCircle "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 65: identifier redeclared: XCircle current : struct _XCircle {..} previous: struct _XCircle {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 150 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 67: (struct) tag redeclared: _XRadialGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 70: identifier redeclared: XRadialGradient current : struct _XRadialGradient {..} previous: struct _XRadialGradient {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 194 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 332: warning: declaration can not follow a statement "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 820: warning: declaration can not follow a statement "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 821: warning: declaration can not follow a statement cc: acomp failed for /export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c gmake[2]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/libawt_xawt/XRBackendNative.o] Error 2 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [libs-only] Error 2 gmake: *** [jdk-only] Error 2 ? After commenting out XLinearGradient, XCircle and XRadialGradient structures in "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", finally I end up with the below error: "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c", line 329: warning: declaration can not follow a statement ld: warning: mapfile: text segment: section '.text%_init' does not appear in any input file ld: warning: mapfile: text segment: section '.text%init64IO' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%setPathEnvironment' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%Java_java_io_FileSystem_getFileSystem' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_io_UnixFileSystem_canonicalize' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_ClassLoader_findLoadedClass' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Float_floatToIntBits' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Double_doubleToLongBits' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Shutdown_halt' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_util_logging_FileHandler_lockFile' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_util_logging_FileHandler_unlockFile' does not appear in any input file ld: warning: mapfile: text segment: section '.text%readLOC' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%huft_build' does not appear in mapfile specified input file(s) Undefined first referenced symbol in file _IO_stdin_used /export/home/preethi/jdk8u15_7/jdk/make/mapfiles/launchers/mapfile-x86 __xargv /opt/solarisstudio12.4/lib/compilers/crt1x.o (symbol has no version assigned) __xargc /opt/solarisstudio12.4/lib/compilers/crt1x.o (symbol has no version assigned) ld: fatal: symbol referencing errors. No output written to /export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/java_objs/java gmake[2]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/java_objs/java] Error 2 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [launchers-only] Error 2 gmake: *** [jdk-only] Error 2 All the tools(X11, cups, cups_dev,freetype), I've installed from opencsw. ? ld path as /usr/ccs/bin/ld ? vi /opt/solarisstudio12.4/lib/compilers/CC-gcc/gcc_version.map $mapfile_version 2 ? /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1514 Can you help me what is going wrong in this? Do I need to install/configure anything else. If this is not the right forum to ask, kindly excuse and point me the right direction. Regards, Preethi ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________ From kim.barrett at oracle.com Sat Jul 18 06:43:39 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 18 Jul 2020 02:43:39 -0400 Subject: [aarch64-port-dev ] RFR(S): 8248851: CMS: Missing memory fences between free chunk check and klass read In-Reply-To: References: <8957BB9E-617D-4E24-9CC4-31AF7D01D12E@oracle.com> <65012FED-2A93-4899-939E-887175AB07AC@oracle.com> <06646cf3-bc21-977f-96e2-1e9a974d1b00@redhat.com> <48d0abe9-29a1-a67f-b8f0-c823e15ce110@oracle.com> <561611d4-18aa-f9d8-7302-3d89aff4ad81@redhat.com> Message-ID: > On Jul 16, 2020, at 11:05 PM, Yangfei (Felix) wrote: > > Hi, > > Thanks for the suggestions. It makes sense to me. > BTW: OrderAccess::loadload() and OrderAccess::acquire() both map to the same instruction for aarch64: dmb ishld. > Updated webrev: > http://cr.openjdk.java.net/~fyang/8248851-8u/webrev.01/ > http://cr.openjdk.java.net/~fyang/8248851-11u/webrev.01/ > http://cr.openjdk.java.net/~fyang/8248851-13u/webrev.01/ > > Performed the same test as before, result looks good. > Does it look better? Looks good. From dl at cs.oswego.edu Sun Jul 19 11:26:34 2020 From: dl at cs.oswego.edu (Doug Lea) Date: Sun, 19 Jul 2020 07:26:34 -0400 Subject: [8u] Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> Message-ID: <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> Sorry that we missed noticing this change, which also conflicts with jsr166 jdk8 version. I am also puzzled why the ForkJoinWorkerThread constructor was changed to ignore the acc argument. Unless there is some good reason for changing (in some different way), it should be reverted back to: ??? ForkJoinWorkerThread(ForkJoinPool pool, ThreadGroup threadGroup, ???????????????????????? AccessControlContext acc) { ??????? super(threadGroup, null, "aForkJoinWorkerThread"); ??????? U.putOrderedObject(this, INHERITEDACCESSCONTROLCONTEXT, acc); ??????? eraseThreadLocals(); // clear before registering ??????? this.pool = pool; ??????? this.workQueue = pool.registerWorker(this); ??? } On 7/17/20 1:32 PM, Anton Kozlov wrote: > Hi, > > backport of JDK-8237117 [1] apparently introduces a regression. > > It was found during runs of running lucene-solr 8.2.0 [2]. > The problem reproduces on a simpler example (in attach) on openjdk8u262-b10[3], but doesn't reproduce on openjdk8u252-b09[4]. > > When I comment out line [5], the lucene-solr test and the provided reproducer passes. > > The change original version is [6]. > Newer JDKs have two package private constructors ForkJoinWorkerThread, that call base protected constructor and then initialize inherited ACC to the INNOCUOUS_ACC. > When users subclass ForkJoinWorkerThread, they are free to provide any ACC, which is by default is the current ACC. > Same was in 8u until backport of JDK-8237117, which changes default ACC to INNOCUOUS_ACC instead of the current one. > > The backport in 8u is also inconsistent with one in jdk11u[7], which does not change ACC in the protected constructor. > The reproducer also passes on openjdk11.0.8 [8], which do have own backport of the original patch. > > Please discuss. It doesn't look the 8u backport is correct. > > I've opened JDK-8249677 to track the issue > > Thanks, > Anton > > [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe > [2] https://github.com/apache/lucene-solr/commit/31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe > [3] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b10 > [4] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u252-b09 > [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe#l1.19 > [6] https://hg.openjdk.java.net/jdk/jdk/rev/50d5266f275f > [7] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/0e9eb367df7a/src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l92 > [8] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.8%2B10 From chris.hegarty at oracle.com Sun Jul 19 21:37:13 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 19 Jul 2020 22:37:13 +0100 Subject: [8u] Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> Message-ID: <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> I added a comment to the JIRA issue. Looks like an error with the backport. -Chris. > On 19 Jul 2020, at 12:26, Doug Lea

wrote: > > Sorry that we missed noticing this change, which also conflicts with jsr166 jdk8 version. I am also puzzled why the ForkJoinWorkerThread constructor was changed to ignore the acc argument. Unless there is some good reason for changing (in some different way), it should be reverted back to: > > ForkJoinWorkerThread(ForkJoinPool pool, ThreadGroup threadGroup, > AccessControlContext acc) { > super(threadGroup, null, "aForkJoinWorkerThread"); > U.putOrderedObject(this, INHERITEDACCESSCONTROLCONTEXT, acc); > eraseThreadLocals(); // clear before registering > this.pool = pool; > this.workQueue = pool.registerWorker(this); > } > > On 7/17/20 1:32 PM, Anton Kozlov wrote: >> Hi, >> >> backport of JDK-8237117 [1] apparently introduces a regression. >> >> It was found during runs of running lucene-solr 8.2.0 [2]. >> The problem reproduces on a simpler example (in attach) on openjdk8u262-b10[3], but doesn't reproduce on openjdk8u252-b09[4]. >> >> When I comment out line [5], the lucene-solr test and the provided reproducer passes. >> >> The change original version is [6]. >> Newer JDKs have two package private constructors ForkJoinWorkerThread, that call base protected constructor and then initialize inherited ACC to the INNOCUOUS_ACC. >> When users subclass ForkJoinWorkerThread, they are free to provide any ACC, which is by default is the current ACC. >> Same was in 8u until backport of JDK-8237117, which changes default ACC to INNOCUOUS_ACC instead of the current one. >> >> The backport in 8u is also inconsistent with one in jdk11u[7], which does not change ACC in the protected constructor. >> The reproducer also passes on openjdk11.0.8 [8], which do have own backport of the original patch. >> >> Please discuss. It doesn't look the 8u backport is correct. >> >> I've opened JDK-8249677 to track the issue >> >> Thanks, >> Anton >> >> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe >> [2] https://github.com/apache/lucene-solr/commit/31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe >> [3] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b10 >> [4] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u252-b09 >> [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe#l1.19 >> [6] https://hg.openjdk.java.net/jdk/jdk/rev/50d5266f275f >> [7] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/0e9eb367df7a/src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l92 >> [8] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.8%2B10 From chris.hegarty at oracle.com Mon Jul 20 05:40:39 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 20 Jul 2020 06:40:39 +0100 Subject: [8u] Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> Message-ID: <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> > On 19 Jul 2020, at 22:37, Chris Hegarty wrote: > > I added a comment to the JIRA issue. Looks like an error with the backport. FTR, here is the aforementioned comment: --- The Oracle JDK does NOT change the behaviour of protected ForkJoinWorkerThread(ForkJoinPool) constructor. This issue does not duplicate on the Oracle jdk1.8.0_261 JDK. $ /Library/Java/JavaVirtualMachines/jdk1.8.0_261.jdk/Contents/Home/bin/javac Test.java $ /Library/Java/JavaVirtualMachines/jdk1.8.0_261.jdk/Contents/Home/bin/java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode) $ $ /Library/Java/JavaVirtualMachines/jdk1.8.0_261.jdk/Contents/Home/bin/java Test done $ --- A solution that reverts the change to the protected constructor, and adds a package-private constructor that does the necessary ACC restricting, in a similar way to that of the code in 11u, would appear most appropriate here. -Chris. > > -Chris. > >> On 19 Jul 2020, at 12:26, Doug Lea
wrote: >> >> Sorry that we missed noticing this change, which also conflicts with jsr166 jdk8 version. I am also puzzled why the ForkJoinWorkerThread constructor was changed to ignore the acc argument. Unless there is some good reason for changing (in some different way), it should be reverted back to: >> >> ForkJoinWorkerThread(ForkJoinPool pool, ThreadGroup threadGroup, >> AccessControlContext acc) { >> super(threadGroup, null, "aForkJoinWorkerThread"); >> U.putOrderedObject(this, INHERITEDACCESSCONTROLCONTEXT, acc); >> eraseThreadLocals(); // clear before registering >> this.pool = pool; >> this.workQueue = pool.registerWorker(this); >> } >> >> On 7/17/20 1:32 PM, Anton Kozlov wrote: >>> Hi, >>> >>> backport of JDK-8237117 [1] apparently introduces a regression. >>> >>> It was found during runs of running lucene-solr 8.2.0 [2]. >>> The problem reproduces on a simpler example (in attach) on openjdk8u262-b10[3], but doesn't reproduce on openjdk8u252-b09[4]. >>> >>> When I comment out line [5], the lucene-solr test and the provided reproducer passes. >>> >>> The change original version is [6]. >>> Newer JDKs have two package private constructors ForkJoinWorkerThread, that call base protected constructor and then initialize inherited ACC to the INNOCUOUS_ACC. >>> When users subclass ForkJoinWorkerThread, they are free to provide any ACC, which is by default is the current ACC. >>> Same was in 8u until backport of JDK-8237117, which changes default ACC to INNOCUOUS_ACC instead of the current one. >>> >>> The backport in 8u is also inconsistent with one in jdk11u[7], which does not change ACC in the protected constructor. >>> The reproducer also passes on openjdk11.0.8 [8], which do have own backport of the original patch. >>> >>> Please discuss. It doesn't look the 8u backport is correct. >>> >>> I've opened JDK-8249677 to track the issue >>> >>> Thanks, >>> Anton >>> >>> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe >>> [2] https://github.com/apache/lucene-solr/commit/31d7ec7bbfdcd2c4cc61d9d35e962165410b65fe >>> [3] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b10 >>> [4] https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u252-b09 >>> [5] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f2610c95d0fe#l1.19 >>> [6] https://hg.openjdk.java.net/jdk/jdk/rev/50d5266f275f >>> [7] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/0e9eb367df7a/src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java#l92 >>> [8] https://github.com/AdoptOpenJDK/openjdk11-upstream-binaries/releases/tag/jdk-11.0.8%2B10 > From maoliang.ml at alibaba-inc.com Mon Jul 20 07:33:56 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Mon, 20 Jul 2020 15:33:56 +0800 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times In-Reply-To: <7C96E000-B255-4A5C-8CA1-8084308FB9E2@amazon.com> References: <7C96E000-B255-4A5C-8CA1-8084308FB9E2@amazon.com> Message-ID: <002501d65e68$203237a0$6096a6e0$@alibaba-inc.com> Hi Paul, Here is the version with the comment change: http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.02/ Thank you for the sponsor. Liang From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: 2020?7?17? 22:47 To: Liang Mao ; 'jdk8u-dev' Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times I?d change the oops_do() comment to // G1 does its own checking because the assert has a general G1 check (i.e., UseG1GC) rather than a specific one. All uses of oops_do() by G1 will have to do their own checks, not just the array slice case that your current comment says. Other than that, lgtm. I?ll sponsor the patch and add a ?reviewed? comment to the issue. Thanks, Paul From: Liang Mao > Date: Thursday, July 16, 2020 at 11:58 PM To: "Hohensee, Paul" >, 'jdk8u-dev' > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Hi Paul, Thanks very much for your detailed review! I just upload the latest change. Could you please help to push if you are ok with it? http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.01/ Thanks, Liang From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: 2020?7?16? 22:30 To: Liang Mao >; 'jdk8u-dev' > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Using #ifndef INCLUDE_ALL_GCS is also a hack. :) I looked for uses of GenericTaskQueue::oops_do() in G1 and could find only one, in ConcurrentMark::verify_no_cset_oops(). In that context, it invokes VerifyNoCSetOopsClosure::do_object_work(), which is updated by the original patch. But, JDK 9 has two asserts rather than JDK 8?s single assert. The first JDK 9 assert is the G1-specific equivalent to the assert in TaskQueue::oops_do(). So, I'd add the first JDK 9 assert to your patch?s VerifyNoCSetOopsClosure::do_object_work(), vis guarantee(G1CMObjArrayProcessor::is_array_slice(obj) || obj->is_oop(), "Non-oop " PTR_FORMAT ", phase: %s, info: %d", p2i(obj), _phase, _info); and change the assert in TaskQueue::oops_do() to what you suggest (with a comment), vis // G1 does its own checking assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Paul On 7/15/20, 7:28 PM, "Liang Mao" > wrote: Hi Paul, In order to partially iterate the object array, the task queue will not only have oop but also "array slice" which is not oop. But inserting G1 specific code into taskqueue.hpp as below seems a little bit hacking: + assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null"); In JDK9, the oops_do() is already replaced by a common general iterate() which won't have that assertion. Do you think changing the assertion as below is better? -assert((*t)->is_oop_or_null(), "Not an oop or null"); +assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Liang > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: 2020?7?16? 5:39 > To: Liang Mao >; jdk8u-dev dev at openjdk.java.net > > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks > like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the > serial collector is the only collector being compiled into Hotspot, so with your > change the assert only gets compiled for that case. Is a taskqueue ever > instantiated for that case? > > Thanks, > Paul > > On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com > wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > > Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time and > hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small patch, I > didn't change much except some assertions. One assertion in taskqueue.hpp > is removed. It should be ok because it's no longer there as well since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > From preethis00 at gmail.com Mon Jul 20 06:17:14 2020 From: preethis00 at gmail.com (preethi selvaraj) Date: Mon, 20 Jul 2020 11:47:14 +0530 Subject: Latest jdk8u faile for Solaris 10 32-bit Message-ID: Hi Team, Latest jdk8u source failed to build for 32-bit in Solaris 10 x86 whereas in the same system build got succeeded for 64-bit with the same setup/ Have pulled latest jdk8u content from http://hg.openjdk.java.net/jdk8u/jdk8u/. When I build in Solaris 10 for 32-bit, Compiling /export/home/preethi/jdk8u15_7/hotspot/src/share/vm/services/attachListener.cpp "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 50: Error: r8 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 51: Error: r9 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 52: Error: r10 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 53: Error: r11 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 57: Error: r11 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 58: Error: r10 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 59: Error: r9 is not defined. "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", line 60: Error: r8 is not defined. 8 Error(s) detected. gmake[6]: *** [assembler_solaris_x86.o] Error 2 gmake[6]: *** Waiting for unfinished jobs.... gmake[5]: *** [the_vm] Error 2 gmake[4]: *** [product] Error 2 gmake[3]: *** [generic_build2] Error 2 gmake[2]: *** [product] Error 2 gmake[1]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/hotspot/_hotspot.timestamp] Error 2 gmake: *** [hotspot-only] Error 2 OS: Solaris 10 /etc/release: Solaris version: Oracle Solaris 10 8/11 s10x_u10wos_17b X86 Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved. Assembled 23 August 2011 bash-3.2# isainfo -b 64 Configuration summary: * Debug level: release * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 32 Tools summary: * Boot JDK: java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) Server VM (build 24.80-b11, mixed mode) (at /jdk1.7.0_241) * Toolchain: solstudio (Oracle Solaris Studio) * C Compiler: Version 5.13 (at /opt/solarisstudio12.4/bin/cc) * C++ Compiler: Version 5.13 (at /opt/solarisstudio12.4/bin/CC) Build performance summary: * Cores to use: 5 * Memory limit: 32723 MB 1) "/export/home/preethi/jdk8u15_7/hotspot/src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp", commented out r8,r9,r10 and r11. After that, below errors: "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 54: (struct) tag redeclared: _XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 57: identifier redeclared: XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 54: (struct) tag redeclared: _XLinearGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 57: identifier redeclared: XLinearGradient current : struct _XLinearGradient {..} previous: struct _XLinearGradient {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 189 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 61: (struct) tag redeclared: _XCircle "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 65: identifier redeclared: XCircle current : struct _XCircle {..} previous: struct _XCircle {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 150 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 67: (struct) tag redeclared: _XRadialGradient "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 70: identifier redeclared: XRadialGradient current : struct _XRadialGradient {..} previous: struct _XRadialGradient {..} : "/opt/csw/include/X11/extensions/Xrender.h", line 194 "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 332: warning: declaration can not follow a statement "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 820: warning: declaration can not follow a statement "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", line 821: warning: declaration can not follow a statement cc: acomp failed for /export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c gmake[2]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/libawt_xawt/XRBackendNative.o] Error 2 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [libs-only] Error 2 gmake: *** [jdk-only] Error 2 ? After commenting out XLinearGradient, XCircle and XRadialGradient structures in "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/java2d/x11/XRBackendNative.c", finally I end up with the below error: "/export/home/preethi/jdk8u15_7/jdk/src/solaris/native/sun/awt/splashscreen/splashscreen_sys.c", line 329: warning: declaration can not follow a statement ld: warning: mapfile: text segment: section '.text%_init' does not appear in any input file ld: warning: mapfile: text segment: section '.text%init64IO' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%setPathEnvironment' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%Java_java_io_FileSystem_getFileSystem' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_io_UnixFileSystem_canonicalize' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_ClassLoader_findLoadedClass' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Float_floatToIntBits' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Double_doubleToLongBits' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_lang_Shutdown_halt' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_util_logging_FileHandler_lockFile' does not appear in any input file ld: warning: mapfile: text segment: section '.text%Java_java_util_logging_FileHandler_unlockFile' does not appear in any input file ld: warning: mapfile: text segment: section '.text%readLOC' does not appear in mapfile specified input file(s) ld: warning: mapfile: text segment: section '.text%huft_build' does not appear in mapfile specified input file(s) Undefined first referenced symbol in file _IO_stdin_used /export/home/preethi/jdk8u15_7/jdk/make/mapfiles/launchers/mapfile-x86 __xargv /opt/solarisstudio12.4/lib/compilers/crt1x.o (symbol has no version assigned) __xargc /opt/solarisstudio12.4/lib/compilers/crt1x.o (symbol has no version assigned) ld: fatal: symbol referencing errors. No output written to /export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/java_objs/java gmake[2]: *** [/export/home/preethi/jdk8u15_7/build/solaris-x86-normal-server-release/jdk/objs/java_objs/java] Error 2 gmake[2]: *** Waiting for unfinished jobs.... gmake[1]: *** [launchers-only] Error 2 gmake: *** [jdk-only] Error 2 All the tools(X11, cups, cups_dev,freetype), I?ve installed from opencsw. ? ld path as /usr/ccs/bin/ld ? vi /opt/solarisstudio12.4/lib/compilers/CC-gcc/gcc_version.map $mapfile_version 2 ? /usr/ccs/bin/ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.1514 Can you help me what is going wrong in this? In the same Solaris 10 system, tried to build latest jdk8u for 64-bit, it?s working fine. As far as I know, if we give ?with-target-bits=32, it should work fine for 32-bit also. I?ve tried with Solaris studio 12.3 and Solaris studio 12.4. Do I need to install/configure anything else. If this is not the right forum to ask, kindly excuse and point me the right direction -- Regards, Preethi From akozlov at azul.com Mon Jul 20 08:37:12 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 20 Jul 2020 11:37:12 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> Message-ID: <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> On 20.07.2020 08:40, Chris Hegarty wrote: > A solution that reverts the change to the protected constructor, and adds a package-private constructor that does the necessary ACC restricting, in a similar way to that of the code in 11u, would appear most appropriate here. Thank you for the comment, I've prepared a fix that follows this way: http://cr.openjdk.java.net/~akozlov/8249677/webrev.00/ The change also brings consistency with observable jdk11u logic. The test case from lucene-solr passes after applying this, as well as Test.java supplied to the bug. Could you please review the change? Thanks, Anton From jdowland at redhat.com Mon Jul 20 09:35:33 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Mon, 20 Jul 2020 10:35:33 +0100 Subject: [8u] RFR: 8159690: [TESTBUG] Mark headful tests with @key headful. Message-ID: <20200720093533.hqlyyaxpf6bl7ich@qusp> Hello, Please review this backport of JDK-8159690 to 8u, for parity with Oracle 8u271. Bug: https://bugs.openjdk.java.net/browse/JDK-8159690 jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/980da45565c8 webrev: https://jmtd.net/tmp/JDK-8159690/ 542/842 hunks applied directly from the original patch. 44 I resolved manually. The remaining hunks are for filenames that do not exist in jdk8u. Those basenames are listed here: https://jmtd.net/tmp/JDK-8159690/basenames_not_in_tree.txt Note that there are two different tests with the basename "ImageTransferTest.java", only one of which is in jdk8u. Thank you, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From sgehwolf at redhat.com Mon Jul 20 11:47:02 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 Jul 2020 13:47:02 +0200 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <1e60b154-8c09-91d2-65c7-c4f283b0f407@azul.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <1e60b154-8c09-91d2-65c7-c4f283b0f407@azul.com> Message-ID: <4a70d3bc9d62883d9a83f0f892ea82bacd571a6c.camel@redhat.com> Hi Andrey, On Fri, 2020-07-17 at 21:44 +0300, Andrey Petushkov wrote: > Hi Severin, > > The code being backported seem to have a bug and will result in a > regression if > being integrated. OK. Do you have any experience on a ballpark number as to how many systems this would affect? Is this a common config? > The problem is that, to my understanding it's legal that only some of known > controllers are mounted (at least man says they can be mounted > individually). > This creates a situation that Metrics gets "active" and populated with > some of > SubSystems, but not all. As a result OperatingSystemImpl considers > containerMetrics > available and uses it as a source. The SubSystem code is written the way > that it > returns 0 for any value if a respective subsystem is missing. At the > same time > OperatingSystemImpl typically uses >=0 as a sanity check of a value > returned from Metrics. > Effectively preventing from falling back to native implementation for > the actual value > and returning 0 instead of actual value > > The problem actually exhibited by GetTotalPhysicalMemorySize test ran on > Raspbian Stretch > which happen to have cgroup fs but not /sys/fs/cgroup/memory Thanks for the heads-up. A couple of questions: * Note that this has changed in JDK 15 where unavailable files should return -1 (over 0) in case of missing crgoup files. Have you tested JDK 15 by any chance? * Do you see this behaviour in a container or also outside? > That's not the problem of a backport and of course should be discussed > with upstream > developers. It just happened that we've found it with a backport so > letting you know Yes, agreed. It seems an issue with the cgroups Metrics infra in older JDKs. Do you mind creating a bug for this issue? Thanks, Severin > Regards, > Andrey > > On 17.07.2020 17:07, Severin Gehwolf wrote: > > Hi, > > > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > > container awareness which has been backported to Oracle JDK (parity > > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > > being used in this patch. > > > > Changes as compared to the JDK 11 patch were: > > > > * SubSystem.java: 8217338: [Containers] Improve systemd slice memory > > limit support not being there => getLongValueMatchingLine() missing > > => dropped > > * OperatingSystemImpl.java: Introduced Java methods which internally > > call the native methods. Renamed native methods to 0 > > * Tests were actually done to the hotspot code in later JDKs, thus, > > for this backport the tests are in the hotspot portion of the webrev > > (separate repo). > > * Other than that, it's just the native bits which are in different > > files in JDK 8. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226575 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ > > CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 > > > > Testing: Included docker tests on Linux x86_64. jdk_management tests and > > tier 1 tests. No regressions noted. > > > > If somebody could test this on Windows/Mac, I'd appreciate it. > > > > Thanks, > > Severin > > > > [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html > > From jdowland at redhat.com Mon Jul 20 13:48:34 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Mon, 20 Jul 2020 14:48:34 +0100 Subject: [8u] RFR: 8160974: [TESTBUG] Mark more headful tests with @key headful. Message-ID: <20200720134834.dftcto4z57gknnl7@qusp> Hello, Please review this backport of JDK-8160974 to 8u, for parity with Oracle 8u271. Bug: https://bugs.openjdk.java.net/browse/JDK-8160974 jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fe58d505fffd webrev: https://jmtd.net/tmp/JDK-8160974/ 228/596 hunks apply without modifications. 16 hunks required manual rework. The remainder were for files not present in jdk8u. Those files were: https://jmtd.net/tmp/JDK-8160974/files_not_present_in_jdk8u.txt Thank you, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From sgehwolf at redhat.com Mon Jul 20 13:52:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 20 Jul 2020 15:52:05 +0200 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> Message-ID: <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Hi Anton, On Mon, 2020-07-20 at 11:37 +0300, Anton Kozlov wrote: > On 20.07.2020 08:40, Chris Hegarty wrote: > > A solution that reverts the change to the protected constructor, > > and adds a package-private constructor that does the necessary ACC > > restricting, in a similar way to that of the code in 11u, would > > appear most appropriate here. > > Thank you for the comment, I've prepared a fix that follows this way: > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.00/ > > The change also brings consistency with observable jdk11u logic. The > test case from lucene-solr passes after applying this, as well as > Test.java supplied to the bug. Couldn't we include a regression test with the fix based on Test.java Like so: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8249677/jdk8/01/webrev/ Thanks, Severin From gnu.andrew at redhat.com Mon Jul 20 14:09:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 20 Jul 2020 15:09:29 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> Message-ID: <739185ab-74b5-e73e-6c60-d711d16221ac@redhat.com> On 20/07/2020 09:37, Anton Kozlov wrote: > On 20.07.2020 08:40, Chris Hegarty wrote: >> A solution that reverts the change to the protected constructor, and adds a package-private constructor that does the necessary ACC restricting, in a similar way to that of the code in 11u, would appear most appropriate here. > > Thank you for the comment, I've prepared a fix that follows this way: > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.00/ > > The change also brings consistency with observable jdk11u logic. The test case from lucene-solr passes after applying this, as well as Test.java supplied to the bug. > > Could you please review the change? > > Thanks, > Anton > Ok, we're looking at this within the vulnerability group and will get back to you. I don't think a public list is the place to discuss this in depth. One comment I would make is it would be a good idea to add a comment along the lines of that in 11u: + * Version for use by the default pool.This is a + separate constructor to avoid affecting the protected + constructor. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jul 20 14:09:54 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 20 Jul 2020 15:09:54 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Message-ID: On 20/07/2020 14:52, Severin Gehwolf wrote: > Hi Anton, > > On Mon, 2020-07-20 at 11:37 +0300, Anton Kozlov wrote: >> On 20.07.2020 08:40, Chris Hegarty wrote: >>> A solution that reverts the change to the protected constructor, >>> and adds a package-private constructor that does the necessary ACC >>> restricting, in a similar way to that of the code in 11u, would >>> appear most appropriate here. >> >> Thank you for the comment, I've prepared a fix that follows this way: >> >> http://cr.openjdk.java.net/~akozlov/8249677/webrev.00/ >> >> The change also brings consistency with observable jdk11u logic. The >> test case from lucene-solr passes after applying this, as well as >> Test.java supplied to the bug. > > Couldn't we include a regression test with the fix based on Test.java > Like so: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8249677/jdk8/01/webrev/ > > Thanks, > Severin > That sounds a good idea. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jul 20 14:13:47 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 20 Jul 2020 15:13:47 +0100 Subject: Latest jdk8u faile for Solaris 10 32-bit In-Reply-To: References: Message-ID: <89f43965-5d98-512d-d1db-d513715ddc60@redhat.com> On 20/07/2020 07:17, preethi selvaraj wrote: > Hi Team, > Latest jdk8u source failed to build for 32-bit in Solaris 10 x86 whereas in > the same system build got succeeded for 64-bit with the same setup/ > Have pulled latest jdk8u content from > http://hg.openjdk.java.net/jdk8u/jdk8u/. When I build in Solaris 10 for > 32-bit, > Has this worked for you before? I'm not aware of anyone testing on Solaris x86, so it may be that 8u has been broken for some time. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From zgu at redhat.com Mon Jul 20 15:31:23 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Jul 2020 11:31:23 -0400 Subject: [8u] 8023697: failed class resolution reports different class name in detail message for the first and subsequent times Message-ID: <01efae7d-445c-17b7-d700-acf08a9d7764@redhat.com> Hi, I would like to backport this to 8u for parity with Oracle 8u271. The original patch does not apply cleanly. The major conflicts were due to the renaming of "this_oop" to "this_cp" in constantPool.[hpp|cpp] Replacing "this_cp" with "this_oop" in original patch, only resulted one minor conflict on copyright line of constantTag.cpp Original bug: https://bugs.openjdk.java.net/browse/JDK-8023697 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/003c36658224 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8023697-8u/webrev.00/ Test: hotspot_tier1 Thanks, -Zhengyu From hohensee at amazon.com Mon Jul 20 15:46:44 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 20 Jul 2020 15:46:44 +0000 Subject: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Message-ID: <712BC537-456D-439D-B204-49FDB67506C7@amazon.com> Thanks, Liang. The issue was already tagged with jdk8u-fix-request, and I?ve added a ?review approval? comment. Paul From: Liang Mao Date: Monday, July 20, 2020 at 12:34 AM To: "Hohensee, Paul" , 'jdk8u-dev' Subject: RE: [EXTERNAL] [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Hi Paul, Here is the version with the comment change: http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.02/ Thank you for the sponsor. Liang From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: 2020?7?17? 22:47 To: Liang Mao ; 'jdk8u-dev' Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times I?d change the oops_do() comment to // G1 does its own checking because the assert has a general G1 check (i.e., UseG1GC) rather than a specific one. All uses of oops_do() by G1 will have to do their own checks, not just the array slice case that your current comment says. Other than that, lgtm. I?ll sponsor the patch and add a ?reviewed? comment to the issue. Thanks, Paul From: Liang Mao > Date: Thursday, July 16, 2020 at 11:58 PM To: "Hohensee, Paul" >, 'jdk8u-dev' > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Hi Paul, Thanks very much for your detailed review! I just upload the latest change. Could you please help to push if you are ok with it? http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.01/ Thanks, Liang From: Hohensee, Paul [mailto:hohensee at amazon.com] Sent: 2020?7?16? 22:30 To: Liang Mao >; 'jdk8u-dev' > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely long synchronization times Using #ifndef INCLUDE_ALL_GCS is also a hack. :) I looked for uses of GenericTaskQueue::oops_do() in G1 and could find only one, in ConcurrentMark::verify_no_cset_oops(). In that context, it invokes VerifyNoCSetOopsClosure::do_object_work(), which is updated by the original patch. But, JDK 9 has two asserts rather than JDK 8?s single assert. The first JDK 9 assert is the G1-specific equivalent to the assert in TaskQueue::oops_do(). So, I'd add the first JDK 9 assert to your patch?s VerifyNoCSetOopsClosure::do_object_work(), vis guarantee(G1CMObjArrayProcessor::is_array_slice(obj) || obj->is_oop(), "Non-oop " PTR_FORMAT ", phase: %s, info: %d", p2i(obj), _phase, _info); and change the assert in TaskQueue::oops_do() to what you suggest (with a comment), vis // G1 does its own checking assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Paul On 7/15/20, 7:28 PM, "Liang Mao" > wrote: Hi Paul, In order to partially iterate the object array, the task queue will not only have oop but also "array slice" which is not oop. But inserting G1 specific code into taskqueue.hpp as below seems a little bit hacking: + assert((*t)->is_g1_array_slice() || (*t)->is_oop_or_null(), "Not an oop or null"); In JDK9, the oops_do() is already replaced by a common general iterate() which won't have that assertion. Do you think changing the assertion as below is better? -assert((*t)->is_oop_or_null(), "Not an oop or null"); +assert(UseG1GC || (*t)->is_oop_or_null(), "Not an oop or null"); Thanks, Liang > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: 2020?7?16? 5:39 > To: Liang Mao >; jdk8u-dev dev at openjdk.java.net> > Subject: RE: [8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Lgtm, except, why you need to remove the assert from taskqueue.hpp? > oops_do() doesn't seem to exist in 9, though I see an iterate() method that looks > like it does the same thing in 9. INCLUDE_ALL_GCS is undefined only when the > serial collector is the only collector being compiled into Hotspot, so with your > change the assert only gets compiled for that case. Is a taskqueue ever > instantiated for that case? > > Thanks, > Paul > > On 7/6/20, 6:13 AM, "jdk8u-dev on behalf of Liang Mao" retn at openjdk.java.net on behalf of maoliang.ml at alibaba-inc.com> wrote: > > Hi, > > Could someone please help? > > Thanks, > Liang > > > > > ------------------------------------------------------------------ > From:MAO, Liang > > Send Time:2020 Jul. 2 (Thu.) 10:30 > To:jdk8u-dev > > Subject:[8u] RFR Backport 8057003: Large reference arrays cause extremely > long synchronization times > > Hi, > > I'm requesting the backport of 8057003 into 8u. As the description in the bug, > it's a serious G1 issue which leads to 10X longer concurrent mark time and > hang > the Java threads for seconds. We encounter the problem in several > applications. > Since G1 is widely used in 8u, we need to fix it. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8057003 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a67614dce6cd > > The JDK9 patch did not apply cleanly. Although it is not a small patch, I > didn't change much except some assertions. One assertion in taskqueue.hpp > is removed. It should be ok because it's no longer there as well since JDK9. > > 8u webrev: > http://cr.openjdk.java.net/~ddong/liangmao/8057003/webrev.00/ > > Testing: > gc/g1, specjbb2015 with fastdebug > > Could someone please have a look and sponsor? > > Thanks, > Liang > > From akozlov at azul.com Mon Jul 20 15:34:26 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 20 Jul 2020 18:34:26 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Message-ID: Hi, thanks, a test case was my intention. I was playing with tests, while the fix can be reviewed. I see an another change in the behavior in defaultForkJoinThreadFactory. Please check the "default" testcase, which passes on openjdk8u252 and does not pass on openjdk8u262. http://cr.openjdk.java.net/~akozlov/8249677/webrev.01/ I'm also attaching a standalone testcase to the bug. The vulnerability group is likely to be a better place to discuss this. Please consider this as something searchable for anyone who meets with the issue Thanks, Anton On 20.07.2020 17:09, Andrew Hughes wrote: > > > On 20/07/2020 14:52, Severin Gehwolf wrote: >> Hi Anton, >> >> On Mon, 2020-07-20 at 11:37 +0300, Anton Kozlov wrote: >>> On 20.07.2020 08:40, Chris Hegarty wrote: >>>> A solution that reverts the change to the protected constructor, >>>> and adds a package-private constructor that does the necessary ACC >>>> restricting, in a similar way to that of the code in 11u, would >>>> appear most appropriate here. >>> >>> Thank you for the comment, I've prepared a fix that follows this way: >>> >>> http://cr.openjdk.java.net/~akozlov/8249677/webrev.00/ >>> >>> The change also brings consistency with observable jdk11u logic. The >>> test case from lucene-solr passes after applying this, as well as >>> Test.java supplied to the bug. >> >> Couldn't we include a regression test with the fix based on Test.java >> Like so: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8249677/jdk8/01/webrev/ >> >> Thanks, >> Severin >> > > That sounds a good idea. > From andrey at azul.com Mon Jul 20 17:48:57 2020 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 20 Jul 2020 20:48:57 +0300 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <4a70d3bc9d62883d9a83f0f892ea82bacd571a6c.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> <1e60b154-8c09-91d2-65c7-c4f283b0f407@azul.com> <4a70d3bc9d62883d9a83f0f892ea82bacd571a6c.camel@redhat.com> Message-ID: Hi Severin, On 20.07.2020 14:47, Severin Gehwolf wrote: > Hi Andrey, > > On Fri, 2020-07-17 at 21:44 +0300, Andrey Petushkov wrote: >> Hi Severin, >> >> The code being backported seem to have a bug and will result in a >> regression if >> being integrated. > OK. Do you have any experience on a ballpark number as to how many > systems this would affect? Is this a common config? We have seen relevant tests fail only on one type of system. So it might be rare enough. Let me check whether other systems have all or nothing cgroups fs or there are more like that just happened not to have respective test to fail > >> The problem is that, to my understanding it's legal that only some of known >> controllers are mounted (at least man says they can be mounted >> individually). >> This creates a situation that Metrics gets "active" and populated with >> some of >> SubSystems, but not all. As a result OperatingSystemImpl considers >> containerMetrics >> available and uses it as a source. The SubSystem code is written the way >> that it >> returns 0 for any value if a respective subsystem is missing. At the >> same time >> OperatingSystemImpl typically uses >=0 as a sanity check of a value >> returned from Metrics. >> Effectively preventing from falling back to native implementation for >> the actual value >> and returning 0 instead of actual value >> >> The problem actually exhibited by GetTotalPhysicalMemorySize test ran on >> Raspbian Stretch >> which happen to have cgroup fs but not /sys/fs/cgroup/memory > Thanks for the heads-up. A couple of questions: > > * Note that this has changed in JDK 15 where unavailable files should > return -1 (over 0) in case of missing crgoup files. Have you tested > JDK 15 by any chance? No, not yet. Let me try > * Do you see this behaviour in a container or also outside? The behavior was observed _only_ outside of container. However I believe we don't run these tests inside a container on RPi. That would be interesting to try, let me see > >> That's not the problem of a backport and of course should be discussed >> with upstream >> developers. It just happened that we've found it with a backport so >> letting you know > Yes, agreed. It seems an issue with the cgroups Metrics infra in older > JDKs. Do you mind creating a bug for this issue? Sure. Let me see the state of JDK15 wrt this issue before filing a bug Thanks, Andrey > > Thanks, > Severin > >> Regards, >> Andrey >> >> On 17.07.2020 17:07, Severin Gehwolf wrote: >>> Hi, >>> >>> Please review this OpenJDK 8u backport for OperatingSystemMXBean's >>> container awareness which has been backported to Oracle JDK (parity >>> bug). This backport depends on JDK-8203357[1] for Metrics.java which is >>> being used in this patch. >>> >>> Changes as compared to the JDK 11 patch were: >>> >>> * SubSystem.java: 8217338: [Containers] Improve systemd slice memory >>> limit support not being there => getLongValueMatchingLine() missing >>> => dropped >>> * OperatingSystemImpl.java: Introduced Java methods which internally >>> call the native methods. Renamed native methods to 0 >>> * Tests were actually done to the hotspot code in later JDKs, thus, >>> for this backport the tests are in the hotspot portion of the webrev >>> (separate repo). >>> * Other than that, it's just the native bits which are in different >>> files in JDK 8. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8226575 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 >>> >>> Testing: Included docker tests on Linux x86_64. jdk_management tests and >>> tier 1 tests. No regressions noted. >>> >>> If somebody could test this on Windows/Mac, I'd appreciate it. >>> >>> Thanks, >>> Severin >>> >>> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html >> From zgu at redhat.com Mon Jul 20 19:45:22 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 20 Jul 2020 15:45:22 -0400 Subject: [8u] RFR 8141457: keytool default cert fingerprint algorithm should be SHA-256 Message-ID: <45f07c31-d9d5-c869-212b-551a4e02d662@redhat.com> I would like to backport this to 8u for parity with Oracle 8u271. The original patch does not apply cleanly. There are a couple of minor conflicts with Main.java and Resource.java, which are easy to resolve. Patches to following files, apparently already came in via JDK-8048830 api_cert_chain.p12_expected.data api_private_key.p12_expected.data api_private_key_not_match.p12_expected.data api_two_pass.p12_expected.data Original bug: https://bugs.openjdk.java.net/browse/JDK-8141457 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/97b25277c28f 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8141457-8u/webrev.00/ Test: jdk_security Thanks, -Zhengyu From mbalao at redhat.com Mon Jul 20 20:33:52 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 20 Jul 2020 17:33:52 -0300 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> Message-ID: <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> Hi Alexey, Thanks for your feedback. On 7/17/20 5:32 PM, Alexey Bakhtin wrote: > 1. You have updated the list of classes in the sun/security/ssl/krb5 package. > These classes are the bridge to JGSS/KRB5 implementation. The compact > profile 1 does not include JGSS/KRB5 implementation, so build scripts > verifies references to removed packages. Exceptions are described in the > make/data/checkdeps/refs.allowed script. This script should be updated > with new class names. Otherwise it fails during profiles creation. Well spotted! Should be fixed in Webrev.03. > 2. Three kerberos test failed because of server can not select KRB5 cipher suite. > It happens because of server principal name is not specified (it?s allowed behaviour). > As result implementation does not create possession and corresponding cipher suite > is not selected. I suggest to create possession even if no serverPrincipal returned, > similar to original implementation. > The code could be update like following in the KrbKeyExchange.java: > @@ -91,7 +91,6 @@ final class KrbKeyExchange { > } > return null; > } > - return new KrbServiceCreds(serviceCreds); > } > } > } catch (PrivilegedActionException e) { > @@ -100,8 +99,9 @@ final class KrbKeyExchange { > SSLLogger.fine("Attempt to obtain Kerberos key failed: " > + e.toString()); > } > + return null; > } > - return null; > + return (serviceCreds != null)?new KrbServiceCreds(serviceCreds):null; > } > } Hmm.. interesting. You're right: I took the extra license of discarding the ciphersuite if serverPrincipal is null. This does not reflect the previous behavior in ServerHandshaker::setupKerberosKeys method (ServerHandshaker.java). Should be fixed in Webrev.03. Webrev.03: http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.03/ Look forward to more feedback. Thanks, Martin.- From mbalao at redhat.com Mon Jul 20 23:06:27 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 20 Jul 2020 20:06:27 -0300 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> Message-ID: Hi Alexey, On 7/16/20 7:25 AM, Alexey Bakhtin wrote: > TLSv1.3, 1.2 and 1.1 contexts are different because of we selected highest protocol explicitly, so return cipher suites for these protocol set only. > My approach requires less configuration from application point of view. > However you are right, this approach could be also misleading if default cipher and protocol set not match each other. > > Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v1/ Thanks for your new proposal. Can we keep the CustomizedTLSContext::customizedProtocols and CustomizedTLSContext::getProtocols signatures? Looks to me that 'getProtocols' was intended for clients to avoid the SSL20Hello protocol, as servers use the inherited 'getSupportedProtocols'. The name is a bit of a misnomer, though. The 'isDefault' parameter, on the other hand, does not add much information to me as these are default values anyways. Thanks, Martin.- From jdowland at redhat.com Tue Jul 21 09:05:50 2020 From: jdowland at redhat.com (Jonathan Dowland) Date: Tue, 21 Jul 2020 10:05:50 +0100 Subject: [8u] RFR: 8168517: java/lang/ProcessBuilder/Basic.java failed Message-ID: <20200721090550.5zqqxtkzxzg2475i@qusp> Hello, Please consider tagging JDK-8168517 for backporting to 8u, for parity with Oracle 8u271. Bug: https://bugs.openjdk.java.net/browse/JDK-8168517 jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88ec80d47d4a The patch applies cleanly. webrev: https://redmars.org/~jon/openjdk/JDK-8168517/ The test passes for me before and after applying to jdk8u-dev tip (0955cfdaee9e at the time of writing) Thank you, -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From sgehwolf at redhat.com Tue Jul 21 11:42:20 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jul 2020 13:42:20 +0200 Subject: [8u] RFR: 8168517: java/lang/ProcessBuilder/Basic.java failed In-Reply-To: <20200721090550.5zqqxtkzxzg2475i@qusp> References: <20200721090550.5zqqxtkzxzg2475i@qusp> Message-ID: <3a7e0e894dbf3f838b7d57e28b26f5fd15015d39.camel@redhat.com> Hi Jon, On Tue, 2020-07-21 at 10:05 +0100, Jonathan Dowland wrote: > Hello, > > Please consider tagging JDK-8168517 for backporting to 8u, > for parity with Oracle 8u271. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8168517 > jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/88ec80d47d4a > > The patch applies cleanly. webrev: > https://redmars.org/~jon/openjdk/JDK-8168517/ You don't need to post a webrev for clean backports. Aside: Please reach out to us for hosting any needed webrevs so that we can put them on cr.openjdk.java.net. Until you'll become OpenJDK Author you'll need a sponsor for those kinds of things. > The test passes for me before and after applying to jdk8u-dev tip > (0955cfdaee9e at the time of writing) Please send me the fix request comment[1] (privately) which I should add and I'll copy it into JBS for you. Thanks, Severin From alexey at azul.com Tue Jul 21 11:50:36 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 21 Jul 2020 11:50:36 +0000 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> Message-ID: <31DBFB21-DF96-4B5B-8528-B8AA4B3C0AF4@azul.com> Hi Martin, You are right. It could be much simple with original method signatures. The updated patch : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v2/ Thank you Alexey > On 21 Jul 2020, at 02:06, Martin Balao wrote: > > Hi Alexey, > > On 7/16/20 7:25 AM, Alexey Bakhtin wrote: >> TLSv1.3, 1.2 and 1.1 contexts are different because of we selected highest protocol explicitly, so return cipher suites for these protocol set only. >> My approach requires less configuration from application point of view. >> However you are right, this approach could be also misleading if default cipher and protocol set not match each other. >> >> Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v1/ > > Thanks for your new proposal. > > Can we keep the CustomizedTLSContext::customizedProtocols and > CustomizedTLSContext::getProtocols signatures? > > Looks to me that 'getProtocols' was intended for clients to avoid the > SSL20Hello protocol, as servers use the inherited > 'getSupportedProtocols'. The name is a bit of a misnomer, though. The > 'isDefault' parameter, on the other hand, does not add much information > to me as these are default values anyways. > > Thanks, > Martin.- > From sgehwolf at redhat.com Tue Jul 21 12:46:51 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jul 2020 14:46:51 +0200 Subject: [8u] RFR (S) 8165936: Potential Heap buffer overflow when seaching timezone info files In-Reply-To: <5c4f2b4a-293e-3dfb-3cb5-991d8e8613f3@redhat.com> References: <5c4f2b4a-293e-3dfb-3cb5-991d8e8613f3@redhat.com> Message-ID: <431418f05b4428eb68906f3b2a8d0fe03b5a7425.camel@redhat.com> On Mon, 2020-03-30 at 12:33 +0200, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8165936 > https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8ec0559cbd7e > > Unfortunately, the patch does apply directly to 8u: > - TimeZone_md.c for unixes is actually in "solaris" folder > - ...and then the context is different enough for fuzz to fail > > 8u webrev: > https://cr.openjdk.java.net/~shade/8165936/webrev.8u.01/ Looks fine to me. Thanks, Severin From alexey at azul.com Tue Jul 21 14:24:24 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 21 Jul 2020 14:24:24 +0000 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> Message-ID: <87194959-BEB3-4492-99D3-E0B76FC92A1E@azul.com> Hi Martin, Thank you for update. This version is looks good, I do not see any issues and all test passed. May be some minor comments : KrbClientKeyExchange.java - krb5Helper is initialized in constructor and should not be changed later. It could be final. Also, there are some unused imports and method in Krb5 functionality ( not actually related to your code change) : - SecretKey and KerberosKey are not used in Krb5ProxyImpl and could be removed from imports. If it is applied, KerberosKey should be also removed in refs.allowed script for Krb5ProxyImpl class, - SecretKey is not used in Krb5Proxy and could be removed from imports, - Krb5Helper.isAvailable() method is not used also and could be removed. Thank you Alexey > On 20 Jul 2020, at 23:33, Martin Balao wrote: > > Hi Alexey, > > Thanks for your feedback. > > On 7/17/20 5:32 PM, Alexey Bakhtin wrote: >> 1. You have updated the list of classes in the sun/security/ssl/krb5 package. >> These classes are the bridge to JGSS/KRB5 implementation. The compact >> profile 1 does not include JGSS/KRB5 implementation, so build scripts >> verifies references to removed packages. Exceptions are described in the >> make/data/checkdeps/refs.allowed script. This script should be updated >> with new class names. Otherwise it fails during profiles creation. > > Well spotted! Should be fixed in Webrev.03. > >> 2. Three kerberos test failed because of server can not select KRB5 cipher suite. >> It happens because of server principal name is not specified (it?s allowed behaviour). >> As result implementation does not create possession and corresponding cipher suite >> is not selected. I suggest to create possession even if no serverPrincipal returned, >> similar to original implementation. >> The code could be update like following in the KrbKeyExchange.java: >> @@ -91,7 +91,6 @@ final class KrbKeyExchange { >> } >> return null; >> } >> - return new KrbServiceCreds(serviceCreds); >> } >> } >> } catch (PrivilegedActionException e) { >> @@ -100,8 +99,9 @@ final class KrbKeyExchange { >> SSLLogger.fine("Attempt to obtain Kerberos key failed: " >> + e.toString()); >> } >> + return null; >> } >> - return null; >> + return (serviceCreds != null)?new KrbServiceCreds(serviceCreds):null; >> } >> } > > Hmm.. interesting. You're right: I took the extra license of discarding > the ciphersuite if serverPrincipal is null. This does not reflect the > previous behavior in ServerHandshaker::setupKerberosKeys method > (ServerHandshaker.java). Should be fixed in Webrev.03. > > Webrev.03: > http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.03/ > > Look forward to more feedback. > > Thanks, > Martin.- > From mbalao at redhat.com Tue Jul 21 14:37:56 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 21 Jul 2020 11:37:56 -0300 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default In-Reply-To: <31DBFB21-DF96-4B5B-8528-B8AA4B3C0AF4@azul.com> References: <1e2f33e9-1af7-17d7-0a14-be7e97386480@redhat.com> <313E3574-2044-4EEE-97FC-2D16DEA92195@azul.com> <2e037057-60d7-3b5e-9581-3e6dece130ff@redhat.com> <31DBFB21-DF96-4B5B-8528-B8AA4B3C0AF4@azul.com> Message-ID: Hi Alexey, On 7/21/20 8:50 AM, Alexey Bakhtin wrote: > You are right. It could be much simple with original method signatures. > The updated patch : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v2/ Looks good to me. Please hold the push until all the patches in the series are maintainer-approved. Thanks, Martin.- From sgehwolf at redhat.com Tue Jul 21 15:53:28 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jul 2020 17:53:28 +0200 Subject: [8u] RFR 8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: <636bc897-f52a-c3ec-badf-765e502d1181@redhat.com> References: <658073af-3313-61e5-7f42-f6889f53774f@redhat.com> <636bc897-f52a-c3ec-badf-765e502d1181@redhat.com> Message-ID: Hi Zhengyu! On Tue, 2020-06-16 at 20:48 -0400, Zhengyu Gu wrote: > > On 6/16/20 7:43 PM, Andrew Hughes wrote: > > > > On 16/06/2020 22:09, Zhengyu Gu wrote: > > > Please review this backport for parity with Oracle 8u271. > > > > > > The original patch does not apply cleanly. The conflicts are minor, as > > > 8u version of CanWriteSequence.test() method format is slightly off. > > > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8183349 > > > Original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/93b7bd25273e > > > > > > 8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8183349-8u/webrev.00/ > > > > > > Test: > > > Passed both tests on Linux x86_64 > > > > > > > > > Thanks, > > > > > > -Zhengyu > > > > > > > Where are the indentation differences coming from in this patch? The > > only difference between the 8u and 10u version of this file prior to the > > patch is the latter has a newline at the end. > > > Right. Adding a newline in 8u version, then patch applied cleanly. > > Do I still need a review? Adding a new-line at the end of the file is fine. Reviewed. If in doubt, post a review :) In this case, I'd have approved the patch if it was mentioned in the fix request comment *without* a review. Thanks, Severin From gnu.andrew at redhat.com Tue Jul 21 16:09:04 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 Jul 2020 17:09:04 +0100 Subject: [8u] RFR 8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java In-Reply-To: References: <658073af-3313-61e5-7f42-f6889f53774f@redhat.com> <636bc897-f52a-c3ec-badf-765e502d1181@redhat.com> Message-ID: <441d8344-8912-910b-9b15-332b21328299@redhat.com> On 21/07/2020 16:53, Severin Gehwolf wrote: > Hi Zhengyu! > > On Tue, 2020-06-16 at 20:48 -0400, Zhengyu Gu wrote: >> >> On 6/16/20 7:43 PM, Andrew Hughes wrote: >>> >>> On 16/06/2020 22:09, Zhengyu Gu wrote: >>>> Please review this backport for parity with Oracle 8u271. >>>> >>>> The original patch does not apply cleanly. The conflicts are minor, as >>>> 8u version of CanWriteSequence.test() method format is slightly off. >>>> >>>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8183349 >>>> Original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/93b7bd25273e >>>> >>>> 8u weberv: http://cr.openjdk.java.net/~zgu/JDK-8183349-8u/webrev.00/ >>>> >>>> Test: >>>> Passed both tests on Linux x86_64 >>>> >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>> >>> Where are the indentation differences coming from in this patch? The >>> only difference between the 8u and 10u version of this file prior to the >>> patch is the latter has a newline at the end. >>> >> Right. Adding a newline in 8u version, then patch applied cleanly. >> >> Do I still need a review? > > Adding a new-line at the end of the file is fine. Reviewed. > > If in doubt, post a review :) In this case, I'd have approved the patch > if it was mentioned in the fix request comment *without* a review. > > Thanks, > Severin > If the patch applies with automated path shuffling via the in-tree scripts, and then builds, it is fine to proceed straight to the approval process. Otherwise, a review is necessary. This is documented on the wiki: https://wiki.openjdk.java.net/display/jdk8u/Main -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Tue Jul 21 16:50:19 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 21 Jul 2020 13:50:19 -0300 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: <87194959-BEB3-4492-99D3-E0B76FC92A1E@azul.com> References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> <87194959-BEB3-4492-99D3-E0B76FC92A1E@azul.com> Message-ID: Hi Alexey, Thanks for your feedback. Webrev.04: http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.04/ On 7/21/20 11:24 AM, Alexey Bakhtin wrote: > KrbClientKeyExchange.java - krb5Helper is initialized in constructor and should not be changed later. It could be final. Fixed. > - SecretKey and KerberosKey are not used in Krb5ProxyImpl and could be removed from imports. If it is applied, KerberosKey should be also removed in refs.allowed script for Krb5ProxyImpl class, Fixed. > - SecretKey is not used in Krb5Proxy and could be removed from imports, Fixed. > - Krb5Helper.isAvailable() method is not used also and could be removed. Fixed. Thanks, Martin.- From gnu.andrew at redhat.com Tue Jul 21 16:28:37 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 Jul 2020 17:28:37 +0100 Subject: [8u] 8023697: failed class resolution reports different class name in detail message for the first and subsequent times In-Reply-To: <01efae7d-445c-17b7-d700-acf08a9d7764@redhat.com> References: <01efae7d-445c-17b7-d700-acf08a9d7764@redhat.com> Message-ID: <50393507-996a-388b-4b9a-386700c0b7f2@redhat.com> On 20/07/2020 16:31, Zhengyu Gu wrote: > Hi, > > I would like to backport this to 8u for parity with Oracle 8u271. > > The original patch does not apply cleanly. The major conflicts were due > to the renaming of "this_oop" to "this_cp" in constantPool.[hpp|cpp] > Seems to be a typographical change with no change in semantics from that alone: https://bugs.openjdk.java.net/browse/JDK-8031820 Keeping 'this_oop' in the new functions for consistency seems the right thing to do. > Replacing "this_cp" with "this_oop" in original patch, only resulted one > minor conflict on copyright line of constantTag.cpp > constantTag.cpp already has 2014, so this is fine. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8023697 > Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/003c36658224 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8023697-8u/webrev.00/ > > Test: > ? hotspot_tier1 > > Thanks, > > -Zhengyu > Looks ok. Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Tue Jul 21 16:53:59 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jul 2020 18:53:59 +0200 Subject: [RFR]: JDK-8196196: Headful tests should not be run in headless mode In-Reply-To: References: Message-ID: On Wed, 2020-07-08 at 14:39 +0200, Mario Torre wrote: > http://cr.openjdk.java.net/~neugens/8196196/webrev.00/ Looks good to me. Thanks, Severin From gnu.andrew at redhat.com Tue Jul 21 16:57:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 Jul 2020 17:57:49 +0100 Subject: [8u] RFR: 8226575: OperatingSystemMXBean should be made container aware In-Reply-To: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> References: <83e786d5b7bb315239e28161757f0b708f314b56.camel@redhat.com> Message-ID: <3d826768-0d20-2d1e-5e4a-cde2ae904962@redhat.com> On 17/07/2020 15:07, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport for OperatingSystemMXBean's > container awareness which has been backported to Oracle JDK (parity > bug). This backport depends on JDK-8203357[1] for Metrics.java which is > being used in this patch. > In that case, let's wait until that backport is reviewed and committed. I'm looking at that now. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Tue Jul 21 16:59:28 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jul 2020 18:59:28 +0200 Subject: [8u] RFR 8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate In-Reply-To: <5574400a-750f-155a-dfae-6c7f80dc8d90@redhat.com> References: <5574400a-750f-155a-dfae-6c7f80dc8d90@redhat.com> Message-ID: <0d975286fd84dfd401da3057f339ee59ba8b13c7.camel@redhat.com> Hi Zhengyu, On Wed, 2020-07-08 at 14:10 -0400, Zhengyu Gu wrote: > I would like to backport this patch to 8u for parity with Oracle 8u271. > > The original patch does not apply cleanly. But the conflicts are minors: > > 1) Copyright line does not match. > 2) Last block is under Universe::heap() != NULL check in 8u, while > original version does not have such check. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8231779 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/fcbd54a2c2d9 > > > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8231779-8u/webrev.00/ Looks good to me. Thanks, Severin From sgehwolf at redhat.com Tue Jul 21 17:04:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Jul 2020 19:04:40 +0200 Subject: [8u] RFR: 8191678: [TESTBUG] Add keyword headful in java/awt and javax tests. In-Reply-To: References: Message-ID: <5633f25da8a6ec0ebe60acca3861e2501050ece5.camel@redhat.com> Hi Alex, On Mon, 2020-07-06 at 11:53 +0100, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8191678 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191678 > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/50d61f4b5d1a > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8191678/webrev.00/ > > This change adds "headful" keyword to a number of client tests. Only a > single test (FocusTransitionTest) from this patch is present in 8u - > only changes to it are backported. Looks good to me. Thanks, Severin > Testing: checked that changed test can be selected with "headful" keyword. > From alexey at azul.com Tue Jul 21 19:34:35 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 21 Jul 2020 19:34:35 +0000 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 In-Reply-To: References: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> <0dcb3904-48cb-deb2-985c-f95fe398cfb7@redhat.com> <786001a2-7c10-80eb-7f83-28264b838835@redhat.com> <3827b74a-bc5d-6376-dcf7-ae796584bcff@redhat.com> <88cc6eb5-815e-51d1-c701-e5fc32a8e359@redhat.com> <87194959-BEB3-4492-99D3-E0B76FC92A1E@azul.com> Message-ID: <856AA18D-546F-4151-B734-C945905D4567@azul.com> Hi Martin, Looks good to me. Thank you Alexey > On 21 Jul 2020, at 19:50, Martin Balao wrote: > > Hi Alexey, > > Thanks for your feedback. > > Webrev.04: > http://cr.openjdk.java.net/~mbalao/webrevs/8245474/8245474.webrev.04/ > > On 7/21/20 11:24 AM, Alexey Bakhtin wrote: >> KrbClientKeyExchange.java - krb5Helper is initialized in constructor and should not be changed later. It could be final. > > Fixed. > >> - SecretKey and KerberosKey are not used in Krb5ProxyImpl and could be removed from imports. If it is applied, KerberosKey should be also removed in refs.allowed script for Krb5ProxyImpl class, > > Fixed. > >> - SecretKey is not used in Krb5Proxy and could be removed from imports, > > Fixed. > >> - Krb5Helper.isAvailable() method is not used also and could be removed. > > Fixed. > > Thanks, > Martin.- > From gnu.andrew at redhat.com Tue Jul 21 19:38:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 Jul 2020 20:38:00 +0100 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: References: Message-ID: On 16/07/2020 16:48, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport of the Java Metrics classes > which are in later JDKs. It is a pre-requisite for JDK-8226575 an > Oracle JDK parity issue. Implementations of the interface are provided > for Linux only and, thus, are compiled for Linux only. This backport > differs from the original JDK 11 change in the following way: > > * MetricsTester: Arrays.compare() => Arrays.equals(). Arrays.compare() > is JDK 9+ only. > * JDK-8223147: JFR Backport, brought in test library code included in > the JDK 11 changeset. I've only done the needed adjustments to the > relevant files in the test libary. Many were already present. > * For this backport I've not included changes to the Launcher to > support -XshowSettings:system (as in later JDKs). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203357 > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/01/webrev/ > > Testing: Included docker tests on Linux x86_64. All pass. Though, they > are in dire need of reliability improvements which I'll work on as a > follow-up. > > Thanks, > Severin > Due to the differing nature of the two patches, it was necessary to split them into three; the set of changes applicable to 8u & 11u, the changes only in 8u and the changes only in 11u. 1. Common changes diffstat for 11u: b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java | 461 +++++++++ b/src/java.base/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java | 208 ++++ b/src/java.base/share/classes/jdk/internal/platform/Container.java | 45 b/src/java.base/share/classes/jdk/internal/platform/Metrics.java | 508 ++++++++++ b/test/jdk/jdk/internal/platform/cgroup/TestCgroupMetrics.java | 57 + b/test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest | 8 b/test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 | 8 b/test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le | 10 b/test/jdk/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x | 7 b/test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java | 178 +++ b/test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java | 140 ++ b/test/jdk/jdk/internal/platform/docker/TestDockerCpuMetrics.java | 167 +++ b/test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java | 151 ++ b/test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java | 61 + 14 files changed, 2009 insertions(+) diffstat for 8u: new/src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java | 461 +++++++++ new/src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java | 208 ++++ new/src/share/classes/jdk/internal/platform/Container.java | 40 new/src/share/classes/jdk/internal/platform/Metrics.java | 506 ++++++++++ new/test/jdk/internal/platform/cgroup/TestCgroupMetrics.java | 55 + new/test/jdk/internal/platform/docker/Dockerfile-BasicTest | 8 new/test/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 | 8 new/test/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le | 10 new/test/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x | 7 new/test/jdk/internal/platform/docker/MetricsCpuTester.java | 178 +++ new/test/jdk/internal/platform/docker/MetricsMemoryTester.java | 140 ++ new/test/jdk/internal/platform/docker/TestDockerCpuMetrics.java | 164 +++ new/test/jdk/internal/platform/docker/TestDockerMemoryMetrics.java | 143 ++ new/test/jdk/internal/platform/docker/TestSystemMetrics.java | 58 + 14 files changed, 1986 insertions(+) Comments: * @author tags are removed from Container.java & Metrics.java. Why? I can see a case for removing the "@since 11" but not the authorship. * Removal of test code related to the module system seems fine. 2. 8u only changes diffstat: new/make/CompileJavaClasses.gmk | 6 ++++++ new/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java | 8 ++++---- 2 files changed, 10 insertions(+), 4 deletions(-) Comments: * The Makefile changes look right and in line with those for Mac OS & AIX. * The MetricsTester changes look correct. I can only imagine this wasn't caught when the test was backported because JDK-8206456 was also backported and so the length != 0 checks that introduced were never triggered (as the metrics weren't actually there) 3. 11u only changes b/src/java.base/share/classes/sun/launcher/LauncherHelper.java | 109 + b/src/java.base/share/classes/sun/launcher/resources/launcher.properties | 8 b/test/hotspot/jtreg/runtime/containers/docker/TestCPUAwareness.java | 4 b/test/hotspot/jtreg/runtime/containers/docker/TestCPUSets.java | 4 b/test/hotspot/jtreg/runtime/containers/docker/TestMemoryAwareness.java | 5 b/test/hotspot/jtreg/runtime/containers/docker/TestMisc.java | 7 b/test/jdk/TEST.ROOT | 3 b/test/jdk/tools/launcher/Settings.java | 19 b/test/lib/jdk/test/lib/containers/cgroup/CPUSetsReader.java | 46 b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java | 589 ++++++++++ b/test/lib/jdk/test/lib/containers/docker/Common.java | 6 b/test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java | 7 b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java | 3 13 files changed, 778 insertions(+), 32 deletions(-) Comments: * I don't see why the launcher changes are being excluded. Yes, it would require a CSR [0], but this doesn't seem like a blocker to me. * All test changes are already present, including file moves, with the exception of one inapplicable import of CPUSetsReader which is not in a package in 8u. I'm not sure some of these file moves are correct, and there seems to be duplication of WhiteBox.java between the HotSpot and JDK repositories, but that's for another bug. So, action items are the missing @author tags and launcher support. [0] https://bugs.openjdk.java.net/browse/JDK-8204107 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Jul 21 20:27:12 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 21 Jul 2020 21:27:12 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Message-ID: On 20/07/2020 16:34, Anton Kozlov wrote: > Hi, > > thanks, a test case was my intention. I was playing with tests, while the fix can be reviewed. > > I see an another change in the behavior in defaultForkJoinThreadFactory. Please check the "default" testcase, which passes on openjdk8u252 and does not pass on openjdk8u262. > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.01/ > > I'm also attaching a standalone testcase to the bug. > > The vulnerability group is likely to be a better place to discuss this. > Please consider this as something searchable for anyone who meets with the issue > > Thanks, > Anton > I'm happy for this to go into 8u-dev. Please flag the bug jdk8u-fix-request and I'll approve. As regards the second issue which also applies to 11u, I suggest filing a separate bug for that to avoid confusion. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Tue Jul 21 20:36:56 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 21 Jul 2020 17:36:56 -0300 Subject: [8u] RFR 8151834: Test SmallPrimeExponentP.java times out intermittently In-Reply-To: <1fef4dca-5cb2-d14f-d08b-93e494f40672@redhat.com> References: <7201b370-802b-986f-599e-c97dd101313c@redhat.com> <1fef4dca-5cb2-d14f-d08b-93e494f40672@redhat.com> Message-ID: Hi Andrew, Thanks for having a look into this. On 7/9/20 12:02 AM, Andrew Hughes wrote: > > I would omit the @modules lines. It makes no sense to add them to 8u. > Done in Webrev.01. Webrev.01: http://cr.openjdk.java.net/~mbalao/webrevs/8151834/8151834.webrev.jdk8u.jdk.01/ If no further comments, I'd proceed to push. Thanks, Martin.- From mbalao at redhat.com Tue Jul 21 20:42:57 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 21 Jul 2020 17:42:57 -0300 Subject: [8u] RFR 8151834: Test SmallPrimeExponentP.java times out intermittently In-Reply-To: References: <7201b370-802b-986f-599e-c97dd101313c@redhat.com> <1fef4dca-5cb2-d14f-d08b-93e494f40672@redhat.com> Message-ID: <903e709f-e18b-5877-2942-332d297075a4@redhat.com> On 7/21/20 5:36 PM, Martin Balao wrote: > > If no further comments, I'd proceed to push. > Note: assuming I get a maintainers approval :) From akozlov at azul.com Wed Jul 22 05:15:39 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 22 Jul 2020 08:15:39 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Message-ID: On 21.07.2020 23:27, Andrew Hughes wrote: > As regards the second issue which also applies to 11u, I suggest filing > a separate bug for that to avoid confusion. Thanks, makes sense. It is JDK-8249846: Change of behavior after JDK-8237117 >> http://cr.openjdk.java.net/~akozlov/8249677/webrev.01/ > > I'm happy for this to go into 8u-dev. Please flag the bug > jdk8u-fix-request and I'll approve. I have to disable the second test case to avoid committing failing test. Sorry for my rush, disabled test case is http://cr.openjdk.java.net/~akozlov/8249677/webrev.02/ The difference between webrev.01 and .02 is below. I'll flag the the bug immediately after review of this. Thanks, Anton diff -r dc7b3f5b37dc test/java/util/concurrent/forkjoin/AccessControlContext.java --- a/test/java/util/concurrent/forkjoin/AccessControlContext.java Mon Jul 20 11:24:32 2020 +0300 +++ b/test/java/util/concurrent/forkjoin/AccessControlContext.java Wed Jul 22 08:12:07 2020 +0300 @@ -23,7 +23,7 @@ /* * @test - * @bug 8249677 + * @bug 8249677 8249846 * @summary AccessControlContext should not be dropped in ForkJoinThread * @run main/othervm/policy=AccessControlContext.policy/timeout=20 AccessControlContext inherit * @run main/othervm/policy=AccessControlContext.policy/timeout=20 AccessControlContext default @@ -90,7 +90,10 @@ testInherit(); break; case "default": - testDefault(); + // Case fails because of "JDK-8249846: Change of behavior after + // JDK-8237117: Better ForkJoinPool behavior". + System.out.println("Disabled: known to fail since 8u262 (see JDK-8249846)"); + //testDefault(); break; } From alexey at azul.com Wed Jul 22 10:16:01 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 22 Jul 2020 10:16:01 +0000 Subject: [8u] TLSv1.3 RFR: 8247276: Backport JDK-8161973 to JDK8u Message-ID: <4A2A621B-764F-4D07-A9D6-A114BD4AA4F0@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This patch backports JDK-8161974 into JDK8u (implementation part only). Original patch [1] applies cleanly and original commit message will be preserved. The test part will be backported as part of JDK-8245681 [2]: test/java/security/cert/PKIXRevocationChecker/OcspUnauthorized.java test/javax/net/ssl/Stapling/SSLSocketWithStapling.java The necessity of this patch has been discussed in [3] JBS task: https://bugs.openjdk.java.net/browse/JDK-8247276 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8247276/webrev.v0/ [1] - http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/4cab82804a44 [2] - http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v0/ [3] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011916.html Regards Alexey From zhaixiang at loongson.cn Wed Jul 22 13:41:17 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Wed, 22 Jul 2020 21:41:17 +0800 Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors Message-ID: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> Hi Patrick, I would like to backport the fix for: https://bugs.openjdk.java.net/browse/JDK-8235903 To OpenJDK 8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev The fix is mostly the same as the version that was committed in 15. Webrev: http://cr.openjdk.java.net/~lzhai/8235903-8u/ Thanks, Leslie Zhai From alexey at azul.com Wed Jul 22 14:53:44 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 22 Jul 2020 14:53:44 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> Message-ID: <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> Please find updated patch for JDK-8245477: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v1/ This version fixes SSL keystore path for the following three tests: - test/sun/security/tools/keytool/PrintSSL.java - test/sun/security/provider/X509Factory/BigCRL.java - test/sun/security/provider/X509Factory/BadPem.java The GIT diff is also available at: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v1/jdk.git.diff Regards Alexey > On 22 May 2020, at 16:33, Alexey Bakhtin wrote: > > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > > JBS task: https://bugs.openjdk.java.net/browse/JDK-8245477 > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v0/ > > This is a first part of TLS test update. > JDK11 and JDK8 has a different directory structure for TLS related tests. As result it is easy to miss test update and get regression. To fix this issue TLS test location should be adjusted between JDK11 and JDK8 > This patch relocates 8u TLS related tests to the directories similar to JDK11. > Also this patch fixes references to keystore and template files caused by test relocation > No one test removed, only moved to another directory. > No regression after the test relocation when executed against 8u262 > > After update, TLS related tests are located in subdirectories: > - javax/net/ssl > - sun/security/ssl > - com/sun/net/ssl > - sun/net/www/httpstest > - sun/net/www/protocol/https > > Regards > Alexey From gnu.andrew at redhat.com Wed Jul 22 17:22:09 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 22 Jul 2020 18:22:09 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Message-ID: On 22/07/2020 06:15, Anton Kozlov wrote: > > > On 21.07.2020 23:27, Andrew Hughes wrote: >> As regards the second issue which also applies to 11u, I suggest filing >> a separate bug for that to avoid confusion. > > Thanks, makes sense. It is JDK-8249846: Change of behavior after JDK-8237117 > >>> http://cr.openjdk.java.net/~akozlov/8249677/webrev.01/ >> >> I'm happy for this to go into 8u-dev. Please flag the bug >> jdk8u-fix-request and I'll approve. > > I have to disable the second test case to avoid committing failing test. > Sorry for my rush, disabled test case is > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.02/ > > The difference between webrev.01 and .02 is below. > I'll flag the the bug immediately after review of this. > > Thanks, > Anton > > diff -r dc7b3f5b37dc test/java/util/concurrent/forkjoin/AccessControlContext.java > --- a/test/java/util/concurrent/forkjoin/AccessControlContext.java Mon Jul 20 11:24:32 2020 +0300 > +++ b/test/java/util/concurrent/forkjoin/AccessControlContext.java Wed Jul 22 08:12:07 2020 +0300 > @@ -23,7 +23,7 @@ > > /* > * @test > - * @bug 8249677 > + * @bug 8249677 8249846 > * @summary AccessControlContext should not be dropped in ForkJoinThread > * @run main/othervm/policy=AccessControlContext.policy/timeout=20 AccessControlContext inherit > * @run main/othervm/policy=AccessControlContext.policy/timeout=20 AccessControlContext default > @@ -90,7 +90,10 @@ > testInherit(); > break; > case "default": > - testDefault(); > + // Case fails because of "JDK-8249846: Change of behavior after > + // JDK-8237117: Better ForkJoinPool behavior". > + System.out.println("Disabled: known to fail since 8u262 (see JDK-8249846)"); > + //testDefault(); > break; > } > > > > > I think this is wrong. The whole purpose of having a test is to catch bugs. The test *should* be failing until either a fix is in place or we make a decision to not fix it. I'm fine with adding the bug ID, comment and output that will help anyone running the test know we're aware of the issue. I'd also still like to see the comment added I suggested in my first review of this [0]. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012198.html Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akozlov at azul.com Wed Jul 22 18:27:52 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 22 Jul 2020 21:27:52 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> Message-ID: <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> On 22.07.2020 20:22, Andrew Hughes wrote: >> >> http://cr.openjdk.java.net/~akozlov/8249677/webrev.02/ >> > > I think this is wrong. The whole purpose of having a test is to catch > bugs. The test *should* be failing until either a fix is in place or we > make a decision to not fix it. > > I'm fine with adding the bug ID, comment and output that will help > anyone running the test know we're aware of the issue. I'd also still > like to see the comment added I suggested in my first review of this [0]. > > [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012198.html My bad, comment is certainly needed. I have also uncommented the test case. http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ Thanks, Anton From alexey at azul.com Wed Jul 22 18:44:08 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 22 Jul 2020 18:44:08 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> Message-ID: Please find updated patch for TLSv1,3 regression tests: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v1 This version fixes test issues caused by client default disabled TLSv1.3 protocol : - javax/net/ssl/SSLSession/ResumeTLS13withSNI.java - javax/net/ssl/SSLSocket/Tls13PacketSize.java - javax/net/ssl/Stapling/HttpsUrlConnClient.java - javax/net/ssl/Stapling/SSLEngineWithStapling.java - javax/net/ssl/Stapling/SSLSocketWithStapling.java - javax/net/ssl/Stapling/StapleEnableProps.java - javax/net/ssl/sanity/ciphersuites/CheckCipherSuites.java Also, this version reverts incorrectly modified sun/security/krb5/auto/SSL.java test Regards Alexey > On 28 May 2020, at 19:56, Alexey Bakhtin wrote: > > Hello Dmitry, > > Yes, you are right. > I?ve uploaded non-incremental webrev for the JDK-8245653 "Remove 8u TLS tests? by mistake. > I?ve updated it in the same location : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v0/ > > JDK-8245681 should be applied cleanly now > > Thank you > Alexey > > >> On 28 May 2020, at 19:07, Dmitry Cherepanov wrote: >> >> Hi Alexey, >> >> On 24.05.2020 21:05, Alexey Bakhtin wrote: >>> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u >>> >>> JBS task: https://bugs.openjdk.java.net/browse/JDK-8245681 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v0/ >>> >>> This is a third part of TLS test update. >> >> When I tried to apply patches, I got conflicts in the last step. There are a lot of rejects due to the fact that new test files already exist. >> >> For example, the third part (of test update) adds new file - test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java >> which existed before and was moved by the first part (of test update) from test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java to test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java >> >> Could you please double check that it's the latest version of webrev? >> >> Thanks >> >> Dmitry >> From gnu.andrew at redhat.com Wed Jul 22 19:33:01 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 22 Jul 2020 20:33:01 +0100 Subject: [8u] RFR 8151834: Test SmallPrimeExponentP.java times out intermittently In-Reply-To: References: <7201b370-802b-986f-599e-c97dd101313c@redhat.com> <1fef4dca-5cb2-d14f-d08b-93e494f40672@redhat.com> Message-ID: On 21/07/2020 21:36, Martin Balao wrote: > Hi Andrew, > > Thanks for having a look into this. > > On 7/9/20 12:02 AM, Andrew Hughes wrote: >> >> I would omit the @modules lines. It makes no sense to add them to 8u. >> > > Done in Webrev.01. > > Webrev.01: > http://cr.openjdk.java.net/~mbalao/webrevs/8151834/8151834.webrev.jdk8u.jdk.01/ > > If no further comments, I'd proceed to push. > > Thanks, > Martin.- > No, you wait for the new version to be reviewed. This should not have been pushed before the review was complete. Having retroactively reviewed what was pushed, I'm happy with this version. But please do not do this again. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jul 22 19:42:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 22 Jul 2020 20:42:38 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> Message-ID: On 22/07/2020 19:27, Anton Kozlov wrote: > > > On 22.07.2020 20:22, Andrew Hughes wrote: >>> >>> http://cr.openjdk.java.net/~akozlov/8249677/webrev.02/ >>> >> >> I think this is wrong. The whole purpose of having a test is to catch >> bugs. The test *should* be failing until either a fix is in place or we >> make a decision to not fix it. >> >> I'm fine with adding the bug ID, comment and output that will help >> anyone running the test know we're aware of the issue. I'd also still >> like to see the comment added I suggested in my first review of this [0]. >> >> [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012198.html > > My bad, comment is certainly needed. I have also uncommented the test case. > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ > > Thanks, > Anton > Thanks. I'm happy with this version. Please flag for approval. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From akozlov at azul.com Wed Jul 22 19:52:20 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 22 Jul 2020 22:52:20 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> Message-ID: On 22.07.2020 22:42, Andrew Hughes wrote: >> >> http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ >> > > Thanks. I'm happy with this version. > > Please flag for approval. Thanks! The flag have been set -- Anton From patrick at os.amperecomputing.com Thu Jul 23 02:13:09 2020 From: patrick at os.amperecomputing.com (Patrick Zhang OS) Date: Thu, 23 Jul 2020 02:13:09 +0000 Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> References: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> Message-ID: Hi Leslie, Thanks for the proposed backport, it is good to me (not a reviewer here). I noticed the patches had been backported to 11u last week. A reminder: you probably need to add "jdk8u-fix-request" at all the three sub-tasks, provide a webrev if it could not be applied cleanly, then ask for maintainers' approval. FYI, the process: https://wiki.openjdk.java.net/display/jdk8u Regards Patrick -----Original Message----- From: Leslie Zhai Sent: Wednesday, July 22, 2020 9:41 PM To: Patrick Zhang OS Cc: jdk8u-dev at openjdk.java.net Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors Hi Patrick, I would like to backport the fix for: https://bugs.openjdk.java.net/browse/JDK-8235903 To OpenJDK 8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev The fix is mostly the same as the version that was committed in 15. Webrev: http://cr.openjdk.java.net/~lzhai/8235903-8u/ Thanks, Leslie Zhai From zhaixiang at loongson.cn Thu Jul 23 02:27:27 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 23 Jul 2020 10:27:27 +0800 Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: References: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> Message-ID: <3888413b-8e19-db91-9e54-7d4500091bba@loongson.cn> Hi Patrick, Thanks for your kind response! ? 2020?07?23? 10:13, Patrick Zhang OS ??: > Hi Leslie, > > Thanks for the proposed backport, it is good to me (not a reviewer here). I noticed the patches had been backported to 11u last week. > > A reminder: you probably need to add "jdk8u-fix-request" at all the three sub-tasks, provide a webrev if it could not be applied cleanly, then ask for maintainers' approval. FYI, the process: https://wiki.openjdk.java.net/display/jdk8u I added "jdk8u-fix-request" label at all the three sub-tasks. > > Regards > Patrick > > -----Original Message----- > From: Leslie Zhai > Sent: Wednesday, July 22, 2020 9:41 PM > To: Patrick Zhang OS > Cc: jdk8u-dev at openjdk.java.net > Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors > > Hi Patrick, > > I would like to backport the fix for: > > https://bugs.openjdk.java.net/browse/JDK-8235903 > > To OpenJDK 8 updates dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > The fix is mostly the same as the version that was committed in 15. > > Webrev: http://cr.openjdk.java.net/~lzhai/8235903-8u/ Do I need to dive the patch into three small ones? Thanks, Leslie Zhai > > Thanks, > > Leslie Zhai > From akozlov at azul.com Thu Jul 23 06:20:24 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 23 Jul 2020 09:20:24 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> Message-ID: On 22.07.2020 22:52, Anton Kozlov wrote: > On 22.07.2020 22:42, Andrew Hughes wrote: >>> >>> http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ >>> >> >> Thanks. I'm happy with this version. >> Thanks for approval. We'll push as soon as 8u be merged into 8u-dev. Thanks, Anton From sgehwolf at redhat.com Thu Jul 23 08:49:43 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Jul 2020 10:49:43 +0200 Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: <3888413b-8e19-db91-9e54-7d4500091bba@loongson.cn> References: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> <3888413b-8e19-db91-9e54-7d4500091bba@loongson.cn> Message-ID: <66393f72e742b2d6768f351df4d81fd22ea22019.camel@redhat.com> Hi Leslie, On Thu, 2020-07-23 at 10:27 +0800, Leslie Zhai wrote: > Hi Patrick, > > Thanks for your kind response! > > > ? 2020?07?23? 10:13, Patrick Zhang OS ??: > > Hi Leslie, > > > > Thanks for the proposed backport, it is good to me (not a reviewer here). I noticed the patches had been backported to 11u last week. > > > > A reminder: you probably need to add "jdk8u-fix-request" at all the three sub-tasks, provide a webrev if it could not be applied cleanly, then ask for maintainers' approval. FYI, the process: https://wiki.openjdk.java.net/display/jdk8u > I added "jdk8u-fix-request" label at all the three sub-tasks. The -fno-common fixes were actually pushed to jdk head via 3 different bugs: https://bugs.openjdk.java.net/browse/JDK-8238380 https://bugs.openjdk.java.net/browse/JDK-8238386 https://bugs.openjdk.java.net/browse/JDK-8238388 Getting the fixes backported to JDK 8u should follow the same process. That is, for each bug there should be a RFR (if needed), get it reviewed by a jdk8u project Reviewer, and finally, once the patch got properly reviewed, the jdk8u-fix-request label can be added with a *relevant* "Fix Request"[1] comment so as to apply for Maintainer approval. Please see "Contributing" section in: https://wiki.openjdk.java.net/display/jdk8u So in this case your proposals are missing a couple of requirements: - No fix request comment - It's not clear whether or not the patch applies as is or not. Did it require a review? Who approved the review? For that reason, I've removed the jdk8u-fix-request labels for them. Please add them back once the requirements for flagging for approval have been satisfied. There are many bugs to be considered for approval and it is a waste of resources to look at bugs which aren't ready for Maintainer approval yet. There is only 3 of us and we are all busy. Thanks for your understanding! Cheers, Severin [1] https://openjdk.java.net/projects/jdk-updates/approval.html > > Regards > > Patrick > > > > -----Original Message----- > > From: Leslie Zhai > > Sent: Wednesday, July 22, 2020 9:41 PM > > To: Patrick Zhang OS > > Cc: jdk8u-dev at openjdk.java.net > > Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors > > > > Hi Patrick, > > > > I would like to backport the fix for: > > > > https://bugs.openjdk.java.net/browse/JDK-8235903 > > > > To OpenJDK 8 updates dev: > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > > > The fix is mostly the same as the version that was committed in 15. > > > > Webrev: http://cr.openjdk.java.net/~lzhai/8235903-8u/ > Do I need to dive the patch into three small ones? > > Thanks, > Leslie Zhai > > > Thanks, > > > > Leslie Zhai > > From shade at redhat.com Thu Jul 23 09:06:14 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Jul 2020 11:06:14 +0200 Subject: [8u] RFR 8166148: Fix for JDK-8165936 broke Solaris builds Message-ID: <90ab2234-2ab5-b5a2-3eb3-01e542e8c85c@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8166148 https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8e4d88e06913 This is a followup for JDK-8165936 backport, which reverts parts of it. The hunk applies cleanly when put into the old file at "solaris": jdk8u-dev/jdk $ find | grep TimeZone_md.c ./src/solaris/native/java/util/TimeZone_md.c ./src/windows/native/java/util/TimeZone_md.c 8u patch: diff -r 698607e7c543 src/solaris/native/java/util/TimeZone_md.c --- a/src/solaris/native/java/util/TimeZone_md.c Tue Sep 13 11:38:31 2016 +0200 +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Jul 23 10:49:43 2020 +0200 @@ -145,17 +145,11 @@ if (dirp == NULL) { return NULL; } name_max = pathconf(dir, _PC_NAME_MAX); - // If pathconf did not work, fall back to NAME_MAX. - if (name_max < 0) { - name_max = NAME_MAX; - } - // Some older System V systems have a very small NAME_MAX size of 14; as - // there is no way to tell readdir_r the output buffer size, lets enforce - // a mimimum buffer size. + // If pathconf did not work, fall back to a mimimum buffer size. if (name_max < 1024) { name_max = 1024; } entry = (struct dirent64 *)malloc(offsetof(struct dirent64, d_name) + name_max + 1); Testing: Linux x86_64 tier1 -- Thanks, -Aleksey From sgehwolf at redhat.com Thu Jul 23 10:08:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Jul 2020 12:08:26 +0200 Subject: [8u] RFR 8166148: Fix for JDK-8165936 broke Solaris builds In-Reply-To: <90ab2234-2ab5-b5a2-3eb3-01e542e8c85c@redhat.com> References: <90ab2234-2ab5-b5a2-3eb3-01e542e8c85c@redhat.com> Message-ID: On Thu, 2020-07-23 at 11:06 +0200, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8166148 > https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8e4d88e06913 > > This is a followup for JDK-8165936 backport, which reverts parts of it. The hunk applies cleanly > when put into the old file at "solaris": > > jdk8u-dev/jdk $ find | grep TimeZone_md.c > ./src/solaris/native/java/util/TimeZone_md.c > ./src/windows/native/java/util/TimeZone_md.c > > 8u patch: > > diff -r 698607e7c543 src/solaris/native/java/util/TimeZone_md.c > --- a/src/solaris/native/java/util/TimeZone_md.c Tue Sep 13 11:38:31 2016 +0200 > +++ b/src/solaris/native/java/util/TimeZone_md.c Thu Jul 23 10:49:43 2020 +0200 > @@ -145,17 +145,11 @@ > if (dirp == NULL) { > return NULL; > } > > name_max = pathconf(dir, _PC_NAME_MAX); > - // If pathconf did not work, fall back to NAME_MAX. > - if (name_max < 0) { > - name_max = NAME_MAX; > - } > - // Some older System V systems have a very small NAME_MAX size of 14; as > - // there is no way to tell readdir_r the output buffer size, lets enforce > - // a mimimum buffer size. > + // If pathconf did not work, fall back to a mimimum buffer size. > if (name_max < 1024) { > name_max = 1024; > } > > entry = (struct dirent64 *)malloc(offsetof(struct dirent64, d_name) + name_max + 1); > > Testing: Linux x86_64 tier1 OK. FWIW, isn't this a clean backport? Path unshuffeling is fair game. I.e. wouldn't have needed a review. Reviewed. Thanks, Severin From shade at redhat.com Thu Jul 23 10:19:04 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Jul 2020 12:19:04 +0200 Subject: [8u] RFR 8166148: Fix for JDK-8165936 broke Solaris builds In-Reply-To: References: <90ab2234-2ab5-b5a2-3eb3-01e542e8c85c@redhat.com> Message-ID: <76b1febe-4bf7-bb0d-33aa-fedcf8c41fe9@redhat.com> On 7/23/20 12:08 PM, Severin Gehwolf wrote: > OK. FWIW, isn't this a clean backport? Path unshuffeling is fair game. > I.e. wouldn't have needed a review. Well, it is not a trivial unshuffle: unix -> solaris :) You have to know this is fine for 8u, i.e. that "unix" platform files are in "solaris" folder in 8u. > Reviewed. Thanks, added the tags. -- Thanks, -Aleksey From sgehwolf at redhat.com Thu Jul 23 14:12:28 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Jul 2020 16:12:28 +0200 Subject: RFC: Disable Java container metrics via some means in 8u? Message-ID: <7d3c22f5fa25c53911136c1316d379821884d860.camel@redhat.com> Hi, I'm currently working on a backport of: JDK-8226575: OperatingSystemMXBean should be made container aware For this to work, the Java subsystem for container metrics is being backported: JDK-8203357: Container Metrics. The thing is, with the hotspot changes one can disable container detection via a flag, -XX:-UseContainerSupport. The same is not the case in the container metrics case. It cannot be disabled if backported as-is. This also means that there wouldn't be a work-around for cases where the container metrics detection is wrong. What's more, it being "wrong" might be exacerbated by the fact that container metrics have slighly different semantics than hotspot. For hotspot all 4 controllers (cpu, cpuacct, memory, cpuset) need to be present for the container detection to kick in. For Java metrics, it's sufficient for any one of the 5 controllers (cpu, cpuacct, memory, cpuset, blkio) to be present for it to return non-null. That, and some coding in the metrics code which turns missing files into 0's instead of some other known-to-be- invalid-value. That in turn can result in regressions. There've been reports about this issue happening outside a container on Linux already: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012183.html The Proposal: Ideally, use -XX:UseContainerSupport flag. Not sure if there is a way to access that hotspot flag without a native call to the JVM. I'm not sure if I like that. As an alternative to the call-into-JVM-approach, introduce a separate switch, say -Djdk.internal.platform.metrics=false, which would disable the container metrics. Hence, all usages of it would return null, thus, falling back to the old non-container code. In the OperatingSystemMXBean case it would mean to get back where it was before the new feature. Thoughts? Opinions? Thank you! Cheers, Severin From mbalao at redhat.com Thu Jul 23 14:46:11 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 23 Jul 2020 11:46:11 -0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> Message-ID: Hi, On 7/23/20 3:20 AM, Anton Kozlov wrote: > > > On 22.07.2020 22:52, Anton Kozlov wrote: >> On 22.07.2020 22:42, Andrew Hughes wrote: >>>> >>>> http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ >>>> >>> >>> Thanks. I'm happy with this version. >>> > > Thanks for approval. > We'll push as soon as 8u be merged into 8u-dev. > Even though your Webrev.03 patch has been reviewed and maintainer-approved, I believe we should revisit the 'testDefault' decision before pushing. It's not clear to me yet whether 'testDefault' behaviour will be 'expected' or 'unexpected'. In any case, that will be addressed in the context of 8249846 [1]. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8249846 From gnu.andrew at redhat.com Thu Jul 23 14:47:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 23 Jul 2020 15:47:13 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> Message-ID: On 23/07/2020 07:20, Anton Kozlov wrote: > > > On 22.07.2020 22:52, Anton Kozlov wrote: >> On 22.07.2020 22:42, Andrew Hughes wrote: >>>> >>>> http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ >>>> >>> >>> Thanks. I'm happy with this version. >>> > > Thanks for approval. > We'll push as soon as 8u be merged into 8u-dev. > > Thanks, > Anton > Testing that right now :) -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Thu Jul 23 14:54:34 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Jul 2020 16:54:34 +0200 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> Message-ID: <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> Hi, On Thu, 2020-07-23 at 11:46 -0300, Martin Balao wrote: > Hi, > > On 7/23/20 3:20 AM, Anton Kozlov wrote: > > > > On 22.07.2020 22:52, Anton Kozlov wrote: > > > On 22.07.2020 22:42, Andrew Hughes wrote: > > > > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.03/ > > > > > > > > > > > > > Thanks. I'm happy with this version. > > > > > > > > Thanks for approval. > > We'll push as soon as 8u be merged into 8u-dev. > > > > Even though your Webrev.03 patch has been reviewed and > maintainer-approved, I believe we should revisit the 'testDefault' > decision before pushing. It's not clear to me yet whether 'testDefault' > behaviour will be 'expected' or 'unexpected'. In any case, that will be > addressed in the context of 8249846 [1]. Yes, agreed. To proceed with this fix I suggest the following: Please remove testDefault code and references to 8249846 from test/java/util/concurrent/forkjoin/AccessControlContext.java It wouldn't be the right call to commit that under 8249677. The test and the fix (if any) should come with the changeset for 8249846. Thanks, Severin > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8249846 > From zhaixiang at loongson.cn Thu Jul 23 16:24:46 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 24 Jul 2020 00:24:46 +0800 Subject: [8u] RFR Backport 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 Message-ID: <33046d7d-4862-e1c3-ca5a-477faecdd1d9@loongson.cn> Hi, I would like to backport the fix for: https://bugs.openjdk.java.net/browse/JDK-8238386 To OpenJDK 8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev The fix is mostly the same as the version that was committed in 15. Webrev: http://cr.openjdk.java.net/~lzhai/8238386-8u/ Thanks, Leslie Zhai From zhaixiang at loongson.cn Thu Jul 23 16:24:39 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 24 Jul 2020 00:24:39 +0800 Subject: [8u] RFR Backport 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 Message-ID: <1f164f02-f4ae-198d-c2d2-78b1c5249c31@loongson.cn> Hi, I would like to backport the fix for: https://bugs.openjdk.java.net/browse/JDK-8238380 To OpenJDK 8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev The fix is mostly the same as the version that was committed in 15. Webrev: http://cr.openjdk.java.net/~lzhai/8238380-8u/ Thanks, Leslie Zhai From zhaixiang at loongson.cn Thu Jul 23 16:24:53 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 24 Jul 2020 00:24:53 +0800 Subject: [8u] RFR Backport 8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 Message-ID: Hi, I would like to backport the fix for: https://bugs.openjdk.java.net/browse/JDK-8238388 To OpenJDK 8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev The fix is mostly the same as the version that was committed in 15. Webrev: http://cr.openjdk.java.net/~lzhai/8238388-8u/ Thanks, Leslie Zhai From zhaixiang at loongson.cn Thu Jul 23 16:31:44 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Fri, 24 Jul 2020 00:31:44 +0800 Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: <66393f72e742b2d6768f351df4d81fd22ea22019.camel@redhat.com> References: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> <3888413b-8e19-db91-9e54-7d4500091bba@loongson.cn> <66393f72e742b2d6768f351df4d81fd22ea22019.camel@redhat.com> Message-ID: Hi Severin, ? 7/23/20 4:49 PM, Severin Gehwolf ??: > Hi Leslie, > > On Thu, 2020-07-23 at 10:27 +0800, Leslie Zhai wrote: >> Hi Patrick, >> >> Thanks for your kind response! >> >> >> ? 2020?07?23? 10:13, Patrick Zhang OS ??: >>> Hi Leslie, >>> >>> Thanks for the proposed backport, it is good to me (not a reviewer here). I noticed the patches had been backported to 11u last week. >>> >>> A reminder: you probably need to add "jdk8u-fix-request" at all the three sub-tasks, provide a webrev if it could not be applied cleanly, then ask for maintainers' approval. FYI, the process: https://wiki.openjdk.java.net/display/jdk8u >> I added "jdk8u-fix-request" label at all the three sub-tasks. > The -fno-common fixes were actually pushed to jdk head via 3 different > bugs: > https://bugs.openjdk.java.net/browse/JDK-8238380 > https://bugs.openjdk.java.net/browse/JDK-8238386 > https://bugs.openjdk.java.net/browse/JDK-8238388 > > Getting the fixes backported to JDK 8u should follow the same process. > That is, for each bug there should be a RFR (if needed), get it https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012249.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012248.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012250.html > reviewed by a jdk8u project Reviewer, and finally, once the patch got > properly reviewed, the jdk8u-fix-request label can be added with a > *relevant* "Fix Request"[1] comment so as to apply for Maintainer > approval. > > Please see "Contributing" section in: > https://wiki.openjdk.java.net/display/jdk8u > > So in this case your proposals are missing a couple of requirements: > - No fix request comment It is also able to reproduce the issue for jdk8u-dev when compiling with GCC 10. And it is able to compile with GCC 10 after applied the patchset: $ ./configure --with-debug-level=fastdebug --with-jtreg=/home/zhaixiang/jtreg $ WARNINGS_ARE_ERRORS=-Wall make test JOBS=12 Thanks, Leslie Zhai > - It's not clear whether or not the patch applies as is > or not. Did it require a review? Who approved the review? > > For that reason, I've removed the jdk8u-fix-request labels for them. > Please add them back once the requirements for flagging for approval > have been satisfied. There are many bugs to be considered for approval > and it is a waste of resources to look at bugs which aren't ready for > Maintainer approval yet. There is only 3 of us and we are all busy. > > Thanks for your understanding! > > Cheers, > Severin > > [1] https://openjdk.java.net/projects/jdk-updates/approval.html > > > >>> Regards >>> Patrick >>> >>> -----Original Message----- >>> From: Leslie Zhai >>> Sent: Wednesday, July 22, 2020 9:41 PM >>> To: Patrick Zhang OS >>> Cc: jdk8u-dev at openjdk.java.net >>> Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors >>> >>> Hi Patrick, >>> >>> I would like to backport the fix for: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8235903 >>> >>> To OpenJDK 8 updates dev: >>> >>> http://hg.openjdk.java.net/jdk8u/jdk8u-dev >>> >>> The fix is mostly the same as the version that was committed in 15. >>> >>> Webrev: http://cr.openjdk.java.net/~lzhai/8235903-8u/ >> Do I need to dive the patch into three small ones? >> >> Thanks, >> Leslie Zhai >> >>> Thanks, >>> >>> Leslie Zhai >>> From akozlov at azul.com Thu Jul 23 16:58:31 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 23 Jul 2020 19:58:31 +0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> Message-ID: Hi, On 23.07.2020 17:54, Severin Gehwolf wrote: > On Thu, 2020-07-23 at 11:46 -0300, Martin Balao wrote: >> >> Even though your Webrev.03 patch has been reviewed and >> maintainer-approved, I believe we should revisit the 'testDefault' >> decision before pushing. It's not clear to me yet whether 'testDefault' >> behaviour will be 'expected' or 'unexpected'. In any case, that will be >> addressed in the context of 8249846 [1]. > > Yes, agreed. > > To proceed with this fix I suggest the following: Please remove > testDefault code and references to 8249846 > from test/java/util/concurrent/forkjoin/AccessControlContext.java > It wouldn't be the right call to commit that under 8249677. The test > and the fix (if any) should come with the changeset for 8249846. I personally don't have a strict opinion about the test case. I specifies the behavior of 8u262, I don't think it is certainly wrong to have one before 8249846. For simplicity of logistics, we can remove the case until resolution for 8249846. Not sure what we'll decide for the test case if we also decide not to fix 8249846. But this is not really important now, I agree. New webrev with proposed changes: http://cr.openjdk.java.net/~akozlov/8249677/webrev.04/ I would like Andrew to acknowledge he have seen the new revision, to avoid missing expectations. Thanks, Anton From sgehwolf at redhat.com Thu Jul 23 17:06:00 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Jul 2020 19:06:00 +0200 Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors In-Reply-To: References: <8e8ae85a-0cbb-3fc3-e44b-fa83864b9944@loongson.cn> <3888413b-8e19-db91-9e54-7d4500091bba@loongson.cn> <66393f72e742b2d6768f351df4d81fd22ea22019.camel@redhat.com> Message-ID: <715d54b113e6e9111d69c92351a846d1c583e316.camel@redhat.com> Hi Leslie, Thanks for your patience. On Fri, 2020-07-24 at 00:31 +0800, Leslie Zhai wrote: > Hi Severin, > > ? 7/23/20 4:49 PM, Severin Gehwolf ??: > > Hi Leslie, > > > > On Thu, 2020-07-23 at 10:27 +0800, Leslie Zhai wrote: > > > Hi Patrick, > > > > > > Thanks for your kind response! > > > > > > > > > ? 2020?07?23? 10:13, Patrick Zhang OS ??: > > > > Hi Leslie, > > > > > > > > Thanks for the proposed backport, it is good to me (not a reviewer here). I noticed the patches had been backported to 11u last week. > > > > > > > > A reminder: you probably need to add "jdk8u-fix-request" at all the three sub-tasks, provide a webrev if it could not be applied cleanly, then ask for maintainers' approval. FYI, the process: https://wiki.openjdk.java.net/display/jdk8u > > > I added "jdk8u-fix-request" label at all the three sub-tasks. > > The -fno-common fixes were actually pushed to jdk head via 3 different > > bugs: > > https://bugs.openjdk.java.net/browse/JDK-8238380 > > https://bugs.openjdk.java.net/browse/JDK-8238386 > > https://bugs.openjdk.java.net/browse/JDK-8238388 > > > > Getting the fixes backported to JDK 8u should follow the same process. > > That is, for each bug there should be a RFR (if needed), get it > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012249.html > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012248.html > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012250.html Thanks. Please wait for each thread to conclude review before applying for JDK 8u backports approval via the "jdk8u-fix-request" label. In the "Fix Request" comment mention the jdk8u Reviewer who approved your patch and add a link to the RFR and webrev. Explain the risk assessment you've done and the testing of the patch you've carried out. Example: https://bugs.openjdk.java.net/browse/JDK-8194298?focusedCommentId=14347472&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14347472 > > reviewed by a jdk8u project Reviewer, and finally, once the patch got > > properly reviewed, the jdk8u-fix-request label can be added with a > > *relevant* "Fix Request"[1] comment so as to apply for Maintainer > > approval. > > > > Please see "Contributing" section in: > > https://wiki.openjdk.java.net/display/jdk8u > > > > So in this case your proposals are missing a couple of requirements: > > - No fix request comment > > It is also able to reproduce the issue for jdk8u-dev when compiling with > GCC 10. > > And it is able to compile with GCC 10 after applied the patchset: > > $ ./configure --with-debug-level=fastdebug > --with-jtreg=/home/zhaixiang/jtreg > > $ WARNINGS_ARE_ERRORS=-Wall make test JOBS=12 OK, I get that :) What I meant to describe in my previous email was that in order to request approval for a JDK 8u backport, certain steps need to be taken. It's *not* sufficient to just add label jdk8u-fix-request to a bug *without* a "Fix Request" comment like was done in your case. Hence my comment about "No fix request comment" in the earlier email. I hope that makes some sense. Thanks, Severin > > - It's not clear whether or not the patch applies as is > > or not. Did it require a review? Who approved the review? > > > > For that reason, I've removed the jdk8u-fix-request labels for them. > > Please add them back once the requirements for flagging for approval > > have been satisfied. There are many bugs to be considered for approval > > and it is a waste of resources to look at bugs which aren't ready for > > Maintainer approval yet. There is only 3 of us and we are all busy. > > > > Thanks for your understanding! > > > > Cheers, > > Severin > > > > [1] https://openjdk.java.net/projects/jdk-updates/approval.html > > > > > > > > > > Regards > > > > Patrick > > > > > > > > -----Original Message----- > > > > From: Leslie Zhai > > > > Sent: Wednesday, July 22, 2020 9:41 PM > > > > To: Patrick Zhang OS > > > > Cc: jdk8u-dev at openjdk.java.net > > > > Subject: RFR[8u] JDK-8235903: GCC default -fno-common exposes "multiple definition" link errors > > > > > > > > Hi Patrick, > > > > > > > > I would like to backport the fix for: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8235903 > > > > > > > > To OpenJDK 8 updates dev: > > > > > > > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > > > > > > > The fix is mostly the same as the version that was committed in 15. > > > > > > > > Webrev: http://cr.openjdk.java.net/~lzhai/8235903-8u/ > > > Do I need to dive the patch into three small ones? > > > > > > Thanks, > > > Leslie Zhai > > > > > > > Thanks, > > > > > > > > Leslie Zhai > > > > From sgehwolf at redhat.com Thu Jul 23 17:23:28 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Jul 2020 19:23:28 +0200 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> Message-ID: Hi Anton, On Thu, 2020-07-23 at 19:58 +0300, Anton Kozlov wrote: > Hi, > > On 23.07.2020 17:54, Severin Gehwolf wrote: > > On Thu, 2020-07-23 at 11:46 -0300, Martin Balao wrote: > > > Even though your Webrev.03 patch has been reviewed and > > > maintainer-approved, I believe we should revisit the 'testDefault' > > > decision before pushing. It's not clear to me yet whether 'testDefault' > > > behaviour will be 'expected' or 'unexpected'. In any case, that will be > > > addressed in the context of 8249846 [1]. > > > > Yes, agreed. > > > > To proceed with this fix I suggest the following: Please remove > > testDefault code and references to 8249846 > > from test/java/util/concurrent/forkjoin/AccessControlContext.java > > It wouldn't be the right call to commit that under 8249677. The test > > and the fix (if any) should come with the changeset for 8249846. > > I personally don't have a strict opinion about the test case. > I specifies the behavior of 8u262, I don't think it is certainly > wrong to have one before 8249846. > > For simplicity of logistics, we can remove the case until resolution > for 8249846. Not sure what we'll decide for the test case if we also > decide not to fix 8249846. But this is not really important now, I agree. > New webrev with proposed changes: > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.04/ This looks good. Thanks for the update! Cheers, Severin From hohensee at amazon.com Thu Jul 23 23:25:42 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 23 Jul 2020 23:25:42 +0000 Subject: RFR (M): 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double In-Reply-To: <0FDFDF99-CDA7-4356-A57C-4460AAB86C87@amazon.com> References: <0FDFDF99-CDA7-4356-A57C-4460AAB86C87@amazon.com> Message-ID: <5E1ACC7D-B484-4EF0-B602-DC56A3E32715@amazon.com> Ping. :) Thanks, Paul ?On 7/10/20, 4:52 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: Please review a proposed backport from jdk9 to jdk8u that fixes a serviceability issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8061616 Original jdk patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd Original hotspot patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1bac07f399ac jdk webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.jdk.01/ hotspot webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.hotspot.01/ Other than a few context and copyright date differences, the only change is testing InitialRAMPercentage rather than CompileThresholdScaling. The latter doesn?t exist in jdk8. Passed: jdk/ test/com/sun/management/HotSpotDiagnosticMXBean hotspot/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java Thanks, Paul From volker.simonis at gmail.com Fri Jul 24 07:11:56 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jul 2020 09:11:56 +0200 Subject: RFR (M): 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double In-Reply-To: <5E1ACC7D-B484-4EF0-B602-DC56A3E32715@amazon.com> References: <0FDFDF99-CDA7-4356-A57C-4460AAB86C87@amazon.com> <5E1ACC7D-B484-4EF0-B602-DC56A3E32715@amazon.com> Message-ID: Hi Paul, thanks for doing this downport. In general it looks good but I think there's something wrong with the webrev. For the jdk part it seems that GetVMOption.java test was merged into GetDoubleVMOption.java which from my understanding should be a new test introduced with this change. The Hotspot part looks good. Thank you and best regards, Volker On Fri, Jul 24, 2020 at 1:28 AM Hohensee, Paul wrote: > > Ping. :) > > Thanks, > Paul > > ?On 7/10/20, 4:52 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Please review a proposed backport from jdk9 to jdk8u that fixes a serviceability issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061616 > Original jdk patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd > Original hotspot patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1bac07f399ac > > jdk webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.jdk.01/ > hotspot webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.hotspot.01/ > > Other than a few context and copyright date differences, the only change is testing InitialRAMPercentage rather than CompileThresholdScaling. The latter doesn?t exist in jdk8. > > Passed: > > > jdk/ test/com/sun/management/HotSpotDiagnosticMXBean > hotspot/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java > > Thanks, > Paul > > > From rwestrel at redhat.com Fri Jul 24 07:20:38 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Jul 2020 09:20:38 +0200 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 Message-ID: <87zh7pmla1.fsf@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8240676 https://hg.openjdk.java.net/jdk/jdk/rev/6ccf082f50d4 The context in compile.hpp changed so the original patch requires a small adjustment. Testing triggered a crash, so I had to cherry-pick the change in type.cpp line 3996 from an RFE that was integrated in a later version of the jdk: 8031755 (Type speculation should be used to optimize explicit null checks). 8u webrev: http://cr.openjdk.java.net/~roland/8240676.8u/webrev.00/ Testing: x86_64, verified new test fails with the fix commented out, works otherwise, hotspot/compiler jtreg, some CTW, ran octane with nashorn. Roland. From katya at azul.com Fri Jul 24 07:38:57 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Fri, 24 Jul 2020 07:38:57 +0000 Subject: [8u] RFR: 8215727: Restore JFR thread sampler loop to old / previous behavior Message-ID: Hello, I would like to backport JFR issue 8215727 to 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8215727 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/58154bf80f90 Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8215727/webrev.00/ The patch applies almost cleanly except for the third hunk of jfrThreadSampler.cpp. It doesn't apply due to different context (iterating through java threads is different between 8u and 13), re-applied manually. Tested with tier1 and jdk.jfr tests on Linux and Windows, no regression. Thanks, Ekaterina From adinn at redhat.com Fri Jul 24 08:57:53 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Jul 2020 09:57:53 +0100 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <87zh7pmla1.fsf@redhat.com> References: <87zh7pmla1.fsf@redhat.com> Message-ID: <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> Hi Roland, On 24/07/2020 08:20, Roland Westrelin wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8240676 > https://hg.openjdk.java.net/jdk/jdk/rev/6ccf082f50d4 > > The context in compile.hpp changed so the original patch requires a > small adjustment. Testing triggered a crash, so I had to cherry-pick the > change in type.cpp line 3996 from an RFE that was integrated in a later > version of the jdk: 8031755 (Type speculation should be used to optimize > explicit null checks). > > 8u webrev: > http://cr.openjdk.java.net/~roland/8240676.8u/webrev.00/ > > Testing: x86_64, verified new test fails with the fix commented out, > works otherwise, hotspot/compiler jtreg, some CTW, ran octane with > nashorn. The changes to Type::meet_helper and Type::check_symmetrical look fine. However, I don't understand what the cherry-picked change to line 3996 in TypeAryPtr::xmeet_helper does and why it is legitimate: - return make(NotNull, NULL, tary, lazy_klass, false, off, InstanceBot); + return make(NotNull, NULL, tary, lazy_klass, false, off, InstanceBot, speculative, depth); Obviously it fixes a crash but -- for the record -- can you explain 1) why the crash happened and how this fixes it 2) why this was not needed in the upstream patch and is needed here regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From rwestrel at redhat.com Fri Jul 24 09:26:36 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Jul 2020 11:26:36 +0200 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> References: <87zh7pmla1.fsf@redhat.com> <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> Message-ID: <87wo2tmfg3.fsf@redhat.com> Hi Andrew, Thanks for looking at this one. > The changes to Type::meet_helper and Type::check_symmetrical look fine. > > However, I don't understand what the cherry-picked change to line 3996 > in TypeAryPtr::xmeet_helper does and why it is legitimate: > > - return make(NotNull, NULL, tary, lazy_klass, false, off, > InstanceBot); > + return make(NotNull, NULL, tary, lazy_klass, false, off, > InstanceBot, speculative, depth); > > Obviously it fixes a crash but -- for the record -- can you explain > > 1) why the crash happened and how this fixes it The background for this patch is the following: we saw a rare crash during testing. The crash couldn't be reproduced. My attempts at a test case didn't succeed either. So instead, I made a change to the verification code in the type system so it stress tested some combinations of types that were usually rarely exercised. It was then easy to write a test case that triggered the failure and implement a fix. The risk with this change is not so much in the fix itself but in the improvement to the verification code that can uncover bugs that we were not aware of before. That's what happens with 8u where we hit a bug that was never seen with 8u before. Object pointer types have 2 parts: a known type part and a speculative part. When the verification code triggers it verify both parts. In the case of this fix, the speculative parts gets accidentally dropped. The new verification code catches it. The previous one didn't for some reason. > 2) why this was not needed in the upstream patch and is needed here I cherry-picked the change from a later release (jdk 9 I think). So the change was not needed in the 11u patch because it was already there. Roland From adinn at redhat.com Fri Jul 24 12:32:21 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Jul 2020 13:32:21 +0100 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <87wo2tmfg3.fsf@redhat.com> References: <87zh7pmla1.fsf@redhat.com> <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> <87wo2tmfg3.fsf@redhat.com> Message-ID: On 24/07/2020 10:26, Roland Westrelin wrote: >> The changes to Type::meet_helper and Type::check_symmetrical look fine. >> >> However, I don't understand what the cherry-picked change to line 3996 >> in TypeAryPtr::xmeet_helper does and why it is legitimate: >> >> - return make(NotNull, NULL, tary, lazy_klass, false, off, >> InstanceBot); >> + return make(NotNull, NULL, tary, lazy_klass, false, off, >> InstanceBot, speculative, depth); >> >> Obviously it fixes a crash but -- for the record -- can you explain >> >> 1) why the crash happened and how this fixes it > > The background for this patch is the following: we saw a rare crash > during testing. The crash couldn't be reproduced. My attempts at a test > case didn't succeed either. So instead, I made a change to the > verification code in the type system so it stress tested some > combinations of types that were usually rarely exercised. It was then > easy to write a test case that triggered the failure and implement a > fix. Ok, understood. > The risk with this change is not so much in the fix itself but in the > improvement to the verification code that can uncover bugs that we were > not aware of before. That's what happens with 8u where we hit a bug that > was never seen with 8u before. Ok, but all the verification code happens under #ifdef ASSERT so that is only going to change behaviour in non-production builds right? i.e. the important change is the one to the meet code? > Object pointer types have 2 parts: a known type part and a speculative > part. When the verification code triggers it verify both parts. In the > case of this fix, the speculative parts gets accidentally dropped. The > new verification code catches it. The previous one didn't for some > reason. Ah ok, I get this now. The change ensures that the speculative type of the meet type is the meet of the respective speculative types. That may well change behaviour for some programs as meets are computed outside of the changed verification path. I'd like to assume the benefits of improving type accuracy override the risk. Do you think that is justified? (one might argue that improved type accuracy is not always better, especially for speculative info where avoiding the erasure might enable optimizations not previously attempted). >> 2) why this was not needed in the upstream patch and is needed here > > I cherry-picked the change from a later release (jdk 9 I think). So the > change was not needed in the 11u patch because it was already there. Doh! Of course. Thanks for the explanation. Well, the change looks good to me but I'm not really in a position to assess the risk of the xmeet change. I am reassured that it exists in the upstream code and is not known to have caused any errors. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From rwestrel at redhat.com Fri Jul 24 12:59:44 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 24 Jul 2020 14:59:44 +0200 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: References: <87zh7pmla1.fsf@redhat.com> <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> <87wo2tmfg3.fsf@redhat.com> Message-ID: <87lfj9m5kv.fsf@redhat.com> > Ok, but all the verification code happens under #ifdef ASSERT so that is > only going to change behaviour in non-production builds right? > > i.e. the important change is the one to the meet code? Yes, to both. > That may well change behaviour for some programs as meets are computed > outside of the changed verification path. I'd like to assume the > benefits of improving type accuracy override the risk. Do you think that > is justified? (one might argue that improved type accuracy is not always > better, especially for speculative info where avoiding the erasure might > enable optimizations not previously attempted). I would say both benefit and risk are small. Without the speculative type change, we'll hit failures in the new verification code so some other tweak would have to be done to work around them. Not sure what could be done but that would likely be as risky. Or only the actual fix is backported and the new verification code is left out. Then the speculative type fix is not required. But a regression wouldn't be caught either. Roland. From sgehwolf at redhat.com Fri Jul 24 13:00:12 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 24 Jul 2020 15:00:12 +0200 Subject: RFC: Disable Java container metrics via some means in 8u? In-Reply-To: <7d3c22f5fa25c53911136c1316d379821884d860.camel@redhat.com> References: <7d3c22f5fa25c53911136c1316d379821884d860.camel@redhat.com> Message-ID: On Thu, 2020-07-23 at 16:12 +0200, Severin Gehwolf wrote: > Hi, > > I'm currently working on a backport of: > > JDK-8226575: OperatingSystemMXBean should be made container aware > > For this to work, the Java subsystem for container metrics is being > backported: JDK-8203357: Container Metrics. > > The thing is, with the hotspot changes one can disable container > detection via a flag, -XX:-UseContainerSupport. The same is not the > case in the container metrics case. It cannot be disabled if backported > as-is. This also means that there wouldn't be a work-around for cases > where the container metrics detection is wrong. What's more, it being > "wrong" might be exacerbated by the fact that container metrics have > slighly different semantics than hotspot. For hotspot all 4 controllers > (cpu, cpuacct, memory, cpuset) need to be present for the container > detection to kick in. For Java metrics, it's sufficient for any one of > the 5 controllers (cpu, cpuacct, memory, cpuset, blkio) to be present > for it to return non-null. That, and some coding in the metrics code > which turns missing files into 0's instead of some other known-to-be- > invalid-value. That in turn can result in regressions. > > There've been reports about this issue happening outside a container on > Linux already: > > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012183.html > > The Proposal: > > Ideally, use -XX:UseContainerSupport flag. Not sure if there is a way > to access that hotspot flag without a native call to the JVM. I'm not > sure if I like that. Here is a proof of concept patch for this: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/UseContainerSupport/01/ http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/UseContainerSupport/before-after.txt Perhaps this should be added to jdk/jdk first and backported all the way to 8... Thanks, Severin > As an alternative to the call-into-JVM-approach, introduce a separate > switch, say -Djdk.internal.platform.metrics=false, which would disable > the container metrics. Hence, all usages of it would return null, thus, > falling back to the old non-container code. In the > OperatingSystemMXBean case it would mean to get back where it was > before the new feature. > > Thoughts? Opinions? > > Thank you! > > Cheers, > Severin > > From hohensee at amazon.com Fri Jul 24 15:16:23 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 Jul 2020 15:16:23 +0000 Subject: RFR (M): 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double Message-ID: <0F926601-7BF1-4826-9825-04B8BD5C46BC@amazon.com> GetDoubleVMOption.java is indeed a new file introduced by this patch. If you look closely at the webrev entry for GetDoubleVMOption.java, you'll see (was test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java) The patch first copied GetVMOption.java to create GetDoubleVMOption.java and then modified it to get the final version. What you see in the webrev diff are the differences between the final version of GetDoubleVMOption.java and GetVMOption.java. If you compare the 'Raw' version of GetDoubleVMOption.java with the one in http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd you'll see they're the same except for switching to InitialRAMPercentage. Thanks, Paul ?On 7/24/20, 12:12 AM, "Volker Simonis" wrote: Hi Paul, thanks for doing this downport. In general it looks good but I think there's something wrong with the webrev. For the jdk part it seems that GetVMOption.java test was merged into GetDoubleVMOption.java which from my understanding should be a new test introduced with this change. The Hotspot part looks good. Thank you and best regards, Volker On Fri, Jul 24, 2020 at 1:28 AM Hohensee, Paul wrote: > > Ping. :) > > Thanks, > Paul > > On 7/10/20, 4:52 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > Please review a proposed backport from jdk9 to jdk8u that fixes a serviceability issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061616 > Original jdk patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd > Original hotspot patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1bac07f399ac > > jdk webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.jdk.01/ > hotspot webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.hotspot.01/ > > Other than a few context and copyright date differences, the only change is testing InitialRAMPercentage rather than CompileThresholdScaling. The latter doesn?t exist in jdk8. > > Passed: > > > jdk/ test/com/sun/management/HotSpotDiagnosticMXBean > hotspot/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java > > Thanks, > Paul > > > From volker.simonis at gmail.com Fri Jul 24 15:36:33 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Jul 2020 17:36:33 +0200 Subject: RFR (M): 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double In-Reply-To: <0F926601-7BF1-4826-9825-04B8BD5C46BC@amazon.com> References: <0F926601-7BF1-4826-9825-04B8BD5C46BC@amazon.com> Message-ID: On Fri, Jul 24, 2020 at 5:16 PM Hohensee, Paul wrote: > > GetDoubleVMOption.java is indeed a new file introduced by this patch. If you look closely at the webrev entry for GetDoubleVMOption.java, you'll see > > (was test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java) > I saw that but I hadn't looked at the raw version. From the unified diff it's hard to see that the outcome will be exactly that of the new file. Have you intentionally created GetDoubleVMOption.java as a copy of GetVMOption.java or why else did it show up in this way in the webrev? I find it hard to review such copy/patch diffs of otherwise unrelated files. > The patch first copied GetVMOption.java to create GetDoubleVMOption.java and then modified it to get the final version. What you see in the webrev diff are the differences between the final version of GetDoubleVMOption.java and GetVMOption.java. If you compare the 'Raw' version of GetDoubleVMOption.java with the one in > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd > Agreed. If I import and apply the whole patch it also looks fine. Please consider this downported as reviewed from my side. Best regards, Volker > you'll see they're the same except for switching to InitialRAMPercentage. > > Thanks, > Paul > > ?On 7/24/20, 12:12 AM, "Volker Simonis" wrote: > > Hi Paul, > > thanks for doing this downport. In general it looks good but I think > there's something wrong with the webrev. > > For the jdk part it seems that GetVMOption.java test was merged into > GetDoubleVMOption.java which from my understanding should be a new > test introduced with this change. > > The Hotspot part looks good. > > Thank you and best regards, > Volker > > On Fri, Jul 24, 2020 at 1:28 AM Hohensee, Paul wrote: > > > > Ping. :) > > > > Thanks, > > Paul > > > > On 7/10/20, 4:52 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > > > Please review a proposed backport from jdk9 to jdk8u that fixes a serviceability issue. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061616 > > Original jdk patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd > > Original hotspot patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1bac07f399ac > > > > jdk webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.jdk.01/ > > hotspot webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.hotspot.01/ > > > > Other than a few context and copyright date differences, the only change is testing InitialRAMPercentage rather than CompileThresholdScaling. The latter doesn?t exist in jdk8. > > > > Passed: > > > > > > jdk/ test/com/sun/management/HotSpotDiagnosticMXBean > > hotspot/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java > > > > Thanks, > > Paul > > > > > > > From hohensee at amazon.com Fri Jul 24 15:52:02 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 24 Jul 2020 15:52:02 +0000 Subject: RFR (M): 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double Message-ID: <0AC5621E-0B9F-4BF4-BFF4-9A3F421E52AB@amazon.com> Thank you, Volker, I'll tag the issue. By way of explanation, the patch generated by "hg export" included the copy, which in the interest of minimal patch modification I didn't change. I've put the jdk9 patch on cr.openjdk.java.net at http://cr.openjdk.java.net/~phh/8061616/8061616.jdk9.patch Paul ?On 7/24/20, 8:37 AM, "Volker Simonis" wrote: On Fri, Jul 24, 2020 at 5:16 PM Hohensee, Paul wrote: > > GetDoubleVMOption.java is indeed a new file introduced by this patch. If you look closely at the webrev entry for GetDoubleVMOption.java, you'll see > > (was test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java) > I saw that but I hadn't looked at the raw version. From the unified diff it's hard to see that the outcome will be exactly that of the new file. Have you intentionally created GetDoubleVMOption.java as a copy of GetVMOption.java or why else did it show up in this way in the webrev? I find it hard to review such copy/patch diffs of otherwise unrelated files. > The patch first copied GetVMOption.java to create GetDoubleVMOption.java and then modified it to get the final version. What you see in the webrev diff are the differences between the final version of GetDoubleVMOption.java and GetVMOption.java. If you compare the 'Raw' version of GetDoubleVMOption.java with the one in > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd > Agreed. If I import and apply the whole patch it also looks fine. Please consider this downported as reviewed from my side. Best regards, Volker > you'll see they're the same except for switching to InitialRAMPercentage. > > Thanks, > Paul > > On 7/24/20, 12:12 AM, "Volker Simonis" wrote: > > Hi Paul, > > thanks for doing this downport. In general it looks good but I think > there's something wrong with the webrev. > > For the jdk part it seems that GetVMOption.java test was merged into > GetDoubleVMOption.java which from my understanding should be a new > test introduced with this change. > > The Hotspot part looks good. > > Thank you and best regards, > Volker > > On Fri, Jul 24, 2020 at 1:28 AM Hohensee, Paul wrote: > > > > Ping. :) > > > > Thanks, > > Paul > > > > On 7/10/20, 4:52 PM, "jdk8u-dev on behalf of Hohensee, Paul" wrote: > > > > Please review a proposed backport from jdk9 to jdk8u that fixes a serviceability issue. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061616 > > Original jdk patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ef6ec39fd6bd > > Original hotspot patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/1bac07f399ac > > > > jdk webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.jdk.01/ > > hotspot webrev: http://cr.openjdk.java.net/~phh/8061616/webrev.8u.hotspot.01/ > > > > Other than a few context and copyright date differences, the only change is testing InitialRAMPercentage rather than CompileThresholdScaling. The latter doesn?t exist in jdk8. > > > > Passed: > > > > > > jdk/ test/com/sun/management/HotSpotDiagnosticMXBean > > hotspot/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java > > > > Thanks, > > Paul > > > > > > > From gnu.andrew at redhat.com Fri Jul 24 16:17:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 24 Jul 2020 17:17:00 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> Message-ID: On 23/07/2020 17:58, Anton Kozlov wrote: > Hi, > > On 23.07.2020 17:54, Severin Gehwolf wrote: >> On Thu, 2020-07-23 at 11:46 -0300, Martin Balao wrote: >>> >>> Even though your Webrev.03 patch has been reviewed and >>> maintainer-approved, I believe we should revisit the 'testDefault' >>> decision before pushing. It's not clear to me yet whether 'testDefault' >>> behaviour will be 'expected' or 'unexpected'. In any case, that will be >>> addressed in the context of 8249846 [1]. >> >> Yes, agreed. >> >> To proceed with this fix I suggest the following: Please remove >> testDefault code and references to 8249846 >> from test/java/util/concurrent/forkjoin/AccessControlContext.java >> It wouldn't be the right call to commit that under 8249677. The test >> and the fix (if any) should come with the changeset for 8249846. > > I personally don't have a strict opinion about the test case. > I specifies the behavior of 8u262, I don't think it is certainly > wrong to have one before 8249846. > > For simplicity of logistics, we can remove the case until resolution > for 8249846. Not sure what we'll decide for the test case if we also > decide not to fix 8249846. But this is not really important now, I agree. > New webrev with proposed changes: > > http://cr.openjdk.java.net/~akozlov/8249677/webrev.04/ > > I would like Andrew to acknowledge he have seen the new revision, to avoid > missing expectations. > > Thanks, > Anton > I discussed this with Martin yesterday evening. I'd prefer we went with webrev.03 and then separately inverted the test to make it absolutely clear that, at present, the new behaviour is the expected behaviour. If we omit the test for 8249846, and that is then later closed as WONTFIX, we risk losing the testcase for this behaviour. I also don't see it as wrong to have a test for 8249846 included here. I've pushed the fix following the merge of 8u262-ga: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/4eca7c32a9c8 I'll follow up shortly with a patch for the test to match the current behaviour. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Fri Jul 24 16:31:14 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 24 Jul 2020 13:31:14 -0300 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <4eaf0cbe-e7cc-70a9-546d-f75479fb7b79@cs.oswego.edu> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> Message-ID: On Fri, Jul 24, 2020 at 1:18 PM Andrew Hughes wrote: > I discussed this with Martin yesterday evening. I'd prefer we went with > webrev.03 and then separately inverted the test to make it absolutely > clear that, at present, the new behaviour is the expected behaviour. > The inverted test sounds like a good idea to me, so we enforce the expected behavior -whatever the expected behavior is-. I'd have gone with Webrev.04 and include the inverted test in a separated commit. Anyways, it's too late for that. From gnu.andrew at redhat.com Fri Jul 24 16:46:32 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 24 Jul 2020 17:46:32 +0100 Subject: [8u] RFR: 8249677: Regression after JDK-8237117: Better ForkJoinPool behavior In-Reply-To: References: <40d770e4-0109-fcb5-e9fc-ec29b115a816@azul.com> <73712200-C763-4868-993B-B2D2D52CEF83@oracle.com> <9E2C4937-544A-4279-8E9B-AA06982B5DDF@oracle.com> <870a4dd2-4490-0f4c-cb08-400b51150dd4@azul.com> <539d3160d4d67600a65472a41e12fde5bde7275a.camel@redhat.com> <02b8f66f-e2b4-3a29-f54b-8a2c275104e7@azul.com> <2c1d0f2916fbc729d54a34b82fcf3fb2c5c12c2a.camel@redhat.com> Message-ID: <7986e2d0-9329-97cd-f75c-e2d0f028d422@redhat.com> On 24/07/2020 17:31, Martin Balao wrote: > On Fri, Jul 24, 2020 at 1:18 PM Andrew Hughes wrote: >> I discussed this with Martin yesterday evening. I'd prefer we went with >> webrev.03 and then separately inverted the test to make it absolutely >> clear that, at present, the new behaviour is the expected behaviour. >> > > The inverted test sounds like a good idea to me, so we enforce the > expected behavior -whatever the expected behavior is-. I'd have gone > with Webrev.04 and include the inverted test in a separated commit. > Anyways, it's too late for that. > I wanted to get the test itself under Anton's authorship, not mine. I'm not sure it matters greatly that the test fails for one revision :) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jul 24 16:36:52 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 24 Jul 2020 17:36:52 +0100 Subject: RFR: [8u] JDK-8250546,,Expect changed behaviour reported in JDK-8249846 Message-ID: <214d9d8c-2728-54ac-6f9d-c8350d9d3ea7@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8250546 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8250546/webrev.01/ Further to the fix for JDK-8249677, and the test added for that issue and JDK-8249846, this patch updates the test to expect the current 8u262 behaviour of ForkJoinPool threads and not that in 8u252 and prior. If/when such a time comes that 8249846 is resolved, that fix should change the test again to reflect the new behaviour. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Fri Jul 24 19:51:34 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 24 Jul 2020 16:51:34 -0300 Subject: RFR: [8u] JDK-8250546, , Expect changed behaviour reported in JDK-8249846 In-Reply-To: <214d9d8c-2728-54ac-6f9d-c8350d9d3ea7@redhat.com> References: <214d9d8c-2728-54ac-6f9d-c8350d9d3ea7@redhat.com> Message-ID: On Fri, Jul 24, 2020 at 1:53 PM Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250546 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8250546/webrev.01/ > > Further to the fix for JDK-8249677, and the test added for that issue > and JDK-8249846, this patch updates the test to expect the current 8u262 > behaviour of ForkJoinPool threads and not that in 8u252 and prior. > > If/when such a time comes that 8249846 is resolved, that fix should > change the test again to reflect the new behaviour. Looks good to me. Thanks, Martin.- From adinn at redhat.com Fri Jul 24 21:07:48 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Jul 2020 22:07:48 +0100 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <87lfj9m5kv.fsf@redhat.com> References: <87zh7pmla1.fsf@redhat.com> <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> <87wo2tmfg3.fsf@redhat.com> <87lfj9m5kv.fsf@redhat.com> Message-ID: <7e9268bf-41d5-52d3-cb6c-449fabb0f192@redhat.com> On 24/07/2020 13:59, Roland Westrelin wrote: >> That may well change behaviour for some programs as meets are computed >> outside of the changed verification path. I'd like to assume the >> benefits of improving type accuracy override the risk. Do you think that >> is justified? (one might argue that improved type accuracy is not always >> better, especially for speculative info where avoiding the erasure might >> enable optimizations not previously attempted). > > I would say both benefit and risk are small. Without the speculative > type change, we'll hit failures in the new verification code so some > other tweak would have to be done to work around them. Not sure what > could be done but that would likely be as risky. Or only the actual fix > is backported and the new verification code is left out. Then the > speculative type fix is not required. But a regression wouldn't be > caught either. That's a good enough justification for me. Ship it! . . . well, modulo maintainer approval ;-) regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From mbalao at redhat.com Fri Jul 24 22:20:21 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 24 Jul 2020 19:20:21 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> Message-ID: Hi Alexey, On Wed, Jul 22, 2020 at 11:55 AM Alexey Bakhtin wrote: > > Please find updated patch for JDK-8245477: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v1/ > Thanks for submitting the series of patches related to TLS tests. I'm trying to understand the rationale behind each step and have some questions. 1) Those tests relocated as part of Step 9 - 8245477, are 8u tests or did you replace them with newer JDK-11 versions in a single step? 2) Is there any other change in addition to relocation and 'references to keystore and template files' modifications? My understanding is that they are just JDK-8 relocated tests with some fixes only to pass, but there is nothing new on them. 3) Should we expect all tests passing in Step 9? If not, why? I read 'no regression' in your first comment but that does not say whether they are all passing or not. 4) I've seen tests that were relocated in Step 9 (and fixed), deleted in Step 10 and added as new files in Step 11 (i.e. RejectClientRenego.java). How did you decide which tests had to be relocated, which had to be deleted in Step 10 and which had to be added in Step 11? 5) Was any test not relocated in Step 9, not deleted in Step 10 or not added in Step 11? Why? 6) What would be the downside if we just delete test/sun/security/ssl/* (and any other directory whose tests are SSL-related) and in the next step add them from JDK-11? The problem here, from a reviewer's side, is that I need a criteria to judge these test relocations. This criteria would be the 8u backport of 8032473, but I'm not sure that we are aligned on that. 8032473 won't apply cleanly and it's a mega-patch. If we are doing relocations to proceed with file replacement later (by file replacement I mean deleting everything in one step and adding all in the next), we can simplify things and do file replacement now agreeing on which are the SSL-related directories. In example: why not deleting "sun/security/ssl" and adding (from JDK-11) "sun/security/ssl", "sun/net/www/protocol/https", "javax/net/ssl" and "com/sun/net/ssl"? Note: there can be tests that fail because they expect a different public API. But that is unavoidable. NOTE: I'm just brainstorming, not convinced yet of anything. Thanks, Martin.- From aph at redhat.com Sat Jul 25 15:14:12 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 25 Jul 2020 16:14:12 +0100 Subject: [8u] RFR: 8240676: Meet not symmetric failure when running lucene on jdk8 In-Reply-To: <7e9268bf-41d5-52d3-cb6c-449fabb0f192@redhat.com> References: <87zh7pmla1.fsf@redhat.com> <9ae30a2b-3443-9954-950e-08e7e26ddd97@redhat.com> <87wo2tmfg3.fsf@redhat.com> <87lfj9m5kv.fsf@redhat.com> <7e9268bf-41d5-52d3-cb6c-449fabb0f192@redhat.com> Message-ID: On 24/07/2020 22:07, Andrew Dinn wrote: > On 24/07/2020 13:59, Roland Westrelin wrote: >>> That may well change behaviour for some programs as meets are computed >>> outside of the changed verification path. I'd like to assume the >>> benefits of improving type accuracy override the risk. Do you think that >>> is justified? (one might argue that improved type accuracy is not always >>> better, especially for speculative info where avoiding the erasure might >>> enable optimizations not previously attempted). >> >> I would say both benefit and risk are small. Without the speculative >> type change, we'll hit failures in the new verification code so some >> other tweak would have to be done to work around them. Not sure what >> could be done but that would likely be as risky. Or only the actual fix >> is backported and the new verification code is left out. Then the >> speculative type fix is not required. But a regression wouldn't be >> caught either. > That's a good enough justification for me. Ship it! > > . . . well, modulo maintainer approval ;-) Yeah, OK. Of course I'm not super keen on a change in C2 which fixes a bug that we can't reproduce, but it'll have to do. -- 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 xxinliu at amazon.com Mon Jul 27 05:44:14 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 27 Jul 2020 05:44:14 +0000 Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib In-Reply-To: <0EEB7BC0-F348-4182-9DCB-4303DFF671D5@amazon.com> References: <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com> <22c7e7db-229f-1631-39c7-60ee4ad958a6@amazon.com>, <0EEB7BC0-F348-4182-9DCB-4303DFF671D5@amazon.com> Message-ID: <1595828653959.18371@amazon.com> hi, Paul and Severin, I redo this per your feedbacks on JBS. here is the new revision. Could you take a look? Webrev: https://cr.openjdk.java.net/~xliu/8247817/01/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8247817 changes since last revision. 1. I remove SkippedException from jdk. I move it to my vmTestBase patchset. 2. I detect a merging conflicts in Platform.java. the method sharedLibraryPathVariableName() has been added in JDK-8238225 I drop mine. thanks, --lx ________________________________________ From: Hohensee, Paul Sent: Friday, June 19, 2020 10:04 AM To: Liu, Xin; jdk8u-dev at openjdk.java.net Subject: Re: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib Thank you, Xin. Lgtm. Paul ?On 6/18/20, 4:00 PM, "Liu, Xin" wrote: hi, Paul, I believe those code were brought in from upstream for JFR, but JFR testing may not cover them. I am working a new patchset which allows users to run vmtestbase using jdk/test/lib of jdk repo. I ran into those problems when I execute vmtestcase. for example, http://cr.openjdk.java.net/~xliu/8247817/00/webrev/test/lib/jdk/test/lib/util/JarUtils.java.udiff.html This class makes use InputStream.transferTo, which is available since jdk9 (https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream) It can't be compiled with the runtime of jdk8u. Other 3 symbols like Platform.sharedLibraryPathVariableName(), Utils.TEST_ROOT and jtreg.SkippedException are all symbols referred by hotspot/test/vmTestbase. yes, we can recursively backport them, but it is time-consuming and introduce a lot of less irrelevant code. They are all incremental changes which won't incur any conflict. thanks, --lx On 6/18/20 2:27 PM, Hohensee, Paul wrote: > Would you describe the problems you encountered that this patch solves please? The Whitebox issue is obvious, but the purpose of the other changes isn't. > > Thanks, > Paul > > On 6/17/20, 5:29 PM, "jdk8u-dev on behalf of Liu, Xin" wrote: > > Hi, maintainers, > > Could you review this webrev for jdk8u-dev/jdk? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8247817 > > Webrev: http://cr.openjdk.java.net/~xliu/8247817/00/webrev/ > > > Description: > > I ran into these problems when I try to use jdk/test/lib of jdk repo, > which was introduced for JFR testing, to run hotspot/test/vmtestbase. > > I guess the JFR testing doesn't cover them. IMHO, we'd better fix them > for jdk8u, Otherwise we will observe something strange when we really > use them. > > eg. The whitebox api isMethodCompilable doesn't work. It's because > CompLevel_any=-1 in jdk8u. Whitebox APIs must be consistent with the > implementation of hotspot. > > thanks, > > --lx > > > From alexey at azul.com Mon Jul 27 05:47:30 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 27 Jul 2020 05:47:30 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> Message-ID: <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> Hello Martin, Please find my answers below Regards Alexey > On 25 Jul 2020, at 01:20, Martin Balao wrote: > > Hi Alexey, > > On Wed, Jul 22, 2020 at 11:55 AM Alexey Bakhtin wrote: >> >> Please find updated patch for JDK-8245477: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v1/ >> > > Thanks for submitting the series of patches related to TLS tests. I'm > trying to understand the rationale behind each step and have some > questions. > > 1) Those tests relocated as part of Step 9 - 8245477, are 8u tests or > did you replace them with newer JDK-11 versions in a single step? Step 9 relocates 8u test only. It does not replace tests with JDK-11 version > > 2) Is there any other change in addition to relocation and 'references > to keystore and template files' modifications? My understanding is > that they are just JDK-8 relocated tests with some fixes only to pass, > but there is nothing new on them. Yes, you are correct. The only changes in the tests is update path to keystore and template files. > > 3) Should we expect all tests passing in Step 9? If not, why? I read > 'no regression' in your first comment but that does not say whether > they are all passing or not. I can not say all test passed, because of three test fails on the original TLSv1.2 implementation and original test file location : - javax/net/ssl/ciphersuites/DisabledAlgorithms.java - sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java - sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java These test still fails after relocation with original TLSv1.2 implementation. This is a reason I wrote ?no regression? instead of all test passed. > > 4) I've seen tests that were relocated in Step 9 (and fixed), deleted > in Step 10 and added as new files in Step 11 (i.e. > RejectClientRenego.java). How did you decide which tests had to be > relocated, which had to be deleted in Step 10 and which had to be > added in Step 11? In Step 9 I have compared test location in JDK8 and JDK11 and perform test relocation. So, after relocation tests located in the same path in JDK8 and JDK11 It will simplify father test merge, because of test located in the same test path E.g.with RejectClientRenego.java test: 1) RejectClientRenego.java is located in sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl in JDK8 repository sun/security/ssl/SSLSocketImpl in JDK11 repository In Step9 RejectClientRenego.java is moved to test/sun/security/ssl/SSLSocketImpl directory 2) RejectClientRenego.java is not identical in the JDK8 and JDK11 repositories. So, RejectClientRenego.java is removed in Step 10. 3) New version of RejectClientRenego.java is added at Step 11. > > 5) Was any test not relocated in Step 9, not deleted in Step 10 or not > added in Step 11? Why? Yes. There are a lot of test that was not modified in terms of location or implementation. These test was not modified in Step 9, Step 10 or Step 11: E.g.: - sun/security/ssl/CertPathRestrictions/JSSEClient.java - sun/security/ssl/CipherSuite/NoDesRC4CiphSuite.java - sun/security/ssl/DHKeyExchange/LegacyDHEKeyExchange.java - sun/security/ssl/HandshakeHash/* - sun/security/ssl/ServerHandshaker/HelloExtensionsTest.java - sun/security/ssl/SSLContextImpl/CustomizedCipherSuites.java and many other tests > > 6) What would be the downside if we just delete > test/sun/security/ssl/* (and any other directory whose tests are > SSL-related) and in the next step add them from JDK-11? As mentioned above, A lot of test was not relocated or modified. So, in this case we just lost history without good reason for unmodified tests. Another reason - is JDK8 contains extra tests which is not present in JDK11: - sun/security/ssl/X509KeyManager/CertificateAuthorities.java - sun/security/ssl/SSLEngineImpl/CloseInboundException.java - sun/security/ssl/SSLContextImpl/DefautlCacheSize.java - sun/security/ssl/SessionIdCollisionTest.java - sun/net/www/https/ChunkedOutputStream/Test.java (was sun/security/ssl/sun/net/www/http/ChunkedOutputStream/Test.java) If we go with delete/add solution we could lost these tests. Also, my solution with three steps allow to verify test consistence after each step : - after Step 9 - no regression with original TLSv1.2 implementation - after Step 10 - test passed with original TLSv1.2 implementation and new TLSv1.3 implementation - after Step 11 - test passed with new TLSv1.3 implementation I understand your concerns about review, but my suggestion keeps more history and allows to track test relocation. > > The problem here, from a reviewer's side, is that I need a criteria to > judge these test relocations. This criteria would be the 8u backport > of 8032473, but I'm not sure that we are aligned on that. 8032473 > won't apply cleanly and it's a mega-patch. If we are doing relocations > to proceed with file replacement later (by file replacement I mean > deleting everything in one step and adding all in the next), we can > simplify things and do file replacement now agreeing on which are the > SSL-related directories. In example: why not deleting > "sun/security/ssl" and adding (from JDK-11) "sun/security/ssl", > "sun/net/www/protocol/https", "javax/net/ssl" and "com/sun/net/ssl"? > Note: there can be tests that fail because they expect a different > public API. But that is unavoidable. > > NOTE: I'm just brainstorming, not convinced yet of anything. > > Thanks, > Martin.- From jaroslav.bachorik at datadoghq.com Mon Jul 27 10:47:57 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Mon, 27 Jul 2020 12:47:57 +0200 Subject: [8u] RFR: 8215727: Restore JFR thread sampler loop to old / previous behavior In-Reply-To: References: Message-ID: Hi Ekaterina, the change looks good. Not a reviewer, though. Cheers, -JB- On Fri, Jul 24, 2020 at 9:43 AM Ekaterina Vergizova wrote: > > Hello, > I would like to backport JFR issue 8215727 to 8u. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215727 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/58154bf80f90 > Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8215727/webrev.00/ > > The patch applies almost cleanly except for the third hunk of jfrThreadSampler.cpp. > It doesn't apply due to different context (iterating through java threads is different between 8u and 13), re-applied manually. > > Tested with tier1 and jdk.jfr tests on Linux and Windows, no regression. > > Thanks, > Ekaterina > From sgehwolf at redhat.com Mon Jul 27 13:14:30 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 27 Jul 2020 15:14:30 +0200 Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib In-Reply-To: <1595828653959.18371@amazon.com> References: <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com> <22c7e7db-229f-1631-39c7-60ee4ad958a6@amazon.com> ,<0EEB7BC0-F348-4182-9DCB-4303DFF671D5@amazon.com> <1595828653959.18371@amazon.com> Message-ID: Hi, On Mon, 2020-07-27 at 05:44 +0000, Liu, Xin wrote: > hi, Paul and Severin, > > I redo this per your feedbacks on JBS. here is the new revision. > Could you take a look? > > Webrev: https://cr.openjdk.java.net/~xliu/8247817/01/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8247817 > > changes since last revision. > 1. I remove SkippedException from jdk. I move it to my vmTestBase patchset. > 2. I detect a merging conflicts in Platform.java. the method sharedLibraryPathVariableName() has been added in JDK-8238225 > I drop mine. Looks good to me. Thanks, Severin From zgu at redhat.com Mon Jul 27 14:40:37 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Jul 2020 10:40:37 -0400 Subject: [8u] RFR 8242556: Cannot load RSASSA-PSS public key with non-null params from byte array Message-ID: I would like to backport this to 8u for parity with Oracle 8u271. The original patch does not apply cleanly. The only conflicts are copyright lines of PSSParametersTest.java and TestPSSKeySupport.java, where they are already up-to-date. Original bug: https://bugs.openjdk.java.net/browse/JDK-8242556 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9eea66de64df 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242556-8u/webrev.00/ Test: jdk_security Thanks, -Zhengyu From mbalao at redhat.com Mon Jul 27 15:51:30 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 27 Jul 2020 12:51:30 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> Message-ID: <0fbcbbbf-4898-2f8a-3030-0cdd19b2a601@redhat.com> Hi Alexey, On 7/27/20 2:47 AM, Alexey Bakhtin wrote: > I understand your concerns about review, but my suggestion keeps more history and allows to track test relocation. > Thanks for your thorough explanation of these changes, I now have a more clear picture of what's behind. I see and agree to some extent with your arguments. My thinking was that preserving SSL test's history after accepting to replace their corresponding library files was not big deal, though. This approach has taken more work from your side, and I'll certainly take from mine. Anyways, I'll review the modifications and the relocations as your proposed them here -possibly against 8032473-. In regards to those tests present in JDK-8 and not in JDK-11, as long as they are not failing I'll probably be okay. Thanks, Martin.- From hohensee at amazon.com Mon Jul 27 16:33:24 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 27 Jul 2020 16:33:24 +0000 Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib Message-ID: <319018DF-C23C-43DD-9D89-7CF556D01D7E@amazon.com> +1. Paul ?On 7/27/20, 6:15 AM, "Severin Gehwolf" wrote: Hi, On Mon, 2020-07-27 at 05:44 +0000, Liu, Xin wrote: > hi, Paul and Severin, > > I redo this per your feedbacks on JBS. here is the new revision. > Could you take a look? > > Webrev: https://cr.openjdk.java.net/~xliu/8247817/01/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8247817 > > changes since last revision. > 1. I remove SkippedException from jdk. I move it to my vmTestBase patchset. > 2. I detect a merging conflicts in Platform.java. the method sharedLibraryPathVariableName() has been added in JDK-8238225 > I drop mine. Looks good to me. Thanks, Severin From zgu at redhat.com Mon Jul 27 18:32:46 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Jul 2020 14:32:46 -0400 Subject: [8u] RFR 8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent Message-ID: I would like to backport this to 8u for parity with Oracle 8u281. The original patch does not apply cleanly. 1) classFileParser.cpp 8u does not have the changes from JDK-8140485, so relaxed class file check is performed from ClassFileParser::parseClassFile, instead of ClassFileParser's constructor. The conflicts are easy to resolve. 2) verifier.hpp Copyright line already updated in 8u 3) FormatCheckingTest.java Changed @library from /test/lib -> /testlibrary Changed imports to reflect test library changes Removed @modules Original bug: https://bugs.openjdk.java.net/browse/JDK-8148854 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/92e705c1e6e6 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8148854-8u/webrev.00/ Test: hotspot/runtime Thanks, -Zhengyu From mbalao at redhat.com Mon Jul 27 22:15:17 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 27 Jul 2020 19:15:17 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <0fbcbbbf-4898-2f8a-3030-0cdd19b2a601@redhat.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <0fbcbbbf-4898-2f8a-3030-0cdd19b2a601@redhat.com> Message-ID: Hi Alexey, A few comments on Webrev.01 below. 1 ------------- Apparently, JDK-8 has 2 SSLSocketTemplate.java files: 'sun/security/ssl/templates/SSLSocketTemplate.java' and 'javax/net/ssl/templates/SSLSocketTemplate.java'. Looks like the javax/net/ssl one was introduced in the context of backporting 8163237 to 8u. On the other had, there could be tests relocated from 'test/sun/security/ssl/javax/net/ssl' to 'test/javax/net/ssl' that were using SSLSocketTemplate.java switching between a JDK-8 and JDK-11 version of it. However, even if this potential case happened, it shouldn't be a problem as you observed no regressions. So my question is: can we remove 'sun/security/ssl/templates/SSLSocketTemplate.java'? 2 ------------- Shouldn't we relocate 'test/sun/security/ssl/README' to 'test/javax/net/ssl/README' (which is part of 8032473)? 3 ------------- The alignment under 'test/sun/net/www/httpstest' does not look good to me. 8032473: test/sun/net/www/protocol/https/AbstractCallback.java (new) test/sun/net/www/protocol/https/ChunkedOutputStream.java (new) test/sun/net/www/protocol/https/ClosedChannelList.java (new) test/sun/net/www/protocol/https/HttpCallback.java (new) test/sun/net/www/protocol/https/HttpTransaction.java (new) test/sun/net/www/protocol/https/TestHttpsServer.java (new) Step 9 - Webrev.01: test/sun/net/www/https/ChunkedOutputStream/Test.java (new) test/sun/net/www/httpstest/AbstractCallback.java (new) test/sun/net/www/httpstest/ClosedChannelList.java (new) test/sun/net/www/httpstest/HttpCallback.java (new) test/sun/net/www/httpstest/HttpTransaction.java (new) test/sun/net/www/httpstest/TestHttpsServer.java (new) We have differences in the directory ('protocol' vs 'httpstest') and in one of the file names ('ChunkedOutputStream.java' vs 'ChunkedOutputStream/Test.java'). Thanks, Martin.- From gnu.andrew at redhat.com Tue Jul 28 02:33:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Jul 2020 03:33:15 +0100 Subject: OpenJDK 8u265 Released Message-ID: <20200728023315.GA878426@stopbrexit> We are pleased to announce the release of OpenJDK 8u265, which fixes a regression found in the recent 8u262 release. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u265-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u265-ga.tar.xz.sig This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 53f5eb7893ef35dcc16ae5b8056613c33a2e8dcfd14281941523fed7a5c397b8 openjdk8u265-ga.tar.xz b065b2f0d5995749ff96ec2477abaacce45c950d632e336ce4f91e00b9d9bb7c openjdk8u265-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u265-ga.sha256 New in release OpenJDK 8u265 (2020-07-27): =========================================== Live versions of these release notes can be found at: * https://bitly.com/openjdk8u265 * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u265.txt * Bug fixes - JDK-8249677: Regression in 8u after JDK-8237117: Better ForkJoinPool behavior - JDK-8250546: Expect changed behaviour reported in JDK-8249846 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Jul 28 05:12:58 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Jul 2020 06:12:58 +0100 Subject: [8u] RFR 8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent In-Reply-To: References: Message-ID: <20200728051258.GB878426@stopbrexit> On 14:32 Mon 27 Jul , Zhengyu Gu wrote: > I would like to backport this to 8u for parity with Oracle 8u281. > > The original patch does not apply cleanly. > > 1) classFileParser.cpp > 8u does not have the changes from JDK-8140485, so relaxed class file > check is performed from ClassFileParser::parseClassFile, instead of > ClassFileParser's constructor. > The conflicts are easy to resolve. > > 2) verifier.hpp > Copyright line already updated in 8u > > 3) FormatCheckingTest.java > Changed @library from /test/lib -> /testlibrary > Changed imports to reflect test library changes > Removed @modules > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8148854 > Original patch: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/92e705c1e6e6 > > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8148854-8u/webrev.00/ > > Test: > hotspot/runtime > > Thanks, > > -Zhengyu > Changes look good. The same ext_class_loader* to platform_class_loader* conversion is visible when comparing the annotation_index method in the same file between 8u and 9u, so seems correct. Funny that this bug says "8-wnf", yet there is a backport listed for 8u281 :/ Is it worth waiting until 8u272 branches before committing this? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Jul 28 05:40:43 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Jul 2020 06:40:43 +0100 Subject: [8u] RFR(S): 8247817: Some incompatible APIs in jdk/test/lib In-Reply-To: <1595828653959.18371@amazon.com> References: <8789C04F-FB8C-4041-828D-143C9A02CC6A@amazon.com> <22c7e7db-229f-1631-39c7-60ee4ad958a6@amazon.com> <0EEB7BC0-F348-4182-9DCB-4303DFF671D5@amazon.com> <1595828653959.18371@amazon.com> Message-ID: <20200728054043.GC878426@stopbrexit> On 05:44 Mon 27 Jul , Liu, Xin wrote: > hi, Paul and Severin, > > I redo this per your feedbacks on JBS. here is the new revision. > Could you take a look? > > Webrev: https://cr.openjdk.java.net/~xliu/8247817/01/webrev/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8247817 > > changes since last revision. > 1. I remove SkippedException from jdk. I move it to my vmTestBase patchset. > 2. I detect a merging conflicts in Platform.java. the method sharedLibraryPathVariableName() has been added in JDK-8238225 > I drop mine. > > thanks, > --lx > The real problem here seems to be that none of these files should actually exist, because they duplicate existing versions in 8u: JFR: test/lib/jdk/test/lib/util/JarUtils.java 8u: test/lib/testlibrary/jdk/testlibrary/JarUtils.java JFR: test/lib/jdk/test/lib/Utils.java 8u: test/lib/testlibrary/jdk/testlibrary/Utils.java JFR: jdk/test/lib/sun/hotspot/WhiteBox.java 8u: hotspot/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java Comparing these shows that the 8u version already avoids transferTo in favour of routines in Utils. So the correct solution here is to delete these duplicates and then fix any tests referring to the wrong version, as should have been done for the initial backport. We shouldn't be maintaining two copies of the test library. It's not clear to me what the TEST_ROOT addition in the patch is for, as I don't see TEST_ROOT referenced anywhere in current 8u jdk/test Java code. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Jul 28 05:54:30 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 28 Jul 2020 06:54:30 +0100 Subject: [8u] RFR 8242556: Cannot load RSASSA-PSS public key with non-null params from byte array In-Reply-To: References: Message-ID: <20200728055430.GD878426@stopbrexit> On 10:40 Mon 27 Jul , Zhengyu Gu wrote: > I would like to backport this to 8u for parity with Oracle 8u271. > > The original patch does not apply cleanly. The only conflicts are copyright > lines of PSSParametersTest.java and TestPSSKeySupport.java, where they are > already up-to-date. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8242556 > Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9eea66de64df > > 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242556-8u/webrev.00/ > > Test: > jdk_security > > > Thanks, > > -Zhengyu > Looks fine. Seems both files were added recently by JDK-8230978, hence updated copyright headers. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Tue Jul 28 10:30:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Jul 2020 12:30:06 +0200 Subject: [8u] RFR 8163251: Hard coded loop limit prevents reading of smart card data greater than 8k Message-ID: <62d41a54-e2b6-4e43-9da5-73ab26b0f8ef@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8163251 https://hg.openjdk.java.net/jdk/jdk/rev/220415dfb4ac 8u has the file in another place. The patch applies cleanly with a little conflict in the copyright line, which I resolved by hand. 8u webrev: https://cr.openjdk.java.net/~shade/8163251/webrev.8u.01/ Testing: 8u builds; jdk_other (includes javax/smartcardio) -- Thanks, -Aleksey From shade at redhat.com Tue Jul 28 10:38:57 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Jul 2020 12:38:57 +0200 Subject: [8u] RFR (S) 8046274: Removing dependency on jakarta-regexp In-Reply-To: <70bee23c67975ae7f4a5c61ada6629b234ab9eaa.camel@redhat.com> References: <01a43b4b-c5a1-dc6e-5d17-d0f5fcd2a0ec@redhat.com> <70bee23c67975ae7f4a5c61ada6629b234ab9eaa.camel@redhat.com> Message-ID: On 7/3/20 10:16 AM, Severin Gehwolf wrote: > On Fri, 2020-03-27 at 12:23 +0100, Aleksey Shipilev wrote: >> Original change: >> https://bugs.openjdk.java.net/browse/JDK-8046274 >> https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/bfc9ec1a816b >> >> Patch does not apply cleanly to 8u, because paths are different. I have removed >> src/com/sun/org/apache/regexp/ by hand. Reapplied THIRD_PARTY_README by hand. InstructionFinder.java >> change applies after reshuffling. >> >> 8u webrev: >> https://cr.openjdk.java.net/~shade/8046274/webrev.8u.01/ >> >> Testing: java/xml tests, tier1 > > This looks good to me. Thanks, I added the tags. > Please be sure to push THIRD_PARTY_README changes to all 8 repositories > once you've got approval. Okay. It would deviate from the jdk9 changeset, but I think it was jdk9 (JDK-8169925) that merged the THIRD_PARTY_README-s together. So it does make some sense to update all of them in 8u... The final push would be like this: https://cr.openjdk.java.net/~shade/8046274/webrev.8u.02/ -- Thanks, -Aleksey From alexey at azul.com Tue Jul 28 10:39:07 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 28 Jul 2020 10:39:07 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <0fbcbbbf-4898-2f8a-3030-0cdd19b2a601@redhat.com> Message-ID: <6310B074-145E-4AEB-A880-0A7EFA98350C@azul.com> Hello Martin, > On 28 Jul 2020, at 01:15, Martin Balao wrote: > > Hi Alexey, > > A few comments on Webrev.01 below. > > 1 > ------------- > > Apparently, JDK-8 has 2 SSLSocketTemplate.java files: > 'sun/security/ssl/templates/SSLSocketTemplate.java' and > 'javax/net/ssl/templates/SSLSocketTemplate.java'. Looks like the > javax/net/ssl one was introduced in the context of backporting 8163237 > to 8u. On the other had, there could be tests relocated from > 'test/sun/security/ssl/javax/net/ssl' to 'test/javax/net/ssl' that were > using SSLSocketTemplate.java switching between a JDK-8 and JDK-11 > version of it. However, even if this potential case happened, it > shouldn't be a problem as you observed no regressions. So my question > is: can we remove 'sun/security/ssl/templates/SSLSocketTemplate.java'? You are right. sun/security/ssl/templates/SSLSocketTemplate.java is not required any more and removed in Step 10 No changes in Step 9 required. > > 2 > ------------- > Shouldn't we relocate 'test/sun/security/ssl/README' to > 'test/javax/net/ssl/README' (which is part of 8032473)? > Yes, you are right. Should be moved to 'test/javax/net/ssl/README? > 3 > ------------- > The alignment under 'test/sun/net/www/httpstest' does not look good to me. > > 8032473: > > test/sun/net/www/protocol/https/AbstractCallback.java (new) > test/sun/net/www/protocol/https/ChunkedOutputStream.java (new) > test/sun/net/www/protocol/https/ClosedChannelList.java (new) > test/sun/net/www/protocol/https/HttpCallback.java (new) > test/sun/net/www/protocol/https/HttpTransaction.java (new) > test/sun/net/www/protocol/https/TestHttpsServer.java (new) > > Step 9 - Webrev.01: > > test/sun/net/www/https/ChunkedOutputStream/Test.java (new) > test/sun/net/www/httpstest/AbstractCallback.java (new) > test/sun/net/www/httpstest/ClosedChannelList.java (new) > test/sun/net/www/httpstest/HttpCallback.java (new) > test/sun/net/www/httpstest/HttpTransaction.java (new) > test/sun/net/www/httpstest/TestHttpsServer.java (new) > > We have differences in the directory ('protocol' vs 'httpstest') and in > one of the file names ('ChunkedOutputStream.java' vs > 'ChunkedOutputStream/Test.java'). Yes, you are right. These tests should be moved to sun/net/www/protocol/https Also, I've renamed ChunkedOutputStream/Test.java to ChunkedOutputStream.java as you suggested New version is available at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v2/ Regards Alexey > > Thanks, > Martin.- > From sgehwolf at redhat.com Tue Jul 28 13:02:46 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 28 Jul 2020 15:02:46 +0200 Subject: [8u] RFR (S) 8046274: Removing dependency on jakarta-regexp In-Reply-To: References: <01a43b4b-c5a1-dc6e-5d17-d0f5fcd2a0ec@redhat.com> <70bee23c67975ae7f4a5c61ada6629b234ab9eaa.camel@redhat.com> Message-ID: <67ef3e32b8a92c8684b3511b526e81dc39cd3afa.camel@redhat.com> On Tue, 2020-07-28 at 12:38 +0200, Aleksey Shipilev wrote: > On 7/3/20 10:16 AM, Severin Gehwolf wrote: > > On Fri, 2020-03-27 at 12:23 +0100, Aleksey Shipilev wrote: > > > Original change: > > > https://bugs.openjdk.java.net/browse/JDK-8046274 > > > https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/bfc9ec1a816b > > > > > > Patch does not apply cleanly to 8u, because paths are different. I have removed > > > src/com/sun/org/apache/regexp/ by hand. Reapplied THIRD_PARTY_README by hand. InstructionFinder.java > > > change applies after reshuffling. > > > > > > 8u webrev: > > > https://cr.openjdk.java.net/~shade/8046274/webrev.8u.01/ > > > > > > Testing: java/xml tests, tier1 > > > > This looks good to me. > > Thanks, I added the tags. > > > Please be sure to push THIRD_PARTY_README changes to all 8 repositories > > once you've got approval. > > Okay. It would deviate from the jdk9 changeset, but I think it was jdk9 (JDK-8169925) that merged > the THIRD_PARTY_README-s together. So it does make some sense to update all of them in 8u... That's how we need to handle THIRD_PARTY_README changes. > The final push would be like this: > https://cr.openjdk.java.net/~shade/8046274/webrev.8u.02/ Yes. Thanks, Severin From zgu at redhat.com Tue Jul 28 14:15:07 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Jul 2020 10:15:07 -0400 Subject: [8u] RFR 8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent In-Reply-To: <20200728051258.GB878426@stopbrexit> References: <20200728051258.GB878426@stopbrexit> Message-ID: Hi Andrew, Thanks for reviewing. > > Changes look good. The same ext_class_loader* to > platform_class_loader* conversion is visible when comparing the > annotation_index method in the same file between 8u and 9u, so seems > correct. > > Funny that this bug says "8-wnf", yet there is a backport listed for 8u281 :/ > > Is it worth waiting until 8u272 branches before committing this? > I have no opinion on this, I can wait till 8u272. Thanks, -Zhengyu > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From zgu at redhat.com Tue Jul 28 14:16:50 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Jul 2020 10:16:50 -0400 Subject: [8u] RFR 8242556: Cannot load RSASSA-PSS public key with non-null params from byte array In-Reply-To: <20200728055430.GD878426@stopbrexit> References: <20200728055430.GD878426@stopbrexit> Message-ID: Thanks, Andrew. -Zhengyu On 7/28/20 1:54 AM, Andrew Hughes wrote: > On 10:40 Mon 27 Jul , Zhengyu Gu wrote: >> I would like to backport this to 8u for parity with Oracle 8u271. >> >> The original patch does not apply cleanly. The only conflicts are copyright >> lines of PSSParametersTest.java and TestPSSKeySupport.java, where they are >> already up-to-date. >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8242556 >> Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9eea66de64df >> >> 8u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8242556-8u/webrev.00/ >> >> Test: >> jdk_security >> >> >> Thanks, >> >> -Zhengyu >> > > Looks fine. Seems both files were added recently by JDK-8230978, hence > updated copyright headers. > > Thanks, > From zgu at redhat.com Tue Jul 28 14:32:01 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Jul 2020 10:32:01 -0400 Subject: [8u] RFR 8163251: Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: <62d41a54-e2b6-4e43-9da5-73ab26b0f8ef@redhat.com> References: <62d41a54-e2b6-4e43-9da5-73ab26b0f8ef@redhat.com> Message-ID: Looks good to me. Thanks, -Zhengyu On 7/28/20 6:30 AM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8163251 > https://hg.openjdk.java.net/jdk/jdk/rev/220415dfb4ac > > 8u has the file in another place. The patch applies cleanly with a little conflict in the copyright > line, which I resolved by hand. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8163251/webrev.8u.01/ > > Testing: 8u builds; jdk_other (includes javax/smartcardio) > From jaroslav.bachorik at datadoghq.com Tue Jul 28 15:44:35 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 28 Jul 2020 17:44:35 +0200 Subject: [8u] RFR 8249158: THREAD_START and THREAD_END event posted in primordial phase Message-ID: This patch is backing out the backport of JDK-8233197. The backport changed slightly the init order and thus broke the expected behavior of the JVMTI VMStart routine (more information in JIRA ticket). Since the original fix (JDK-8233197) is fixing an issue which can not be hit in JDK 8 due to different implementation of the VM init phases it makes sense to back out the backport and restore the original JVMTI behavior. JIRA : https://bugs.openjdk.java.net/browse/JDK-8249158 CR : http://cr.openjdk.java.net/~jbachorik/8249158 The backout is fairly straightforward. When applied all jdk/jfr and hotspot/runtime tests are passing. Cheers, -JB- From alexey at azul.com Tue Jul 28 16:29:53 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 28 Jul 2020 16:29:53 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <6310B074-145E-4AEB-A880-0A7EFA98350C@azul.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <0fbcbbbf-4898-2f8a-3030-0cdd19b2a601@redhat.com> <6310B074-145E-4AEB-A880-0A7EFA98350C@azul.com> Message-ID: Git diff for the JDK-8245477 webrev.v2 is available at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v2/jdk.git.diff Original jdk.patch in the webrev.v2 does not move binary files > On 28 Jul 2020, at 13:39, Alexey Bakhtin wrote: > > Hello Martin, > >> On 28 Jul 2020, at 01:15, Martin Balao wrote: >> >> Hi Alexey, >> >> A few comments on Webrev.01 below. >> >> 1 >> ------------- >> >> Apparently, JDK-8 has 2 SSLSocketTemplate.java files: >> 'sun/security/ssl/templates/SSLSocketTemplate.java' and >> 'javax/net/ssl/templates/SSLSocketTemplate.java'. Looks like the >> javax/net/ssl one was introduced in the context of backporting 8163237 >> to 8u. On the other had, there could be tests relocated from >> 'test/sun/security/ssl/javax/net/ssl' to 'test/javax/net/ssl' that were >> using SSLSocketTemplate.java switching between a JDK-8 and JDK-11 >> version of it. However, even if this potential case happened, it >> shouldn't be a problem as you observed no regressions. So my question >> is: can we remove 'sun/security/ssl/templates/SSLSocketTemplate.java'? > > You are right. sun/security/ssl/templates/SSLSocketTemplate.java > is not required any more and removed in Step 10 > No changes in Step 9 required. >> >> 2 >> ------------- >> Shouldn't we relocate 'test/sun/security/ssl/README' to >> 'test/javax/net/ssl/README' (which is part of 8032473)? >> > > Yes, you are right. > Should be moved to 'test/javax/net/ssl/README? > >> 3 >> ------------- >> The alignment under 'test/sun/net/www/httpstest' does not look good to me. >> >> 8032473: >> >> test/sun/net/www/protocol/https/AbstractCallback.java (new) >> test/sun/net/www/protocol/https/ChunkedOutputStream.java (new) >> test/sun/net/www/protocol/https/ClosedChannelList.java (new) >> test/sun/net/www/protocol/https/HttpCallback.java (new) >> test/sun/net/www/protocol/https/HttpTransaction.java (new) >> test/sun/net/www/protocol/https/TestHttpsServer.java (new) >> >> Step 9 - Webrev.01: >> >> test/sun/net/www/https/ChunkedOutputStream/Test.java (new) >> test/sun/net/www/httpstest/AbstractCallback.java (new) >> test/sun/net/www/httpstest/ClosedChannelList.java (new) >> test/sun/net/www/httpstest/HttpCallback.java (new) >> test/sun/net/www/httpstest/HttpTransaction.java (new) >> test/sun/net/www/httpstest/TestHttpsServer.java (new) >> >> We have differences in the directory ('protocol' vs 'httpstest') and in >> one of the file names ('ChunkedOutputStream.java' vs >> 'ChunkedOutputStream/Test.java'). > > Yes, you are right. These tests should be moved to sun/net/www/protocol/https > Also, I've renamed ChunkedOutputStream/Test.java to ChunkedOutputStream.java as you suggested > > New version is available at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v2/ > > Regards > Alexey >> >> Thanks, >> Martin.- From rkennke at redhat.com Tue Jul 28 19:04:46 2020 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Jul 2020 21:04:46 +0200 Subject: RFR(8u): 8171974: Fix for R10 Register clobbering with usage of ExternalAddress Message-ID: <2df4bba5737a65fbe6cf1b2b4563292a3bc6eda4.camel@redhat.com> Can I please get a review for the following backport: http://cr.openjdk.java.net/~rkennke/JDK-8171974-jdk8u/webrev.00/ This is a backport of: https://bugs.openjdk.java.net/browse/JDK-8171974 The patch is identical with the original one: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8e139e328150 Except for the parts that are not yet present in 8u (all of macroAssembler_x86_sha.cpp and some of stubGenerator_x86_64.cpp). Testing: tier1 and tier2 without regressions Is this ok to go into jdk8u? Thanks, Roman From mbalao at redhat.com Tue Jul 28 19:41:54 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 28 Jul 2020 16:41:54 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> <0fbcbbbf-4898-2f8a-3030-0cdd19b2a601@redhat.com> <6310B074-145E-4AEB-A880-0A7EFA98350C@azul.com> Message-ID: Hi Alexey, On 7/28/20 1:29 PM, Alexey Bakhtin wrote: > Git diff for the JDK-8245477 webrev.v2 is available at : > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v2/jdk.git.diff > Original jdk.patch in the webrev.v2 does not move binary files > Thanks for providing that! My thinking was that generating a Webrev after committing the change locally was, in all cases, generating the proper git patch with all the binaries relocated. Then I realized that when you specify a revision (-r argument to webrev.ksh), it does not: only when you generate the webrev against the remote repository (and changes were committed). There is not much risk of messing this up without any notice because most of the test cases will fail. So I'll take your jdk.git.diff as valid here, even if the generated jdk.patch on your Webrev is not ready to be applied and I did not review jdk.git.diff. Note: diffing jdk.patch and jdk.git.diff brings pure noise. Kind regards, Martin.- From mbalao at redhat.com Tue Jul 28 21:24:18 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 28 Jul 2020 18:24:18 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> Message-ID: Hi Alexey, On 7/27/20 2:47 AM, Alexey Bakhtin wrote: >> 3) Should we expect all tests passing in Step 9? If not, why? I read >> 'no regression' in your first comment but that does not say whether >> they are all passing or not. > > I can not say all test passed, because of three test fails on the original TLSv1.2 implementation > and original test file location : > - javax/net/ssl/ciphersuites/DisabledAlgorithms.java > - sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java > - sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java > These test still fails after relocation with original TLSv1.2 implementation. > This is a reason I wrote ?no regression? instead of all test passed. > I've found some regressions after Webrev.02 on sun/security/ssl tests category. A couple of examples: CustomizedDefaultProtocols.java: .................................... * Passing in JDK-8 (located in sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java) and failing in Webrev.02 (located in sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java). Apparently, TLSv13 is not among the expected protocols in the test assertions. LengthCheckTest.java .................................... * Passing in JDK-8 (located in sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java) and failing in Webrev.02 (located in sun/security/ssl/ClientHandshaker/LengthCheckTest.java). Apparently, after Step 1 ProtocolVersion.valueOf changed the signature to receive 'byte' arguments instead of 'int'; and that's preventing the test from compiling. .................................... There are around 15 more in this category. I've not tested other categories. Am I doing something wrong? Is the expectation of having no regressions still correct for Step 9? I'm not very surprised by these results and it's not my expectation for tests to pass until Step 11 (where they are updated to work with the new TLS engine). In case there is one still failing after Step 11, then we can analyze it. What do you think? Thanks, Martin.- From shade at redhat.com Wed Jul 29 07:57:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 29 Jul 2020 09:57:03 +0200 Subject: [8u] RFR 8163251: Hard coded loop limit prevents reading of smart card data greater than 8k In-Reply-To: References: <62d41a54-e2b6-4e43-9da5-73ab26b0f8ef@redhat.com> Message-ID: <40ebfdfe-ff51-66b3-9f14-69827324d42d@redhat.com> On 7/28/20 4:32 PM, Zhengyu Gu wrote: > Looks good to me. Thank you, added the tags. -- -Aleksey From adinn at redhat.com Wed Jul 29 09:02:56 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 29 Jul 2020 10:02:56 +0100 Subject: [8u] RFR 8249158: THREAD_START and THREAD_END event posted in primordial phase In-Reply-To: References: Message-ID: Hi Jaroslav, On 28/07/2020 16:44, Jaroslav Bachor?k wrote: > This patch is backing out the backport of JDK-8233197. The backport > changed slightly the init order and thus broke the expected behavior > of the JVMTI VMStart routine (more information in JIRA ticket). > > Since the original fix (JDK-8233197) is fixing an issue which can not > be hit in JDK 8 due to different implementation of the VM init phases > it makes sense to back out the backport and restore the original JVMTI > behavior. > > JIRA : https://bugs.openjdk.java.net/browse/JDK-8249158 > CR : http://cr.openjdk.java.net/~jbachorik/8249158 > > The backout is fairly straightforward. When applied all jdk/jfr and > hotspot/runtime tests are passing. The backout looks correct to me except for one (non-functional) detail. At thread.cpp:3545 you now appear to have two copies of the comment explaining the significance of bug 4211085. regards, Andrew Dinn ----------- From aph at redhat.com Wed Jul 29 09:51:25 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Jul 2020 10:51:25 +0100 Subject: RFR(8u): 8171974: Fix for R10 Register clobbering with usage of ExternalAddress In-Reply-To: <2df4bba5737a65fbe6cf1b2b4563292a3bc6eda4.camel@redhat.com> References: <2df4bba5737a65fbe6cf1b2b4563292a3bc6eda4.camel@redhat.com> Message-ID: <592984d6-937b-eaa6-695e-b4df90fa64e4@redhat.com> On 7/28/20 8:04 PM, Roman Kennke wrote: > The patch is identical with the original one: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8e139e328150 > > Except for the parts that are not yet present in 8u (all of > macroAssembler_x86_sha.cpp and some of stubGenerator_x86_64.cpp). > > Testing: tier1 and tier2 without regressions > > Is this ok to go into jdk8u? Ouch. Yes, please. -- 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 alexey at azul.com Wed Jul 29 15:12:20 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 29 Jul 2020 15:12:20 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> Message-ID: Hello Martin, As I mentioned before, I expect no regression with ORIGINAL TLSv1.2 implementation after Step 9 . On this Step, I do not expect all test pass on the new TLSv1.3 implementation because of difference in the Cipher Suites, ordering, protocols and so on. So, on this Step should not be any regression if run with original TLSv1.2 implementation I just found one test issue caused by latest test relocation to the sun/net/www/protocol/https directory. Test sun/net/www/protocol/https/HttpsURLConnection/B6216082.java is fixed (the changes in this test only). Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v3/ GIT diff : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v3/jdk.git.diff On the Step 10 I removed all tests failed with NEW TLSv1.3 implementation. So remaining test passed with ORIGINAL TLSv1.2 and NEW TLSv1.3 implementations. Note 1: NEW TLSv1.3 implementations passes with new keystore files only - javax/net/ssl/etc/keystore and javax/net/ssl/etc/trustore Note 2: sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java fails because of javax/net/ssl/templates/SSLSocketTemplate.java removed on this Step. This test passed after step 11 because of new SSLSocketTemplate.java is added. On the Step 11 tests are updated from JDK 11.07. After this step all test should pass with the NEW TLSv1.3 implementation Regards Alexey > On 29 Jul 2020, at 00:24, Martin Balao wrote: > > Hi Alexey, > > On 7/27/20 2:47 AM, Alexey Bakhtin wrote: >>> 3) Should we expect all tests passing in Step 9? If not, why? I read >>> 'no regression' in your first comment but that does not say whether >>> they are all passing or not. >> >> I can not say all test passed, because of three test fails on the original TLSv1.2 implementation >> and original test file location : >> - javax/net/ssl/ciphersuites/DisabledAlgorithms.java >> - sun/security/ssl/com/sun/net/ssl/internal/ssl/X509KeyManager/PreferredKey.java >> - sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java >> These test still fails after relocation with original TLSv1.2 implementation. >> This is a reason I wrote ?no regression? instead of all test passed. >> > > I've found some regressions after Webrev.02 on sun/security/ssl tests > category. A couple of examples: > > CustomizedDefaultProtocols.java: > .................................... > > * Passing in JDK-8 (located in > sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java) > and failing in Webrev.02 (located in > sun/security/ssl/SSLContextImpl/CustomizedDefaultProtocols.java). > Apparently, TLSv13 is not among the expected protocols in the test > assertions. > > LengthCheckTest.java > .................................... > > * Passing in JDK-8 (located in > sun/security/ssl/com/sun/net/ssl/internal/ssl/ClientHandshaker/LengthCheckTest.java) > and failing in Webrev.02 (located in > sun/security/ssl/ClientHandshaker/LengthCheckTest.java). Apparently, > after Step 1 ProtocolVersion.valueOf changed the signature to receive > 'byte' arguments instead of 'int'; and that's preventing the test from > compiling. > > .................................... > > There are around 15 more in this category. I've not tested other categories. > > Am I doing something wrong? Is the expectation of having no regressions > still correct for Step 9? I'm not very surprised by these results and > it's not my expectation for tests to pass until Step 11 (where they are > updated to work with the new TLS engine). In case there is one still > failing after Step 11, then we can analyze it. What do you think? > > Thanks, > Martin.- > From mbalao at redhat.com Wed Jul 29 17:16:11 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 29 Jul 2020 14:16:11 -0300 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location In-Reply-To: References: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> <821417F7-1B0B-4991-B41D-3A970F29D945@azul.com> <6653A5C0-C981-474B-9616-3A56B323E2DD@azul.com> Message-ID: <8a78da1e-d5b6-6c6a-7e69-7c26adc2d9b4@redhat.com> On 7/29/20 12:12 PM, Alexey Bakhtin wrote: > Updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v3/ Hi, The goal of Step 9 - 8245477 was to align JSSE regression test hierarchy to JDK-11 (changes introduced to main line by 8032473 [1]). This alignment will make easier to understand which tests were modified by the new SunJSSE engine, and do file-replacement in Steps 10 (removal of the existing file) and 11 (addition of the new version). In addition to file-relocation, minor path-related adjustments were made in Step 9 (i.e.: paths to keystores used by some tests). Path changes in tests (keystore locations): * Ok. Template library relocation (sun/security/ssl/templates -> javax/net/ssl/templates) and adjustment of tests that use it: * Ok. No other change in test files: * Ok. Relocations (review against 8032473) * Ok. Test regressions * It's not my expectation to verify no test regressions on this Step. Tests that do not enforce TLSv1.2 or below will probably fail if TLSv1.3 is negotiated. Tests that depend on internal APIs will likely fail too. The following comments and their replies are part of this review: [2], [3], [4] and [5]. With that said, Step 9 - 8245477 Webrev.03 looks good to me. Please hold the push until the whole series is review-approved and maintainer-approved. When committing this patch, please include a reference to 8032473 in the message. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8032473 [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012273.html [3] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012280.html [4] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012283.html [5] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012299.html From mbalao at redhat.com Wed Jul 29 21:12:29 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 29 Jul 2020 18:12:29 -0300 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests In-Reply-To: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> References: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> Message-ID: On 5/24/20 2:21 PM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u Hi Alexey, Thanks for proposing a patch for Step 10 - 8245653. A few comments below. Files that we might want to delete because they were modified in JDK-11 (11.0.7): * test/sun/security/ssl * CertPathRestrictions * JSSEServer.java * TLSRestrictions.java * ClientHandshaker * RSAExport.java * DHKeyExchange * LegacyDHEKeyExchange.java * GenSSLConfigs * main.java * HandshakeHash * MyProvider.java * HandshakeOutStream * NullCerts.java * InputRecord * ClientHelloRead.java * SSLSocketTimeoutNulls.java * ProtocolVersion * HttpsProtocols.java * SSLContextImpl * CustomizedCipherSuites.java * SSLEngineImpl * DelegatedTaskWrongException.java * SSLSocketImpl * CheckMethods.java * NonAutoClose.java * SSLSocketImplThrowsWrongExceptions.java * SetClientMode.java * ServerHandshaker * AnonCipherWithWantClientAuth.java * GetPeerHostClient.java * GetPeerHostServer.java * SocketCreation * SocketCreation.java * X509TrustManagerImpl * Symantec * Distrust.java * CheckNullEntity.java * rsa * SignatureOffsets.java * SignedObjectChain.java * test/com/sun/net/ssl * SSLSecurity * ProviderTest.java * TruncateArray.java * test/javax/net/ssl * ALPN * MyX509ExtendedKeyManager.java * SSLServerSocketAlpnTest.java * SSLSocketAlpnTest.java * SSLParameters * UseCipherSuitesOrder.java * SSLSession * CheckMyTrustedKeystore.java * ServerName * SSLEngineExplorer.java * SSLSocketExplorer.java * TLSv11 * EmptyCertificateAuthorities.java * GenericBlockCipher.java * GenericStreamCipher.java * TLSv12 * ShortRSAKeyGCM.java * SignatureAlgorithms.java * ciphersuites * DisabledAlgorithms.java * etc * keystore * truststore * sanity * pluggability * CheckSSLContextExport.java * templates * SSLExplorer.java * GetInstance.java * test/sun/net/www/protocol/https * HttpsClient * ProxyAuthTest.java * ServerIdentityTest.java * HttpsURLConnection * B6216082.java * B6226610.java * CheckMethods.java * DNSIdentities.java * HttpsCreateSockTest.java * HttpsSocketFacTest.java * IPAddressDNSIdentities.java * IPAddressIPIdentities.java * IPIdentities.java * Identities.java * PostThruProxy.java * PostThruProxyWithAuth.java * RetryHttps.java * NewImpl * ComHTTPSConnection.java * ComHostnameVerified.java * ChunkedOutputStream.java If there is a reason not to delete them, please let me know. Files that should be removed because they do not exist in JDK-11, were relocated or renamed: * test/sun/security/ssl * SSLContextImpl * DefautlCacheSize.java * Relocated to SSLSessionContextImpl (there might be file changes as well) SSL-related tests that are in JDK-8 but not in JDK-11: * test/sun/net/www/protocol/https * HttpsClient * OriginServer.java * test/sun/security/ssl * SSLEngineImpl * CloseInboundException.java * SessionIdCollisionTest.java Are we sure that we want to keep them? I'd like to have a quick look and make sure that we want to keep them. Regards, Martin.- From sgehwolf at redhat.com Thu Jul 30 09:17:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2020 11:17:18 +0200 Subject: [8u] RFR: 8203357: Container Metrics In-Reply-To: References: Message-ID: <29d81a510f5ffb7bd7df5f3937f722ad3f383560.camel@redhat.com> Hi Andrew, Thanks for the review! On Tue, 2020-07-21 at 20:38 +0100, Andrew Hughes wrote: > > On 16/07/2020 16:48, Severin Gehwolf wrote: > > Hi, > > > > Please review this OpenJDK 8u backport of the Java Metrics classes > > which are in later JDKs. It is a pre-requisite for JDK-8226575 an > > Oracle JDK parity issue. Implementations of the interface are provided > > for Linux only and, thus, are compiled for Linux only. This backport > > differs from the original JDK 11 change in the following way: > > > > * MetricsTester: Arrays.compare() => Arrays.equals(). Arrays.compare() > > is JDK 9+ only. > > * JDK-8223147: JFR Backport, brought in test library code included in > > the JDK 11 changeset. I've only done the needed adjustments to the > > relevant files in the test libary. Many were already present. > > * For this backport I've not included changes to the Launcher to > > support -XshowSettings:system (as in later JDKs). > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203357 > > webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/01/webrev/ > > > > Testing: Included docker tests on Linux x86_64. All pass. Though, they > > are in dire need of reliability improvements which I'll work on as a > > follow-up. > > > > Thanks, > > Severin > > [...] > > Comments: > * @author tags are removed from Container.java & Metrics.java. Why? I > can see a case for removing the "@since 11" but not the authorship. > * Removal of test code related to the module system seems fine. [...] > Comments: > * The Makefile changes look right and in line with those for Mac OS & AIX. > * The MetricsTester changes look correct. I can only imagine this > wasn't caught when the test was backported because JDK-8206456 was also > backported and so the length != 0 checks that introduced were never > triggered (as the metrics weren't actually there) It appears MetricsTester was never run, thus compiled. So I think this never worked in 8u. Now code uses it and the Arrays.compare() JDK 9+ feature needed to be reworked. [...] > So, action items are the missing @author tags and launcher support. New webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/jdk8/02/webrev/ Thoughts? Thanks, Severin From shade at redhat.com Thu Jul 30 10:36:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Jul 2020 12:36:52 +0200 Subject: [8u] RFR 8220165: Encryption using GCM results in RuntimeException: input length out of bound Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8220165 https://hg.openjdk.java.net/jdk/jdk/rev/4ff6c8365b69 This is a follow-up for JDK-8201633 backport. The changeset applies cleanly, but it puts the test in the wrong location, so it does not run. Moved the test by hand, and also had to fix the compilation bug that is 8u-specific: // Hash of encrypted results of AES/GCM for particular lengths. // - static final HashMap results = new HashMap<>() {{ + static final HashMap results = new HashMap() {{ 8u webrev: https://cr.openjdk.java.net/~shade/8220165/webrev.8u.01/ Testing: jdk_security; new test (fails before the patch, passes with it) -- Thanks, -Aleksey From akashche at redhat.com Thu Jul 30 12:57:02 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 30 Jul 2020 15:57:02 +0300 Subject: [8u] RFR: 8191678: [TESTBUG] Add keyword headful in java/awt and javax tests. In-Reply-To: <5633f25da8a6ec0ebe60acca3861e2501050ece5.camel@redhat.com> References: <5633f25da8a6ec0ebe60acca3861e2501050ece5.camel@redhat.com> Message-ID: On 7/21/20, Severin Gehwolf wrote: > Hi Alex, > > On Mon, 2020-07-06 at 11:53 +0100, Alex Kashchenko wrote: >> Hi, >> >> Please review the backport of JDK-8191678 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191678 >> >> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/50d61f4b5d1a >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8191678/webrev.00/ >> >> This change adds "headful" keyword to a number of client tests. Only a >> single test (FocusTransitionTest) from this patch is present in 8u - >> only changes to it are backported. > > Looks good to me. Thanks for the review! I've added fix request to the issue. -- -Alex From hohensee at amazon.com Thu Jul 30 15:19:47 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 30 Jul 2020 15:19:47 +0000 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call Message-ID: I took a look at the webrev. Doesn't seem that extensive (or risky) to me. Summary of changes: 69 lines changed: 40 ins; 0 del; 29 mod; 31448 unchg. If we don't do it, besides making future backports a bit more difficult, we'll have a (admittedly subtle) behavioral difference with Oracle, which in this case doesn?t seem justified to me. Thanks, Paul ?On 7/16/20, 6:19 AM, "jdk8u-dev on behalf of Zhengyu Gu" wrote: >> >> To my mind, that doesn't really change anything from a technical >> standpoint, but I'll leave the final say to Andrew Haley. > > Hmm. Once strdup() has failed, the whole program is basically dead in > the water, and throwing an OutOfMemoryError only delays the > inevitable. It might even be argued that a VM error is more > informative than an OutOfMemoryError, because then the problem doesn't > look like heap exhaustion. > > The fact that this is now a parity backport does swing me more to > saying "yes", but this is an extensive change and that makes me > nervous, so I'm leaning towards "no". I am aware that I'm swithering > here, but it's a genuine dilemma: neither course of action is great. > So, it it a rejection? Another drawback for not backporting parity bugs, is making future backports harder. Thanks, -Zhengyu From sgehwolf at redhat.com Thu Jul 30 15:32:39 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Jul 2020 17:32:39 +0200 Subject: [8u] RFR 8220165: Encryption using GCM results in RuntimeException: input length out of bound In-Reply-To: References: Message-ID: <8f97a87cf69bfc2d4d0ba195799ee2a874555a27.camel@redhat.com> On Thu, 2020-07-30 at 12:36 +0200, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8220165 > https://hg.openjdk.java.net/jdk/jdk/rev/4ff6c8365b69 > > This is a follow-up for JDK-8201633 backport. The changeset applies cleanly, but it puts the test in > the wrong location, so it does not run. Moved the test by hand, and also had to fix the compilation > bug that is 8u-specific: > > // Hash of encrypted results of AES/GCM for particular lengths. > // > - static final HashMap results = new HashMap<>() {{ > + static final HashMap results = new HashMap() {{ > > 8u webrev: > https://cr.openjdk.java.net/~shade/8220165/webrev.8u.01/ > > Testing: jdk_security; new test (fails before the patch, passes with it) Looks good. Thanks, Severin From jhuttana at redhat.com Thu Jul 30 16:06:04 2020 From: jhuttana at redhat.com (Jayashree Huttanagoudar) Date: Thu, 30 Jul 2020 21:36:04 +0530 Subject: OpenJDK 8u265 Released In-Reply-To: <20200728023315.GA878426@stopbrexit> References: <20200728023315.GA878426@stopbrexit> Message-ID: Hi All, On Tue, Jul 28, 2020 at 8:06 AM Andrew Hughes wrote: > We are pleased to announce the release of OpenJDK 8u265, which fixes a > regression found in the recent 8u262 release. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u265-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u265-ga.tar.xz.sig > > This is signed by our Red Hat OpenJDK key (openjdk at redhat.com): > > PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) > Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F > The binaries to go with this are here: https://adoptopenjdk.net/upstream.html?variant=openjdk8&jvmVariant=hotspot Thanks and Regards, Jaya > SHA256 checksums: > > 53f5eb7893ef35dcc16ae5b8056613c33a2e8dcfd14281941523fed7a5c397b8 > openjdk8u265-ga.tar.xz > b065b2f0d5995749ff96ec2477abaacce45c950d632e336ce4f91e00b9d9bb7c > openjdk8u265-ga.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u265-ga.sha256 > > New in release OpenJDK 8u265 (2020-07-27): > =========================================== > Live versions of these release notes can be found at: > * https://bitly.com/openjdk8u265 > * > https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u265.txt > > * Bug fixes > - JDK-8249677: Regression in 8u after JDK-8237117: Better ForkJoinPool > behavior > - JDK-8250546: Expect changed behaviour reported in JDK-8249846 > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > OpenJDK Package Owner > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From katya at azul.com Thu Jul 30 20:04:51 2020 From: katya at azul.com (Ekaterina Vergizova) Date: Thu, 30 Jul 2020 20:04:51 +0000 Subject: [8u] RFR: 8220657: JFR.dump does not work when filename is set Message-ID: <22410d48fbe44f3db5b82ee9fc47aa39@azul.com> Hello, I would like to backport JFR issue 8220657 to 8u. JBS: https://bugs.openjdk.java.net/browse/JDK-8220657 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/bd613b97c7c8 Webrev for 8u: https://cr.openjdk.java.net/~apetushkov/jfr_backports_katya/8220657/webrev.00/ The patch applies cleanly, but the added test TestJcmdDumpWithFileName.java requires some adjustments to pass under 8u: - the test tags are adjusted - ProcessHandle.current().pid() calls replaced by ProcessTools.getProcessId() - Path.of() calls replaced by their 8u analogue Paths.get() - unsupported syntax `try (stream)` replaced by standard try-with-resources Tested with tier1 and jdk.jfr tests on Linux and Windows, the added test TestJcmdDumpWithFileName.java failed before the fix and passes after. Thanks, Ekaterina From denghui.ddh at alibaba-inc.com Fri Jul 31 08:00:11 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 31 Jul 2020 16:00:11 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlI6IDgyNTA4NzU6IEluY29ycmVjdCBwYXJhbWV0ZXIgdHlwZSBmb3IgdXBkYXRl?= =?UTF-8?B?X251bWJlciBpbiBKREtfVmVyc2lvbjo6amRrX3VwZGF0ZQ==?= Message-ID: <0b7b6b85-175a-415c-a24b-14203ca76370.denghui.ddh@alibaba-inc.com> Hi, Could I have a review of this trivial fix that amend the type of update_number in JDK_Version::jdk_update? Summary: Now the update number is over 255, and if we make some flags obsolete later, it will cause a build failure Bug: https://bugs.openjdk.java.net/browse/JDK-8250875 Webrev: http://cr.openjdk.java.net/~ddong/8250875/webrev.00/ Thanks Denghui Dong From shade at redhat.com Fri Jul 31 08:13:26 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 31 Jul 2020 10:13:26 +0200 Subject: [8u] RFR 8220165: Encryption using GCM results in RuntimeException: input length out of bound In-Reply-To: <8f97a87cf69bfc2d4d0ba195799ee2a874555a27.camel@redhat.com> References: <8f97a87cf69bfc2d4d0ba195799ee2a874555a27.camel@redhat.com> Message-ID: <0e1a5a37-7c35-0330-0165-a7bbde05ade9@redhat.com> On 7/30/20 5:32 PM, Severin Gehwolf wrote: > On Thu, 2020-07-30 at 12:36 +0200, Aleksey Shipilev wrote: >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8220165 >> https://hg.openjdk.java.net/jdk/jdk/rev/4ff6c8365b69 >> >> This is a follow-up for JDK-8201633 backport. The changeset applies cleanly, but it puts the test in >> the wrong location, so it does not run. Moved the test by hand, and also had to fix the compilation >> bug that is 8u-specific: >> >> // Hash of encrypted results of AES/GCM for particular lengths. >> // >> - static final HashMap results = new HashMap<>() {{ >> + static final HashMap results = new HashMap() {{ >> >> 8u webrev: >> https://cr.openjdk.java.net/~shade/8220165/webrev.8u.01/ >> >> Testing: jdk_security; new test (fails before the patch, passes with it) Thanks, added tags. -- Thanks, -Aleksey From aph at redhat.com Fri Jul 31 08:29:05 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 Jul 2020 09:29:05 +0100 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: References: Message-ID: <16ac9ba2-e0d8-4e23-8157-67c1a787da64@redhat.com> On 7/30/20 4:19 PM, Hohensee, Paul wrote: > I took a look at the webrev. Doesn't seem that extensive (or risky) to me. > > Summary of changes: 69 lines changed: 40 ins; 0 del; 29 mod; 31448 unchg. > > If we don't do it, besides making future backports a bit more difficult, we'll have a (admittedly subtle) behavioral difference with Oracle, which in this case doesn?t seem justified to me. Mmm, OK, that's a way of looking at it. I guess that is enough to swing behind acceptance of this patch. It's good. -- 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 sgehwolf at redhat.com Fri Jul 31 08:35:12 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 31 Jul 2020 10:35:12 +0200 Subject: [8u] RFR: 8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update In-Reply-To: <0b7b6b85-175a-415c-a24b-14203ca76370.denghui.ddh@alibaba-inc.com> References: <0b7b6b85-175a-415c-a24b-14203ca76370.denghui.ddh@alibaba-inc.com> Message-ID: On Fri, 2020-07-31 at 16:00 +0800, Denghui Dong wrote: > Hi, > Could I have a review of this trivial fix that amend the type of update_number in JDK_Version::jdk_update? > Summary: > Now the update number is over 255, and if we make some flags obsolete later, > it will cause a build failure > > Bug: https://bugs.openjdk.java.net/browse/JDK-8250875 > Webrev: http://cr.openjdk.java.net/~ddong/8250875/webrev.00/ OK. Thanks, Severin From hohensee at amazon.com Fri Jul 31 15:35:23 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 31 Jul 2020 15:35:23 +0000 Subject: [8u] RFR 6424123: JVM crashes on failed 'strdup' call In-Reply-To: <16ac9ba2-e0d8-4e23-8157-67c1a787da64@redhat.com> References: <16ac9ba2-e0d8-4e23-8157-67c1a787da64@redhat.com> Message-ID: Thanks, Andrew. Zhengyu, you're good afaic too. Paul ?On 7/31/20, 1:29 AM, "Andrew Haley" wrote: On 7/30/20 4:19 PM, Hohensee, Paul wrote: > I took a look at the webrev. Doesn't seem that extensive (or risky) to me. > > Summary of changes: 69 lines changed: 40 ins; 0 del; 29 mod; 31448 unchg. > > If we don't do it, besides making future backports a bit more difficult, we'll have a (admittedly subtle) behavioral difference with Oracle, which in this case doesn?t seem justified to me. Mmm, OK, that's a way of looking at it. I guess that is enough to swing behind acceptance of this patch. It's good. -- 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