From akashche at redhat.com Mon Jan 4 22:10:46 2021 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 4 Jan 2021 22:10:46 +0000 Subject: [8u] RFR: 8256818: SSLSocket that is never bound or connected leaks socket resources Message-ID: 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 jdowland at redhat.com Wed Jan 6 11:25:02 2021 From: jdowland at redhat.com (Jonathan Dowland) Date: Wed, 6 Jan 2021 11:25:02 +0000 Subject: Tracking dependencies between backport bugs Message-ID: <20210106112502.c2hf7pts2needqok@qusp> Happy New Year! I'm picking up work on backporting JDK-8196196, which is one of those large test-tagging patches. The current WIP backport patch drops about half of the original patch. In line with prior discussions, I'm now investigating whether the hunks that don't apply in 8u shed light on some other patches that should be backported first. The first concrete example for this bug is the file test/javax/swing/JComboBox/6632953/bug6632953.java, for which the hunk does not apply in 8u yet, because JDK-8078614 ("WindowsClassicLookAndFeel : MetalComboBoxUI.getbaseLine fails with IllegalArgumentException") needs to be applied first. I personally think that JDK-8078614 looks suitable for backporting to 8u, although it might fail on the criteria (it's not an Oracle parity patch I don't think?) My question is: (how) should I record this dependency in JBS? * Should I create a Backport bug for JDK-8078614, and then mark that as a blocker against the backport bug for JDK-8196196 (this already exists, it's JDK-8257838). Note that I'm not sure that I will work on this dependent bug myself (in particular this is a Windows-only bug: although it looks trivial enough I can probably test it to satisfaction, in general I can't work on Window specific bugs). For now I just want to capture all the dependencies of the main backport I'm looking at. Best wishes -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From goetz.lindenmaier at sap.com Wed Jan 6 14:54:48 2021 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 6 Jan 2021 14:54:48 +0000 Subject: Tracking dependencies between backport bugs In-Reply-To: <20210106112502.c2hf7pts2needqok@qusp> References: <20210106112502.c2hf7pts2needqok@qusp> Message-ID: Hi Jonathan, I would not consider this a dependency between the bugs. There is no semantic connection between the two. It's just a conflict in the context, right? Resolving them is trivial. So you should just downport what you want to downport. If you plan to do them both, do them in the right order. If you only want to downport JDK-8196196 do it, and resolve the files. If you think about downporting JDK-8078614, you should consider whether you need the fix in src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java in 8. You should not downport such an issue just because of a conflict in context with a change later in the source. Having conflicts and resolving them is the very business of downporting ?? Best regards, Goetz. > -----Original Message----- > From: jdk8u-dev On Behalf Of Jonathan > Dowland > Sent: Wednesday, January 6, 2021 12:25 PM > To: jdk8u-dev at openjdk.java.net > Subject: Tracking dependencies between backport bugs > > Happy New Year! > > I'm picking up work on backporting JDK-8196196, which is one of those > large test-tagging patches. The current WIP backport patch drops about > half of the original patch. In line with prior discussions, I'm now > investigating whether the hunks that don't apply in 8u shed light on > some other patches that should be backported first. > > The first concrete example for this bug is the file > test/javax/swing/JComboBox/6632953/bug6632953.java, for which the hunk > does not apply in 8u yet, because JDK-8078614 > ("WindowsClassicLookAndFeel : MetalComboBoxUI.getbaseLine fails with > IllegalArgumentException") needs to be applied first. I personally think that > JDK-8078614 looks suitable for backporting to 8u, although it might fail > on the criteria (it's not an Oracle parity patch I don't think?) > > My question is: (how) should I record this dependency in JBS? > > * Should I create a Backport bug for JDK-8078614, and then mark that as > a blocker against the backport bug for JDK-8196196 (this already > exists, it's JDK-8257838). > > Note that I'm not sure that I will work on this dependent bug myself (in > particular this is a Windows-only bug: although it looks trivial enough > I can probably test it to satisfaction, in general I can't work on > Window specific bugs). For now I just want to capture all the > dependencies of the main backport I'm looking at. > > > Best wishes > > -- > ???? Jonathan Dowland > Senior Software Engineer, OpenJDK, Red Hat From jdowland at redhat.com Thu Jan 7 09:41:51 2021 From: jdowland at redhat.com (Jonathan Dowland) Date: Thu, 7 Jan 2021 09:41:51 +0000 Subject: Tracking dependencies between backport bugs In-Reply-To: References: <20210106112502.c2hf7pts2needqok@qusp> Message-ID: <20210107094151.zshtigsjguip3ybe@qusp> Hi, On Wed, Jan 06, 2021 at 02:54:48PM +0000, Lindenmaier, Goetz wrote: > I would not consider this a dependency between the bugs. > There is no semantic connection between the two. > It's just a conflict in the context, right? Thanks for your reply. I agree entirely with the rest of your mail predicated on there being no semantic dependency. But unfortunately I think there is. The "outer-most" bug adds a new labelled statement to a case statement that does not exist in 8u (introduced by the other patch). I'm not sure what issue that case label should related to (it's not relevant to the topic of JDK-8196196, tagging bugs @headful), but my concern would be that if I drop that hunk in this backport, and someone later comes along to backport JDK-8078614, this case label will never be added because both backports would be considered "done". -- ???? Jonathan Dowland Senior Software Engineer, OpenJDK, Red Hat From aph at redhat.com Thu Jan 7 10:49:03 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Jan 2021 10:49:03 +0000 Subject: Tracking dependencies between backport bugs In-Reply-To: <20210106112502.c2hf7pts2needqok@qusp> References: <20210106112502.c2hf7pts2needqok@qusp> Message-ID: <2e811352-1b35-f847-9dff-b902dd3a8b6e@redhat.com> On 1/6/21 11:25 AM, Jonathan Dowland wrote: > I personally think that > JDK-8078614 looks suitable for backporting to 8u, although it might fail > on the criteria (it's not an Oracle parity patch I don't think?) Maybe just backport 8078614. You've already spent more time thinking about it than just fixing the bug. Or maybe just add a comment to 8078614? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Fri Jan 8 03:27:39 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 8 Jan 2021 03:27:39 +0000 Subject: [8u] RFR: JDK-8259384: CUP version wrong in THIRD_PARTY_README after JDK-8233548 Message-ID: <20210108032739.GA683667@rincewind> Bug: https://bugs.openjdk.java.net/browse/JDK-8259384 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8259384/webrev.01/ During the merge of 8u282-b04 into aarch64/shenandoah-jdk8u [0], we spotted an issue with the 8u backport of JDK-8233548, namely that the version was wrongly changed to 0.10b from 0.10k, rather than 0.11b. This set of patches for each repo fixes the version. It also removes an errant trailing space present on the line above in all copies of THIRD_PARTY_README except the jdk one, bringing them into sync with one another. This is only applicable to 8u. The version is correct in the jdk/jdk and jdk-updates/jdk11u versions. Ok for 8u292? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jan 8 04:08:35 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 8 Jan 2021 04:08:35 +0000 Subject: Tracking dependencies between backport bugs In-Reply-To: <20210107094151.zshtigsjguip3ybe@qusp> References: <20210106112502.c2hf7pts2needqok@qusp> <20210107094151.zshtigsjguip3ybe@qusp> Message-ID: <20210108040835.GA684163@rincewind> On 09:41 Thu 07 Jan , Jonathan Dowland wrote: > Hi, > > On Wed, Jan 06, 2021 at 02:54:48PM +0000, Lindenmaier, Goetz wrote: > > I would not consider this a dependency between the bugs. > > There is no semantic connection between the two. > > It's just a conflict in the context, right? > > Thanks for your reply. I agree entirely with the rest of your mail > predicated on there being no semantic dependency. But unfortunately I > think there is. > > The "outer-most" bug adds a new labelled statement to a case statement > that does not exist in 8u (introduced by the other patch). I'm not sure > what issue that case label should related to (it's not relevant to the > topic of JDK-8196196, tagging bugs @headful), but my concern would be > that if I drop that hunk in this backport, and someone later comes along > to backport JDK-8078614, this case label will never be added because > both backports would be considered "done". > > > -- > ???? Jonathan Dowland > Senior Software Engineer, OpenJDK, Red Hat > Definitely sounds like it should be backported. It's bad form for the headful patch to be including additional changes, but we should avoid discarding such hunks where possible. This is also my concern with skipping files that are absent in 8u; if someone later backports the fix that introduces that file, the later change that was discarded in the earlier backport may never be added. The Oracle parity patches are just suggestions as to what we may wish to include. Just because a patch is in that list does not mean it is a good idea for us to backport it as well, and, likewise, there are plenty of patches we have included of our own volition. We don't know the criteria Oracle apply for choosing to include patches, and their reasoning may differ from ours. The main concern with 8u is not to backport patches that are overly disruptive or cause compatibility issues without a very good reason. I don't think this applies to JDK-8078614. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Jan 8 04:12:55 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 8 Jan 2021 04:12:55 +0000 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> <20201215183218.GA131217@rincewind> Message-ID: <20210108041255.GB684163@rincewind> On 03:28 Thu 31 Dec , Yangfei (Felix) wrote: > Hi, > > > -----Original Message----- > > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > > Sent: Wednesday, December 16, 2020 2:32 AM > > To: Yangfei (Felix) > > Cc: jdk8u-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net > > Subject: Re: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u > > > > On 08:57 Sat 28 Nov , Yangfei (Felix) wrote: > > > Hi, > > > > > > > -----Original Message----- > > > > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf > > > > Of Andrew Hughes > > > > Sent: Friday, November 27, 2020 3:34 PM > > > > To: jdk8u-dev at openjdk.java.net > > > > Cc: aarch64-port-dev at openjdk.java.net > > > > Subject: Re: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into > > > > 8u > > > > > > > > On 07:21 Fri 27 Nov , Andrew Hughes wrote: > > > > > Umbrella Bug: https://bugs.openjdk.java.net/browse/JDK-8257192 > > > > > Webrevs: > > > > > > Thanks for bringing this to 8u upstream. > > > > > > I performed some testing on our platforms for the following patches based > > on the latest jdk8u-dev repo (jdk8u282-b03): > > > > > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/root/webrev.01/ > > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/jdk/webrev.01/ > > > > > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.0 > > 2 > > > / > > > > > > 1. Run full jtreg test with release build on x86_64-linux-gnu, no regression > > witnessed. > > > Passed jcstress test on x86_64-linux-gnu. > > > > > > 2. Run full jtreg test with release build on aarch64-linux-gnu, no regression > > witnessed. (Compared with jtreg test result of aarch64 release build from > > latest aarch64-port/jdk8u-shenandoah repo) > > > Passed jcstress test on my 128-core aarch64 Kunpeng server. > > > > > > 3. Performed specjbb2015 test with release build on aarch64-linux-gnu. > > > Performance numbers is reproducible as compared with aarch64 release > > build from latest aarch64-port/jdk8u-shenandoah repo. > > > > > > Hope that helps :-) > > > > > > Best regards, > > > Felix > > > > It does. > > > > Good to know it works for you :-) > > > > I'll make another revision, based on Aleksey's latest comments, and we'll try > > and get this in. > > I find aarch64 release & fastdebug fail to build with the three patches based on the latest jdk8u-dev repo. I am using gcc version 7.5.0. > > sh configure --prefix=/home/yangfei/jdk8u-release --with-jvm-variants=server --with-debug-level=release --enable-unlimited-crypto --with-native-debug-symbols=internal --with-boot-jdk=/home/yangfei/tools/jdk8u275-b01 > > Compile error message: > /home/yangfei/openjdk8u-dev/hotspot/src/cpu/aarch64/vm/aarch64.ad: In member function ?virtual void cmpFastLockNode::emit(CodeBuffer&, PhaseRegAlloc*) const?: > /home/yangfei/openjdk8u-dev/hotspot/src/cpu/aarch64/vm/aarch64.ad:3354:85: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] > __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place)); > ^ ^ > I think we might need to add one extra patch here: http://hg.openjdk.java.net/jdk/jdk/rev/964186594f5f > This patch is trivial and applies after path shuffling. OK to build aarch64 release & fastdebug with this extra patch. > Please take a look. > > Thanks, > Felix Oh great, someone broke it by backporting JDK-8221408 :/ Thanks for catching this. I'll include this fix in an updated patch which also resolves Aleksey's comments. -- 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 felix.yang at huawei.com Fri Jan 8 06:17:15 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 8 Jan 2021 06:17:15 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node Message-ID: Hi, I am witnessing a known issue [1] when running jcstress test with 8u aarch64 fastdebug build. This issue can be easily reproduced during a jcstress run on my aarch64 linux server. Crash log looks like: # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/yangfei/openjdk8u-dev/hotspot/src/share/vm/opto/postaloc.cpp:139), pid=42814, tid=0x0000ffff72e381f0 # assert(false) failed: unexpected yanked node # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-yangfei_2020_12_31_10_36-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-aarch64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0000ffff8c1c8800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=44138, stack(0x0000ffff72c39000,0x0000ffff72e3 9000)] Stack: [0x0000ffff72c39000,0x0000ffff72e39000], sp=0x0000ffff72e337f0, free space=2025k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1084458] VMError::report_and_die()+0x328 V [libjvm.so+0x6b91cc] report_vm_error(char const*, int, char const*, char const*)+0x6c V [libjvm.so+0xe454b8] PhaseChaitin::yank_if_dead_recurse(Node*, Node*, Block*, Node_List*, Node_List*) [clone .part.51]+0x120 V [libjvm.so+0xe4ab7c] PhaseChaitin::post_allocate_copy_removal()+0xcdc V [libjvm.so+0x503ea0] PhaseChaitin::Register_Allocate()+0x7a0 V [libjvm.so+0x620af8] Compile::Code_Gen()+0x288 V [libjvm.so+0x623968] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xd30 V [libjvm.so+0x4c79a0] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xd8 V [libjvm.so+0x630034] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x814 V [libjvm.so+0x6313a4] CompileBroker::compiler_thread_loop()+0x7d4 V [libjvm.so+0xff6250] JavaThread::thread_main_inner()+0x1f8 V [libjvm.so+0xff6504] JavaThread::run()+0x274 V [libjvm.so+0xdb77a4] java_start(Thread*)+0x104 C [libpthread.so.0+0x7088] start_thread+0xb0 C [libc.so.6+0xd04ec] I find that JDK-8168996 is made inaccessible for the public. So I cannot follow the normal 8u backport procedure at [2]. Original RFR thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-November/024987.html Here is the original patch for JDK-8168996: # HG changeset patch # User thartmann # Date 1480403775 -3600 # Tue Nov 29 08:16:15 2016 +0100 # Node ID 771199a0134932b6ca0d7408115abc32125998e1 # Parent 14af457890427b326d4eaee62581fd5c80559d4a 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node Summary: Prevent MemBarAcquire from keeping a LoadNNode alive by adding it to the worklist if it is the only user of a DecodeNNode. Reviewed-by: kvn diff -r 14af45789042 -r 771199a01349 hotspot/src/share/vm/opto/node.cpp --- a/hotspot/src/share/vm/opto/node.cpp Sun Nov 27 19:58:30 2016 -0800 +++ b/hotspot/src/share/vm/opto/node.cpp Tue Nov 29 08:16:15 2016 +0100 @@ -1117,8 +1117,8 @@ if (this->is_Store()) { // Condition for back-to-back stores folding. return n->Opcode() == op && n->in(MemNode::Memory) == this; - } else if (this->is_Load()) { - // Condition for removing an unused LoadNode from the MemBarAcquire precedence input + } else if (this->is_Load() || this->is_DecodeN()) { + // Condition for removing an unused LoadNode or DecodeNNode from the MemBarAcquire precedence input return n->Opcode() == Op_MemBarAcquire; } else if (op == Op_AddL) { // Condition for convL2I(addL(x,y)) ==> addI(convL2I(x),convL2I(y)) Original patch applies cleanly to jdk8u-dev. Performed full jtreg test on aarch64 linux server. Also passed jcstress test on the same platform. OK to backport? [1] https://bugs.openjdk.java.net/browse/JDK-8168996 [2] https://wiki.openjdk.java.net/display/jdk8u/Main Thanks, Felix From sgehwolf at redhat.com Fri Jan 8 09:28:49 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Jan 2021 10:28:49 +0100 Subject: [8u] RFR: JDK-8259384: CUP version wrong in THIRD_PARTY_README after JDK-8233548 In-Reply-To: <20210108032739.GA683667@rincewind> References: <20210108032739.GA683667@rincewind> Message-ID: <4c03bc79e9ff0b231c92cfa805e6a78dfe7137d0.camel@redhat.com> On Fri, 2021-01-08 at 03:27 +0000, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8259384 > Webrev:? https://cr.openjdk.java.net/~andrew/openjdk8/8259384/webrev.01/ > > During the merge of 8u282-b04 into aarch64/shenandoah-jdk8u [0], > we spotted an issue with the 8u backport of JDK-8233548, namely > that the version was wrongly changed to 0.10b from 0.10k, rather > than 0.11b. > > This set of patches for each repo fixes the version. It also removes > an errant trailing space present on the line above in all copies of > THIRD_PARTY_README except the jdk one, bringing them into sync with > one another. > > This is only applicable to 8u. The version is correct in the jdk/jdk > and jdk-updates/jdk11u versions. > > Ok for 8u292? Yes, this is fine. Thanks for fixing it! Cheers, Severin From adinn at redhat.com Fri Jan 8 09:32:26 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 8 Jan 2021 09:32:26 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: References: Message-ID: <3a04a114-97cc-8e70-3f9e-b4bf55165c5c@redhat.com> Hi Felix, On 08/01/2021 06:17, Yangfei (Felix) wrote: > Hi, > > I am witnessing a known issue [1] when running jcstress test with 8u aarch64 fastdebug build. > This issue can be easily reproduced during a jcstress run on my aarch64 linux server. This certainly looks like the right fix for the right 'known issue' i.e. the one reported in JDK-8168996. However, I don't really understand how you came to the conclusion that 8168996 was the issue that is causing the problem, given that the bug is private. Are you basing that assumption on the brief description in the email thread? Or the fact that the fix makes the problem go away? Or both? Or maybe something else? I would prefer simply to approve this patch but it would help to have more background if you have any. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Fri Jan 8 09:35:13 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Jan 2021 10:35:13 +0100 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: References: Message-ID: <826db0f2e17763ce5a9a35bcacbb5b61f7c410d1.camel@redhat.com> Hi, On Fri, 2021-01-08 at 06:17 +0000, Yangfei (Felix) wrote: > Hi, > > ? I am witnessing a known issue [1] when running jcstress test with 8u aarch64 fastdebug build. > ? This issue can be easily reproduced during a jcstress run on my aarch64 linux server. > ? Crash log looks like: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > #? Internal Error (/home/yangfei/openjdk8u-dev/hotspot/src/share/vm/opto/postaloc.cpp:139), pid=42814, tid=0x0000ffff72e381f0 > #? assert(false) failed: unexpected yanked node > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-fastdebug-yangfei_2020_12_31_10_36-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode linux-aarch64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > #?? http://bugreport.java.com/bugreport/crash.jsp > # > > ---------------? T H R E A D? --------------- > > Current thread (0x0000ffff8c1c8800):? JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=44138, stack(0x0000ffff72c39000,0x0000ffff72e3 > 9000)] > > Stack: [0x0000ffff72c39000,0x0000ffff72e39000],? sp=0x0000ffff72e337f0,? free space=2025k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V? [libjvm.so+0x1084458]? VMError::report_and_die()+0x328 > V? [libjvm.so+0x6b91cc]? report_vm_error(char const*, int, char const*, char const*)+0x6c > V? [libjvm.so+0xe454b8]? PhaseChaitin::yank_if_dead_recurse(Node*, Node*, Block*, Node_List*, Node_List*) [clone .part.51]+0x120 > V? [libjvm.so+0xe4ab7c]? PhaseChaitin::post_allocate_copy_removal()+0xcdc > V? [libjvm.so+0x503ea0]? PhaseChaitin::Register_Allocate()+0x7a0 > V? [libjvm.so+0x620af8]? Compile::Code_Gen()+0x288 > V? [libjvm.so+0x623968]? Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xd30 > V? [libjvm.so+0x4c79a0]? C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xd8 > V? [libjvm.so+0x630034]? CompileBroker::invoke_compiler_on_method(CompileTask*)+0x814 > V? [libjvm.so+0x6313a4]? CompileBroker::compiler_thread_loop()+0x7d4 > V? [libjvm.so+0xff6250]? JavaThread::thread_main_inner()+0x1f8 > V? [libjvm.so+0xff6504]? JavaThread::run()+0x274 > V? [libjvm.so+0xdb77a4]? java_start(Thread*)+0x104 > C? [libpthread.so.0+0x7088]? start_thread+0xb0 > C? [libc.so.6+0xd04ec] > > ? I find that JDK-8168996 is made inaccessible for the public.? So I cannot follow the normal 8u backport procedure at [2]. > ? Original RFR thread: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-November/024987.html? > ? Here is the original patch for JDK-8168996: > > # HG changeset patch > # User thartmann > # Date 1480403775 -3600 > #????? Tue Nov 29 08:16:15 2016 +0100 > # Node ID 771199a0134932b6ca0d7408115abc32125998e1 > # Parent? 14af457890427b326d4eaee62581fd5c80559d4a > 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node > Summary: Prevent MemBarAcquire from keeping a LoadNNode alive by adding it to the worklist if it is the only user of a DecodeNNode. > Reviewed-by: kvn > > diff -r 14af45789042 -r 771199a01349 hotspot/src/share/vm/opto/node.cpp > --- a/hotspot/src/share/vm/opto/node.cpp??????? Sun Nov 27 19:58:30 2016 -0800 > +++ b/hotspot/src/share/vm/opto/node.cpp??????? Tue Nov 29 08:16:15 2016 +0100 > @@ -1117,8 +1117,8 @@ > ?? if (this->is_Store()) { > ???? // Condition for back-to-back stores folding. > ???? return n->Opcode() == op && n->in(MemNode::Memory) == this; > -? } else if (this->is_Load()) { > -??? // Condition for removing an unused LoadNode from the MemBarAcquire precedence input > +? } else if (this->is_Load() || this->is_DecodeN()) { > +??? // Condition for removing an unused LoadNode or DecodeNNode from the MemBarAcquire precedence input > ???? return n->Opcode() == Op_MemBarAcquire; > ?? } else if (op == Op_AddL) { > ???? // Condition for convL2I(addL(x,y)) ==> addI(convL2I(x),convL2I(y)) > > ? Original patch applies cleanly to jdk8u-dev. > ? Performed full jtreg test on aarch64 linux server.? Also passed jcstress test on the same platform. > ? OK to backport? > > [1] https://bugs.openjdk.java.net/browse/JDK-8168996? > [2] https://wiki.openjdk.java.net/display/jdk8u/Main? The aarch64 port hasn't yet been integrated with 8u mainline. I'd suggest to wait for this until it happened[i]. Expected for the 8u292 cycle. Thanks, Severin [i] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/013121.html > Thanks, > Felix From adinn at redhat.com Fri Jan 8 09:42:20 2021 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 8 Jan 2021 09:42:20 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: <826db0f2e17763ce5a9a35bcacbb5b61f7c410d1.camel@redhat.com> References: <826db0f2e17763ce5a9a35bcacbb5b61f7c410d1.camel@redhat.com> Message-ID: <7fdb02e4-8594-4eec-cbe6-6a22dbb67318@redhat.com> On 08/01/2021 09:35, Severin Gehwolf wrote: > The aarch64 port hasn't yet been integrated with 8u mainline. I'd > suggest to wait for this until it happened[i]. Expected for the 8u292 > cycle. If Felix has diagnosed this correctly then it is not an AArch64-specific bug (even though it may currently only have manifested on AArch64). I'd like to be more sure of the diagnosis before we push a patch but I don't see anything wrong with us pre-emptively patching before the problem turns up on x86. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Fri Jan 8 09:44:08 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 08 Jan 2021 10:44:08 +0100 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: <826db0f2e17763ce5a9a35bcacbb5b61f7c410d1.camel@redhat.com> References: <826db0f2e17763ce5a9a35bcacbb5b61f7c410d1.camel@redhat.com> Message-ID: On Fri, 2021-01-08 at 10:35 +0100, Severin Gehwolf wrote: Hi, On Fri, 2021-01-08 at 06:17 +0000, Yangfei (Felix) wrote: > Hi, > > ? I am witnessing a known issue [1] when running jcstress test with > 8u aarch64 fastdebug build. > ? This issue can be easily reproduced during a jcstress run on my > aarch64 linux server. > ? Crash log looks like: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > #? Internal Error (/home/yangfei/openjdk8u- > dev/hotspot/src/share/vm/opto/postaloc.cpp:139), pid=42814, > tid=0x0000ffff72e381f0 > #? assert(false) failed: unexpected yanked node > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0- > internal-fastdebug-yangfei_2020_12_31_10_36-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-fastdebug mixed mode > linux-aarch64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # If you would like to submit a bug report, please visit: > #?? http://bugreport.java.com/bugreport/crash.jsp > # > > ---------------? T H R E A D? --------------- > > Current thread (0x0000ffff8c1c8800):? JavaThread "C2 CompilerThread0" > daemon [_thread_in_native, id=44138, > stack(0x0000ffff72c39000,0x0000ffff72e3 > 9000)] > > Stack: [0x0000ffff72c39000,0x0000ffff72e39000],? > sp=0x0000ffff72e337f0,? free space=2025k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V? [libjvm.so+0x1084458]? VMError::report_and_die()+0x328 > V? [libjvm.so+0x6b91cc]? report_vm_error(char const*, int, char > const*, char const*)+0x6c > V? [libjvm.so+0xe454b8]? PhaseChaitin::yank_if_dead_recurse(Node*, > Node*, Block*, Node_List*, Node_List*) [clone .part.51]+0x120 > V? [libjvm.so+0xe4ab7c]? > PhaseChaitin::post_allocate_copy_removal()+0xcdc > V? [libjvm.so+0x503ea0]? PhaseChaitin::Register_Allocate()+0x7a0 > V? [libjvm.so+0x620af8]? Compile::Code_Gen()+0x288 > V? [libjvm.so+0x623968]? Compile::Compile(ciEnv*, C2Compiler*, > ciMethod*, int, bool, bool, bool)+0xd30 > V? [libjvm.so+0x4c79a0]? C2Compiler::compile_method(ciEnv*, > ciMethod*, int)+0xd8 > V? [libjvm.so+0x630034]? > CompileBroker::invoke_compiler_on_method(CompileTask*)+0x814 > V? [libjvm.so+0x6313a4]? CompileBroker::compiler_thread_loop()+0x7d4 > V? [libjvm.so+0xff6250]? JavaThread::thread_main_inner()+0x1f8 > V? [libjvm.so+0xff6504]? JavaThread::run()+0x274 > V? [libjvm.so+0xdb77a4]? java_start(Thread*)+0x104 > C? [libpthread.so.0+0x7088]? start_thread+0xb0 > C? [libc.so.6+0xd04ec] > > ? I find that JDK-8168996 is made inaccessible for the public.? So I > cannot follow the normal 8u backport procedure at [2]. > ? Original RFR thread: > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-November/024987.html > ? > ? Here is the original patch for JDK-8168996: > > # HG changeset patch > # User thartmann > # Date 1480403775 -3600 > #????? Tue Nov 29 08:16:15 2016 +0100 > # Node ID 771199a0134932b6ca0d7408115abc32125998e1 > # Parent? 14af457890427b326d4eaee62581fd5c80559d4a > 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: > unexpected yanked node > Summary: Prevent MemBarAcquire from keeping a LoadNNode alive by > adding it to the worklist if it is the only user of a DecodeNNode. > Reviewed-by: kvn > > diff -r 14af45789042 -r 771199a01349 > hotspot/src/share/vm/opto/node.cpp > --- a/hotspot/src/share/vm/opto/node.cpp??????? Sun Nov 27 19:58:30 > 2016 -0800 > +++ b/hotspot/src/share/vm/opto/node.cpp??????? Tue Nov 29 08:16:15 > 2016 +0100 > @@ -1117,8 +1117,8 @@ > ?? if (this->is_Store()) { > ???? // Condition for back-to-back stores folding. > ???? return n->Opcode() == op && n->in(MemNode::Memory) == this; > -? } else if (this->is_Load()) { > -??? // Condition for removing an unused LoadNode from the > MemBarAcquire precedence input > +? } else if (this->is_Load() || this->is_DecodeN()) { > +??? // Condition for removing an unused LoadNode or DecodeNNode from > the MemBarAcquire precedence input > ???? return n->Opcode() == Op_MemBarAcquire; > ?? } else if (op == Op_AddL) { > ???? // Condition for convL2I(addL(x,y)) ==> > addI(convL2I(x),convL2I(y)) > > ? Original patch applies cleanly to jdk8u-dev. > ? Performed full jtreg test on aarch64 linux server.? Also passed > jcstress test on the same platform. > ? OK to backport? > > [1] https://bugs.openjdk.java.net/browse/JDK-8168996? > [2] https://wiki.openjdk.java.net/display/jdk8u/Main? The aarch64 port hasn't yet been integrated with 8u mainline. I'd suggest to wait for this until it happened[i]. Expected for the 8u292 cycle. Sorry, this is in shared code so it seems suitable to integrate now into 8u-dev. Andrew Haley, are you OK with this? Seems reasonable to me. Thanks, Severin [i] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/013121.html > Thanks, > Felix From alvdavi at amazon.com Fri Jan 8 21:01:59 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Fri, 8 Jan 2021 21:01:59 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close Message-ID: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> Hi, I would like a review for 8209333. This is one of the Socket related patches that were applied to OpenJDK11 after the backport of TLS 1.3 to OpenJDK8 BugId: https://bugs.openjdk.java.net/browse/JDK-8209333 Webrev: http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.00/ The only relevant differences are in SSLSocketImpl.java, as it contained a java 9 try-with-resources block [1]. A @SuppressWarnings("try") was needed. All tests under sun/security/ssl pass after this change. Thanks David -- [1] https://hg.openjdk.java.net/jdk- updates/jdk11u/rev/ba9e4043b4b1#l2.8 From gnu.andrew at redhat.com Mon Jan 11 04:08:18 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jan 2021 04:08:18 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> Message-ID: <20210111040818.GA119842@rincewind> On 21:01 Fri 08 Jan , Alvarez, David wrote: > Hi, > > I would like a review for 8209333. This is one of the Socket related > patches that were applied to OpenJDK11 after the backport of TLS 1.3 to > OpenJDK8 > > BugId: https://bugs.openjdk.java.net/browse/JDK-8209333 > Webrev: > http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.00/ > > The only relevant differences are in SSLSocketImpl.java, as it > contained a java 9 try-with-resources block [1]. A > @SuppressWarnings("try") was needed. > > All tests under sun/security/ssl pass after this change. > > Thanks > > David > > -- > [1] https://hg.openjdk.java.net/jdk- > updates/jdk11u/rev/ba9e4043b4b1#l2.8 What warning was emitted? Is it not possible to rewrite this so as to avoid the warning? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jan 11 04:09:50 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jan 2021 04:09:50 +0000 Subject: [8u] RFR: JDK-8259384: CUP version wrong in THIRD_PARTY_README after JDK-8233548 In-Reply-To: <4c03bc79e9ff0b231c92cfa805e6a78dfe7137d0.camel@redhat.com> References: <20210108032739.GA683667@rincewind> <4c03bc79e9ff0b231c92cfa805e6a78dfe7137d0.camel@redhat.com> Message-ID: <20210111040950.GB119842@rincewind> On 10:28 Fri 08 Jan , Severin Gehwolf wrote: > On Fri, 2021-01-08 at 03:27 +0000, Andrew Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8259384 > > Webrev:? https://cr.openjdk.java.net/~andrew/openjdk8/8259384/webrev.01/ > > > > During the merge of 8u282-b04 into aarch64/shenandoah-jdk8u [0], > > we spotted an issue with the 8u backport of JDK-8233548, namely > > that the version was wrongly changed to 0.10b from 0.10k, rather > > than 0.11b. > > > > This set of patches for each repo fixes the version. It also removes > > an errant trailing space present on the line above in all copies of > > THIRD_PARTY_README except the jdk one, bringing them into sync with > > one another. > > > > This is only applicable to 8u. The version is correct in the jdk/jdk > > and jdk-updates/jdk11u versions. > > > > Ok for 8u292? > > Yes, this is fine. Thanks for fixing it! > > Cheers, > Severin > Thanks, flagged for approval. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jan 11 04:18:31 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 Jan 2021 04:18:31 +0000 Subject: [8u] RFR 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <3d881947-313b-3b7b-ef0b-b09c66589374@bell-sw.com> References: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> <20201202053430.GC387637@rincewind> <73edda88-69d4-0ef1-37f8-755307b60594@bell-sw.com> <3d881947-313b-3b7b-ef0b-b09c66589374@bell-sw.com> Message-ID: <20210111041831.GC119842@rincewind> On 20:49 Mon 07 Dec , Alexander Scherbatiy wrote: > Hello, > > Could you review the updated backport of JDK-8233228 to 8u. > > ? 8u webrev: > http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.02/jdk.patch > > The only difference between the updated backport and the previous webrev.01 > version > is that the public modifier is removed from "static String[] > getNamesByOID(String oid)" method > of CurveDB class. > > All classes which use CurveDB.getNamesByOID(oid) method > are placed in the same package as CurveDB and the original jdk11u patch > has the package-private CurveDB.getNamesByOID(oid) method. > > Thanks, > Alexander. > > On 12/3/20 7:36 PM, Alexander Scherbatiy wrote: > > Hello, > > > > Could you review the updated backport of JDK-8233228 to 8u. > > > > ? 8u webrev: > > http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.01 > > > > The classes ECParameters, NamedCurve, and CurveDB needs to be moved from > > sun.security.ec packageto sun.security.util > > because sun.security.ec is placed in sunec.jar and these classes are not > > accessible > > from ConstraintsParameters, DisabledAlgorithmConstraints which are > > stored in rt.jar. > > > > Moving ECParameters, NamedCurve, and CurveDB classes is sent as a part > > of a separate request [1] > > ?? JDK-8035166: Remove dependency on EC classes from pkcs11 provider > > > > The patch for JDK-8035166 needs to be applied first and the patch for > > JDK-8233228 on top of it. > > > > The tests compact3, java_security, java_security_infra, needs_jdk, and > > needs_jre were run. > > > > In total they contain the following crypto and security tests: > > ? sun/security/tools/jarsigner/* > > ? com/sun/crypto/provider/* > > ? com/sun/security/* > > ? java/security/* > > ? javax/crypto/* > > ? javax/net/ssl/* > > ? javax/security/* > > ? javax/xml/crypto/* > > ? sun/security/* > > ? security/infra/java/security/* > > > > The are no new failures comparing to the build without the fix. > > > > [1] > > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013171.html > > > > Thanks, > > Alexander > > > > On 12/2/20 8:34 AM, Andrew Hughes wrote: > > > On 22:14 Tue 01 Dec???? , Alexander Scherbatiy wrote: > > > > ?Hello, > > > > > > > > Could you review the backport of P2 JDK-8233228 to 8u. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233228 > > > > 11u patch: > > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a17295342862 > > > > 8u webrev: > > > > http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00 > > > > > > > > > > > > 8233228 backport to 8u (compared to 11u): > > > > *?sun.security.ec.ECParameters -> sun.security.util.ECParameters > > > > *?sun.security.ec.NamedCurve?? -> sun.security.util.NamedCurve > > > > *?sun.security.ec.CurveDB????? -> sun.security.util.CurveDB > > > > * security/tools/keytool fixed context difference > > > > * DisabledAlgorithmConstraints.java fixed context difference > > > > * Manual merge in ConstraintsParameters.java (XECKey, > > > > NamedParameterSpec are > > > > not available in 8u). > > > > * CurveDB.SPLIT_PATTERN, CurveDB.getSupportedCurves() made public > > > > * NamedCurve class, getName(), getObjectId() made public > > > > * ECParameters.getAlgorithmParameters() made public > > > > * files java.security- are separate in each platform, applied > > > > identical changes in all > > > > > > > Why is it necessary to move the package these files are in? > > > > > > If we really need to do this, it should be done as a separate backport > > > of JDK-8035166, but I'm not yet convinced this is necessary, given the > > > disruption it will cause to code that relies on the code being in the > > > current locations. > > > > > > > The are no new failures in hotspot and compact3 tests comparing > > > > to the build > > > > without the fix. > > > I'm not sure how HotSpot tests would relate to a crypto change. What > > > crypto > > > tests were run? > > > > > > > Thanks, > > > > Alexander. > > > > > > > Thanks, > This looks ok to me now. Reviewed & approved. 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 felix.yang at huawei.com Mon Jan 11 06:29:36 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 11 Jan 2021 06:29:36 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: <3a04a114-97cc-8e70-3f9e-b4bf55165c5c@redhat.com> References: <3a04a114-97cc-8e70-3f9e-b4bf55165c5c@redhat.com> Message-ID: Hi Andrew, Thanks for the quick reply :-) > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Friday, January 8, 2021 5:32 PM > To: Yangfei (Felix) > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: > unexpected yanked node > > Hi Felix, > > On 08/01/2021 06:17, Yangfei (Felix) wrote: > > Hi, > > > > I am witnessing a known issue [1] when running jcstress test with 8u > aarch64 fastdebug build. > > This issue can be easily reproduced during a jcstress run on my aarch64 > linux server. > > This certainly looks like the right fix for the right 'known issue' i.e. > the one reported in JDK-8168996. However, I don't really understand how > you came to the conclusion that 8168996 was the issue that is causing the > problem, given that the bug is private. > > Are you basing that assumption on the brief description in the email thread? > Or the fact that the fix makes the problem go away? Or both? Or maybe > something else? > > I would prefer simply to approve this patch but it would help to have more > background if you have any. Sorry, I should have mentioned more details about the diagnosis for 8u in my previous mail. There is some description about C2 graph in the original RFR thread: "The problem is that there is a MemBarAcquire node from a volatile object field load that keeps otherwise dead LoadN nodes alive (see graph at [1]). This is very similar to JDK-8048879 [2] with the difference that the MemBarAcquire -> DecodeN is not directly connected to the LoadN but there is a Phi in between. " Given that the bug is private, I think what we can do is capturing the C2 graph for our scenario and compare it with this description. We witnessed that the crash always triggers for the same java method: Current CompileTask: C2: 2287 88 org.openjdk.jcstress.tests.locks.stamped.StampedLockPairwiseTests_tRLt_URs_aWL_U_jcstress::lambda$sanityCheck_Footprints$2 (120 bytes) Given the concurrency execution of jcstress test, we need some local hacking [1] on 8u JVM in order to get the C2 graph on the crash site. Two purposes for the local hacking: 1. Add process id to the C2 graph dump file name so we won't have two jvm process dumping to the same file. 2. Enable C2 graph dump for specific java method so that the dump file won't be too large in size. Then the JVM command line becomes something like: $ java -XX:-BackgroundCompilation -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:PrintIdealGraphLevel=3 -XX:PrintIdealGraphFile=ideal-%p-%t.xml -XX:CompileCommand="print *jcstress::lambda\$sanityCheck_Footprints\$2" -jar jcstress.jar -c 64 -f 1 -iters 1 -t org.openjdk.jcstress.tests.locks.stamped.StampedLockPairwiseTests With that we managed to get the C2 graph after "Optimized finished" phase. The subgraph looks like: LoadN --> DecodeN --> MemBarAcquire Here, the MemBarAcquire node from a volatile object field was keeping the otherwise dead LoadN nodes alive. But we don't have a Phi in between. This is slight different with the C2 graph in the original RFR thread. I think this does not affect the application of the original fix. Is this enough to validate the 8u backport? Thanks, Felix [1] local modification to capture the C2 graph diff --git a/hotspot/src/share/vm/opto/idealGraphPrinter.cpp b/hotspot/src/share/vm/opto/idealGraphPrinter.cpp index 65c1ac97b..5a4762eb7 100644 --- a/hotspot/src/share/vm/opto/idealGraphPrinter.cpp +++ b/hotspot/src/share/vm/opto/idealGraphPrinter.cpp @@ -130,10 +130,10 @@ IdealGraphPrinter::IdealGraphPrinter() { } else { st.print("%s%d", PrintIdealGraphFile, _file_count); } - fileStream *stream = new (ResourceObj::C_HEAP, mtCompiler) fileStream(st.as_string()); + fileStream *stream = new (ResourceObj::C_HEAP, mtCompiler) fileStream(st.as_string(), true); _output = stream; } else { - fileStream *stream = new (ResourceObj::C_HEAP, mtCompiler) fileStream(PrintIdealGraphFile); + fileStream *stream = new (ResourceObj::C_HEAP, mtCompiler) fileStream(PrintIdealGraphFile, true); _output = stream; } _file_count++; diff --git a/hotspot/src/share/vm/utilities/ostream.cpp b/hotspot/src/share/vm/utilities/ostream.cpp index 587b839b9..670f25b13 100644 --- a/hotspot/src/share/vm/utilities/ostream.cpp +++ b/hotspot/src/share/vm/utilities/ostream.cpp @@ -705,6 +705,18 @@ void test_snprintf() { } #endif // PRODUCT +fileStream::fileStream(const char* file_name, bool is_need_transform) { + if(is_need_transform) + file_name = make_log_name(file_name, NULL); + _file = fopen(file_name, "w"); + if (_file != NULL) { + _need_close = true; + } else { + warning("Cannot open file %s due to %s\n", file_name, strerror(errno)); + _need_close = false; + } +} + fileStream::fileStream(const char* file_name) { _file = fopen(file_name, "w"); if (_file != NULL) { diff --git a/hotspot/src/share/vm/utilities/ostream.hpp b/hotspot/src/share/vm/utilities/ostream.hpp index c69289fb5..1fdd52102 100644 --- a/hotspot/src/share/vm/utilities/ostream.hpp +++ b/hotspot/src/share/vm/utilities/ostream.hpp @@ -200,6 +200,7 @@ class fileStream : public outputStream { public: fileStream() { _file = NULL; _need_close = false; } fileStream(const char* file_name); + fileStream(const char *file_name, bool is_need_transform); fileStream(const char* file_name, const char* opentype); fileStream(FILE* file, bool need_close = false) { _file = file; _need_close = need_close; } ~fileStream(); diff --git a/hotspot/src/share/vm/opto/compile.cpp b/hotspot/src/share/vm/opto/compile.cpp index 540cae5d6..f2f85915f 100644 --- a/hotspot/src/share/vm/opto/compile.cpp +++ b/hotspot/src/share/vm/opto/compile.cpp @@ -866,7 +866,7 @@ Compile::Compile( ciEnv* ci_env, C2Compiler* compiler, ciMethod* target, int osr // Drain the list. Finish_Warm(); #ifndef PRODUCT - if (_printer) { + if (_printer && CompilerOracle::should_print(C->method()->get_Method())) { _printer->print_inlining(this); } #endif diff --git a/hotspot/src/share/vm/opto/compile.hpp b/hotspot/src/share/vm/opto/compile.hpp index 93fa11737..2a368a5fb 100644 --- a/hotspot/src/share/vm/opto/compile.hpp +++ b/hotspot/src/share/vm/opto/compile.hpp @@ -639,7 +639,7 @@ class Compile : public Phase { void begin_method() { #ifndef PRODUCT - if (_printer) _printer->begin_method(this); + if (_printer && CompilerOracle::should_print(C->method()->get_Method())) _printer->begin_method(this); #endif C->_latest_stage_start_counter.stamp(); } @@ -656,7 +656,7 @@ class Compile : public Phase { #ifndef PRODUCT - if (_printer) _printer->print_method(this, CompilerPhaseTypeHelper::to_string(cpt), level); + if (_printer && CompilerOracle::should_print(C->method()->get_Method())) _printer->print_method(this, CompilerPhaseTypeHelper::to_string(cpt), level); #endif C->_latest_stage_start_counter.stamp(); } @@ -671,7 +671,7 @@ class Compile : public Phase { event.commit(); } #ifndef PRODUCT - if (_printer) _printer->end_method(); + if (_printer && CompilerOracle::should_print(C->method()->get_Method())) _printer->end_method(); #endif } From adinn at redhat.com Mon Jan 11 09:46:00 2021 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Jan 2021 09:46:00 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: References: <3a04a114-97cc-8e70-3f9e-b4bf55165c5c@redhat.com> Message-ID: Hi Felix, On 11/01/2021 06:29, Yangfei (Felix) wrote: > Sorry, I should have mentioned more details about the diagnosis for > 8u in my previous mail. > . . . > With that we managed to get the C2 graph after "Optimized finished" > phase. The subgraph looks like: > LoadN --> DecodeN --> MemBarAcquire > Here, the MemBarAcquire node from a volatile object field was keeping > the otherwise dead LoadN nodes alive. But we don't have a Phi in > between. This is slight different with the C2 graph in the original > RFR thread. I think this does not affect the application of the > original fix. Is this enough to validate the 8u backport? That's more than enough to approve this as the right fix for the right issue! Nice work ;-) regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Mon Jan 11 10:26:11 2021 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Jan 2021 10:26:11 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: <20210111040818.GA119842@rincewind> References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> Message-ID: <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> On 1/11/21 4:08 AM, Andrew Hughes wrote: > On 21:01 Fri 08 Jan , Alvarez, David wrote: >> Hi, >> >> I would like a review for 8209333. This is one of the Socket related >> patches that were applied to OpenJDK11 after the backport of TLS 1.3 to >> OpenJDK8 >> >> BugId: https://bugs.openjdk.java.net/browse/JDK-8209333 >> Webrev: >> http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.00/ >> >> The only relevant differences are in SSLSocketImpl.java, as it >> contained a java 9 try-with-resources block [1]. A >> @SuppressWarnings("try") was needed. > > What warning was emitted? Is it not possible to rewrite this so > as to avoid the warning? Yes, I think this warning is for a real bug. Should be something like: if (!conContext.isInboundClosed()) { try { // Try the best to use up the input records and close the // socket gracefully, without impact the performance too // much. appInput.deplete(); } finally { conContext.inputRecord.close(); } } -- 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 Mon Jan 11 10:57:53 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Jan 2021 11:57:53 +0100 Subject: [8u] RFR: 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" Message-ID: <2d4122c1d9bd59264d311a2a38098974a77b2af9.camel@redhat.com> Hi, I'd like to backport this simple fix to OpenJDK 8u as it simplifies the backport of JDK-8172404 to 8u and the patch at hand is low risk. The JDK 8u patch is the same as the one for JDK 10, except for one context difference in keytool/Resources.java. The reason for this is that JDK- 8191137 got fixed in JDK 10 *after* JDK-8185934 and in JDK 8u it's the other way around. Other than that, the patch is identical. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8185934 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185934/jdk8/01/webrev/ Thoughts? Thanks, Severin From volker.simonis at gmail.com Mon Jan 11 11:27:42 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 11 Jan 2021 12:27:42 +0100 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> Message-ID: Hi everybody, I think that David's downport is correct and there's nothing much we can do about the warning except suppressing it. "try-with resources" was introduced in Java 7 and allowed the declaration of resources in the try clause [1]. Later, in Java 9, "try-with resources" was extended to also accept already existing resources as final or "effectively final" variables in the try statement [2]. The initial change uses such an "effectively final" resource (i.e. "conContext.inputRecord"): try (conContext.inputRecord) { appInput.deplete(); } Unfortunately that exact version can't be downported as is because that syntax is simply not supported in Java 8. So we have to declare a new variable in the try statement as David did: try (InputRecord ir = conContext.inputRecord) { appInput.deplete(); } But now javac complains that "ir" is not referenced in body of corresponding try statement (which is true, but we know that it exists and we know that it must be closed if an exception occurs). The "SuppressWarnings("try")" annotation exist for this exact scenario. Notice that this annotations is already used in the jdk8 class-library, e.g. in BufferedWriter.java [3] or FilterOutputStream.java[4] in similar situations. In Java 9 and later, javac doesn't emits this warning for final or "effectively final" variables which are declared in the try statement but not used in the try body. Using Andrew H's proposal would certainly work as well, but from my point of view it would be a bigger difference compared to the original change so I'd vote for keeping David's version. Thank you and best regards, Volker [1] https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html [2] https://docs.oracle.com/en/java/javase/15/language/java-language-changes.html#GUID-A920DB06-0FD1-4F9C-8A9A-15FC979D5DA3 [3] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7432d3558458/src/share/classes/java/io/BufferedWriter.java#l258 [4] https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7432d3558458/src/share/classes/java/io/FilterOutputStream.java#l155 On Mon, Jan 11, 2021 at 11:28 AM Andrew Haley wrote: > > On 1/11/21 4:08 AM, Andrew Hughes wrote: > > On 21:01 Fri 08 Jan , Alvarez, David wrote: > >> Hi, > >> > >> I would like a review for 8209333. This is one of the Socket related > >> patches that were applied to OpenJDK11 after the backport of TLS 1.3 to > >> OpenJDK8 > >> > >> BugId: https://bugs.openjdk.java.net/browse/JDK-8209333 > >> Webrev: > >> http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.00/ > >> > >> The only relevant differences are in SSLSocketImpl.java, as it > >> contained a java 9 try-with-resources block [1]. A > >> @SuppressWarnings("try") was needed. > > > > What warning was emitted? Is it not possible to rewrite this so > > as to avoid the warning? > > Yes, I think this warning is for a real bug. Should be something like: > > if (!conContext.isInboundClosed()) { > try { > // Try the best to use up the input records and close the > // socket gracefully, without impact the performance too > // much. > appInput.deplete(); > } finally { > conContext.inputRecord.close(); > } > } > > -- > 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 Mon Jan 11 11:35:15 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Jan 2021 12:35:15 +0100 Subject: [8u] RFR: 8172404: Tools should warn if weak algorithms are used before restricting them Message-ID: <9c624fb63fee681ac7e7edd210ef5882e65c8235.camel@redhat.com> Hi, Please review this 8u backport of JDK-8172404, an enhancement to warn about insecure and soon-to-be-disabled algorithms in security tools. This patch introduces a new security property, jdk.security.legacyAlgorithms, and thus requires a CSR. Since Oracle backported this patch, we are re-using that CSR. The original patch doesn't apply cleanly so I had to adjust hunks manually. In order for this backport to apply better, it depends on JDK-8185934[1] and JDK-8233228[2]. Of particular note are the differences in jarsigner/Main.java method signJar(). For this backport, I've moved initialization of a null sigalg a bit earlier in signJar() by virtue of calling new private static method getDefaultSignatureAlgorithm(privateKey). This allows one to reason that sigalg, tSADigestAlg and digestalg will never be null when new method checkWeakSign() is being called. The former, because of what I've just explained earlier, the latter two because they are being set to default values on object construction in contrast to code in JDK 11u. Bug: https://bugs.openjdk.java.net/browse/JDK-8172404 webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8172404/jdk8/02/webrev/ CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8238640 Testing: keytool/jarsigner tests. Manual testing that warnings are being printed for weak CA certs in cacerts Thoughts? Thanks, Severin [1] On review here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013291.html [2] Reviewed and 8u-Maintainer-approved. Waiting for push: https://bugs.openjdk.java.net/browse/JDK-8233228 From felix.yang at huawei.com Mon Jan 11 12:37:42 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 11 Jan 2021 12:37:42 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node Message-ID: Hi Andrew, > > Hi Felix, > > On 11/01/2021 06:29, Yangfei (Felix) wrote: > > Sorry, I should have mentioned more details about the diagnosis for 8u > > in my previous mail. > > . . . > > With that we managed to get the C2 graph after "Optimized finished" > > phase. The subgraph looks like: > > LoadN --> DecodeN --> MemBarAcquire Here, the MemBarAcquire node > > from a volatile object field was keeping the otherwise dead LoadN > > nodes alive. But we don't have a Phi in between. This is slight > > different with the C2 graph in the original RFR thread. I think this > > does not affect the application of the original fix. Is this enough > > to validate the 8u backport? > > That's more than enough to approve this as the right fix for the right issue! > > Nice work ;-) Great to hear that resolves your concern :-) Thanks for reviewing and approving this. Then I think I need push approval from the 8u maintainers. Anyone please? Best Regards, Felix From sgehwolf at redhat.com Mon Jan 11 13:38:00 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Jan 2021 14:38:00 +0100 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: References: Message-ID: On Mon, 2021-01-11 at 12:37 +0000, Yangfei (Felix) wrote: > > That's more than enough to approve this as the right fix for the > > right issue! > > > > Nice work ;-) > > Great to hear that resolves your concern :-) Thanks for reviewing and approving this. > Then I think I need push approval from the 8u maintainers. Anyone please? OK for 8u-dev. Thanks, Severin From volker.simonis at gmail.com Mon Jan 11 14:30:20 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 11 Jan 2021 15:30:20 +0100 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently In-Reply-To: References: <139d1e126a3f42d187da3c80703b4ecf@azul.com> <4CEFF951-CD47-4483-B309-05D3307A9E69@azul.com> <9ae99166-7cb5-3d7f-235c-df671de6df8b@azul.com> Message-ID: Looks good to me and pretty trivial. Reviewed. Best regards, Volker On Tue, Dec 8, 2020 at 5:02 PM Hohensee, Paul wrote: > > Ping. :) > > ?-----Original Message----- > From: jdk8u-dev on behalf of "Hohensee, Paul" > Date: Wednesday, November 25, 2020 at 1:43 PM > To: Andrew Hughes , Andrey Petushkov , Aleksey Shipilev > Cc: "jdk8u-dev at openjdk.java.net" > Subject: RE: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently > > I've taken the liberty of re-doing the backport. It's clean except for a context diff at the start of hunk #1. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8031126 > Patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 > Webrev: http://cr.openjdk.java.net/~phh/8031126/webrev.8u.00/ > > Thanks, > Paul > > On 2/19/20, 8:45 PM, "jdk8u-dev on behalf of Andrew Hughes" wrote: > > On 19/02/2020 13:00, Andrey Petushkov wrote: > > Hi Andrew, > > > > Uploaded webrev at https://cr.openjdk.java.net/~fijiol/8031126/webrev.00/ > > > > Thanks, > > Andrey > > > > On 19.02.2020 07:20, Andrew Hughes wrote: > >> > >> On 31/07/2019 16:23, Andrey Petushkov wrote: > >>> Hi Aleksey, > >>> > >>> I'll do > >>> > >>> Thanks, > >>> Andrey > >>> > >>>> On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: > >>>> > >>>> On 7/16/19 7:42 PM, Fedor Burdun wrote: > >>>>> The issue described in bugs 8031126/8030631 is still reproducible on java8. > >>>>> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? > >>>> This makes sense. Is there anyone from Azul to assist you with following this checklist? > >>>> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > >>>> > >>>> Thanks, > >>>> -Aleksey > >> Is there a webrev for this backport? > >> > >> Thanks, > > > > Thanks. > > Backport looks right, but I think we should probably backport > JDK-8036122 first (which includes the changes to proc_stat_path). > That should then make this change a clean backport. > > I take a look at this and get back to you. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > From shade at redhat.com Mon Jan 11 14:38:34 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Jan 2021 15:38:34 +0100 Subject: [8u] RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days Message-ID: <82f7325b-39c6-d828-81d8-0ea1ec0786b8@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8259312 https://github.com/openjdk/jdk/commit/3be6e06958c4304cafee707a29d06d6b2cc5b76b Patch does not apply cleanly to 8u, because @bug line does not have one of the expected bug IDs. I added the bug ID from the original patch by hand. 8u variant: diff -r 987c8e6b992e test/sun/security/lib/cacerts/VerifyCACerts.java --- a/test/sun/security/lib/cacerts/VerifyCACerts.java Sat Dec 21 06:28:48 2019 +0800 +++ b/test/sun/security/lib/cacerts/VerifyCACerts.java Mon Jan 11 15:29:54 2021 +0100 @@ -25,11 +25,11 @@ /** * @test * @bug 8189131 8198240 8191844 8189949 8191031 8196141 8204923 8195774 8199779 * 8209452 8209506 8210432 8195793 8216577 8222089 8222133 8222137 8222136 * 8223499 8225392 8232019 8234245 8233223 8225068 8225069 8243321 8243320 - * 8225072 8258630 + * 8225072 8258630 8259312 * @summary Check root CA entries in cacerts file */ import java.io.ByteArrayInputStream; import java.io.File; import java.nio.file.Files; @@ -275,10 +275,12 @@ add("thawtepremiumserverca [jdk]"); // Valid until: Wed Mar 17 02:51:37 PDT 2021 add("luxtrustglobalrootca [jdk]"); // Valid until: Wed Mar 17 11:33:33 PDT 2021 add("quovadisrootca [jdk]"); + // Valid until: Tue Apr 06 00:29:40 PDT 2021 + add("soneraclass2ca [jdk]"); } }; // Ninety days in milliseconds private static final long NINETY_DAYS = 7776000000L; Testing: jdk_security tests (used to fail, now pass) -- Thanks, -Aleksey From sgehwolf at redhat.com Mon Jan 11 14:57:30 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Jan 2021 15:57:30 +0100 Subject: [8u] RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days In-Reply-To: <82f7325b-39c6-d828-81d8-0ea1ec0786b8@redhat.com> References: <82f7325b-39c6-d828-81d8-0ea1ec0786b8@redhat.com> Message-ID: On Mon, 2021-01-11 at 15:38 +0100, Aleksey Shipilev wrote: > Original fix: > ?? https://bugs.openjdk.java.net/browse/JDK-8259312 > ?? https://github.com/openjdk/jdk/commit/3be6e06958c4304cafee707a29d06d6b2cc5b76b > > Patch does not apply cleanly to 8u, because @bug line does not have one of the expected bug IDs. I > added the bug ID from the original patch by hand. It looks like the JDK 11 patch applies clean, no? https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/26e55fdece42 Thanks, Severin From shade at redhat.com Mon Jan 11 15:06:56 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Jan 2021 16:06:56 +0100 Subject: [8u] RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days In-Reply-To: References: <82f7325b-39c6-d828-81d8-0ea1ec0786b8@redhat.com> Message-ID: <16791b2a-a6f5-3364-6263-c4ee599c4301@redhat.com> On 1/11/21 3:57 PM, Severin Gehwolf wrote: > On Mon, 2021-01-11 at 15:38 +0100, Aleksey Shipilev wrote: >> Original fix: >> ?? https://bugs.openjdk.java.net/browse/JDK-8259312 >> ?? https://github.com/openjdk/jdk/commit/3be6e06958c4304cafee707a29d06d6b2cc5b76b >> >> Patch does not apply cleanly to 8u, because @bug line does not have one of the expected bug IDs. I >> added the bug ID from the original patch by hand. > > It looks like the JDK 11 patch applies clean, no? > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/26e55fdece42 Ah, maybe! I did not check 11u version, backported the original. -- Thanks, -Aleksey From sgehwolf at redhat.com Mon Jan 11 15:53:39 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 Jan 2021 16:53:39 +0100 Subject: [8u] RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days In-Reply-To: <16791b2a-a6f5-3364-6263-c4ee599c4301@redhat.com> References: <82f7325b-39c6-d828-81d8-0ea1ec0786b8@redhat.com> <16791b2a-a6f5-3364-6263-c4ee599c4301@redhat.com> Message-ID: <813a09e834c284be40cb388f4b15757aa9799ca0.camel@redhat.com> On Mon, 2021-01-11 at 16:06 +0100, Aleksey Shipilev wrote: > On 1/11/21 3:57 PM, Severin Gehwolf wrote: > > On Mon, 2021-01-11 at 15:38 +0100, Aleksey Shipilev wrote: > > > Original fix: > > > ??? https://bugs.openjdk.java.net/browse/JDK-8259312 > > > ???? > > > https://github.com/openjdk/jdk/commit/3be6e06958c4304cafee707a29d06d6b2cc5b76b > > > > > > Patch does not apply cleanly to 8u, because @bug line does not > > > have one of the expected bug IDs. I > > > added the bug ID from the original patch by hand. > > > > It looks like the JDK 11 patch applies clean, no? > > https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/26e55fdece42 > > Ah, maybe! I did not check 11u version, backported the original. For the record, your 8u patch patch is fine. Just keep in mind to use or at least look at the available patch of the oldest JDK release higher than the one to backport to before going for a rewrite from JDK head. In this case, I'm pretty sure the review could have been skipped (applies cleanly). Thanks, Severin From shade at redhat.com Mon Jan 11 15:58:20 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Jan 2021 16:58:20 +0100 Subject: [8u] RFR (XS) 8259568: PPC64 builds broken after JDK-8221408 8u backport Message-ID: <7daf9872-679f-0b8c-f6f0-9a5f142ea3ed@redhat.com> This is 8u-specific bug: https://bugs.openjdk.java.net/browse/JDK-8259568 Please read the details in the bug report. Fix: http://cr.openjdk.java.net/~shade/8259568/webrev.01/ Testing: Linux PPC64 build (used to fail before, passes now); jcstress (running) -- Thanks, -Aleksey From shade at redhat.com Mon Jan 11 16:01:59 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Jan 2021 17:01:59 +0100 Subject: [8u] RFR: 8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days In-Reply-To: <813a09e834c284be40cb388f4b15757aa9799ca0.camel@redhat.com> References: <82f7325b-39c6-d828-81d8-0ea1ec0786b8@redhat.com> <16791b2a-a6f5-3364-6263-c4ee599c4301@redhat.com> <813a09e834c284be40cb388f4b15757aa9799ca0.camel@redhat.com> Message-ID: <49ded3b5-259f-74bf-5769-82e609b8f6a5@redhat.com> On 1/11/21 4:53 PM, Severin Gehwolf wrote: > On Mon, 2021-01-11 at 16:06 +0100, Aleksey Shipilev wrote: >> On 1/11/21 3:57 PM, Severin Gehwolf wrote: >>> On Mon, 2021-01-11 at 15:38 +0100, Aleksey Shipilev wrote: >>>> Original fix: >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8259312 >>>> >>>> https://github.com/openjdk/jdk/commit/3be6e06958c4304cafee707a29d06d6b2cc5b76b >>>> >>>> Patch does not apply cleanly to 8u, because @bug line does not >>>> have one of the expected bug IDs. I >>>> added the bug ID from the original patch by hand. >>> >>> It looks like the JDK 11 patch applies clean, no? >>> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/26e55fdece42 >> >> Ah, maybe! I did not check 11u version, backported the original. > > For the record, your 8u patch patch is fine. Thanks, tagged. > Just keep in mind to use or at least look at the available patch of the > oldest JDK release higher than the one to backport to before going for > a rewrite from JDK head. > > In this case, I'm pretty sure the review could have been skipped > (applies cleanly). Yes. -- Thanks, -Aleksey From alvdavi at amazon.com Mon Jan 11 16:14:33 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Mon, 11 Jan 2021 16:14:33 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> Message-ID: Hi, What Volker describes is exactly what is going on. When I first backported this issue, I did the same as Andrew suggests, just adding a finally with the close statement. However, after several works, we have tracked the issues we were having with SSLException to slight differences in the exceptions thrown by the TLS1.3 stack compared to TLS1.2 ([1], another patch that I will backport to 8 once the prereqs are done). For that reason, I decided to ensure there were no differences introduced in this backport. Using the @SuppressWarnings("try") is not the only option, though. We can replace the try-with resources with a functionally equivalent block, the closest I know one being defined in this article [2]. However, seeing that the @SuppressWarnings("try") was already in use in other areas, I decided the extra code would be more confusing. Thanks, David --- [1] https://github.com/openjdk/jdk/pull/1968 [2] https://www.oracle.com/technical-resources/articles/java/trywithresources.html#nb2 On Mon, 2021-01-11 at 12:27 +0100, Volker Simonis wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > Hi everybody, > > I think that David's downport is correct and there's nothing much we > can do about the warning except suppressing it. > > "try-with resources" was introduced in Java 7 and allowed the > declaration of resources in the try clause [1]. > > Later, in Java 9, "try-with resources" was extended to also accept > already existing resources as final or "effectively final" variables > in the try statement [2]. > > The initial change uses such an "effectively final" resource (i.e. > "conContext.inputRecord"): > > try (conContext.inputRecord) { > appInput.deplete(); > } > > Unfortunately that exact version can't be downported as is because > that syntax is simply not supported in Java 8. So we have to declare > a > new variable in the try statement as David did: > > try (InputRecord ir = conContext.inputRecord) { > appInput.deplete(); > } > > But now javac complains that "ir" is not referenced in body of > corresponding try statement (which is true, but we know that it > exists > and we know that it must be closed if an exception occurs). The > "SuppressWarnings("try")" annotation exist for this exact scenario. > Notice that this annotations is already used in the jdk8 > class-library, e.g. in BufferedWriter.java [3] or > FilterOutputStream.java[4] in similar situations. In Java 9 and > later, > javac doesn't emits this warning for final or "effectively final" > variables which are declared in the try statement but not used in the > try body. > > Using Andrew H's proposal would certainly work as well, but from my > point of view it would be a bigger difference compared to the > original > change so I'd vote for keeping David's version. > > Thank you and best regards, > Volker > > [1] > https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html > [2] > https://docs.oracle.com/en/java/javase/15/language/java-language-changes.html#GUID-A920DB06-0FD1-4F9C-8A9A-15FC979D5DA3 > [3] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7432d3558458/src/share/classes/java/io/BufferedWriter.java#l258 > [4] > https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/7432d3558458/src/share/classes/java/io/FilterOutputStream.java#l155 > > On Mon, Jan 11, 2021 at 11:28 AM Andrew Haley wrote: > > > > On 1/11/21 4:08 AM, Andrew Hughes wrote: > > > On 21:01 Fri 08 Jan , Alvarez, David wrote: > > > > Hi, > > > > > > > > I would like a review for 8209333. This is one of the Socket > > > > related > > > > patches that were applied to OpenJDK11 after the backport of > > > > TLS 1.3 to > > > > OpenJDK8 > > > > > > > > BugId: https://bugs.openjdk.java.net/browse/JDK-8209333 > > > > Webrev: > > > > http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.00/ > > > > > > > > The only relevant differences are in SSLSocketImpl.java, as it > > > > contained a java 9 try-with-resources block [1]. A > > > > @SuppressWarnings("try") was needed. > > > > > > What warning was emitted? Is it not possible to rewrite this so > > > as to avoid the warning? > > > > Yes, I think this warning is for a real bug. Should be something > > like: > > > > if (!conContext.isInboundClosed()) { > > try { > > // Try the best to use up the input records and > > close the > > // socket gracefully, without impact the > > performance too > > // much. > > appInput.deplete(); > > } finally { > > conContext.inputRecord.close(); > > } > > } > > > > -- > > 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 Mon Jan 11 17:27:59 2021 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 11 Jan 2021 17:27:59 +0000 Subject: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently Message-ID: <43546E2F-9F41-4EB7-8BFD-78423FDDF8D7@amazon.com> Thanks, Volker. Backport issue (https://bugs.openjdk.java.net/browse/JDK-8259029) tagged. Paul ?-----Original Message----- From: Volker Simonis Date: Monday, January 11, 2021 at 6:31 AM To: "Hohensee, Paul" Cc: Andrew Hughes , Andrey Petushkov , Aleksey Shipilev , "jdk8u-dev at openjdk.java.net" Subject: RE: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently Looks good to me and pretty trivial. Reviewed. Best regards, Volker On Tue, Dec 8, 2020 at 5:02 PM Hohensee, Paul wrote: > > Ping. :) > > -----Original Message----- > From: jdk8u-dev on behalf of "Hohensee, Paul" > Date: Wednesday, November 25, 2020 at 1:43 PM > To: Andrew Hughes , Andrey Petushkov , Aleksey Shipilev > Cc: "jdk8u-dev at openjdk.java.net" > Subject: RE: RFR(s): backport of 8031126: java/lang/management/ThreadMXBean/ThreadUserTime.java fails intermittently > > I've taken the liberty of re-doing the backport. It's clean except for a context diff at the start of hunk #1. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8031126 > Patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 > Webrev: http://cr.openjdk.java.net/~phh/8031126/webrev.8u.00/ > > Thanks, > Paul > > On 2/19/20, 8:45 PM, "jdk8u-dev on behalf of Andrew Hughes" wrote: > > On 19/02/2020 13:00, Andrey Petushkov wrote: > > Hi Andrew, > > > > Uploaded webrev at https://cr.openjdk.java.net/~fijiol/8031126/webrev.00/ > > > > Thanks, > > Andrey > > > > On 19.02.2020 07:20, Andrew Hughes wrote: > >> > >> On 31/07/2019 16:23, Andrey Petushkov wrote: > >>> Hi Aleksey, > >>> > >>> I'll do > >>> > >>> Thanks, > >>> Andrey > >>> > >>>> On 31 Jul 2019, at 15:54, Aleksey Shipilev wrote: > >>>> > >>>> On 7/16/19 7:42 PM, Fedor Burdun wrote: > >>>>> The issue described in bugs 8031126/8030631 is still reproducible on java8. > >>>>> May I request a backport of the changeset http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/af53a220ea60 to java8? > >>>> This makes sense. Is there anyone from Azul to assist you with following this checklist? > >>>> https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > >>>> > >>>> Thanks, > >>>> -Aleksey > >> Is there a webrev for this backport? > >> > >> Thanks, > > > > Thanks. > > Backport looks right, but I think we should probably backport > JDK-8036122 first (which includes the changes to proc_stat_path). > That should then make this change a clean backport. > > I take a look at this and get back to you. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > > > From stooke at redhat.com Mon Jan 11 21:08:38 2021 From: stooke at redhat.com (Simon Tooke) Date: Mon, 11 Jan 2021 16:08:38 -0500 Subject: RFR: 8u backport of JDK-8243114 Implement montgomery{Multiply,Square}intrinsics on Windows Message-ID: <6c2a6dff-3156-55aa-b06c-cf82a8e43877@redhat.com> Backport of JDK-8243114 Implement montgomery{Multiply,Square} intrinsics on Windows JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk8u/hotspot.01/ I would like to backport this performance enhancement to 8u, for performance and for Oracle parity. The backport is trivial, with one exception: Visual Studio 2010 does not implement a required compiler intrinsic used by this backport. Accordingly, the backport is #ifdef'ed to only apply on Windows if Visual Studio 2017 (or higher) is used as the build compiler. I do not have (so was not able to test this backport with) intermediate versions of VS; if someone were to grep for _addcarry_u64 in intrin.h, perhaps earlier versions can be supported. Visual Studio 2010 is still supported as a build compiler, but will not reap the benefit of this backport. In addition, MontgomeryMultiplyTest is no longer omitted on Windows platforms, and I made sure to apply 8248347 (the follow-up build fix patch). Using the program below, speedups were observed: >openjdk-8u282-b04-vs2010\bin\java MMTest elapsed time 58220 ms >openjdk-8u282-b04-vs2017\bin\java -XX:+UseMontgomeryMultiplyIntrinsic -XX:+UseMontgomerySquareIntrinsic MMTest (this is the default) elapsed time 25471 ms >openjdk-8u282-b04-vs2017\bin\java -XX:-UseMontgomeryMultiplyIntrinsic -XX:-UseMontgomerySquareIntrinsic MMTest elapsed time 58980 ms Test code: class MMTest { ? public static void main(String[] args) { ??? Instant start = Instant.now(); ??? BigInteger base = BigInteger.ONE.shiftLeft(1024); ??? long count = LongStream.rangeClosed(2, 100_000) ??? ??? ?.mapToObj(n -> BigInteger.valueOf(n).add(base)) ??? ??? ?.filter(i -> i.isProbablePrime(50)) ??? ??? ?.count(); ??? Instant finish = Instant.now(); ??? long timeElapsed = Duration.between(start, finish).toMillis(); ??? System.out.format("elapsed time %d ms\n", timeElapsed); ? } } Thanks, -simon From ebaron at redhat.com Mon Jan 11 23:51:19 2021 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 11 Jan 2021 18:51:19 -0500 Subject: [8u] RFR Backport 8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods Message-ID: <6cf95c93-d536-b371-11ac-600307cabdbf@redhat.com> Hi, I'd like to request a review to backport 8167281 to 8u. Original fix: https://bugs.openjdk.java.net/browse/JDK-8167281 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ffba2718d7f6 The original fix did not apply cleanly, but only required a small change to the patch context. This is due to 8u using a raw List in the getElementsByTagName signature instead of a parameterized List. 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8167281/webrev.00/ Testing: x86_64 build, jdk_tier1, jdk_imageio tests (including new tests) Thanks, Elliott From felix.yang at huawei.com Tue Jan 12 00:57:50 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 12 Jan 2021 00:57:50 +0000 Subject: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: unexpected yanked node In-Reply-To: References: Message-ID: Hi Severin, > -----Original Message----- > From: Severin Gehwolf [mailto:sgehwolf at redhat.com] > Sent: Monday, January 11, 2021 9:38 PM > To: Yangfei (Felix) ; Andrew Dinn > > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: RFA: 8168996: C2 crash at postaloc.cpp:140 : assert(false) failed: > unexpected yanked node > > On Mon, 2021-01-11 at 12:37 +0000, Yangfei (Felix) wrote: > > > That's more than enough to approve this as the right fix for the > > > right issue! > > > > > > Nice work ;-) > > > > Great to hear that resolves your concern :-) Thanks for reviewing and > approving this. > > Then I think I need push approval from the 8u maintainers. Anyone please? > > OK for 8u-dev. Thanks for approving this. Pushed. Best Regards, Felix From felix.yang at huawei.com Tue Jan 12 07:39:01 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 12 Jan 2021 07:39:01 +0000 Subject: PING? RE: RFR: 8258669: fastdebug jvm crashes when do event based tracing for monitor inflation Message-ID: 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 serge.chernyshev at bell-sw.com Tue Jan 12 09:50:10 2021 From: serge.chernyshev at bell-sw.com (Sergey Chernyshev) Date: Tue, 12 Jan 2021 12:50:10 +0300 Subject: [8u] RFR 8233228: Disable weak named curves by default in TLS, CertPath, and Signed JAR In-Reply-To: <20210111041831.GC119842@rincewind> References: <56edd471-f7d7-6a23-1554-e99d51ecf940@bell-sw.com> <20201202053430.GC387637@rincewind> <73edda88-69d4-0ef1-37f8-755307b60594@bell-sw.com> <3d881947-313b-3b7b-ef0b-b09c66589374@bell-sw.com> <20210111041831.GC119842@rincewind> Message-ID: <67e0855c-3c54-a3dd-29cb-58913b297961@bell-sw.com> Hi Andrew, Thank you for the review. Thanks, Serge On 11.01.2021 07:18, Andrew Hughes wrote: > On 20:49 Mon 07 Dec , Alexander Scherbatiy wrote: >> Hello, >> >> Could you review the updated backport of JDK-8233228 to 8u. >> >> ? 8u webrev: >> http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.02/jdk.patch >> >> The only difference between the updated backport and the previous webrev.01 >> version >> is that the public modifier is removed from "static String[] >> getNamesByOID(String oid)" method >> of CurveDB class. >> >> All classes which use CurveDB.getNamesByOID(oid) method >> are placed in the same package as CurveDB and the original jdk11u patch >> has the package-private CurveDB.getNamesByOID(oid) method. >> >> Thanks, >> Alexander. >> >> On 12/3/20 7:36 PM, Alexander Scherbatiy wrote: >>> Hello, >>> >>> Could you review the updated backport of JDK-8233228 to 8u. >>> >>> ? 8u webrev: >>> http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.01 >>> >>> The classes ECParameters, NamedCurve, and CurveDB needs to be moved from >>> sun.security.ec packageto sun.security.util >>> because sun.security.ec is placed in sunec.jar and these classes are not >>> accessible >>> from ConstraintsParameters, DisabledAlgorithmConstraints which are >>> stored in rt.jar. >>> >>> Moving ECParameters, NamedCurve, and CurveDB classes is sent as a part >>> of a separate request [1] >>> ?? JDK-8035166: Remove dependency on EC classes from pkcs11 provider >>> >>> The patch for JDK-8035166 needs to be applied first and the patch for >>> JDK-8233228 on top of it. >>> >>> The tests compact3, java_security, java_security_infra, needs_jdk, and >>> needs_jre were run. >>> >>> In total they contain the following crypto and security tests: >>> ? sun/security/tools/jarsigner/* >>> ? com/sun/crypto/provider/* >>> ? com/sun/security/* >>> ? java/security/* >>> ? javax/crypto/* >>> ? javax/net/ssl/* >>> ? javax/security/* >>> ? javax/xml/crypto/* >>> ? sun/security/* >>> ? security/infra/java/security/* >>> >>> The are no new failures comparing to the build without the fix. >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-December/013171.html >>> >>> Thanks, >>> Alexander >>> >>> On 12/2/20 8:34 AM, Andrew Hughes wrote: >>>> On 22:14 Tue 01 Dec???? , Alexander Scherbatiy wrote: >>>>> ?Hello, >>>>> >>>>> Could you review the backport of P2 JDK-8233228 to 8u. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8233228 >>>>> 11u patch: >>>>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a17295342862 >>>>> 8u webrev: >>>>> http://cr.openjdk.java.net/~alexsch/sercher/8233228/webrev.00 >>>>> >>>>> >>>>> 8233228 backport to 8u (compared to 11u): >>>>> *?sun.security.ec.ECParameters -> sun.security.util.ECParameters >>>>> *?sun.security.ec.NamedCurve?? -> sun.security.util.NamedCurve >>>>> *?sun.security.ec.CurveDB????? -> sun.security.util.CurveDB >>>>> * security/tools/keytool fixed context difference >>>>> * DisabledAlgorithmConstraints.java fixed context difference >>>>> * Manual merge in ConstraintsParameters.java (XECKey, >>>>> NamedParameterSpec are >>>>> not available in 8u). >>>>> * CurveDB.SPLIT_PATTERN, CurveDB.getSupportedCurves() made public >>>>> * NamedCurve class, getName(), getObjectId() made public >>>>> * ECParameters.getAlgorithmParameters() made public >>>>> * files java.security- are separate in each platform, applied >>>>> identical changes in all >>>>> >>>> Why is it necessary to move the package these files are in? >>>> >>>> If we really need to do this, it should be done as a separate backport >>>> of JDK-8035166, but I'm not yet convinced this is necessary, given the >>>> disruption it will cause to code that relies on the code being in the >>>> current locations. >>>> >>>>> The are no new failures in hotspot and compact3 tests comparing >>>>> to the build >>>>> without the fix. >>>> I'm not sure how HotSpot tests would relate to a crypto change. What >>>> crypto >>>> tests were run? >>>> >>>>> Thanks, >>>>> Alexander. >>>>> >>>> Thanks, > This looks ok to me now. Reviewed & approved. > > Thanks, -- Best regards, Sergey Chernyshev Bellsoft LLC From yano-masanori at fujitsu.com Tue Jan 12 07:29:50 2021 From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com) Date: Tue, 12 Jan 2021 07:29:50 +0000 Subject: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails on Windows because of extra-'' In-Reply-To: References: Message-ID: Hello, Please reply if anyone can be a sponsor. Regards, Masanori Yano > -----Original Message----- > From: Yano, Masanori > Sent: Wednesday, December 23, 2020 4:58 PM > To: 'jdk8u-dev at openjdk.java.net' > Subject: [PING] RE: 8180478: tools/launcher/MultipleJRE.sh fails on Windows > because of extra-'' > > Hello, > > Please reply if anyone can be a sponsor. > > Regards, > Masanori Yano > > > -----Original Message----- > > From: Yano, Masanori/?? ?? > > Sent: Wednesday, November 11, 2020 4:06 PM > > To: 'jdk8u-dev at openjdk.java.net' > > Subject: 8180478: tools/launcher/MultipleJRE.sh fails on Windows > > because of extra-'' > > > > Hello. > > > > I would like to contribute for JDK-8180478. > > > > The test of tools/launcher/MultipleJRE.sh fails on the JDK8 for the > > Windows because the 'RELEASE' variable contains the carriage return. > > > > The 'RELEASE' variable is created from the third word in the first > > line of the "java -version" command. > > But this is a last word of the line, so the 'RELEASE' variable > > contains the carriage return. > > The 'RELEASE' variable is compared to the actual java version, but > > does not match because of the carriage return difference. > > > > Since JDK 11, this is no longer a problem because the date has been > > added as a fourth word. > > Therefore, the test for JDK8 should be fixed to remove the carriage returns. > > > > Please sponsor the following change. > > > > diff -r 4c5dceabd4c6 test/tools/launcher/MultipleJRE.sh > > --- a/test/tools/launcher/MultipleJRE.sh Mon Apr 21 14:35:14 2014 > +0400 > > +++ b/test/tools/launcher/MultipleJRE.sh Tue Nov 10 20:08:05 2020 > > +0900 > > @@ -308,7 +308,7 @@ > > # Main test sequence starts here > > # > > RELEASE=`$JAVA -version 2>&1 | head -n 1 | cut -d ' ' -f 3 | \ > > - sed -e "s/\"//g"` > > + sed -e "s/\"//g" | sed -e "s/\r//g"` > > BASE_RELEASE=`echo $RELEASE | sed -e "s/-.*//g"` > > > > # > > > > Regards, > > Masanori Yano From aph at redhat.com Tue Jan 12 10:30:14 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Jan 2021 10:30:14 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> Message-ID: <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> On 1/11/21 11:27 AM, Volker Simonis wrote: > Using Andrew H's proposal would certainly work as well, but from my > point of view it would be a bigger difference compared to the original > change so I'd vote for keeping David's version. It would, but the original code was obscure and misleading, and now we have code which is both misleading and suppresses a warning. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue Jan 12 10:44:22 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 Jan 2021 11:44:22 +0100 Subject: [8u] RFR Backport 8167281: IIOMetadataNode bugs in getElementsByTagName and NodeList.item methods In-Reply-To: <6cf95c93-d536-b371-11ac-600307cabdbf@redhat.com> References: <6cf95c93-d536-b371-11ac-600307cabdbf@redhat.com> Message-ID: On Mon, 2021-01-11 at 18:51 -0500, Elliott Baron wrote: > Hi, > > I'd like to request a review to backport 8167281 to 8u. > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8167281 > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ffba2718d7f6 > > The original fix did not apply cleanly, but only required a small change > to the patch context. This is due to 8u using a raw List in the > getElementsByTagName signature instead of a parameterized List. > > 8u webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8167281/webrev.00/ This looks fine to me. Thanks, Severin From volker.simonis at gmail.com Tue Jan 12 17:46:28 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 Jan 2021 18:46:28 +0100 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> Message-ID: On Tue, Jan 12, 2021 at 11:30 AM Andrew Haley wrote: > > On 1/11/21 11:27 AM, Volker Simonis wrote: > > Using Andrew H's proposal would certainly work as well, but from my > > point of view it would be a bigger difference compared to the original > > change so I'd vote for keeping David's version. > > It would, but the original code was obscure and misleading, and now we > have code which is both misleading and suppresses a warning. > Not sure what you are meaning by "obscure and misleading". I find the original code is concise and clear. It tries its best to consume the input and close the socket (by calling "appInput.deplete()"), but in any case, even if that fails, it will close 'conContext.inputRecord': try (conContext.inputRecord) { // Try the best to use up the input records and close the // socket gracefully, without impact the performance too // much. appInput.deplete(); } Notice that it is perfectly fine to put an autoclosable resources in the try clause, even if that resource is not used within the try block itself. After all, that's the reason why Java 9 simplified this pattern by extending "try-with resources" to also accept already existing resources as final or "effectively final" variables in the try statement [1]. Nothing obscure at all. In 8 however, we have to declare a new variable for the resource in the try clause, because the Java 9 simplification isn't available. If we were to write new code for jdk8 I could agree with you to use the older, more traditional pattern. But we're reviewing a downport here and for downports we have other priorities: - keep modifications of a change to a minimum - try to not impact future downports As David mentioned, more backports in this area will follow that's why I think that the code version he presented is the best compromise. Best regards, Volker [1] https://docs.oracle.com/en/java/javase/15/language/java-language-changes.html#GUID-A920DB06-0FD1-4F9C-8A9A-15FC979D5DA3 > -- > 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 peter.zhelezniakov at bell-sw.com Tue Jan 12 17:51:12 2021 From: peter.zhelezniakov at bell-sw.com (Peter Zhelezniakov) Date: Tue, 12 Jan 2021 20:51:12 +0300 Subject: [Ping] Re: RFR [1/3]: 8057038 Speculative traps not robust when compilation and class unloading are concurrent In-Reply-To: <9A1F0FBE-AC8D-4A17-B014-1C8EFF6F21E8@getmailspring.com> References: <9A1F0FBE-AC8D-4A17-B014-1C8EFF6F21E8@getmailspring.com> Message-ID: <9D37C4B3-6FA8-4BCF-A842-C6D747F32321@getmailspring.com> 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 zgu at redhat.com Tue Jan 12 18:40:07 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 12 Jan 2021 13:40:07 -0500 Subject: [8u] RFR 8074286: Add getSelectedIndices() to ListSelectionModel Message-ID: <3e54e1c6-edf2-53af-c91a-9b291fd3e447@redhat.com> I would like to backport this patch to 8u. It is *not* a parity backport. However, JDK-8072767, which is a parity backport, has dependence on it. Without this patch, the new test fails. Original bug: https://bugs.openjdk.java.net/browse/JDK-8074286 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/5daa8ef17089 The original patch does not apply cleanly. There is a conflict in JList.java, due to line shifts. Resolved manually. 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8074286-8u/webrev.00/ Thanks, -Zhengyu From ecki at zusammenkunft.net Wed Jan 13 00:24:32 2021 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 13 Jan 2021 00:24:32 +0000 Subject: RFR: 8u backport of JDK-8243114 Implement montgomery{Multiply,Square}intrinsics on Windows In-Reply-To: <6c2a6dff-3156-55aa-b06c-cf82a8e43877@redhat.com> References: <6c2a6dff-3156-55aa-b06c-cf82a8e43877@redhat.com> Message-ID: The patch does not touch the flag processing, will PrintFlagsFinal be able to tell if the version, compiler and os supports it? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: jdk8u-dev im Auftrag von Simon Tooke Gesendet: Monday, January 11, 2021 10:08:38 PM An: jdk8u-dev at openjdk.java.net Betreff: RFR: 8u backport of JDK-8243114 Implement montgomery{Multiply,Square}intrinsics on Windows Backport of JDK-8243114 Implement montgomery{Multiply,Square} intrinsics on Windows JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 Webrev: http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk8u/hotspot.01/ I would like to backport this performance enhancement to 8u, for performance and for Oracle parity. The backport is trivial, with one exception: Visual Studio 2010 does not implement a required compiler intrinsic used by this backport. Accordingly, the backport is #ifdef'ed to only apply on Windows if Visual Studio 2017 (or higher) is used as the build compiler. I do not have (so was not able to test this backport with) intermediate versions of VS; if someone were to grep for _addcarry_u64 in intrin.h, perhaps earlier versions can be supported. Visual Studio 2010 is still supported as a build compiler, but will not reap the benefit of this backport. In addition, MontgomeryMultiplyTest is no longer omitted on Windows platforms, and I made sure to apply 8248347 (the follow-up build fix patch). Using the program below, speedups were observed: >openjdk-8u282-b04-vs2010\bin\java MMTest elapsed time 58220 ms >openjdk-8u282-b04-vs2017\bin\java -XX:+UseMontgomeryMultiplyIntrinsic -XX:+UseMontgomerySquareIntrinsic MMTest (this is the default) elapsed time 25471 ms >openjdk-8u282-b04-vs2017\bin\java -XX:-UseMontgomeryMultiplyIntrinsic -XX:-UseMontgomerySquareIntrinsic MMTest elapsed time 58980 ms Test code: class MMTest { public static void main(String[] args) { Instant start = Instant.now(); BigInteger base = BigInteger.ONE.shiftLeft(1024); long count = LongStream.rangeClosed(2, 100_000) .mapToObj(n -> BigInteger.valueOf(n).add(base)) .filter(i -> i.isProbablePrime(50)) .count(); Instant finish = Instant.now(); long timeElapsed = Duration.between(start, finish).toMillis(); System.out.format("elapsed time %d ms\n", timeElapsed); } } Thanks, -simon From aph at redhat.com Wed Jan 13 10:30:03 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jan 2021 10:30:03 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> Message-ID: On 1/12/21 5:46 PM, Volker Simonis wrote: > Notice that it is perfectly fine to put an autoclosable resources in > the try clause, even if that resource is not used within the try block > itself. After all, that's the reason why Java 9 simplified this > pattern by extending "try-with resources" to also accept already > existing resources as final or "effectively final" variables in the > try statement [1]. Nothing obscure at all. One person's obscure is another's apogee of clarity, I suppose. The problem here, IMO, is that the TWR construct doesn't do anything useful: it's only hiding a catch-then-close. > In 8 however, we have to declare a new variable for the resource in > the try clause, because the Java 9 simplification isn't available. If > we were to write new code for jdk8 I could agree with you to use the > older, more traditional pattern. But we're reviewing a downport here > and for downports we have other priorities: > - keep modifications of a change to a minimum > - try to not impact future downports OK, so for you deviations from upstream patches are more important than idiomatic JDK8 code. I get that, but in this case the resulting code is such that it provokes a warning, which I expect you'll admit is something of a red flag. Any backports to a "stable" release that generate new warnings are a big deal, IMO, although I grant you that this warning is not about anything terribly important. > As David mentioned, more backports in this area will follow that's why > I think that the code version he presented is the best compromise. In this exact area, as in these lines of code or the ones next to them? If not, that doesn't matter. -- 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 stooke at redhat.com Wed Jan 13 13:45:53 2021 From: stooke at redhat.com (Simon Tooke) Date: Wed, 13 Jan 2021 08:45:53 -0500 Subject: RFR: 8u backport of JDK-8243114 Implement montgomery{Multiply,Square}intrinsics on Windows In-Reply-To: References: <6c2a6dff-3156-55aa-b06c-cf82a8e43877@redhat.com> Message-ID: Hello, Bernd, and thanks for taking a look at this. On 2021-01-12 7:24 p.m., Bernd Eckenfels wrote: > The patch does not touch the flag processing, will PrintFlagsFinal be able to tell if the version, compiler and os supports it? The original patch did not touch the flag processing either, so I would not have included it in this patch. Currently the flag processing only emits an error if a 32-bit VM is used. For 64 bit VMs on all platforms and compilers (if I read the code correctly), the flag is valid, but implementation of the intrinsic varies (by nature; it is an intrinsic). So it's slower on some platforms and faster on others; this patch merely speeds up the implementation when built with the correct compiler.? The defaults for the flag are unchanged. Thanks, -Simon > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: jdk8u-dev im Auftrag von Simon Tooke > Gesendet: Monday, January 11, 2021 10:08:38 PM > An: jdk8u-dev at openjdk.java.net > Betreff: RFR: 8u backport of JDK-8243114 Implement montgomery{Multiply,Square}intrinsics on Windows > > Backport of JDK-8243114 Implement montgomery{Multiply,Square} intrinsics > on Windows > > JBS: https://bugs.openjdk.java.net/browse/JDK-8243114 > > > Webrev: > http://cr.openjdk.java.net/~stooke/webrevs/jdk-8243114-jdk8u/hotspot.01/ > > > I would like to backport this performance enhancement to 8u, for > performance and for Oracle parity. > > The backport is trivial, with one exception: Visual Studio 2010 does not > implement a required compiler intrinsic used by this backport. > > Accordingly, the backport is #ifdef'ed to only apply on Windows if > Visual Studio 2017 (or higher) is used as the build compiler. > > I do not have (so was not able to test this backport with) intermediate > versions of VS; if someone were to grep for _addcarry_u64 in intrin.h, > perhaps earlier versions can be supported. > > Visual Studio 2010 is still supported as a build compiler, but will not > reap the benefit of this backport. > > In addition, MontgomeryMultiplyTest is no longer omitted on Windows > platforms, and I made sure to apply 8248347 (the follow-up build fix patch). > > Using the program below, speedups were observed: > > >openjdk-8u282-b04-vs2010\bin\java MMTest > elapsed time 58220 ms > > >openjdk-8u282-b04-vs2017\bin\java -XX:+UseMontgomeryMultiplyIntrinsic > -XX:+UseMontgomerySquareIntrinsic MMTest (this is the default) > elapsed time 25471 ms > > >openjdk-8u282-b04-vs2017\bin\java -XX:-UseMontgomeryMultiplyIntrinsic > -XX:-UseMontgomerySquareIntrinsic MMTest > elapsed time 58980 ms > > Test code: > > class MMTest { > > public static void main(String[] args) { > Instant start = Instant.now(); > BigInteger base = BigInteger.ONE.shiftLeft(1024); > long count = LongStream.rangeClosed(2, 100_000) > .mapToObj(n -> BigInteger.valueOf(n).add(base)) > .filter(i -> i.isProbablePrime(50)) > .count(); > Instant finish = Instant.now(); > long timeElapsed = Duration.between(start, finish).toMillis(); > System.out.format("elapsed time %d ms\n", timeElapsed); > } > } > > > Thanks, > > -simon > > > > From volker.simonis at gmail.com Wed Jan 13 14:02:38 2021 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 13 Jan 2021 15:02:38 +0100 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> Message-ID: Andrew Haley schrieb am Mi., 13. Jan. 2021, 11:30: > On 1/12/21 5:46 PM, Volker Simonis wrote: > > Notice that it is perfectly fine to put an autoclosable resources in > > the try clause, even if that resource is not used within the try block > > itself. After all, that's the reason why Java 9 simplified this > > pattern by extending "try-with resources" to also accept already > > existing resources as final or "effectively final" variables in the > > try statement [1]. Nothing obscure at all. > > One person's obscure is another's apogee of clarity, I suppose. > The problem here, IMO, is that the TWR construct doesn't do > anything useful: it's only hiding a catch-then-close. > > > In 8 however, we have to declare a new variable for the resource in > > the try clause, because the Java 9 simplification isn't available. If > > we were to write new code for jdk8 I could agree with you to use the > > older, more traditional pattern. But we're reviewing a downport here > > and for downports we have other priorities: > > - keep modifications of a change to a minimum > > - try to not impact future downports > > OK, so for you deviations from upstream patches are more important > than idiomatic JDK8 code. I get that, but in this case the resulting > code is such that it provokes a warning, which I expect you'll admit > is something of a red flag. Any backports to a "stable" release that > generate new warnings are a big deal, IMO, although I grant you that > this warning is not about anything terribly important. > But this warning is suppress by an annotation as it is already done in several other places in the 8u code base. If that's still not acceptable for you I won't argue any further and recommend David to rewrite his downport as proposed by you. In the end we only want to fix the underlaying issue. > > As David mentioned, more backports in this area will follow that's why > > I think that the code version he presented is the best compromise. > > In this exact area, as in these lines of code or the ones next to > them? If not, that doesn't matter. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From alvdavi at amazon.com Wed Jan 13 22:12:12 2021 From: alvdavi at amazon.com (Alvarez, David) Date: Wed, 13 Jan 2021 22:12:12 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> Message-ID: <6994ca3d8a71cdebfc9a0f7ea1a79048246bb35b.camel@amazon.com> Hi, I have uploaded two new versions of the patch. The first one replaces the try-with-resources with its equivalent. This removes the need for the SuppressWarnings: http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.01/ The second one is what Andrew was suggesting, just adding the finally block. The only problem with this approach is that an exception in the close call would override an exception in the deplete call. The deplete call seems pretty safe though, as it is already suppresing potential IOExceptions, so this is probably fine. http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.02/ I really don't care which version gets approved. I went through all three before. My first implementation was v02, then I moved to v01 because I wanted to ensure there was no possible difference on how exceptions were being thrown and finally to v00 with the SuppressWarnings because v01 was just ugly. I hope this helps. Just make clear which version gets approved so I can mention it in the JBS bug when adding the jdk8u-fix-request. Thanks, David On Wed, 2021-01-13 at 15:02 +0100, Volker Simonis wrote: > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > > Andrew Haley schrieb am Mi., 13. Jan. 2021, 11:30: > > > On 1/12/21 5:46 PM, Volker Simonis wrote: > > > Notice that it is perfectly fine to put an autoclosable resources > > > in > > > the try clause, even if that resource is not used within the try > > > block > > > itself. After all, that's the reason why Java 9 simplified this > > > pattern by extending "try-with resources" to also accept already > > > existing resources as final or "effectively final" variables in > > > the > > > try statement [1]. Nothing obscure at all. > > > > One person's obscure is another's apogee of clarity, I suppose. > > The problem here, IMO, is that the TWR construct doesn't do > > anything useful: it's only hiding a catch-then-close. > > > > > In 8 however, we have to declare a new variable for the resource > > > in > > > the try clause, because the Java 9 simplification isn't > > > available. If > > > we were to write new code for jdk8 I could agree with you to use > > > the > > > older, more traditional pattern. But we're reviewing a downport > > > here > > > and for downports we have other priorities: > > > - keep modifications of a change to a minimum > > > - try to not impact future downports > > > > OK, so for you deviations from upstream patches are more important > > than idiomatic JDK8 code. I get that, but in this case the > > resulting > > code is such that it provokes a warning, which I expect you'll > > admit > > is something of a red flag. Any backports to a "stable" release > > that > > generate new warnings are a big deal, IMO, although I grant you > > that > > this warning is not about anything terribly important. > > > > But this warning is suppress by an annotation as it is already done > in > several other places in the 8u code base. > > If that's still not acceptable for you I won't argue any further and > recommend David to rewrite his downport as proposed by you. In the > end we > only want to fix the underlaying issue. > > > > > As David mentioned, more backports in this area will follow > > > that's why > > > I think that the code version he presented is the best > > > compromise. > > > > In this exact area, as in these lines of code or the ones next to > > them? If not, that doesn't matter. > > > > -- > > 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 Thu Jan 14 06:29:22 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 14 Jan 2021 06:29:22 +0000 Subject: RFR: 8166811: Missing memory fences between memory allocation and refinement Message-ID: Hi, Please review the backport of JDK-8166811 to 8u: Original bug: https://bugs.openjdk.java.net/browse/JDK-8166811 Original RFR thread: https://mail.openjdk.java.net/pipermail/hotspot-dev/2016-October/025027.html Original change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/075fbfdb498f This is necessary for RMO architectures like aarch64. Original change does not apply cleanly to 8u-dev repo. Two changes for 8u: 1. Removed comment added in file g1CollectedHeap.cpp; 2. Trivial adaptation is needed for newly added function is_old_or_humongous in file heapRegionType.hpp; Webrev for 8u: http://cr.openjdk.java.net/~fyang/8259659/webrev.00/ Performed two rounds of jtreg testing: first round without extra option and second round with -XX:+UseG1GC option. Also performed two rounds of specjbb2015 with -XX:+UseG1GC. OK to backport? Thanks, Felix From aph at redhat.com Thu Jan 14 10:24:35 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jan 2021 10:24:35 +0000 Subject: RFR: 8166811: Missing memory fences between memory allocation and refinement In-Reply-To: References: Message-ID: <2bf7507c-37d3-9044-95bb-acc336f3cce2@redhat.com> On 1/14/21 6:29 AM, Yangfei (Felix) wrote: > Webrev for 8u: http://cr.openjdk.java.net/~fyang/8259659/webrev.00/ > > Performed two rounds of jtreg testing: first round without extra option and second round with -XX:+UseG1GC option. > Also performed two rounds of specjbb2015 with -XX:+UseG1GC. > OK to backport? Crikey, that's a big change. I guess we should be pretty safe, given that the original patch was for JDK 9. Have any problems ever been observed on JDK 8? -- 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 Thu Jan 14 11:40:37 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 14 Jan 2021 11:40:37 +0000 Subject: RFR: 8166811: Missing memory fences between memory allocation and refinement In-Reply-To: <2bf7507c-37d3-9044-95bb-acc336f3cce2@redhat.com> References: <2bf7507c-37d3-9044-95bb-acc336f3cce2@redhat.com> Message-ID: Hi, > -----Original Message----- > From: jdk8u-dev [mailto:jdk8u-dev-retn at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Thursday, January 14, 2021 6:25 PM > To: jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8166811: Missing memory fences between memory > allocation and refinement > > On 1/14/21 6:29 AM, Yangfei (Felix) wrote: > > Webrev for 8u: http://cr.openjdk.java.net/~fyang/8259659/webrev.00/ > > > > Performed two rounds of jtreg testing: first round without extra option and > second round with -XX:+UseG1GC option. > > Also performed two rounds of specjbb2015 with -XX:+UseG1GC. > > OK to backport? > > Crikey, that's a big change. I guess we should be pretty safe, given that the > original patch was for JDK 9. Have any problems ever been observed on JDK 8? Thanks for the reply. I agree it's not a trivial change. This is not biting me for now when using JDK 8. And I guess it would be hard to trigger. I can leave it aside if it doesn't worth the risk for JDK 8. Best Regards, Felix From aph at redhat.com Thu Jan 14 16:16:05 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jan 2021 16:16:05 +0000 Subject: RFR: 8166811: Missing memory fences between memory allocation and refinement In-Reply-To: References: <2bf7507c-37d3-9044-95bb-acc336f3cce2@redhat.com> Message-ID: <47d2fc5a-8e46-98ab-2b52-f3fe620c0c60@redhat.com> On 1/14/21 11:40 AM, Yangfei (Felix) wrote: > Thanks for the reply. I agree it's not a trivial change. > This is not biting me for now when using JDK 8. And I guess it would be hard to trigger. > I can leave it aside if it doesn't worth the risk for JDK 8. I'm not sure, to be honest. It feels like something we should have, and I hate the idea of missing fences, it's just as shame that this patch wasn't just a few missing fences, but a big reorganization. We know that changes in one part of the GC affect other parts, and it might well be that the JDK 9 patch breaks something else. Maybe we could get some advice from someone familiar with the GC. -- 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 Fri Jan 15 09:11:03 2021 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 15 Jan 2021 09:11:03 +0000 Subject: RFR: 8166811: Missing memory fences between memory allocation and refinement In-Reply-To: <47d2fc5a-8e46-98ab-2b52-f3fe620c0c60@redhat.com> References: <2bf7507c-37d3-9044-95bb-acc336f3cce2@redhat.com> <47d2fc5a-8e46-98ab-2b52-f3fe620c0c60@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Friday, January 15, 2021 12:16 AM > To: Yangfei (Felix) ; jdk8u-dev at openjdk.java.net > Subject: Re: RFR: 8166811: Missing memory fences between memory > allocation and refinement > > On 1/14/21 11:40 AM, Yangfei (Felix) wrote: > > Thanks for the reply. I agree it's not a trivial change. > > This is not biting me for now when using JDK 8. And I guess it would be > hard to trigger. > > I can leave it aside if it doesn't worth the risk for JDK 8. > > I'm not sure, to be honest. It feels like something we should have, and I hate > the idea of missing fences, it's just as shame that this patch wasn't just a few > missing fences, but a big reorganization. We know that changes in one part of > the GC affect other parts, and it might well be that the JDK 9 patch breaks > something else. > > Maybe we could get some advice from someone familiar with the GC. Yes, comments from GC experts would surely be appreciated here. Could we have some GC folks to take a look please? Thanks, Felix From aph at redhat.com Sat Jan 16 11:11:55 2021 From: aph at redhat.com (Andrew Haley) Date: Sat, 16 Jan 2021 11:11:55 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: <6994ca3d8a71cdebfc9a0f7ea1a79048246bb35b.camel@amazon.com> References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> <6994ca3d8a71cdebfc9a0f7ea1a79048246bb35b.camel@amazon.com> Message-ID: Hi, On 1/13/21 10:12 PM, Alvarez, David wrote: > > I have uploaded two new versions of the patch. > > The first one replaces the try-with-resources with its equivalent. This > removes the need for the SuppressWarnings: > > http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.01/ > > > The second one is what Andrew was suggesting, just adding the finally > block. The only problem with this approach is that an exception in the > close call would override an exception in the deplete call. The deplete > call seems pretty safe though, as it is already suppresing potential > IOExceptions, so this is probably fine. > > http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.02/ > > I really don't care which version gets approved. I went through all > three before. My first implementation was v02, then I moved to v01 > because I wanted to ensure there was no possible difference on how > exceptions were being thrown and finally to v00 with the > SuppressWarnings because v01 was just ugly. Thank you very much for doing this. It certainly wasn't my intention to change the behaviour of this code, so I think my suggestion is not appropriate. I also agree that v01 is just ugly. So, please go ahead with the SuppressWarnings. I'm sorry I ever doubted you. :-) -- 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 m.yamamoto at change-vision.com Mon Jan 18 05:58:42 2021 From: m.yamamoto at change-vision.com (Mitsuhiro Yamamoto) Date: Mon, 18 Jan 2021 14:58:42 +0900 Subject: [macosx] Action registered for keyboard shortcut is called twice Message-ID: Hi there, The fix for the bug shown below has been applied since Java 9, but it doesn't seem to be applied to Java 8. So could you backport this fix to Java 8? https://bugs.openjdk.java.net/browse/JDK-8139169 For reference, this is the fix commit for it in openjdk/jdk. https://github.com/openjdk/jdk/commit/7d9d3a469949a3874f35ebacb140e0aaf49c12f0 Best Regards Mit From shade at redhat.com Mon Jan 18 14:02:02 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Jan 2021 15:02:02 +0100 Subject: [8u] RFR (XS) 8259568: PPC64 builds broken after JDK-8221408 8u backport In-Reply-To: <7daf9872-679f-0b8c-f6f0-9a5f142ea3ed@redhat.com> References: <7daf9872-679f-0b8c-f6f0-9a5f142ea3ed@redhat.com> Message-ID: <5dc6caeb-d0f8-256d-d618-aa88475982f3@redhat.com> On 1/11/21 4:58 PM, Aleksey Shipilev wrote: > This is 8u-specific bug: > https://bugs.openjdk.java.net/browse/JDK-8259568 > > Please read the details in the bug report. > > Fix: > http://cr.openjdk.java.net/~shade/8259568/webrev.01/ > > Testing: Linux PPC64 build (used to fail before, passes now); jcstress (running) jcstress runs pass. Friendly reminder that this is still a problem in jdk8-dev. -- Thanks, -Aleksey From martin.doerr at sap.com Mon Jan 18 14:33:33 2021 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Jan 2021 14:33:33 +0000 Subject: [8u] RFR (XS) 8259568: PPC64 builds broken after JDK-8221408 8u backport In-Reply-To: <5dc6caeb-d0f8-256d-d618-aa88475982f3@redhat.com> References: <7daf9872-679f-0b8c-f6f0-9a5f142ea3ed@redhat.com> <5dc6caeb-d0f8-256d-d618-aa88475982f3@redhat.com> Message-ID: Hi Aleksey, your fix looks good. Thanks for fixing it. Best regards, Martin > -----Original Message----- > From: jdk8u-dev On Behalf Of Aleksey > Shipilev > Sent: Montag, 18. Januar 2021 15:02 > To: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFR (XS) 8259568: PPC64 builds broken after JDK-8221408 8u > backport > > On 1/11/21 4:58 PM, Aleksey Shipilev wrote: > > This is 8u-specific bug: > > https://bugs.openjdk.java.net/browse/JDK-8259568 > > > > Please read the details in the bug report. > > > > Fix: > > http://cr.openjdk.java.net/~shade/8259568/webrev.01/ > > > > Testing: Linux PPC64 build (used to fail before, passes now); jcstress > (running) > > jcstress runs pass. > > Friendly reminder that this is still a problem in jdk8-dev. > > -- > Thanks, > -Aleksey From zgu at redhat.com Mon Jan 18 15:18:17 2021 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 18 Jan 2021 10:18:17 -0500 Subject: [8u] RFR 8072767: DefaultCellEditor for comboBox creates ActionEvent with wrong source object Message-ID: <8357fb1e-d09c-e5b8-7ef9-c93261f5c6ef@redhat.com> 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 shade at redhat.com Mon Jan 18 15:25:16 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 18 Jan 2021 16:25:16 +0100 Subject: [8u] RFR (XS) 8259568: PPC64 builds broken after JDK-8221408 8u backport In-Reply-To: References: <7daf9872-679f-0b8c-f6f0-9a5f142ea3ed@redhat.com> <5dc6caeb-d0f8-256d-d618-aa88475982f3@redhat.com> Message-ID: <6b45a8dc-df9b-4d74-6aa6-73f7cd90dd97@redhat.com> On 1/18/21 3:33 PM, Doerr, Martin wrote: > your fix looks good. Thanks for fixing it. Thank you. Tagged! -- -Aleksey From mbalao at redhat.com Mon Jan 18 19:57:52 2021 From: mbalao at redhat.com (Martin Balao) Date: Mon, 18 Jan 2021 16:57:52 -0300 Subject: [8u] RFR 8242141: New System Properties to configure the TLS signature schemes Message-ID: Hi, I'd like to propose an 8u backport of JDK-8242141 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8242141/8242141.webrev.8u.jdk.00/ The 11u backport does not apply cleanly to 8u because of the following conflicts: * src/share/classes/sun/security/ssl/CertSignAlgsExtension.java * In 8u, JDK-8245470 [2] was applied changing the context on line 244. This was to substitute a List::of call. Manually added shc.sslConfig parameter and rearranged the list of parameters to look similar to 11u. * src/share/classes/sun/security/ssl/SSLConfiguration.java * In 8u there is JDK-8245417 [3] which changes the context by adding an import. Manually added the import for JDK-8242141. * src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java * In 8u, JDK-8245470 [2] was applied changing the context on line 410. This was to substitute a List::of call. Manually added shc.sslConfig parameter and rearranged the list of parameters to look similar to 11u. No regressions found in jdk/sun/security/ssl. Once I have a review-approval, I'll create a CSR and ask for maintainers approval. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8242141 [2] - https://bugs.openjdk.java.net/browse/JDK-8245470 [3] - https://bugs.openjdk.java.net/browse/JDK-8245417 From sgehwolf at redhat.com Tue Jan 19 15:13:08 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 19 Jan 2021 16:13:08 +0100 Subject: [8u] RFR 8242141: New System Properties to configure the TLS signature schemes In-Reply-To: References: Message-ID: <05618234e702757f0996084e437b2b4b90b739b0.camel@redhat.com> On Mon, 2021-01-18 at 16:57 -0300, Martin Balao wrote: > Once I have a review-approval, I'll create a CSR and ask for maintainers > approval. CSR is here for this: https://bugs.openjdk.java.net/browse/JDK-8245536 No need to create a new one. Thanks, Severin From gnu.andrew at redhat.com Tue Jan 19 16:34:32 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 Jan 2021 16:34:32 +0000 Subject: [8u] RFR 8242141: New System Properties to configure the TLS signature schemes In-Reply-To: References: Message-ID: <20210119163432.GA1018664@rincewind> On 16:57 Mon 18 Jan , Martin Balao wrote: > Hi, > > I'd like to propose an 8u backport of JDK-8242141 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8242141/8242141.webrev.8u.jdk.00/ > > The 11u backport does not apply cleanly to 8u because of the following > conflicts: > > * src/share/classes/sun/security/ssl/CertSignAlgsExtension.java > * In 8u, JDK-8245470 [2] was applied changing the context on line 244. > This was to substitute a List::of call. Manually added shc.sslConfig > parameter and rearranged the list of parameters to look similar to 11u. > > * src/share/classes/sun/security/ssl/SSLConfiguration.java > * In 8u there is JDK-8245417 [3] which changes the context by adding > an import. Manually added the import for JDK-8242141. > > * src/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java > * In 8u, JDK-8245470 [2] was applied changing the context on line 410. > This was to substitute a List::of call. Manually added shc.sslConfig > parameter and rearranged the list of parameters to look similar to 11u. > > No regressions found in jdk/sun/security/ssl. > > Once I have a review-approval, I'll create a CSR and ask for maintainers > approval. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8242141 > [2] - https://bugs.openjdk.java.net/browse/JDK-8245470 > [3] - https://bugs.openjdk.java.net/browse/JDK-8245417 > This looks fine to me. Thanks for the very detailed account of the changes for 8u. I wasn't aware of JDK-8245470 before this. I assume that was part of the TLSv1.3 forest work? Please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Tue Jan 19 16:41:51 2021 From: mbalao at redhat.com (Martin Balao) Date: Tue, 19 Jan 2021 13:41:51 -0300 Subject: [8u] RFR 8242141: New System Properties to configure the TLS signature schemes In-Reply-To: <20210119163432.GA1018664@rincewind> References: <20210119163432.GA1018664@rincewind> Message-ID: Hi Andrew, On 1/19/21 1:34 PM, Andrew Hughes wrote: > This looks fine to me. Thanks for the very detailed account of the changes > for 8u. > Thanks for your review. > I wasn't aware of JDK-8245470 before this. I assume that was part of the > TLSv1.3 forest work? > Yes, 8245470 has a series of changes needed for the 11u-version of the TLS engine to work in 8u. Among these changes, we have equivalents to List::of uses. More info here [1]. Regards, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/011850.html From gnu.andrew at redhat.com Tue Jan 19 17:10:50 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 Jan 2021 17:10:50 +0000 Subject: [8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close In-Reply-To: References: <3dce681fdef81e79f3ceb5223442ac543e9c48f2.camel@amazon.com> <20210111040818.GA119842@rincewind> <3a6fdef4-b571-fd05-5bc9-8b7580836707@redhat.com> <11d679b5-cf8b-f5d3-51d9-1d27c37b15c2@redhat.com> <6994ca3d8a71cdebfc9a0f7ea1a79048246bb35b.camel@amazon.com> Message-ID: <20210119171050.GB1018664@rincewind> On 11:11 Sat 16 Jan , Andrew Haley wrote: > Hi, > > On 1/13/21 10:12 PM, Alvarez, David wrote: > > > > I have uploaded two new versions of the patch. > > > > The first one replaces the try-with-resources with its equivalent. This > > removes the need for the SuppressWarnings: > > > > http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.01/ > > > > > > The second one is what Andrew was suggesting, just adding the finally > > block. The only problem with this approach is that an exception in the > > close call would override an exception in the deplete call. The deplete > > call seems pretty safe though, as it is already suppresing potential > > IOExceptions, so this is probably fine. > > > > http://cr.openjdk.java.net/~alvdavi/webrevs/8209333/webrev.8u.jdk.02/ > > > > I really don't care which version gets approved. I went through all > > three before. My first implementation was v02, then I moved to v01 > > because I wanted to ensure there was no possible difference on how > > exceptions were being thrown and finally to v00 with the > > SuppressWarnings because v01 was just ugly. > > Thank you very much for doing this. It certainly wasn't my intention to > change the behaviour of this code, so I think my suggestion is not > appropriate. I also agree that v01 is just ugly. > > So, please go ahead with the SuppressWarnings. I'm sorry I ever doubted > you. :-) > > -- > 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 > Ok, sounds like this one can be flagged for approval, David. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed Jan 20 04:51:29 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Jan 2021 04:51:29 +0000 Subject: OpenJDK 8u282 Released Message-ID: <20210120045129.GA1247983@rincewind> We are pleased to announce the release of OpenJDK 8u282. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u282-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk8/openjdk8u282-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: e5c0000d54fea680375ab06e6d477713fb5c294d84baf0ed6224498bde811b7c openjdk8u282-ga.tar.xz 312d9de15c5bf667c17c8dc4b8a582ec929fbc5af227e005b48c15744d512ecf openjdk8u282-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk8/openjdk8u282-ga.sha256 New in release OpenJDK 8u282 (2021-01-19): =========================================== Live versions of these release notes can be found at: * https://bitly.com/openjdk8u282 * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u282.txt * Security fixes - JDK-8247619: Improve Direct Buffering of Characters * Other changes - JDK-6962725: Regtest javax/swing/JFileChooser/6738668/bug6738668.java fails under Linux - JDK-8008657: JSpinner setComponentOrientation doesn't affect on text orientation - JDK-8022535: [TEST BUG] javax/swing/text/html/parser/Test8017492.java fails - JDK-8025936: Windows .pdb and .map files does not have proper dependencies setup - JDK-8030350: Enable additional compiler warnings for GCC - JDK-8031423: Test java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails by Timeout on Windows - JDK-8036122: Fix warning 'format not a string literal' - JDK-8039279: Move awt tests to openjdk repository - JDK-8041592: [TEST_BUG] Move 42 AWT hw/lw mixing tests to jdk - JDK-8043126: move awt automated functional tests from AWT_Events/Lw and AWT_Events/AWT to OpenJDK repository - JDK-8043131: Move ShapedAndTranslucentWindows and GC functional AWT tests to regression tree - JDK-8043899: compiler/5091921/Test7005594.java fails if specified -Xmx is less than 1600m - JDK-8044157: [TEST_BUG] Improve recently submitted AWT_Mixing tests - JDK-8044172: [TEST_BUG] Move regtests for 4523758 and AltPlusNumberKeyCombinationsTest to jdk - JDK-8044429: move awt automated tests for AWT_Modality to OpenJDK repository - JDK-8044765: Move functional tests AWT_SystemTray/Automated to openjdk repository - JDK-8046221: [TEST_BUG] Cleanup datatransfer tests - JDK-8047180: Move functional tests AWT_Headless/Automated to OpenJDK repository - JDK-8047367: move awt automated tests from AWT_Modality to OpenJDK repository - part 2 - JDK-8048246: Move AWT_DnD/Clipboard/Automated functional tests to OpenJDK - JDK-8049617: move awt automated tests from AWT_Modality to OpenJDK repository - part 3 - JDK-8049694: Migrate functional AWT_DesktopProperties/Automated tests to OpenJDK - JDK-8050885: move awt automated tests from AWT_Modality to OpenJDK repository - part 4 - JDK-8051440: move tests about maximizing undecorated to OpenJDK - JDK-8051853: new URI("x/").resolve("..").getSchemeSpecificPart() returns null! - JDK-8052012: move awt automated tests from AWT_Modality to OpenJDK repository - part 5 - JDK-8052408: Move AWT_BAT functional tests to OpenJDK (3 of 3) - JDK-8053657: [TEST_BUG] move some 5 tests related to undecorated Frame/JFrame to JDK - JDK-8054143: move awt automated tests from AWT_Modality to OpenJDK repository - part 6 - JDK-8054358: move awt automated tests from AWT_Modality to OpenJDK repository - part 7 - JDK-8054359: move awt automated tests from AWT_Modality to OpenJDK repository - part 8 - JDK-8055360: Move the rest part of AWT ShapedAndTranslucent tests to OpenJDK - JDK-8055664: move 14 tests about setLocationRelativeTo to jdk - JDK-8055836: move awt tests from AWT_Modality to OpenJDK repository - part 9 - JDK-8057694: move awt tests from AWT_Modality to OpenJDK repository - part 10 - JDK-8058805: [TEST_BUG]Test java/awt/TrayIcon/SecurityCheck/NoPermissionTest/NoPermissionTest.java fails - JDK-8062808: Turn on the -Wreturn-type warning - JDK-8063102: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1 - JDK-8063104: Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 2 - JDK-8063106: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 1 - JDK-8063107: Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 - JDK-8064573: [TEST_BUG] javax/swing/text/AbstractDocument/6968363/Test6968363.java is asocial pressing VK_LEFT and not releasing - JDK-8064575: [TEST_BUG] javax/swing/JEditorPane/6917744/bug6917744.java 100 times press keys and never releases - JDK-8064809: [TEST_BUG] javax/swing/JComboBox/4199622/bug4199622.java contains a lot of keyPress and not a single keyRelease - JDK-8067441: Some tests fails with error: cannot find symbol getSystemMnemonicKeyCodes() - JDK-8068228: Test closed/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest fails with GTKLookAndFeel - JDK-8068275: Some tests failed after JDK-8063104 - JDK-8069211: (zipfs) ZipFileSystem creates corrupted zip if entry output stream gets closed more than once - JDK-8074807: Fix some tests unnecessary using internal API - JDK-8076315: move 4 manual functional swing tests to regression suite - JDK-8130772: Util.hitMnemonics does not work: getSystemMnemonicKeyCodes() returns ALT_MASK rather than VK_ALT - JDK-8132664: closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on Windows - JDK-8134632: Mark javax/sound/midi/Devices/InitializationHang.java as headful - JDK-8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent - JDK-8148916: Mark bug6400879.java as intermittently failing - JDK-8148983: Fix extra comma in changes for JDK-8148916 - JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants - JDK-8156803: Turn StressLCM/StressGCM flags to diagnostic - JDK-8160438: javax/swing/plaf/nimbus/8057791/bug8057791.java fails - JDK-8160761: [TESTBUG] Several compiler tests fail with product bits - JDK-8163161: [PIT][TEST_BUG] increase timeout in javax/swing/plaf/nimbus/8057791/bug8057791.java - JDK-8165808: Add release barriers when allocating objects with concurrent collection - JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java - JDK-8166583: Add oopDesc::klass_or_null_acquire() - JDK-8166663: Simplify oops_on_card_seq_iterate_careful - JDK-8166862: CMS needs klass_or_null_acquire - JDK-8168292: [TESTBUG] [macosx] Test java/awt/TrayIcon/DragEventSource/DragEventSource.java fails on OS X - JDK-8168682: jdk/test/java/lang/ClassLoader/forNameLeak/ClassForNameLeak.java fails with -Xcomp - JDK-8179083: Uninitialized notifier in Java Monitor Wait tracing event - JDK-8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument - JDK-8197981: Missing return statement in __sync_val_compare_and_swap_8 - JDK-8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017 - JDK-8205507: jdk/javax/xml/crypto/dsig/GenerationTests.java timed out - JDK-8207766: [testbug] Adapt tests for Aix. - JDK-8212070: Introduce diagnostic flag to abort VM on failed JIT compilation - JDK-8213448: [TESTBUG] enhance jfr/jvm/TestDumpOnCrash - JDK-8215727: Restore JFR thread sampler loop to old / previous behavior - JDK-8217362: Emergency dump does not work when disk=false is set - JDK-8217766: Container Support doesn't work for some Join Controllers combinations - JDK-8219013: Update Apache Santuario (XML Signature) to version 2.1.3 - JDK-8219562: Line of code in osContainer_linux.cpp L102 appears unreachable - JDK-8220579: [Containers] SubSystem.java out of sync with osContainer_linux.cpp - JDK-8220657: JFR.dump does not work when filename is set - JDK-8221340: [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562 - JDK-8221342: [TESTBUG] Generate Dockerfile for docker testing - JDK-8221710: [TESTBUG] more configurable parameters for docker testing - JDK-8223108: Test java/awt/EventQueue/NonComponentSourcePost.java is unstable - JDK-8224502: [TESTBUG] JDK docker test TestSystemMetrics.java fails with access issues and OOM - JDK-8225072: Add LuxTrust certificate that is expiring in March 2021 to list of allowed but expired certs - JDK-8227006: [linux] Runtime.availableProcessors execution time increased by factor of 100 - JDK-8229868: Update Apache Santuario TPRM version - JDK-8231209: [REDO] ThreadMXBean::getThreadAllocatedBytes() can be quicker for self thread - JDK-8231968: getCurrentThreadAllocatedBytes default implementation s/b getThreadAllocatedBytes - JDK-8232114: JVM crashed at imjpapi.dll in native code - JDK-8233548: Update CUP to v0.11b - JDK-8234270: [REDO] JDK-8204128 NMT might report incorrect numbers for Compiler area - JDK-8234339: replace JLI_StrTok in java_md_solinux.c - JDK-8238448: RSASSA-PSS signature verification fail when using certain odd key sizes - JDK-8239105: Add exception for expiring Digicert root certificates to VerifyCACerts test - JDK-8242335: Additional Tests for RSASSA-PSS - JDK-8242480: Negative value may be returned by getFreeSwapSpaceSize() in the docker - JDK-8244225: stringop-overflow warning on strncpy call from compile_the_world_in - JDK-8245400: Upgrade to LittleCMS 2.11 - JDK-8246648: issue with OperatingSystemImpl getFreeSwapSpaceSize in docker after 8242480 - JDK-8248214: Add paddings for TaskQueueSuper to reduce false-sharing cache contention - JDK-8249176: Update GlobalSignR6CA test certificates - JDK-8249846: Change of behavior after JDK-8237117: Better ForkJoinPool behavior - JDK-8250636: iso8601_time returns incorrect offset part on MacOS - JDK-8250665: Wrong translation for the month name of May in ar_JO,LB,SY - JDK-8250928: JFR: Improve hash algorithm for stack traces - JDK-8251365: Build failure on AIX after 8250636 - JDK-8251469: Better cleanup for test/jdk/javax/imageio/SetOutput.java - JDK-8251840: Java_sun_awt_X11_XToolkit_getDefaultScreenData should not be in make/mapfiles/libawt_xawt/mapfile-vers - JDK-8252384: [TESTBUG] Some tests refer to COMPAT provider rather than JRE - JDK-8252395: [8u] --with-native-debug-symbols=external doesn't include debuginfo files for binaries - JDK-8252497: Incorrect numeric currency code for ROL - JDK-8252754: Hash code calculation of JfrStackTrace is inconsistent - JDK-8252904: VM crashes when JFR is used and JFR event class is transformed - JDK-8252975: [8u] JDK-8252395 breaks the build for --with-native-debug-symbols=internal - JDK-8253036: Support building the Zero assembler port on AArch64 - JDK-8253284: Zero OrderAccess barrier mappings are incorrect - JDK-8253550: [8u] JDK-8252395 breaks the build for make STRIP_POLICY=no_strip - JDK-8253752: test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java fails randomly - JDK-8253837: JFR 8u fix symbol and cstring hashtable equals implementaion - JDK-8254081: java/security/cert/PolicyNode/GetPolicyQualifiers.java fails due to an expired certificate - JDK-8254144: Non-x86 Zero builds fail with return-type warning in os_linux_zero.cpp - JDK-8254166: Zero: return-type warning in zeroInterpreter_zero.cpp - JDK-8254177: (tz) Upgrade time-zone data to tzdata2020b - JDK-8254683: [TEST_BUG] jdk/test/sun/tools/jconsole/WorkerDeadlockTest.java fails - JDK-8254982: (tz) Upgrade time-zone data to tzdata2020c - JDK-8255003: Build failures on Solaris - JDK-8255226: (tz) Upgrade time-zone data to tzdata2020d - JDK-8255269: Unsigned overflow in g1Policy.cpp - JDK-8255603: Memory/Performance regression after JDK-8210985 - JDK-8255717: Fix JFR crash in WriteObjectSampleStacktrace due to object not initialized - JDK-8256618: Zero: Linux x86_32 build still fails - JDK-8256671: Incorrect assignment operator used in guarantee() in genCollectedHeap - JDK-8256752: 8252395 incorrect copy rule for macos .dSYM folder - JDK-8257397: [TESTBUG] test/lib/containers/docker/Common.java refers to -Xlog:os+container=trace - JDK-8258630: Add expiry exception for QuoVadis root certificate Notes on individual issues: =========================== core-libs/java.time: JDK-8254177: US/Pacific-New Zone name removed as part of tzdata2020b ==================================================================== Following JDK's update to tzdata2020b, the long-obsolete files pacificnew and systemv have been removed. As a result, the "US/Pacific-New" zone name declared in the pacificnew data file is no longer available for use. Information regarding the update can be viewed at https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html JDK-8259474: JDK time-zone data upgraded to tzdata2020c ======================================================= The JDK update incorporates tzdata2020c. The main change is * Fiji starts DST later than usual, on 2020-12-20. Please refer to https://mm.icann.org/pipermail/tz-announce/2020-October/000060.html for more information. JDK-8259476: JDK time-zone data upgraded to tzdata2020d ======================================================= The JDK update incorporates tzdata2020d. The main change is * Palestine ends DST earlier than predicted, on 2020-10-24. Please refer to https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html for more information. security-libs/javax.xml.crypto: JDK-8230839: Updated XML Signature Implementation to Apache Santuario 2.1.3 =========================================================================== The XML Signature implementation in the `java.xml.crypto` module has been updated to version 2.1.3 of Apache Santuario. New features include: * Added support for embedding elliptic curve public keys in the KeyValue element 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 jhuttana at redhat.com Wed Jan 20 07:37:36 2021 From: jhuttana at redhat.com (Jayashree Huttanagoudar) Date: Wed, 20 Jan 2021 13:07:36 +0530 Subject: OpenJDK 8u282 Released In-Reply-To: <20210120045129.GA1247983@rincewind> References: <20210120045129.GA1247983@rincewind> Message-ID: Hi Team, On Wed, Jan 20, 2021 at 10:24 AM Andrew Hughes wrote: > We are pleased to announce the release of OpenJDK 8u282. > > The source tarball is available from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u282-ga.tar.xz > > The tarball is accompanied by a digital signature available at: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u282-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: > > e5c0000d54fea680375ab06e6d477713fb5c294d84baf0ed6224498bde811b7c > openjdk8u282-ga.tar.xz > 312d9de15c5bf667c17c8dc4b8a582ec929fbc5af227e005b48c15744d512ecf > openjdk8u282-ga.tar.xz.sig > > The checksums can be downloaded from: > > * https://openjdk-sources.osci.io/openjdk8/openjdk8u282-ga.sha256 The binaries to go with this are here: https://adoptopenjdk.net/upstream.html?variant=openjdk8&jvmVariant=hotspot Thanks and 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 gnu.andrew at redhat.com Wed Jan 20 17:01:31 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 Jan 2021 17:01:31 +0000 Subject: [8u] RFR: 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" In-Reply-To: <2d4122c1d9bd59264d311a2a38098974a77b2af9.camel@redhat.com> References: <2d4122c1d9bd59264d311a2a38098974a77b2af9.camel@redhat.com> Message-ID: <20210120170131.GA1302787@rincewind> On 11:57 Mon 11 Jan , Severin Gehwolf wrote: > Hi, > > I'd like to backport this simple fix to OpenJDK 8u as it simplifies the > backport of JDK-8172404 to 8u and the patch at hand is low risk. The > JDK 8u patch is the same as the one for JDK 10, except for one context > difference in keytool/Resources.java. The reason for this is that JDK- > 8191137 got fixed in JDK 10 *after* JDK-8185934 and in JDK 8u it's the > other way around. Other than that, the patch is identical. Please > review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185934 > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185934/jdk8/01/webrev/ > > Thoughts? > > Thanks, > Severin > Looks fine (after moving the jarsigner parts of the patch to the end to compare with the 11u version). Not sure why the webrev is showing three bug IDs. Anyway, please flag for approval. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Thu Jan 21 09:04:21 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Jan 2021 10:04:21 +0100 Subject: [8u] RFR: 8185934: keytool shows "Signature algorithm: SHA1withECDSA, -1-bit key" In-Reply-To: <20210120170131.GA1302787@rincewind> References: <2d4122c1d9bd59264d311a2a38098974a77b2af9.camel@redhat.com> <20210120170131.GA1302787@rincewind> Message-ID: <2dba8e9abeb89bd5531f7ff84529e4d24fd592b1.camel@redhat.com> On Wed, 2021-01-20 at 17:01 +0000, Andrew Hughes wrote: > On 11:57 Mon 11 Jan???? , Severin Gehwolf wrote: > > Hi, > > > > I'd like to backport this simple fix to OpenJDK 8u as it simplifies the > > backport of JDK-8172404 to 8u and the patch at hand is low risk. The > > JDK 8u patch is the same as the one for JDK 10, except for one context > > difference in keytool/Resources.java. The reason for this is that JDK- > > 8191137 got fixed in JDK 10 *after* JDK-8185934 and in JDK 8u it's the > > other way around. Other than that, the patch is identical. Please > > review. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8185934 > > webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8185934/jdk8/01/webrev/ > > > > Thoughts? > > > > Thanks, > > Severin > > > > Looks fine (after moving the jarsigner parts of the patch to the end to compare > with the 11u version). Thanks for the review! > Anyway, please flag for approval. Done now. Thanks, Severin From mbalao at redhat.com Thu Jan 21 14:15:29 2021 From: mbalao at redhat.com (Martin Balao) Date: Thu, 21 Jan 2021 11:15:29 -0300 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 Message-ID: Hi, I'd like to propose an 8u backport of JDK-8202343 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8202343/8202343.webrev.8u.jdk.00/ The 11u patch does not apply cleanly because of the following conflicts: * src/share/conf/security/java.security * In 8u, there is one java.security file per supported operating system. Manually added 'TLSv1' and 'TLSv1.1' to the 'jdk.tls.disabledAlgorithms' property for each file. * test/javax/net/ssl/TLS/TLSClientPropertyTest.java * 8u has JDK-8251478 which introduced a change to this test consistent with the decision of having TLSv1.2 as the default choice for the TLS client. This conflict affects the context only; so I manually added the change. * It's important to notice that HUNK #3 succeeded when applying the patch but the change was not correct and should have been a conflict. Removed "TLSv1" and "TLSv1.1" in the 'NoProperty' case. * test/javax/net/ssl/TLSCommon/interop/JdkProcClient.java * 8u does not have JDK-8243029 which introduces this test file. JDK-8243029 is a massive patch which does not apply cleanly. If JDK-8243029 is backported to 8u, tests using this class will fail until the change in JDK-8202343 (re-enabling TLSv1 and TLSv1.1) is applied. Because of the previous, and the fact that JDK-8243029 is not fundamental to JDK-8202343, I propose to skip the changes on this file at this time. * test/javax/net/ssl/TLSv11/GenericBlockCipher.java * 8u does not have JDK-8166032, which changes the copyright date to 2016 and adds the '@modules' jtreg tag. JDK-8166032 does not apply to 8u, so I manually update the copyright date and the '@library /test/lib' line. See more on '@library /test/lib' below. * test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java * 8u does not have JDK-8234728 which introduces this test file. This case is similar to the JdkProcClient.java one, so I propose the same action now. * test/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java * 8u does not have JDK-8234728 which introduces this test file. This case is similar to the JdkProcClient.java one, so I propose the same action now. * test/sun/security/ssl/CipherSuite/DisabledCurve.java * 8u does not have JDK-8246330 which introduces this test file. JDK-8246330 is not as large as JDK-8243029, but it does not apply cleanly and is not fundamental to JDK-8202343; so I propose the same action now. * test/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java * 8u does not have JDK-8224650 which introduces this test file. JDK-8224650 does not apply to 8u, unless the JDK-8171279 enhancement is backported first. This is not fundamental to JDK-8202343 so I propose this not to be a dependency. * test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java * 8u has JDK-8251478 which removes the '@modules' jtreg tag. The conflict is because of the context. Manually added the new '@library' jtreg tag. See more on '@library' below. * test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java * 8u does not have JDK-8234728 which changes the copyright date to 2019. Manually adjusted the copyright date. * test/sun/security/util/HostnameMatcher/NullHostnameCheck.java * JDK-8228967 is not in 8u so there is a context conflict while adding the import. JDK-8228967 also causes a context conflict when adding the line that re-enables TLS 1.0 and 1.1. However, these changes are not needed in 8u as the test works for TLS 1.2 only (so there is no need to re-enable TLS 1.0 and 1.1). If JDK-8228967 is ever backported to 8u, this test will fail until TLS 1.0 and 1.1 are enabled. * test/lib/security/SecurityUtils.java * For an unknown reason, the 8u backport of 8207258 has copyright date 2019 (instead of 2018, as the original file). This has been this way from the first proposed 8u backport webrev (http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/raw_files/new/test/lib/security/SecurityUtils.java). I've manually update the copyright date to go between 2018 and 2020, so we hopefully avoid a future conflict here. In addition to static file-patching conflicts, I had to make changes for this patch to run in 8u: * test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.java * '@library /test/lib' replaced with '@library /lib/security' * 'import jdk.test.lib.security.SecurityUtils;' removed * OutputAnalyzer and ProcessTools imports changed to 8u's locations * Added /lib to @library for OutputAnalyzer and ProcessTools imports * test/lib/security/SecurityUtils.java * 'List.of' is not available in 8u. Found a replacement. * test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java * test/sun/security/ssl/SSLContextImpl/IllegalProtocolProperty.java * test/sun/security/ssl/SSLContextImpl/SSLContextVersion.java * test/sun/security/ssl/SSLEngineImpl/EmptyExtensionData.java * test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java * test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java * test/javax/net/ssl/TLSv11/GenericBlockCipher.java * test/javax/net/ssl/SSLEngine/Arrays.java * '@library /test/lib' replaced with '@library /lib/security' * 'import jdk.test.lib.security.SecurityUtils;' removed * sun/security/ssl/SSLContextImpl/SSLContextDefault.java * 'List.of' is not available in 8u. Found replacements. No regressions found in sun/security/ssl and javax/net/ssl. Also tested that NullHostnameCheck.java test passes. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8202343 From sgehwolf at redhat.com Thu Jan 21 18:31:18 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 21 Jan 2021 19:31:18 +0100 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: Hi Martin, Thanks for doing this patch and the detailed write-up. Review below. On Thu, 2021-01-21 at 11:15 -0300, Martin Balao wrote: > Hi, > > I'd like to propose an 8u backport of JDK-8202343 [1]. > > Webrev.00: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8202343/8202343.webrev.8u.jdk.00/ > > The 11u patch does not apply cleanly because of the following > conflicts: > > ?* src/share/conf/security/java.security > ? * In 8u, there is one java.security file per supported operating > system. Manually added 'TLSv1' and 'TLSv1.1' to the > 'jdk.tls.disabledAlgorithms' property for each file. OK. > ?* test/javax/net/ssl/TLS/TLSClientPropertyTest.java > ? * 8u has JDK-8251478 which introduced a change to this test consistent > with the decision of having TLSv1.2 as the default choice for the TLS > client. This conflict affects the context only; so I manually added the > change. > ? * It's important to notice that HUNK #3 succeeded when applying the > patch but the change was not correct and should have been a conflict. > Removed "TLSv1" and "TLSv1.1" in the 'NoProperty' case. OK. > ?* test/javax/net/ssl/TLSCommon/interop/JdkProcClient.java > ? * 8u does not have JDK-8243029 which introduces this test file. > JDK-8243029 is a massive patch which does not apply cleanly. If > JDK-8243029 is backported to 8u, tests using this class will fail until > the change in JDK-8202343 (re-enabling TLSv1 and TLSv1.1) is applied. > Because of the previous, and the fact that JDK-8243029 is not > fundamental to JDK-8202343, I propose to skip the changes on this file > at this time. Agreed. > ?* test/javax/net/ssl/TLSv11/GenericBlockCipher.java > ? * 8u does not have JDK-8166032, which changes the copyright date to > 2016 and adds the '@modules' jtreg tag. JDK-8166032 does not apply to > 8u, so I manually update the copyright date and the '@library /test/lib' > line. See more on '@library /test/lib' below. OK. > ?* > test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.ja > va > ? * 8u does not have JDK-8234728 which introduces this test file. This > case is similar to the JdkProcClient.java one, so I propose the same > action now. I tend to disagree. JDK-8234728 seems like a good patch to have for OpenJDK 8u. It verifies proper ciphers are available for certain algorithms. With the TLS 1.3 backport in 8u, it would be good to have associated tests too. Oracle backported it to 8 as well. I'd suggest to first backport JDK-8234728 and rebase this one on top. If you prefer to integrate this one first, I'd urge you to follow up with JDK-8234728 for 8u with relevant hunks from this patch included. Your call. > ?* test/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java > ? * 8u does not have JDK-8234728 which introduces this test file. This > case is similar to the JdkProcClient.java one, so I propose the same > action now. Same comment as for SystemPropCipherSuitesOrder.java. I think we should get it in first. > > ?* test/sun/security/ssl/CipherSuite/DisabledCurve.java > ? * 8u does not have JDK-8246330 which introduces this test file. > JDK-8246330 is not as large as JDK-8243029, but it does not apply > cleanly and is not fundamental to JDK-8202343; so I propose the same > action now. OK to post-pone this one before integrating this patch, but please add a comment to JDK-8246330 that relevant hunks from 8202343 need to get included when it gets backported to JDK 8. > ?* test/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java > ? * 8u does not have JDK-8224650 which introduces this test file. > JDK-8224650 does not apply to 8u, unless the JDK-8171279 enhancement is > backported first. This is not fundamental to JDK-8202343 so I propose > this not to be a dependency. OK. > ?* test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java > ? * 8u has JDK-8251478 which removes the '@modules' jtreg tag. The > conflict is because of the context. Manually added the new '@library' > jtreg tag. See more on '@library' below. OK. > ?* > test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java > ? * 8u does not have JDK-8234728 which changes the copyright date to > 2019. Manually adjusted the copyright date. OK. > ?* test/sun/security/util/HostnameMatcher/NullHostnameCheck.java > ? * JDK-8228967 is not in 8u so there is a context conflict while adding > the import. JDK-8228967 also causes a context conflict when adding the > line that re-enables TLS 1.0 and 1.1. However, these changes are not > needed in 8u as the test works for TLS 1.2 only (so there is no need to > re-enable TLS 1.0 and 1.1). If JDK-8228967 is ever backported to 8u, > this test will fail until TLS 1.0 and 1.1 are enabled. OK. Please add a comment to that effect to JDK-8228967. > ?* test/lib/security/SecurityUtils.java > ? * For an unknown reason, the 8u backport of 8207258 has copyright date > 2019 (instead of 2018, as the original file). This has been this way > from the first proposed 8u backport webrev > ( http://cr.openjdk.java.net/~phh/8207258/webrev.8u.00/raw_files/new/test/lib/security/SecurityUtils.java). > I've manually update the copyright date to go between 2018 and 2020, so > we hopefully avoid a future conflict here. OK. > In addition to static file-patching conflicts, I had to make changes for > this patch to run in 8u: > > ?* test/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.java > ? * '@library /test/lib' replaced with '@library /lib/security' > ? * 'import jdk.test.lib.security.SecurityUtils;' removed > ? * OutputAnalyzer and ProcessTools imports changed to 8u's locations > ? * Added /lib to @library for OutputAnalyzer and ProcessTools > imports OK. > ?* test/lib/security/SecurityUtils.java > ? * 'List.of' is not available in 8u. Found a replacement. OK. > ?* test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java > ?* test/sun/security/ssl/SSLContextImpl/IllegalProtocolProperty.java > ?* test/sun/security/ssl/SSLContextImpl/SSLContextVersion.java > ?* test/sun/security/ssl/SSLEngineImpl/EmptyExtensionData.java > ?* test/sun/security/ssl/SSLEngineImpl/SSLEngineBadBufferArrayAccess.java > ?* test/sun/security/ssl/ClientHandshaker/LengthCheckTest.java > ?* test/javax/net/ssl/TLSv11/GenericBlockCipher.java > ?* test/javax/net/ssl/SSLEngine/Arrays.java > ? * '@library /test/lib' replaced with '@library /lib/security' > ? * 'import jdk.test.lib.security.SecurityUtils;' removed OK. > ?* sun/security/ssl/SSLContextImpl/SSLContextDefault.java > ? * 'List.of' is not available in 8u. Found replacements. 41 public class SSLContextDefault { 42 43 private final static String[] protocols = { 44 "", "SSL", "TLS", "SSLv3", "TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3" 45 }; 46 47 private final static List disabledProtocols; 48 49 static { 50 List protocols = Arrays.asList("SSLv3", "TLSv1", "TLSv1.1"); 51 protocols = Collections.unmodifiableList(protocols); 52 disabledProtocols = protocols; 53 } Local variable 'protocols' shadows static variable 'protocols'. Please use a different name in the static initializer instead. Suggestion: 'disProts' or some such. I wonder if we should just simplify this to and get rid of the static initializer: private final static List disabledProtocols = Collections.unmodifiableList(Arrays.asList("SSLv3", "TLSv1", "TLSv1.1")); Your call. 131 List protocolsList = Arrays.asList(protocols); 132 protocolsList = Collections.unmodifiableList(protocolsList); 133 for (String disabledProtocol : disabledProtocols) { 134 if (!protocolsList.contains(disabledProtocol)) { Same here. Perhaps use: List protocolsList = Collections.unmodifiableList(Arrays.asList(protocols)); Thanks, Severin From qingfeng.yy at alibaba-inc.com Fri Jan 22 06:39:20 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Fri, 22 Jan 2021 14:39:20 +0800 Subject: =?UTF-8?B?UkZSOiA4dSBiYWNrcG9ydCBvZiBKREstODIzNzQ5OSBKRlI6IEluY2x1ZGUgc3RhY2sgdHJh?= =?UTF-8?B?Y2UgaW4gdGhlIFRocmVhZFN0YXJ0IGV2ZW50?= Message-ID: Hi, May I have a request backport of JDK-8237499? JBS: https://bugs.openjdk.java.net/browse/JDK-8237499 Webrev: http://cr.openjdk.java.net/~ddong/yiyang/8237499/ testing: jdk/test/jdk/jfr/ It's useful for users to know where their threads start. This patch doesn't apply cleanly but is fairly trivial. The latest jdk8u-dev has no `Thread::current_or_null` function, just adding this function solves the problem. This patch will cause another problem, e.g., the minimized VM fails to build, this problem has been solved by JDK-8239886, so a follow-up backport of JDK-8239886(one-line change) will be sent later. Cheers, Yang Yi From alexey at azul.com Fri Jan 22 08:40:00 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 22 Jan 2021 08:40:00 +0000 Subject: [8u] RFR: 8238579: HttpsURLConnection drops the timeout and hangs forever in read Message-ID: <3A0F3F57-E7ED-4BEB-8323-ABACBC6D555A@azul.com> Hi, Please review the backport of JDK-8238579 to 8u: Bug: https://bugs.openjdk.java.net/browse/JDK-8238579 Webrev: http://cr.openjdk.java.net/~abakhtin/8238579/webrev.v0/ Original patch applies clean, except for copyright header and source file location. Relevant regression tests are passed. Regards Alexey From sgehwolf at redhat.com Fri Jan 22 09:52:34 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 22 Jan 2021 10:52:34 +0100 Subject: [8u] RFR: 8238579: HttpsURLConnection drops the timeout and hangs forever in read In-Reply-To: <3A0F3F57-E7ED-4BEB-8323-ABACBC6D555A@azul.com> References: <3A0F3F57-E7ED-4BEB-8323-ABACBC6D555A@azul.com> Message-ID: Hi Alexey, On Fri, 2021-01-22 at 08:40 +0000, Alexey Bakhtin wrote: > Hi, Please review the backport of JDK-8238579 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238579 > Webrev: http://cr.openjdk.java.net/~abakhtin/8238579/webrev.v0/ > > Original patch applies clean, except for copyright header and source file location. > Relevant regression tests are passed. Patch looks fine to me. Thanks! I was also able to reproduce the issue with the reproducer in the bug. Proposed patch fixes the issue. I've also approved this patch for 8u292. Thanks, Severin From alexey at azul.com Fri Jan 22 10:48:17 2021 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 22 Jan 2021 10:48:17 +0000 Subject: [8u] RFR: 8238579: HttpsURLConnection drops the timeout and hangs forever in read In-Reply-To: References: <3A0F3F57-E7ED-4BEB-8323-ABACBC6D555A@azul.com> Message-ID: <47ACF165-5343-435D-89E0-0A78392414F2@azul.com> Hi Severin, Thank you for the review. Thanks, Alexey > On 22 Jan 2021, at 12:52, Severin Gehwolf wrote: > > Hi Alexey, > > On Fri, 2021-01-22 at 08:40 +0000, Alexey Bakhtin wrote: >> Hi, Please review the backport of JDK-8238579 to 8u: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8238579 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8238579/webrev.v0/ >> >> Original patch applies clean, except for copyright header and source file location. >> Relevant regression tests are passed. > > Patch looks fine to me. Thanks! > > I was also able to reproduce the issue with the reproducer in the bug. > Proposed patch fixes the issue. I've also approved this patch for > 8u292. > > Thanks, > Severin From mbalao at redhat.com Fri Jan 22 15:40:57 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 Jan 2021 12:40:57 -0300 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: References: Message-ID: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> Hi Severin, Thanks for having a look at this. On 1/21/21 3:31 PM, Severin Gehwolf wrote: >> ?* >> test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.ja >> va >> ? * 8u does not have JDK-8234728 which introduces this test file. This >> case is similar to the JdkProcClient.java one, so I propose the same >> action now. > > I tend to disagree. JDK-8234728 seems like a good patch to have for > OpenJDK 8u. It verifies proper ciphers are available for certain > algorithms. With the TLS 1.3 backport in 8u, it would be good to have > associated tests too. Oracle backported it to 8 as well. I'd suggest to > first backport JDK-8234728 and rebase this one on top. Even when it would be desirable to have JDK-8234728 in 8u, I see it analogous to JDK-8243029 and tend to disagree on the dependencies-enforcement criteria. It's not a fundamental dependency: they conflict accidentally because 8202343 is touching many test files with the only goal of re-enabling TLS 1.0/1.1 for them to keep passing. It's perhaps more clear if we think that 8202343 would have been developed before 8234728 without any issues; and the fact that 8234728 was before is just a coincidence. Even when JDK-8234728 applies cleanly, it fails to pass and it's far from a trivial backport. In fact, my current investigation is suggesting that JDK-8234728 is failing to properly execute HandshakeHashCloneExhaustion with TLS 1.3; and is making it to trivially-pass. TLS 1.3 uses the HKDF class to derive keys, which gets a MessageDigest instance. However, because of JDK-8157579, there is a fallback scheme for non-clonable MessageDigest implementations. As a result, the MessageDigest instance used is not DigestBase$ (from the test BaseDigest.java file) but one from the SUN provider. Looks to me that this is different than in TLS 1.2 or below, where the TlsPrfGenerator class is used to derive keys and we have no fallback-scheme for non-clonable MessageDigests. I've still not verified this last statement, though. Verifying this last statement would confirm HandshakeHashCloneExhaustion author's intention of using DigestBase$ instead of any other MessageDigest implementation. Note: 8u does not have the JDK-8157579 fallback-scheme and is exposing the bug. My point is that we now need to shift focus to investigate 8234728 in jdk/jdk, fix it (eventually), create backports for it, backport 8157579 perhaps, and then continue with the backport of 8234728 -which has a followup for another test, and I'm not sure it does not cause conflicts or leads to a whole new chain of dependencies-. I agree in that would be ideal to have all these tests and fixes, or even to backport dependencies when they are non-fundamental but trivial. But my concern is that a low-priority test may now be blocking an important backport. Thanks, Martin.- From sgehwolf at redhat.com Fri Jan 22 16:10:11 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 22 Jan 2021 17:10:11 +0100 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> References: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> Message-ID: <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> Hi Martin, On Fri, 2021-01-22 at 12:40 -0300, Martin Balao wrote: > Hi Severin, > > Thanks for having a look at this. > > On 1/21/21 3:31 PM, Severin Gehwolf wrote: > > > ?* > > > test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.ja > > > va > > > ? * 8u does not have JDK-8234728 which introduces this test file. This > > > case is similar to the JdkProcClient.java one, so I propose the same > > > action now. > > > > I tend to disagree. JDK-8234728 seems like a good patch to have for > > OpenJDK 8u. It verifies proper ciphers are available for certain > > algorithms. With the TLS 1.3 backport in 8u, it would be good to have > > associated tests too. Oracle backported it to 8 as well. I'd suggest to > > first backport JDK-8234728 and rebase this one on top. > > Even when it would be desirable to have JDK-8234728 in 8u, I see it > analogous to JDK-8243029 and tend to disagree on the > dependencies-enforcement criteria. It's not a fundamental dependency: > they conflict accidentally because 8202343 is touching many test files > with the only goal of re-enabling TLS 1.0/1.1 for them to keep passing. > It's perhaps more clear if we think that 8202343 would have been > developed before 8234728 without any issues; and the fact that 8234728 > was before is just a coincidence. > > Even when JDK-8234728 applies cleanly, it fails to pass and it's far > from a trivial backport. In fact, my current investigation is suggesting > that JDK-8234728 is failing to properly execute > HandshakeHashCloneExhaustion with TLS 1.3; and is making it to > trivially-pass. TLS 1.3 uses the HKDF class to derive keys, which gets a > MessageDigest instance. However, because of JDK-8157579, there is a > fallback scheme for non-clonable MessageDigest implementations. As a > result, the MessageDigest instance used is not DigestBase$ (from > the test BaseDigest.java file) but one from the SUN provider. Looks to > me that this is different than in TLS 1.2 or below, where the > TlsPrfGenerator class is used to derive keys and we have no > fallback-scheme for non-clonable MessageDigests. I've still not verified > this last statement, though. Verifying this last statement would confirm > HandshakeHashCloneExhaustion author's intention of using > DigestBase$ instead of any other MessageDigest implementation. > Note: 8u does not have the JDK-8157579 fallback-scheme and is exposing > the bug. > > My point is that we now need to shift focus to investigate 8234728 in > jdk/jdk, fix it (eventually), create backports for it, backport 8157579 > perhaps, and then continue with the backport of 8234728 -which has a > followup for another test, and I'm not sure it does not cause conflicts > or leads to a whole new chain of dependencies-. > > I agree in that would be ideal to have all these tests and fixes, or > even to backport dependencies when they are non-fundamental but trivial. > But my concern is that a low-priority test may now be blocking an > important backport. The basis of my suggestion to pull in that dep first was that the backport of JDK-8234728 would be reasonable straight-forward. It sounds like it isn't. Given the aforementioned, that it's a hunk to test-only files missing and on the grounds that this patch only adds a hunk to re-enable old TLS like this: + // Re-enable protocol if disabled. + if (protocol.equals("TLSv1") || protocol.equals("TLSv1.1")) { + SecurityUtils.removeFromDisabledTlsAlgs(protocol); + } it should be reasonable to omit those and get 8202343 in. Please add a comment on JDK-8234728 to that effect. This would ensure that those hunks will get added should JDK-8234728 get backported later. To me this isn't the same ballpark as JDK-8243029 since A) for JDK- 8243029, JDK 11's version of the framework can be used to test JDK 8 compatibility this isn't the case for JDK-8234728 B) JDK-8234728 checks correctness of some TLS 1.3 aspects not otherwise covered. YMMV. Either way, please proceed with the backport of this with hunks to test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java test/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java omitted and adding a comment on JDK-8234728. Thanks, Severin From vyommani at gmail.com Fri Jan 22 17:41:43 2021 From: vyommani at gmail.com (Vyom Tiwari) Date: Fri, 22 Jan 2021 23:11:43 +0530 Subject: [8u] RFR: 8238579: HttpsURLConnection drops the timeout and hangs forever in read In-Reply-To: <3A0F3F57-E7ED-4BEB-8323-ABACBC6D555A@azul.com> References: <3A0F3F57-E7ED-4BEB-8323-ABACBC6D555A@azul.com> Message-ID: looks ok to me as well. Vyom On Fri, Jan 22, 2021 at 2:10 PM Alexey Bakhtin wrote: > Hi, Please review the backport of JDK-8238579 to 8u: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8238579 > Webrev: http://cr.openjdk.java.net/~abakhtin/8238579/webrev.v0/ > > Original patch applies clean, except for copyright header and source file > location. > Relevant regression tests are passed. > > Regards > Alexey > -- Thanks, Vyom From mbalao at redhat.com Fri Jan 22 19:20:30 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 Jan 2021 16:20:30 -0300 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> References: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> Message-ID: <17a48411-19a0-2f4c-3b33-169b1e6d805c@redhat.com> Hello, On 1/22/21 12:40 PM, Martin Balao wrote: > Even when JDK-8234728 applies cleanly, it fails to pass and it's far > from a trivial backport. In fact, my current investigation is suggesting > that JDK-8234728 is failing to properly execute > HandshakeHashCloneExhaustion with TLS 1.3; and is making it to > trivially-pass. TLS 1.3 uses the HKDF class to derive keys, which gets a > MessageDigest instance. However, because of JDK-8157579, there is a > fallback scheme for non-clonable MessageDigest implementations. As a > result, the MessageDigest instance used is not DigestBase$ (from > the test BaseDigest.java file) but one from the SUN provider. Looks to > me that this is different than in TLS 1.2 or below, where the > TlsPrfGenerator class is used to derive keys and we have no > fallback-scheme for non-clonable MessageDigests. I've still not verified > this last statement, though. Verifying this last statement would confirm > HandshakeHashCloneExhaustion author's intention of using > DigestBase$ instead of any other MessageDigest implementation. > Note: 8u does not have the JDK-8157579 fallback-scheme and is exposing > the bug. I've further investigated these initial findings/assumptions and have a more conclusive idea of the problem. JDK-8234728 [1] is intended to make some tests work with TLS 1.3. There is HandshakeHashCloneExhaustion among them. In TLS 1.3, a HKDF instance is created for key derivation. This instance has a HMAC object inside, which is an instance of the HmacCore class. When a HmacCore instance is constructed, a MessageDigest instance is obtained [2]. The instance obtained is a non-clonable one, from the test's BaseDigest class [3]. However, there is a fallback scheme for non-clonable MessageDigest instances introduced by JDK-8157579 [4] that changes the previous instance to one from the SUN security provider (i.e.: sun.security.provider.SHA2$SHA256 class). For the handshake hash, the right test's DigestBase class is used (the fallback scheme is only in HmacCore class). In TLS 1.2, key derivation is done with the TlsPrfGenerator class. The MessageDigest instance used for key derivation is from the test's BaseDigest class [5]. The previous two findings made me think there could be a problem. Further looking at what HandshakeHashCloneExhaustion is testing, the use of a clonable MessageDigest instance for HKDF key derivation (instead of the test's BaseDigest one) does not make the test to trivially-pass: there are still several uses of the non-clonable instance which require the code to properly handle it. I've verified with the debugger how during the recording of the HandshakeHash, CertificateVerify::T13CertificateVerifyMessage requires an instance of a MessageDigest and the same one being used for the handshake is returned (that is: DigestBase$SHA256). So if the HandshakeHash does not handle this well, the MessageDigest state would be corrupted by the CertificateVerify use -at least-. In 8u (contrary to newer releases which have JDK-8157579) TLS 1.3 HKDF will use the same test DigestBase$SHA256 instance. To backport JDK-8234728 to 8u, we need to implement the engineGetMacLength API through proper delegation (so we don't get a default length of 0 and fail later while deriving keys). In conclusion, there is nothing to fix in jdk/jdk -implementing engineGetMacLength there would be dead code, technically- but we would need to make adjustments when backporting 8234728 to 8u. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8234728 [2] - https://github.com/openjdk/jdk/blob/49f9e577156986825a1ab6c627573956ba712beb/src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java#L68 [3] - https://github.com/openjdk/jdk/blob/14c85c2934b422efb9560f25a43a4f3b9c9bbd6a/test/jdk/sun/security/ssl/HandshakeHash/DigestBase.java#L26 [4] - https://github.com/openjdk/jdk/blob/49f9e577156986825a1ab6c627573956ba712beb/src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java#L69 [5] - https://github.com/openjdk/jdk/blob/8e859259bc46c65c5310801899b48e3df0a92989/src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java#L178 From mbalao at redhat.com Fri Jan 22 19:27:30 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 Jan 2021 16:27:30 -0300 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> References: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> Message-ID: <0de2eb0a-b604-97db-5d49-370707b8817c@redhat.com> Hi Severin, I appreciate your thoughts. On 1/22/21 1:10 PM, Severin Gehwolf wrote: > The basis of my suggestion to pull in that dep first was that the > backport of JDK-8234728 would be reasonable straight-forward. It sounds > like it isn't. Given the aforementioned, that it's a hunk to test-only > files missing and on the grounds that this patch only adds a hunk to > re-enable old TLS like this: > > + // Re-enable protocol if disabled. > + if (protocol.equals("TLSv1") || protocol.equals("TLSv1.1")) { > + SecurityUtils.removeFromDisabledTlsAlgs(protocol); > + } > > it should be reasonable to omit those and get 8202343 in. Please add a > comment on JDK-8234728 to that effect. This would ensure that those > hunks will get added should JDK-8234728 get backported later. > Yes, we are on the same page here. Before arguing against a dependency I usually try to apply the patch and run the tests: if it's low-hanging fruit and low risk, I go with it. Otherwise, I look at whether it's fundamental or not. I should have been more explicit about that in my first comment. Anyways, now that the time for backporting 8234728 to 8u has been invested (and the knowledge is fresh), I'll go with it. Regards, Martin.- From mbalao at redhat.com Fri Jan 22 20:06:56 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 Jan 2021 17:06:56 -0300 Subject: [8u] RFR 8234728: Some security tests should support TLSv1.3 Message-ID: Hi, I'd like to request a review for the 8u backport of JDK-8234728 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8234728/8234728.webrev.8u.jdk.00/ 11u patch applies cleanly but the following changes were needed for tests to work in 8u: * test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java * test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java * The 8u backport of SunJSSE does not currently enable TLSv1.3 on the client by default. Enable it for the tests (as done with multiple other TLSv1.3 tests backported to 8u before). * test/sun/security/ssl/HandshakeHash/DigestBase.java * See an explanation of this change here [2]. No regressions found in tests affected by this patch. Risk for this patch is low as only tests are affected. Note: test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java introduced by this patch raises an error because it has the '@ignore' label. This label is removed by a followup patch that I intend to backport to 8u. See JDK-8235874 [3]. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8234728 [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013350.html [3] - https://bugs.openjdk.java.net/browse/JDK-8235874 From mbalao at redhat.com Fri Jan 22 20:11:11 2021 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 Jan 2021 17:11:11 -0300 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <0de2eb0a-b604-97db-5d49-370707b8817c@redhat.com> References: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> <0de2eb0a-b604-97db-5d49-370707b8817c@redhat.com> Message-ID: <89b8d207-4aae-d1f9-868f-f871c9968315@redhat.com> On 1/22/21 4:27 PM, Martin Balao wrote: > > Anyways, now that the time for backporting 8234728 to 8u has been > invested (and the knowledge is fresh), I'll go with it. > Followup of the 8u backport of JDK-8234728 here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013352.html From gnu.andrew at redhat.com Mon Jan 25 17:17:57 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Jan 2021 17:17:57 +0000 Subject: [8u] RFR 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: <20210125171757.GB1819091@rincewind> On 17:06 Fri 22 Jan , Martin Balao wrote: > Hi, > > I'd like to request a review for the 8u backport of JDK-8234728 [1]. > > Webrev.00: > > * > http://cr.openjdk.java.net/~mbalao/webrevs/8234728/8234728.webrev.8u.jdk.00/ > > 11u patch applies cleanly but the following changes were needed for > tests to work in 8u: > > * test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java > * test/sun/security/ssl/HandshakeHash/HandshakeHashCloneExhaustion.java > * The 8u backport of SunJSSE does not currently enable TLSv1.3 on the > client by default. Enable it for the tests (as done with multiple other > TLSv1.3 tests backported to 8u before). > > * test/sun/security/ssl/HandshakeHash/DigestBase.java > * See an explanation of this change here [2]. > > No regressions found in tests affected by this patch. Risk for this > patch is low as only tests are affected. > > Note: > test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java > introduced by this patch raises an error because it has the '@ignore' > label. This label is removed by a followup patch that I intend to > backport to 8u. See JDK-8235874 [3]. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8234728 > [2] - > https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013350.html > [3] - https://bugs.openjdk.java.net/browse/JDK-8235874 > Looks good to me. Thanks for the detailed explanation. Please flag for approval. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon Jan 25 19:43:37 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 Jan 2021 19:43:37 +0000 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> <20201127192303.GA793596@rincewind> Message-ID: <20210125194337.GC1819091@rincewind> On 14:45 Mon 30 Nov , Aleksey Shipilev wrote: > Hi, > > Thanks for explanations. These are the only things left from my review: > > On 11/27/20 8:23 PM, Andrew Hughes wrote: > > > *) src/share/vm/adlc/formssel.cpp: > > > - equivalent_predicates addition changes the shared code path. Is this a bugfix? > > > > > > > 8145438: Guarantee failures since 8144028: Use AArch64 bit-test instructions in C2 > > > > Made AARCH64_ONLY. > > You can write this: > > 1246 _matrule->equivalent(AD.globalNames(), short_branch->_matrule) && > 1247 AARCH64_ONLY(equivalent_predicates(this, short_branch)) NOT_AARCH64(true)) { > > as: > > 1246 _matrule->equivalent(AD.globalNames(), short_branch->_matrule) > 1247 AARCH64_ONLY(&& equivalent_predicates(this, short_branch))) { > > I was in two minds between this and wanting to keep the symmetry of the '&&' on the line above. Neither is perfect, but I've switched to this one now. > > > *) src/share/vm/c1/c1_Runtime1.hpp > > > - so, "move_klass_patching" is undefined for AARCH64 (see .cpp change), should it be undeclared too? > > > > It's in src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp > > Yes, but under TARGET_ARCH_aarch64, *_patching and friends remains _only_ > declared, not defined. Shouldn't the entire *_patching declaration block be > e.g. this? > > #ifdef TARGET_ARCH_aarch64 > static void patch_code_aarch64(JavaThread* thread, StubID stub_id); > #else > static int access_field_patching(JavaThread* thread); > static int move_klass_patching(JavaThread* thread); > static int move_mirror_patching(JavaThread* thread); > static int move_appendix_patching(JavaThread* thread); > static void patch_code(JavaThread* thread, StubID stub_id); > #endif > Still not sure what you're aiming at here. The routines are defined in c1_Runtime1_aarch64.cpp. If they were not defined anywhere, surely the build would fail? Given how well tested the current version is, I'd prefer to leave it as is in the current patch, so as to not to deviate too far in the initial import or delay this any further. You're welcome to change this in a follow-up patch. > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.02/ > > I have only a philosophical point left: if we push this to 8u282, this means > we start the clock on getting any remaining issues resolved in December > before the January release. Since December is the time when a significant > part of involved people take vacations, I think we are risking this quite a > bit. While not exactly the concern of OpenJDK 8u Upstream, it would also > mean we would need to merge this back to aarch64-port/jdk8u-shenandoah, and > make sure that Shenandoah itself is not broken. > > It would make me sleep and relax better if we integrate it first thing in > 8u292 (for April CPU), so that we would have plenty of time next year to > work out the kinks, if any. This is ultimately something for 8u Maintainers > to decide, of course. > I think breakage is unlikely - and that's why I'm trying to minimise differences from what's already in aarch64/shenandoah-jdk8u where possible - but we're now aiming for 8u292. https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.03/ has the first change listed above and also JDK-8221725, following the inclusion of JDK-8221408 in 8u292. Differences look like this: $ diff -u ../../webrevs/openjdk8/8257192/hotspot/webrev.02/hotspot.patch ../../webrevs/openjdk8/8257192/hotspot/webrev.03/hotspot.aarch64.patch |egrep '^[+-][+-] ' -+ _matrule->equivalent(AD.globalNames(), short_branch->_matrule) && -+ AARCH64_ONLY(equivalent_predicates(this, short_branch)) NOT_AARCH64(true)) { ++ _matrule->equivalent(AD.globalNames(), short_branch->_matrule) ++ AARCH64_ONLY(&& equivalent_predicates(this, short_branch))) { -+ __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place)); ++ __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place)); Doing a test build with this now across all architectures. Let's finally get this in. > -- > Thanks, > -Aleksey > 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 qingfeng.yy at alibaba-inc.com Tue Jan 26 02:17:09 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Tue, 26 Jan 2021 10:17:09 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogOHUgYmFja3BvcnQgb2YgSkRLLTgyMzc0OTkgSkZSOiBJbmNsdWRlIHN0YWNr?= =?UTF-8?B?IHRyYWNlIGluIHRoZSBUaHJlYWRTdGFydCBldmVudA==?= In-Reply-To: References: Message-ID: <29c73d97-a723-411c-b8f0-af11ebc8139c.qingfeng.yy@alibaba-inc.com> As mentioned[1] before, the minimized VM fails to build after 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/ ---- [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 ------------------Original Mail ------------------ Sender:Yang Yi Send Date:Fri Jan 22 14:39:20 2021 Recipients:jdk8u-dev at openjdk.java.net Subject:RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event Hi, May I have a request backport of JDK-8237499? JBS: https://bugs.openjdk.java.net/browse/JDK-8237499 Webrev: http://cr.openjdk.java.net/~ddong/yiyang/8237499/ testing: jdk/test/jdk/jfr/ It's useful for users to know where their threads start. This patch doesn't apply cleanly but is fairly trivial. The latest jdk8u-dev has no `Thread::current_or_null` function, just adding this function solves the problem. This patch will cause another problem, e.g., the minimized VM fails to build, this problem has been solved by JDK-8239886, so a follow-up backport of JDK-8239886(one-line change) will be sent later. Cheers, Yang Yi From sgehwolf at redhat.com Tue Jan 26 09:28:50 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Jan 2021 10:28:50 +0100 Subject: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event In-Reply-To: <29c73d97-a723-411c-b8f0-af11ebc8139c.qingfeng.yy@alibaba-inc.com> References: <29c73d97-a723-411c-b8f0-af11ebc8139c.qingfeng.yy@alibaba-inc.com> Message-ID: <2c5de9462213a8b473d9a9170c688b8212b4a7a8.camel@redhat.com> On Tue, 2021-01-26 at 10:17 +0800, Yang Yi wrote: > As mentioned[1] before, the minimized VM fails to build > after 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/ Please create a separate review thread for this and adjust the subject accordingly. It's a different bug (though, related). Thanks, Severin From qingfeng.yy at alibaba-inc.com Tue Jan 26 12:06:08 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Tue, 26 Jan 2021 20:06:08 +0800 Subject: =?UTF-8?B?UkZSOiA4dSBiYWNrcG9ydCBvZiBKREstODIzOTg4NiBNaW5pbWFsIFZNIGJ1aWxkIGZhaWxz?= =?UTF-8?B?IGFmdGVyIEpESy04MjM3NDk5?= Message-ID: 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 qingfeng.yy at alibaba-inc.com Tue Jan 26 12:10:46 2021 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Tue, 26 Jan 2021 20:10:46 +0800 Subject: =?UTF-8?B?UmU6IFJGUjogOHUgYmFja3BvcnQgb2YgSkRLLTgyMzc0OTkgSkZSOiBJbmNsdWRlIHN0YWNr?= =?UTF-8?B?IHRyYWNlIGluIHRoZSBUaHJlYWRTdGFydCBldmVudA==?= In-Reply-To: <2c5de9462213a8b473d9a9170c688b8212b4a7a8.camel@redhat.com> References: <29c73d97-a723-411c-b8f0-af11ebc8139c.qingfeng.yy@alibaba-inc.com>, <2c5de9462213a8b473d9a9170c688b8212b4a7a8.camel@redhat.com> Message-ID: <66dcf549-e1cf-4a03-9d6c-b290d51d556d.qingfeng.yy@alibaba-inc.com> Hi Severin, I've created a new separate review thread[1]. Can you help review these two backports? Thanks, Yang Yi ---- [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-January/013358.html ------------------------------------------------------------------ From:Severin Gehwolf Send Time:2021 Jan. 26 (Tue.) 17:29 To:"YANG, Yi" ; jdk8u-dev at openjdk.java.net Subject:Re: RFR: 8u backport of JDK-8237499 JFR: Include stack trace in the ThreadStart event On Tue, 2021-01-26 at 10:17 +0800, Yang Yi wrote: > As mentioned[1] before, the minimized VM fails to build > after 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/ Please create a separate review thread for this and adjust the subject accordingly. It's a different bug (though, related). Thanks, Severin From mbalao at redhat.com Tue Jan 26 18:46:39 2021 From: mbalao at redhat.com (Martin Balao) Date: Tue, 26 Jan 2021 15:46:39 -0300 Subject: =?UTF-8?Q?=5b8u=5d_RFR_8235874=3a_The_ordering_of_Cipher_Suites_is_?= =?UTF-8?Q?not_maintained_provided_through_=e2=80=9cjdk=2etls=2eclient=2ecip?= =?UTF-8?B?aGVyU3VpdGVz4oCdIGFuZCDigJxqZGsudGxzLnNlcnZlci5jaXBoZXJTdWl0ZXM=?= =?UTF-8?Q?=e2=80=9d_system_property=2e?= Message-ID: Hi, I'd like to propose an 8u backport of JDK-8235874 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8235874/8235874.webrev.8u.jdk.00 Changes to the 11u patch: * File paths to the pre-modules scheme * javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java * Removed TLS_CHACHA20_POLY1305_SHA256 ciphersuite from the test as "JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms" [2] is not in 8u. Testing: no regressions observed in javax/net/ssl. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8235874 [2] - https://bugs.openjdk.java.net/browse/JDK-8153028 From sgehwolf at redhat.com Tue Jan 26 19:19:11 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 26 Jan 2021 20:19:11 +0100 Subject: [8u] RFR 8235874: The ordering of Cipher Suites is not maintained provided through =?UTF-8?Q?=E2=80=9Cjdk=2Etls=2Eclient=2EcipherSuites=E2=80=9D?= and =?UTF-8?Q?=E2=80=9Cjdk=2Etls=2Eserver=2EcipherSuites=E2=80=9D?= system property. In-Reply-To: References: Message-ID: <1a6c1ce0b80af0f9143f5e857d77c17637d2b51b.camel@redhat.com> Hi Martin, On Tue, 2021-01-26 at 15:46 -0300, Martin Balao wrote: > Hi, > > I'd like to propose an 8u backport of JDK-8235874 [1]. > > Webrev.00: > > ?* > > http://cr.openjdk.java.net/~mbalao/webrevs/8235874/8235874.webrev.8u.jdk.00 This looks fine. Thanks, Severin From mbalao at redhat.com Wed Jan 27 13:08:11 2021 From: mbalao at redhat.com (Martin Balao) Date: Wed, 27 Jan 2021 10:08:11 -0300 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> References: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> Message-ID: <9523688f-db0b-1361-cb5e-c4753af006e6@redhat.com> Hi Severin, I'd like to propose Webrev.01: * http://cr.openjdk.java.net/~mbalao/webrevs/8202343/8202343.webrev.8u.jdk.01 Differences between webrevs 00 and 01: * test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java * test/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java * Changes added, after backporting JDK-8234728 to 8u * Applied '@library /lib/security' change and removed 'import jdk.test.lib.security.SecurityUtils;' as with other tests * test/sun/security/ssl/SSLContextImpl/SSLContextDefault.java * Applied suggested changes to the List variables No regressions observed in 'sun/security/ssl' and 'javax/net/ssl' test categories. Additionally, I added 8u backport notes to JDK-8246330 [1] and JDK-8228967 [2]. Are we good to request an 8u maintainers approval? Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8246330 [2] - https://bugs.openjdk.java.net/browse/JDK-8228967 From sgehwolf at redhat.com Wed Jan 27 13:20:00 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 27 Jan 2021 14:20:00 +0100 Subject: [8u] RFR 8202343: Disable TLS 1.0 and 1.1 In-Reply-To: <9523688f-db0b-1361-cb5e-c4753af006e6@redhat.com> References: <9ec57b8e-0a97-c605-0f87-19a8bfb3d0f6@redhat.com> <7f4b392df72bf2985246dd5b60d07a8b6d9543c5.camel@redhat.com> <9523688f-db0b-1361-cb5e-c4753af006e6@redhat.com> Message-ID: <3875c5fe77167a7271916e24c2abbdd323873a40.camel@redhat.com> Hi Martin, On Wed, 2021-01-27 at 10:08 -0300, Martin Balao wrote: > Hi Severin, > > I'd like to propose Webrev.01: > > ?* > http://cr.openjdk.java.net/~mbalao/webrevs/8202343/8202343.webrev.8u.jdk.01 This looks good. > Differences between webrevs 00 and 01: > > ?* test/javax/net/ssl/sanity/ciphersuites/SystemPropCipherSuitesOrder.java > ?* test/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java > ? * Changes added, after backporting JDK-8234728 to 8u > ? * Applied '@library /lib/security' change and removed 'import > jdk.test.lib.security.SecurityUtils;' as with other tests Thanks for doing them! > ?* test/sun/security/ssl/SSLContextImpl/SSLContextDefault.java > ? * Applied suggested changes to the List variables > > No regressions observed in 'sun/security/ssl' and 'javax/net/ssl' test > categories. > > Additionally, I added 8u backport notes to JDK-8246330 [1] and > JDK-8228967 [2]. Great, thank you! > Are we good to request an 8u maintainers approval? Yes. Thanks, Severin > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8246330 > [2] - https://bugs.openjdk.java.net/browse/JDK-8228967 > > From shade at redhat.com Wed Jan 27 16:15:30 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 27 Jan 2021 17:15:30 +0100 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: <20210125194337.GC1819091@rincewind> References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> <20201127192303.GA793596@rincewind> <20210125194337.GC1819091@rincewind> Message-ID: On 1/25/21 8:43 PM, Andrew Hughes wrote: >>>> *) src/share/vm/c1/c1_Runtime1.hpp >>>> - so, "move_klass_patching" is undefined for AARCH64 (see .cpp change), should it be undeclared too? >>> >>> It's in src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp >> >> Yes, but under TARGET_ARCH_aarch64, *_patching and friends remains _only_ >> declared, not defined. Shouldn't the entire *_patching declaration block be >> e.g. this? >> >> #ifdef TARGET_ARCH_aarch64 >> static void patch_code_aarch64(JavaThread* thread, StubID stub_id); >> #else >> static int access_field_patching(JavaThread* thread); >> static int move_klass_patching(JavaThread* thread); >> static int move_mirror_patching(JavaThread* thread); >> static int move_appendix_patching(JavaThread* thread); >> static void patch_code(JavaThread* thread, StubID stub_id); >> #endif > > Still not sure what you're aiming at here. The routines are defined in > c1_Runtime1_aarch64.cpp. If they were not defined anywhere, surely > the build would fail? Given how well tested the current version is, > I'd prefer to leave it as is in the current patch, so as to not to > deviate too far in the initial import or delay this any > further. You're welcome to change this in a follow-up patch. Yeah, it is not a build breakage to define the method and not implement it, as long as nobody tries to reference the method. When that happens, linker would complain. But I agree about leaving it as is for integration sanity. > I think breakage is unlikely - and that's why I'm trying to minimise differences > from what's already in aarch64/shenandoah-jdk8u where possible - but we're now > aiming for 8u292. > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.03/ > > has the first change listed above and also JDK-8221725, following the inclusion > of JDK-8221408 in 8u292. > > Differences look like this: > > $ diff -u ../../webrevs/openjdk8/8257192/hotspot/webrev.02/hotspot.patch ../../webrevs/openjdk8/8257192/hotspot/webrev.03/hotspot.aarch64.patch |egrep '^[+-][+-] ' > -+ _matrule->equivalent(AD.globalNames(), short_branch->_matrule) && > -+ AARCH64_ONLY(equivalent_predicates(this, short_branch)) NOT_AARCH64(true)) { > ++ _matrule->equivalent(AD.globalNames(), short_branch->_matrule) > ++ AARCH64_ONLY(&& equivalent_predicates(this, short_branch))) { > -+ __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place)); > ++ __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place)); > > Doing a test build with this now across all architectures. Let's finally get this in. Okay, this looks good to me. We are (hopefully) done! -- Thanks, -Aleksey From mbalao at redhat.com Wed Jan 27 19:38:48 2021 From: mbalao at redhat.com (Martin Balao) Date: Wed, 27 Jan 2021 16:38:48 -0300 Subject: [8u] RFR 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures Message-ID: <47d919b2-6b6d-614d-a69b-914109cdc09c@redhat.com> Hi, I'd like to propose an 8u backport of JDK-8258833 [1]. Webrev.00: * http://cr.openjdk.java.net/~mbalao/webrevs/8258833/8258833.webrev.8u.jdk.00 The 11u patch does not apply cleanly because of the following conflicts: * src/share/classes/sun/security/pkcs11/P11Signature.java * JDK-8149802 was not backported to 8u, so the context for one of the hunks is different. In particular, "pe" was expected to be the PKCS11Exception exception variable name -in 8u the name is "e"-, and a catch "SignatureException | ProviderException e" line was expected after. None of this affects the 8u backport of 8258833; which, in the aforementioned hunk, adds documentation only. Backporting 8149802 to 8u would require further analysis; as the fix is quite old now and many changes have been applied on top of it. For example, the most-updated jdk/jdk code just re-throws the SignatureException and ProviderException exceptions. In other words, the cancelOperation call introduced by 8149802 was removed and it's a no-operation now. Please notice that both jdk/jdk and 8u do a cancel call from the 'finally' block (which did not exist by the time 8149802 was developed). As a result, my suggestion here would be not to block the 8u backport of 8258833 enforcing a dependency on 8149802. The conflict has been trivially fixed rebasing the hunk context to 8u. * test/sun/security/pkcs11/Cipher/CancelMultipart.java * '@modules jdk.crypto.cryptoki/sun.security.pkcs11:open' does not apply to 8u * '/test/lib' library path replaced with '/lib/security' * File paths converted to the pre-modules scheme. Testing: no regressions observed in the sun/security/pkcs11 category. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8258833 From sgehwolf at redhat.com Thu Jan 28 10:05:06 2021 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 Jan 2021 11:05:06 +0100 Subject: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase In-Reply-To: <26ea45a4-bf19-6a5e-c885-5b628e6aebfd@oracle.com> References: <26ea45a4-bf19-6a5e-c885-5b628e6aebfd@oracle.com> Message-ID: <4e6a3167c955d66ef732e46c7fcda51566d19359.camel@redhat.com> Hi, On Thu, 2021-01-28 at 14:37 +1000, David Holmes wrote: > Hi, > > On 28/01/2021 10:51 am, Nhat Nguyen wrote: > > Hi, > > > > I'm writing this email to follow up on JDK-7018422 [1] on jdk8u, where the JavaAgent code > > is always interpreted during the initialization phase on jdk8. > > Just FYI for changes to 8u you need to raise the issue on > jdk8u-dev at openjdk.java.net. Adding jdk8u-dev to cc. > > > For background, one of our tools is currently making use of a JavaAgent whose performance > > is important. As part of a performance investigation, I discovered that the CompilerBroker is > > not initialized by the time the premain method runs, therefore all compilation requests for > > the JavaAgent are discarded. > > > > Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing. > > However, the ticket was closed as "Not an issue" because the initialization order is changed > > with the introduction of the module system. > > > > So I would like to ask the mailing list for opinions on whether a fix for this issue can be > > considered for jdk8u. I have also attached a prototype fix [2] and would appreciate any > > suggestions and comments as well. > > You have to be extremely careful changing the initialization order as > there are many hidden inter-dependencies. Yes, and we've been bitten by this before[i]. There is a significant risk involved changing initialization order in stable jdk8u. The reasons given here don't strike me as a good enough reason to accept such a patch. YMMV. Andrew Haley, thoughts? Thanks, Severin [i] https://bugs.openjdk.java.net/browse/JDK-8249158 and https://bugs.openjdk.java.net/browse/JDK-8233197 > And as Serguei stated, that change may potentially allow JIT'ing to be > possible, but that doesn't mean it will actually occur. > > Cheers, > David > ----- > > > > > [1]: https://bugs.openjdk.java.net/browse/JDK-7018422 > > [2]: > > > > --- > > ? hotspot/src/share/vm/runtime/thread.cpp | 10 +++++----- > > ? 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/hotspot/src/share/vm/runtime/thread.cpp > > b/hotspot/src/share/vm/runtime/thread.cpp > > index 330593acb3..3918f989cc 100644 > > --- a/hotspot/src/share/vm/runtime/thread.cpp > > +++ b/hotspot/src/share/vm/runtime/thread.cpp > > @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs* > > args, bool* canTryAgain) { > > ????? create_vm_init_libraries(); > > ??? } > > ? > > -? // Notify JVMTI agents that VM initialization is complete - nop > > if no agents. > > -? JvmtiExport::post_vm_initialized(); > > - > > -? JFR_ONLY(Jfr::on_vm_start();) > > - > > ??? if (CleanChunkPoolAsync) { > > ????? Chunk::start_chunk_pool_cleaner_task(); > > ??? } > > @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs* > > args, bool* canTryAgain) { > > ??? CompileBroker::compilation_init(); > > ? #endif > > ? > > +? // Notify JVMTI agents that VM initialization is complete - nop > > if no agents. > > +? JvmtiExport::post_vm_initialized(); > > + > > +? JFR_ONLY(Jfr::on_vm_start();) > > + > > ??? if (EnableInvokeDynamic) { > > ????? // Pre-initialize some JSR292 core classes to avoid deadlock > > during class loading. > > ????? // It is done after compilers are initialized, because > > otherwise compilations of > > -- > > > From gnu.andrew at redhat.com Fri Jan 29 17:23:42 2021 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 Jan 2021 17:23:42 +0000 Subject: [8u] RFR: JDK-8257192: Integrate AArch64 JIT port into 8u In-Reply-To: References: <20201127072126.GJ488659@rincewind> <20201127073332.GA779738@rincewind> <20201127192303.GA793596@rincewind> <20210125194337.GC1819091@rincewind> Message-ID: <20210129172342.GD88249@rincewind> On 17:15 Wed 27 Jan , Aleksey Shipilev wrote: > On 1/25/21 8:43 PM, Andrew Hughes wrote: > > > > > *) src/share/vm/c1/c1_Runtime1.hpp > > > > > - so, "move_klass_patching" is undefined for AARCH64 (see .cpp change), should it be undeclared too? > > > > > > > > It's in src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp > > > > > > Yes, but under TARGET_ARCH_aarch64, *_patching and friends remains _only_ > > > declared, not defined. Shouldn't the entire *_patching declaration block be > > > e.g. this? > > > > > > #ifdef TARGET_ARCH_aarch64 > > > static void patch_code_aarch64(JavaThread* thread, StubID stub_id); > > > #else > > > static int access_field_patching(JavaThread* thread); > > > static int move_klass_patching(JavaThread* thread); > > > static int move_mirror_patching(JavaThread* thread); > > > static int move_appendix_patching(JavaThread* thread); > > > static void patch_code(JavaThread* thread, StubID stub_id); > > > #endif > > > > Still not sure what you're aiming at here. The routines are defined in > > c1_Runtime1_aarch64.cpp. If they were not defined anywhere, surely > > the build would fail? Given how well tested the current version is, > > I'd prefer to leave it as is in the current patch, so as to not to > > deviate too far in the initial import or delay this any > > further. You're welcome to change this in a follow-up patch. > > Yeah, it is not a build breakage to define the method and not implement it, > as long as nobody tries to reference the method. When that happens, linker > would complain. But I agree about leaving it as is for integration sanity. > Yeah, I'm not currently convinced they are all unused and, unlike the other changes, it is a significant code change, rather than cleanup and rewriting the same thing in a better way. Definitely something that warrants its own bug and review IMHO. > > I think breakage is unlikely - and that's why I'm trying to minimise differences > > from what's already in aarch64/shenandoah-jdk8u where possible - but we're now > > aiming for 8u292. > > > > https://cr.openjdk.java.net/~andrew/openjdk8/8257192/hotspot/webrev.03/ > > > > has the first change listed above and also JDK-8221725, following the inclusion > > of JDK-8221408 in 8u292. > > > > Differences look like this: > > > > $ diff -u ../../webrevs/openjdk8/8257192/hotspot/webrev.02/hotspot.patch ../../webrevs/openjdk8/8257192/hotspot/webrev.03/hotspot.aarch64.patch |egrep '^[+-][+-] ' > > -+ _matrule->equivalent(AD.globalNames(), short_branch->_matrule) && > > -+ AARCH64_ONLY(equivalent_predicates(this, short_branch)) NOT_AARCH64(true)) { > > ++ _matrule->equivalent(AD.globalNames(), short_branch->_matrule) > > ++ AARCH64_ONLY(&& equivalent_predicates(this, short_branch))) { > > -+ __ mov(tmp, (address) (~(os::vm_page_size()-1) | markOopDesc::lock_mask_in_place)); > > ++ __ mov(tmp, (address) (~(os::vm_page_size()-1) | (uintptr_t)markOopDesc::lock_mask_in_place)); > > > > Doing a test build with this now across all architectures. Let's finally get this in. > > Okay, this looks good to me. > > We are (hopefully) done! > Great, thanks! I've flagged the metabug for approval. > -- > Thanks, > -Aleksey > -- 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