From felix.yang at huawei.com Thu Apr 1 01:52:37 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 1 Apr 2021 01:52:37 +0000 Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event based tracing for monitor inflation In-Reply-To: References: Message-ID: Hi, Thanks for reviewing this fix. I have tagged this for approval. Felix > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: Thursday, April 1, 2021 4:44 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event > based tracing for monitor inflation > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of "Yangfei > (Felix)" > Date: Wednesday, February 17, 2021 at 7:26 PM > To: "jdk8u-dev at openjdk.java.net" > Subject: RE: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event > based tracing for monitor inflation > > Hi, > > Anyone want to take a look at this? > As this adds back "cause" information for the monitor inflation event, it > should also improves basic functionality of 8u JFR event-based tracing. > > Thanks, > Felix > > > -----Original Message----- > > From: Yangfei (Felix) > > Sent: Tuesday, January 12, 2021 3:39 PM > > To: 'jdk8u-dev at openjdk.java.net' > > Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event > > based tracing for monitor inflation > > > > Any comments? > > > > > -----Original Message----- > > > From: Yangfei (Felix) > > > Sent: Friday, December 18, 2020 8:35 PM > > > To: jdk8u-dev at openjdk.java.net > > > Subject: RFR: 8258669: fastdebug jvm crashes when do event based > > > tracing for monitor inflation > > > > > > Hi, > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8258669 > > > Webrev: http://cr.openjdk.java.net/~fyang/8258669/webrev.00 > > > > > > By referencing jdk11u, I think the reason is that we are not > > > setting the "cause" in post_monitor_inflate_event for jdk8u. > > > Proposed patch adds back the missing code changes in: 8138562: > > > Event based tracing should cover monitor inflation. Also enabled > > > code in MonitorInflateCauseConstant::serialize. > > > Since this only adds some extra "cause" information for the > > > monitor inflation event, I think it should be low risk. > > > Performed full jtreg test based on the latest jdk8u-dev. OK? > > > > > > Thanks, > > > Felix From zhaixiang at loongson.cn Thu Apr 1 05:20:25 2021 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 1 Apr 2021 13:20:25 +0800 Subject: RFC: Change uint8 to uint16_t for _num_regs Message-ID: <5e16cb09-366f-a799-3e31-9915c2458b32@loongson.cn> Hi, When lrg.set_num_regs(305) for `MachProjNode::fat_proj`, the value `305` is out of range of `uint8`, then failed: ... 49 [S0-A7_H,F0-YOURARCH_FLAG], #305 EffDeg: 0 Def: N34 Cost: 1 Area: 0 Score:1e+35 Fat Lo Bound Trivial ^--- DEBUG: lrg.compute_mask_size: 305, lrg.num_regs: 49, chunk: 0 # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/chaitin.cpp:1388 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (.../hotspot/src/share/vm/opto/chaitin.cpp:1388), pid=21742, tid=0x000000ffe11931e0 # assert(lrg.compute_mask_size() == lrg.num_regs() || lrg.num_regs() == 2) failed: fat projs exactly color Patch: diff --git a/hotspot/src/share/vm/opto/chaitin.hpp b/hotspot/src/share/vm/opto/chaitin.hpp index de6d443..94f66b8 100644 --- a/hotspot/src/share/vm/opto/chaitin.hpp +++ b/hotspot/src/share/vm/opto/chaitin.hpp @@ -136,7 +136,7 @@ public: // Number of registers this live range uses when it colors private: - uint8 _num_regs; // 2 for Longs and Doubles, 1 for all else + uint16_t _num_regs; // 2 for Longs and Doubles, 1 for all else // except _num_regs is kill count for fat_proj public: int num_regs() const { return _num_regs; } Thanks, Leslie Zhai From shade at redhat.com Thu Apr 1 10:25:15 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 1 Apr 2021 12:25:15 +0200 Subject: RFC: Change uint8 to uint16_t for _num_regs In-Reply-To: <5e16cb09-366f-a799-3e31-9915c2458b32@loongson.cn> References: <5e16cb09-366f-a799-3e31-9915c2458b32@loongson.cn> Message-ID: On 4/1/21 7:20 AM, Leslie Zhai wrote: > Patch: > > diff --git a/hotspot/src/share/vm/opto/chaitin.hpp > b/hotspot/src/share/vm/opto/chaitin.hpp > index de6d443..94f66b8 100644 > --- a/hotspot/src/share/vm/opto/chaitin.hpp > +++ b/hotspot/src/share/vm/opto/chaitin.hpp > @@ -136,7 +136,7 @@ public: > > // Number of registers this live range uses when it colors > private: > - uint8 _num_regs; // 2 for Longs and Doubles, 1 for all else > + uint16_t _num_regs; // 2 for Longs and Doubles, 1 for all else > // except _num_regs is kill count for > fat_proj > public: > int num_regs() const { return _num_regs; } Looks to me it was changed to uint16_t in JDK 9 by "8076276: Add support for AVX512" https://bugs.openjdk.java.net/browse/JDK-8076276 Note that patch also changed: - uint8_t _reg_pressure; + uint16_t _reg_pressure; From reading the uses of these fields, I think these are more or less safe to widen. -- Thanks, -Aleksey From shade at redhat.com Thu Apr 1 10:53:48 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 1 Apr 2021 12:53:48 +0200 Subject: RFR (S) 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8234011 https://hg.openjdk.java.net/jdk/jdk/rev/fe87a92570db Patch does not apply to 8u cleanly, because we need to shuffle the files and fix the test to match JDK 8 APIs. It follows the thing Volker did for 11u: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-July/003560.html ...but 8u does not even have Map.of. Plus, I had to fold the follow-up 11u-specific fix: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1ba4c16a8afa 8u webrev: https://cr.openjdk.java.net/~shade/8234011/webrev.8u.01/ Testing: Linux x86_64, new test fails without patch, passes with it; Windows x86_64, test passes -- Thanks, -Aleksey From zhaixiang at loongson.cn Thu Apr 1 10:59:45 2021 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 1 Apr 2021 18:59:45 +0800 Subject: RFC: Change uint8 to uint16_t for _num_regs In-Reply-To: References: <5e16cb09-366f-a799-3e31-9915c2458b32@loongson.cn> Message-ID: <6d6e9490-0b19-7268-b85c-2861f75eea56@loongson.cn> Hi Aleksey, Thanks for your kind response! ? 2021?04?01? 18:25, Aleksey Shipilev ??: > On 4/1/21 7:20 AM, Leslie Zhai wrote: >> Patch: >> >> diff --git a/hotspot/src/share/vm/opto/chaitin.hpp >> b/hotspot/src/share/vm/opto/chaitin.hpp >> index de6d443..94f66b8 100644 >> --- a/hotspot/src/share/vm/opto/chaitin.hpp >> +++ b/hotspot/src/share/vm/opto/chaitin.hpp >> @@ -136,7 +136,7 @@ public: >> >> // Number of registers this live range uses when it colors >> private: >> - uint8 _num_regs; // 2 for Longs and Doubles, 1 for >> all else >> + uint16_t _num_regs; // 2 for Longs and Doubles, 1 for >> all else >> // except _num_regs is kill count for >> fat_proj >> public: >> int num_regs() const { return _num_regs; } > > Looks to me it was changed to uint16_t in JDK 9 by "8076276: Add > support for AVX512" > https://bugs.openjdk.java.net/browse/JDK-8076276 > > Note that patch also changed: > - uint8_t _reg_pressure; > + uint16_t _reg_pressure; Thanks! Leslie Zhai > > From reading the uses of these fields, I think these are more or less > safe to widen. > From volker.simonis at gmail.com Thu Apr 1 12:09:36 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 1 Apr 2021 14:09:36 +0200 Subject: RFR (S) 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() In-Reply-To: References: Message-ID: Looks good to me. Thanks for downporting, Volker On Thu, Apr 1, 2021 at 12:55 PM Aleksey Shipilev wrote: > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8234011 > https://hg.openjdk.java.net/jdk/jdk/rev/fe87a92570db > > Patch does not apply to 8u cleanly, because we need to shuffle the files and fix the test to match > JDK 8 APIs. It follows the thing Volker did for 11u: > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-July/003560.html > > ...but 8u does not even have Map.of. Plus, I had to fold the follow-up 11u-specific fix: > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1ba4c16a8afa > > 8u webrev: > https://cr.openjdk.java.net/~shade/8234011/webrev.8u.01/ > > Testing: Linux x86_64, new test fails without patch, passes with it; Windows x86_64, test passes > > -- > Thanks, > -Aleksey > From shade at redhat.com Thu Apr 1 15:27:00 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 1 Apr 2021 17:27:00 +0200 Subject: RFR (S) 8234011: (zipfs) Memory leak in ZipFileSystem.releaseDeflater() In-Reply-To: References: Message-ID: <51f70c5f-8a19-4e19-2808-9edfb1790c20@redhat.com> On 4/1/21 2:09 PM, Volker Simonis wrote: > Looks good to me. Thanks, I tagged it for approval. -- -Aleksey From denghui.ddh at alibaba-inc.com Thu Apr 1 15:47:52 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Thu, 01 Apr 2021 23:47:52 +0800 Subject: =?UTF-8?B?V2VhayBoYW5kbGVzIGxlYWsgY2F1c2VzIEdDIHRvIHRha2UgbG9uZ2Vy?= Message-ID: Hi, One of our applications using JDK8 has the problem of slow increase in YGC time-consuming, and I found that the problem is caused by the weak handles leak. The following code can reproduce this problem after running for a long time. ``` class Test { static MethodHandles.Lookup lookup = MethodHandles.lookup(); public static void main(String[] args) { while (true) { MethodType type = MethodType.methodType(double.class, double.class); try { MethodHandle mh = lookup.findStatic(Math.class, "log", type); System.err.println(mh); } catch (Throwable t) { } } } } ``` I think it's a known problem, there are two issues related to this problem, JDK-8152271: MemberNameTable doesn't purge stale entries JDK-8174749: Use hash table/oops for MemberName table JDK-8152271 already exists in 8u but doesn't resolve this problem. So I tried to backport JDK-8152271 and another performance improvement issue JDK-8249719, it works, but introduced another performance problem, and also the backport is not clean. So i tried another way, and I think the following fix may rolve the problem, diff --git a/src/share/vm/prims/methodHandles.cpp b/src/share/vm/prims/methodHandles.cpp index 9e19dbbe3..fb9d0be7e 100644 --- a/src/share/vm/prims/methodHandles.cpp +++ b/src/share/vm/prims/methodHandles.cpp @@ -972,6 +972,13 @@ oop MemberNameTable::find_or_add_member_name(jweak mem_name_wref) { return mname; } } + + if (new_index < len) { + assert(JNIHandles::resolve(this->at(new_index)) == NULL, "sanity"); + // destory the old handle + JNIHandles::destroy_weak_global(this->at(new_index)); + } + // Not found, push the new one, or reuse empty slot this->at_put_grow(new_index, mem_name_wref); return new_mem_name; I didn't file a new issue in JBS yet. I want to hear your suggestions because I am not familiar with the implementation of MemberName-related stuff, so I am not sure if there is a problem with this fix. testing: linux_x86 jdk/test/java/lang/invoke Any input is appreciated. Thanks, Denghui From felix.yang at huawei.com Fri Apr 2 01:22:54 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 2 Apr 2021 01:22:54 +0000 Subject: RFR: 8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() Message-ID: <2482c29e62b24019ad23c7b59cea2b59@huawei.com> Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8217230 https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a5a3822a7239 JDK-8217230 is a regression by JDK-8214862 (https://bugs.openjdk.java.net/browse/JDK-8214862). JDK-8214862 was backported to openjdk8u272, but JDK-8217230 is not there. This bug was triggered only once for this test case in my local jtreg run (hard to reproduce): java/util/concurrent/ConcurrentQueues/RemovePollRace.java Patch does not apply to 8u cleanly due to changes in surrounding context in file compile.hpp. 8u webrev: http://cr.openjdk.java.net/~fyang/8217230-8u/webrev.00 The fix is simple and should be low risk (it removes a dead node from the C2 IR). Performed full jtreg test with fastdebug build on x86_64 Linux. OK to backport? Thanks, Felix From felix.yang at huawei.com Fri Apr 2 01:46:41 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 2 Apr 2021 01:46:41 +0000 Subject: RFR(XS): 8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type Message-ID: Hi, Please review this one-line change fixing a JFR crash for 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8264562 http://cr.openjdk.java.net/~fyang/8264562/webrev.00/ This issue can always be reproduced by running the following two jtreg tests with 8u debug build: jdk/jfr/event/gc/collection/TestGCEventMixedWithG1ConcurrentMark.java jdk/jfr/event/gc/collection/TestGCEventMixedWithG1FullCollection.java I think the reason is that we are not setting trace type for EventG1HeapRegionInformation event. Patch adds back "type" information for EventG1HeapRegionInformation event. This should also improves basic functionality of 8u JFR EventG1HeapRegionInformation tracing. Performed full jtreg test with fastdebug build on x86_64 Linux. These two affected jtreg tests fail without this fix and pass otherwise. OK? Thanks, Felix From rwestrel at redhat.com Fri Apr 2 12:01:08 2021 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 02 Apr 2021 14:01:08 +0200 Subject: RFR: 8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() In-Reply-To: <2482c29e62b24019ad23c7b59cea2b59@huawei.com> References: <2482c29e62b24019ad23c7b59cea2b59@huawei.com> Message-ID: <87im54q4jf.fsf@redhat.com> > http://cr.openjdk.java.net/~fyang/8217230-8u/webrev.00 Change looks good to me. Roland. From mathiske at amazon.com Fri Apr 2 20:21:51 2021 From: mathiske at amazon.com (Mathiske, Bernd) Date: Fri, 2 Apr 2021 20:21:51 +0000 Subject: Defer disabling TLS 1.0/1.1 by default? Message-ID: We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now. Can this default configuration change be deferred in general?? Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default?? Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date? My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct? We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur. (sent to jdk-updates-dev@, jdk8u-dev@, and security-dev@) Bernd From hohensee at amazon.com Fri Apr 2 20:42:20 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 2 Apr 2021 20:42:20 +0000 Subject: RFR(XS): 8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type Message-ID: <7B40E5E7-816B-4CB4-A938-C3C01EE19C8B@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "Yangfei (Felix)" Date: Thursday, April 1, 2021 at 6:47 PM To: "jdk8u-dev at openjdk.java.net" Subject: RFR(XS): 8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type Hi, Please review this one-line change fixing a JFR crash for 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8264562 http://cr.openjdk.java.net/~fyang/8264562/webrev.00/ This issue can always be reproduced by running the following two jtreg tests with 8u debug build: jdk/jfr/event/gc/collection/TestGCEventMixedWithG1ConcurrentMark.java jdk/jfr/event/gc/collection/TestGCEventMixedWithG1FullCollection.java I think the reason is that we are not setting trace type for EventG1HeapRegionInformation event. Patch adds back "type" information for EventG1HeapRegionInformation event. This should also improves basic functionality of 8u JFR EventG1HeapRegionInformation tracing. Performed full jtreg test with fastdebug build on x86_64 Linux. These two affected jtreg tests fail without this fix and pass otherwise. OK? Thanks, Felix From hedongbo at huawei.com Sat Apr 3 01:52:17 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Sat, 3 Apr 2021 09:52:17 +0800 Subject: [8u] RFR 8259886: Improve SSL session cache performance and scalability Message-ID: /Hi, //////Original Bug: https://bugs.openjdk.java.net/browse/JDK-8259886 / ////https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/82a5dca5c57c ///Patch does not apply to 8u cleanly, because we need to remove the //microbenchmark that//doesn't exist in 8u./////8u webrev: /http://cr.openjdk.java.net/~dongbohe/8259886/webrev.01/ The following is the performance data on my machine. JMH: CacheBench.put 20480 86400 avgt 25 125214.877 ? 771.891 ns/op CacheBench.put 20480 0 avgt 25 130.827 ? 4.886 ns/op CacheBench.put 204800 86400 avgt 25 1421192.003 ? 10492.641 ns/op CacheBench.put 204800 0 avgt 25 205.607 ? 9.081 ns/op CacheBench.put 5120000 86400 avgt 25 426789424.874 ? 56051669.301 ns/op CacheBench.put 5120000 0 avgt 25 1694.398 ? 178.005 ns/op after patch: CacheBench.put 20480 0 avgt 25 135.425 ? 4.609 ns/op CacheBench.put 204800 86400 avgt 25 281.704 ? 10.688 ns/op CacheBench.put 204800 0 avgt 25 220.617 ? 10.616 ns/op CacheBench.put 5120000 86400 avgt 25 1803.882 ? 220.730 ns/op CacheBench.put 5120000 0 avgt 25 1748.993 ? 245.926 ns/op tomcat+jmeter:/ //summary + 431008 in 00:00:06 = 71846.6/s Avg: 12 Min: 0 Max: 500 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 72392845 in 00:16:54 = 71365.9/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 415424 in 00:00:06 = 69237.3/s Avg: 12 Min: 0 Max: 499 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 72808269 in 00:17:00 = 71353.4/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 422887 in 00:00:06 = 70481.2/s Avg: 12 Min: 0 Max: 619 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 73231156 in 00:17:06 = 71348.3/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 415679 in 00:00:06 = 69279.8/s Avg: 13 Min: 0 Max: 517 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 73646835 in 00:17:12 = 71336.3/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 397989 in 00:00:06 = 66276.3/s Avg: 14 Min: 0 Max: 507 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0/ after patch:///summary + 671589 in 00:00:06 = 111931.5/s Avg: 2 Min: 0 Max: 132 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 101709661 in 00:16:43 = 101436.1/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 618923 in 00:00:06 = 102965.1/s Avg: 1 Min: 0 Max: 127 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 102328584 in 00:16:49 = 101445.1/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 624735 in 00:00:06 = 104331.2/s Avg: 1 Min: 0 Max: 200 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 102953319 in 00:16:55 = 101462.1/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 576132 in 00:00:06 = 95766.6/s Avg: 1 Min: 0 Max: 154 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 103529451 in 00:17:01 = 101428.6/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 529216 in 00:00:06 = 88438.5/s Avg: 1 Min: 0 Max: 128 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0/ //////Testing: Linux x86_64 tier1. / -- thanks, hedongbo From colm at apache.org Fri Apr 2 21:15:58 2021 From: colm at apache.org (=?UTF-8?Q?Colm_MacC=C3=A1rthaigh?=) Date: Fri, 2 Apr 2021 14:15:58 -0700 Subject: Defer disabling TLS 1.0/1.1 by default? In-Reply-To: References: Message-ID: I'm a mere Java user and developer, I'm not a JDK person. I'm also only on jdk-updates-dev, so if this message ended up in mod-queues, apologies! I'm replying as a TLS person. I work at AWS too, leading our TLS work, and we took a look at this as part of the upcoming changes for Amazon Corretto. The short version is this: we think about 1% of applications and traffic "out there" are still using TLS1.0/TLS1.1. Given where browsers are at, I think this percentage is an under-estimate of the usage on Java applications - I suspect it's even higher there. When we dig in with customers "Why are you still using TLS1.0 or TLS1.1" the most common reasons are legacy appliances and applications. Think of hardware load balancers that were never updated, or can't be, to support TLS1.2 or better. Compliance mandated traffic inspection devices that force TLS1.0 in certain industries are another reason. For these applications, the change will break them, and they'll get a low-level exception. The users can re-enable TLS1.0 and TLS1.1, but they may suffer an outage because they likely weren't expecting a breaking change low in the networking stack. Retiring TLS1.0 and TLS1.1 is worthy, but I'd suggest that doing it in one pass is premature right now. The browsers are each at different degrees of support, some have "nuisance" warnings, some have no warnings at all. They've all punted a few times on when TLS1.0 and TLS1.1 may be hard disabled, but so far it's available in some form in all of them. I don't know of any other programming language (e.g. Go, Python, etc) that's doing something similar either. I tend to be an absolute paranoid zealot about security, but I don't lose sleep terribly over the issues that are in TLS1.0 and TLS1.1. I do want to retire the protocols ... but ideally without breaking anyone. If there's a way instead to do multiple passes and ship a JDK that measures TLS1.0 and TLS1.1 usage - as the browsers do - I'd love that. Then I could work with users to identify workloads where they are relying on TLS1.0 as a last resort and be proactive about the change. This doesn't have to be spyware phone-home measurements, even a local counter would be valuable. When we make these kinds of changes to AWS services, we go through a similar process: we see who is still using the old protocols and reach out to customers to work with them to update and ensure they won't be impacted. OpenJDK isn't a managed service, but we could help consumers help themselves at least. Since it will likely come up - here's a summary of the known security issues that are in TLS1.0 and TLS1.1: 1. The BEAST attack, which is in TLS1.0 only. The BEAST attack is a sophisticated attack that utilizes both active traffic interception and manipulation of retries and responses to Browsers (the ?B? in BEAST stands for ?Browser?). In general, it?s not the kind of attack that Java applications are vulnerable to.Even so, OpenJDK actually includes mitigations for the BEAST attack, but the "other" side of a TLS connection may not. 2. The SHA1/MD5 Transcript hash. To ensure that a sender or receiver isn?t being tricked by any kind of attacker in the middle, TLS uses a secure record of all the data sent and received called a transcript hash. In TLSv1.0 and TLSv1.1 this hash uses either a novel combination of the MD5 and SHA1 algorithms, or the SHA1 algorithm alone. Both MD5 and SHA1 are considered broken. In Cryptography we like to have extremely generous security margins, and the bar for what is considered ?broken? and what is actually practical are often very different. In this case, researchers estimate that it takes about 150 trillion trillion (that?s 150 trillion, times a trillion) operations to brute-force a TLSv1.0 or TLSv1.1 transcript hash. These hashes aren?t fixed, like the hashes on a certificate, they are unique to every SSL/TLS session. To use this weakness an attacker first has to intercept all communications between the sender and receiver. They put themselves in the middle. Then, during the handshake, the attacker must perform 150 trillion trillion operations to ?crack? the hash before allowing either side to proceed past the handshake. This also must happen without either side timing out or noticing the delay. Advanced dedicated SHA1 crackers can crack approximately 100 billion SHA1 hashes per second per processor. Even with these devices, it would take about fifty thousand processor years to crack a single TLS transcript hash. Performing the attack within 30 seconds would require over 500 million such devices operating in parallel. There are also no commercial devices capable of targeting the novel MD5/SHA1 combination, which is much more typical in TLSv1.0 and TLSv1.1. In short, cryptographers are rightly concerned about this issue. Processors will only get faster, and at some point, this attack may fall within the capabilities of large actors such as nation states and organized crime. But this issue is not a serious risk or threat for most java applications. 3. TLS1.0 and TLS1.1 support only the CBC ciphers which are vulnerable to Lucky13 and Sweet32. Turning off TLS1.0 and TLS1.1 actually doesn't fully mitigate these - these ciphers can be used over TLS1.2 also. But TLS1.2 does have better alternatives (e.g. AES-GCM). Lucky13 isn't a practical attack against TLS, even in extremely favorable circumstances for an attacker. Regardless, OpenJDK includes mitigations and uses a constant-time padding algorithm which is what matters. That leaves Sweet32, which is specific to 3DES. This issue impacts applications that send very large amounts of data, and again requires an active interception from an attacker. Many large websites with great security teams continue to maintain 3DES as a last-resort for compatibility with legacy systems, and I can see the reasoning. Other background: My experience is that many Java applications use TLS for confidentiality, but often do not consider traffic interception important in their threat model. It's very common to see self-signed certificates being used, for example, which make any application vulnerable to interception. The kinds of places where TLS1.0 and TLS1.1 are still used tend by their nature to be private networks that have other security controls in place. There are no TLS1.0 or TLS1.1 differences relating to how certificates are handled. OpenJDK is also immune to downgrade attacks. An attacker can't make it choose TLS1.0 or 1.1 if the other end supports TLS1.2 or better. On the whole, with all of those trade-offs in balance, it feels risky to me to disable TLS1.0 and TLS1.1 right now. To be clear though: it is better to use TLS1.2 than to use TLS1.0 and TLS1.1, and I'm very glad that OpenJDK does it right. People should fix or remove those legacy appliances in their networks, and I know customers that are. We all know that attacks only improve over time. But I don't think there's quite any clearly exploitable or very concerning issue that rises to the level of "this shouldn't even be supported in the language right now". I also don't see it as a few "bad" users out there holding back the rest of us. Keeping TLS1.0 and TLS1.1 in the default set in no way prevents applications from using TLS1.2 or better. But opinions can differ here. Others may prefer to be more forceful with changes and to take on a mission of clearing cruft faster. We've been having internal discussions about this and wanted to bring it here to the community and be open about it. On Fri, Apr 2, 2021 at 1:22 PM Mathiske, Bernd wrote: > > We have recently been made aware of increasing concerns by customers that disabling TLS 1.0/1.1 in the upcoming round of OpenJDK updates on April 20, as is the plan of record, could still cause outages. So we are considering keeping TLS 1.0/1.1 enabled by default in Amazon Corretto for now. > > Can this default configuration change be deferred in general? > > Are there any concerns regarding Amazon Corretto keeping TLS 1.0/1.1 enabled by default? > > Should we offer an alternate build that conforms with disabling by default and have the two lines converge again at a later date? > > My understanding is that in principle TLS 1.2/1.3 is not more secure than 1.0/1.1 and therefore we are not looking at a security fix here, correct? > > We are aware that the default setting can be manually changed by every user, but considering automated intake of binary artifacts we anticipate that this will not always be applied and disruptions will still occur. > > (sent to jdk-updates-dev@, jdk8u-dev@, and security-dev@) > > Bernd > > -- Colm From felix.yang at huawei.com Tue Apr 6 01:33:44 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 6 Apr 2021 01:33:44 +0000 Subject: RFR: 8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() In-Reply-To: <87im54q4jf.fsf@redhat.com> References: <2482c29e62b24019ad23c7b59cea2b59@huawei.com> <87im54q4jf.fsf@redhat.com> Message-ID: Hi, Thanks for reviewing this fix. I have tagged this for approval. Felix > -----Original Message----- > From: Roland Westrelin [mailto:rwestrel at redhat.com] > Sent: Friday, April 2, 2021 8:01 PM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8217230: assert(t == t_no_spec) failure in > NodeHash::check_no_speculative_types() > > > > http://cr.openjdk.java.net/~fyang/8217230-8u/webrev.00 > > Change looks good to me. > > Roland. From felix.yang at huawei.com Tue Apr 6 01:34:01 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 6 Apr 2021 01:34:01 +0000 Subject: RFR(XS): 8264562: assert(verify_field_bit(1)) failed: Attempting to write an uninitialized event field: type In-Reply-To: <7B40E5E7-816B-4CB4-A938-C3C01EE19C8B@amazon.com> References: <7B40E5E7-816B-4CB4-A938-C3C01EE19C8B@amazon.com> Message-ID: Hi, Thanks for reviewing this fix. I have tagged this for approval. Felix > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: Saturday, April 3, 2021 4:42 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR(XS): 8264562: assert(verify_field_bit(1)) failed: Attempting > to write an uninitialized event field: type > > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of "Yangfei > (Felix)" > Date: Thursday, April 1, 2021 at 6:47 PM > To: "jdk8u-dev at openjdk.java.net" > Subject: RFR(XS): 8264562: assert(verify_field_bit(1)) failed: Attempting to > write an uninitialized event field: type > > Hi, > > Please review this one-line change fixing a JFR crash for 8u: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8264562 > http://cr.openjdk.java.net/~fyang/8264562/webrev.00/ > > This issue can always be reproduced by running the following two jtreg tests > with 8u debug build: > > jdk/jfr/event/gc/collection/TestGCEventMixedWithG1ConcurrentMark.java > jdk/jfr/event/gc/collection/TestGCEventMixedWithG1FullCollection.java > > I think the reason is that we are not setting trace type for > EventG1HeapRegionInformation event. > Patch adds back "type" information for EventG1HeapRegionInformation > event. > This should also improves basic functionality of 8u JFR > EventG1HeapRegionInformation tracing. > > Performed full jtreg test with fastdebug build on x86_64 Linux. > These two affected jtreg tests fail without this fix and pass otherwise. > OK? > > Thanks, > Felix From hedongbo at huawei.com Tue Apr 6 06:38:32 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Tue, 6 Apr 2021 14:38:32 +0800 Subject: [8u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: Oh..sorry, my thunderbird doesn?t seem to be configured properly, causing the format of the web page to be messed up. It should work now. JMH uses the microbenchmark in the 11u patch. In general, the CacheBench.put averageTime of JMH increased by 99% (timeout=86400), and the tomcat TPS increased by 33%. Any thoughts? Original Bug: ??? https://bugs.openjdk.java.net/browse/JDK-8259886 ??? https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/82a5dca5c57c Patch does not apply to 8u cleanly, because we need to remove the microbenchmark that doesn't exist in 8u. 8u webrev: http://cr.openjdk.java.net/~dongbohe/8259886/webrev.01/ The following is the performance data on my machine. JMH(mode=AverageTime): ? Benchmark?????????? (size)?? (timeout) Mode? Cnt????????? Score????????? Error? Units ? CacheBench.put?????? 20480????? 86400? avgt?? 25???? 125214.877 ?????? 771.891? ns/op ? CacheBench.put?????? 20480????????? 0? avgt?? 25??????? 130.827 ???????? 4.886? ns/op ? CacheBench.put????? 204800????? 86400? avgt?? 25??? 1421192.003 ???? 10492.641? ns/op ? CacheBench.put????? 204800????????? 0? avgt?? 25??????? 205.607 ???????? 9.081? ns/op ? CacheBench.put???? 5120000????? 86400? avgt?? 25? 426789424.874 ? 56051669.301? ns/op ? CacheBench.put???? 5120000????????? 0? avgt?? 25?????? 1694.398 ?????? 178.005? ns/op after patch: ? Benchmark?????????? (size)?? (timeout) Mode? Cnt???? Score???? Error? Units ? CacheBench.put?????? 20480????? 86400? avgt?? 25?? 194.639 ??? 3.222? ns/op ? CacheBench.put?????? 20480????????? 0? avgt?? 25?? 135.425 ??? 4.609? ns/op ? CacheBench.put????? 204800????? 86400? avgt?? 25?? 281.704 ?? 10.688? ns/op ? CacheBench.put????? 204800????????? 0? avgt?? 25?? 220.617 ?? 10.616? ns/op ? CacheBench.put???? 5120000????? 86400? avgt?? 25? 1803.882 ? 220.730? ns/op ? CacheBench.put???? 5120000????????? 0? avgt?? 25? 1748.993 ? 245.926? ns/op tomcat+jmeter: ? summary + 431008 in 00:00:06 = 71846.6/s Avg:??? 12 Min:???? 0 Max:?? 500 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 72392845 in 00:16:54 = 71365.9/s Avg:??? 12 Min:???? 0 Max:? 1155 Err:???? 0 (0.00%) ? summary + 415424 in 00:00:06 = 69237.3/s Avg:??? 12 Min:???? 0 Max:?? 499 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 72808269 in 00:17:00 = 71353.4/s Avg:??? 12 Min:???? 0 Max:? 1155 Err:???? 0 (0.00%) ? summary + 422887 in 00:00:06 = 70481.2/s Avg:??? 12 Min:???? 0 Max:?? 619 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 73231156 in 00:17:06 = 71348.3/s Avg:??? 12 Min:???? 0 Max:? 1155 Err:???? 0 (0.00%) ? summary + 415679 in 00:00:06 = 69279.8/s Avg:??? 13 Min:???? 0 Max:?? 517 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 73646835 in 00:17:12 = 71336.3/s Avg:??? 12 Min:???? 0 Max:? 1155 Err:???? 0 (0.00%) ? summary + 397989 in 00:00:06 = 66276.3/s Avg:??? 14 Min:???? 0 Max:?? 507 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 after patch: ? summary + 671589 in 00:00:06 = 111931.5/s Avg:???? 2 Min:???? 0 Max:?? 132 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 101709661 in 00:16:43 = 101436.1/s Avg:???? 2 Min:???? 0 Max:? 1378 Err:???? 0 (0.00%) ? summary + 618923 in 00:00:06 = 102965.1/s Avg:???? 1 Min:???? 0 Max:?? 127 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 102328584 in 00:16:49 = 101445.1/s Avg:???? 2 Min:???? 0 Max:? 1378 Err:???? 0 (0.00%) ? summary + 624735 in 00:00:06 = 104331.2/s Avg:???? 1 Min:???? 0 Max:?? 200 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 102953319 in 00:16:55 = 101462.1/s Avg:???? 2 Min:???? 0 Max:? 1378 Err:???? 0 (0.00%) ? summary + 576132 in 00:00:06 = 95766.6/s Avg:???? 1 Min:???? 0 Max:?? 154 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 ? summary = 103529451 in 00:17:01 = 101428.6/s Avg:???? 2 Min:???? 0 Max:? 1378 Err:???? 0 (0.00%) ? summary + 529216 in 00:00:06 = 88438.5/s Avg:???? 1 Min:???? 0 Max:?? 128 Err:???? 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 Testing: Linux x86_64 tier1. On 4/3/2021 9:52 AM, He Dongbo(JVM) wrote: > /Hi, //////Original Bug: ? https://bugs.openjdk.java.net/browse/JDK-8259886 / ////https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/82a5dca5c57c ///Patch does not apply to 8u cleanly, because we need to remove the //microbenchmark that//doesn't exist in 8u./////8u webrev: /http://cr.openjdk.java.net/~dongbohe/8259886/webrev.01/ The following is the performance data on my machine. JMH: CacheBench.put 20480 86400 avgt 25 125214.877 ? 771.891 ns/op CacheBench.put 20480 0 avgt 25 130.827 ? 4.886 ns/op CacheBench.put 204800 86400 avgt 25 1421192.003 ? 10492.641 ns/op CacheBench.put 204800 0 avgt 25 205.607 ? 9.081 ns/op CacheBench.put 5120000 86400 avgt 25 426789424.874 ? 56051669.301 ns/op CacheBench.put 5120000 0 avgt 25 1694.398 ? 178.005 ns/op after patch: CacheBench.put 20480 0 avgt 25 135.425 ? 4.609 ns/op CacheBench.put 204800 86400 avgt 25 281.704 ? 10.688 ns/op CacheBench.put 204800 0 avgt 25 220.617 ? 10.616 ns/op CacheBench.put 5120000 86400 avgt 25 1803.882 ? 220.730 ns/op CacheBench.put 5120000 0 avgt 25 1748.993 ? 245.926 ns/op tomcat+jmeter:/ > //summary + 431008 in 00:00:06 = 71846.6/s Avg: 12 Min: 0 Max: 500 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 72392845 in 00:16:54 = 71365.9/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 415424 in 00:00:06 = 69237.3/s Avg: 12 Min: 0 Max: 499 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 72808269 in 00:17:00 = 71353.4/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 422887 in 00:00:06 = 70481.2/s Avg: 12 Min: 0 Max: 619 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 73231156 in 00:17:06 = 71348.3/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 415679 in 00:00:06 = 69279.8/s Avg: 13 Min: 0 Max: 517 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 73646835 in 00:17:12 = 71336.3/s Avg: 12 Min: 0 Max: 1155 Err: 0 (0.00%) summary + 397989 in 00:00:06 = 66276.3/s Avg: 14 Min: 0 Max: 507 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0/ after patch:///summary + 671589 in 00:00:06 = 111931.5/s Avg: 2 Min: 0 Max: 132 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 101709661 in 00:16:43 = 101436.1/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 618923 in 00:00:06 = 102965.1/s Avg: 1 Min: 0 Max: 127 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 102328584 in 00:16:49 = 101445.1/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 624735 in 00:00:06 = 104331.2/s Avg: 1 Min: 0 Max: 200 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 102953319 in 00:16:55 = 101462.1/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 576132 in 00:00:06 = 95766.6/s Avg: 1 Min: 0 Max: 154 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0 summary = 103529451 in 00:17:01 = 101428.6/s Avg: 2 Min: 0 Max: 1378 Err: 0 (0.00%) summary + 529216 in 00:00:06 = 88438.5/s Avg: 1 Min: 0 Max: 128 Err: 0 (0.00%) Active: 1000 Started: 1000 Finished: 0/ //////Testing: Linux x86_64 tier1. / > -- > thanks, > hedongbo -- thanks, hedongbo From denghui.ddh at alibaba-inc.com Wed Apr 7 07:44:47 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 07 Apr 2021 15:44:47 +0800 Subject: =?UTF-8?B?Wzh1XSBSRlIgODI2NDgxNjogV2VhayBoYW5kbGVzIGxlYWsgY2F1c2VzIEdDIHRvIHRha2Ug?= =?UTF-8?B?bG9uZ2Vy?= Message-ID: <07897f72-21fe-45da-846a-3d5cdf088d32.denghui.ddh@alibaba-inc.com> Hi, Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 Testing: Linux x86_64 jdk/test/java/lang/invoke Other information: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html Thanks, Denghui From aph at redhat.com Wed Apr 7 10:18:22 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 7 Apr 2021 11:18:22 +0100 Subject: [8u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: On 4/6/21 7:38 AM, He Dongbo(JVM) wrote: > JMH uses the microbenchmark in the 11u patch. In general, the CacheBench.put averageTime of JMH increased by 99% (timeout=86400), and the tomcat TPS increased by 33%. Any thoughts? Looks reasonable enough, but I'd like a security specialist to have a look too. Cc: mbalao. -- 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 anleonar at redhat.com Wed Apr 7 17:16:46 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Wed, 7 Apr 2021 18:16:46 +0100 Subject: RFR: 8264509: jdk8u MacOS zipped debug symbols won't build Message-ID: Hi, Please can I request a review for this fix on jdk8u mac, following merging of the debug symbols support PR https://bugs.openjdk.java.net/browse/JDK-8262730, i've discovered that trying to build on jdk8u mac with default configure options, which will default to zipped, will fail on Mac as there is a missing rule to copy the .diz. The following fix simply adds that missing rule: webrev: http://cr.openjdk.java.net/~aleonard/8264509/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8264509 Please can I get a review and sponsor to merge, thank you Andrew From hohensee at amazon.com Wed Apr 7 20:04:55 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 7 Apr 2021 20:04:55 +0000 Subject: RFR: 8264509: jdk8u MacOS zipped debug symbols won't build Message-ID: <4E329C3B-ABCF-4838-A2C2-04CE1BA3BC6A@amazon.com> Lgtm. I'll sponsor. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Andrew Leonard Date: Wednesday, April 7, 2021 at 10:18 AM To: "jdk8u-dev at openjdk.java.net" Subject: RFR: 8264509: jdk8u MacOS zipped debug symbols won't build Hi, Please can I request a review for this fix on jdk8u mac, following merging of the debug symbols support PR https://bugs.openjdk.java.net/browse/JDK-8262730, i've discovered that trying to build on jdk8u mac with default configure options, which will default to zipped, will fail on Mac as there is a missing rule to copy the .diz. The following fix simply adds that missing rule: webrev: http://cr.openjdk.java.net/~aleonard/8264509/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8264509 Please can I get a review and sponsor to merge, thank you Andrew From anleonar at redhat.com Thu Apr 8 07:59:06 2021 From: anleonar at redhat.com (Andrew Leonard) Date: Thu, 8 Apr 2021 08:59:06 +0100 Subject: RFR: 8264509: jdk8u MacOS zipped debug symbols won't build In-Reply-To: <4E329C3B-ABCF-4838-A2C2-04CE1BA3BC6A@amazon.com> References: <4E329C3B-ABCF-4838-A2C2-04CE1BA3BC6A@amazon.com> Message-ID: Thank you Paul, much appreciated On Wed, Apr 7, 2021 at 9:05 PM Hohensee, Paul wrote: > Lgtm. I'll sponsor. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Andrew > Leonard > Date: Wednesday, April 7, 2021 at 10:18 AM > To: "jdk8u-dev at openjdk.java.net" > Subject: RFR: 8264509: jdk8u MacOS zipped debug symbols won't build > > Hi, > Please can I request a review for this fix on jdk8u mac, following merging > of the debug symbols support PR > https://bugs.openjdk.java.net/browse/JDK-8262730, i've discovered that > trying to build on jdk8u mac with default configure options, which will > default to zipped, will fail on Mac as there is a missing rule to copy the > .diz. The following fix simply adds that missing rule: > webrev: http://cr.openjdk.java.net/~aleonard/8264509/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8264509 > > Please can I get a review and sponsor to merge, > thank you > Andrew > > From hohensee at amazon.com Thu Apr 8 16:10:17 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 8 Apr 2021 16:10:17 +0000 Subject: RFR [3/3]: 8231501 VM crash in MethodData::clean_extra_data(CleanExtraDataClosure*): fatal error: unexpected tag 99 Message-ID: <7651EB8E-8A01-456D-B79E-26C1F6EBE3EF@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Peter Zhelezniakov Date: Tuesday, December 22, 2020 at 4:24 AM To: "jdk8u-dev at openjdk.java.net" Subject: RFR [3/3]: 8231501 VM crash in MethodData::clean_extra_data(CleanExtraDataClosure*): fatal error: unexpected tag 99 Hi, This is the final backport request in a series of 3: [1], [2], [3]. The patch did not apply cleanly because context has changed significantly. Tested with Hotspot JTreg tests. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8231501 Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8231501/8231501/ Thanks! Peter [1] https://bugs.openjdk.java.net/browse/JDK-8057038 [2] https://bugs.openjdk.java.net/browse/JDK-8139247 [3] https://bugs.openjdk.java.net/browse/JDK-8231501 From hohensee at amazon.com Thu Apr 8 22:06:33 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 8 Apr 2021 22:06:33 +0000 Subject: [aarch64-port-dev ] discussion: two possible 8u backport patches Message-ID: Imo failing tests in 8u should be fixed, especially in debug versions because those are the ones we depend on for, e.g., nightly testing. So, I'm in favor of backporting these to 8u. Initial discussion is appropriate for jdk8u-dev, so cross-posting there. Thanks, Paul ?-----Original Message----- From: aarch64-port-dev on behalf of "Yangfei (Felix)" Date: Wednesday, March 31, 2021 at 12:31 AM To: "aarch64-port-dev at openjdk.java.net" Subject: [aarch64-port-dev ] discussion: two possible 8u backport patches Hi, When running 8u jtreg hotspot test with -XX:+VerifyOops using fastdebug build, I find issue [1] was triggered for more than 200 test cases. And I am expecting more triggering of issue [1] with fix for issue [2] without which we may miss verifying some oops. As these two issues only affects debug version, I am not quite sure if they are valid candidates for 8u backporting. Since they are aarch64-specific, so I send here for some initial discussion before posting on jdk8u-dev mailing list. Personally, I am inclined to think that we should have them in 8u. This will ensure/improve testing effectiveness for 8u aarch64. We are continuously carrying out building and testing for aarch64 fastdebug build internally. 8247350 : [aarch64] assert(false) failed: wrong size of mach node 8260029 : aarch64: fix typo in verify_oop_array 1. https://bugs.openjdk.java.net/browse/JDK-8247350 2. https://bugs.openjdk.java.net/browse/JDK-8260029 Thanks, Felix From felix.yang at huawei.com Fri Apr 9 08:51:37 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 9 Apr 2021 08:51:37 +0000 Subject: [aarch64-port-dev ] discussion: two possible 8u backport patches In-Reply-To: References: Message-ID: Hi, Thanks for the comments. That makes sense to me. I will post a separate 8u RFR mail if there's no different opinions. Felix > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: Friday, April 9, 2021 6:07 AM > To: Yangfei (Felix) ; aarch64-port- > dev at openjdk.java.net > Cc: jdk8u-dev at openjdk.java.net > Subject: RE: [aarch64-port-dev ] discussion: two possible 8u backport patches > > Imo failing tests in 8u should be fixed, especially in debug versions because > those are the ones we depend on for, e.g., nightly testing. So, I'm in favor of > backporting these to 8u. Initial discussion is appropriate for jdk8u-dev, so > cross-posting there. > > Thanks, > Paul > > ?-----Original Message----- > From: aarch64-port-dev on > behalf of "Yangfei (Felix)" > Date: Wednesday, March 31, 2021 at 12:31 AM > To: "aarch64-port-dev at openjdk.java.net" dev at openjdk.java.net> > Subject: [aarch64-port-dev ] discussion: two possible 8u backport patches > > Hi, > > When running 8u jtreg hotspot test with -XX:+VerifyOops using fastdebug > build, I find issue [1] was triggered for more than 200 test cases. > And I am expecting more triggering of issue [1] with fix for issue [2] without > which we may miss verifying some oops. > As these two issues only affects debug version, I am not quite sure if they > are valid candidates for 8u backporting. > Since they are aarch64-specific, so I send here for some initial discussion > before posting on jdk8u-dev mailing list. > Personally, I am inclined to think that we should have them in 8u. This will > ensure/improve testing effectiveness for 8u aarch64. > We are continuously carrying out building and testing for aarch64 fastdebug > build internally. > > 8247350 : [aarch64] assert(false) failed: wrong size of mach node > 8260029 : aarch64: fix typo in verify_oop_array > > 1. https://bugs.openjdk.java.net/browse/JDK-8247350 > 2. https://bugs.openjdk.java.net/browse/JDK-8260029 > > Thanks, > Felix From mbalao at redhat.com Fri Apr 9 17:45:22 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 9 Apr 2021 14:45:22 -0300 Subject: [8u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: References: Message-ID: <51b0eb9c-a939-cc10-0063-ef6ece695a52@redhat.com> Hi Hedongbo, Thanks for contributing this backport to 8u. The original change makes perfect sense for 8u; I see nothing 8u-specific since we have almost the same SunJSSE engine than in newer releases. The change is fairly trivial, low risk and -as demonstrated- generates a good performance benefit. In regards to your backport, the only thing I'm not sure is the microbenchmark removal. I see many of these tests pushed to jdk/jdk, only a couple to 11u -plus the one added by 8259886-, and no tests in jdk8u. I now wonder if it was correct to push some of them to 11u. I guess we will not push it to 8u, but I'm CCing Aleksey for his input on this matter. Thanks, Martin.- On 4/7/21 7:18 AM, Andrew Haley wrote: > On 4/6/21 7:38 AM, He Dongbo(JVM) wrote: >> JMH uses the microbenchmark in the 11u patch. In general, the CacheBench.put averageTime of JMH increased by 99% (timeout=86400), and the tomcat TPS increased by 33%. Any thoughts? > > Looks reasonable enough, but I'd like a security specialist to have a > look too. Cc: mbalao. > From hohensee at amazon.com Fri Apr 9 22:41:44 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 9 Apr 2021 22:41:44 +0000 Subject: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException Message-ID: Fixed. https://cr.openjdk.java.net/~phh/8239798/webrev.8u.jdk.03/ Thanks, Paul ?-----Original Message----- From: Andrew Hughes Date: Sunday, March 28, 2021 at 8:26 PM To: "Hohensee, Paul" Cc: "Alvarez, David" , "jdk8u-dev at openjdk.java.net" Subject: RE: RFR [8u] JDK-8239798 : SSLSocket closes socket both socket endpoints on a SocketTimeoutException On 19:46 Thu 25 Mar , Hohensee, Paul wrote: > Webrev with fixed copyright header (and copyright dates): https://cr.openjdk.java.net/~phh/8239798/webrev.8u.jdk.01/ > > Thanks, > Paul > SSLSocketInputRecord.java now looks correct. Why are copyright changes being made to src/share/classes/sun/security/ssl/SSLTransport.java, test/sun/security/ssl/SSLSocketImpl/ClientTimeout.java and test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java? These changes are not in the original backport patch and also not in 11u at all. If this is necessary, it should go to 11u (and possibly HEAD) first in its own patch, so we don't create local divergence. 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 Fri Apr 9 23:16:58 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 9 Apr 2021 23:16:58 +0000 Subject: RFR: 8182036: Load from initializing arraycopy uses wrong memory state Message-ID: <61BDC9D1-0D1A-447F-9255-6C999005F47C@amazon.com> Looks reasonable to me, but I'd be happier if a C2 engineer weighed in. Roland? Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "Yangfei (Felix)" Date: Sunday, March 28, 2021 at 8:13 PM To: jdk8u-dev Subject: RFR: 8182036: Load from initializing arraycopy uses wrong memory state Hi, Please review this 8u backport fixing an user-visible C2 bug. Original bug: https://bugs.openjdk.java.net/browse/JDK-8182036 Original patch: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/fe7fdd0fc266 Original review thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-June/026448.html Webrev for 8u: http://cr.openjdk.java.net/~fyang/8182036-8u/webrev.00 This bug can always reproduced by running the provided test case with 8u on x86_64 or aarch64 linux. The AArch64 C2 JIT code snippet with & without the fix is shown here [1] [2]. I think we only needs this part for 8u (quotation from the original review thread): " Initialization of dst is performed by the arraycopy. PhaseMacroExpand::generate_block_arraycopy() generates a load/store pair to copy the element at offset 1 so it can bulk copy the elements starting at offset 2. Both the load and store are on the same slice which for an initializing arraycopy is raw memory. So the src[1] load and the src[1] = 0x42 store are not on the same slice and the load can happen before the store resulting in an incorrect execution. The fix I propose is for the load to be from the src's slice. " The rest of the original fix is not needed for 8u as it's related to the following two issues which is not there in 8u: 8076188: Optimize arraycopy out for non escaping destination 8150933: System::arraycopy intrinsic doesn't mark mismatched loads Performed full jtreg test on both x86_64 and aarch64 Linux. Newly added jtreg test fails without the patch and passes otherwise. OK to backport? Thanks, Felix [1]. AArch64 C2 JIT code without patch: 284 ;; B5: # N1 <- B9 B4 Freq: 1 285 286 ;; 0x42 287 0x0000ffff8d01e13c: mov w11, #0x42 // #66 288 0x0000ffff8d01e140: str xzr, [x19, #16] ;*invokestatic arraycopy 289 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14) 290 291 0x0000ffff8d01e144: str w11, [x14, #20] ;*iastore 292 ; - TestInitializingACLoadWithBadMem::test1 at 18 (line 11) 293 294 0x0000ffff8d01e148: str wzr, [x19, #20] <================ store wrong value 0 295 ;; 0x4 296 0x0000ffff8d01e14c: orr x2, xzr, #0x4 297 0x0000ffff8d01e150: add x1, x19, #0x18 298 0x0000ffff8d01e154: add x0, x14, #0x18 299 0x0000ffff8d01e158: bl Stub::arrayof_jlong_disjoint_arraycopy 300 ;*invokestatic arraycopy 301 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14) 302 ; {runtime_call} [2]. AArch64 C2 JIT code with patch: 284 ;; B5: # N1 <- B9 B4 Freq: 1 285 286 ;; 0x42 287 0x0000ffff9d01e03c: mov w11, #0x42 // #66 288 0x0000ffff9d01e040: str xzr, [x19, #16] ;*invokestatic arraycopy 289 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14) 290 291 0x0000ffff9d01e044: str w11, [x14, #20] ;*iastore 292 ; - TestInitializingACLoadWithBadMem::test1 at 18 (line 11) 293 294 0x0000ffff9d01e048: str w11, [x19, #20] <================ store correct value 0x42 295 ;; 0x4 296 0x0000ffff9d01e04c: orr x2, xzr, #0x4 297 0x0000ffff9d01e050: add x1, x19, #0x18 298 0x0000ffff9d01e054: add x0, x14, #0x18 299 0x0000ffff9d01e058: bl Stub::arrayof_jlong_disjoint_arraycopy 300 ;*invokestatic arraycopy 301 ; - TestInitializingACLoadWithBadMem::test1 at 25 (line 14) 302 ; {runtime_call} From aph at redhat.com Sat Apr 10 08:19:51 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 10 Apr 2021 09:19:51 +0100 Subject: [8u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: <51b0eb9c-a939-cc10-0063-ef6ece695a52@redhat.com> References: <51b0eb9c-a939-cc10-0063-ef6ece695a52@redhat.com> Message-ID: <54dd187b-63a3-9f56-c7f0-730719f1ed11@redhat.com> On 4/9/21 6:45 PM, Martin Balao wrote: > The original change makes perfect sense for 8u; I see nothing > 8u-specific since we have almost the same SunJSSE engine than in newer > releases. The change is fairly trivial, low risk and -as demonstrated- > generates a good performance benefit. OK, thanks. Good to go. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Mon Apr 12 01:13:13 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 12 Apr 2021 01:13:13 +0000 Subject: RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node Message-ID: <519bad68b5a842b5931c9e0341c0be7a@huawei.com> Hi, Original Bug: https://bugs.openjdk.java.net/browse/JDK-8247350 https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a9a275f22821 When running 8u jtreg hotspot test with -XX:+VerifyOops using aarch64 fastdebug build, I find this was triggered for more than 200 test cases. As discussed in [1], we should backport this for purposes like nightly testing. Patch for jdk11u does not apply cleanly due to conflict for the header file include in output.cpp. Webrev for 8u: http://cr.openjdk.java.net/~fyang/8247350-8u/webrev.00 Performed full jtreg test with -XX:+VerifyOops using aarch64 fastdebug build. OK to backport? Thanks, Felix [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013635.html From hedongbo at huawei.com Mon Apr 12 02:17:30 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Mon, 12 Apr 2021 10:17:30 +0800 Subject: [8u] RFR 8259886: Improve SSL session cache performance and scalability In-Reply-To: <54dd187b-63a3-9f56-c7f0-730719f1ed11@redhat.com> References: <51b0eb9c-a939-cc10-0063-ef6ece695a52@redhat.com> <54dd187b-63a3-9f56-c7f0-730719f1ed11@redhat.com> Message-ID: <8c0744f4-1242-d7a8-75b1-3613fbecf683@huawei.com> Martin, Andrew Haley. Thank you for review. Tagged. On 4/10/2021 4:19 PM, Andrew Haley wrote: > On 4/9/21 6:45 PM, Martin Balao wrote: >> The original change makes perfect sense for 8u; I see nothing >> 8u-specific since we have almost the same SunJSSE engine than in newer >> releases. The change is fairly trivial, low risk and -as demonstrated- >> generates a good performance benefit. > OK, thanks. Good to go. > -- thanks, hedongbo From aph at redhat.com Mon Apr 12 08:45:36 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Apr 2021 09:45:36 +0100 Subject: RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <519bad68b5a842b5931c9e0341c0be7a@huawei.com> References: <519bad68b5a842b5931c9e0341c0be7a@huawei.com> Message-ID: <983ccb77-0ea3-3284-ace2-5b6f8a4f1047@redhat.com> On 4/12/21 2:13 AM, Yangfei (Felix) wrote: > Performed full jtreg test with -XX:+VerifyOops using aarch64 fastdebug build. > OK to backport? Looks reasonable. -- 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 Apr 13 00:39:14 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 13 Apr 2021 00:39:14 +0000 Subject: RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach node In-Reply-To: <983ccb77-0ea3-3284-ace2-5b6f8a4f1047@redhat.com> References: <519bad68b5a842b5931c9e0341c0be7a@huawei.com> <983ccb77-0ea3-3284-ace2-5b6f8a4f1047@redhat.com> Message-ID: <6bc61a598bae4f038ac42c750df4a25e@huawei.com> Hi, Thanks for reviewing this fix. I have tagged this for approval. Felix > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Monday, April 12, 2021 4:46 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8247350: [aarch64] assert(false) failed: wrong size of mach > node > > On 4/12/21 2:13 AM, Yangfei (Felix) wrote: > > Performed full jtreg test with -XX:+VerifyOops using aarch64 fastdebug > build. > > OK to backport? > > Looks reasonable. > > -- > 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 Tue Apr 13 18:10:41 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 13 Apr 2021 14:10:41 -0400 Subject: [8u] RFR 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 Message-ID: I would like to backport this patch to 8u for parity with Oracle 8u301. The original bug: https://bugs.openjdk.java.net/browse/JDK-8073446 The original patch: https://github.com/openjdk/jdk/commit/7284f013 The original patch does not apply cleanly. Other than copyright year conflict in ZoneInfo.java, the new test uses new language feature "var" that is not supported in 8u, 8u patch changed them to their concrete types. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8073446-8u/webrev.00/ Test: passed new test. Thanks, -Zhengyu From mbalao at redhat.com Tue Apr 13 19:45:24 2021 From: mbalao at redhat.com (Martin Balao) Date: Tue, 13 Apr 2021 16:45:24 -0300 Subject: [8u] RFR 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Message-ID: <7bd9e5e6-a242-181f-c76a-f89fb27ee760@redhat.com> Hi, I'd like to request a review for the 8u backport of 8261355 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8261355/webrev.8261355.jdk8u.jdk.00/ Changes compared to 11u: * Paths changes to the pre-9 scheme * '/test/lib' library removed from EncryptionPadding test jtreg header. N/A for 8u. No regressions found in jdk/sun/security/pkcs11 test category. The new EncryptionPadding test passes. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 From hohensee at amazon.com Wed Apr 14 15:35:05 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 15:35:05 +0000 Subject: [8u] RFR 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Zhengyu Gu Date: Tuesday, April 13, 2021 at 11:11 AM To: jdk8u-dev Subject: [8u] RFR 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 I would like to backport this patch to 8u for parity with Oracle 8u301. The original bug: https://bugs.openjdk.java.net/browse/JDK-8073446 The original patch: https://github.com/openjdk/jdk/commit/7284f013 The original patch does not apply cleanly. Other than copyright year conflict in ZoneInfo.java, the new test uses new language feature "var" that is not supported in 8u, 8u patch changed them to their concrete types. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8073446-8u/webrev.00/ Test: passed new test. Thanks, -Zhengyu From zgu at redhat.com Wed Apr 14 15:40:10 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 14 Apr 2021 11:40:10 -0400 Subject: [8u] RFR 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 In-Reply-To: References: Message-ID: Thanks, Paul. Tagged for approval. -Zhengyu On 4/14/21 11:35 AM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Tuesday, April 13, 2021 at 11:11 AM > To: jdk8u-dev > Subject: [8u] RFR 8073446: TimeZone getOffset API does not return a dst offset between years 2038-2137 > > I would like to backport this patch to 8u for parity with Oracle 8u301. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8073446 > The original patch: https://github.com/openjdk/jdk/commit/7284f013 > > The original patch does not apply cleanly. Other than copyright year > conflict in ZoneInfo.java, the new test uses new language feature "var" > that is not supported in 8u, 8u patch changed them to their concrete types. > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8073446-8u/webrev.00/ > > Test: > passed new test. > > Thanks, > > -Zhengyu > > From hohensee at amazon.com Wed Apr 14 15:42:00 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 15:42:00 +0000 Subject: [8u] RFR 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Message-ID: <465E3F29-5941-4CFF-B9DA-DA7D4187C861@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Martin Balao Date: Tuesday, April 13, 2021 at 12:46 PM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding Hi, I'd like to request a review for the 8u backport of 8261355 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8261355/webrev.8261355.jdk8u.jdk.00/ Changes compared to 11u: * Paths changes to the pre-9 scheme * '/test/lib' library removed from EncryptionPadding test jtreg header. N/A for 8u. No regressions found in jdk/sun/security/pkcs11 test category. The new EncryptionPadding test passes. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8261355 From hohensee at amazon.com Wed Apr 14 17:39:53 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 17:39:53 +0000 Subject: [Ping] Re: RFR [1/3]: 8057038 Speculative traps not robust when compilation and class unloading are concurrent Message-ID: <841F7B73-D9DF-4DCD-AE45-282220DB6EB8@amazon.com> Lgtm. The other two are 8139247 and 8231501. The latter I reviewed for 8u, but isn't in 11u: there's a comment that says that 11u isn?t affected by it because 8215889 isn't in 11u. But, 8057038 also references 8215889. The latter hasn't been backported to either 8u or 11u, presumably because it fixes a concurrent class unloading issue in ZGC, and ZGC issues are being ignored in 11u. But, Shenandoah has/will have concurrent class unloading, which could very well end up in 11u, so imo both 8215889 and 8231501 should be backported to 11u as part of this series. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Peter Zhelezniakov Date: Tuesday, January 12, 2021 at 9:54 AM To: "jdk8u-dev at openjdk.java.net" Subject: [Ping] Re: RFR [1/3]: 8057038 Speculative traps not robust when compilation and class unloading are concurrent Any thoughts? On Dec 22 2020, at 3:14 pm, Peter Zhelezniakov wrote: > Hi, > > This is the first backport request in a series of 3: [1], [2], [3]. These fixes introduce atomicity and mutexes to Hotspot code. They help address crashes that occur in Apache Geode when running on a server with tens of CPU cores. > The patch from jdk9 did not apply as is, some contextual changes were needed. > This fix had a flaw that was later identified and fixed under [2]. Request for [2] is coming next in the series. > Testing: Hotspot JTreg tests. > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8057038 > Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8057038/8057038/ > > > Thanks! > Peter > > [1] https://bugs.openjdk.java.net/browse/JDK-8057038 > [2] https://bugs.openjdk.java.net/browse/JDK-8139247 > [3] https://bugs.openjdk.java.net/browse/JDK-8231501 From hohensee at amazon.com Wed Apr 14 17:43:39 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 17:43:39 +0000 Subject: RFR [2/3]: 8139247 Improper locking of MethodData::_extra_data_lock Message-ID: Lgtm, and see my comment on 8057038. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Peter Zhelezniakov Date: Tuesday, December 22, 2020 at 4:18 AM To: "jdk8u-dev at openjdk.java.net" Subject: RFR [2/3]: 8139247 Improper locking of MethodData::_extra_data_lock Hi, This is the second backport request in a series of 3: [1], [2], [3]. This fix corrects a flaw that was made in the fix for [1]. The patch from jdk9 did not apply as is. One small change was needed to introduce err_msg that was absent in jdk9 code base. Tested with Hotspot JTreg tests. JBS issue: https://bugs.openjdk.java.net/browse/JDK-8139247 Webrev: http://cr.openjdk.java.net/~avoitylov/peterz/8139247/8139247/ Thanks! Peter [1] https://bugs.openjdk.java.net/browse/JDK-8057038 [2] https://bugs.openjdk.java.net/browse/JDK-8139247 [3] https://bugs.openjdk.java.net/browse/JDK-8231501 From alvdavi at amazon.com Wed Apr 14 18:51:48 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 14 Apr 2021 11:51:48 -0700 Subject: RFR: 8u backport of JDK-8211301 [macos] support full window content options In-Reply-To: References: <6450b696-c7e6-4929-b071-4ff4658e45c5@www.fastmail.com> Message-ID: <0c192136-bd9c-3d1e-8efe-9cb3af354a7d@amazon.com> Hi, I want to mention we have faced a compilation error caused by this patch when building OpenJDK8 using Xcode 6.3.1 on OSX 10.10. The error seems to be cause by NSWindow contentView property being defined on that version of the ApplicationKit as an object of type id, instead of an NSView (even if the documentation stated contentView will always be an id). Newer versions of the AppKit will define the contentView of an NSWindow as an NSView object, so the issue will not appear. Apple's documentation for Cocoa Application Kit is no longer online, but I have found a mirror [1] that shows how NSWindow contentFrame was defined as such: contentView - (id)contentView Returns the receivers?s content view, the highest accessible NSView object in the receiver?s view hierarchy. This is compared with the current documentation [2]: @property(strong) __kindof NSView *contentView; We have fixed our builds by adding a cast to NSView, but I wanted to leave this here in case someone else faces the same issue. David -- [1] http://mirror.informatimago.com/next/developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSWindow.html#//apple_ref/doc/uid/20000013/contentView [2] https://developer.apple.com/documentation/appkit/nswindow/1419160-contentview?language=objc On 2/11/21 10:08 AM, Severin Gehwolf wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi, > > On Thu, 2021-02-11 at 16:55 +0100, Andreas Ahlenstorf wrote: >> Hi Severin, >> >> On Thu, Feb 11, 2021, at 10:39, Severin Gehwolf wrote: >> >>> The JDK 11 patch set the updated year to 2018, not 2021. Please keep >>> 2018. The reason for this is to keep code bases in sync as much as >>> possible. >> >> Thanks. Will fix. >> >>> What kind of testing have you done? >> >> jtreg on jdk/test/java/awt/Window. > > OK thanks, I can sponsor this for you. > > Cheers, > Severin > From alvdavi at amazon.com Wed Apr 14 19:23:00 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 14 Apr 2021 12:23:00 -0700 Subject: RFR: 8u backport of JDK-8211301 [macos] support full window content options In-Reply-To: <0c192136-bd9c-3d1e-8efe-9cb3af354a7d@amazon.com> References: <6450b696-c7e6-4929-b071-4ff4658e45c5@www.fastmail.com> <0c192136-bd9c-3d1e-8efe-9cb3af354a7d@amazon.com> Message-ID: <20b44cd5-df56-096c-1cad-006faa8a7621@amazon.com> Hi, I've created JDK-8265238 [1] to keep track of this David -- [1] https://bugs.openjdk.java.net/browse/JDK-8265238 On 4/14/21 11:51 AM, Alvarez, David wrote: > Hi, > > I want to mention we have faced a compilation error caused by this patch > when building OpenJDK8 using Xcode 6.3.1 on OSX 10.10. > > The error seems to be cause by NSWindow contentView property being > defined on that version of the ApplicationKit as an object of type id, > instead of an NSView (even if the documentation stated contentView will > always be an id). Newer versions of the AppKit will define the > contentView of an NSWindow as an NSView object, so the issue will not > appear. > > Apple's documentation for Cocoa Application Kit is no longer online, but > I have found a mirror [1] that shows how NSWindow contentFrame was > defined as such: > > contentView > - (id)contentView > Returns the receivers?s content view, the highest accessible NSView > object in the receiver?s view hierarchy. > > This is compared with the current documentation [2]: > @property(strong) __kindof NSView *contentView; > > We have fixed our builds by adding a cast to NSView, but I wanted to > leave this here in case someone else faces the same issue. > > David > > -- > [1] > http://mirror.informatimago.com/next/developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSWindow.html#//apple_ref/doc/uid/20000013/contentView > > [2] > https://developer.apple.com/documentation/appkit/nswindow/1419160-contentview?language=objc > > On 2/11/21 10:08 AM, Severin Gehwolf wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. >> >> >> >> Hi, >> >> On Thu, 2021-02-11 at 16:55 +0100, Andreas Ahlenstorf wrote: >>> Hi Severin, >>> >>> On Thu, Feb 11, 2021, at 10:39, Severin Gehwolf wrote: >>> >>>> The JDK 11 patch set the updated year to 2018, not 2021. Please keep >>>> 2018. The reason for this is to keep code bases in sync as much as >>>> possible. >>> >>> Thanks. Will fix. >>> >>>> What kind of testing have you done? >>> >>> jtreg on jdk/test/java/awt/Window. >> >> OK thanks, I can sponsor this for you. >> >> Cheers, >> Severin >> From hohensee at amazon.com Wed Apr 14 21:16:17 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 14 Apr 2021 21:16:17 +0000 Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Message-ID: <2DE9E34F-F706-4EA2-8BF3-368C3FADACC5@amazon.com> If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) { assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From shade at redhat.com Thu Apr 15 12:31:05 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Apr 2021 14:31:05 +0200 Subject: [8u] RFR (S) 8231949: [PPC64, s390]: Make async profiling more reliable Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8231949 https://hg.openjdk.java.net/jdk/jdk/rev/c6cbcc673cd3 We suspect this causes some of the real-world failures on 8u ppc64le, but there is no clear reproducer to see if it actually helps. So, this is somewhat of a blind backport. The 8u patch follows the same footsteps Martin did for 11u backport: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002137.html Namely, we are using the old style for these checks: - if (!Method::is_valid_method(m)) return false; - if (!Metaspace::contains(m->constMethod())) return false; + if (m == NULL || !m->is_valid_method()) return false; + if (!Metaspace::contains((const void*)m->constMethod())) return false; (I would suggest backporting JDK-8207779 that would introduce Method::is_valid_method in 8u, then we would rewrite this line back to upstream state). There are also no s390x parts, because that port is not available in 8u. 8u webrev: https://cr.openjdk.java.net/~shade/8231949/webrev.8u.01/ Testing: Linux ppc64le jdk_jfr (no new failures, no new passes) -- Thanks, -Aleksey From wattsun at tencent.com Thu Apr 15 12:36:46 2021 From: wattsun at tencent.com (=?utf-8?B?d2F0dHN1bijlrZnlrocp?=) Date: Thu, 15 Apr 2021 12:36:46 +0000 Subject: =?utf-8?B?5Zue5aSNOiBKREstODI1NzAzOTogTWVtb3J5IGFsbG9jYXRlZCBieSBHZW5l?= =?utf-8?B?cmljVGFza1F1ZXVlOjpfYXJyYXlfYWxsb2NhdG9yIG1heSBiZSBkb3VibGUg?= =?utf-8?Q?freed(Internet_mail)?= In-Reply-To: <2DE9E34F-F706-4EA2-8BF3-368C3FADACC5@amazon.com> References: <2DE9E34F-F706-4EA2-8BF3-368C3FADACC5@amazon.com> Message-ID: Thanks for your reply, Paul. make sense, both methods can eliminate the risk of double-free , and free the memory in ~ArrayAllocator is more reasonable. Update the patch: diff -r 91b61f678a19 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Sat Mar 27 19:01:26 2021 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Thu Apr 15 20:32:02 2021 +0800 @@ -430,9 +430,7 @@ } template -GenericTaskQueue::~GenericTaskQueue() { - FREE_C_HEAP_ARRAY(E, _elems, F); -} +GenericTaskQueue::~GenericTaskQueue() {} // OverflowTaskQueue is a TaskQueue that also includes an overflow stack for // elements that do not fit in the TaskQueue. Thanks wattsun -----????----- ???: Hohensee, Paul ????: 2021?4?15? 5:16 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) { assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From shade at redhat.com Thu Apr 15 15:24:33 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 15 Apr 2021 17:24:33 +0200 Subject: [8u] RFR (S) 8207779: Method::is_valid_method() compares 'this' with NULL Message-ID: Original bug: https://bugs.openjdk.java.net/browse/JDK-8207779 https://hg.openjdk.java.net/jdk/jdk/rev/b5aac518b097 I was looking at backporting this to 8u as the pre-requisite for JDK-8231949. I have suggested JDK-8231949 without this pre-requisite, which also matches how 11u backported without this fix. But, I think the fix is actually simple enough to backport and it dodges UB as a good bonus. The patch does not apply to 8u cleanly, and requires adjustments to fit the context differences. I grepped the source for is_valid_method to catch all other places where this needs to be adjusted. 8u webrev: https://cr.openjdk.java.net/~shade/8207779/webrev.8u.01 Testing: Linux x86_64 fastdebug, {tier1, jdk_jfr} -- Thanks, -Aleksey From thomas.stuefe at gmail.com Thu Apr 15 15:58:19 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 15 Apr 2021 17:58:19 +0200 Subject: [8u] RFR (S) 8231949: [PPC64, s390]: Make async profiling more reliable In-Reply-To: References: Message-ID: Looks fine to me. I am not sure whether the const void* cast was needed though. Cheers, Thomas On Thu, Apr 15, 2021 at 2:31 PM Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8231949 > https://hg.openjdk.java.net/jdk/jdk/rev/c6cbcc673cd3 > > We suspect this causes some of the real-world failures on 8u ppc64le, but > there is no clear > reproducer to see if it actually helps. So, this is somewhat of a blind > backport. > > The 8u patch follows the same footsteps Martin did for 11u backport: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002137.html > > Namely, we are using the old style for these checks: > > - if (!Method::is_valid_method(m)) return false; > - if (!Metaspace::contains(m->constMethod())) return false; > + if (m == NULL || !m->is_valid_method()) return false; > + if (!Metaspace::contains((const void*)m->constMethod())) return > false; > > (I would suggest backporting JDK-8207779 that would introduce > Method::is_valid_method in 8u, then we > would rewrite this line back to upstream state). > > There are also no s390x parts, because that port is not available in 8u. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8231949/webrev.8u.01/ > > Testing: Linux ppc64le jdk_jfr (no new failures, no new passes) > > -- > Thanks, > -Aleksey > > From hohensee at amazon.com Thu Apr 15 19:05:07 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 19:05:07 +0000 Subject: =?utf-8?B?UkU6IOWbnuWkjTogSkRLLTgyNTcwMzk6IE1lbW9yeSBhbGxvY2F0ZWQgYnkg?= =?utf-8?B?R2VuZXJpY1Rhc2tRdWV1ZTo6X2FycmF5X2FsbG9jYXRvciBtYXkgYmUgZG91?= =?utf-8?Q?ble_freed(Internet_mail)?= Message-ID: Lgtm. ?-----Original Message----- From: "wattsun(??)" Date: Thursday, April 15, 2021 at 5:37 AM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Thanks for your reply, Paul. make sense, both methods can eliminate the risk of double-free , and free the memory in ~ArrayAllocator is more reasonable. Update the patch: diff -r 91b61f678a19 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Sat Mar 27 19:01:26 2021 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Thu Apr 15 20:32:02 2021 +0800 @@ -430,9 +430,7 @@ } template -GenericTaskQueue::~GenericTaskQueue() { - FREE_C_HEAP_ARRAY(E, _elems, F); -} +GenericTaskQueue::~GenericTaskQueue() {} // OverflowTaskQueue is a TaskQueue that also includes an overflow stack for // elements that do not fit in the TaskQueue. Thanks wattsun -----????----- ???: Hohensee, Paul ????: 2021?4?15? 5:16 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) { assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From hohensee at amazon.com Thu Apr 15 19:49:19 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 15 Apr 2021 19:49:19 +0000 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Message-ID: This patch needs updating. E.g., the IOException catch code in SocketImpl.java is already in 8u. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Monday, January 4, 2021 at 2:11 PM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Hi, Please review the backport of JDK-8256818 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 Original change: https://github.com/openjdk/jdk/commit/93b6ab56 11u change: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 Some details on current 11u behaviour (also applicable to 8u): https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ Code change to SSLSocketImpl.java applies cleanly after path change. SSLSocketLeak.java test needs to be adapted for 8u: to get the number of process handles on Windows native lib is required; there is no support for building native test libs in 8u, because of this libFileUtils.c is placed into the same directory where test is; test is marked as "manual" and "native" and comment with details about shared lib is added to the test; test is adapted to load shared lib directly without going through FileUtils; changes to CheckHandles.java are not applicable to 8u, because corresponding change JDK-8239893 is not in 8u. Testing: checked that added test passes on Linux and Windows, ran jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . -- -Alex From akashche at redhat.com Thu Apr 15 22:17:42 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 15 Apr 2021 23:17:42 +0100 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: On 4/15/21, Hohensee, Paul wrote: > This patch needs updating. E.g., the IOException catch code in > SocketImpl.java is already in 8u. Thanks for your comments! I will revisit the patch and prepare the updated version shortly. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Alex > Kashchenko > Date: Monday, January 4, 2021 at 2:11 PM > To: "jdk8u-dev at openjdk.java.net" > Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks > socket resources > > Hi, > > Please review the backport of JDK-8256818 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 > > Original change: https://github.com/openjdk/jdk/commit/93b6ab56 > > 11u change: > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 > > Some details on current 11u behaviour (also applicable to 8u): > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ > > Code change to SSLSocketImpl.java applies cleanly after path change. > SSLSocketLeak.java test needs to be adapted for 8u: to get the number > of process handles on Windows native lib is required; there is no > support for building native test libs in 8u, because of this > libFileUtils.c is placed into the same directory where test is; test > is marked as "manual" and "native" and comment with details about > shared lib is added to the test; test is adapted to load shared lib > directly without going through FileUtils; changes to CheckHandles.java > are not applicable to 8u, because corresponding change JDK-8239893 is > not in 8u. > > Testing: checked that added test passes on Linux and Windows, ran > jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . > > -- > -Alex > > > -- -Alex From shade at redhat.com Fri Apr 16 08:21:10 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 16 Apr 2021 10:21:10 +0200 Subject: [8u] RFR (S) 8231949: [PPC64, s390]: Make async profiling more reliable In-Reply-To: References: Message-ID: <37ee03c1-ef31-df71-9c88-c19251719aaa@redhat.com> On 4/15/21 5:58 PM, Thomas St?fe wrote: > Looks fine to me. I am not sure whether the const void* cast was needed though. Me neither, but I would follow what 11u does. I marked this for approval. -- Thanks, -Aleksey From aph at redhat.com Sat Apr 17 11:05:36 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 17 Apr 2021 12:05:36 +0100 Subject: [8u] RFR (S) 8231949: [PPC64, s390]: Make async profiling more reliable In-Reply-To: <37ee03c1-ef31-df71-9c88-c19251719aaa@redhat.com> References: <37ee03c1-ef31-df71-9c88-c19251719aaa@redhat.com> Message-ID: <8625d1a6-c97d-e28f-e340-74a8a3b3c8db@redhat.com> On 4/16/21 9:21 AM, Aleksey Shipilev wrote: > On 4/15/21 5:58 PM, Thomas St?fe wrote: >> Looks fine to me. I am not sure whether the const void* cast was needed though. > > Me neither, but I would follow what 11u does. > > I marked this for approval. I guess the S/390 port was never ported to 8u? OK, but without a comment to that effect the Bug Report is a bit mysterious. -- 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 akozlov at azul.com Mon Apr 19 07:04:18 2021 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 19 Apr 2021 10:04:18 +0300 Subject: RFR: 8264640: CMS ParScanClosure misses a barrier Message-ID: <47805fc1-21df-cd17-a742-9f45ee8ecc72@azul.com> Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8264640 https://github.com/openjdk/jdk13u-dev/commit/efc81a3d Please review a backport of the fix for CMS. The issue originally manifested in 8u. Original patch applied almost cleanly, except adjustments for very minor context differences (obj->mark vs obj->mark_raw). 8u webrev: http://cr.openjdk.java.net/~akozlov/8264640/8.webrev/ Testing: x86_64 build, hotspot tier1 (2 test failures before and after this patch) Thanks, Anton From shade at redhat.com Mon Apr 19 12:46:38 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Apr 2021 14:46:38 +0200 Subject: [8u] RFR (XS) 8183910: gc/arguments/TestAggressiveHeap.java fails intermittently Message-ID: <2c20c140-4794-fb29-768e-f0c83cd30a56@redhat.com> Original test bug: https://bugs.openjdk.java.net/browse/JDK-8183910 https://hg.openjdk.java.net/jdk/jdk/rev/63f8bc358cca This test reliably fails for me in 8u on my large development machine: it reserves too much memory, which is not available with lots of concurrent tests. The patch does not apply to 8u due to context differences. I had to reapply both chunks by hand. 8u change is identical otherwise: diff -r 9da639b96992 test/gc/arguments/TestAggressiveHeap.java --- a/test/gc/arguments/TestAggressiveHeap.java Sun Nov 02 18:43:00 2014 +0300 +++ b/test/gc/arguments/TestAggressiveHeap.java Mon Apr 19 14:44:03 2021 +0200 @@ -49,17 +49,22 @@ private static final String option = "-XX:+AggressiveHeap"; // Option requires at least 256M, else error during option processing. private static final long minMemory = 256 * 1024 * 1024; + // Setting the heap to half of the physical memory is not suitable for + // a test environment with many tests running concurrently, setting to + // half of the required size instead. + private static final String heapSizeOption = "-Xmx128M"; + // bool UseParallelGC := true {product} private static final String parallelGCPattern = " *bool +UseParallelGC *:= *true +\\{product\\}"; private static void testFlag() throws Exception { ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( - option, "-XX:+PrintFlagsFinal", "-version"); + option, heapSizeOption, "-XX:+PrintFlagsFinal", "-version"); OutputAnalyzer output = new OutputAnalyzer(pb.start()); output.shouldHaveExitValue(0); Testing: affected test in tier1 (used to fail, now passes) -- Thanks, -Aleksey From shade at redhat.com Mon Apr 19 12:48:38 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Apr 2021 14:48:38 +0200 Subject: [8u] RFR (S) 8231949: [PPC64, s390]: Make async profiling more reliable In-Reply-To: <8625d1a6-c97d-e28f-e340-74a8a3b3c8db@redhat.com> References: <37ee03c1-ef31-df71-9c88-c19251719aaa@redhat.com> <8625d1a6-c97d-e28f-e340-74a8a3b3c8db@redhat.com> Message-ID: <1cb9418d-275d-cf5f-f195-0602eb81404f@redhat.com> On 4/17/21 1:05 PM, Andrew Haley wrote: > On 4/16/21 9:21 AM, Aleksey Shipilev wrote: >> On 4/15/21 5:58 PM, Thomas St?fe wrote: >>> Looks fine to me. I am not sure whether the const void* cast was needed though. >> >> Me neither, but I would follow what 11u does. >> >> I marked this for approval. > > I guess the S/390 port was never ported to 8u? OK, but without a > comment to that effect the Bug Report is a bit mysterious. Yeah, I mentioned this in RFR: "There are also no s390x parts, because that port is not available in 8u." I updated the Fix Request now. -- Thanks, -Aleksey From sgehwolf at redhat.com Mon Apr 19 13:16:02 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 19 Apr 2021 15:16:02 +0200 Subject: [8u] RFR (XS) 8183910: gc/arguments/TestAggressiveHeap.java fails intermittently In-Reply-To: <2c20c140-4794-fb29-768e-f0c83cd30a56@redhat.com> References: <2c20c140-4794-fb29-768e-f0c83cd30a56@redhat.com> Message-ID: <6a698aad7c76f307497b9adfeafbabfd7eafb0bc.camel@redhat.com> On Mon, 2021-04-19 at 14:46 +0200, Aleksey Shipilev wrote: > Original test bug: > ?? https://bugs.openjdk.java.net/browse/JDK-8183910 > ?? https://hg.openjdk.java.net/jdk/jdk/rev/63f8bc358cca > > This test reliably fails for me in 8u on my large development machine: it reserves too much memory, > which is not available with lots of concurrent tests. The patch does > not apply to 8u due to context differences. I had to reapply both chunks by hand. > > 8u change is identical otherwise: > > diff -r 9da639b96992 test/gc/arguments/TestAggressiveHeap.java > --- a/test/gc/arguments/TestAggressiveHeap.java Sun Nov 02 18:43:00 2014 +0300 > +++ b/test/gc/arguments/TestAggressiveHeap.java Mon Apr 19 14:44:03 2021 +0200 > @@ -49,17 +49,22 @@ > ????? private static final String option = "-XX:+AggressiveHeap"; > > ????? // Option requires at least 256M, else error during option processing. > ????? private static final long minMemory = 256 * 1024 * 1024; > > +??? // Setting the heap to half of the physical memory is not suitable for > +??? // a test environment with many tests running concurrently, setting to > +??? // half of the required size instead. > +??? private static final String heapSizeOption = "-Xmx128M"; > + > ????? // bool UseParallelGC := true {product} > ????? private static final String parallelGCPattern = > ????????? " *bool +UseParallelGC *:= *true +\\{product\\}"; > > ????? private static void testFlag() throws Exception { > ????????? ProcessBuilder pb = ProcessTools.createJavaProcessBuilder( > -??????????? option, "-XX:+PrintFlagsFinal", "-version"); > +??????????? option, heapSizeOption, "-XX:+PrintFlagsFinal", "-version"); > > ????????? OutputAnalyzer output = new OutputAnalyzer(pb.start()); > > ????????? output.shouldHaveExitValue(0); This looks fine. Thanks, Severin From felix.yang at huawei.com Mon Apr 19 13:16:36 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 19 Apr 2021 13:16:36 +0000 Subject: RFR: 8182036: Load from initializing arraycopy uses wrong memory state In-Reply-To: <61BDC9D1-0D1A-447F-9255-6C999005F47C@amazon.com> References: <61BDC9D1-0D1A-447F-9255-6C999005F47C@amazon.com> Message-ID: <41dfa34a91fb4bfcb495b513125ba19e@huawei.com> Hi, Thanks for looking at this. Could I have another review from some C2 experts please? Felix > -----Original Message----- > From: Hohensee, Paul [mailto:hohensee at amazon.com] > Sent: Saturday, April 10, 2021 7:17 AM > To: Yangfei (Felix) ; jdk8u-dev dev at openjdk.java.net> > Subject: RE: RFR: 8182036: Load from initializing arraycopy uses wrong > memory state > > Looks reasonable to me, but I'd be happier if a C2 engineer weighed in. > Roland? > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of "Yangfei > (Felix)" > Date: Sunday, March 28, 2021 at 8:13 PM > To: jdk8u-dev > Subject: RFR: 8182036: Load from initializing arraycopy uses wrong memory > state > > Hi, > > Please review this 8u backport fixing an user-visible C2 bug. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8182036 > Original patch: > http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/fe7fdd0fc266 > Original review thread: https://mail.openjdk.java.net/pipermail/hotspot- > compiler-dev/2017-June/026448.html > > Webrev for 8u: http://cr.openjdk.java.net/~fyang/8182036-8u/webrev.00 > > This bug can always reproduced by running the provided test case with 8u on > x86_64 or aarch64 linux. > The AArch64 C2 JIT code snippet with & without the fix is shown here [1] [2]. > > I think we only needs this part for 8u (quotation from the original review > thread): > " > Initialization of dst is performed by the arraycopy. > PhaseMacroExpand::generate_block_arraycopy() generates a load/store > pair to copy the element at offset 1 so it can bulk copy the elements starting > at offset 2. Both the load and store are on the same slice which for an > initializing arraycopy is raw memory. So the src[1] load and the src[1] = 0x42 > store are not on the same slice and the load can happen before the store > resulting in an incorrect execution. > > The fix I propose is for the load to be from the src's slice. > " > > The rest of the original fix is not needed for 8u as it's related to the following > two issues which is not there in 8u: > 8076188: Optimize arraycopy out for non escaping destination > 8150933: System::arraycopy intrinsic doesn't mark mismatched loads > > Performed full jtreg test on both x86_64 and aarch64 Linux. > Newly added jtreg test fails without the patch and passes otherwise. > OK to backport? > > Thanks, > Felix > > [1]. AArch64 C2 JIT code without patch: > > 284 ;; B5: # N1 <- B9 B4 Freq: 1 > 285 > 286 ;; 0x42 > 287 0x0000ffff8d01e13c: mov w11, #0x42 // #66 > 288 0x0000ffff8d01e140: str xzr, [x19, #16] ;*invokestatic arraycopy > 289 ; - TestInitializingACLoadWithBadMem::test1 at 25 > (line 14) > 290 > 291 0x0000ffff8d01e144: str w11, [x14, #20] ;*iastore > 292 ; - TestInitializingACLoadWithBadMem::test1 at 18 > (line 11) > 293 > 294 0x0000ffff8d01e148: str wzr, [x19, #20] <================ > store wrong value 0 > 295 ;; 0x4 > 296 0x0000ffff8d01e14c: orr x2, xzr, #0x4 > 297 0x0000ffff8d01e150: add x1, x19, #0x18 > 298 0x0000ffff8d01e154: add x0, x14, #0x18 > 299 0x0000ffff8d01e158: bl Stub::arrayof_jlong_disjoint_arraycopy > 300 ;*invokestatic arraycopy > 301 ; - TestInitializingACLoadWithBadMem::test1 at 25 > (line 14) > 302 ; {runtime_call} > > [2]. AArch64 C2 JIT code with patch: > > 284 ;; B5: # N1 <- B9 B4 Freq: 1 > 285 > 286 ;; 0x42 > 287 0x0000ffff9d01e03c: mov w11, #0x42 // #66 > 288 0x0000ffff9d01e040: str xzr, [x19, #16] ;*invokestatic arraycopy > 289 ; - TestInitializingACLoadWithBadMem::test1 at 25 > (line 14) > 290 > 291 0x0000ffff9d01e044: str w11, [x14, #20] ;*iastore > 292 ; - TestInitializingACLoadWithBadMem::test1 at 18 > (line 11) > 293 > 294 0x0000ffff9d01e048: str w11, [x19, #20] <================ > store correct value 0x42 > 295 ;; 0x4 > 296 0x0000ffff9d01e04c: orr x2, xzr, #0x4 > 297 0x0000ffff9d01e050: add x1, x19, #0x18 > 298 0x0000ffff9d01e054: add x0, x14, #0x18 > 299 0x0000ffff9d01e058: bl Stub::arrayof_jlong_disjoint_arraycopy > 300 ;*invokestatic arraycopy > 301 ; - TestInitializingACLoadWithBadMem::test1 at 25 > (line 14) > 302 ; {runtime_call} > > From shade at redhat.com Mon Apr 19 14:09:07 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Apr 2021 16:09:07 +0200 Subject: [8u] RFR (XS) 8183910: gc/arguments/TestAggressiveHeap.java fails intermittently In-Reply-To: <6a698aad7c76f307497b9adfeafbabfd7eafb0bc.camel@redhat.com> References: <2c20c140-4794-fb29-768e-f0c83cd30a56@redhat.com> <6a698aad7c76f307497b9adfeafbabfd7eafb0bc.camel@redhat.com> Message-ID: On 4/19/21 3:16 PM, Severin Gehwolf wrote: > This looks fine. Thanks, tagged for approval. -- Thanks, -Aleksey From shade at redhat.com Mon Apr 19 14:23:08 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 19 Apr 2021 16:23:08 +0200 Subject: [8u] RFR (XS) 8255734: VM should ignore SIGXFSZ on ppc64, s390 too Message-ID: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8255734 https://github.com/openjdk/jdk/commit/54c88132 The patch does not apply cleanly to 8u, because s390x port is not available in 8u, and there is enough context changes (mostly due to JDK-8252324) to fail the automatic patch. 8u variant: diff -r 7ab0ec535776 src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp --- a/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Thu Oct 24 16:28:51 2019 +0200 +++ b/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Mon Apr 19 10:54:12 2021 +0200 @@ -178,7 +178,7 @@ // avoid unnecessary crash when libjsig is not preloaded, try handle signals // that do not require siginfo/ucontext first. - if (sig == SIGPIPE) { + if (sig == SIGPIPE || sig == SIGXFSZ) { if (os::Aix::chained_handler(sig, info, ucVoid)) { return 1; } else { diff -r 7ab0ec535776 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Thu Oct 24 16:28:51 2019 +0200 +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Mon Apr 19 10:54:12 2021 +0200 @@ -185,7 +185,7 @@ // avoid unnecessary crash when libjsig is not preloaded, try handle signals // that do not require siginfo/ucontext first. - if (sig == SIGPIPE) { + if (sig == SIGPIPE || sig == SIGXFSZ) { if (os::Linux::chained_handler(sig, info, ucVoid)) { return true; } else { Reproducer before patch: $ build/linux-ppc64le-normal-server-fastdebug/images/j2sdk-image/bin/java Test # # A fatal error has been detected by the Java Runtime Environment: # # SIGXFSZ (0x19) at pc=0x00003fff953a3348, pid=80212, tid=0x00003fff93b8f1b0 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-shade_2021_04_13_10_40-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-ppc64le compressed oops) # Problematic frame: # C [libpthread.so.0+0x13348] write+0x98 Reproducer after patch: $ build/linux-ppc64le-normal-server-fastdebug/images/j2sdk-image/bin/java Test java.io.IOException: File too large at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:313) at Test.main(Test.java:7) Done Testing: ppc64le build, reproducer from JDK-8255734 -- Thanks, -Aleksey From zgu at redhat.com Tue Apr 20 02:01:08 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 19 Apr 2021 22:01:08 -0400 Subject: [8u] RFR 8177809: File.lastModified() is losing milliseconds (always ends in 000) Message-ID: <1c9c1639-ebc2-1dcc-fa71-7d228037887c@redhat.com> I would like to backport this patch to 8u for parity with Oracle 8u301. The original bug: https://bugs.openjdk.java.net/browse/JDK-8177809 The original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/8e2030e03a61 The original patch does not apply cleanly. The only conflict was copyright year line of UnixFileSystem_md.c 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8177809-8u/webrev.00/ Test: Passed test in patch. Thanks, -Zhengyu From shade at redhat.com Tue Apr 20 08:32:16 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 10:32:16 +0200 Subject: [8u] RFR 8177809: File.lastModified() is losing milliseconds (always ends in 000) In-Reply-To: <1c9c1639-ebc2-1dcc-fa71-7d228037887c@redhat.com> References: <1c9c1639-ebc2-1dcc-fa71-7d228037887c@redhat.com> Message-ID: <8665adbf-770a-f024-8251-1f6d6829dd7d@redhat.com> On 4/20/21 4:01 AM, Zhengyu Gu wrote: > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8177809-8u/webrev.00/ This looks good. -- Thanks, -Aleksey From shade at redhat.com Tue Apr 20 09:02:46 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 11:02:46 +0200 Subject: [8u] RFR (XS) 8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME Message-ID: <8dbe987f-a8ab-334c-cdb3-fb1bd7b01ef7@redhat.com> Original test bug: https://bugs.openjdk.java.net/browse/JDK-8166046 https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d288db38d1aa This is a part of larger effort to improve JDK 8 testing. This patch is very simple, yet it does not apply cleanly, because "8132919: Put compiler tests in packages" is missing. 8u patch is otherwise the same: diff -r b4de82aff831 test/compiler/stringopts/TestStringObjectInitialization.java --- a/test/compiler/stringopts/TestStringObjectInitialization.java Wed Dec 10 13:58:30 2014 +0000 +++ b/test/compiler/stringopts/TestStringObjectInitialization.java Tue Apr 20 10:59:56 2021 +0200 @@ -57,10 +57,15 @@ public void run(String s, String[] sArray) { // Trigger C2's string concatenation optimization add(s + Arrays.toString(sArray) + " const "); } + + public void reset() { + // Reset string to avoid OOMEs + myString = ""; + } } class Runner implements Runnable { private TestStringObjectInitialization test; @@ -68,11 +73,12 @@ test = t; } public void run(){ String[] array = {"a", "b", "c"}; - for (int i = 0; i < 10000; ++i) { + for (int i = 0; i < 100_000; ++i) { test.run("a", array); + test.reset(); } } } Testing: tier1 -- Thanks, -Aleksey From sgehwolf at redhat.com Tue Apr 20 10:23:49 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 20 Apr 2021 12:23:49 +0200 Subject: [8u] RFR: 8206925: Support the certificate_authorities extension Message-ID: Hi, Please review this OpenJDK 8u backport of the certificate_authorities extensionj. The OpenJDK 11u patch didn't apply cleanly after path unshuffeling, but was fairly trivial to resolve. Conflicts caused by: 1. X509Authentication.java copyright line conflict only. Resolved manually. 2. SSLContextTemplate.java private interface methods not allowed in JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to default. Note: this is code used in tests only. 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the test invocations since JDK 8u doesn't enable TLSv1.3 on the client side by default. See JDK-8248721, CSR of the TLSv1.3 8u backport. Other than that, the patch is identical to the OpenJDK 11.0.12 version of this patch. This introduces a new system property, jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has been reused from the Oracle JDK backport. See below. Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 CSR: https://bugs.openjdk.java.net/browse/JDK-8248709 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/ Testing: sun/security/ssl tests and tier1. No new regressions. New tests pass. Thoughts? Thanks, Severin From shade at redhat.com Tue Apr 20 12:58:56 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 14:58:56 +0200 Subject: [8u] RFR (XS) 8260484: CheckExamples.java / NoJavaLangTest.java fail with jtreg 4.2 Message-ID: <0ff4409b-58ef-03a8-ad7a-400aff2af700@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8260484 There is no changeset available for it, Oracle-private fix. But, the report mentions it is fixed in JDK 9+, and I have successfully adapted these two fixes from JDK 9+: https://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/4012b3f11f0d#l20.1 8u webrev: https://cr.openjdk.java.net/~shade/8260484/webrev.8u.01/ Testing: langtools_tier1 (tests are now passing, except the remaining 8u regression: JDK-8265527) -- Thanks, -Aleksey From sgehwolf at redhat.com Tue Apr 20 14:03:40 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 20 Apr 2021 16:03:40 +0200 Subject: [8u] RFR (XS) 8260484: CheckExamples.java / NoJavaLangTest.java fail with jtreg 4.2 In-Reply-To: <0ff4409b-58ef-03a8-ad7a-400aff2af700@redhat.com> References: <0ff4409b-58ef-03a8-ad7a-400aff2af700@redhat.com> Message-ID: <781b67dedb3d52a121b12ea17fe70dd80320ed7e.camel@redhat.com> On Tue, 2021-04-20 at 14:58 +0200, Aleksey Shipilev wrote: > Original bug: > ?? https://bugs.openjdk.java.net/browse/JDK-8260484 > > There is no changeset available for it, Oracle-private fix. But, the > report mentions it is fixed in > JDK 9+, and I have successfully adapted these two fixes from JDK 9+: > ?? > https://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/4012b3f11f0d#l20.1 > > 8u webrev: > ?? https://cr.openjdk.java.net/~shade/8260484/webrev.8u.01/ > > Testing: langtools_tier1 (tests are now passing, except the remaining > 8u regression: JDK-8265527) This is fine. Thanks for fixing it! Cheers, Severin From shade at redhat.com Tue Apr 20 15:53:27 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Apr 2021 17:53:27 +0200 Subject: [8u] RFR (XS) 8260484: CheckExamples.java / NoJavaLangTest.java fail with jtreg 4.2 In-Reply-To: <781b67dedb3d52a121b12ea17fe70dd80320ed7e.camel@redhat.com> References: <0ff4409b-58ef-03a8-ad7a-400aff2af700@redhat.com> <781b67dedb3d52a121b12ea17fe70dd80320ed7e.camel@redhat.com> Message-ID: On 4/20/21 4:03 PM, Severin Gehwolf wrote: > This is fine. Thanks for fixing it! Thanks, I marked it for 8u approval. -- Thanks, -Aleksey From akashche at redhat.com Tue Apr 20 19:52:17 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 20 Apr 2021 20:52:17 +0100 Subject: [8u] RFR: 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 Message-ID: Hi, Please review the backport of JDK-8257997 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8257997 Original changeset: https://github.com/openjdk/jdk/commit/29ffffa7 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/webrev.00/ 8u exported commit: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/8257997_8u.changeset This change is a follow-up to JDK-8256818 8u backport [1] and needs to be applied on top of it. Note 1, webrev was generated with "-r" flag, that doesn't include commit metadata, so there is a separate exported commit link above. Note 2, in mainline jdk there were two more changes between JDK-8256818 and JDK-8257997: JDK-8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks [2] JDK-8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test [3] These changes are included into the proposed backport. JDK-8257670 (switch the test from "othervm" to "manual") won't apply to 8u, because JDK-8256818 requires native lib and was already marked as "manual". And JDK-8257884 changes the same lines as the proposed fix. Testing: checked that changed test passes on Windows and Linux. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013660.html [2] https://bugs.openjdk.java.net/browse/JDK-8257670 [3] https://bugs.openjdk.java.net/browse/JDK-8257884 -- -Alex From akashche at redhat.com Tue Apr 20 19:56:43 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 20 Apr 2021 20:56:43 +0100 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: Hi, On 4/15/21, Alex Kashchenko wrote: > On 4/15/21, Hohensee, Paul wrote: >> This patch needs updating. E.g., the IOException catch code in >> SocketImpl.java is already in 8u. > > Thanks for your comments! I will revisit the patch and prepare the > updated version shortly. I've re-checked that the patch can be applied to the latest 8u-dev, it appeared that recent IOException changes do not overlap with it. In mainline this patch required 3 follow-up commits with minor fixes to the test. I've combined these patches into one 8u backport and posted it for review here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013678.html I think it will make sense to push this backport together with the follow-up one. > >> >> Thanks, >> Paul >> >> ?-----Original Message----- >> From: jdk8u-dev on behalf of Alex >> Kashchenko >> Date: Monday, January 4, 2021 at 2:11 PM >> To: "jdk8u-dev at openjdk.java.net" >> Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected >> leaks >> socket resources >> >> Hi, >> >> Please review the backport of JDK-8256818 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 >> >> Original change: https://github.com/openjdk/jdk/commit/93b6ab56 >> >> 11u change: >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 >> >> Some details on current 11u behaviour (also applicable to 8u): >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ >> >> Code change to SSLSocketImpl.java applies cleanly after path change. >> SSLSocketLeak.java test needs to be adapted for 8u: to get the number >> of process handles on Windows native lib is required; there is no >> support for building native test libs in 8u, because of this >> libFileUtils.c is placed into the same directory where test is; test >> is marked as "manual" and "native" and comment with details about >> shared lib is added to the test; test is adapted to load shared lib >> directly without going through FileUtils; changes to CheckHandles.java >> are not applicable to 8u, because corresponding change JDK-8239893 is >> not in 8u. >> >> Testing: checked that added test passes on Linux and Windows, ran >> jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . >> >> -- >> -Alex >> >> >> > > > -- > -Alex > -- -Alex From gnu.andrew at redhat.com Wed Apr 21 05:14:22 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 21 Apr 2021 06:14:22 +0100 Subject: OpenJDK 8u292 Released Message-ID: <20210421051422.GA483014@rincewind> We are pleased to announce the release of OpenJDK 8u292. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u292-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u292-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: 9008c700c699739e185ee5b1b4554b769a81492f9b3358634cd693ce75668b3f openjdk8u292-ga.tar.xz 3d9f770da61ea72ba43a3ccde1a72d14e40bf6bc3ea7cba947617a9434d2c988 openjdk8u292-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u292-ga.sha256 New in release OpenJDK 8u292 (2021-04-20): =========================================== Live versions of these release notes can be found at: * https://bitly.com/openjdk8u292 * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u292.txt * Security fixes - JDK-8227467: Better class method invocations - JDK-8244473: Contextualize registration for JNDI - JDK-8244543: Enhanced handling of abstract classes - JDK-8249906, CVE-2021-2163: Enhance opening JARs - JDK-8250568, CVE-2021-2161: Less ambiguous processing - JDK-8253799: Make lists of normal filenames * Other changes - JDK-6345095: regression test EmptyClipRenderingTest fails - JDK-6896810: TEST_BUG: java/lang/ref/SoftReference/Pin.java fails with OOME during System.out.println - JDK-6949753: [TEST BUG]: java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop - JDK-7009641: Don't fail VM when CodeCache is full - JDK-7107012: sun.jvm.hotspot.code.CompressedReadStream readDouble() conversion to long mishandled - JDK-7112454: TEST_BUG: java/awt/Choice/PopdownGeneratesMouseEvents/PopdownGeneratesMouseEvents.html failed - JDK-7131835: [TEST_BUG] Test does not consider that the rounded edges of the window in Mac OS 10.7 - JDK-7185221: [macosx] Regtest should not throw exception if a suitable display mode found - JDK-8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently - JDK-8035166: Remove dependency on EC classes from pkcs11 provider - JDK-8035186: j2se_jdk/jdk/test/java/lang/invoke/lambda/LogGeneratedClassesTest.java - assertion error - JDK-8038723: Openup some PrinterJob tests - JDK-8041464: [TEST_BUG] CustomClassLoaderTransferTest does not support OS X - JDK-8041561: Inconsistent opacity behaviour between JCheckBox and JRadioButton - JDK-8061777: (zipfs) IllegalArgumentException in ZipCoder.toString when using Shitft_JIS - JDK-8073108: [AArch64] Use x86 and SPARC CPU instructions for GHASH acceleration - JDK-8078024: javac, several incorporation steps are silently failing when an error should be reported - JDK-8078450: Implement consistent process for quarantine of tests - JDK-8078614: WindowsClassicLookAndFeel MetalComboBoxUI.getbaseLine fails with IllegalArgumentException - JDK-8080953: [TEST_BUG]Test java/awt/FontClass/DebugFonts.java fails due to wrongly typed bugid - JDK-8081547: Prepare client libs regression tests for running in a concurrent, headless jtreg environment - JDK-8129626: G1: set_in_progress() and clear_started() needs a barrier on non-TSO platforms - JDK-8141457: keytool default cert fingerprint algorithm should be SHA-256 - JDK-8130309: Need to bailout cleanly if creation of stubs fails when codecache is out of space (AArch64 changes) - JDK-8131779: AARCH64: add Montgomery multiply intrinsic - JDK-8132875: AArch64: Fix error introduced into AArch64 CodeCache by commit for 8130309 - JDK-8135018: AARCH64: Missing memory barriers for CMS collector - JDK-8145051: Wrong parameter name in synthetic lambda method leads to verifier error - JDK-8150204: (fs) Enhance java/nio/file/Files/probeContentType/Basic.java debugging output - JDK-8145320: Create unsafe_arraycopy and generic_arraycopy for AArch64 - JDK-8148328: aarch64: redundant lsr instructions in stub code. - JDK-8148783: aarch64: SEGV running SpecJBB2013 - JDK-8148948: aarch64: generate_copy_longs calls align() incorrectly - JDK-8149080: AArch64: Recognise disjoint array copy in stub code - JDK-8149365: aarch64: memory copy does not prefetch on backwards copy - JDK-8149907: aarch64: use load/store pair instructions in call_stub - JDK-8150038: aarch64: make use of CBZ and CBNZ when comparing narrow pointer with zero - JDK-8150045: arraycopy causes segfaults in SATB during garbage collection - JDK-8150082: aarch64: optimise small array copy - JDK-8150229: aarch64: pipeline class for several instructions is not set correctly - JDK-8150313: aarch64: optimise array copy using SIMD instructions - JDK-8150394: aarch64: add support for 8.1 LSE CAS instructions - JDK-8150652: Remove unused code in AArch64 back end - JDK-8151340: aarch64: prefetch the destination word for write prior to ldxr/stxr loops. - JDK-8151502: optimize pd_disjoint_words and pd_conjoint_words - JDK-8151775: aarch64: add support for 8.1 LSE atomic operations - JDK-8152537: aarch64: Make use of CBZ and CBNZ when comparing unsigned values with zero. - JDK-8152840: aarch64: improve _unsafe_arraycopy stub routine - JDK-8153172: aarch64: hotspot crashes after the 8.1 LSE patch is merged - JDK-8153713: aarch64: improve short array clearing using store pair - JDK-8153797: aarch64: Add Arrays.fill stub code - JDK-8154413: AArch64: Better byte behaviour - JDK-8154537: AArch64: some integer rotate instructions are never emitted - JDK-8154739: AArch64: TemplateTable::fast_xaccess loads in wrong mode - JDK-8155015: Aarch64: bad assert in spill generation code - JDK-8155100: AArch64: Relax alignment requirement for byte_map_base - JDK-8155612: Aarch64: vector nodes need to support misaligned offset - JDK-8155617: aarch64: ClearArray does not use DC ZVA - JDK-8155627: Enable SA on AArch64 - JDK-8155653: TestVectorUnalignedOffset.java not pushed with 8155612 - JDK-8156731: aarch64: java/util/Arrays/Correct.java fails due to _generic_arraycopy stub routine - JDK-8157841: aarch64: prefetch ignores cache line size - JDK-8157906: aarch64: some more integer rotate instructions are never emitted - JDK-8158525: Update a few java/net tests to use the loopback address instead of the host address - JDK-8160217: JavaSound should clean up resources better - JDK-8158913: aarch64: SEGV running Spark terasort - JDK-8159052: aarch64: optimise unaligned copies in pd_disjoint_words and pd_conjoint_words - JDK-8159063: aarch64: optimise unaligned array copy long - JDK-8160748: [AArch64] Inconsistent types for ideal_reg - JDK-8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure - JDK-8161190: AArch64: Fix overflow in immediate cmp instruction - JDK-8163363: AArch64: Stack size in tools/launcher/Settings.java needs to be adjusted - JDK-8164113: AArch64: follow-up the fix for 8161598 - JDK-8165673: AArch64: Fix JNI floating point argument handling - JDK-8167200: AArch64: Broken stack pointer adjustment in interpreter - JDK-8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods - JDK-8167421: AArch64: in one core system, fatal error: Illegal threadstate encountered - JDK-8167595: AArch64: SEGV in stub code cipherBlockChaining_decryptAESCrypt - JDK-8168699: Validate special case invocations [AArch64 support] - JDK-8168888: Port 8160591: Improve internal array handling to AArch64. - JDK-8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node - JDK-8170100: AArch64: Crash in C1-compiled code accessing References - JDK-8170188: jtreg test compiler/types/TestMeetIncompatibleInterfaceArrays.java causes JVM crash - JDK-8170873: PPC64/aarch64: Poor StrictMath performance due to non-optimized compilation - JDK-8171410: aarch64: long multiplyExact shifts by 31 instead of 63 - JDK-8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 - JDK-8172404: Tools should warn if weak algorithms are used before restricting them - JDK-8172881: AArch64: assertion failure: the int pressure is incorrect - JDK-8173472: AArch64: C1 comparisons with null only use 32-bit instructions - JDK-8176100: [AArch64] [REDO][REDO] G1 Needs pre barrier on dereference of weak JNI handles - JDK-8177661: Correct ad rule output register types from iRegX to iRegXNoSp - JDK-8179954: AArch64: C1 and C2 volatile accesses are not sequentially consistent - JDK-8182581: aarch64: fix for crash caused by earlyret of compiled method - JDK-8183925: [AArch64] Decouple crash protection from watcher thread - JDK-8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" - JDK-8186090: java.nio.Bits.unaligned() doesn't handle aarch64 - JDK-8186325: AArch64: jtreg test hotspot/test/gc/g1/TestJNIWeakG1/TestJNIWeakG1.java SEGV - JDK-8187224: aarch64: some inconsistency between aarch64_ad.m4 and aarch64.ad - JDK-8189170: [AArch64] Add option to disable stack overflow checking in primordial thread for use with JNI_CreateJavaJVM - JDK-8191915: JCK tests produce incorrect results with C2 - JDK-8193133: Assertion failure because 0xDEADDEAD can be in-heap - JDK-8195685: AArch64 port of 8174962: Better interface invocations - JDK-8195859: AArch64: vtableStubs gtest fails after 8174962 - JDK-8196136: AArch64: Correct register use in patch for JDK-8194686 - JDK-8196221: AArch64: Mistake in committed patch for JDK-8195859 - JDK-8198334: java/awt/FileDialog/8003399/bug8003399.java fails in headless mode - JDK-8199712: [AArch64] Flight Recorder - JDK-8202343: Disable TLS 1.0 and 1.1 - JDK-8203481: Incorrect constraint for unextended_sp in frame:safe_for_sender - JDK-8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 - JDK-8205421: AARCH64: StubCodeMark should be placed after alignment - JDK-8206163: AArch64: incorrect code generation for StoreCM - JDK-8207345: Trampoline generation code reads from uninitialized memory - JDK-8207838: AArch64: Float registers incorrectly restored in JNI call - JDK-8209333: Socket reset issue for TLS 1.3 socket close - JDK-8209413: AArch64: NPE in clhsdb jstack command - JDK-8209414: [AArch64] method handle invocation does not respect JVMTI interp_only mode - JDK-8209415: Fix JVMTI test failure HS202 - JDK-8209420: Track membars for volatile accesses so they can be properly optimized - JDK-8209835: Aarch64: elide barriers on all volatile operations - JDK-8210425: [AArch64] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization - JDK-8211064: [AArch64] Interpreter and c1 don't correctly handle jboolean results in native calls - JDK-8211233: MemBarNode::trailing_membar() and MemBarNode::leading_membar() need to handle dying subgraphs better - JDK-8211301: [macos] support full window content options - JDK-8211339: NPE during SSL handshake caused by HostnameChecker - JDK-8213134: AArch64: vector shift failed with MaxVectorSize=8 - JDK-8213419: [AArch64] C2 may hang in MulLNode::Ideal()/MulINode::Ideal() with gcc 8.2.1 - JDK-8214857: "bad trailing membar" assert failure at memnode.cpp:3220 - JDK-8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults - JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 - JDK-8216350: AArch64: monitor unlock fast path not called - JDK-8216987: ciMethodData::load_data() unpacks MDOs with non-atomic copy - JDK-8217338: [Containers] Improve systemd slice memory limit support - JDK-8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 - JDK-8217368: AArch64: C2 recursive stack locking optimisation not triggered - JDK-8218185: aarch64: missing LoadStore barrier in TemplateTable::putfield_or_static - JDK-8219011: Implement MacroAssembler::warn method on AArch64 - JDK-8219635: aarch64: missing LoadStore barrier in TemplateTable::fast_storefield - JDK-8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl - JDK-8221408: Windows 32bit build build errors/warnings in hotspot - JDK-8221220: AArch64: Add StoreStore membar explicitly for Volatile Writes in TemplateTable - JDK-8221658: aarch64: add necessary predicate for ubfx patterns - JDK-8223186: HotSpot compile warnings from GCC 9 - JDK-8224671: AArch64: mauve System.arraycopy test failure - JDK-8224828: aarch64: rflags is not correct after safepoint poll - JDK-8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 - JDK-8224880: AArch64: java/javac error with AllocatePrefetchDistance - JDK-8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14 - JDK-8225805: Java Access Bridge does not close the logger - JDK-8226899: Problemlist compiler/rtm tests - JDK-8227642: [TESTBUG] Make docker tests podman compatible - JDK-8228434: jdk/net/Sockets/Test.java fails after JDK-8227642 - JDK-8228400: Remove built-in AArch64 simulator - JDK-8228406: Superfluous change in chaitin.hpp - JDK-8228593: Revert explicit JDK 7 support additions - JDK-8228716: Revert InstanceKlass::print_on debug additions - JDK-8228718: Revert incorrect backport of JDK-8129757 to 8-aarch64 - JDK-8228725: AArch64: Purge method call format support - JDK-8228747: Revert "unused" attribute from test_arraycopy_func - JDK-8228767: Revert ResourceMark additions - JDK-8228770: Revert development hsdis changes - JDK-8229123: Revert build fixes for aarch64/zero - JDK-8229124: Revert disassembler.cpp changes - JDK-8229145: Revert TemplateTable::bytecode() visibility change - JDK-8229284: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage - JDK-8230388: Problemlist additional compiler/rtm tests - JDK-8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR - JDK-8233839: aarch64: missing memory barrier in NewObjectArrayStub and NewTypeArrayStub - JDK-8234727: sun/security/ssl/X509TrustManagerImpl tests support TLSv1.3 - JDK-8234728: Some security tests should support TLSv1.3 - JDK-8235263: Revert TLS 1.3 change that wrapped IOExceptions - JDK-8235311: Tag mismatch may alert bad_record_mac - JDK-8235874: The ordering of Cipher Suites is not maintained provided through jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system property. - JDK-8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory - JDK-8237512: AArch64: aarch64TestHook leaks a BufferBlob - JDK-8238579: HttpsURLConnection drops the timeout and hangs forever in read - JDK-8239091: Reversed arguments in call to strstr in freetype "debug" code. - JDK-8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 - JDK-8240827: Downport SSLSocketImpl.java from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE" - JDK-8242141: New System Properties to configure the TLS signature schemes - JDK-8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11 - JDK-8246482: Build failures with +JFR -PCH - JDK-8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg - JDK-8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield - JDK-8248336: AArch64: C2: offset overflow in BoxLockNode::emit - JDK-8249183: JVM crash in "AwtFrame::WmSize" method - JDK-8249251: [dark_mode ubuntu 20.04] The selected menu is not highlighted in GTKLookAndFeel - JDK-8249588: libwindowsaccessbridge issues on 64bit Windows - JDK-8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets - JDK-8250984: Memory Docker tests fail on some Linux kernels w/o cgroupv1 swap limit capabilities - JDK-8251397: NPE on ClassValue.ClassValueMap.cacheArray - JDK-8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows - JDK-8253368: TLS connection always receives close_notify exception - JDK-8253476: TestUseContainerSupport.java fails on some Linux kernels w/o swap limit capabilities - JDK-8253932: SSL debug log prints incorrect caller info - JDK-8254854: [cgroups v1] Metric limits not properly detected on some join controller combinations - JDK-8255880: UI of Swing components is not redrawn after their internal state changed - JDK-8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem - JDK-8255937: Better cleanup for test/jdk/javax/imageio/stream/StreamFlush.java - JDK-8256421: Add 2 HARICA roots to cacerts truststore - JDK-8256642: [TEST_BUG] jdk/test/javax/sound/midi/MidiSystem/DefaultProperties.java failed - JDK-8258079: Eliminate ParNew's use of klass_or_null() - JDK-8256682: JDK-8202343 is incomplete - JDK-8257192: Integrate AArch64 JIT port into 8u - JDK-8257746: Regression introduced with JDK-8250984 - memory might be null in some machines - JDK-8258079: Eliminate ParNew's use of klass_or_null() - JDK-8258241: [8u] Missing doPrivileged() hunks from JDK-8226575 - JDK-8258247: Couple of issues in fix for JDK-8249906 - JDK-8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk() - JDK-8258430: 8u backport of JDK-8063107 missing test/javax/swing/JRadioButton/8041561/bug8041561.java changes - JDK-8258833: Cancel multi-part cipher operations in SunPKCS11 after failures - JDK-8258933: G1 needs klass_or_null_acquire - JDK-8259048: (tz) Upgrade time-zone data to tzdata2020f - JDK-8259312: VerifyCACerts.java fails as soneraclass2ca cert will - JDK-8259384: CUP version wrong in THIRD_PARTY_README after JDK-8233548 - JDK-8259428: AlgorithmId.getEncodedParams() should return copy - JDK-8259568: PPC64 builds broken after JDK-8221408 8u backport - JDK-8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS - JDK-8260356: (tz) Upgrade time-zone data to tzdata2021a - JDK-8260930: AARCH64: Invalid value passed to critical JNI function - JDK-8261183: Follow on to Make lists of normal filenames - JDK-8261231: Windows IME was disabled after DnD operation - JDK-8261766: [8u] hotspot needs to recognise cl.exe 19.16 to build with VS2017 - JDK-8262073: assert(allocates2(pc)) failed: not in CodeBuffer memory - JDK-8262075: sun/security/krb5/auto/UseCacheAndStoreKey.java timed out intermittently - JDK-8263008: AARCH64: Add debug info for libsaproc.so - JDK-8264171: Missing aarch64 parts of JDK-8236179 (C1 register allocation failure with T_ADDRESS) Notes on individual issues: =========================== security-libs/java.security: JDK-8260597: Added 2 HARICA Root CA Certificates ================================================ The following root certificates have been added to the cacerts truststore: Alias Name: haricarootca2015 Distinguished Name: CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR Alias Name: haricaeccrootca2015 Distinguished Name: CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR JDK-8236730: Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default =================================================================================== Weak named curves are disabled by default by adding them to the following `disabledAlgorithms` security properties: * jdk.tls.disabledAlgorithms * jdk.certpath.disabledAlgorithms * jdk.jar.disabledAlgorithms The disabled curves are as follows: * secp112r1 * secp112r2 * secp128r1 * secp128r2 * secp160k1 * secp160r1 * secp160r2 * secp192k1 * secp192r1 * secp224k1 * secp224r1 * secp256k1 * sect113r1 * sect113r2 * sect131r1 * sect131r2 * sect163k1 * sect163r1 * sect163r2 * sect193r1 * sect193r2 * sect233k1 * sect233r1 * sect239k1 * sect283k1 * sect283r1 * sect409k1 * sect409r1 * sect571k1 * sect571r1 * X9.62 c2tnb191v1 * X9.62 c2tnb191v2 * X9.62 c2tnb191v3 * X9.62 c2tnb239v1 * X9.62 c2tnb239v2 * X9.62 c2tnb239v3 * X9.62 c2tnb359v1 * X9.62 c2tnb431r1 * X9.62 prime192v2 * X9.62 prime192v3 * X9.62 prime239v1 * X9.62 prime239v2 * X9.62 prime239v3 * brainpoolP256r1 * brainpoolP320r1 * brainpoolP384r1 * brainpoolP512r1 The curves that remain enabled are: * secp256r1 * secp384r1 * secp521r1 * X25519 * X448 When large numbers of weak named curves need to be disabled, adding individual named curves to each `disabledAlgorithms` property would be overwhelming. To relieve this, a new security property, `jdk.disabled.namedCurves`, is implemented that can list the named curves common to all of the `disabledAlgorithms` properties. To use the new property in the `disabledAlgorithms` properties, precede the full property name with the keyword `include`. Users can still add individual named curves to `disabledAlgorithms` properties separate from this new property. No other properties can be included in the `disabledAlgorithms` properties. To restore the named curves, remove the `include jdk.disabled.namedCurves` either from specific or from all `disabledAlgorithms` security properties. To restore one or more curves, remove the specific named curve(s) from the `jdk.disabled.namedCurves` property. JDK-8244286: Tools Warn If Weak Algorithms Are Used =================================================== The `keytool` and `jarsigner` tools have been updated to warn users when weak cryptographic algorithms are used in keys, certificates, and signed JARs before they are disabled. The weak algorithms are set in the `jdk.security.legacyAlgorithms` security property in the `java.security` configuration file. In this release, the tools issue warnings for the SHA-1 hash algorithm and 1024-bit RSA/DSA keys. security-libs/javax.net.ssl: JDK-8256490: Disable TLS 1.0 and 1.1 ==================================== TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3). These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the `jdk.tls.disabledAlgorithms` security property in the `java.security` configuration file. JDK-8242147: New System Properties to Configure the TLS Signature Schemes ========================================================================= Two new system properties have been added to customize the TLS signature schemes in JDK. `jdk.tls.client.SignatureSchemes` has been added for the TLS client side, and `jdk.tls.server.SignatureSchemes` has been added for the server side. Each system property contains a comma-separated list of supported signature scheme names specifying the signature schemes that could be used for the TLS connections. The names are described in the "Signature Schemes" section of the *Java Security Standard Algorithm Names Specification*. tools/javac: JDK-8177368: Several incorporation steps are silently failing when an error should be reported ============================================================================================== Reporting previously silent errors found during incorporation, JLS 8?18.3, was supposed to be a clean-up with performance only implications. But consider the test case: import java.util.Arrays; import java.util.List; class Klass { public static List> foo(List... lists) { return foo(Arrays.asList(lists)); } public static List> foo(List> lists) { return null; } } This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler. While determining the applicability of method: List> foo(List> lists) for which we have the constraints: b <: Object t <: List t<:Object List <: t first, inference variable b is selected for instantiation: b = CAP1 of ? extends A so this implies that: t <: List t<: Object List <: t Now all the bounds are checked for consistency. While checking if List is a subtype of List a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 ?18.4 This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility. [1] https://bugs.openjdk.java.net/browse/JDK-8078024 Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Apr 21 09:23:15 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Apr 2021 11:23:15 +0200 Subject: [8u] RFR (XS) 8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> References: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> Message-ID: <442ce8a0-09b6-ffec-17c4-c4e07030eb81@redhat.com> Thomas, Martin, Goetz, Do you agree with this backport? -Aleksey On 4/19/21 4:23 PM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8255734 > https://github.com/openjdk/jdk/commit/54c88132 > > The patch does not apply cleanly to 8u, because s390x port is not available in 8u, and there is > enough context changes (mostly due to JDK-8252324) to fail the automatic patch. 8u variant: > > diff -r 7ab0ec535776 src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp > --- a/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Thu Oct 24 16:28:51 2019 +0200 > +++ b/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Mon Apr 19 10:54:12 2021 +0200 > @@ -178,7 +178,7 @@ > // avoid unnecessary crash when libjsig is not preloaded, try handle signals > // that do not require siginfo/ucontext first. > > - if (sig == SIGPIPE) { > + if (sig == SIGPIPE || sig == SIGXFSZ) { > if (os::Aix::chained_handler(sig, info, ucVoid)) { > return 1; > } else { > diff -r 7ab0ec535776 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Thu Oct 24 16:28:51 2019 +0200 > +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Mon Apr 19 10:54:12 2021 +0200 > @@ -185,7 +185,7 @@ > // avoid unnecessary crash when libjsig is not preloaded, try handle signals > // that do not require siginfo/ucontext first. > > - if (sig == SIGPIPE) { > + if (sig == SIGPIPE || sig == SIGXFSZ) { > if (os::Linux::chained_handler(sig, info, ucVoid)) { > return true; > } else { > > > Reproducer before patch: > > $ build/linux-ppc64le-normal-server-fastdebug/images/j2sdk-image/bin/java Test > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGXFSZ (0x19) at pc=0x00003fff953a3348, pid=80212, tid=0x00003fff93b8f1b0 > # > # JRE version: OpenJDK Runtime Environment (8.0) (build > 1.8.0-internal-fastdebug-shade_2021_04_13_10_40-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-ppc64le compressed oops) > # Problematic frame: > # C [libpthread.so.0+0x13348] write+0x98 > > Reproducer after patch: > > $ build/linux-ppc64le-normal-server-fastdebug/images/j2sdk-image/bin/java Test > java.io.IOException: File too large > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:313) > at Test.main(Test.java:7) > Done > > Testing: ppc64le build, reproducer from JDK-8255734 > -- Thanks, -Aleksey From thomas.stuefe at gmail.com Wed Apr 21 09:29:41 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 21 Apr 2021 11:29:41 +0200 Subject: [8u] RFR (XS) 8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: <442ce8a0-09b6-ffec-17c4-c4e07030eb81@redhat.com> References: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> <442ce8a0-09b6-ffec-17c4-c4e07030eb81@redhat.com> Message-ID: Oh, of course. Looks fine. Thanks for doing this. On Wed, Apr 21, 2021, 11:23 Aleksey Shipilev wrote: > Thomas, Martin, Goetz, > > Do you agree with this backport? > > -Aleksey > > On 4/19/21 4:23 PM, Aleksey Shipilev wrote: > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8255734 > > https://github.com/openjdk/jdk/commit/54c88132 > > > > The patch does not apply cleanly to 8u, because s390x port is not > available in 8u, and there is > > enough context changes (mostly due to JDK-8252324) to fail the automatic > patch. 8u variant: > > > > diff -r 7ab0ec535776 src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp > > --- a/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Thu Oct 24 16:28:51 2019 > +0200 > > +++ b/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp Mon Apr 19 10:54:12 2021 > +0200 > > @@ -178,7 +178,7 @@ > > // avoid unnecessary crash when libjsig is not preloaded, try > handle signals > > // that do not require siginfo/ucontext first. > > > > - if (sig == SIGPIPE) { > > + if (sig == SIGPIPE || sig == SIGXFSZ) { > > if (os::Aix::chained_handler(sig, info, ucVoid)) { > > return 1; > > } else { > > diff -r 7ab0ec535776 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > > --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Thu Oct 24 > 16:28:51 2019 +0200 > > +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp Mon Apr 19 > 10:54:12 2021 +0200 > > @@ -185,7 +185,7 @@ > > // avoid unnecessary crash when libjsig is not preloaded, try > handle signals > > // that do not require siginfo/ucontext first. > > > > - if (sig == SIGPIPE) { > > + if (sig == SIGPIPE || sig == SIGXFSZ) { > > if (os::Linux::chained_handler(sig, info, ucVoid)) { > > return true; > > } else { > > > > > > Reproducer before patch: > > > > $ > build/linux-ppc64le-normal-server-fastdebug/images/j2sdk-image/bin/java Test > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGXFSZ (0x19) at pc=0x00003fff953a3348, pid=80212, > tid=0x00003fff93b8f1b0 > > # > > # JRE version: OpenJDK Runtime Environment (8.0) (build > > 1.8.0-internal-fastdebug-shade_2021_04_13_10_40-b00) > > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode > linux-ppc64le compressed oops) > > # Problematic frame: > > # C [libpthread.so.0+0x13348] write+0x98 > > > > Reproducer after patch: > > > > $ > build/linux-ppc64le-normal-server-fastdebug/images/j2sdk-image/bin/java Test > > java.io.IOException: File too large > > at java.io.FileOutputStream.writeBytes(Native Method) > > at java.io.FileOutputStream.write(FileOutputStream.java:313) > > at Test.main(Test.java:7) > > Done > > > > Testing: ppc64le build, reproducer from JDK-8255734 > > > > > -- > Thanks, > -Aleksey > > From shade at redhat.com Wed Apr 21 09:31:25 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Apr 2021 11:31:25 +0200 Subject: [8u] RFR (XS) 8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: References: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> <442ce8a0-09b6-ffec-17c4-c4e07030eb81@redhat.com> Message-ID: <11d4ef93-da0e-26f7-ee5b-4f926bec559c@redhat.com> On 4/21/21 11:29 AM, Thomas St?fe wrote: > Oh, of course. Looks fine. Thanks for doing this. Thanks! I tagged it for 8u approvals. -- -Aleksey From jhuttana at redhat.com Wed Apr 21 10:39:00 2021 From: jhuttana at redhat.com (Jayashree Huttanagoudar) Date: Wed, 21 Apr 2021 16:09:00 +0530 Subject: OpenJDK 8u292 Released In-Reply-To: <20210421051422.GA483014@rincewind> References: <20210421051422.GA483014@rincewind> Message-ID: Hi Team, On Wed, Apr 21, 2021 at 10:45 AM Andrew Hughes wrote: > We are pleased to announce the release of OpenJDK 8u292. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u292-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u292-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: > > 9008c700c699739e185ee5b1b4554b769a81492f9b3358634cd693ce75668b3f > openjdk8u292-ga.tar.xz > 3d9f770da61ea72ba43a3ccde1a72d14e40bf6bc3ea7cba947617a9434d2c988 > openjdk8u292-ga.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u292-ga.sha256 > > The binaries to go with this are here : https://adoptopenjdk.net/upstream.html?variant=openjdk8&jvmVariant=hotspot Thanks & Regards, Jaya > > 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 Wed Apr 21 11:49:57 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 21 Apr 2021 07:49:57 -0400 Subject: [8u] RFR 8177809: File.lastModified() is losing milliseconds (always ends in 000) In-Reply-To: <8665adbf-770a-f024-8251-1f6d6829dd7d@redhat.com> References: <1c9c1639-ebc2-1dcc-fa71-7d228037887c@redhat.com> <8665adbf-770a-f024-8251-1f6d6829dd7d@redhat.com> Message-ID: Thanks for reviewing, Aleksey. Tagged for approval. -Zhengyu On 4/20/21 4:32 AM, Aleksey Shipilev wrote: > On 4/20/21 4:01 AM, Zhengyu Gu wrote: >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8177809-8u/webrev.00/ > > This looks good. > From zgu at redhat.com Wed Apr 21 11:52:19 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 21 Apr 2021 07:52:19 -0400 Subject: [8u] RFR (XS) 8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME In-Reply-To: <8dbe987f-a8ab-334c-cdb3-fb1bd7b01ef7@redhat.com> References: <8dbe987f-a8ab-334c-cdb3-fb1bd7b01ef7@redhat.com> Message-ID: <135f70b2-fc25-0a51-02b9-2db239afaf44@redhat.com> Looks good. -Zhengyu On 4/20/21 5:02 AM, Aleksey Shipilev wrote: > Original test bug: > ? https://bugs.openjdk.java.net/browse/JDK-8166046 > ? https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d288db38d1aa > > This is a part of larger effort to improve JDK 8 testing. This patch is > very simple, yet it does not apply cleanly, because "8132919: Put > compiler tests in packages" is missing. 8u patch is otherwise the same: > > diff -r b4de82aff831 > test/compiler/stringopts/TestStringObjectInitialization.java > --- a/test/compiler/stringopts/TestStringObjectInitialization.java > Wed Dec 10 13:58:30 2014 +0000 > +++ b/test/compiler/stringopts/TestStringObjectInitialization.java > Tue Apr 20 10:59:56 2021 +0200 > @@ -57,10 +57,15 @@ > > ???? public void run(String s, String[] sArray) { > ???????? // Trigger C2's string concatenation optimization > ???????? add(s + Arrays.toString(sArray) + " const "); > ???? } > + > +??? public void reset() { > +??????? // Reset string to avoid OOMEs > +??????? myString = ""; > +??? } > ?} > > ?class Runner implements Runnable { > ???? private TestStringObjectInitialization test; > > @@ -68,11 +73,12 @@ > ???????? test = t; > ???? } > > ???? public void run(){ > ???????? String[] array = {"a", "b", "c"}; > -??????? for (int i = 0; i < 10000; ++i) { > +??????? for (int i = 0; i < 100_000; ++i) { > ???????????? test.run("a", array); > +??????????? test.reset(); > ???????? } > ???? } > ?} > > Testing: tier1 > From shade at redhat.com Wed Apr 21 12:37:50 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Apr 2021 14:37:50 +0200 Subject: [8u] RFR (XS) 8166046: [TESTBUG] compiler/stringopts/TestStringObjectInitialization.java fails with OOME In-Reply-To: <135f70b2-fc25-0a51-02b9-2db239afaf44@redhat.com> References: <8dbe987f-a8ab-334c-cdb3-fb1bd7b01ef7@redhat.com> <135f70b2-fc25-0a51-02b9-2db239afaf44@redhat.com> Message-ID: On 4/21/21 1:52 PM, Zhengyu Gu wrote: > Looks good. Thanks, tagged for approvals. -- -Aleksey From zgu at redhat.com Wed Apr 21 14:54:27 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 21 Apr 2021 10:54:27 -0400 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak Message-ID: I would like to backport this patch to 8u for parity with Oracle 8u301 The original bug: https://bugs.openjdk.java.net/browse/JDK-8178403 The original patch: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/5fcac4064fdd The original patch does not apply cleanly. 1. DirectAudioDevice.java has newer copyright year in 8u. 2. ClipCloseLoss.java does not in 8u's ProblemList.txt 3. ClipCloseLoss.java test does not have "@key intermittent" line in 8u. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178403-8u/webrev.00/ Test: passed ClipCloseLoss.java test Thanks, -Zhengyu From shade at redhat.com Wed Apr 21 15:03:54 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Apr 2021 17:03:54 +0200 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: References: Message-ID: On 4/21/21 4:54 PM, Zhengyu Gu wrote: > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178403-8u/webrev.00/ This looks fine. > Test: > passed ClipCloseLoss.java test Did you see the test failing before the patch? -- Thanks, -Aleksey From zgu at redhat.com Wed Apr 21 15:11:06 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 21 Apr 2021 11:11:06 -0400 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: References: Message-ID: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> Hi Aleksey, On 4/21/21 11:03 AM, Aleksey Shipilev wrote: > On 4/21/21 4:54 PM, Zhengyu Gu wrote: >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178403-8u/webrev.00/ > > This looks fine. > Thanks for reviewing. >> Test: >> ??? passed ClipCloseLoss.java test > > Did you see the test failing before the patch? > No, I could not reproduce with 5 runs. This is an intermittent bug. -Zhengyu From shade at redhat.com Wed Apr 21 15:30:23 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 21 Apr 2021 17:30:23 +0200 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> References: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> Message-ID: <5f119906-f6a5-3c61-15e2-20389cd58fd9@redhat.com> On 4/21/21 5:11 PM, Zhengyu Gu wrote: > Hi Aleksey, > > On 4/21/21 11:03 AM, Aleksey Shipilev wrote: >> On 4/21/21 4:54 PM, Zhengyu Gu wrote: >>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8178403-8u/webrev.00/ >> >> This looks fine. >> > > Thanks for reviewing. > >>> Test: >>> ??? passed ClipCloseLoss.java test >> >> Did you see the test failing before the patch? >> > > No, I could not reproduce with 5 runs. This is an intermittent bug. Okay then. -- Thanks, -Aleksey From Sergey.Bylokhov at oracle.com Wed Apr 21 18:17:23 2021 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 21 Apr 2021 11:17:23 -0700 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> References: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> Message-ID: On 21.04.2021 08:11, Zhengyu Gu wrote: > No, I could not reproduce with 5 runs. This is an intermittent bug. Even using an updated test? -- Best regards, Sergey. From zgu at redhat.com Wed Apr 21 20:25:49 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 21 Apr 2021 16:25:49 -0400 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: References: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> Message-ID: Hi Sergey On 4/21/21 2:17 PM, Sergey Bylokhov wrote: > On 21.04.2021 08:11, Zhengyu Gu wrote: >> No, I could not reproduce with 5 runs. This is an intermittent bug. > > Even using an updated test? > I am not sure what you mean here. Patched test case is identical to the one in jdk/jdk, except with additional "@key headful" test annotation Could you elaborate? Thanks, -Zhengyu > From Sergey.Bylokhov at oracle.com Wed Apr 21 21:44:31 2021 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 21 Apr 2021 14:44:31 -0700 Subject: [External] : Re: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: References: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> Message-ID: On 21.04.2021 13:25, Zhengyu Gu wrote: >> Even using an updated test? >> > I am not sure what you mean here. Patched test case is identical to the one in jdk/jdk, except with additional "@key headful" test annotation I just would like to confirm that you cannot reproduce the bug using the unpatched/old JDK + the patched test? -- Best regards, Sergey. From hohensee at amazon.com Wed Apr 21 23:16:29 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 21 Apr 2021 23:16:29 +0000 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Message-ID: <1B8EB9F7-D941-41C7-B3F4-AFA92D622DD7@amazon.com> You're correct, there's no overlap. Looks fine. 11u contains 3 separate follow-up backports, so it would be best to do the same for 8u. Thanks, Paul ?-----Original Message----- From: Alex Kashchenko Date: Tuesday, April 20, 2021 at 12:57 PM To: "Hohensee, Paul" Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Hi, On 4/15/21, Alex Kashchenko wrote: > On 4/15/21, Hohensee, Paul wrote: >> This patch needs updating. E.g., the IOException catch code in >> SocketImpl.java is already in 8u. > > Thanks for your comments! I will revisit the patch and prepare the > updated version shortly. I've re-checked that the patch can be applied to the latest 8u-dev, it appeared that recent IOException changes do not overlap with it. In mainline this patch required 3 follow-up commits with minor fixes to the test. I've combined these patches into one 8u backport and posted it for review here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013678.html I think it will make sense to push this backport together with the follow-up one. > >> >> Thanks, >> Paul >> >> -----Original Message----- >> From: jdk8u-dev on behalf of Alex >> Kashchenko >> Date: Monday, January 4, 2021 at 2:11 PM >> To: "jdk8u-dev at openjdk.java.net" >> Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected >> leaks >> socket resources >> >> Hi, >> >> Please review the backport of JDK-8256818 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 >> >> Original change: https://github.com/openjdk/jdk/commit/93b6ab56 >> >> 11u change: >> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 >> >> Some details on current 11u behaviour (also applicable to 8u): >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html >> >> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ >> >> Code change to SSLSocketImpl.java applies cleanly after path change. >> SSLSocketLeak.java test needs to be adapted for 8u: to get the number >> of process handles on Windows native lib is required; there is no >> support for building native test libs in 8u, because of this >> libFileUtils.c is placed into the same directory where test is; test >> is marked as "manual" and "native" and comment with details about >> shared lib is added to the test; test is adapted to load shared lib >> directly without going through FileUtils; changes to CheckHandles.java >> are not applicable to 8u, because corresponding change JDK-8239893 is >> not in 8u. >> >> Testing: checked that added test passes on Linux and Windows, ran >> jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . >> >> -- >> -Alex >> >> >> > > > -- > -Alex > -- -Alex From zgu at redhat.com Thu Apr 22 12:54:44 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 22 Apr 2021 08:54:44 -0400 Subject: [External] : Re: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: References: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> Message-ID: <13cbb583-6732-c868-1d6a-2d22e26921c4@redhat.com> On 4/21/21 5:44 PM, Sergey Bylokhov wrote: > On 21.04.2021 13:25, Zhengyu Gu wrote: > >>> Even using an updated test? >>> >> I am not sure what you mean here. Patched test case is identical to >> the one in jdk/jdk, except with additional "@key headful" test annotation > > I just would like to confirm that you cannot reproduce the bug using the > unpatched/old JDK + the patched test? Ah, thanks for clarification, Sergey. Yes, patched test failed with unpatched jdk, and passed with patched jdk. -Zhengyu > > From Sergey.Bylokhov at oracle.com Thu Apr 22 16:30:12 2021 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 22 Apr 2021 09:30:12 -0700 Subject: [8u] RFR 8178403: DirectAudio in JavaSound may hang and leak In-Reply-To: <13cbb583-6732-c868-1d6a-2d22e26921c4@redhat.com> References: <5dbd693a-7b92-aef7-2ae0-89cf24ce4c20@redhat.com> <13cbb583-6732-c868-1d6a-2d22e26921c4@redhat.com> Message-ID: On 22.04.2021 05:54, Zhengyu Gu wrote: >>> I am not sure what you mean here. Patched test case is identical to the one in jdk/jdk, except with additional "@key headful" test annotation >> >> I just would like to confirm that you cannot reproduce the bug using the unpatched/old JDK + the patched test? > > Ah, thanks for clarification, Sergey. > > Yes, patched test failed with unpatched jdk, and passed with patched jdk. Thank you for confirmation. -- Best regards, Sergey. From mbalao at redhat.com Thu Apr 22 19:14:47 2021 From: mbalao at redhat.com (Martin Balao) Date: Thu, 22 Apr 2021 16:14:47 -0300 Subject: [8u] RFR 8254631: Better support ALPN byte wire values in SunJSSE Message-ID: <140ad267-cb65-bb87-f3d2-f6dca105db2e@redhat.com> Hi, I'd like to request a review for the 8u backport of JDK-8254631 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8254631/8254631.webrev.jdk8u.jdk.00/ The 11u patch does not apply cleanly because of the following reasons: * Paths need to be converted to the old scheme * java.security changes need to be propagated through the different java.security- files * AlpnGreaseTest.java uses a java.util.Arrays public API not available in 8u (introduced by JDK-8033148 [2]). * Fixed creating copies of the arrays to compare. * AlpnGreaseTest.java uses ByteBuffer::flip that returns a ByteBuffer. In 8u JDK-4774077 [3] is not present so Buffer::flip gets called and a Buffer is returned. This is a problem because ::get(byte[]) is then invoked and this is not available in the Buffer class (but in ByteBuffer). * Fixed with a simple casting. No test regressions found in jdk/sun/security/ssl. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8254631 [2] - https://bugs.openjdk.java.net/browse/JDK-8033148 [3] - https://bugs.openjdk.java.net/browse/JDK-4774077 From shade at redhat.com Fri Apr 23 07:44:12 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Apr 2021 09:44:12 +0200 Subject: [8u] RFR (XS) 8265832: runtime/StackGap/testme.sh fails to compile in 8u Message-ID: This is 8u-specific bug, because in original 11u fix (JDK-8197429) the build is handled by the build system itself. In 8u, however, it fails with: Compilation flag: STDERR: openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-shade_2021_04_22_19_10-b00) OpenJDK 64-Bit Server VM (build 25.71-b00-fastdebug, mixed mode) /usr/bin/ld: /tmp/ccj5AhI1.o: in function `create_vm': exestack-gap.c:(.text+0x103): undefined reference to `JNI_CreateJavaVM' collect2: error: ld returned 1 exit status /home/shade/trunks/jdk8u-dev/hotspot/test/runtime/StackGap/testme.sh: 72: ./stack-gap: not found Ultimately, that is because the link options order matters for this test, as linker would try to search for external functions from left to right, so the library containing the definition should appear after the source file that uses it. This was apparently lax in older gcc-s, but newer gcc-s are breaking with the error above. This fixes 8u: diff -r d05490a39074 test/runtime/StackGap/testme.sh --- a/test/runtime/StackGap/testme.sh Thu Apr 22 20:27:11 2021 +0200 +++ b/test/runtime/StackGap/testme.sh Fri Apr 23 09:37:01 2021 +0200 @@ -65,9 +65,10 @@ # for /usr/lib/`uname -m`-linux-gnu version ensure to add that path to below compilation. $gcc_cmd -DLINUX ${CFLAGS} -o stack-gap \ -I${COMPILEJAVA}/include -I${COMPILEJAVA}/include/linux \ -L${COMPILEJAVA}/jre/lib/${VM_CPU}/${VM_TYPE} \ - -ljvm -lpthread exestack-gap.c + exestack-gap.c \ + -ljvm -lpthread ./stack-gap || exit $? ./stack-gap -XX:+DisablePrimordialThreadGuardPages || exit $? Testing: affected test, now passes -- Thanks, -Aleksey From shade at redhat.com Fri Apr 23 09:37:55 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Apr 2021 11:37:55 +0200 Subject: [8u] RFR (S) 8071374: Native disassembler implementation may be not thread-safe Message-ID: <526cfccd-42b6-277f-b5b8-abcb0b23513e@redhat.com> Original bug: https://bugs.openjdk.java.net/browse/JDK-8071374 https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/116a12504a2f This still bites me with 8u JMH runs. The Stress reproducer from the issue also fails without this patch and passes with it. Unfortunately, the patch has a few conflicts when applied to 8u: - at times, the context near print_cr-s is different enough for automatic patch to fail; - there are no PrintAssemblyOption in 8u (added later by JEP 165); - there is no jvmciCompilerToVM.cpp (added later by JEP 243); 8u webrev: https://cr.openjdk.java.net/~shade/8071374/webrev.8u.01/ Testing: reproducer from the test (now passes); adhoc JMH perfasm runs (now reliable); hotspot_tier1 -- Thanks, -Aleksey From sgehwolf at redhat.com Fri Apr 23 11:55:02 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 23 Apr 2021 13:55:02 +0200 Subject: [8u] RFR (XS) 8265832: runtime/StackGap/testme.sh fails to compile in 8u In-Reply-To: References: Message-ID: <02e0c9ca03b86f35bdc5359d8730c32598139d90.camel@redhat.com> On Fri, 2021-04-23 at 09:44 +0200, Aleksey Shipilev wrote: diff -r d05490a39074 test/runtime/StackGap/testme.sh --- a/test/runtime/StackGap/testme.sh?? Thu Apr 22 20:27:11 2021+0200 +++ b/test/runtime/StackGap/testme.sh?? Fri Apr 23 09:37:01 2021+0200 @@ -65,9 +65,10 @@ ? # for /usr/lib/`uname -m`-linux-gnu version ensure to add that part to below compilation. ? $gcc_cmd -DLINUX ${CFLAGS} -o stack-gap \ ????? -I${COMPILEJAVA}/include -I${COMPILEJAVA}/include/linux \ ????? -L${COMPILEJAVA}/jre/lib/${VM_CPU}/${VM_TYPE} \ -??? -ljvm -lpthread exestack-gap.c +??? exestack-gap.c \ +??? -ljvm -lpthread ? ./stack-gap || exit $? ? ./stack-gap -XX:+DisablePrimordialThreadGuardPages || exit $? Looks fine. Thanks, Severin From shade at redhat.com Fri Apr 23 12:06:46 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 23 Apr 2021 14:06:46 +0200 Subject: [8u] RFR (XS) 8265832: runtime/StackGap/testme.sh fails to compile in 8u In-Reply-To: <02e0c9ca03b86f35bdc5359d8730c32598139d90.camel@redhat.com> References: <02e0c9ca03b86f35bdc5359d8730c32598139d90.camel@redhat.com> Message-ID: <1db6bffa-9f59-1eab-65f0-65e5b565a347@redhat.com> On 4/23/21 1:55 PM, Severin Gehwolf wrote: > Looks fine. Thanks, tagged for approvals. -- Thanks, -Aleksey From denghui.ddh at alibaba-inc.com Fri Apr 23 12:25:31 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Fri, 23 Apr 2021 20:25:31 +0800 Subject: =?UTF-8?B?UElORyBbOHVdIFJGUiA4MjY0ODE2OiBXZWFrIGhhbmRsZXMgbGVhayBjYXVzZXMgR0MgdG8g?= =?UTF-8?B?dGFrZSBsb25nZXI=?= Message-ID: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com> Gentle ping? ------------------------------------------------------------------ From:???(??) Send Time:2021?4?7?(???) 15:44 To:jdk8u-dev ; jdk-updates-dev at openjdk.java.net Subject:[8u] RFR 8264816: Weak handles leak causes GC to take longer Hi, Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 Testing: Linux x86_64 jdk/test/java/lang/invoke Other information: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html Thanks, Denghui From zgu at redhat.com Fri Apr 23 12:54:14 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 23 Apr 2021 08:54:14 -0400 Subject: PING [8u] RFR 8264816: Weak handles leak causes GC to take longer In-Reply-To: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com> References: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com> Message-ID: <11292f01-f384-dc48-d7c4-755f8889bddd@redhat.com> Looks good to me. -Zhengyu On 4/23/21 8:25 AM, Denghui Dong wrote: > Gentle ping? > ------------------------------------------------------------------ > From:???(??) > Send Time:2021?4?7?(???) 15:44 > To:jdk8u-dev ; jdk-updates-dev at openjdk.java.net > Subject:[8u] RFR 8264816: Weak handles leak causes GC to take longer > > Hi, > > Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 > webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 > > Testing: Linux x86_64 jdk/test/java/lang/invoke > Other information: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html > > Thanks, > Denghui > From zgu at redhat.com Fri Apr 23 13:06:46 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 23 Apr 2021 09:06:46 -0400 Subject: [8u] RFR 8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported Message-ID: I would like to backport this patch to 8u for parity with Oracle 8u301. The original bug: https://bugs.openjdk.java.net/browse/JDK-8134672 The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/af678f2593e2 The original patch does not apply cleanly to 8u. The only conflict is copyright year. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8134672-8u/webrev.00/ Test: Test passed on Linux x86_84 Thanks, -Zhengyu From mbalao at redhat.com Fri Apr 23 13:47:40 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 23 Apr 2021 10:47:40 -0300 Subject: [8u] RFR 8228757: Fail fast if the handshake type is unknown Message-ID: Hi, I'd like to request a review for the 8u backport of JDK-8228757 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8228757/8228757.webrev.jdk8u.jdk.00/ Changes from 11u: * Changes in the 'DTLSInputRecord.java' file do not apply to 8u because there is no DTLS support in 8u. See JDK-8245469 [2]. * In 'SSLEngineInputRecord.java' file, the copyright end date in 8u is greater than in the patch because 8u has JDK-8245417 [3]. So the copyright end date change does not apply. No regressions found in jdk/sun/security/ssl tests category. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8228757 [2] - https://bugs.openjdk.java.net/browse/JDK-8245469 [3] - https://bugs.openjdk.java.net/browse/JDK-8245417 From alexey at azul.com Fri Apr 23 14:54:57 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 23 Apr 2021 14:54:57 +0000 Subject: [8u] RFR 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) Message-ID: <761A14C0-9485-45F4-858A-9F3D007E8EEB@azul.com> Hello All, Could you please review fix for the JDK-8241248 Issue happens during the TLSv1.3 handshake in case of server receives several parallel requests with the same pre_shared_key. The main idea of the fix is to remove resuming session from the session cache on the early stage. JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ The test from the bug report using OpenSSL is passed javax/net/ssl and sun/security/ssl jtreg tests passed Regards Alexey From sgehwolf at redhat.com Fri Apr 23 15:35:12 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 23 Apr 2021 17:35:12 +0200 Subject: [8u] RFR 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: <761A14C0-9485-45F4-858A-9F3D007E8EEB@azul.com> References: <761A14C0-9485-45F4-858A-9F3D007E8EEB@azul.com> Message-ID: <4e74777455dd847730fa166a9d5c2269fe935d44.camel@redhat.com> Hi Alexey, On Fri, 2021-04-23 at 14:54 +0000, Alexey Bakhtin wrote: > Hello All, > > Could you please review fix for the JDK-8241248 > Issue happens during the TLSv1.3 handshake in case of server receives > several parallel requests with the same pre_shared_key. > The main idea of the fix is to remove resuming session from the > session cache on the early stage. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ > > The test from the bug report using OpenSSL is passed > javax/net/ssl and sun/security/ssl jtreg tests passed As far as I can see this bug isn't fix in latest JDK head. It should get fixed there first before we attempt to address it in OpenJDK 8. Thanks, Severin From sgehwolf at redhat.com Fri Apr 23 15:51:30 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 23 Apr 2021 17:51:30 +0200 Subject: [8u] RFR 8228757: Fail fast if the handshake type is unknown In-Reply-To: References: Message-ID: <9606f35e25ff16e1914fe9668d1b558708020569.camel@redhat.com> Hi Martin, On Fri, 2021-04-23 at 10:47 -0300, Martin Balao wrote: > http://cr.openjdk.java.net/~mbalao/webrevs/8228757/8228757.webrev.jdk8u.jdk.00/ This looks fine. Thanks, Severin From alexey at azul.com Fri Apr 23 16:46:17 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 23 Apr 2021 16:46:17 +0000 Subject: [8u] RFR 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) In-Reply-To: <4e74777455dd847730fa166a9d5c2269fe935d44.camel@redhat.com> References: <761A14C0-9485-45F4-858A-9F3D007E8EEB@azul.com> <4e74777455dd847730fa166a9d5c2269fe935d44.camel@redhat.com> Message-ID: <32053FC1-90DC-4882-ABC3-D1E49AEA4293@azul.com> Hi Severin, Thank you. I will submit it to upstream because of issue reproducible with disabled server stateless session resumption. Regards Alexey > On 23 Apr 2021, at 18:35, Severin Gehwolf wrote: > > Hi Alexey, > > On Fri, 2021-04-23 at 14:54 +0000, Alexey Bakhtin wrote: >> Hello All, >> >> Could you please review fix for the JDK-8241248 >> Issue happens during the TLSv1.3 handshake in case of server receives >> several parallel requests with the same pre_shared_key. >> The main idea of the fix is to remove resuming session from the >> session cache on the early stage. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ >> >> The test from the bug report using OpenSSL is passed >> javax/net/ssl and sun/security/ssl jtreg tests passed > > As far as I can see this bug isn't fix in latest JDK head. It should > get fixed there first before we attempt to address it in OpenJDK 8. > > Thanks, > Severin From denghui.ddh at alibaba-inc.com Sat Apr 24 03:16:55 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Sat, 24 Apr 2021 11:16:55 +0800 Subject: =?UTF-8?B?UmU6IFBJTkcgWzh1XSBSRlIgODI2NDgxNjogV2VhayBoYW5kbGVzIGxlYWsgY2F1c2VzIEdD?= =?UTF-8?B?IHRvIHRha2UgbG9uZ2Vy?= In-Reply-To: <11292f01-f384-dc48-d7c4-755f8889bddd@redhat.com> References: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com>, <11292f01-f384-dc48-d7c4-755f8889bddd@redhat.com> Message-ID: <096b5caa-277d-419d-b9fc-88a7ad9ca866.denghui.ddh@alibaba-inc.com> Thank you! Denghui ------------------------------------------------------------------ From:Zhengyu Gu Send Time:2021?4?23?(???) 20:54 To:???(??) ; jdk8u-dev Subject:Re: PING [8u] RFR 8264816: Weak handles leak causes GC to take longer Looks good to me. -Zhengyu On 4/23/21 8:25 AM, Denghui Dong wrote: > Gentle ping? > ------------------------------------------------------------------ > From:???(??) > Send Time:2021?4?7?(???) 15:44 > To:jdk8u-dev ; jdk-updates-dev at openjdk.java.net > Subject:[8u] RFR 8264816: Weak handles leak causes GC to take longer > > Hi, > > Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 > webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 > > Testing: Linux x86_64 jdk/test/java/lang/invoke > Other information: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html > > Thanks, > Denghui > From akashche at redhat.com Sat Apr 24 13:10:02 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 24 Apr 2021 14:10:02 +0100 Subject: [8u] RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks Message-ID: Hi, Please review the backport of JDK-8257670 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8257670 Original change: https://github.com/openjdk/jdk/commit/39b8a2e6 11u backport: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0fdf7159d5c2 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257670/webrev.00/ 8u exported patch: https://cr.openjdk.java.net/~akasko/jdk8u/8257670/8257670_8u.changeset This change is a follow-up to JDK-8256818 (review thread [1]) and needs to be applied on top of it. The change to the jtreg @run tag is not applicable to 8u, because the test requires a native lib and is already marked as manual in 8u. Testing: checked that changed test passes. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013695.html -- -Alex From akashche at redhat.com Sat Apr 24 13:10:17 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 24 Apr 2021 14:10:17 +0100 Subject: [8u] RFR: 8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test Message-ID: Hi, Please review the backport of JDK-8257884 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8257884 Original change: https://github.com/openjdk/jdk/commit/fae7961a 11u backport: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/59a6aaef42a7 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257884/webrev.00/ 8u exported commit: https://cr.openjdk.java.net/~akasko/jdk8u/8257884/8257884_8u.changeset This change is a follow-up to JDK-8256818 (review thread [1]) and JDK-8257670 [2] and needs to be applied on top of them. It requires minor adjustemts, because jdk.test.lib.Platform API used there is not available in 8u. Testing: checked that changed test can be compiled, it fails in my environment reporting found leaks, this problem with it is mitigated with a follow-up change JDK-8257997 [3]. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013695.html [2] https://bugs.openjdk.java.net/browse/JDK-8257670 [3] https://bugs.openjdk.java.net/browse/JDK-8257997 -- -Alex From akashche at redhat.com Sat Apr 24 13:10:51 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 24 Apr 2021 14:10:51 +0100 Subject: [8u] RFR: 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 In-Reply-To: References: Message-ID: On 4/20/21, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8257997 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8257997 > > Original changeset: https://github.com/openjdk/jdk/commit/29ffffa7 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/webrev.00/ > > [...] > Updated webrev following up the comments from JDK-8256818 review thread [1]: 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/webrev.01/ 8u exported commit: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/8257997_8u_rework.changeset This change is a follow-up to JDK-8256818 (review thread [1]), JDK-8257670 [2] and JDK-8257884 [3] and needs to be applied on top of them. Testing: checked that changed test passes on Windows and Linux. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013695.html [2] https://bugs.openjdk.java.net/browse/JDK-8257670 [3] https://bugs.openjdk.java.net/browse/JDK-8257884 -- -Alex From akashche at redhat.com Sat Apr 24 13:15:40 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Sat, 24 Apr 2021 14:15:40 +0100 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: <1B8EB9F7-D941-41C7-B3F4-AFA92D622DD7@amazon.com> References: <1B8EB9F7-D941-41C7-B3F4-AFA92D622DD7@amazon.com> Message-ID: On 4/22/21, Hohensee, Paul wrote: > You're correct, there's no overlap. Looks fine. Thanks for the review! > > 11u contains 3 separate follow-up backports, so it would be best to do the > same for 8u. Posted these three backports for review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013712.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013713.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013714.html > > Thanks, > Paul > > ?-----Original Message----- > From: Alex Kashchenko > Date: Tuesday, April 20, 2021 at 12:57 PM > To: "Hohensee, Paul" > Cc: "jdk8u-dev at openjdk.java.net" > Subject: RE: [8u] RFR: 8256818: SSLSocket that is never bound or connected > leaks socket resources > > Hi, > > On 4/15/21, Alex Kashchenko wrote: >> On 4/15/21, Hohensee, Paul wrote: >>> This patch needs updating. E.g., the IOException catch code in >>> SocketImpl.java is already in 8u. >> >> Thanks for your comments! I will revisit the patch and prepare the >> updated version shortly. > > I've re-checked that the patch can be applied to the latest 8u-dev, it > appeared that recent IOException changes do not overlap with it. > > In mainline this patch required 3 follow-up commits with minor fixes > to the test. I've combined these patches into one 8u backport and > posted it for review here: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013678.html > > I think it will make sense to push this backport together with the > follow-up one. > > >> >>> >>> Thanks, >>> Paul >>> >>> -----Original Message----- >>> From: jdk8u-dev on behalf of Alex >>> Kashchenko >>> Date: Monday, January 4, 2021 at 2:11 PM >>> To: "jdk8u-dev at openjdk.java.net" >>> Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected >>> leaks >>> socket resources >>> >>> Hi, >>> >>> Please review the backport of JDK-8256818 to 8u: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 >>> >>> Original change: https://github.com/openjdk/jdk/commit/93b6ab56 >>> >>> 11u change: >>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 >>> >>> Some details on current 11u behaviour (also applicable to 8u): >>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html >>> >>> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ >>> >>> Code change to SSLSocketImpl.java applies cleanly after path change. >>> SSLSocketLeak.java test needs to be adapted for 8u: to get the number >>> of process handles on Windows native lib is required; there is no >>> support for building native test libs in 8u, because of this >>> libFileUtils.c is placed into the same directory where test is; test >>> is marked as "manual" and "native" and comment with details about >>> shared lib is added to the test; test is adapted to load shared lib >>> directly without going through FileUtils; changes to CheckHandles.java >>> are not applicable to 8u, because corresponding change JDK-8239893 is >>> not in 8u. >>> >>> Testing: checked that added test passes on Linux and Windows, ran >>> jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . >>> >>> -- >>> -Alex >>> >>> >>> >> >> >> -- >> -Alex >> > > > -- > -Alex > > > -- -Alex From felix.yang at huawei.com Sun Apr 25 06:30:58 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sun, 25 Apr 2021 06:30:58 +0000 Subject: RFR(XS): 8217348: assert(thread->is_Java_thread()) failed: just checking Message-ID: Hi, Please review this backport of one trivial change fixing an obvious typo: Original Bug: https://bugs.openjdk.java.net/browse/JDK-8217348 http://hg.openjdk.java.net/jdk/jdk13/rev/09ee0bd26bda This was once biting us in our internal development. Original patch does not apply cleanly to 8u due to changes in surrounding context. 8u webrev: http://cr.openjdk.java.net/~fyang/8217348-8u/webrev.00 Testing: Performed full jtreg tests with a fastdebug build. Thanks, Felix From zgu at redhat.com Sun Apr 25 17:59:00 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Sun, 25 Apr 2021 13:59:00 -0400 Subject: RFR(XS): 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: References: Message-ID: LGTM. -Zhengyu On 4/25/21 2:30 AM, Yangfei (Felix) wrote: > Hi, > > Please review this backport of one trivial change fixing an obvious typo: > > Original Bug: > https://bugs.openjdk.java.net/browse/JDK-8217348 > http://hg.openjdk.java.net/jdk/jdk13/rev/09ee0bd26bda > > This was once biting us in our internal development. > Original patch does not apply cleanly to 8u due to changes in surrounding context. > > 8u webrev: > http://cr.openjdk.java.net/~fyang/8217348-8u/webrev.00 > > Testing: > Performed full jtreg tests with a fastdebug build. > > Thanks, > Felix > From felix.yang at huawei.com Mon Apr 26 00:51:59 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 26 Apr 2021 00:51:59 +0000 Subject: RFR(XS): 8217348: assert(thread->is_Java_thread()) failed: just checking In-Reply-To: References: Message-ID: <0135d82fe7f94299ab470f76db2c1143@huawei.com> Hi, Thanks for reviewing this, Zhengyu. I have tagged for approval. Felix > -----Original Message----- > From: Zhengyu Gu [mailto:zgu at redhat.com] > Sent: Monday, April 26, 2021 1:59 AM > To: Yangfei (Felix) ; jdk8u-dev dev at openjdk.java.net> > Subject: Re: RFR(XS): 8217348: assert(thread->is_Java_thread()) failed: just > checking > > LGTM. > > -Zhengyu > > On 4/25/21 2:30 AM, Yangfei (Felix) wrote: > > Hi, > > > > Please review this backport of one trivial change fixing an obvious typo: > > > > Original Bug: > > https://bugs.openjdk.java.net/browse/JDK-8217348 > > http://hg.openjdk.java.net/jdk/jdk13/rev/09ee0bd26bda > > > > This was once biting us in our internal development. > > Original patch does not apply cleanly to 8u due to changes in surrounding > context. > > > > 8u webrev: > > http://cr.openjdk.java.net/~fyang/8217348-8u/webrev.00 > > > > Testing: > > Performed full jtreg tests with a fastdebug build. > > > > Thanks, > > Felix > > From shade at redhat.com Mon Apr 26 07:46:41 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 09:46:41 +0200 Subject: [8u] RFR 8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported In-Reply-To: References: Message-ID: <499fa0cb-1485-4763-1533-7f4ea6ac13dc@redhat.com> On 4/23/21 3:06 PM, Zhengyu Gu wrote: > I would like to backport this patch to 8u for parity with Oracle 8u301. > > The original bug: https://bugs.openjdk.java.net/browse/JDK-8134672 > The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/af678f2593e2 > > The original patch does not apply cleanly to 8u. The only conflict is > copyright year. > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8134672-8u/webrev.00/ This looks fine. -- Thanks, -Aleksey From shade at redhat.com Mon Apr 26 09:37:01 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 11:37:01 +0200 Subject: PING [8u] RFR 8264816: Weak handles leak causes GC to take longer In-Reply-To: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com> References: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com> Message-ID: <84056e47-e982-ce8f-b860-25eacc4c3491@redhat.com> On 4/23/21 2:25 PM, Denghui Dong wrote: > Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 > webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 OK, I can reproduce it with the test from: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html ...with: $ build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -Xmx16m -verbose:gc -XX:+PrintGCDetails -XX:+PrintReferenceGC Test 2>&1 | grep "JNI Weak" | awk '{ print $25; }' It is a very slow leak, but plotting the data from the command above shows it happens without the patch, and stops happening with the patch. And in JDK 10, this is resolved by JDK-8174749 that caches the MemberName in ResolvedMemberName properly. Okay then! Minor nit: typo, "destory": // destory the old handle -- Thanks, -Aleksey From denghui.ddh at alibaba-inc.com Mon Apr 26 11:05:18 2021 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Mon, 26 Apr 2021 19:05:18 +0800 Subject: =?UTF-8?B?UmU6IFBJTkcgWzh1XSBSRlIgODI2NDgxNjogV2VhayBoYW5kbGVzIGxlYWsgY2F1c2VzIEdD?= =?UTF-8?B?IHRvIHRha2UgbG9uZ2Vy?= In-Reply-To: <84056e47-e982-ce8f-b860-25eacc4c3491@redhat.com> References: <2ba6a159-ac60-4552-8209-5c1a49eda268.denghui.ddh@alibaba-inc.com>, <84056e47-e982-ce8f-b860-25eacc4c3491@redhat.com> Message-ID: <90637ecd-9942-4b33-b28d-5f22767428a6.denghui.ddh@alibaba-inc.com> Thanks for the review! I have tagged for approval. Denghui ------------------------------------------------------------------ From:Aleksey Shipilev Send Time:2021?4?26?(???) 17:37 To:???(??) ; jdk8u-dev Subject:Re: PING [8u] RFR 8264816: Weak handles leak causes GC to take longer On 4/23/21 2:25 PM, Denghui Dong wrote: > Could I have a review of this small fix that solve the weak handles leak problem that exists in MembernameTable. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8264816 > webrev: http://cr.openjdk.java.net/~ddong/8264816/webrev.00 OK, I can reproduce it with the test from: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013618.html ...with: $ build/linux-x86_64-normal-server-fastdebug/images/j2sdk-image/bin/java -Xmx16m -verbose:gc -XX:+PrintGCDetails -XX:+PrintReferenceGC Test 2>&1 | grep "JNI Weak" | awk '{ print $25; }' It is a very slow leak, but plotting the data from the command above shows it happens without the patch, and stops happening with the patch. And in JDK 10, this is resolved by JDK-8174749 that caches the MemberName in ResolvedMemberName properly. Okay then! Minor nit: typo, "destory": // destory the old handle -- Thanks, -Aleksey From zgu at redhat.com Mon Apr 26 12:15:18 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 26 Apr 2021 08:15:18 -0400 Subject: [8u] RFR 8134672: [TEST_BUG] Some tests should check isDisplayChangeSupported In-Reply-To: <499fa0cb-1485-4763-1533-7f4ea6ac13dc@redhat.com> References: <499fa0cb-1485-4763-1533-7f4ea6ac13dc@redhat.com> Message-ID: <40abbf41-1739-c779-8b9c-9c11969e1c9b@redhat.com> Thanks, Aleksey. Tagged for approval. -Zhengyu On 4/26/21 3:46 AM, Aleksey Shipilev wrote: > On 4/23/21 3:06 PM, Zhengyu Gu wrote: >> I would like to backport this patch to 8u for parity with Oracle 8u301. >> >> The original bug: https://bugs.openjdk.java.net/browse/JDK-8134672 >> The original patch: https://hg.openjdk.java.net/jdk/jdk/rev/af678f2593e2 >> >> The original patch does not apply cleanly to 8u. The only conflict is >> copyright year. >> >> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8134672-8u/webrev.00/ > > This looks fine. > From sgehwolf at redhat.com Mon Apr 26 12:39:01 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Apr 2021 14:39:01 +0200 Subject: [8u] RFR 8254631: Better support ALPN byte wire values in SunJSSE In-Reply-To: <140ad267-cb65-bb87-f3d2-f6dca105db2e@redhat.com> References: <140ad267-cb65-bb87-f3d2-f6dca105db2e@redhat.com> Message-ID: Hi Martin, Just a nit on the changed test. Looks fine otherwise. On Thu, 2021-04-22 at 16:14 -0300, Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of JDK-8254631 [1]. > > Webrev.00: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8254631/8254631.webrev.jdk8u.jdk.00/ > > The 11u patch does not apply cleanly because of the following reasons: > > ?* Paths need to be converted to the old scheme OK. > ?* java.security changes need to be propagated through the different > java.security- files OK. > ?* AlpnGreaseTest.java uses a java.util.Arrays public API not available > in 8u (introduced by JDK-8033148 [2]). > ? * Fixed creating copies of the arrays to compare. 89 System.arraycopy(bytes, i, a1, 0, greaseBytes.length); 90 System.arraycopy(greaseBytes, 0, a2, 0, greaseBytes.length); 91 if (Arrays.equals(a1, a2)) { I don't think we'd need to copy greaseBytes for this array comparison, do we? Can't we use 'Arrays.equals(a1, greaseBytes)'? Better yet, don't do a copy at all and just do a simple search using a ByteBuffer like this: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8254631.test-fix.patch ?* AlpnGreaseTest.java uses ByteBuffer::flip that returns a ByteBuffer. In 8u JDK-4774077 [3] is not present so Buffer::flip gets called and a Buffer is returned. This is a problem because ::get(byte[]) is then invoked and this is not available in the Buffer class (but in ByteBuffer). ? * Fixed with a simple casting. OK. Thanks, Severin From felix.yang at huawei.com Mon Apr 26 12:52:11 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 26 Apr 2021 12:52:11 +0000 Subject: RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Message-ID: Hi, I find issue JDK-8239477 [1] is triggering for 16 jfr jtreg tests with fastdebug build. Fix for this issue depends on JDK-8233019 as it emits a compare with metadataConst(0). So need to backport JDK-8233019 first. Original bug: https://bugs.openjdk.java.net/browse/JDK-8233019 https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e1b6631cbd2f Original patch does not apply to 8u cleanly. Two adaptations are made for 8u: 1. Discarded changes in file c1_LIRGenerator.cpp as JDK-8150669 [2] is not there in 8u. 2. Added new test hotspot/test/compiler/intrinsics/class/TestClassIsPrimitive.java which was introduced by [2] and further modified by this issue. 8u webrev: http://cr.openjdk.java.net/~fyang/8233019-8u/webrev.00 Performed full jtreg test on both aarch64 and x86_64 linux platforms. Thanks, Felix [1] https://bugs.openjdk.java.net/browse/JDK-8239477 [2] https://bugs.openjdk.java.net/browse/JDK-8150669 From shade at redhat.com Mon Apr 26 13:00:16 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 15:00:16 +0200 Subject: RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: <269ebb2d-fc29-9490-d7e1-eefd92efcddf@redhat.com> On 4/26/21 2:52 PM, Yangfei (Felix) wrote: > I find issue JDK-8239477 [1] is triggering for 16 jfr jtreg tests with fastdebug build. > Fix for this issue depends on JDK-8233019 as it emits a compare with metadataConst(0). > So need to backport JDK-8233019 first. > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8233019 > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e1b6631cbd2f > > Original patch does not apply to 8u cleanly. Two adaptations are made for 8u: > 1. Discarded changes in file c1_LIRGenerator.cpp as JDK-8150669 [2] is not there in 8u. > 2. Added new test hotspot/test/compiler/intrinsics/class/TestClassIsPrimitive.java which was introduced by [2] and further modified by this issue. Honestly, I would consider backporting JDK-8150669 first. It seems quite small: https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d15b795cdf21 Otherwise, we are splicing the fix under the unrelated synopsis... Let 8u maintainers decide. -- Thanks, -Aleksey From shade at redhat.com Mon Apr 26 16:16:09 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 18:16:09 +0200 Subject: [8u] RFR (XS) 8265978: make test should look for more locations when searching for exit code Message-ID: <7b3d0ab2-6cc5-4d95-d603-29e0ffd484d9@redhat.com> This is 8u-specific build system bug: https://bugs.openjdk.java.net/browse/JDK-8265978 I believe there is a little omission in the code that checks the exitcode. See the bugreport for more details. 8u fix: https://cr.openjdk.java.net/~shade/8265978/webrev.8u.01/ Testing: failing tests now report non-zero exitcode -- Thanks, -Aleksey From shade at redhat.com Mon Apr 26 17:45:32 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 19:45:32 +0200 Subject: [8u] RFR (S) 8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u Message-ID: <86d90fc2-b889-b5c0-67bb-ab81f27f862c@redhat.com> This is 8u-specific testbug: https://bugs.openjdk.java.net/browse/JDK-8265988 These tests were introduced to 8u with JDK-8031145. But it cannot really run on 8u, because it uses JDK 9+ module patching. I fixed them to use -Xbootclasspath/p:. 8u webrev: https://cr.openjdk.java.net/~shade/8265978/webrev.8u.01/ Testing: affected test (fails before, now passes) -- Thanks, -Aleksey From shade at redhat.com Mon Apr 26 17:46:50 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Apr 2021 19:46:50 +0200 Subject: [8u] RFR (S) 8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u In-Reply-To: <86d90fc2-b889-b5c0-67bb-ab81f27f862c@redhat.com> References: <86d90fc2-b889-b5c0-67bb-ab81f27f862c@redhat.com> Message-ID: On 4/26/21 7:45 PM, Aleksey Shipilev wrote: > This is 8u-specific testbug: > https://bugs.openjdk.java.net/browse/JDK-8265988 > > These tests were introduced to 8u with JDK-8031145. But it cannot really run on 8u, because it uses > JDK 9+ module patching. I fixed them to use -Xbootclasspath/p:. > > 8u webrev: Wrong webrev in the last mail, sorry. This is the correct one: https://cr.openjdk.java.net/~shade/8265988/webrev.8u.01/ -- Thanks, -Aleksey From aph at redhat.com Tue Apr 27 08:54:41 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 27 Apr 2021 09:54:41 +0100 Subject: [8u] RFR (S) 8071374: Native disassembler implementation may be not thread-safe In-Reply-To: <526cfccd-42b6-277f-b5b8-abcb0b23513e@redhat.com> References: <526cfccd-42b6-277f-b5b8-abcb0b23513e@redhat.com> Message-ID: <0fa67d97-4683-19a0-af08-512b477d5fc2@redhat.com> Looks good. On 4/23/21 10:37 AM, Aleksey Shipilev wrote: > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8071374 > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/116a12504a2f > > This still bites me with 8u JMH runs. The Stress reproducer from the issue also fails without this > patch and passes with it. > > Unfortunately, the patch has a few conflicts when applied to 8u: > - at times, the context near print_cr-s is different enough for automatic patch to fail; > - there are no PrintAssemblyOption in 8u (added later by JEP 165); > - there is no jvmciCompilerToVM.cpp (added later by JEP 243); > > 8u webrev: > https://cr.openjdk.java.net/~shade/8071374/webrev.8u.01/ > > Testing: reproducer from the test (now passes); adhoc JMH perfasm runs (now reliable); hotspot_tier1 > -- 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 Tue Apr 27 08:57:58 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 10:57:58 +0200 Subject: [8u] RFR (S) 8071374: Native disassembler implementation may be not thread-safe In-Reply-To: <0fa67d97-4683-19a0-af08-512b477d5fc2@redhat.com> References: <526cfccd-42b6-277f-b5b8-abcb0b23513e@redhat.com> <0fa67d97-4683-19a0-af08-512b477d5fc2@redhat.com> Message-ID: On 4/27/21 10:54 AM, Andrew Haley wrote: > Looks good. Thanks, tagged for approval. -- -Aleksey From shade at redhat.com Tue Apr 27 09:44:33 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 11:44:33 +0200 Subject: [8u] RFR (S) 8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out" Message-ID: <53c95c86-4aa4-32e2-2d3c-d7a7d03c8261@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8205014 https://hg.openjdk.java.net/jdk/sandbox/rev/85305a50b1b4 This is apparently missing in 8u TLS 1.3 backport! This thing is kinda unusual, because it backports the patch from sandbox. The patch also does not apply cleanly, and I had to reapply it by hand. There are conflicts in both ProblemList and the code itself. 8u webrev: https://cr.openjdk.java.net/~shade/8205014/webrev.8u.01/ Testing: affected test (used to fail, now passes) -- Thanks, -Aleksey From shade at redhat.com Tue Apr 27 09:52:02 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 11:52:02 +0200 Subject: [8u] RFR (S) 8065215: Print warning summary at end of configure Message-ID: <43a6cc4b-a735-8d1f-45d2-714c9ed64145@redhat.com> Original RFE: https://bugs.openjdk.java.net/browse/JDK-8065215 https://hg.openjdk.java.net/jdk9/jdk9/rev/eefa97d0d263 I would like to backport this 8u build system change to improve error detection during configure. This also allows cleaner backport of JDK-8079891. The patch has a few minor differences: *) There is no CUSTOM_SUMMARY_AND_WARNINGS_HOOK, no configure.ac hunk does not apply automatically; *) There are no relevant "has been successfully created" blocks in help.m4; *) generated-configure.sh is obviously different; 8u webrev: https://cr.openjdk.java.net/~shade/8065215/webrev.8u.01/ Testing: 8u build; injecting synthetic AS_MSG_WARN into .m4 files shows the warning at the end of configure -- Thanks, -Aleksey From shade at redhat.com Tue Apr 27 09:59:40 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 11:59:40 +0200 Subject: [8u] RFR (S) 8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u In-Reply-To: <52c1c4f9752cce741ef620c19c92d61b5bf6c97b.camel@redhat.com> References: <86d90fc2-b889-b5c0-67bb-ab81f27f862c@redhat.com> <52c1c4f9752cce741ef620c19c92d61b5bf6c97b.camel@redhat.com> Message-ID: On 4/27/21 11:58 AM, Severin Gehwolf wrote: >> Wrong webrev in the last mail, sorry. This is the correct one: >> ?? https://cr.openjdk.java.net/~shade/8265988/webrev.8u.01/ > > This looks fine. Thanks, tagged for approvals. -- -Aleksey From sgehwolf at redhat.com Tue Apr 27 09:58:00 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 27 Apr 2021 11:58:00 +0200 Subject: [8u] RFR (S) 8265988: Fix sun/text/IntHashtable/Bug4170614 for JDK 8u In-Reply-To: References: <86d90fc2-b889-b5c0-67bb-ab81f27f862c@redhat.com> Message-ID: <52c1c4f9752cce741ef620c19c92d61b5bf6c97b.camel@redhat.com> On Mon, 2021-04-26 at 19:46 +0200, Aleksey Shipilev wrote: > On 4/26/21 7:45 PM, Aleksey Shipilev wrote: > > This is 8u-specific testbug: > > ??? https://bugs.openjdk.java.net/browse/JDK-8265988 > > > > These tests were introduced to 8u with JDK-8031145. But it cannot > > really run on 8u, because it uses > > JDK 9+ module patching. I fixed them to use -Xbootclasspath/p:. > > > > 8u webrev: > > Wrong webrev in the last mail, sorry. This is the correct one: > ?? https://cr.openjdk.java.net/~shade/8265988/webrev.8u.01/ This looks fine. Thanks, Severin From shade at redhat.com Tue Apr 27 10:01:45 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 12:01:45 +0200 Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8079891 https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09 I would like to have this simple build feature in 8u to better report configuration logs from 8u CIs. This patch applies mostly trivially, with the following changes: *) Blocks mentioning CONFIGURESUPPORT_OUTPUTDIR are removed, as these are not relevant to 8u build system; *) Minor contextual conflicts are resolved; Current patch needs JDK-8065215 applied first to get the help block at the end of configure. This also needs JDK-8080082 as the follow-up. Testing: 8u build; observing configure.log in build artifacts -- Thanks, -Aleksey From shade at redhat.com Tue Apr 27 10:09:35 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 12:09:35 +0200 Subject: [8u] RFR (XS) 8080082: configure fails if you create an empty directory and then run configure from it Message-ID: Original fix: https://bugs.openjdk.java.net/browse/JDK-8080082 https://hg.openjdk.java.net/jdk9/jdk9/rev/2038a6987213 This is a follow up for JDK-8079891 backport. There are no changes, but generated-configure.sh needs merging with current state of 8u. 8u webrev: https://cr.openjdk.java.net/~shade/8080082/webrev.8u.01/ Testing: running ./configure from empty dir (used to fail, now passes) -- Thanks, -Aleksey From akozlov at azul.com Tue Apr 27 11:36:39 2021 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 27 Apr 2021 14:36:39 +0300 Subject: RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: <47805fc1-21df-cd17-a742-9f45ee8ecc72@azul.com> References: <47805fc1-21df-cd17-a742-9f45ee8ecc72@azul.com> Message-ID: Ping? On 4/19/21 10:04 AM, Anton Kozlov wrote: > Hi, > > Original bug: > ? https://bugs.openjdk.java.net/browse/JDK-8264640 > ? https://github.com/openjdk/jdk13u-dev/commit/efc81a3d > > Please review a backport of the fix for CMS. The issue originally manifested in > 8u. Original patch applied almost cleanly, except adjustments for very minor > context differences (obj->mark vs obj->mark_raw). > > 8u webrev: > ? http://cr.openjdk.java.net/~akozlov/8264640/8.webrev/ > > Testing: x86_64 build, hotspot tier1 (2 test failures before and after this patch) > > Thanks, > Anton From felix.yang at huawei.com Tue Apr 27 12:18:28 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 27 Apr 2021 12:18:28 +0000 Subject: RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: <269ebb2d-fc29-9490-d7e1-eefd92efcddf@redhat.com> References: <269ebb2d-fc29-9490-d7e1-eefd92efcddf@redhat.com> Message-ID: Hi, Thanks for the quick reply :-) > -----Original Message----- > From: Aleksey Shipilev [mailto:shade at redhat.com] > Sent: Monday, April 26, 2021 9:00 PM > To: Yangfei (Felix) ; jdk8u-dev dev at openjdk.java.net> > Subject: Re: RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns wrong > result if Klass* is aligned to 32bit > > On 4/26/21 2:52 PM, Yangfei (Felix) wrote: > > I find issue JDK-8239477 [1] is triggering for 16 jfr jtreg tests with fastdebug > build. > > Fix for this issue depends on JDK-8233019 as it emits a compare with > metadataConst(0). > > So need to backport JDK-8233019 first. > > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8233019 > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/e1b6631cbd2f > > > > Original patch does not apply to 8u cleanly. Two adaptations are made for > 8u: > > 1. Discarded changes in file c1_LIRGenerator.cpp as JDK-8150669 [2] is not > there in 8u. > > 2. Added new test > hotspot/test/compiler/intrinsics/class/TestClassIsPrimitive.java which was > introduced by [2] and further modified by this issue. > > Honestly, I would consider backporting JDK-8150669 first. It seems quite small: > https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/d15b795cdf21 > > Otherwise, we are splicing the fix under the unrelated synopsis... > > Let 8u maintainers decide. Yes, I agree it will be more cleaner if we backport JDK-8150669 first. And I am happy to propose another 8u webrev for JDK-8150669 if it's OK for 8u maintainers. Felix From sgehwolf at redhat.com Tue Apr 27 12:21:09 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 27 Apr 2021 14:21:09 +0200 Subject: [8u] RFR (S) 8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out" In-Reply-To: <53c95c86-4aa4-32e2-2d3c-d7a7d03c8261@redhat.com> References: <53c95c86-4aa4-32e2-2d3c-d7a7d03c8261@redhat.com> Message-ID: <132916807f14c2d31158457860a8b3c27e1346e9.camel@redhat.com> On Tue, 2021-04-27 at 11:44 +0200, Aleksey Shipilev wrote: > Original fix: > ?? https://bugs.openjdk.java.net/browse/JDK-8205014 > ?? https://hg.openjdk.java.net/jdk/sandbox/rev/85305a50b1b4 > > This is apparently missing in 8u TLS 1.3 backport! This thing is kinda > unusual, because it backports the patch from sandbox. The patch also > does not apply cleanly, and I had to reapply it by hand. In later JDKs this got added with: 8196584: TLS 1.3 Implementation $ hg diff -c 68fa3d4026ea --stat | grep DeadSSLLdap test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java | 5 +- $ hg diff -c 68fa3d4026ea test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java diff --git a/test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java b/test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java --- a/test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java +++ b/test/jdk/com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2011, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -67,7 +67,8 @@ public void performOp(InitialContext ctx) throws NamingException {} public void handleNamingException(NamingException e, long start, long end) { - if (e.getCause() instanceof SocketTimeoutException) { + if (e.getCause() instanceof SocketTimeoutException + || e.getCause().getCause() instanceof SocketTimeoutException) { // SSL connect will timeout via readReply using // SocketTimeoutException e.printStackTrace(); There are conflicts in both ProblemList and the code itself. 8u webrev: ?? https://cr.openjdk.java.net/~shade/8205014/webrev.8u.01/ Looks fine to me. Thanks, Severin From shade at redhat.com Tue Apr 27 12:45:27 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 14:45:27 +0200 Subject: [8u] RFR (S) 8205014: com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java failed with "Read timed out" In-Reply-To: <132916807f14c2d31158457860a8b3c27e1346e9.camel@redhat.com> References: <53c95c86-4aa4-32e2-2d3c-d7a7d03c8261@redhat.com> <132916807f14c2d31158457860a8b3c27e1346e9.camel@redhat.com> Message-ID: <808b166d-ffc8-e8b5-2566-370ca467750d@redhat.com> On 4/27/21 2:21 PM, Severin Gehwolf wrote: > 8u webrev: > ?? https://cr.openjdk.java.net/~shade/8205014/webrev.8u.01/ > > Looks fine to me. Thanks, I tagged this for approvals. -- -Aleksey From sgehwolf at redhat.com Tue Apr 27 13:09:43 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 27 Apr 2021 15:09:43 +0200 Subject: [8u] RFR (XS) 8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> References: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> Message-ID: <2d198ee790ab678a991e2322cdf4850529fe1ed1.camel@redhat.com> On Mon, 2021-04-19 at 16:23 +0200, Aleksey Shipilev wrote: > 8u variant: > > diff -r 7ab0ec535776 src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp > --- a/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp??????Thu Oct 24 16:28:51 2019 +0200 > +++ b/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp??????Mon Apr 19 10:54:12 2021 +0200 > @@ -178,7 +178,7 @@ > ??? // avoid unnecessary crash when libjsig is not preloaded, try handle signals > ??? // that do not require siginfo/ucontext first. > > -? if (sig == SIGPIPE) { > +? if (sig == SIGPIPE || sig == SIGXFSZ) { > ????? if (os::Aix::chained_handler(sig, info, ucVoid)) { > ??????? return 1; > ????? } else { > diff -r 7ab0ec535776 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp??Thu Oct 24 16:28:51 2019 +0200 > +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp??Mon Apr 19 10:54:12 2021 +0200 > @@ -185,7 +185,7 @@ > ??? // avoid unnecessary crash when libjsig is not preloaded, try handle signals > ??? // that do not require siginfo/ucontext first. > > -? if (sig == SIGPIPE) { > +? if (sig == SIGPIPE || sig == SIGXFSZ) { > ????? if (os::Linux::chained_handler(sig, info, ucVoid)) { > ??????? return true; > ????? } else { This looks fine. Thanks, Severin From shade at redhat.com Tue Apr 27 13:11:30 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Apr 2021 15:11:30 +0200 Subject: [8u] RFR (XS) 8255734: VM should ignore SIGXFSZ on ppc64, s390 too In-Reply-To: <2d198ee790ab678a991e2322cdf4850529fe1ed1.camel@redhat.com> References: <0a6c91da-d5ce-e612-d305-d57bcc49ac18@redhat.com> <2d198ee790ab678a991e2322cdf4850529fe1ed1.camel@redhat.com> Message-ID: <735de564-ebcb-dfbe-e589-26b6a4813ac0@redhat.com> On 4/27/21 3:09 PM, Severin Gehwolf wrote: > On Mon, 2021-04-19 at 16:23 +0200, Aleksey Shipilev wrote: >> 8u variant: >> >> diff -r 7ab0ec535776 src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp >> --- a/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp??????Thu Oct 24 16:28:51 2019 +0200 >> +++ b/src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp??????Mon Apr 19 10:54:12 2021 +0200 >> @@ -178,7 +178,7 @@ >> ??? // avoid unnecessary crash when libjsig is not preloaded, try handle signals >> ??? // that do not require siginfo/ucontext first. >> >> -? if (sig == SIGPIPE) { >> +? if (sig == SIGPIPE || sig == SIGXFSZ) { >> ????? if (os::Aix::chained_handler(sig, info, ucVoid)) { >> ??????? return 1; >> ????? } else { >> diff -r 7ab0ec535776 src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp >> --- a/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp??Thu Oct 24 16:28:51 2019 +0200 >> +++ b/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp??Mon Apr 19 10:54:12 2021 +0200 >> @@ -185,7 +185,7 @@ >> ??? // avoid unnecessary crash when libjsig is not preloaded, try handle signals >> ??? // that do not require siginfo/ucontext first. >> >> -? if (sig == SIGPIPE) { >> +? if (sig == SIGPIPE || sig == SIGXFSZ) { >> ????? if (os::Linux::chained_handler(sig, info, ucVoid)) { >> ??????? return true; >> ????? } else { > > This looks fine. Thank you, already tagged for approvals. -- -Aleksey From hohensee at amazon.com Tue Apr 27 13:17:42 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 13:17:42 +0000 Subject: RFR: 8264640: CMS ParScanClosure misses a barrier Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Anton Kozlov Date: Tuesday, April 27, 2021 at 4:38 AM To: "jdk8u-dev at openjdk.java.net" Subject: Re: RFR: 8264640: CMS ParScanClosure misses a barrier Ping? On 4/19/21 10:04 AM, Anton Kozlov wrote: > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8264640 > https://github.com/openjdk/jdk13u-dev/commit/efc81a3d > > Please review a backport of the fix for CMS. The issue originally manifested in > 8u. Original patch applied almost cleanly, except adjustments for very minor > context differences (obj->mark vs obj->mark_raw). > > 8u webrev: > http://cr.openjdk.java.net/~akozlov/8264640/8.webrev/ > > Testing: x86_64 build, hotspot tier1 (2 test failures before and after this patch) > > Thanks, > Anton From hohensee at amazon.com Tue Apr 27 13:20:26 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 13:20:26 +0000 Subject: [8u] RFR (XS) 8080082: configure fails if you create an empty directory and then run configure from it Message-ID: <448C242A-B195-4E8F-92DD-B6DDA60CA7EC@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Aleksey Shipilev Date: Tuesday, April 27, 2021 at 3:12 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR (XS) 8080082: configure fails if you create an empty directory and then run configure from it Original fix: https://bugs.openjdk.java.net/browse/JDK-8080082 https://hg.openjdk.java.net/jdk9/jdk9/rev/2038a6987213 This is a follow up for JDK-8079891 backport. There are no changes, but generated-configure.sh needs merging with current state of 8u. 8u webrev: https://cr.openjdk.java.net/~shade/8080082/webrev.8u.01/ Testing: running ./configure from empty dir (used to fail, now passes) -- Thanks, -Aleksey From hohensee at amazon.com Tue Apr 27 13:47:20 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 13:47:20 +0000 Subject: [8u] RFR (XS) 8265978: make test should look for more locations when searching for exit code Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Aleksey Shipilev Date: Monday, April 26, 2021 at 10:18 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR (XS) 8265978: make test should look for more locations when searching for exit code This is 8u-specific build system bug: https://bugs.openjdk.java.net/browse/JDK-8265978 I believe there is a little omission in the code that checks the exitcode. See the bugreport for more details. 8u fix: https://cr.openjdk.java.net/~shade/8265978/webrev.8u.01/ Testing: failing tests now report non-zero exitcode -- Thanks, -Aleksey From akozlov at azul.com Tue Apr 27 13:47:54 2021 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 27 Apr 2021 16:47:54 +0300 Subject: RFR: 8264640: CMS ParScanClosure misses a barrier In-Reply-To: References: Message-ID: Paul, thanks! -- Anton On 4/27/21 4:17 PM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Anton Kozlov > Date: Tuesday, April 27, 2021 at 4:38 AM > To: "jdk8u-dev at openjdk.java.net" > Subject: Re: RFR: 8264640: CMS ParScanClosure misses a barrier > > Ping? > > On 4/19/21 10:04 AM, Anton Kozlov wrote: >> Hi, >> >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8264640 >> https://github.com/openjdk/jdk13u-dev/commit/efc81a3d >> >> Please review a backport of the fix for CMS. The issue originally manifested in >> 8u. Original patch applied almost cleanly, except adjustments for very minor >> context differences (obj->mark vs obj->mark_raw). >> >> 8u webrev: >> http://cr.openjdk.java.net/~akozlov/8264640/8.webrev/ >> >> Testing: x86_64 build, hotspot tier1 (2 test failures before and after this patch) >> >> Thanks, >> Anton > > From hohensee at amazon.com Tue Apr 27 14:09:57 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 14:09:57 +0000 Subject: [8u] RFR (S) 8065215: Print warning summary at end of configure Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Aleksey Shipilev Date: Tuesday, April 27, 2021 at 2:53 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR (S) 8065215: Print warning summary at end of configure Original RFE: https://bugs.openjdk.java.net/browse/JDK-8065215 https://hg.openjdk.java.net/jdk9/jdk9/rev/eefa97d0d263 I would like to backport this 8u build system change to improve error detection during configure. This also allows cleaner backport of JDK-8079891. The patch has a few minor differences: *) There is no CUSTOM_SUMMARY_AND_WARNINGS_HOOK, no configure.ac hunk does not apply automatically; *) There are no relevant "has been successfully created" blocks in help.m4; *) generated-configure.sh is obviously different; 8u webrev: https://cr.openjdk.java.net/~shade/8065215/webrev.8u.01/ Testing: 8u build; injecting synthetic AS_MSG_WARN into .m4 files shows the warning at the end of configure -- Thanks, -Aleksey From hohensee at amazon.com Tue Apr 27 14:13:45 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 14:13:45 +0000 Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log Message-ID: <7527B677-E06C-44D6-80B9-DCCC9222FB5B@amazon.com> 8u webrev? Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Aleksey Shipilev Date: Tuesday, April 27, 2021 at 3:02 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR (S) 8079891: Store configure log in $BUILD/configure.log Original RFE: https://bugs.openjdk.java.net/browse/JDK-8079891 https://hg.openjdk.java.net/jdk9/jdk9/rev/98e85b507b09 I would like to have this simple build feature in 8u to better report configuration logs from 8u CIs. This patch applies mostly trivially, with the following changes: *) Blocks mentioning CONFIGURESUPPORT_OUTPUTDIR are removed, as these are not relevant to 8u build system; *) Minor contextual conflicts are resolved; Current patch needs JDK-8065215 applied first to get the help block at the end of configure. This also needs JDK-8080082 as the follow-up. Testing: 8u build; observing configure.log in build artifacts -- Thanks, -Aleksey From hohensee at amazon.com Tue Apr 27 14:57:10 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 14:57:10 +0000 Subject: [8u] RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks Message-ID: <8F211D6A-9B68-4075-BE64-D656FA9F2593@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Saturday, April 24, 2021 at 6:10 AM To: jdk8u-dev Subject: [8u] RFR: 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks Hi, Please review the backport of JDK-8257670 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8257670 Original change: https://github.com/openjdk/jdk/commit/39b8a2e6 11u backport: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/0fdf7159d5c2 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257670/webrev.00/ 8u exported patch: https://cr.openjdk.java.net/~akasko/jdk8u/8257670/8257670_8u.changeset This change is a follow-up to JDK-8256818 (review thread [1]) and needs to be applied on top of it. The change to the jtreg @run tag is not applicable to 8u, because the test requires a native lib and is already marked as manual in 8u. Testing: checked that changed test passes. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013695.html -- -Alex From hohensee at amazon.com Tue Apr 27 15:00:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 15:00:32 +0000 Subject: [8u] RFR: 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 Message-ID: <8A652667-0706-4803-B810-4C8514438D45@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Saturday, April 24, 2021 at 6:12 AM To: jdk8u-dev Subject: Re: [8u] RFR: 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports leaks after JDK-8257884 On 4/20/21, Alex Kashchenko wrote: > Hi, > > Please review the backport of JDK-8257997 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8257997 > > Original changeset: https://github.com/openjdk/jdk/commit/29ffffa7 > > 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/webrev.00/ > > [...] > Updated webrev following up the comments from JDK-8256818 review thread [1]: 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/webrev.01/ 8u exported commit: https://cr.openjdk.java.net/~akasko/jdk8u/8257997/8257997_8u_rework.changeset This change is a follow-up to JDK-8256818 (review thread [1]), JDK-8257670 [2] and JDK-8257884 [3] and needs to be applied on top of them. Testing: checked that changed test passes on Windows and Linux. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013695.html [2] https://bugs.openjdk.java.net/browse/JDK-8257670 [3] https://bugs.openjdk.java.net/browse/JDK-8257884 -- -Alex From hohensee at amazon.com Tue Apr 27 15:03:51 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 15:03:51 +0000 Subject: [8u] RFR: 8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Saturday, April 24, 2021 at 6:11 AM To: jdk8u-dev Subject: [8u] RFR: 8257884: Re-enable sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java as automatic test Hi, Please review the backport of JDK-8257884 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8257884 Original change: https://github.com/openjdk/jdk/commit/fae7961a 11u backport: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/59a6aaef42a7 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8257884/webrev.00/ 8u exported commit: https://cr.openjdk.java.net/~akasko/jdk8u/8257884/8257884_8u.changeset This change is a follow-up to JDK-8256818 (review thread [1]) and JDK-8257670 [2] and needs to be applied on top of them. It requires minor adjustemts, because jdk.test.lib.Platform API used there is not available in 8u. Testing: checked that changed test can be compiled, it fails in my environment reporting found leaks, this problem with it is mitigated with a follow-up change JDK-8257997 [3]. [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013695.html [2] https://bugs.openjdk.java.net/browse/JDK-8257670 [3] https://bugs.openjdk.java.net/browse/JDK-8257997 -- -Alex From hohensee at amazon.com Tue Apr 27 16:01:27 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 16:01:27 +0000 Subject: [8u] RFR: 8198411: [TEST_BUG] Two java2d tests are unstable in mach5 Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Alex Kashchenko Date: Tuesday, December 1, 2020 at 5:01 AM To: jdk8u-dev Subject: [8u] RFR: 8198411: [TEST_BUG] Two java2d tests are unstable in mach5 Hi, Please review the backport of JDK-8198411 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8198411 Original change: https://hg.openjdk.java.net/jdk/jdk/raw-rev/af2ed7605f8c 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8198411/webrev.00/ For 8u changes to ProblemList are excluded and paths are changed. Testing: checked that changed tests pass on Linux and Windows. -- -Alex From hohensee at amazon.com Tue Apr 27 16:02:44 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 16:02:44 +0000 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Message-ID: Reviewed all three. Thanks, Paul ?-----Original Message----- From: Alex Kashchenko Date: Saturday, April 24, 2021 at 6:16 AM To: "Hohensee, Paul" Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources On 4/22/21, Hohensee, Paul wrote: > You're correct, there's no overlap. Looks fine. Thanks for the review! > > 11u contains 3 separate follow-up backports, so it would be best to do the > same for 8u. Posted these three backports for review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013712.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013713.html https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013714.html > > Thanks, > Paul > > -----Original Message----- > From: Alex Kashchenko > Date: Tuesday, April 20, 2021 at 12:57 PM > To: "Hohensee, Paul" > Cc: "jdk8u-dev at openjdk.java.net" > Subject: RE: [8u] RFR: 8256818: SSLSocket that is never bound or connected > leaks socket resources > > Hi, > > On 4/15/21, Alex Kashchenko wrote: >> On 4/15/21, Hohensee, Paul wrote: >>> This patch needs updating. E.g., the IOException catch code in >>> SocketImpl.java is already in 8u. >> >> Thanks for your comments! I will revisit the patch and prepare the >> updated version shortly. > > I've re-checked that the patch can be applied to the latest 8u-dev, it > appeared that recent IOException changes do not overlap with it. > > In mainline this patch required 3 follow-up commits with minor fixes > to the test. I've combined these patches into one 8u backport and > posted it for review here: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013678.html > > I think it will make sense to push this backport together with the > follow-up one. > > >> >>> >>> Thanks, >>> Paul >>> >>> -----Original Message----- >>> From: jdk8u-dev on behalf of Alex >>> Kashchenko >>> Date: Monday, January 4, 2021 at 2:11 PM >>> To: "jdk8u-dev at openjdk.java.net" >>> Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected >>> leaks >>> socket resources >>> >>> Hi, >>> >>> Please review the backport of JDK-8256818 to 8u: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 >>> >>> Original change: https://github.com/openjdk/jdk/commit/93b6ab56 >>> >>> 11u change: >>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 >>> >>> Some details on current 11u behaviour (also applicable to 8u): >>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html >>> >>> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ >>> >>> Code change to SSLSocketImpl.java applies cleanly after path change. >>> SSLSocketLeak.java test needs to be adapted for 8u: to get the number >>> of process handles on Windows native lib is required; there is no >>> support for building native test libs in 8u, because of this >>> libFileUtils.c is placed into the same directory where test is; test >>> is marked as "manual" and "native" and comment with details about >>> shared lib is added to the test; test is adapted to load shared lib >>> directly without going through FileUtils; changes to CheckHandles.java >>> are not applicable to 8u, because corresponding change JDK-8239893 is >>> not in 8u. >>> >>> Testing: checked that added test passes on Linux and Windows, ran >>> jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . >>> >>> -- >>> -Alex >>> >>> >>> >> >> >> -- >> -Alex >> > > > -- > -Alex > > > -- -Alex From hohensee at amazon.com Tue Apr 27 17:07:49 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 17:07:49 +0000 Subject: =?utf-8?B?UmU6IOWbnuWkjTogSkRLLTgyNTcwMzk6IE1lbW9yeSBhbGxvY2F0ZWQgYnkg?= =?utf-8?B?R2VuZXJpY1Rhc2tRdWV1ZTo6X2FycmF5X2FsbG9jYXRvciBtYXkgYmUgZG91?= =?utf-8?Q?ble_freed(Internet_mail)?= In-Reply-To: References: Message-ID: Do you need a sponsor? ?-----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 12:06 PM To: "wattsun(??)" , "jdk8u-dev at openjdk.java.net" Subject: RE: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Lgtm. -----Original Message----- From: "wattsun(??)" Date: Thursday, April 15, 2021 at 5:37 AM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Thanks for your reply, Paul. make sense, both methods can eliminate the risk of double-free , and free the memory in ~ArrayAllocator is more reasonable. Update the patch: diff -r 91b61f678a19 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Sat Mar 27 19:01:26 2021 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Thu Apr 15 20:32:02 2021 +0800 @@ -430,9 +430,7 @@ } template -GenericTaskQueue::~GenericTaskQueue() { - FREE_C_HEAP_ARRAY(E, _elems, F); -} +GenericTaskQueue::~GenericTaskQueue() {} // OverflowTaskQueue is a TaskQueue that also includes an overflow stack for // elements that do not fit in the TaskQueue. Thanks wattsun -----????----- ???: Hohensee, Paul ????: 2021?4?15? 5:16 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) { assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From hohensee at amazon.com Tue Apr 27 18:12:28 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 18:12:28 +0000 Subject: [8u] RFR 8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object Message-ID: Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Zhengyu Gu Date: Monday, January 18, 2021 at 7:22 AM To: jdk8u-dev Subject: [8u] RFR 8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object Hi, I would like to backport this patch to openjdk8u, for parity with Oracle 8u291. The original patch applies cleanly. However, the test failed on Fedora due to component layout issue. Please see comments in bug for details. I added a delay to ensure that layout is stable before test starts to execute. diff -r 15ca08c8faf5 test/javax/swing/JComboBox/8072767/bug8072767.java --- a/test/javax/swing/JComboBox/8072767/bug8072767.java Wed Apr 15 14:38:13 2015 +0400 +++ b/test/javax/swing/JComboBox/8072767/bug8072767.java Mon Jan 18 10:11:16 2021 -0500 @@ -59,12 +59,12 @@ robot.setAutoDelay(50); SwingUtilities.invokeAndWait(bug8072767::createAndShowGUI); robot.waitForIdle(); + robot.delay(500); SwingUtilities.invokeAndWait(() -> { point = table.getLocationOnScreen(); Rectangle rect = table.getCellRect(0, 0, true); point.translate(rect.width / 2, rect.height / 2); }); Original bug: https://bugs.openjdk.java.net/browse/JDK-8072767 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2ca1d772b1f1 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8072767-8u/webrev.00/ Test: Test passed on Fedora/Ubuntu Linux x86_64 Thanks, -Zhengyu From hohensee at amazon.com Tue Apr 27 18:20:22 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 18:20:22 +0000 Subject: RFR: 8u backport of JDK-8239886 Minimal VM build fails after JDK-8237499 Message-ID: <6F9B942A-F80C-4F0A-B3BD-AE7247A37EAD@amazon.com> Lgtm. Do you need a sponsor? Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Yang Yi Reply-To: Yang Yi Date: Tuesday, January 26, 2021 at 4:06 AM To: jdk8u-dev Subject: RFR: 8u backport of JDK-8239886 Minimal VM build fails after JDK-8237499 Hi, Please help review this minor backport. This is a follow-up backport. As mentioned[1] before, the minimized VM fails to build after backporting of JDK-8237499[2], this backport[3] solves the problem, it has only a few line changes. Webrev: http://cr.openjdk.java.net/~ddong/yiyang/8239886/ Thanks, Yang Yi ---- [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013343.html [2] https://bugs.openjdk.java.net/browse/JDK-8237499 [3] https://bugs.openjdk.java.net/browse/JDK-8239886 From zgu at redhat.com Tue Apr 27 18:25:19 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 27 Apr 2021 14:25:19 -0400 Subject: [8u] RFR 8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object In-Reply-To: References: Message-ID: Thanks, Paul. Tagged for approval. -Zhengyu On 4/27/21 2:12 PM, Hohensee, Paul wrote: > Lgtm. > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Monday, January 18, 2021 at 7:22 AM > To: jdk8u-dev > Subject: [8u] RFR 8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object > > Hi, > > I would like to backport this patch to openjdk8u, for parity with Oracle > 8u291. > > The original patch applies cleanly. However, the test failed on Fedora > due to component layout issue. Please see comments in bug for details. > > I added a delay to ensure that layout is stable before test starts to > execute. > > diff -r 15ca08c8faf5 test/javax/swing/JComboBox/8072767/bug8072767.java > --- a/test/javax/swing/JComboBox/8072767/bug8072767.java Wed Apr > 15 14:38:13 2015 +0400 > +++ b/test/javax/swing/JComboBox/8072767/bug8072767.java Mon Jan > 18 10:11:16 2021 -0500 > @@ -59,12 +59,12 @@ > robot.setAutoDelay(50); > SwingUtilities.invokeAndWait(bug8072767::createAndShowGUI); > robot.waitForIdle(); > + robot.delay(500); > SwingUtilities.invokeAndWait(() -> { > point = table.getLocationOnScreen(); > Rectangle rect = table.getCellRect(0, 0, true); > point.translate(rect.width / 2, rect.height / 2); > }); > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8072767 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2ca1d772b1f1 > > 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8072767-8u/webrev.00/ > > Test: > Test passed on Fedora/Ubuntu Linux x86_64 > > Thanks, > > -Zhengyu > > From hohensee at amazon.com Tue Apr 27 18:32:32 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 18:32:32 +0000 Subject: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Message-ID: <642A1A9B-EE96-40B0-ABDE-7D6656C59133@amazon.com> Lgtm. Do you need a sponsor? Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Yang Yi Date: Wednesday, February 17, 2021 at 9:27 PM To: Yang Yi , Andrew Hughes Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Gentle Ping v2 :-) ------------------Original Mail ------------------ Sender:Yang Yi Send Date:Thu Feb 4 11:08:39 2021 Recipients:Andrew Hughes CC:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Hi Andrew, Thanks to your explanation, it makes sense, I have updated my patch according to your change. Webrev: HotSpot Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/hotspot-webrev.01/ JDK Part: http://cr.openjdk.java.net/~ddong/yiyang/8237499/jdk-webrev/ Cheers, Yang Yi ------------------------------------------------------------------ From:Andrew Hughes Send Time:2021 Feb. 4 (Thu.) 01:45 To:"YANG, Yi" Cc:jdk8u-dev at openjdk.java.net Subject:Re: PING: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event On 19:52 Tue 02 Feb , Yang Yi wrote: > Hi Andrew, > > Do you mean I should update my patch to add these three functions together so that they work as a whole rather than adding them one by one in the future? > > Please let me know if I misunderstand your reply. > > Thanks, > Yang Yi > Yes, that's correct. In other words, please add my patch to what you have and provide an updated webrev :-) 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 akashche at redhat.com Tue Apr 27 19:38:49 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Tue, 27 Apr 2021 20:38:49 +0100 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources In-Reply-To: References: Message-ID: On 4/27/21, Hohensee, Paul wrote: > Reviewed all three. Thanks for the reviews! Added Fix Requests to all of them. > > Thanks, > Paul > > ?-----Original Message----- > From: Alex Kashchenko > Date: Saturday, April 24, 2021 at 6:16 AM > To: "Hohensee, Paul" > Cc: "jdk8u-dev at openjdk.java.net" > Subject: RE: [8u] RFR: 8256818: SSLSocket that is never bound or connected > leaks socket resources > > On 4/22/21, Hohensee, Paul wrote: >> You're correct, there's no overlap. Looks fine. > > Thanks for the review! > >> >> 11u contains 3 separate follow-up backports, so it would be best to do >> the >> same for 8u. > > Posted these three backports for review: > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013712.html > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013713.html > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013714.html > > >> >> Thanks, >> Paul >> >> -----Original Message----- >> From: Alex Kashchenko >> Date: Tuesday, April 20, 2021 at 12:57 PM >> To: "Hohensee, Paul" >> Cc: "jdk8u-dev at openjdk.java.net" >> Subject: RE: [8u] RFR: 8256818: SSLSocket that is never bound or >> connected >> leaks socket resources >> >> Hi, >> >> On 4/15/21, Alex Kashchenko wrote: >>> On 4/15/21, Hohensee, Paul wrote: >>>> This patch needs updating. E.g., the IOException catch code in >>>> SocketImpl.java is already in 8u. >>> >>> Thanks for your comments! I will revisit the patch and prepare the >>> updated version shortly. >> >> I've re-checked that the patch can be applied to the latest 8u-dev, it >> appeared that recent IOException changes do not overlap with it. >> >> In mainline this patch required 3 follow-up commits with minor fixes >> to the test. I've combined these patches into one 8u backport and >> posted it for review here: >> >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-April/013678.html >> >> I think it will make sense to push this backport together with the >> follow-up one. >> >> >>> >>>> >>>> Thanks, >>>> Paul >>>> >>>> -----Original Message----- >>>> From: jdk8u-dev on behalf of Alex >>>> Kashchenko >>>> Date: Monday, January 4, 2021 at 2:11 PM >>>> To: "jdk8u-dev at openjdk.java.net" >>>> Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected >>>> leaks >>>> socket resources >>>> >>>> Hi, >>>> >>>> Please review the backport of JDK-8256818 to 8u: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8256818 >>>> >>>> Original change: https://github.com/openjdk/jdk/commit/93b6ab56 >>>> >>>> 11u change: >>>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/8f9ce4460636 >>>> >>>> Some details on current 11u behaviour (also applicable to 8u): >>>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004507.html >>>> >>>> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8256818/webrev.00/ >>>> >>>> Code change to SSLSocketImpl.java applies cleanly after path change. >>>> SSLSocketLeak.java test needs to be adapted for 8u: to get the number >>>> of process handles on Windows native lib is required; there is no >>>> support for building native test libs in 8u, because of this >>>> libFileUtils.c is placed into the same directory where test is; test >>>> is marked as "manual" and "native" and comment with details about >>>> shared lib is added to the test; test is adapted to load shared lib >>>> directly without going through FileUtils; changes to CheckHandles.java >>>> are not applicable to 8u, because corresponding change JDK-8239893 is >>>> not in 8u. >>>> >>>> Testing: checked that added test passes on Linux and Windows, ran >>>> jtreg:jdk/sun/security/ssl/ and jck:api/javax_net/ssl . >>>> >>>> -- >>>> -Alex >>>> >>>> >>>> >>> >>> >>> -- >>> -Alex >>> >> >> >> -- >> -Alex >> >> >> > > > -- > -Alex > > > -- -Alex From hohensee at amazon.com Tue Apr 27 20:17:40 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 20:17:40 +0000 Subject: [8u] RFR: 8261952: Avoid converting path to vcruntime140.dll to short-style path Message-ID: Why not backport 8201267? Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Dmitry Cherepanov Date: Thursday, February 18, 2021 at 4:59 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: 8261952: Avoid converting path to vcruntime140.dll to short-style path Bug: https://bugs.openjdk.java.net/browse/JDK-8261952 Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8261952/webrev.v0/ Please review the partial backport for Windows build with VS 2017. This is to avoid converting path to vcruntime140.dll to short-style path (with vcrunt~1.dll) In JDK 11, it was fixed as a part of https://bugs.openjdk.java.net/browse/JDK-8201267 From original RFR: https://mail.openjdk.java.net/pipermail/build-dev/2018-April/021563.html * In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all directories sent in here are already fixed. Calling it here messes up the filename of the dll, which in VS2017 is more than 8 chars. Thanks, Dmitry From hohensee at amazon.com Tue Apr 27 20:26:17 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 20:26:17 +0000 Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead Message-ID: <7C189E0A-9849-4C76-82A3-6F80E6BF29C3@amazon.com> Why not backport 8032050 first? It isn't very big, in fact most of it is waitFor(). Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Zhengyu Gu Date: Monday, March 15, 2021 at 10:21 AM To: jdk8u-dev Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead Hi, I would like to backport this patch to 8u for parity with Oracle 8u301. Original bug: https://bugs.openjdk.java.net/browse/JDK-8035000 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1b599b4755bd The original patch applies cleanly. However, patched RMID.java uses waitFor(long timeout) method, that was introduced by JDK-8032050 [1] and it is not backported to 8u. Therefore, I propose backport this specific function from JDK-8032050 with this patch. --- old/test/java/rmi/testlibrary/JavaVM.java 2021-03-15 13:03:32.298020591 -0400 +++ new/test/java/rmi/testlibrary/JavaVM.java 2021-03-15 13:03:32.157020372 -0400 @@ -26,6 +26,7 @@ import java.io.OutputStream; import java.util.Arrays; import java.util.StringTokenizer; +import java.util.concurrent.TimeoutException; /** * RMI regression test utility class that uses Runtime.exec to spawn a @@ -183,6 +184,39 @@ errPipe.join(); return status; } + /** + * Causes the current thread to wait the vm process to exit, if necessary, + * wait until the vm process has terminated, or the specified waiting time + * elapses. Release allocated input/output after vm process has terminated. + * @param timeout the maximum milliseconds to wait. + * @return exit value for vm process. + * @throws InterruptedException if the current thread is interrupted + * while waiting. + * @throws TimeoutException if subprocess does not end after timeout + * milliseconds passed + */ + public int waitFor(long timeout) + throws InterruptedException, TimeoutException { + if (vm == null) + throw new IllegalStateException("can't wait for JavaVM that isn't running"); + long startTime = System.currentTimeMillis(); + long rem = timeout; + + do { + try { + int status = vm.exitValue(); + outPipe.join(); + errPipe.join(); + return status; + } catch (IllegalThreadStateException ex) { + if (rem > 0) { + Thread.sleep(Math.min(rem, 100)); + } + } + rem = timeout - (System.currentTimeMillis() - startTime); + } while (rem > 0); + throw new TimeoutException(); + } /** * Starts the subprocess, waits for it to exit, and returns its exit status. Thanks, -Zhengyu [1] https://bugs.openjdk.java.net/browse/JDK-8032050 From hohensee at amazon.com Tue Apr 27 20:32:56 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 20:32:56 +0000 Subject: [8u] RFR: 8187450: JNI local refs exceeds capacity warning in NetworkInterface::getAll Message-ID: <3BC86A5D-7CEF-4E44-BBBB-8659F217CFB5@amazon.com> Lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Jonathan Dowland Date: Thursday, March 25, 2021 at 2:59 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR: 8187450: JNI local refs exceeds capacity warning in NetworkInterface::getAll Good morning, I'm requesting a review of a backport of JDK-8187450 to 8u. The patch (from 11u backport) does not apply cleanly, just one hunk due to extra #if defined(AF_INET6) in the context. Bug: https://bugs.openjdk.java.net/browse/JDK-8187450 Webrev: https://cr.openjdk.java.net/~jdowland/webrevs/JDK-8187450/webrev.jdk8u.00/ Testing notes: test/java/net/NetworkInterface/Test.java passes. I had two tier1 failures that I am confident are unrelated, and also fail for me against a known-good 8u: tools/javac/diags/CheckExamples.java: provide examples of code that generate diagnostics tools/javac/fatalErrors/NoJavaLangTest.java: Verify that the compiler does not crash when java.lang is not they fail with jtreg The rest of tier1 passed. If you want to check out the impact this change makes, on a Linux host you can use network namespaces to isolate the number of network interfaces that are visible to Java, and steadily add more (virtual) interfaces. There are some shell script snippets in the original GitHub PR that might be useful: https://github.com/openjdk/jdk/pull/2963 My results comparing before/after this patch for 8u are baseline, 2 network interfaces sufficient to breach the local refs limit: $ sudo ip netns exec jbase ip link show | grep UP | wc -l 2 $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest WARNING: JNI local refs: 33, exceeds capacity: 32 at java.net.NetworkInterface.getAll(Native Method) at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355) at NITest.main(NITest.java:4) after patch, the first local refs breach occurs with 5 interfaces: ... $ ./addif.sh 4 5 interfaces $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest WARNING: JNI local refs: 33, exceeds capacity: 32 at java.net.NetworkInterface.getAll(Native Method) at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355) at NITest.main(NITest.java:4) after patch, it takes 10 interfaces to breach the next limit ... $ ./addif.sh 9 10 interfaces $ sudo ip netns exec jbase $JAVA_HOME/bin/java -Xcheck:jni NITest WARNING: JNI local refs: 33, exceeds capacity: 32 at java.net.NetworkInterface.getAll(Native Method) at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355) at NITest.main(NITest.java:4) WARNING: JNI local refs: 66, exceeds capacity: 65 at java.net.NetworkInterface.getAll(Native Method) at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:355) at NITest.main(NITest.java:4) -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From hohensee at amazon.com Tue Apr 27 20:54:48 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 27 Apr 2021 20:54:48 +0000 Subject: [8u] RFR (S) 8207779: Method::is_valid_method() compares 'this' with NULL Message-ID: I'd add the modified assert in restore_unshareable_info() in method.cpp, even though it's not present right now. Otherwise lgtm. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Aleksey Shipilev Date: Thursday, April 15, 2021 at 8:25 AM To: "jdk8u-dev at openjdk.java.net" Subject: [8u] RFR (S) 8207779: Method::is_valid_method() compares 'this' with NULL Original bug: https://bugs.openjdk.java.net/browse/JDK-8207779 https://hg.openjdk.java.net/jdk/jdk/rev/b5aac518b097 I was looking at backporting this to 8u as the pre-requisite for JDK-8231949. I have suggested JDK-8231949 without this pre-requisite, which also matches how 11u backported without this fix. But, I think the fix is actually simple enough to backport and it dodges UB as a good bonus. The patch does not apply to 8u cleanly, and requires adjustments to fit the context differences. I grepped the source for is_valid_method to catch all other places where this needs to be adjusted. 8u webrev: https://cr.openjdk.java.net/~shade/8207779/webrev.8u.01 Testing: Linux x86_64 fastdebug, {tier1, jdk_jfr} -- Thanks, -Aleksey From wattsun at tencent.com Wed Apr 28 01:48:47 2021 From: wattsun at tencent.com (=?utf-8?B?d2F0dHN1bijlrZnlrocp?=) Date: Wed, 28 Apr 2021 01:48:47 +0000 Subject: =?utf-8?B?5Zue5aSNOiDlm57lpI06IEpESy04MjU3MDM5OiBNZW1vcnkgYWxsb2NhdGVk?= =?utf-8?B?IGJ5IEdlbmVyaWNUYXNrUXVldWU6Ol9hcnJheV9hbGxvY2F0b3IgbWF5IGJl?= =?utf-8?Q?_double_freed(Internet_mail)?= In-Reply-To: References: Message-ID: <5a88376555424b9f8cb0cf93bf21e560@tencent.com> Hi,Paul Yes, I need a sponsor, Thank you very much. Yours watt -----????----- ???: Hohensee, Paul ????: 2021?4?28? 1:08 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: Re: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Do you need a sponsor? ?-----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 12:06 PM To: "wattsun(??)" , "jdk8u-dev at openjdk.java.net" Subject: RE: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Lgtm. -----Original Message----- From: "wattsun(??)" Date: Thursday, April 15, 2021 at 5:37 AM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Thanks for your reply, Paul. make sense, both methods can eliminate the risk of double-free , and free the memory in ~ArrayAllocator is more reasonable. Update the patch: diff -r 91b61f678a19 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Sat Mar 27 19:01:26 2021 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Thu Apr 15 20:32:02 2021 +0800 @@ -430,9 +430,7 @@ } template -GenericTaskQueue::~GenericTaskQueue() { - FREE_C_HEAP_ARRAY(E, _elems, F); -} +GenericTaskQueue::~GenericTaskQueue() {} // OverflowTaskQueue is a TaskQueue that also includes an overflow stack for // elements that do not fit in the TaskQueue. Thanks wattsun -----????----- ???: Hohensee, Paul ????: 2021?4?15? 5:16 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) +{ assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From hedongbo at huawei.com Wed Apr 28 07:38:28 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Wed, 28 Apr 2021 15:38:28 +0800 Subject: [8u] RFR 8266191: Missing aarch64 parts of JDK-8181872(C1: possible overflow when strength reducing integer multiply by constant) Message-ID: Original fix: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 https://bugs.openjdk.java.net/browse/JDK-8181872 8u(aarch64 platforms) webrev: http://cr.openjdk.java.net/~dongbohe/8266191/webrev.00/ Note that JDK-8181872 got backported to OpenJDK 8u. Released with 8u252. Aarch64 port got integrated with 8u292 (JDK-8257192). Since JDK-8181872 got backported earlier, the aarch64 code is missing the aarch64 part of https://bugs.openjdk.java.net/browse/JDK-8181872 Testing: tier1 -- thanks, hedongbo From aph at redhat.com Wed Apr 28 08:28:20 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Apr 2021 09:28:20 +0100 Subject: [8u] RFR 8266191: Missing aarch64 parts of JDK-8181872(C1: possible overflow when strength reducing integer multiply by constant) In-Reply-To: References: Message-ID: <256068bb-3664-daa5-89b5-0060dec47fa4@redhat.com> On 4/28/21 8:38 AM, He Dongbo(JVM) wrote: > Original fix: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 > https://bugs.openjdk.java.net/browse/JDK-8181872 > > 8u(aarch64 platforms) webrev: > http://cr.openjdk.java.net/~dongbohe/8266191/webrev.00/ > > Note that JDK-8181872 got backported to OpenJDK 8u. Released with 8u252. Aarch64 port got integrated with 8u292 (JDK-8257192). Since JDK-8181872 got backported earlier, the aarch64 code is missing the aarch64 part of > https://bugs.openjdk.java.net/browse/JDK-8181872 > > Testing: tier1 Looks fine. -- 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 hedongbo at huawei.com Wed Apr 28 08:34:57 2021 From: hedongbo at huawei.com (He Dongbo(JVM)) Date: Wed, 28 Apr 2021 16:34:57 +0800 Subject: [8u] RFR 8266191: Missing aarch64 parts of JDK-8181872(C1: possible overflow when strength reducing integer multiply by constant) In-Reply-To: <256068bb-3664-daa5-89b5-0060dec47fa4@redhat.com> References: <256068bb-3664-daa5-89b5-0060dec47fa4@redhat.com> Message-ID: <1a57eb93-637f-7ef2-882a-3a9b2430f141@huawei.com> Thanks, Andrew Haley. Tagged. On 4/28/2021 4:28 PM, Andrew Haley wrote: > On 4/28/21 8:38 AM, He Dongbo(JVM) wrote: >> Original fix: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/16c9c159df90 >> https://bugs.openjdk.java.net/browse/JDK-8181872 >> >> 8u(aarch64 platforms) webrev: >> http://cr.openjdk.java.net/~dongbohe/8266191/webrev.00/ >> >> Note that JDK-8181872 got backported to OpenJDK 8u. Released with 8u252. Aarch64 port got integrated with 8u292 (JDK-8257192). Since JDK-8181872 got backported earlier, the aarch64 code is missing the aarch64 part of >> https://bugs.openjdk.java.net/browse/JDK-8181872 >> >> Testing: tier1 > Looks fine. > -- thanks, hedongbo From dcherepanov at azul.com Wed Apr 28 09:04:07 2021 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Wed, 28 Apr 2021 12:04:07 +0300 Subject: [8u] RFR: 8261952: Avoid converting path to vcruntime140.dll to short-style path In-Reply-To: References: Message-ID: <047c4bf3-62e4-574c-ef39-76318b25e00f@azul.com> Hi Paul, 8201267 is about disabling warnings and I don't see a good justification for full backport of 8201267 (even if some of these warnings apply to 8u). The proposed patch fixes build failure (when 8u built with pre-installed VS 2017) and it's probably worth backporting it to 8u. Thanks, Dmitry On 27.04.2021 23:17, Hohensee, Paul wrote: > Why not backport 8201267? > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Dmitry Cherepanov > Date: Thursday, February 18, 2021 at 4:59 AM > To: "jdk8u-dev at openjdk.java.net" > Subject: [8u] RFR: 8261952: Avoid converting path to vcruntime140.dll to short-style path > > Bug: https://bugs.openjdk.java.net/browse/JDK-8261952 > Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8261952/webrev.v0/ > > Please review the partial backport for Windows build with VS 2017. > This is to avoid converting path to vcruntime140.dll to short-style path (with vcrunt~1.dll) > > In JDK 11, it was fixed as a part of https://bugs.openjdk.java.net/browse/JDK-8201267 > From original RFR: https://mail.openjdk.java.net/pipermail/build-dev/2018-April/021563.html > > * In toolchain_windows.m4, the BASIC_FIXUP_PATH was redundant as all > directories sent in here are already fixed. Calling it here messes up > the filename of the dll, which in VS2017 is more than 8 chars. > > Thanks, > > Dmitry > > From wilkinsona at vmware.com Wed Apr 28 10:35:02 2021 From: wilkinsona at vmware.com (Andy Wilkinson) Date: Wed, 28 Apr 2021 10:35:02 +0000 Subject: =?Windows-1252?Q?JDK-8157190_=96_back_port_of_JDK-8156584_to_JDK_8?= Message-ID: <8C9415EA-DC6D-48A1-8DFF-BD4462B3D680@vmware.com> Hello, I am a maintainer of Spring Boot and a recent change to our CI environment resulted in us being affected [1] by JDK-8156584 [2]. We have worked around the problem [3] but were wondering if the possible back port of the fix to JDK 8, which is being tracked by JDK-8157190 [4], could be rekindled? Thanks, Andy [1] https://github.com/spring-projects/spring-boot/issues/26252 [2] https://bugs.openjdk.java.net/browse/JDK-8156584 [3] https://github.com/spring-projects/spring-boot/commit/912c82e50de096ff35ce31910ea8388298b0193e [4] https://bugs.openjdk.java.net/browse/JDK-8157190 From aph at redhat.com Wed Apr 28 12:52:52 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Apr 2021 13:52:52 +0100 Subject: [aarch64-port-dev ] [8u]RFR:backporting JDK-8069191 to 8u In-Reply-To: <32a42b09-f9bb-49e4-b8cb-de46ded05d82.zhuoren.wz@alibaba-inc.com> References: <32a42b09-f9bb-49e4-b8cb-de46ded05d82.zhuoren.wz@alibaba-inc.com> Message-ID: <80a1f976-71c1-0354-d10a-a871a76f922c@redhat.com> On 4/28/21 1:20 PM, Wang Zhuo(Zhuoren) wrote: > Please help review this patch. AArch64 JDK8 may crash without this patch. The newly added tests can reproduce this crash on aarch64 platform. > > webrev : http://cr.openjdk.java.net/~wzhuo/8266039/webrev.00/ > JDK-bug: https://bugs.openjdk.java.net/browse/JDK-8266039 Crikey! We really do need Roland to review this one. -- 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 Apr 28 13:26:26 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 28 Apr 2021 09:26:26 -0400 Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead In-Reply-To: <7C189E0A-9849-4C76-82A3-6F80E6BF29C3@amazon.com> References: <7C189E0A-9849-4C76-82A3-6F80E6BF29C3@amazon.com> Message-ID: <09f1fe9f-4a3f-0a3a-903e-ccb80b617810@redhat.com> Hi, Make sense, especially, 8032050 backport is clean. Thanks for the suggestion. -Zhengyu On 4/27/21 4:26 PM, Hohensee, Paul wrote: > Why not backport 8032050 first? It isn't very big, in fact most of it is waitFor(). > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Monday, March 15, 2021 at 10:21 AM > To: jdk8u-dev > Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead > > Hi, > > I would like to backport this patch to 8u for parity with Oracle 8u301. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8035000 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1b599b4755bd > > The original patch applies cleanly. > > However, patched RMID.java uses waitFor(long timeout) method, that was > introduced by JDK-8032050 [1] and it is not backported to 8u. Therefore, > I propose backport this specific function from JDK-8032050 with this patch. > > > --- old/test/java/rmi/testlibrary/JavaVM.java 2021-03-15 > 13:03:32.298020591 -0400 > +++ new/test/java/rmi/testlibrary/JavaVM.java 2021-03-15 > 13:03:32.157020372 -0400 > @@ -26,6 +26,7 @@ > import java.io.OutputStream; > import java.util.Arrays; > import java.util.StringTokenizer; > +import java.util.concurrent.TimeoutException; > > /** > * RMI regression test utility class that uses Runtime.exec to spawn a > @@ -183,6 +184,39 @@ > errPipe.join(); > return status; > } > + /** > + * Causes the current thread to wait the vm process to exit, if > necessary, > + * wait until the vm process has terminated, or the specified > waiting time > + * elapses. Release allocated input/output after vm process has > terminated. > + * @param timeout the maximum milliseconds to wait. > + * @return exit value for vm process. > + * @throws InterruptedException if the current thread is interrupted > + * while waiting. > + * @throws TimeoutException if subprocess does not end after timeout > + * milliseconds passed > + */ > + public int waitFor(long timeout) > + throws InterruptedException, TimeoutException { > + if (vm == null) > + throw new IllegalStateException("can't wait for JavaVM > that isn't running"); > + long startTime = System.currentTimeMillis(); > + long rem = timeout; > + > + do { > + try { > + int status = vm.exitValue(); > + outPipe.join(); > + errPipe.join(); > + return status; > + } catch (IllegalThreadStateException ex) { > + if (rem > 0) { > + Thread.sleep(Math.min(rem, 100)); > + } > + } > + rem = timeout - (System.currentTimeMillis() - startTime); > + } while (rem > 0); > + throw new TimeoutException(); > + } > > /** > * Starts the subprocess, waits for it to exit, and returns its > exit status. > > > Thanks, > > -Zhengyu > > [1] https://bugs.openjdk.java.net/browse/JDK-8032050 > > From zgu at redhat.com Wed Apr 28 13:34:08 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 28 Apr 2021 09:34:08 -0400 Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead In-Reply-To: <7C189E0A-9849-4C76-82A3-6F80E6BF29C3@amazon.com> References: <7C189E0A-9849-4C76-82A3-6F80E6BF29C3@amazon.com> Message-ID: Hi, I would like to withdraw this code review. As Paul suggested, I will backport 8032050 (a clean backport) first, then this patch will be a clean backport. Thanks, -Zhengyu On 4/27/21 4:26 PM, Hohensee, Paul wrote: > Why not backport 8032050 first? It isn't very big, in fact most of it is waitFor(). > > Thanks, > Paul > > ?-----Original Message----- > From: jdk8u-dev on behalf of Zhengyu Gu > Date: Monday, March 15, 2021 at 10:21 AM > To: jdk8u-dev > Subject: [8u] RFR 8263601: TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead > > Hi, > > I would like to backport this patch to 8u for parity with Oracle 8u301. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8035000 > Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1b599b4755bd > > The original patch applies cleanly. > > However, patched RMID.java uses waitFor(long timeout) method, that was > introduced by JDK-8032050 [1] and it is not backported to 8u. Therefore, > I propose backport this specific function from JDK-8032050 with this patch. > > > --- old/test/java/rmi/testlibrary/JavaVM.java 2021-03-15 > 13:03:32.298020591 -0400 > +++ new/test/java/rmi/testlibrary/JavaVM.java 2021-03-15 > 13:03:32.157020372 -0400 > @@ -26,6 +26,7 @@ > import java.io.OutputStream; > import java.util.Arrays; > import java.util.StringTokenizer; > +import java.util.concurrent.TimeoutException; > > /** > * RMI regression test utility class that uses Runtime.exec to spawn a > @@ -183,6 +184,39 @@ > errPipe.join(); > return status; > } > + /** > + * Causes the current thread to wait the vm process to exit, if > necessary, > + * wait until the vm process has terminated, or the specified > waiting time > + * elapses. Release allocated input/output after vm process has > terminated. > + * @param timeout the maximum milliseconds to wait. > + * @return exit value for vm process. > + * @throws InterruptedException if the current thread is interrupted > + * while waiting. > + * @throws TimeoutException if subprocess does not end after timeout > + * milliseconds passed > + */ > + public int waitFor(long timeout) > + throws InterruptedException, TimeoutException { > + if (vm == null) > + throw new IllegalStateException("can't wait for JavaVM > that isn't running"); > + long startTime = System.currentTimeMillis(); > + long rem = timeout; > + > + do { > + try { > + int status = vm.exitValue(); > + outPipe.join(); > + errPipe.join(); > + return status; > + } catch (IllegalThreadStateException ex) { > + if (rem > 0) { > + Thread.sleep(Math.min(rem, 100)); > + } > + } > + rem = timeout - (System.currentTimeMillis() - startTime); > + } while (rem > 0); > + throw new TimeoutException(); > + } > > /** > * Starts the subprocess, waits for it to exit, and returns its > exit status. > > > Thanks, > > -Zhengyu > > [1] https://bugs.openjdk.java.net/browse/JDK-8032050 > > From hohensee at amazon.com Wed Apr 28 14:27:37 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 28 Apr 2021 14:27:37 +0000 Subject: =?utf-8?B?UkU6IOWbnuWkjTogIOWbnuWkjTogSkRLLTgyNTcwMzk6IE1lbW9yeSBhbGxv?= =?utf-8?B?Y2F0ZWQgYnkgR2VuZXJpY1Rhc2tRdWV1ZTo6X2FycmF5X2FsbG9jYXRvciBt?= =?utf-8?Q?ay_be_double_freed(Internet_mail)?= Message-ID: Issue tagged on your behalf. Paul ?-----Original Message----- From: "wattsun(??)" Date: Tuesday, April 27, 2021 at 6:49 PM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Hi,Paul Yes, I need a sponsor, Thank you very much. Yours watt -----????----- ???: Hohensee, Paul ????: 2021?4?28? 1:08 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: Re: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Do you need a sponsor? -----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 12:06 PM To: "wattsun(??)" , "jdk8u-dev at openjdk.java.net" Subject: RE: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Lgtm. -----Original Message----- From: "wattsun(??)" Date: Thursday, April 15, 2021 at 5:37 AM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Thanks for your reply, Paul. make sense, both methods can eliminate the risk of double-free , and free the memory in ~ArrayAllocator is more reasonable. Update the patch: diff -r 91b61f678a19 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Sat Mar 27 19:01:26 2021 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Thu Apr 15 20:32:02 2021 +0800 @@ -430,9 +430,7 @@ } template -GenericTaskQueue::~GenericTaskQueue() { - FREE_C_HEAP_ARRAY(E, _elems, F); -} +GenericTaskQueue::~GenericTaskQueue() {} // OverflowTaskQueue is a TaskQueue that also includes an overflow stack for // elements that do not fit in the TaskQueue. Thanks wattsun -----????----- ???: Hohensee, Paul ????: 2021?4?15? 5:16 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) +{ assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From serge.chernyshev at bell-sw.com Wed Apr 28 14:50:05 2021 From: serge.chernyshev at bell-sw.com (Sergey Chernyshev) Date: Wed, 28 Apr 2021 17:50:05 +0300 Subject: =?UTF-8?Q?Re=3a_JDK-8157190_=e2=80=93_back_port_of_JDK-8156584_to_J?= =?UTF-8?Q?DK_8?= In-Reply-To: <8C9415EA-DC6D-48A1-8DFF-BD4462B3D680@vmware.com> References: <8C9415EA-DC6D-48A1-8DFF-BD4462B3D680@vmware.com> Message-ID: Hi Andy, I see no reason why this should not be backported as it solves the race condition. I'm going to take it for a spin and propose the backport when ready. Thanks, Sergey On 4/28/2021 1:35 PM, Andy Wilkinson wrote: > Hello, > > I am a maintainer of Spring Boot and a recent change to our CI environment resulted in us being affected [1] by JDK-8156584 [2]. We have worked around the problem [3] but were wondering if the possible back port of the fix to JDK 8, which is being tracked by JDK-8157190 [4], could be rekindled? > > Thanks, > Andy > > [1] https://github.com/spring-projects/spring-boot/issues/26252 > [2] https://bugs.openjdk.java.net/browse/JDK-8156584 > [3] https://github.com/spring-projects/spring-boot/commit/912c82e50de096ff35ce31910ea8388298b0193e > [4] https://bugs.openjdk.java.net/browse/JDK-8157190 -- Best regards, Sergey Chernyshev Bellsoft LLC From hohensee at amazon.com Wed Apr 28 20:36:43 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 28 Apr 2021 20:36:43 +0000 Subject: jdk8u-dev MacOS 10.15+ build environment? Message-ID: Restarting this thread. We at Amazon have been building 8u using Xcode 12 for some months, see Ben Taylor's post https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-March/013558.html so that?s what we'd like to see targeted. Several backports have already been done (8200550, 8230428, 8077364, 8055754, 8033289) and another is tagged (8253375). Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Andrew Hughes Date: Tuesday, March 16, 2021 at 8:42 PM To: Simon Tooke Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: jdk8u-dev MacOS 10.15+ build environment? On 08:24 Mon 15 Mar , Simon Tooke wrote: > > On 2021-03-15 7:19 a.m., Andrew Haley wrote: > > On 3/1/21 2:33 PM, Andrew Leonard wrote: > > > > > I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I > > > would like to contribute it upstream to jdk8u-dev, unfortunately the > > > jdk8u-dev supported build platform is MacOS 10.7. Is there a method people > > > use to build & test their contributions if you don't have a MacOS 10.7 > > > environment? The AdoptOpenJDK jdk8u base has patches to allow building > > > jdk8u with Xcode 11.5 on 10.15+.. > > Let's get those patches in, then. Who contributed them? We'd > > need to get them to contribute to 8u. > > Almost all the patches are backports; as they were not bugfixes per se, they > rarely got approved. > > https://github.com/stooke/jdk8u-xcode10 see especially the patch > directories. > > -Simon > From what I remember, they were not proposed as backports but as a separate patch without the source history. I can't see a problem with most of the changes proposed, particularly if they only touch a build configuration (Mac OS) which doesn't work at present. Patches like https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/hotspot/8033289.patch I've backported myself a long time ago in IcedTea. Which version of clang are we targetting? As I said before, with the shared code, a lot of this seems to be warnings from a particular version of clang that will likely be the same on other platforms, and so can be reproduced without needing Mac OS. 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 wattsun at tencent.com Thu Apr 29 02:11:48 2021 From: wattsun at tencent.com (=?utf-8?B?d2F0dHN1bijlrZnlrocp?=) Date: Thu, 29 Apr 2021 02:11:48 +0000 Subject: =?utf-8?B?5Zue5aSNOiDlm57lpI06ICDlm57lpI06IEpESy04MjU3MDM5OiBNZW1vcnkg?= =?utf-8?B?YWxsb2NhdGVkIGJ5IEdlbmVyaWNUYXNrUXVldWU6Ol9hcnJheV9hbGxvY2F0?= =?utf-8?Q?or_may_be_double_freed(Internet_mail)?= In-Reply-To: References: Message-ID: <82dfbadf15b147eeaf83a69467ce8b09@tencent.com> Ok?thanks Paul Watt -----????----- ???: Hohensee, Paul ????: 2021?4?28? 22:28 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: ??: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Issue tagged on your behalf. Paul ?-----Original Message----- From: "wattsun(??)" Date: Tuesday, April 27, 2021 at 6:49 PM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Hi,Paul Yes, I need a sponsor, Thank you very much. Yours watt -----????----- ???: Hohensee, Paul ????: 2021?4?28? 1:08 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: Re: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Do you need a sponsor? -----Original Message----- From: jdk8u-dev on behalf of "Hohensee, Paul" Date: Thursday, April 15, 2021 at 12:06 PM To: "wattsun(??)" , "jdk8u-dev at openjdk.java.net" Subject: RE: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Lgtm. -----Original Message----- From: "wattsun(??)" Date: Thursday, April 15, 2021 at 5:37 AM To: "Hohensee, Paul" , "jdk8u-dev at openjdk.java.net" Subject: ??: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) Thanks for your reply, Paul. make sense, both methods can eliminate the risk of double-free , and free the memory in ~ArrayAllocator is more reasonable. Update the patch: diff -r 91b61f678a19 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Sat Mar 27 19:01:26 2021 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Thu Apr 15 20:32:02 2021 +0800 @@ -430,9 +430,7 @@ } template -GenericTaskQueue::~GenericTaskQueue() { - FREE_C_HEAP_ARRAY(E, _elems, F); -} +GenericTaskQueue::~GenericTaskQueue() {} // OverflowTaskQueue is a TaskQueue that also includes an overflow stack for // elements that do not fit in the TaskQueue. Thanks wattsun -----????----- ???: Hohensee, Paul ????: 2021?4?15? 5:16 ???: wattsun(??) ; jdk8u-dev at openjdk.java.net ??: RE: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed(Internet mail) If I read this correctly, you're disabling ArrayAllocator::free() to accommodate ~GenericTaskQueue, which latter explicitly frees the queue element array. This seems backwards to me because ~GenericTaskQueue currently reachs into the implementation of ArrayAllocator, violating encapsulation. Your original patch, which eliminated the explicit free in ~GenericTaskQueue, removed that reaching and left it up to ~ArrayAllocator to handle it, which is what I'd prefer. Thanks, Paul -----Original Message----- From: jdk8u-dev on behalf of "wattsun(??)" Date: Wednesday, December 23, 2020 at 2:06 AM To: "jdk8u-dev at openjdk.java.net" Subject: JDK-8257039: Memory allocated by GenericTaskQueue::_array_allocator may be double freed Dear All, may I hava this small bug fix to review? Bug: https://bugs.openjdk.java.net/browse/JDK-8257039 the diff: diff -r 83661fdee9f0 src/share/vm/utilities/taskqueue.hpp --- a/src/share/vm/utilities/taskqueue.hpp Wed Nov 18 06:55:35 2020 +0000 +++ b/src/share/vm/utilities/taskqueue.hpp Wed Nov 25 18:10:28 2020 +0800 @@ -314,7 +314,7 @@ }; template -GenericTaskQueue::GenericTaskQueue() { +GenericTaskQueue::GenericTaskQueue() : _array_allocator(false) +{ assert(sizeof(Age) == sizeof(size_t), "Depends on this."); } Thanks! watt From aph at redhat.com Thu Apr 29 07:56:16 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 29 Apr 2021 08:56:16 +0100 Subject: jdk8u-dev MacOS 10.15+ build environment? In-Reply-To: References: Message-ID: On 4/28/21 9:36 PM, Hohensee, Paul wrote: > Restarting this thread. We at Amazon have been building 8u using Xcode 12 for some months, see Ben Taylor's post > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-March/013558.html > > so that?s what we'd like to see targeted. Several backports have already been done (8200550, 8230428, 8077364, 8055754, 8033289) and another is tagged (8253375). So as far as I can see, the only issue is formatting the backports and getting them approved. It'd be very nice to get them done as a group. For what it's worth, I'm on the bleeding edge here because I'm testing AArch64. The patches from Simon Tooke allow an x86 jdk8u build to work in that environment. -- 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 Thu Apr 29 14:05:42 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 29 Apr 2021 14:05:42 +0000 Subject: jdk8u-dev MacOS 10.15+ build environment? Message-ID: <6ABDFE9E-AD0C-4A1F-B995-E99D0F87990E@amazon.com> Working on getting both Simon's and Amazon's (the non-backports based on Simon's) done. ?-----Original Message----- From: jdk8u-dev on behalf of Andrew Haley Date: Thursday, April 29, 2021 at 12:56 AM To: "jdk8u-dev at openjdk.java.net" Subject: RE: jdk8u-dev MacOS 10.15+ build environment? On 4/28/21 9:36 PM, Hohensee, Paul wrote: > Restarting this thread. We at Amazon have been building 8u using Xcode 12 for some months, see Ben Taylor's post > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-March/013558.html > > so that?s what we'd like to see targeted. Several backports have already been done (8200550, 8230428, 8077364, 8055754, 8033289) and another is tagged (8253375). So as far as I can see, the only issue is formatting the backports and getting them approved. It'd be very nice to get them done as a group. For what it's worth, I'm on the bleeding edge here because I'm testing AArch64. The patches from Simon Tooke allow an x86 jdk8u build to work in that environment. -- 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 Thu Apr 29 15:24:45 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 29 Apr 2021 17:24:45 +0200 Subject: Ping? [8u] RFR: 8206925: Support the certificate_authorities extension In-Reply-To: References: Message-ID: <3ee97cc85d184730ed4d59ebb18529852105beda.camel@redhat.com> Anyone? On Tue, 2021-04-20 at 12:23 +0200, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport of the certificate_authorities > extensionj. The OpenJDK 11u patch didn't apply cleanly after path > unshuffeling, but was fairly trivial to resolve. Conflicts caused by: > > 1. X509Authentication.java copyright line conflict only. Resolved > ?? manually. > 2. SSLContextTemplate.java private interface methods not allowed in > ?? JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to > ?? default. Note: this is code used in tests only. > 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the > ?? test invocations since JDK 8u doesn't enable TLSv1.3 on the > ?? client side by default. See JDK-8248721, CSR of the TLSv1.3 8u > ?? backport. > > Other than that, the patch is identical to the OpenJDK 11.0.12 > version > of this patch. > > This introduces a new system property, > jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has > been reused from the Oracle JDK backport. See below. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206925 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248709 > webrev: > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/ > > Testing: sun/security/ssl tests and tier1. No new regressions. > ???????? New tests pass. > > Thoughts? > > Thanks, > Severin From hohensee at amazon.com Thu Apr 29 21:06:41 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 29 Apr 2021 21:06:41 +0000 Subject: [8u] RFR (XS): 8074836: Resolve disabled warnings for libosxkrb5 Message-ID: Please review this syntax-only backport to help make 8u buildable using Xcode 12. Original issues: https://bugs.openjdk.java.net/browse/JDK-8074836 https://bugs.openjdk.java.net/browse/JDK-8074835 Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1f7132eec73c 8u webrev: https://cr.openjdk.java.net/~phh/8074836/webrev.8u.jdk.00/ DISABLED_WARNINGS_clang is not present in 8u, so that part of the patch is omitted. SecurityLibraries.gmk is the 8u equivalent of Lib-java.security.jgss.gmk: the former adds only a comment. The rest of the patch applies cleanly and is syntax-only. 8074835 shares the patch with 8074836. Thanks, Paul From hohensee at amazon.com Thu Apr 29 21:23:20 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 29 Apr 2021 21:23:20 +0000 Subject: [8u] RFR: 8035287: gcc warnings compiling various libraries files Message-ID: Please review this backport to help 8u build using Xcode 12. Original issue: https://bugs.openjdk.java.net/browse/JDK-8035287 Original commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/b97e0a836dc0 8u webrev: https://cr.openjdk.java.net/~phh/8035287/webrev.8u.jdk.00/ The patch applies cleanly, except that the part of awt_LoadLibrary.c patched by the original commit does not exist in 8u, and the patch to XToolKit.c had a context difference. Thanks, Paul From hohensee at amazon.com Thu Apr 29 21:58:35 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 29 Apr 2021 21:58:35 +0000 Subject: [8u] RFR: 8037825: Fix warnings and enable "warnings as errors" in serviceability native libraries Message-ID: <0A810346-152C-4F6D-B14E-2FF2F23518EA@amazon.com> Please review this backport to help 8u build using Xcode 12. Original issue: https://bugs.openjdk.java.net/browse/JDK-8037825 Original commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f5a18100873c 8u webrev: https://cr.openjdk.java.net/~phh/8037825/webrev.8u.jdk.00/ The patch applied cleanly, except that the change to InvocationAdapter.c was already in place, so was left out of the backport. There are no semantic changes. Thanks, Paul From serge.chernyshev at bell-sw.com Fri Apr 30 04:53:51 2021 From: serge.chernyshev at bell-sw.com (Sergey Chernyshev) Date: Fri, 30 Apr 2021 07:53:51 +0300 Subject: [8u] RFR: 8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: References: <8C9415EA-DC6D-48A1-8DFF-BD4462B3D680@vmware.com> Message-ID: <2d582b9f-f80b-8d35-804a-39d2e2dba273@bell-sw.com> Dear colleauges, Here's an 8u backport identical to the one proposed by Martin Buchholz in 2016 here [1]. It got approved in [2], but hasn't been pushed. original fix: ? https://bugs.openjdk.java.net/browse/JDK-8156584 ? http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d7e0283a937c 8u webrev: ? http://cr.openjdk.java.net/~alexsch/sercher/8156584.8u/webrev.00/ The patch applies almost cleanly except for the paths need unshuffling and a difference in the removed code (new HashMap<> needs explicit generic parameters). Testing: compact3, needs_jdk, needs_jre, jdk_security test groups were run. No regressions observed. Thanks, Sergey [1] https://bugs.openjdk.java.net/browse/JDK-8157190 [2] http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013899.html On 4/28/2021 5:50 PM, Sergey Chernyshev wrote: > Hi Andy, > > I see no reason why this should not be backported as it solves the race > condition. I'm going to take it for a spin and propose the backport when > ready. > > Thanks, > Sergey > > On 4/28/2021 1:35 PM, Andy Wilkinson wrote: >> Hello, >> >> I am a maintainer of Spring Boot and a recent change to our CI environment resulted in us being affected [1] by JDK-8156584 [2]. We have worked around the problem [3] but were wondering if the possible back port of the fix to JDK 8, which is being tracked by JDK-8157190 [4], could be rekindled? >> >> Thanks, >> Andy >> >> [1] https://github.com/spring-projects/spring-boot/issues/26252 >> [2] https://bugs.openjdk.java.net/browse/JDK-8156584 >> [3] https://github.com/spring-projects/spring-boot/commit/912c82e50de096ff35ce31910ea8388298b0193e >> [4] https://bugs.openjdk.java.net/browse/JDK-8157190 -- Best regards, Sergey Chernyshev Bellsoft LLC From aph at redhat.com Fri Apr 30 07:50:11 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Apr 2021 08:50:11 +0100 Subject: [8u] RFR: 8156584: Initialization race in sun.security.x509.AlgorithmId.get In-Reply-To: <2d582b9f-f80b-8d35-804a-39d2e2dba273@bell-sw.com> References: <8C9415EA-DC6D-48A1-8DFF-BD4462B3D680@vmware.com> <2d582b9f-f80b-8d35-804a-39d2e2dba273@bell-sw.com> Message-ID: <1aaa9287-8454-67d1-8595-e465134f59a3@redhat.com> On 4/30/21 5:53 AM, Sergey Chernyshev wrote: > Here's an 8u backport identical to the one proposed by Martin Buchholz > in 2016 here [1]. > It got approved in [2], but hasn't been pushed. > > original fix: > ? https://bugs.openjdk.java.net/browse/JDK-8156584 > ? http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d7e0283a937c > > 8u webrev: > ? http://cr.openjdk.java.net/~alexsch/sercher/8156584.8u/webrev.00/ So it's been reviewed already. It just needs an approval request tag. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Fri Apr 30 16:55:39 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 30 Apr 2021 16:55:39 +0000 Subject: jdk8u-dev MacOS 10.15+ build environment? Message-ID: <62CD7EEC-BBD4-42F3-8BC5-D5DEE1A0B8FA@amazon.com> For Corretto, we're using macOS 10.10 and Xcode 6 to build 8u. The 8u build fails with 10.8 + Xcode 4 due to the backport of https://bugs.openjdk.java.net/browse/JDK-8211301, which uses NSFullSizeContentViewWindowMask, which is not present in 10.8. Similarly with https://bugs.openjdk.java.net/browse/JDK-8251546, TCP_KEEPCNT and TCP_KEEPINTVL are not present in 10.8. I suggest we update the minimum macOS build environment. 10.8 and Xcode 4 have been out of support for a long time. If your company delivers macOS 8u binaries, please post your minimum build configuration. Thanks, Paul ?-----Original Message----- From: jdk8u-dev on behalf of Andrew Hughes Date: Tuesday, March 16, 2021 at 8:42 PM To: Simon Tooke Cc: "jdk8u-dev at openjdk.java.net" Subject: RE: jdk8u-dev MacOS 10.15+ build environment? On 08:24 Mon 15 Mar , Simon Tooke wrote: > > On 2021-03-15 7:19 a.m., Andrew Haley wrote: > > On 3/1/21 2:33 PM, Andrew Leonard wrote: > > > > > I have a Mac OS contribution i've developed and tested at AdoptOpenJDK, I > > > would like to contribute it upstream to jdk8u-dev, unfortunately the > > > jdk8u-dev supported build platform is MacOS 10.7. Is there a method people > > > use to build & test their contributions if you don't have a MacOS 10.7 > > > environment? The AdoptOpenJDK jdk8u base has patches to allow building > > > jdk8u with Xcode 11.5 on 10.15+.. > > Let's get those patches in, then. Who contributed them? We'd > > need to get them to contribute to 8u. > > Almost all the patches are backports; as they were not bugfixes per se, they > rarely got approved. > > https://github.com/stooke/jdk8u-xcode10 see especially the patch > directories. > > -Simon > From what I remember, they were not proposed as backports but as a separate patch without the source history. I can't see a problem with most of the changes proposed, particularly if they only touch a build configuration (Mac OS) which doesn't work at present. Patches like https://cr.openjdk.java.net/~phh/jdk8u-xcode12-patches/hotspot/8033289.patch I've backported myself a long time ago in IcedTea. Which version of clang are we targetting? As I said before, with the shared code, a lot of this seems to be warnings from a particular version of clang that will likely be the same on other platforms, and so can be reproduced without needing Mac OS. 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