From yan at azul.com Wed Apr 1 06:14:05 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 1 Apr 2020 09:14:05 +0300 Subject: [13u] RFR: 8241913: Bump update version for OpenJDK: jdk-13.0.4 In-Reply-To: References: <09f82ff1-4294-1c7a-4b25-0d6e7c9fa65b@azul.com> Message-ID: <18081937-f9bf-4a59-8756-63fbda1607e4@azul.com> Thank you Christoph! --yan On 31.03.2020 22:27, Langer, Christoph wrote: > Hi Yan, > > looks correct to me ?? > > Cheers > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Yuri Nesterenko >> Sent: Dienstag, 31. M?rz 2020 10:34 >> To: jdk-updates-dev at openjdk.java.net >> Subject: [13u] RFR: 8241913: Bump update version for OpenJDK: jdk-13.0.4 >> >> Hi, >> >> to start the next development period of jdk-13.0.4, we need to bump the >> version in jdk13u-dev >> Please review: >> http://cr.openjdk.java.net/~yan/8241913/webrev.0/ >> >> I'll push the change after successful request to add 13.0.4 to JBS and to >> hgupdater. >> >> Release date set to July 14, see https://www.oracle.com/security-alerts/ >> >> Thanks, >> --yan > From yan at azul.com Wed Apr 1 08:02:24 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 1 Apr 2020 11:02:24 +0300 Subject: [13u notice] 13u closed, 13u-dev bumped to 13.0.4 Message-ID: Hi, please don't push to jdk13u master, it is considered closed. Version of development repository jdk13u-dev is bumped to 13.0.4, and normal fixes from there are targeted to July release. Thanks, --yan From rwestrel at redhat.com Thu Apr 2 14:36:29 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 02 Apr 2020 16:36:29 +0200 Subject: [11u] 8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() In-Reply-To: <874kubfked.fsf@redhat.com> References: <874kubfked.fsf@redhat.com> Message-ID: <87h7y2c5ua.fsf@redhat.com> > This is required to backport 8237086 (assert(is_MachReturn()) running > CTW with fix for JDK-8231291). > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8217230 > http://hg.openjdk.java.net/jdk/jdk12/rev/1b292ae4eb50 > > Original patch does not apply cleanly to 11u because context changed in > compile.hpp. Patch is otherwise identical. > > 11u webrev: > http://cr.openjdk.java.net/~roland/8217230.11u/webrev.00/ > > Testing: x86_64 build, tier1 + tier2 Anyone for this review? Roland. From goetz.lindenmaier at sap.com Fri Apr 3 11:26:02 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Apr 2020 11:26:02 +0000 Subject: [11u] RFR(M): 8234728: Some security tests should support TLSv1.3 Message-ID: Hi, I would like to downport this for parity with 11.0.8-oracle. http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/webrev/ Although this change claims it is a test fix, it touches java.base. It fixes some type-os there. Some of the comments fixed are not in CipherSuite.java in 11u, so the patch did not apply. I had to skip these. Also, the change did not cleanly apply to the the test NullHostnameCheck.java because "8228967: Trust/Key store and SSL context utilities for tests" is not in 11. I adapted it. The TLS level is now passed to the test. The change makes TLSCipherSuitesOrder.java fail. First, it looks for a Cipher Suite not in 11. I removed this. Second, it depends on a change by "8171279: Support X25519 and X448 in TLS". This is a big change and only a single function call is needed. I added only the required changes of 8171279 to TLSSocketTemplate.java in this change. I also changed CipherSuitesInOrder.java so that it passes. I kept the old list of supportedCipherSuites, and added TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. Please review. Original change: https://bugs.openjdk.java.net/browse/JDK-8234728 https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 From rs at jelastic.com Fri Apr 3 12:25:38 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Fri, 3 Apr 2020 15:25:38 +0300 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 Message-ID: Hi everyone, I believe backporting JEP 346 to JDK 11 is a great idea. The first version of JEP 346 was against JDK 11, but then due to timing it got pushed to JDK 12. This improvement is very useful for saving resources and for making java more elastic - no need to use dirty hacks with an agent and explicit call of Full GC. We had a conversation in another thread about this backport and Thomas Schatzl kindly agreed to help with review, but looks like we need to get pre-approval from the current maintainers, so we do not waste our time for nothing at the end. Thank you and stay safe -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From neugens at redhat.com Fri Apr 3 13:02:47 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 3 Apr 2020 15:02:47 +0200 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 Message-ID: Hi all, I marked the bugs in $subject for backport in 11u-dev, they are kind of related so I would like to backport the full batch in one go if approved. I'm still thinking if it's a good idea to backport them to 8 too, the bugs are present though so I may as well do it, but I'll send a separate mail for this. There is another reason I send this email though, 8214481 and 8224109 do affect rendering. 8214481 seems mostly harmless but 8224109 does change the result of the affine transform. The current transform is wrong though, so I would expect that the ones who noticed would be happy about getting a fix but if they have workarounds in their code it will invalidate those, so I understand if we want to only ship those fixes in a major version and not in an update. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From aph at redhat.com Fri Apr 3 13:16:22 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 3 Apr 2020 14:16:22 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: Message-ID: On 4/3/20 1:25 PM, Ruslan Synytsky wrote: > We had a conversation in another thread about this backport and Thomas > Schatzl kindly agreed to help with review, but looks like we need to get > pre-approval from the current maintainers, so we do not waste our time for > nothing at the end. That makes sense. Do you have any idea of the likely complexity and impact of this patch? -- 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 goetz.lindenmaier at sap.com Fri Apr 3 14:14:46 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Apr 2020 14:14:46 +0000 Subject: [11u] RFR(S): 8235874: The ordering of Cipher Suites is not maintained provided through jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system property. Message-ID: Hi, I would like to downport this for parity with 11.0.8-oracle. I had to remove one cipher from the test because that is Not supported by 11: I had to remove TLS_CHACHA20_POLY1305_SHA256 http://cr.openjdk.java.net/~goetz/wr20/8235874-CipherSuite_ordering-jdk11/01/ original change: https://bugs.openjdk.java.net/browse/JDK-8235874 https://hg.openjdk.java.net/jdk/jdk14/rev/d821eb811ca8 Best regards, Goetz. From goetz.lindenmaier at sap.com Fri Apr 3 14:21:33 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Apr 2020 14:21:33 +0000 Subject: [ping] [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to v3.2.2 Message-ID: Hi, Could I please get a review? Thanks! Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Friday, March 27, 2020 7:47 AM > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to > v3.2.2 > > Hi > > I would like to downport this change for parity with 11.0.8-oracle. > The patch does not apply clean. > > http://cr.openjdk.java.net/~goetz/wr20/8236700-upgrade_jszip-jdk11/01/ > > The .js files have been moved to another location in 14: > https://bugs.openjdk.java.net/browse/JDK-8221644 jquery directory should > be renamed > (Later, they have been removed altogether > https://bugs.openjdk.java.net/browse/JDK-8237909 Remove zipped index > files feature) > > The move could be undone by simply editing the paths in the patch. > The patch then applies clean to the .js files. > > A part of the license change did not apply. > The corresponding text is not in 11. It was introduced > when moving the pako license into the jszip license. > The bugs that document this are closed, but here the link > to the changes: > 8219803: Nodeca Pako license text needs to be inserted in JSZip license text > http://hg.openjdk.java.net/jdk/jdk/rev/5d97784f08bf > 8228492: Remove pako.md > http://hg.openjdk.java.net/jdk/jdk/rev/5b5747ed8f34 > > I just dropped the sentence. > > Please review. > > Thanks, Goetz. From maoliang.ml at alibaba-inc.com Sat Apr 4 05:10:37 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Sat, 04 Apr 2020 13:10:37 +0800 Subject: =?UTF-8?B?UmU6IFsxMXVdIEJhY2twb3J0IEpFUCAzNDYgOiBQcm9tcHRseSBSZXR1cm4gVW51c2VkIENv?= =?UTF-8?B?bW1pdHRlZCBNZW1vcnkgZnJvbSBHMQ==?= In-Reply-To: References: , Message-ID: Hi Andrew , I have already tried the backport and prepare the webrevs. Please look into the following mail. Although there're many changesets but there are only few conflicts. https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html Thanks, Liang ------------------------------------------------------------------ From:Andrew Haley Send Time:2020 Apr. 3 (Fri.) 21:16 To:rs ; jdk-updates-dev Subject:Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 On 4/3/20 1:25 PM, Ruslan Synytsky wrote: > We had a conversation in another thread about this backport and Thomas > Schatzl kindly agreed to help with review, but looks like we need to get > pre-approval from the current maintainers, so we do not waste our time for > nothing at the end. That makes sense. Do you have any idea of the likely complexity and impact of this patch? -- 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 gil at azul.com Sat Apr 4 07:24:56 2020 From: gil at azul.com (Gil Tene) Date: Sat, 4 Apr 2020 07:24:56 +0000 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: Message-ID: - Are there any indications that Oracle is backporting this into their Oracle JDK 11? - Do we have input from the GC team on the complexity and potential tie-in or dependence [explicit or implied] of this JEP implementation on other post-11 G1 improvements, changes, assumptions, or invariant modifications? - What level of extensive review by GC experts and exhaustive GC stress-testing are we willing to put in to gain confidence that this will not regress the stability of 11u? [Note: There is a reason that GCs are slow-to-bring-to-producton-quality things, and often take 6-10 years to mature. Subtly introduced GC bugs are nasty things. They tend to heisen-bug, and often manifestas correctness issues rather than crashes, such that only stress tests with fastdebug and -alot modes will tend to detect many of them before they make it into the wild. An "I ran this in product mode on a bunch of in-house stuff for several hours and didn't seem to detect any crashes or math problems" approach just doesn't cut it for avoiding GC regression, and unfortunately neither does fastdebug execution of small test kernels]. I'll note my general opinion/position that "stability is job 1, 2, 3, 4, and 5" opinion for OpenJDK updates projects, and that the bar for adding features to 11u should to be very high, and driven by extreme need [something is broken or missing, a gap is opening with regards to Oracle JDK of the same version, or something is about to start cauing serious issues] as opposed to "this would be good to have, and the risk seems low" approach. Low risk is no reason to add a feature to a stable updates release when there are multiple GA'ed releases that have followed it already. The first question I'd ask anyone who wants this in 11u is "why don't you just move to using one of the three already-GA'ed OpenJDK versions that followed 11 and have this JEP implemented?". If the answer that comes back is along the lines of "because I think/hope 11u is much more stable", I'll note that (a) doing this sort of feature backport will fundamentally work against that premise, and (b) that thought/hope is either wrong, or it means that you are asking to introduced a potentially unstable or under-exposed feature into 11u (can't have it both ways). > On Apr 3, 2020, at 10:10 PM, Liang Mao wrote: > > Hi Andrew , > > I have already tried the backport and prepare the webrevs. Please look into the following mail. Although there're many changesets but there are only few conflicts. > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html > > > Thanks, > Liang > > > > > > ------------------------------------------------------------------ > From:Andrew Haley > Send Time:2020 Apr. 3 (Fri.) 21:16 > To:rs ; jdk-updates-dev > Subject:Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 > > On 4/3/20 1:25 PM, Ruslan Synytsky wrote: >> We had a conversation in another thread about this backport and Thomas >> Schatzl kindly agreed to help with review, but looks like we need to get >> pre-approval from the current maintainers, so we do not waste our time for >> nothing at the end. > > That makes sense. Do you have any idea of the likely complexity > and impact of this patch? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From christoph.langer at sap.com Sat Apr 4 10:30:20 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 4 Apr 2020 10:30:20 +0000 Subject: [11u] RFR: 8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly Message-ID: Hi, please review this backport of a test change to 11u. We see a failure in test nsk/jvmti/scenarios/sampling/SP06/sp06t001 once in a while in our regression testing. The related bug JDK-8053911 claims it has been fixed by JDK-8051349, so I looked into backporting it to reduce testing noise. The original patch does not apply for the .cpp files. In 11 these are still .c files and the constructs at the patched locations look different. I made the patch fit to the c code in 11. Bug: https://bugs.openjdk.java.net/browse/JDK-8051349 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3bc260237317 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8051349.11u/ Thanks Christoph From christoph.langer at sap.com Sat Apr 4 12:23:31 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sat, 4 Apr 2020 12:23:31 +0000 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u Message-ID: Hi, please review this partial backport of JDK-4947890 [0] to OpenJDK 11u. I'm currently working on backporting 8232080: jlink plugins for vendor information and command-line options [1]. That patch adds a jlink plugin for setting customized values for system properties java.vendor.version, java.vendor.url and java.vendor.url.bug in a jlinked runtime image by modifying the bytecode of class java.lang.VersionProps. Amongst other things, JDK-4947890 created the foundation for this patch by moving the initialization of java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. Before, it was initialized in libjava's System.c. While it's not desirable to backport JDK-4947890 as a whole to 11u, I'd like to bring in the part that moves initialization of java.vendor, java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. Since it's only a part of the original JDK-4947890, I created the new JDK11 specific bug JDK- 8242154. Bug: https://bugs.openjdk.java.net/browse/JDK-8242154 Original change of JDK-4947890: http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242154.11u.0/ Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-4947890 [1] https://bugs.openjdk.java.net/browse/JDK-8232080 From christoph.langer at sap.com Sun Apr 5 14:18:38 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 5 Apr 2020 14:18:38 +0000 Subject: [11u] RFR: 8232080: jlink plugins for vendor information and command-line options Message-ID: Hi, now, please review the backport of JDK-8232080: jlink plugins for vendor information and command-line options. It's part of Oracle's 11.0.7 and contains valuable functionality for downstream vendors and jlinkers. Bug: https://bugs.openjdk.java.net/browse/JDK-8232080 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6c255334120d Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232080.11u.0/ Its prerequisite is the backport of 8242154: Backport parts of JDK-4947890 to OpenJDK 11u which I posted yesterday [0]. With that change in place, I had to do the following: - resolve src/hotspot/share/classfile/classLoader.cpp - ignore src/hotspot/share/runtime/vmStructs.cpp, which does not apply - resolve src/hotspot/share/utilities/vmError.cpp - resolve src/java.base/share/classes/java/lang/VersionProps.java - ignore src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java which does not apply I furthermore changed the version information of ASM to ASM6 (instead of ASM7) since that's the level in JDK11. But functionality-wise that's no problem. Everything used is part of ASM6 as well. With this patch I plan to push backports of JDK-8233137, JDK-8233291 and JDK-8234696 as they contain follow-up fixes. Thanks Christoph [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/002955.html From christoph.langer at sap.com Sun Apr 5 14:37:35 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 5 Apr 2020 14:37:35 +0000 Subject: [11u] RFR: 8238721: Add failing client jtreg tests to the Problem List Message-ID: Hi, please review this backport of some test exclusions in the awt/swing area. This is 11.0.8-oracle and we're seeing some of the test errors on our newer MacOS and Linux test boxes as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8238721 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/915d0c063009 Webrev for resolved change: http://cr.openjdk.java.net/~clanger/webrevs/8238721.11u/ The only notable difference to the original change is that for java/awt/Modal/FileDialog/FileDialogDocModal7Test.java the backport changes the referenced bug to 7186009. In jdk11u-dev, 8198664 was referenced but I believe 7186009 is more current, as of head. Thanks Christoph From christoph.langer at sap.com Mon Apr 6 05:54:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 05:54:19 +0000 Subject: [11u] RFR(M): 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: Hi Goetz, thanks for doing this backport. I had a look now. I think it is ok, to just keep the old list of ciphersuites in test/jdk/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java, instead of making the old list fit into the commented format of the list that comes with the patch. For test/jdk/sun/security/util/HostnameMatcher/NullHostnameCheck.java I have a question: Why don't you take the hunk to use the passed protocol for clientCtx (https://hg.openjdk.java.net/jdk/jdk/rev/d6a38e8f7389#l6.35) ? I think it would fit. In test/jdk/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java, I would not uncomment the lines of TLS_CHACHA20_POLY1305_SHA256 and TLS_CHACHA20_POLY1305_SHA256 but rather drop them completely. These suites don't exist in 11 and for CipherSuitesInOrder.java we also don't keep them commented. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 3. April 2020 13:26 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR(M): 8234728: Some security tests should > support TLSv1.3 > > Hi, > > I would like to downport this for parity with 11.0.8-oracle. > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests- > jdk11/webrev/ > > Although this change claims it is a test fix, it touches > java.base. It fixes some type-os there. > Some of the comments fixed are not in CipherSuite.java in > 11u, so the patch did not apply. I had to skip these. > > Also, the change did not cleanly apply to the the test > NullHostnameCheck.java > because "8228967: Trust/Key store and SSL context utilities for tests" is not > in 11. I adapted it. The TLS level is now passed to the test. > > The change makes TLSCipherSuitesOrder.java fail. > First, it looks for a Cipher Suite not in 11. I removed this. > Second, it depends on a change by "8171279: Support X25519 and > X448 in TLS". This is a big change and only a single function > call is needed. I added only the required changes of 8171279 to > TLSSocketTemplate.java in this change. > > I also changed CipherSuitesInOrder.java so that it passes. > I kept the old list of supportedCipherSuites, and > added TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. > > Please review. > > Original change: > https://bugs.openjdk.java.net/browse/JDK-8234728 > https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 From christoph.langer at sap.com Mon Apr 6 05:58:09 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 05:58:09 +0000 Subject: [11u] RFR(S): 8235874: The ordering of Cipher Suites is not maintained provided through jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system property. In-Reply-To: References: Message-ID: Hi Goetz, this looks good. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 3. April 2020 16:15 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR(S): 8235874: The ordering of Cipher Suites is > not maintained provided through jdk.tls.client.cipherSuites and > jdk.tls.server.cipherSuites system property. > > Hi, > > I would like to downport this for parity with 11.0.8-oracle. > > I had to remove one cipher from the test because that is > Not supported by 11: > I had to remove TLS_CHACHA20_POLY1305_SHA256 > http://cr.openjdk.java.net/~goetz/wr20/8235874-CipherSuite_ordering- > jdk11/01/ > > original change: > https://bugs.openjdk.java.net/browse/JDK-8235874 > https://hg.openjdk.java.net/jdk/jdk14/rev/d821eb811ca8 > > Best regards, > Goetz. From christoph.langer at sap.com Mon Apr 6 06:09:38 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 06:09:38 +0000 Subject: [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to v3.2.2 In-Reply-To: References: Message-ID: Hi Goetz, looks correct. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Freitag, 27. M?rz 2020 07:47 > To: jdk-updates-dev at openjdk.java.net > Subject: [CAUTION] [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to > v3.2.2 > > Hi > > I would like to downport this change for parity with 11.0.8-oracle. > The patch does not apply clean. > > http://cr.openjdk.java.net/~goetz/wr20/8236700-upgrade_jszip-jdk11/01/ > > The .js files have been moved to another location in 14: > https://bugs.openjdk.java.net/browse/JDK-8221644 jquery directory should > be renamed > (Later, they have been removed altogether > https://bugs.openjdk.java.net/browse/JDK-8237909 Remove zipped index > files feature) > > The move could be undone by simply editing the paths in the patch. > The patch then applies clean to the .js files. > > A part of the license change did not apply. > The corresponding text is not in 11. It was introduced > when moving the pako license into the jszip license. > The bugs that document this are closed, but here the link > to the changes: > 8219803: Nodeca Pako license text needs to be inserted in JSZip license text > http://hg.openjdk.java.net/jdk/jdk/rev/5d97784f08bf > 8228492: Remove pako.md > http://hg.openjdk.java.net/jdk/jdk/rev/5b5747ed8f34 > > I just dropped the sentence. > > Please review. > > Thanks, Goetz. From christoph.langer at sap.com Mon Apr 6 06:11:57 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 06:11:57 +0000 Subject: [11u] RFR 8212986: Make Visual Studio compiler check less strict In-Reply-To: <00d4768f-b5c5-ab4c-e393-197da1e9f7db@redhat.com> References: <00d4768f-b5c5-ab4c-e393-197da1e9f7db@redhat.com> Message-ID: Hi Zhengyu, this looks good. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Zhengyu Gu > Sent: Dienstag, 31. M?rz 2020 18:19 > To: jdk-updates-dev at openjdk.java.net > Subject: [11u] RFR 8212986: Make Visual Studio compiler check less strict > > Hi, > > I would like to backport this small patch to 11u, so that can build JDK > with VSC++ with different locals, other than English. > > The original patch does not apply cleanly, but the conflicts are minor, > just line shifts. > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8212986 > Original webrev: https://hg.openjdk.java.net/jdk/jdk/rev/885b23ef907d > > 11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8212986_11u/webrev.00/ > > Test: > Built jdk11u on Windows. > > Thanks, > > -Zhengyu From christoph.langer at sap.com Mon Apr 6 06:21:49 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 06:21:49 +0000 Subject: Last 14u commit that was merged into 14.0.1 CPU repository In-Reply-To: References: Message-ID: Hi Rob, ping. As the April update release is approaching, can you please give the link to the latest jdk14u commit that was merged into the 14.0.1 CPU repository? Thanks Christoph From: Langer, Christoph Sent: Dienstag, 24. M?rz 2020 20:35 To: Rob McKenna Cc: jdk-updates-dev at openjdk.java.net Subject: Last 14u commit that was merged into 14.0.1 CPU repository Hi Rob, can you please let the world know, which was the latest commit from jdk-updates/jdk14u that made it into the 14.0.1 CPU repository? Thanks Christoph From tobias.hartmann at oracle.com Mon Apr 6 06:34:45 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 6 Apr 2020 08:34:45 +0200 Subject: [11u] 8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() In-Reply-To: <87h7y2c5ua.fsf@redhat.com> References: <874kubfked.fsf@redhat.com> <87h7y2c5ua.fsf@redhat.com> Message-ID: Hi Roland, looks good. Best regards, Tobias On 02.04.20 16:36, Roland Westrelin wrote: > >> This is required to backport 8237086 (assert(is_MachReturn()) running >> CTW with fix for JDK-8231291). >> >> Original bug: >> https://bugs.openjdk.java.net/browse/JDK-8217230 >> http://hg.openjdk.java.net/jdk/jdk12/rev/1b292ae4eb50 >> >> Original patch does not apply cleanly to 11u because context changed in >> compile.hpp. Patch is otherwise identical. >> >> 11u webrev: >> http://cr.openjdk.java.net/~roland/8217230.11u/webrev.00/ >> >> Testing: x86_64 build, tier1 + tier2 > > Anyone for this review? > > Roland. > From rwestrel at redhat.com Mon Apr 6 07:17:15 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 06 Apr 2020 09:17:15 +0200 Subject: [11u] 8217230: assert(t == t_no_spec) failure in NodeHash::check_no_speculative_types() In-Reply-To: References: <874kubfked.fsf@redhat.com> <87h7y2c5ua.fsf@redhat.com> Message-ID: <87369hccck.fsf@redhat.com> Thanks for the review. Roland. From goetz.lindenmaier at sap.com Mon Apr 6 07:44:23 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Apr 2020 07:44:23 +0000 Subject: [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to v3.2.2 In-Reply-To: References: Message-ID: Hi Christoph, Thanks for reviewing! Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Monday, April 6, 2020 8:10 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to v3.2.2 > > Hi Goetz, > > looks correct. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 27. M?rz 2020 07:47 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to > > v3.2.2 > > > > Hi > > > > I would like to downport this change for parity with 11.0.8-oracle. > > The patch does not apply clean. > > > > http://cr.openjdk.java.net/~goetz/wr20/8236700-upgrade_jszip-jdk11/01/ > > > > The .js files have been moved to another location in 14: > > https://bugs.openjdk.java.net/browse/JDK-8221644 jquery directory > should > > be renamed > > (Later, they have been removed altogether > > https://bugs.openjdk.java.net/browse/JDK-8237909 Remove zipped index > > files feature) > > > > The move could be undone by simply editing the paths in the patch. > > The patch then applies clean to the .js files. > > > > A part of the license change did not apply. > > The corresponding text is not in 11. It was introduced > > when moving the pako license into the jszip license. > > The bugs that document this are closed, but here the link > > to the changes: > > 8219803: Nodeca Pako license text needs to be inserted in JSZip license > text > > http://hg.openjdk.java.net/jdk/jdk/rev/5d97784f08bf > > 8228492: Remove pako.md > > http://hg.openjdk.java.net/jdk/jdk/rev/5b5747ed8f34 > > > > I just dropped the sentence. > > > > Please review. > > > > Thanks, Goetz. From aph at redhat.com Mon Apr 6 10:43:01 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 6 Apr 2020 11:43:01 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: Message-ID: On 4/4/20 8:24 AM, Gil Tene wrote: > - Are there any indications that Oracle is backporting this into > their Oracle JDK 11? > > - Do we have input from the GC team on the complexity and potential > tie-in or dependence [explicit or implied] of this JEP > implementation on other post-11 G1 improvements, changes, > assumptions, or invariant modifications? > > - What level of extensive review by GC experts and exhaustive GC > stress-testing are we willing to put in to gain confidence that this > will not regress the stability of 11u? All good questions. The idea of the rolling updates model of OpenJDK is to allow the rapid development and release of features such as these, and because Java is almost entirely backwards compatible, users can choose a modern but less-tested release or a stable long-term release. If we were to backport substantial changes such as this to the stable 11u branch we would take away that choice from our users. Reluctantly, therefore, I must say no, because our users need to be able to make that choice. Maybe there is an argument to be made for a "jdk11u-performance" release of OpenJDK 11, which would be distinct from the stable release. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Mon Apr 6 11:57:46 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 11:57:46 +0000 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 In-Reply-To: References: Message-ID: Hi Mario, I think all of these fixes are good for backporting to JDK11 Updates. So they are approved now. Best regards Christoph > -----Original Message----- > From: Mario Torre > Sent: Freitag, 3. April 2020 15:03 > To: jdk-updates-dev > Cc: Andrew Haley ; Langer, Christoph > > Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 > > Hi all, > > I marked the bugs in $subject for backport in 11u-dev, they are kind > of related so I would like to backport the full batch in one go if > approved. > > I'm still thinking if it's a good idea to backport them to 8 too, the > bugs are present though so I may as well do it, but I'll send a > separate mail for this. > > There is another reason I send this email though, 8214481 and 8224109 > do affect rendering. 8214481 seems mostly harmless but 8224109 does > change the result of the affine transform. The current transform is > wrong though, so I would expect that the ones who noticed would be > happy about getting a fix but if they have workarounds in their code > it will invalidate those, so I understand if we want to only ship > those fixes in a major version and not in an update. > > Cheers, > Mario > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From neugens at redhat.com Mon Apr 6 12:04:06 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 6 Apr 2020 14:04:06 +0200 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 In-Reply-To: References: Message-ID: Thanks! Cheers, Mario On Mon, Apr 6, 2020 at 1:58 PM Langer, Christoph wrote: > > Hi Mario, > > I think all of these fixes are good for backporting to JDK11 Updates. So they are approved now. > > Best regards > Christoph > > > -----Original Message----- > > From: Mario Torre > > Sent: Freitag, 3. April 2020 15:03 > > To: jdk-updates-dev > > Cc: Andrew Haley ; Langer, Christoph > > > > Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 > > > > Hi all, > > > > I marked the bugs in $subject for backport in 11u-dev, they are kind > > of related so I would like to backport the full batch in one go if > > approved. > > > > I'm still thinking if it's a good idea to backport them to 8 too, the > > bugs are present though so I may as well do it, but I'll send a > > separate mail for this. > > > > There is another reason I send this email though, 8214481 and 8224109 > > do affect rendering. 8214481 seems mostly harmless but 8224109 does > > change the result of the affine transform. The current transform is > > wrong though, so I would expect that the ones who noticed would be > > happy about getting a fix but if they have workarounds in their code > > it will invalidate those, so I understand if we want to only ship > > those fixes in a major version and not in an update. > > > > Cheers, > > Mario > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From goetz.lindenmaier at sap.com Mon Apr 6 16:23:52 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Apr 2020 16:23:52 +0000 Subject: [11u] RFR(M): 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: Hi Christoph, Thanks for reviewing. > I think it is ok, to just keep the old list of ciphersuites in > test/jdk/javax/net/ssl/sanity/ciphersuites/CipherSuitesInOrder.java, instead > of making the old list fit into the commented format of the list that comes > with the patch. Thanks. I think merging the comments in there wouldn't work very well because of the different orderings. > For test/jdk/sun/security/util/HostnameMatcher/NullHostnameCheck.java I > have a question: Why don't you take the hunk to use the passed protocol for > clientCtx (https://hg.openjdk.java.net/jdk/jdk/rev/d6a38e8f7389#l6.35) ? I > think it would fit. The tests differ a lot. I edited the test in 11 to use the protocol passed in Wherever needed. The test in 11 does not deal with the clientCtx, so There was no place for that. > In test/jdk/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java, I > would not uncomment the lines of TLS_CHACHA20_POLY1305_SHA256 and > TLS_CHACHA20_POLY1305_SHA256 but rather drop them completely. These > suites don't exist in 11 and for CipherSuitesInOrder.java we also don't keep > them commented. Ok, I will remove them. New webrev: http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/02/ Best regards, Goetz. > > Best regards > Christoph > > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 3. April 2020 13:26 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR(M): 8234728: Some security tests should > > support TLSv1.3 > > > > Hi, > > > > I would like to downport this for parity with 11.0.8-oracle. > > > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests- > > jdk11/webrev/ > > > > Although this change claims it is a test fix, it touches > > java.base. It fixes some type-os there. > > Some of the comments fixed are not in CipherSuite.java in > > 11u, so the patch did not apply. I had to skip these. > > > > Also, the change did not cleanly apply to the the test > > NullHostnameCheck.java > > because "8228967: Trust/Key store and SSL context utilities for tests" is not > > in 11. I adapted it. The TLS level is now passed to the test. > > > > The change makes TLSCipherSuitesOrder.java fail. > > First, it looks for a Cipher Suite not in 11. I removed this. > > Second, it depends on a change by "8171279: Support X25519 and > > X448 in TLS". This is a big change and only a single function > > call is needed. I added only the required changes of 8171279 to > > TLSSocketTemplate.java in this change. > > > > I also changed CipherSuitesInOrder.java so that it passes. > > I kept the old list of supportedCipherSuites, and > > added TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. > > > > Please review. > > > > Original change: > > https://bugs.openjdk.java.net/browse/JDK-8234728 > > https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 From goetz.lindenmaier at sap.com Mon Apr 6 16:35:16 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 6 Apr 2020 16:35:16 +0000 Subject: [11u] RFR(M): 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: > > For test/jdk/sun/security/util/HostnameMatcher/NullHostnameCheck.java > > I have a question: Why don't you take the hunk to use the passed protocol > >for clientCtx (https://hg.openjdk.java.net/jdk/jdk/rev/d6a38e8f7389#l6.35) ? I > > think it would fit. > The tests differ a lot. I edited the test in 11 to use the protocol passed in > Wherever needed. The test in 11 does not deal with the clientCtx, so > There was no place for that. Oh no, you are right, I missed it. All nonsense above ... here better webrev: http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/03/ Sorry, Goetz > > In test/jdk/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java, I > > would not uncomment the lines of TLS_CHACHA20_POLY1305_SHA256 and > > TLS_CHACHA20_POLY1305_SHA256 but rather drop them completely. > These > > suites don't exist in 11 and for CipherSuitesInOrder.java we also don't keep > > them commented. > Ok, I will remove them. > > New webrev: > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/02/ > > Best regards, > Goetz. > > > > > > Best regards > > Christoph > > > > > > > -----Original Message----- > > > From: jdk-updates-dev > On > > > Behalf Of Lindenmaier, Goetz > > > Sent: Freitag, 3. April 2020 13:26 > > > To: jdk-updates-dev at openjdk.java.net > > > Subject: [CAUTION] [11u] RFR(M): 8234728: Some security tests should > > > support TLSv1.3 > > > > > > Hi, > > > > > > I would like to downport this for parity with 11.0.8-oracle. > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests- > > > jdk11/webrev/ > > > > > > Although this change claims it is a test fix, it touches > > > java.base. It fixes some type-os there. > > > Some of the comments fixed are not in CipherSuite.java in > > > 11u, so the patch did not apply. I had to skip these. > > > > > > Also, the change did not cleanly apply to the the test > > > NullHostnameCheck.java > > > because "8228967: Trust/Key store and SSL context utilities for tests" is > not > > > in 11. I adapted it. The TLS level is now passed to the test. > > > > > > The change makes TLSCipherSuitesOrder.java fail. > > > First, it looks for a Cipher Suite not in 11. I removed this. > > > Second, it depends on a change by "8171279: Support X25519 and > > > X448 in TLS". This is a big change and only a single function > > > call is needed. I added only the required changes of 8171279 to > > > TLSSocketTemplate.java in this change. > > > > > > I also changed CipherSuitesInOrder.java so that it passes. > > > I kept the old list of supportedCipherSuites, and > > > added TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. > > > > > > Please review. > > > > > > Original change: > > > https://bugs.openjdk.java.net/browse/JDK-8234728 > > > https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 From neugens at redhat.com Mon Apr 6 17:15:48 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 6 Apr 2020 19:15:48 +0200 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 In-Reply-To: References: Message-ID: I'm going to retire 8239091 from this list for now, I did more testing and I can see some rendering artifacts in some cases, and I can't figure out why just yet, I can't see any obvious difference in the code so it may be caused by some other changes. The other patches are fine however so far. Cheers, Mario On Mon, Apr 6, 2020 at 2:04 PM Mario Torre wrote: > > Thanks! > > Cheers, > Mario > > On Mon, Apr 6, 2020 at 1:58 PM Langer, Christoph > wrote: > > > > Hi Mario, > > > > I think all of these fixes are good for backporting to JDK11 Updates. So they are approved now. > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Mario Torre > > > Sent: Freitag, 3. April 2020 15:03 > > > To: jdk-updates-dev > > > Cc: Andrew Haley ; Langer, Christoph > > > > > > Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 > > > > > > Hi all, > > > > > > I marked the bugs in $subject for backport in 11u-dev, they are kind > > > of related so I would like to backport the full batch in one go if > > > approved. > > > > > > I'm still thinking if it's a good idea to backport them to 8 too, the > > > bugs are present though so I may as well do it, but I'll send a > > > separate mail for this. > > > > > > There is another reason I send this email though, 8214481 and 8224109 > > > do affect rendering. 8214481 seems mostly harmless but 8224109 does > > > change the result of the affine transform. The current transform is > > > wrong though, so I would expect that the ones who noticed would be > > > happy about getting a fix but if they have workarounds in their code > > > it will invalidate those, so I understand if we want to only ship > > > those fixes in a major version and not in an update. > > > > > > Cheers, > > > Mario > > > > > > -- > > > Mario Torre > > > Associate Manager, Software Engineering > > > Red Hat GmbH > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Mon Apr 6 19:05:12 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 19:05:12 +0000 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 In-Reply-To: References: Message-ID: Hi Mario, thanks for being cautious here. Looking at this change, however, it's hard to believe that it can have any functional effect, unless you had set your FREETYPE_PROPERTIES variable to the exact string "interpreter-version". Shall I withdraw the approval flags or do you just need a bit of time for further testing? Cheers Christoph > -----Original Message----- > From: Mario Torre > Sent: Montag, 6. April 2020 19:16 > To: Langer, Christoph > Cc: jdk-updates-dev ; Andrew Haley > > Subject: Re: FYI: request backports for 8239091, 8238942, 8224109 and > 8214481 > > I'm going to retire 8239091 from this list for now, I did more testing > and I can see some rendering artifacts in some cases, and I can't > figure out why just yet, I can't see any obvious difference in the > code so it may be caused by some other changes. > > The other patches are fine however so far. > > Cheers, > Mario > > On Mon, Apr 6, 2020 at 2:04 PM Mario Torre wrote: > > > > Thanks! > > > > Cheers, > > Mario > > > > On Mon, Apr 6, 2020 at 1:58 PM Langer, Christoph > > wrote: > > > > > > Hi Mario, > > > > > > I think all of these fixes are good for backporting to JDK11 Updates. So > they are approved now. > > > > > > Best regards > > > Christoph > > > > > > > -----Original Message----- > > > > From: Mario Torre > > > > Sent: Freitag, 3. April 2020 15:03 > > > > To: jdk-updates-dev > > > > Cc: Andrew Haley ; Langer, Christoph > > > > > > > > Subject: FYI: request backports for 8239091, 8238942, 8224109 and > 8214481 > > > > > > > > Hi all, > > > > > > > > I marked the bugs in $subject for backport in 11u-dev, they are kind > > > > of related so I would like to backport the full batch in one go if > > > > approved. > > > > > > > > I'm still thinking if it's a good idea to backport them to 8 too, the > > > > bugs are present though so I may as well do it, but I'll send a > > > > separate mail for this. > > > > > > > > There is another reason I send this email though, 8214481 and 8224109 > > > > do affect rendering. 8214481 seems mostly harmless but 8224109 does > > > > change the result of the affine transform. The current transform is > > > > wrong though, so I would expect that the ones who noticed would be > > > > happy about getting a fix but if they have workarounds in their code > > > > it will invalidate those, so I understand if we want to only ship > > > > those fixes in a major version and not in an update. > > > > > > > > Cheers, > > > > Mario > > > > > > > > -- > > > > Mario Torre > > > > Associate Manager, Software Engineering > > > > Red Hat GmbH > > > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > > > > > > -- > > Mario Torre > > Associate Manager, Software Engineering > > Red Hat GmbH > > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Mon Apr 6 19:07:37 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 6 Apr 2020 19:07:37 +0000 Subject: [11u] RFR(M): 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: Hi Goetz, looks good now. Feel free to push, unless this update would break the test results ?? Best regards Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 6. April 2020 18:35 > To: Lindenmaier, Goetz ; Langer, Christoph > ; jdk-updates-dev at openjdk.java.net > Subject: RE: [11u] RFR(M): 8234728: Some security tests should support > TLSv1.3 > > > > For > test/jdk/sun/security/util/HostnameMatcher/NullHostnameCheck.java > > > I have a question: Why don't you take the hunk to use the passed > protocol > > >for clientCtx > (https://hg.openjdk.java.net/jdk/jdk/rev/d6a38e8f7389#l6.35) ? I > > > think it would fit. > > The tests differ a lot. I edited the test in 11 to use the protocol passed in > > Wherever needed. The test in 11 does not deal with the clientCtx, so > > There was no place for that. > > Oh no, you are right, I missed it. All nonsense above ... here better webrev: > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/03/ > > Sorry, > Goetz > > > > > In test/jdk/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java, > I > > > would not uncomment the lines of TLS_CHACHA20_POLY1305_SHA256 > and > > > TLS_CHACHA20_POLY1305_SHA256 but rather drop them completely. > > These > > > suites don't exist in 11 and for CipherSuitesInOrder.java we also don't > keep > > > them commented. > > Ok, I will remove them. > > > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/02/ > > > > Best regards, > > Goetz. > > > > > > > > > > Best regards > > > Christoph > > > > > > > > > > -----Original Message----- > > > > From: jdk-updates-dev > > On > > > > Behalf Of Lindenmaier, Goetz > > > > Sent: Freitag, 3. April 2020 13:26 > > > > To: jdk-updates-dev at openjdk.java.net > > > > Subject: [CAUTION] [11u] RFR(M): 8234728: Some security tests should > > > > support TLSv1.3 > > > > > > > > Hi, > > > > > > > > I would like to downport this for parity with 11.0.8-oracle. > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests- > > > > jdk11/webrev/ > > > > > > > > Although this change claims it is a test fix, it touches > > > > java.base. It fixes some type-os there. > > > > Some of the comments fixed are not in CipherSuite.java in > > > > 11u, so the patch did not apply. I had to skip these. > > > > > > > > Also, the change did not cleanly apply to the the test > > > > NullHostnameCheck.java > > > > because "8228967: Trust/Key store and SSL context utilities for tests" is > > not > > > > in 11. I adapted it. The TLS level is now passed to the test. > > > > > > > > The change makes TLSCipherSuitesOrder.java fail. > > > > First, it looks for a Cipher Suite not in 11. I removed this. > > > > Second, it depends on a change by "8171279: Support X25519 and > > > > X448 in TLS". This is a big change and only a single function > > > > call is needed. I added only the required changes of 8171279 to > > > > TLSSocketTemplate.java in this change. > > > > > > > > I also changed CipherSuitesInOrder.java so that it passes. > > > > I kept the old list of supportedCipherSuites, and > > > > added TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. > > > > > > > > Please review. > > > > > > > > Original change: > > > > https://bugs.openjdk.java.net/browse/JDK-8234728 > > > > https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 From neugens at redhat.com Mon Apr 6 19:27:15 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 6 Apr 2020 21:27:15 +0200 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 In-Reply-To: References: Message-ID: On Mon, Apr 6, 2020 at 9:05 PM Langer, Christoph wrote: > > Hi Mario, > > thanks for being cautious here. Hi Christoph, > Looking at this change, however, it's hard to believe that it can have any functional effect, unless you had set your FREETYPE_PROPERTIES variable to the exact string "interpreter-version". Ouch, I pasted the wrong bug ID before!! The patch I want to retire is this (and sorry for the noise!): https://bugs.openjdk.java.net/browse/JDK-8214481 While I still want to keep the others: 8224109, 8238942 and 8239091. The FT_LOAD_NO_HINTING change is the problem for me. In some fonts and with fractional metrics enabled it causes the rendering to be very blurry. I do remember this to be the case in 8 or 7 at some point and then it was finally fixed, so this change is a regression for me, this is most likely tied to freetype but I don't understand why it's not happening in 14+ with all the same code and compiled the same way, so clearly I'm missing a patch somewhere and I would like to figure out which one. > Shall I withdraw the approval flags or do you just need a bit of time for further testing? Yes, I think I'll take another day or two to test. I have built the jdk with the default settings. I thought that the FREETYPE_PROPERTIES thing was responsible at first but I didn't change this and is not set in my build, but I'll need to do some more testing. I do remember we had a couple of changes related to this as well as changes specific to fractional metrics, but the code is actually the same at this stage between 15-dev and 11-dev. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From rs at jelastic.com Tue Apr 7 09:37:41 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Tue, 7 Apr 2020 12:37:41 +0300 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: Message-ID: 100% agree that stability should be #1 acceptance criteria of any backporting. Is there a good enough process in place to make sure that stability does not degrade? > why don't you just move to using one of the three already-GA'ed OpenJDK versions that followed 11 and have this If we talk about our company - we do offer new releases to the end users, it's easy to get a standalone JDK runtime or "some" middleware stacks that support the newest versions. However while number of jdk11+ installations is growing the number of jdk8 environments is still high. We can't force people to move to the latest versions... We can motivate and promote it, but no way to force it. And, I assume *many companies would prefer to use LTS versions and the next LTS is planned to be released with Java SE 17 in September 2021*. > Maybe there is an argument to be made for a "jdk11u-performance" Motivation of this topic is simple - to make Java applications (including Java middleware stacks) less greedy on the RAM usage, in other words make it elastic. This problem exists many years as the default GC was not aligned well with the widely adopted elastic cloud technologies, specifically with containers. People used to live with this issue... But some cloud vendors tried to come up with different solutions. For example, Alibaba and Jelastic had own internal customization for bringing more efficiency to java workloads. There is also an old article from RedHat OpenShift related to the same issue https://developers.redhat.com/blog/2014/07/15/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/. I hope many of us understand that cost of consumed cloud resources is carefully counted at small and medium sized projects and even large enterprises that care about infrastructure use optimization may benefit from it. Now finally the elasticity is available in the open source core. The new GC implementations took into account the importance of the resource usage efficiency (Shenandoah, ZGC) . We have a solution for G1 as well, so no need to give up on efficiency with the default GC. Can we accept this backport as a performance improvement? I believe it depends on what people put behind the "performance" word. The improvement will not speed up anything while it can help to get the same results with smaller amount of used resources. On Mon, 6 Apr 2020 at 13:43, Andrew Haley wrote: > On 4/4/20 8:24 AM, Gil Tene wrote: > > > - Are there any indications that Oracle is backporting this into > > their Oracle JDK 11? > > > > - Do we have input from the GC team on the complexity and potential > > tie-in or dependence [explicit or implied] of this JEP > > implementation on other post-11 G1 improvements, changes, > > assumptions, or invariant modifications? > > > > - What level of extensive review by GC experts and exhaustive GC > > stress-testing are we willing to put in to gain confidence that this > > will not regress the stability of 11u? > > All good questions. > > The idea of the rolling updates model of OpenJDK is to allow the rapid > development and release of features such as these, and because Java is > almost entirely backwards compatible, users can choose a modern but > less-tested release or a stable long-term release. If we were to > backport substantial changes such as this to the stable 11u branch we > would take away that choice from our users. Reluctantly, therefore, I > must say no, because our users need to be able to make that choice. > > Maybe there is an argument to be made for a "jdk11u-performance" > release of OpenJDK 11, which would be distinct from the stable > release. > > -- > 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 > > -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From maoliang.ml at alibaba-inc.com Tue Apr 7 10:30:35 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Tue, 07 Apr 2020 18:30:35 +0800 Subject: =?UTF-8?B?WzExdV0gQmFja3BvcnQgSkVQIDM0NiA6IFByb21wdGx5IFJldHVybiBVbnVzZWQgQ29tbWl0?= =?UTF-8?B?dGVkIE1lbW9yeSBmcm9tIEcx?= Message-ID: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> Hi, Agree with Ruslan that the elasticity of memory footprint of Java application is really important. As far as I know, not only Jelastic and Alibaba, Google has its own similar feature. But much more users don't have the ability to make such customization to JDK. In the meanwhile most of users are still using JDK8 and migrating to JDK11 is a noticeable trend. I totally agree stability is the most important factor for any changes against stable versions. But if a feature has been tested through several releases(the JEP and related bug fixes were pushed in JDK12/13), we are able to take it into the consideration as a stable change. Anyway, do you think we shall get some more technical comments from Thomas before make the decision? Thanks, Liang ------------------------------------------------------------------ From:Ruslan Synytsky Send Time:2020 Apr. 7 (Tue.) 17:37 To:Andrew Haley Cc:Gil Tene ; "MAO, Liang" ; jdk-updates-dev Subject:Re: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 100% agree that stability should be #1 acceptance criteria of any backporting. Is there a good enough process in place to make sure that stability does not degrade? > why don't you just move to using one of the three already-GA'ed OpenJDK versions that followed 11 and have this If we talk about our company - we do offer new releases to the end users, it's easy to get a standalone JDK runtime or "some" middleware stacks that support the newest versions. However while number of jdk11+ installations is growing the number of jdk8 environments is still high. We can't force people to move to the latest versions... We can motivate and promote it, but no way to force it. And, I assume many companies would prefer to use LTS versions and the next LTS is planned to be released with Java SE 17 in September 2021. > Maybe there is an argument to be made for a "jdk11u-performance" Motivation of this topic is simple - to make Java applications (including Java middleware stacks) less greedy on the RAM usage, in other words make it elastic. This problem exists many years as the default GC was not aligned well with the widely adopted elastic cloud technologies, specifically with containers. People used to live with this issue... But some cloud vendors tried to come up with different solutions. For example, Alibaba and Jelastic had own internal customization for bringing more efficiency to java workloads. There is also an old article from RedHat OpenShift related to the same issue https://developers.redhat.com/blog/2014/07/15/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/. I hope many of us understand that cost of consumed cloud resources is carefully counted at small and medium sized projects and even large enterprises that care about infrastructure use optimization may benefit from it. Now finally the elasticity is available in the open source core. The new GC implementations took into account the importance of the resource usage efficiency (Shenandoah, ZGC) . We have a solution for G1 as well, so no need to give up on efficiency with the default GC. Can we accept this backport as a performance improvement? I believe it depends on what people put behind the "performance" word. The improvement will not speed up anything while it can help to get the same results with smaller amount of used resources. On Mon, 6 Apr 2020 at 13:43, Andrew Haley wrote: On 4/4/20 8:24 AM, Gil Tene wrote: > - Are there any indications that Oracle is backporting this into > their Oracle JDK 11? > > - Do we have input from the GC team on the complexity and potential > tie-in or dependence [explicit or implied] of this JEP > implementation on other post-11 G1 improvements, changes, > assumptions, or invariant modifications? > > - What level of extensive review by GC experts and exhaustive GC > stress-testing are we willing to put in to gain confidence that this > will not regress the stability of 11u? All good questions. The idea of the rolling updates model of OpenJDK is to allow the rapid development and release of features such as these, and because Java is almost entirely backwards compatible, users can choose a modern but less-tested release or a stable long-term release. If we were to backport substantial changes such as this to the stable 11u branch we would take away that choice from our users. Reluctantly, therefore, I must say no, because our users need to be able to make that choice. Maybe there is an argument to be made for a "jdk11u-performance" release of OpenJDK 11, which would be distinct from the stable release. -- 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 -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From aph at redhat.com Tue Apr 7 10:30:23 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Apr 2020 11:30:23 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: Message-ID: On 4/7/20 10:37 AM, Ruslan Synytsky wrote: > 100% agree that stability should be #1 acceptance criteria of any > backporting. Is there a good enough process in place to make sure that > stability does not degrade? Not really. No test plan can ever be perfect for such things, and simply adding tests makes the test suite run for longer, meaning it gets run less frequently. In practice, most of the subtle bugs have been reported in production. The only effective way to test new major features (AFAIK) would be to have an experimental release of JDK 11. We'd then put it out and get people to test it in real applications, then very carefully merge it back into mainline. The problem with this plan, of course, is that it's very hard in practice to get people to use experimental releases in production! This is the perennial problem with Beta testing, as we all know. >> Maybe there is an argument to be made for a "jdk11u-performance" > Motivation of this topic is simple - to make Java applications > (including Java middleware stacks) less greedy on the RAM usage, in > other words make it elastic. This problem exists many years as the > default GC was not aligned well with the widely adopted elastic > cloud technologies, specifically with containers. People used to > live with this issue... But some cloud vendors tried to come up with > different solutions. For example, Alibaba and Jelastic had own > internal customization for bringing more efficiency to java > workloads. There is also an old article from RedHat OpenShift > related to the same issue > https://developers.redhat.com/blog/2014/07/15/dude-wheres-my-paas-memory-tuning-javas-footprint-in-openshift-part-1/. > > I hope many of us understand that cost of consumed cloud resources > is carefully counted at small and medium sized projects and even > large enterprises that care about infrastructure use optimization > may benefit from it. These days I think of little else. I'm sure that's true for many of us; we all understand this. However, it's a balance of risk and reward. I am aware that JDK 11u has many downstream variants, with varying features. JDK 11u, therefore, has to be the lowest common denominator, the most conservative baseline. > Now finally the elasticity is available in the open source core. The > new GC implementations took into account the importance of the > resource usage efficiency (Shenandoah, ZGC) . We have a solution for > G1 as well, so no need to give up on efficiency with the default > GC. Can we accept this backport as a performance improvement? > I believe it depends on what people put behind the "performance" > word. The improvement will not speed up anything while it can help > to get the same results with smaller amount of used resources. "Performance" is a very broad term. If it's using less memory to get the same throughput, that's what I call better performance. The question for us to answer is this: what is JDK 11u for? It's a maturing piece of software, approaching stability. And how do you determine that a piece of software is stable? In my opinion, that's when it's changing very little while meeting the needs of its users. No surprises, in other words. A question for you. Do you believe that there should be a version of JDK 11 which does not change very much, except for occasional fixes for remaining bugs? -- 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 aph at redhat.com Tue Apr 7 10:36:41 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Apr 2020 11:36:41 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> References: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> Message-ID: <510b4e9a-d3e8-4b35-5183-47d5c029668c@redhat.com> On 4/7/20 11:30 AM, Liang Mao wrote: > But if a feature has been tested through several releases(the JEP > and related bug fixes were pushed in JDK12/13), we are able to take > it into the consideration as a stable change. Anyway, do you think > we shall get some more technical comments from Thomas before make > the decision? I think we should keep talking. As far as I'm concerned this is still a live issue for discussion, but I made my points in https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/002977.html -- 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 rbruno at gsd.inesc-id.pt Tue Apr 7 11:42:20 2020 From: rbruno at gsd.inesc-id.pt (Rodrigo Bruno) Date: Tue, 7 Apr 2020 13:42:20 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <510b4e9a-d3e8-4b35-5183-47d5c029668c@redhat.com> References: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> <510b4e9a-d3e8-4b35-5183-47d5c029668c@redhat.com> Message-ID: Hi everyone, I globally agree with most of the discussion so far. Just trying to answer Gil's question on why we want this in JDK11u; I think the main reason is that JDK11 is the current LST and the next one is still >1year away. IMHO and experience, people in the Java community tend to extensively rely on libraries and code that was not developed by themselves. A great percentage of this code is not updated regularly to keep up with non-LTS JDK releases and trying to move your project to a more recent JDK release is a huge headache, especially in large projects with 100s of dependencies. I've been in several projects where people are reluctant to deploy production code in non-LTS JDKs... Andrew also mentioned the problem of testing experimental releases. I think here this is not a problem since we have two industry companies advocating for this patch. Would Alibaba and Jelastic be available to deploy an experimental version of JDK11u with this JEP? If so, maybe after a couple of months there would be enough convincing evidence that this JEP won't break anything significant. cheers, rodrigo Andrew Haley escreveu no dia ter?a, 7/04/2020 ?(s) 12:51: > On 4/7/20 11:30 AM, Liang Mao wrote: > > > But if a feature has been tested through several releases(the JEP > > and related bug fixes were pushed in JDK12/13), we are able to take > > it into the consideration as a stable change. Anyway, do you think > > we shall get some more technical comments from Thomas before make > > the decision? > > I think we should keep talking. As far as I'm concerned this is still > a live issue for discussion, but I made my points in > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/002977.html > > -- > 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 > > -- rodrigo-bruno.github.io From shade at redhat.com Tue Apr 7 12:20:29 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 7 Apr 2020 14:20:29 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> <510b4e9a-d3e8-4b35-5183-47d5c029668c@redhat.com> Message-ID: Hi, On 4/7/20 1:42 PM, Rodrigo Bruno wrote: > Andrew also mentioned the problem of testing experimental releases. I think > here this is not a problem since we have two industry companies advocating > for this patch. Would Alibaba and Jelastic be available to deploy an > experimental version of JDK11u with this JEP? If so, maybe after a couple > of months there would be enough convincing evidence that this JEP won't > break anything significant. Speaking as someone who does Shenandoah support in downstream JDK 11 for years now, I can tell that backporting non-trivial JVM/GC features is only sane when you have the component/area developers' buy-in for *supporting* it in the target release. LTS maintenance is not fire-and-forget kind of deal. The non-exhaustive list of things that need to be covered: a) When users of JDK 11 are reporting bugs, somebody needs to take a look at them. Indeed, you need to have somebody interested in JDK 11 in addition to the latest release; b) When related bugs in later releases get discovered, somebody needs to track them and backport them to JDK 11; c) When follow-up JDK 11 backports with bugfixes come, someone would need to look how to adapt them properly without breaking stuff; Unless somebody with relevant G1 development experience steps in and makes the above possible, I'd be skeptical about backporting G1 features. Knowing the gist of Oracle's release cadence POV, I don't believe we would get Oracle's G1 team buy-in for this. I cannot say Jelastic is experienced in this kind of role. I have hopes for Alibaba, but we cannot count on that until they explicitly agree to above. Bottom-line: it is not about the technical feasibility of the backport and initial testing -- that one is doable and pretty clear. What happens next is where the problem is. -- Thanks, -Aleksey From goetz.lindenmaier at sap.com Tue Apr 7 13:51:31 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 7 Apr 2020 13:51:31 +0000 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> <510b4e9a-d3e8-4b35-5183-47d5c029668c@redhat.com> Message-ID: Hi, I would like to share our point of view as team supplying the VMs used at SAP (not as maintainer of 11u). We would appreciate if this change came to 11u. It reduces the pressure on memory in the default configuration. This is an important issue to us. We like to see SAP software lifted from 8 to 11. Any argument to go to 11 helps here. 17 will only be released within 17 months, and until it finds adoption will take even longer. So improving the performance of the default configuration of 11 is really helpful. I understand the stability concerns. We are doing support for Java for roughly 15 years now. But I think this is a rather small change, only a few 100 lines! http://hg.openjdk.java.net/jdk/jdk/rev/f94c7929a44b Thus, the risk of this change cannot be compared with downporting a whole GC algorithm, the graal compiler or similar. We should not be misled by this being a JEP. Also, we as part of the 11u maintenance team will take our part to address upcoming issues with this change. Wrt. to testing, we would volunteer to test the required changes in our infrastructure and push it to SapMachine before they are brought to the OpenJDK 11u-dev repository. It could run productive with SapMachine for one update or so to collect feedback. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Rodrigo Bruno > Sent: Tuesday, April 7, 2020 1:42 PM > To: Andrew Haley > Cc: jdk-updates-dev ; rs > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > Memory from G1 > > Hi everyone, > > I globally agree with most of the discussion so far. > > Just trying to answer Gil's question on why we want this in JDK11u; I think > the main reason is that JDK11 is the current LST and the next one is still > >1year away. IMHO and experience, people in the Java community tend to > extensively rely on libraries and code that was not developed by > themselves. A great percentage of this code is not updated regularly to > keep up with non-LTS JDK releases and trying to move your project to a more > recent JDK release is a huge headache, especially in large projects with > 100s of dependencies. I've been in several projects where people are > reluctant to deploy production code in non-LTS JDKs... > > Andrew also mentioned the problem of testing experimental releases. I > think > here this is not a problem since we have two industry companies advocating > for this patch. Would Alibaba and Jelastic be available to deploy an > experimental version of JDK11u with this JEP? If so, maybe after a couple > of months there would be enough convincing evidence that this JEP won't > break anything significant. > > cheers, > rodrigo > > > Andrew Haley escreveu no dia ter?a, 7/04/2020 ?(s) > 12:51: > > > On 4/7/20 11:30 AM, Liang Mao wrote: > > > > > But if a feature has been tested through several releases(the JEP > > > and related bug fixes were pushed in JDK12/13), we are able to take > > > it into the consideration as a stable change. Anyway, do you think > > > we shall get some more technical comments from Thomas before make > > > the decision? > > > > I think we should keep talking. As far as I'm concerned this is still > > a live issue for discussion, but I made my points in > > > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > April/002977.html > > > > -- > > 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 > > > > > > -- > rodrigo-bruno.github.io From neugens at redhat.com Tue Apr 7 14:05:13 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 7 Apr 2020 16:05:13 +0200 Subject: FYI: request backports for 8239091, 8238942, 8224109 and 8214481 In-Reply-To: References: Message-ID: On Mon, Apr 6, 2020 at 9:27 PM Mario Torre wrote: > > On Mon, Apr 6, 2020 at 9:05 PM Langer, Christoph > wrote: > > > > Hi Mario, > > > > thanks for being cautious here. > > Hi Christoph, > > > Looking at this change, however, it's hard to believe that it can have any functional effect, unless you had set your FREETYPE_PROPERTIES variable to the exact string "interpreter-version". > > Ouch, I pasted the wrong bug ID before!! The patch I want to retire is > this (and sorry for the noise!): > > https://bugs.openjdk.java.net/browse/JDK-8214481 > > While I still want to keep the others: 8224109, 8238942 and 8239091. > > The FT_LOAD_NO_HINTING change is the problem for me. In some fonts and > with fractional metrics enabled it causes the rendering to be very > blurry. I do remember this to be the case in 8 or 7 at some point and > then it was finally fixed, so this change is a regression for me, this > is most likely tied to freetype but I don't understand why it's not > happening in 14+ with all the same code and compiled the same way, so > clearly I'm missing a patch somewhere and I would like to figure out > which one. > > > Shall I withdraw the approval flags or do you just need a bit of time for further testing? > > Yes, I think I'll take another day or two to test. I have built the > jdk with the default settings. I thought that the FREETYPE_PROPERTIES > thing was responsible at first but I didn't change this and is not set > in my build, but I'll need to do some more testing. I do remember we > had a couple of changes related to this as well as changes specific to > fractional metrics, but the code is actually the same at this stage > between 15-dev and 11-dev. I think this is a regression in 15-dev too. I'll follow up on the 2d-dev about this. For now I confirm to backport only 8224109, 8238942 and 8239091 then. Should I remove the jdk11u-fix-request flag? Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From maoliang.ml at alibaba-inc.com Wed Apr 8 05:24:17 2020 From: maoliang.ml at alibaba-inc.com (Liang Mao) Date: Wed, 08 Apr 2020 13:24:17 +0800 Subject: =?UTF-8?B?WzExdV0gQmFja3BvcnQgSkVQIDM0NiA6IFByb21wdGx5IFJldHVybiBVbnVzZWQgQ29tbWl0?= =?UTF-8?B?dGVkIE1lbW9yeSBmcm9tIEcx?= Message-ID: Hi, I need to answer some decent questions from Gil and Andrew first. > - Are there any indications that Oracle is backporting this into their Oracle JDK 11? IMHO, I don't think we have to wait until Oracle has backported any attractive features. The community can make some differences since we have some very experienced experts like you and others from other companies beside Oracle who can provide very good advices. > - Do we have input from the GC team on the complexity and potential tie-in or dependence > [explicit or implied] of this JEP implementation on other post-11 G1 improvements, > changes, assumptions, or invariant modifications? I have done the initial analysis and code merge. There are few dependences which are quite safe. But we need G1 team's review after maintainer's pre-approval. > - What level of extensive review by GC experts and exhaustive GC stress-testing are > we willing to put in to gain confidence that this will not regress the stability of 11u? This answer still needs the G1 team's review after pre-approval. BTW, the main feature is guarded by a seperate option G1PeriodicGCInterval and won't affect the default flow. > A question for you. Do you believe that there should be a version of JDK 11 which does not change very much, except for occasional fixes for remaining bugs? I'm afaid I don't think so. Actually JDK11u is not so widely used and most of users are still using JDK8u. Migrating JDK versions is so painfull to them that most of users will not catch up latest versions for new features. An LTS version with evolved updates is always the best choice. To us JDK developers, both JDK11u and JDK12u are mature releases. We are trying to merge a mature feature in a mature release to another mature release. To most of users, JDK11u seems not mature enough until everybody uses it. If I was the user as I decided to take the risk to migrate from JDK8u to JDK11u, why cannot I get more attractive features? I have read some mails of your philosophy as a maintainer and I appreciate your thinking: "One other thing: we must remember that people have a choice. They are not prisoners to Java. If we withhold backports in order to persuade them to jump to later JDK releases we're forcing them to do work, and some of them might just port to some other platform altogether." Thank Goetz for your insterest and voluntary in this. We Alibaba will surely take the responsibility of maintainence as well. Our internal customers already tried this and got very good result. Hope to see your findings in near future. Beside the feature implementation changeset, there're several dependency changes and bug fixes. Here is the initial analysis. https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html Thanks, Liang ------------------------------------------------------------------ From:Lindenmaier, Goetz Send Time:2020 Apr. 7 (Tue.) 21:54 To:Rodrigo Bruno ; Andrew Haley Cc:jdk-updates-dev ; rs Subject:RE: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 Hi, I would like to share our point of view as team supplying the VMs used at SAP (not as maintainer of 11u). We would appreciate if this change came to 11u. It reduces the pressure on memory in the default configuration. This is an important issue to us. We like to see SAP software lifted from 8 to 11. Any argument to go to 11 helps here. 17 will only be released within 17 months, and until it finds adoption will take even longer. So improving the performance of the default configuration of 11 is really helpful. I understand the stability concerns. We are doing support for Java for roughly 15 years now. But I think this is a rather small change, only a few 100 lines! http://hg.openjdk.java.net/jdk/jdk/rev/f94c7929a44b Thus, the risk of this change cannot be compared with downporting a whole GC algorithm, the graal compiler or similar. We should not be misled by this being a JEP. Also, we as part of the 11u maintenance team will take our part to address upcoming issues with this change. Wrt. to testing, we would volunteer to test the required changes in our infrastructure and push it to SapMachine before they are brought to the OpenJDK 11u-dev repository. It could run productive with SapMachine for one update or so to collect feedback. Best regards, Goetz. > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Rodrigo Bruno > Sent: Tuesday, April 7, 2020 1:42 PM > To: Andrew Haley > Cc: jdk-updates-dev ; rs > > Subject: Re: [11u] Backport JEP 346 : Promptly Return Unused Committed > Memory from G1 > > Hi everyone, > > I globally agree with most of the discussion so far. > > Just trying to answer Gil's question on why we want this in JDK11u; I think > the main reason is that JDK11 is the current LST and the next one is still > >1year away. IMHO and experience, people in the Java community tend to > extensively rely on libraries and code that was not developed by > themselves. A great percentage of this code is not updated regularly to > keep up with non-LTS JDK releases and trying to move your project to a more > recent JDK release is a huge headache, especially in large projects with > 100s of dependencies. I've been in several projects where people are > reluctant to deploy production code in non-LTS JDKs... > > Andrew also mentioned the problem of testing experimental releases. I > think > here this is not a problem since we have two industry companies advocating > for this patch. Would Alibaba and Jelastic be available to deploy an > experimental version of JDK11u with this JEP? If so, maybe after a couple > of months there would be enough convincing evidence that this JEP won't > break anything significant. > > cheers, > rodrigo > > > Andrew Haley escreveu no dia ter?a, 7/04/2020 ?(s) > 12:51: > > > On 4/7/20 11:30 AM, Liang Mao wrote: > > > > > But if a feature has been tested through several releases(the JEP > > > and related bug fixes were pushed in JDK12/13), we are able to take > > > it into the consideration as a stable change. Anyway, do you think > > > we shall get some more technical comments from Thomas before make > > > the decision? > > > > I think we should keep talking. As far as I'm concerned this is still > > a live issue for discussion, but I made my points in > > > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > April/002977.html > > > > -- > > 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 > > > > > > -- > rodrigo-bruno.github.io From rs at jelastic.com Wed Apr 8 09:09:51 2020 From: rs at jelastic.com (Ruslan Synytsky) Date: Wed, 8 Apr 2020 12:09:51 +0300 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 Message-ID: *> Goetz: I understand the stability concerns. We are doing support for Java for roughly 15 years now. But I think this is a rather small change, only a few 100 lines! http://hg.openjdk.java.net/jdk/jdk/rev/f94c7929a44b . > Thus, the risk of this change cannot be compared with downporting a whole GC algorithm, the graal compiler or similar. We should not be misled by this being a JEP. * *> Liang: BTW, the main feature is guarded by a separate option G1PeriodicGCInterval and won't affect the default flow.* Good points. As a summary, it's not a large code base adjustment which does not change the default behaviour of JVM. *> **Andrew: **We'd then put it out and get people to test it in real applications, then very carefully merge it back into mainline. The problem with this plan, of course, is that it's very hard in practice to get people to use experimental releases in production! This is the perennial problem with Beta testing, as we all know.* *> Goetz: we would volunteer to test the required changes in our infrastructure and push it to SapMachine before they are brought to the OpenJDK 11u-dev repository. It could run productive with SapMachine for one update or so to collect feedback.* >From Jelastic side, we can run full set of our functional, integration and load tests related to provisioning and scaling of Java stacks. *> **Andrew: **A question for you. Do you believe that there should be a version of **JDK 11 which does not change very much, except for occasional fixes **for remaining bugs?* > *Liang: Actually JDK11u is not so widely used and most of users are still using JDK8u. Migrating JDK versions is so painful to them that most of users will not catch up latest versions for new features. An LTS version with evolved updates is always the best choice. * While I expected that migration to the new releases will be faster, we notice the same issue described by Liang among our Java end users. *> Alexey: **Bottom-line: it is not about the technical feasibility of the backport and initial testing -- that one is doable and pretty clear. What happens next is where the problem is.* *> Goetz: Also, we as part of the 11u maintenance team will take our part to address upcoming issues with this change.* *> Liang: We Alibaba will surely take the responsibility of maintenance as well.* Is this commitment enough for making steps forward? Are there any other unspoken or uncovered important questions? Thanks -- Ruslan Synytsky CEO @ Jelastic Multi-Cloud PaaS From shade at redhat.com Wed Apr 8 11:40:54 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 8 Apr 2020 13:40:54 +0200 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: Message-ID: <1d97a8a3-18a2-46c3-28b7-73ce13ee47cb@redhat.com> On 4/8/20 11:09 AM, Ruslan Synytsky wrote: > /> _Alexey_:?//Bottom-line: it is not about the technical feasibility of the backport and initial > testing -- that one is doable and pretty clear. What happens next is where the problem is./ > />?_Goetz_:?Also, we as part of the 11u maintenance team will take our part to address upcoming > issues with this change./ > />?_Liang_:?We Alibaba will surely take the responsibility of maintenance?as well./ > > Is this commitment enough for making steps forward? Yes, it is enough for me! -- Thanks, -Aleksey From akashche at redhat.com Wed Apr 8 15:08:28 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 8 Apr 2020 16:08:28 +0100 Subject: [13u, 11u] RFA: 8236996: Incorrect Roboto font rendering on Windows with subpixel antialiasing Message-ID: <0ade9a93-33e5-cacc-dedc-3a4b6d8b1e12@redhat.com> Hi, Just FYI, I was working on backporting JDK-8236996 to 13, 11 and 8 and added Fix Request labels for 13 and 11 to it: https://bugs.openjdk.java.net/browse/JDK-8236996 I understand that separate approval emails are not necessary (patch applies cleanly), just this issue is currently not included into Oracle backports and may be overlooked because of that. -- -Alex From martijnverburg at gmail.com Wed Apr 8 20:20:23 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 8 Apr 2020 21:20:23 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: <1d97a8a3-18a2-46c3-28b7-73ce13ee47cb@redhat.com> References: <1d97a8a3-18a2-46c3-28b7-73ce13ee47cb@redhat.com> Message-ID: Hi all, To add to this, MSFT's OpenJDK engineering group would also be willing to help out on maintaining this patch, we believe it will benefit our customers. In the interests of setting expectations, we'd like to be clear that: - We do not currently have the test infrastructure set up to do any heavy lifting on testing or performance measurements today (this will change in the coming quarters!). - We have limited expertise in G1 development so our reviews of the code changes would provide minimal quality assurances. - We do not have any experience in monitoring changes in newer releases to find bugs, etc that need to be backported for this feature if they happen - but we're very willing to learn! - We do however have people power (experienced JVM engineers) that we could use to help diagnose/work on new bugs and help backport bug fixes for this patch. Either way, very happy to abide by the decision of the project lead on this one :-). Cheers, Martijn On Wed, 8 Apr 2020 at 12:41, Aleksey Shipilev wrote: > On 4/8/20 11:09 AM, Ruslan Synytsky wrote: > > /> _Alexey_: //Bottom-line: it is not about the technical feasibility of > the backport and initial > > testing -- that one is doable and pretty clear. What happens next is > where the problem is./ > > /> _Goetz_: Also, we as part of the 11u maintenance team will take our > part to address upcoming > > issues with this change./ > > /> _Liang_: We Alibaba will surely take the responsibility of > maintenance as well./ > > > > Is this commitment enough for making steps forward? > > Yes, it is enough for me! > > -- > Thanks, > -Aleksey > > From matthias.baesken at sap.com Thu Apr 9 08:57:14 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Apr 2020 08:57:14 +0000 Subject: [11u] RFR: 8238721: Add failing client jtreg tests to the Problem List In-Reply-To: References: Message-ID: Hi Christoph, looks good to me ! Best regards, Matthias From: Langer, Christoph Sent: Sonntag, 5. April 2020 16:38 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8238721: Add failing client jtreg tests to the Problem List Hi, please review this backport of some test exclusions in the awt/swing area. This is 11.0.8-oracle and we?re seeing some of the test errors on our newer MacOS and Linux test boxes as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8238721 Original change: https://hg.openjdk.java.net/jdk/jdk/rev/915d0c063009 Webrev for resolved change: http://cr.openjdk.java.net/~clanger/webrevs/8238721.11u/ The only notable difference to the original change is that for java/awt/Modal/FileDialog/FileDialogDocModal7Test.java the backport changes the referenced bug to 7186009. In jdk11u-dev, 8198664 was referenced but I believe 7186009 is more current, as of head. Thanks Christoph From matthias.baesken at sap.com Thu Apr 9 09:31:38 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 9 Apr 2020 09:31:38 +0000 Subject: [11u] RFR: 8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly In-Reply-To: References: Message-ID: Hi Christoph, looks good to me ! From: Langer, Christoph Sent: Samstag, 4. April 2020 12:30 To: jdk-updates-dev at openjdk.java.net Subject: [11u] RFR: 8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly Hi, please review this backport of a test change to 11u. We see a failure in test nsk/jvmti/scenarios/sampling/SP06/sp06t001 once in a while in our regression testing. The related bug JDK-8053911 claims it has been fixed by JDK-8051349, so I looked into backporting it to reduce testing noise. The original patch does not apply for the .cpp files. In 11 these are still .c files and the constructs at the patched locations look different. I made the patch fit to the c code in 11. Bug: https://bugs.openjdk.java.net/browse/JDK-8051349 Original change: http://hg.openjdk.java.net/jdk/jdk/rev/3bc260237317 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8051349.11u/ Thanks Christoph From goetz.lindenmaier at sap.com Thu Apr 9 09:55:31 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 9 Apr 2020 09:55:31 +0000 Subject: [11u] RFR(M): 8234728: Some security tests should support TLSv1.3 In-Reply-To: References: Message-ID: Hi, Thanks! To double-check I ran it through our tests once more, all green. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Monday, April 6, 2020 9:08 PM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR(M): 8234728: Some security tests should support > TLSv1.3 > > Hi Goetz, > > looks good now. Feel free to push, unless this update would break the test > results ?? > > Best regards > Christoph > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Montag, 6. April 2020 18:35 > > To: Lindenmaier, Goetz ; Langer, Christoph > > ; jdk-updates-dev at openjdk.java.net > > Subject: RE: [11u] RFR(M): 8234728: Some security tests should support > > TLSv1.3 > > > > > > For > > test/jdk/sun/security/util/HostnameMatcher/NullHostnameCheck.java > > > > I have a question: Why don't you take the hunk to use the passed > > protocol > > > >for clientCtx > > (https://hg.openjdk.java.net/jdk/jdk/rev/d6a38e8f7389#l6.35) ? I > > > > think it would fit. > > > The tests differ a lot. I edited the test in 11 to use the protocol passed in > > > Wherever needed. The test in 11 does not deal with the clientCtx, so > > > There was no place for that. > > > > Oh no, you are right, I missed it. All nonsense above ... here better webrev: > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests-jdk11/03/ > > > > Sorry, > > Goetz > > > > > > > > In > test/jdk/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java, > > I > > > > would not uncomment the lines of TLS_CHACHA20_POLY1305_SHA256 > > and > > > > TLS_CHACHA20_POLY1305_SHA256 but rather drop them completely. > > > These > > > > suites don't exist in 11 and for CipherSuitesInOrder.java we also don't > > keep > > > > them commented. > > > Ok, I will remove them. > > > > > > New webrev: > > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests- > jdk11/02/ > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > > > > Best regards > > > > Christoph > > > > > > > > > > > > > -----Original Message----- > > > > > From: jdk-updates-dev bounces at openjdk.java.net> > > > On > > > > > Behalf Of Lindenmaier, Goetz > > > > > Sent: Freitag, 3. April 2020 13:26 > > > > > To: jdk-updates-dev at openjdk.java.net > > > > > Subject: [CAUTION] [11u] RFR(M): 8234728: Some security tests > should > > > > > support TLSv1.3 > > > > > > > > > > Hi, > > > > > > > > > > I would like to downport this for parity with 11.0.8-oracle. > > > > > > > > > > http://cr.openjdk.java.net/~goetz/wr20/8234728-security_tests- > > > > > jdk11/webrev/ > > > > > > > > > > Although this change claims it is a test fix, it touches > > > > > java.base. It fixes some type-os there. > > > > > Some of the comments fixed are not in CipherSuite.java in > > > > > 11u, so the patch did not apply. I had to skip these. > > > > > > > > > > Also, the change did not cleanly apply to the the test > > > > > NullHostnameCheck.java > > > > > because "8228967: Trust/Key store and SSL context utilities for tests" > is > > > not > > > > > in 11. I adapted it. The TLS level is now passed to the test. > > > > > > > > > > The change makes TLSCipherSuitesOrder.java fail. > > > > > First, it looks for a Cipher Suite not in 11. I removed this. > > > > > Second, it depends on a change by "8171279: Support X25519 and > > > > > X448 in TLS". This is a big change and only a single function > > > > > call is needed. I added only the required changes of 8171279 to > > > > > TLSSocketTemplate.java in this change. > > > > > > > > > > I also changed CipherSuitesInOrder.java so that it passes. > > > > > I kept the old list of supportedCipherSuites, and > > > > > added TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. > > > > > > > > > > Please review. > > > > > > > > > > Original change: > > > > > https://bugs.openjdk.java.net/browse/JDK-8234728 > > > > > https://hg.openjdk.java.net/jdk/jdk14/rev/fa82151f29c4 From goetz.lindenmaier at sap.com Thu Apr 9 09:57:42 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 9 Apr 2020 09:57:42 +0000 Subject: [11u] RFR(S): 8235874: The ordering of Cipher Suites is not maintained provided through jdk.tls.client.cipherSuites and jdk.tls.server.cipherSuites system property. In-Reply-To: References: Message-ID: Thnaks! Best regards, Goetz > -----Original Message----- > From: Langer, Christoph > Sent: Monday, April 6, 2020 7:58 AM > To: Lindenmaier, Goetz ; jdk-updates- > dev at openjdk.java.net > Subject: RE: [11u] RFR(S): 8235874: The ordering of Cipher Suites is not > maintained provided through jdk.tls.client.cipherSuites and > jdk.tls.server.cipherSuites system property. > > Hi Goetz, > > this looks good. > > Best regards > Christoph > > > -----Original Message----- > > From: jdk-updates-dev On > > Behalf Of Lindenmaier, Goetz > > Sent: Freitag, 3. April 2020 16:15 > > To: jdk-updates-dev at openjdk.java.net > > Subject: [CAUTION] [11u] RFR(S): 8235874: The ordering of Cipher Suites is > > not maintained provided through jdk.tls.client.cipherSuites and > > jdk.tls.server.cipherSuites system property. > > > > Hi, > > > > I would like to downport this for parity with 11.0.8-oracle. > > > > I had to remove one cipher from the test because that is > > Not supported by 11: > > I had to remove TLS_CHACHA20_POLY1305_SHA256 > > http://cr.openjdk.java.net/~goetz/wr20/8235874-CipherSuite_ordering- > > jdk11/01/ > > > > original change: > > https://bugs.openjdk.java.net/browse/JDK-8235874 > > https://hg.openjdk.java.net/jdk/jdk14/rev/d821eb811ca8 > > > > Best regards, > > Goetz. From aph at redhat.com Thu Apr 9 10:18:17 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Apr 2020 11:18:17 +0100 Subject: [11u] Backport JEP 346 : Promptly Return Unused Committed Memory from G1 In-Reply-To: References: <60de85df-6bc0-4822-91b8-d7b87f6a4810.maoliang.ml@alibaba-inc.com> <510b4e9a-d3e8-4b35-5183-47d5c029668c@redhat.com> Message-ID: <629f0a97-62f3-14e9-2daf-3bdc3a9d1a6a@redhat.com> On 4/7/20 2:51 PM, Lindenmaier, Goetz wrote: > I would like to share our point of view as team supplying > the VMs used at SAP (not as maintainer of 11u). > > We would appreciate if this change came to 11u. > It reduces the pressure on memory in the default > configuration. This is an important issue to us. > > We like to see SAP software lifted from 8 to 11. Any argument to go > to 11 helps here. 17 will only be released within 17 months, and until > it finds adoption will take even longer. So improving the performance > of the default configuration of 11 is really helpful. Sure. The issue at base here is that it requires a determination of what kind of thing JDK 11 is. For example, JDK 8 is a stable, long-term release; it is clear to me that a change like this would not be appropriate for JDK 8. So, when will JDK 11 be a stable, long-term release? By your logic above, perhaps not until JDK 17 is released, and perhaps not until it has stabilized for a release cycle. Or perhaps we should think of it as a sliding scale, where JDK 11 becomes more and more stable over time, and the back pressure against changes becomes gradually stronger. But it's very hard to turn that into an understandable, let alone enforceable, policy. When I took up the job of project lead, I knew that the pressure to accept feature backports would be very strong, and that it would take all of my moral fibre to resist it. I know that, as a group, developers tend to want features, and so do their managers. But the more we do that, the more we risk an update crashing services in production. Having fixed a few hard-to-find GC bugs, I know that serious problems can be undetected for years. Remember this? https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-June/026193.html That serious bug languished from 2005 until I fixed it last year. I'm sure that's not a record, either. It was an example of the kind of mistake that is made by serious, expert, concurrent GC developers, the best people in the business. How many mistakes of that kind are there in the patch we're proposing to back-port? I don't know, and I doubt that you do either. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Thu Apr 9 12:12:23 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 09 Apr 2020 14:12:23 +0200 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u In-Reply-To: References: Message-ID: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> Hi Christoph, On Sat, 2020-04-04 at 12:23 +0000, Langer, Christoph wrote: > Hi, > > please review this partial backport of JDK-4947890 [0] to OpenJDK > 11u. > > I'm currently working on backporting 8232080: jlink plugins for > vendor information and command-line options [1]. That patch adds a > jlink plugin for setting customized values for system properties > java.vendor.version, java.vendor.url and java.vendor.url.bug in a > jlinked runtime image by modifying the bytecode of class > java.lang.VersionProps. Amongst other things, JDK-4947890 created the > foundation for this patch by moving the initialization of > java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. > Before, it was initialized in libjava's System.c. While it's not > desirable to backport JDK-4947890 as a whole to 11u, I'd like to > bring in the part that moves initialization of java.vendor, > java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. > Since it's only a part of the original JDK-4947890, I created the new > JDK11 specific bug JDK- 8242154. OK. > Bug: https://bugs.openjdk.java.net/browse/JDK-8242154 > Original change of JDK-4947890: http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242154.11u.0/ in System.c: - PUTPROP(props, "java.version", VERSION_SHORT); - PUTPROP(props, "java.vendor", VENDOR); - PUTPROP(props, "java.vendor.url", VENDOR_URL); - PUTPROP(props, "java.vendor.url.bug", VENDOR_URL_BUG); - Aren't you removing "PUTPROP(props, "java.version", VERSION_SHORT)"; too eagerly here? Thoughts? Thanks, Severin > [0] https://bugs.openjdk.java.net/browse/JDK-4947890 > [1] https://bugs.openjdk.java.net/browse/JDK-8232080 > From christoph.langer at sap.com Thu Apr 9 20:38:59 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 9 Apr 2020 20:38:59 +0000 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u In-Reply-To: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> References: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> Message-ID: Hi Severin, thanks for having a look at this. > -----Original Message----- > From: Severin Gehwolf > Sent: Donnerstag, 9. April 2020 14:12 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK > 11u > > Hi Christoph, > > On Sat, 2020-04-04 at 12:23 +0000, Langer, Christoph wrote: > > Hi, > > > > please review this partial backport of JDK-4947890 [0] to OpenJDK > > 11u. > > > > I'm currently working on backporting 8232080: jlink plugins for > > vendor information and command-line options [1]. That patch adds a > > jlink plugin for setting customized values for system properties > > java.vendor.version, java.vendor.url and java.vendor.url.bug in a > > jlinked runtime image by modifying the bytecode of class > > java.lang.VersionProps. Amongst other things, JDK-4947890 created the > > foundation for this patch by moving the initialization of > > java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. > > Before, it was initialized in libjava's System.c. While it's not > > desirable to backport JDK-4947890 as a whole to 11u, I'd like to > > bring in the part that moves initialization of java.vendor, > > java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. > > Since it's only a part of the original JDK-4947890, I created the new > > JDK11 specific bug JDK- 8242154. > > OK. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242154 > > Original change of JDK-4947890: > http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242154.11u.0/ > > in System.c: > > - PUTPROP(props, "java.version", VERSION_SHORT); > - PUTPROP(props, "java.vendor", VENDOR); > - PUTPROP(props, "java.vendor.url", VENDOR_URL); > - PUTPROP(props, "java.vendor.url.bug", VENDOR_URL_BUG); > - > > Aren't you removing "PUTPROP(props, "java.version", VERSION_SHORT)"; > too eagerly here? I don't think so. The removed statements put the named properties into a Properties object that is handed down to private static native method java.lang.System:: initProperties(Properties props). This method is actually called twice. Once in System:: initPhase1. But after it's called there, (line 1948), VersionProps.init() is invoked as well (line 1968). Then, the other occasion is System::setProperties(Properties props), in case the passed props object is null. And for that case, I added the call to VersionProps.init() right after initProperties (line 776 of System.java). The only drawback of that could be that now a few properties could be initialized to a value which weren't before when calling System.setProperties(null); That would affect "java.version.date", "java.runtime.version", "java.runtime.name" and "java.vendor.version"; But does that matter? How likely is it that somebody relies on that behavior? Best regards Christoph From manc at google.com Fri Apr 10 00:12:34 2020 From: manc at google.com (Man Cao) Date: Thu, 9 Apr 2020 17:12:34 -0700 Subject: Help requested on pushing 8241556 to 11u-dev Message-ID: Hi, Could anyone help me push this change to 11u-dev? https://cr.openjdk.java.net/~manc/8241556/webrev.01/jdk11uDev.changeset Original bug: https://bugs.openjdk.java.net/browse/JDK-8241556 Original change: https://hg.openjdk.java.net/jdk/jdk/raw-rev/2502db745df8 The only conflicts are the copyright years in the header comment. I have run all tier1 tests and no new failure on my x86_64 Linux machine. (I'm a Committer on the jdk project, but not on the jdk-updates project yet.) -Man From jianglizhou at google.com Fri Apr 10 00:17:33 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 9 Apr 2020 17:17:33 -0700 Subject: Help requested on pushing 8241556 to 11u-dev In-Reply-To: References: Message-ID: Hi Man, I'll help you. Best, Jiangli On Thu, Apr 9, 2020 at 5:15 PM Man Cao wrote: > > Hi, > > Could anyone help me push this change to 11u-dev? > https://cr.openjdk.java.net/~manc/8241556/webrev.01/jdk11uDev.changeset > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8241556 > Original change: https://hg.openjdk.java.net/jdk/jdk/raw-rev/2502db745df8 > > The only conflicts are the copyright years in the header comment. > I have run all tier1 tests and no new failure on my x86_64 Linux machine. > (I'm a Committer on the jdk project, but not on the jdk-updates project > yet.) > > -Man From manc at google.com Fri Apr 10 00:40:17 2020 From: manc at google.com (Man Cao) Date: Thu, 9 Apr 2020 17:40:17 -0700 Subject: Help requested on pushing 8241556 to 11u-dev In-Reply-To: References: Message-ID: Thanks, Jiangli! -Man On Thu, Apr 9, 2020 at 5:17 PM Jiangli Zhou wrote: > Hi Man, > > I'll help you. > > Best, > Jiangli > > On Thu, Apr 9, 2020 at 5:15 PM Man Cao wrote: > > > > Hi, > > > > Could anyone help me push this change to 11u-dev? > > https://cr.openjdk.java.net/~manc/8241556/webrev.01/jdk11uDev.changeset > > > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8241556 > > Original change: > https://hg.openjdk.java.net/jdk/jdk/raw-rev/2502db745df8 > > > > The only conflicts are the copyright years in the header comment. > > I have run all tier1 tests and no new failure on my x86_64 Linux machine. > > (I'm a Committer on the jdk project, but not on the jdk-updates project > > yet.) > > > > -Man > From sgehwolf at redhat.com Fri Apr 10 13:13:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 10 Apr 2020 15:13:42 +0200 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u In-Reply-To: References: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> Message-ID: Hi Christoph, On Thu, 2020-04-09 at 20:38 +0000, Langer, Christoph wrote: > Hi Severin, > > thanks for having a look at this. > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Donnerstag, 9. April 2020 14:12 > > To: Langer, Christoph ; jdk-updates- > > dev at openjdk.java.net > > Subject: Re: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK > > 11u > > > > Hi Christoph, > > > > On Sat, 2020-04-04 at 12:23 +0000, Langer, Christoph wrote: > > > Hi, > > > > > > please review this partial backport of JDK-4947890 [0] to OpenJDK > > > 11u. > > > > > > I'm currently working on backporting 8232080: jlink plugins for > > > vendor information and command-line options [1]. That patch adds a > > > jlink plugin for setting customized values for system properties > > > java.vendor.version, java.vendor.url and java.vendor.url.bug in a > > > jlinked runtime image by modifying the bytecode of class > > > java.lang.VersionProps. Amongst other things, JDK-4947890 created the > > > foundation for this patch by moving the initialization of > > > java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. > > > Before, it was initialized in libjava's System.c. While it's not > > > desirable to backport JDK-4947890 as a whole to 11u, I'd like to > > > bring in the part that moves initialization of java.vendor, > > > java.vendor.url and java.vendor.url.bug to java.lang.VersionProps. > > > Since it's only a part of the original JDK-4947890, I created the new > > > JDK11 specific bug JDK- 8242154. > > > > OK. > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8242154 > > > Original change of JDK-4947890: > > http://hg.openjdk.java.net/jdk/jdk/rev/0bdbf854472f > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8242154.11u.0/ > > > > in System.c: > > > > - PUTPROP(props, "java.version", VERSION_SHORT); > > - PUTPROP(props, "java.vendor", VENDOR); > > - PUTPROP(props, "java.vendor.url", VENDOR_URL); > > - PUTPROP(props, "java.vendor.url.bug", VENDOR_URL_BUG); > > - > > > > Aren't you removing "PUTPROP(props, "java.version", VERSION_SHORT)"; > > too eagerly here? > > I don't think so. Well, my point was more about the following: For this partial backport it should be sufficient to only remove PUTPROP calls for *vendor* related properties. I.e. this isn't part of 4947890 while the others are. I agree it shouldn't matter from a functional perspective. It's just a bit confusing. Patch seems OK otherwise. Thanks, Severin > The removed statements put the named properties into a Properties > object that is handed down to private static native method > java.lang.System:: initProperties(Properties props). > This method is actually called twice. Once in System:: initPhase1. > But after it's called there, (line 1948), VersionProps.init() is > invoked as well (line 1968). > Then, the other occasion is System::setProperties(Properties props), > in case the passed props object is null. And for that case, I added > the call to VersionProps.init() right after initProperties (line 776 > of System.java). The only drawback of that could be that now a few > properties could be initialized to a value which weren't before when > calling System.setProperties(null); That would affect > "java.version.date", "java.runtime.version", "java.runtime.name" and > "java.vendor.version"; But does that matter? How likely is it that > somebody relies on that behavior? > > Best regards > Christoph > From rob.mckenna at oracle.com Fri Apr 10 13:24:14 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 10 Apr 2020 14:24:14 +0100 Subject: Last 14u commit that was merged into 14.0.1 CPU repository In-Reply-To: References: Message-ID: <20200410132414.GB1034@DESKTOP-JNNKIHU.localdomain> Apologies Christoph, I missed this mail. The latest pull from jdk14u took all changesets up to: changeset: 57617:c678e3151577 user: igerasim date: Mon Mar 02 22:57:20 2020 -0800 summary: 8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 -Rob On 24/03/20 19:35, Langer, Christoph wrote: > Hi Rob, > > can you please let the world know, which was the latest commit from jdk-updates/jdk14u that made it into the 14.0.1 CPU repository? > > Thanks > Christoph > From rob.mckenna at oracle.com Fri Apr 10 13:24:50 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 10 Apr 2020 14:24:50 +0100 Subject: Last 14u commit that was merged into 14.0.1 CPU repository In-Reply-To: <20200410132414.GB1034@DESKTOP-JNNKIHU.localdomain> References: <20200410132414.GB1034@DESKTOP-JNNKIHU.localdomain> Message-ID: <20200410132450.GC1034@DESKTOP-JNNKIHU.localdomain> (up to and including) -Rob On 10/04/20 14:24, Rob McKenna wrote: > Apologies Christoph, I missed this mail. > > The latest pull from jdk14u took all changesets up to: > > changeset: 57617:c678e3151577 > user: igerasim > date: Mon Mar 02 22:57:20 2020 -0800 > summary: 8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 > > -Rob > > On 24/03/20 19:35, Langer, Christoph wrote: > > Hi Rob, > > > > can you please let the world know, which was the latest commit from jdk-updates/jdk14u that made it into the 14.0.1 CPU repository? > > > > Thanks > > Christoph > > From sgehwolf at redhat.com Fri Apr 10 14:03:19 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 10 Apr 2020 16:03:19 +0200 Subject: [11u] RFR: 8232080: jlink plugins for vendor information and command-line options In-Reply-To: References: Message-ID: <0917d8fb8b78853e84cbb2405fe8d6f6ca5ad8d5.camel@redhat.com> Hi Christoph, On Sun, 2020-04-05 at 14:18 +0000, Langer, Christoph wrote: > Hi, > > now, please review the backport of JDK-8232080: jlink plugins for > vendor information and command-line options. It's part of Oracle's > 11.0.7 and contains valuable functionality for downstream vendors and > jlinkers. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232080 > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6c255334120d > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232080.11u.0/ This looks good to me. Nice work! > Its prerequisite is the backport of 8242154: Backport parts of JDK- > 4947890 to OpenJDK 11u which I posted yesterday [0]. > > With that change in place, I had to do the following: > - resolve src/hotspot/share/classfile/classLoader.cpp > - ignore src/hotspot/share/runtime/vmStructs.cpp, which does not apply > - resolve src/hotspot/share/utilities/vmError.cpp > - resolve src/java.base/share/classes/java/lang/VersionProps.java > - ignore src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java which does not apply Right. JDK-8217845 isn't in OpenJDK 11u. OK. > I furthermore changed the version information of ASM to ASM6 (instead > of ASM7) since that's the level in JDK11. But functionality-wise > that's no problem. Everything used is part of ASM6 as well. > > With this patch I plan to push backports of JDK-8233137, JDK-8233291 > and JDK-8234696 as they contain follow-up fixes. Please also consider JDK-8239557 in this batch. Thanks, Severin > Thanks > Christoph > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-April/002955.html > From suenaga at oss.nttdata.com Tue Apr 14 00:40:59 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 14 Apr 2020 09:40:59 +0900 Subject: [11u] RFA: 8242283: Can't start JVM when java home path includes non-ASCII character Message-ID: Hi all, Please approve this backport: JBS: https://bugs.openjdk.java.net/browse/JDK-8242283 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242283/11u/webrev.00/ original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/5f5876adb88c JVM fails to start on Windows with non-ASCII characters in the path if current regional format differs from the system locale. We need to convert char* to wchar_t* to support long path, so I used CP_THREAD_ACP in MultiByteToWideChar(). But we found CP_ACP works nicely rather than CP_THREAD_ACP. Using CP_THREAD_ACP was introduced in JDK-8240197 and JDK-8240725, however only JDK-8240197 has been backported to 11u. So I want to apply original bug to 11u partially. (it makes the change for HotSpot only) Thanks, Yasumasa From neugens at redhat.com Tue Apr 14 16:26:57 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 14 Apr 2020 18:26:57 +0200 Subject: Test repo to experiment with JFR Streaming API Message-ID: Hi Andrew and Christoph and all, Following the initial discussion on this same mailing list [1], I would like to request the creation of a staging repository so that the people who have interest in this backport can start experimenting with a possible implementation that is suitable for 11u. The original backport poses some challenges, for example it is adding some API in protected namespace, so we know we will need to request a careful CSR and we will likely need to explore what options we have that keep us compatible with the current 11 specification; this email serves a starting point for such discussions, especially regarding the pros and cons of this backport - in particular if there are concerns - and questions. Cheers, Mario [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002820.html -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From christoph.langer at sap.com Tue Apr 14 19:48:02 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Apr 2020 19:48:02 +0000 Subject: Last 14u commit that was merged into 14.0.1 CPU repository In-Reply-To: <20200410132450.GC1034@DESKTOP-JNNKIHU.localdomain> References: <20200410132414.GB1034@DESKTOP-JNNKIHU.localdomain> <20200410132450.GC1034@DESKTOP-JNNKIHU.localdomain> Message-ID: Hi Rob, thanks for that information. That still helps in pre-testing. Best regards Christoph > -----Original Message----- > From: Rob McKenna > Sent: Freitag, 10. April 2020 15:25 > To: Langer, Christoph > Cc: jdk-updates-dev at openjdk.java.net > Subject: Re: Last 14u commit that was merged into 14.0.1 CPU repository > > (up to and including) > > -Rob > > On 10/04/20 14:24, Rob McKenna wrote: > > Apologies Christoph, I missed this mail. > > > > The latest pull from jdk14u took all changesets up to: > > > > changeset: 57617:c678e3151577 > > user: igerasim > > date: Mon Mar 02 22:57:20 2020 -0800 > > summary: 8238452: Keytool generates wrong expiration date if validity is > set to 2050/01/01 > > > > -Rob > > > > On 24/03/20 19:35, Langer, Christoph wrote: > > > Hi Rob, > > > > > > can you please let the world know, which was the latest commit from jdk- > updates/jdk14u that made it into the 14.0.1 CPU repository? > > > > > > Thanks > > > Christoph > > > From gnu.andrew at redhat.com Tue Apr 14 19:56:34 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 20:56:34 +0100 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga Message-ID: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> Here are the remaining changes for the jdk11u repository: Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ Changes in jdk-11.0.7+10: - S8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation - S8189861: Refactor CacheFind - S8204551: Event descriptions are truncated in logs - S8210459: Add support for generating compile_commands.json - S8214534: Setting of THIS_FILE in the build is broken - S8217728: Speed up incremental rerun of "make hotspot" - S8219597: (bf) Heap buffer state changes could provoke unexpected exceptions - S8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build - S8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC - S8222264: Windows incremental build is broken with JDK-8217728 - S8223678: Add Visual Studio Code workspace generation support (for native code) - S8223898: Forward references to Nashorn - S8223904: Improve Nashorn matching - S8224541: Better mapping of serial ENUMs - S8224549: Less Blocking Array Queues - S8225603: Enhancement for big integers - S8226346: Build better binary builders - S8227467: Better class method invocations - S8227542: Manifest improved jar headers - S8229733: TLS message handling improvements - S8231415: Better signatures in XML - S8231785: Improved socket permissions - S8232424: More constrained algorithms - S8232581: Improve TLS verification - S8233250: Better X11 rendering - S8233383: Various minor fixes - S8233410: Better Build Scripting - S8234027: Better JCEKS key support - S8234408: Improve TLS session handling - S8234825: Better Headings for HTTP Servers - S8234841: Enhance buffering of byte buffers - S8235274: Enhance typing of methods - S8235691: Enhance TLS connectivity - S8236201: Better Scanner conversions - S8237879: make 4.3 breaks build - S8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap Note that some of these are backports from 11u-dev. The result is tagged 11.0.7+10 and 11.0.7-ga. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue Apr 14 20:01:27 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Apr 2020 20:01:27 +0000 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> Message-ID: Hi Andrew, these look good to me. Please push ?? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew John Hughes > Sent: Dienstag, 14. April 2020 21:57 > To: 'jdk-updates-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga > > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ > > Changes in jdk-11.0.7+10: > - S8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle > cross-compilation > - S8189861: Refactor CacheFind > - S8204551: Event descriptions are truncated in logs > - S8210459: Add support for generating compile_commands.json > - S8214534: Setting of THIS_FILE in the build is broken > - S8217728: Speed up incremental rerun of "make hotspot" > - S8219597: (bf) Heap buffer state changes could provoke unexpected > exceptions > - S8220613: java/util/Arrays/TimSortStackSize2.java times out with > fastdebug build > - S8221851: Use of THIS_FILE in hotspot invalidates precompiled header > on Linux/GCC > - S8222264: Windows incremental build is broken with JDK-8217728 > - S8223678: Add Visual Studio Code workspace generation support (for > native code) > - S8223898: Forward references to Nashorn > - S8223904: Improve Nashorn matching > - S8224541: Better mapping of serial ENUMs > - S8224549: Less Blocking Array Queues > - S8225603: Enhancement for big integers > - S8226346: Build better binary builders > - S8227467: Better class method invocations > - S8227542: Manifest improved jar headers > - S8229733: TLS message handling improvements > - S8231415: Better signatures in XML > - S8231785: Improved socket permissions > - S8232424: More constrained algorithms > - S8232581: Improve TLS verification > - S8233250: Better X11 rendering > - S8233383: Various minor fixes > - S8233410: Better Build Scripting > - S8234027: Better JCEKS key support > - S8234408: Improve TLS session handling > - S8234825: Better Headings for HTTP Servers > - S8234841: Enhance buffering of byte buffers > - S8235274: Enhance typing of methods > - S8235691: Enhance TLS connectivity > - S8236201: Better Scanner conversions > - S8237879: make 4.3 breaks build > - S8238960: linux-i586 builds are inconsistent as the newly build jdk > is not able to reserve enough space for object heap > > Note that some of these are backports from 11u-dev. > > The result is tagged 11.0.7+10 and 11.0.7-ga. > > Ok to push? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From shade at redhat.com Tue Apr 14 20:06:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Apr 2020 22:06:22 +0200 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> Message-ID: <4e0b23ad-fbf1-376b-5c3d-3d75df0cb2b0@redhat.com> On 4/14/20 9:56 PM, Andrew John Hughes wrote: > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ *) I believe at least some hunks here are not correct: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/doc/building.md.sdiff.html -- 11u still uses "linux-x64-normal-server-release". Otherwise looks fine. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From christoph.langer at sap.com Tue Apr 14 20:18:01 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Apr 2020 20:18:01 +0000 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u In-Reply-To: References: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> Message-ID: Hi Severin, > > > in System.c: > > > > > > - PUTPROP(props, "java.version", VERSION_SHORT); > > > - PUTPROP(props, "java.vendor", VENDOR); > > > - PUTPROP(props, "java.vendor.url", VENDOR_URL); > > > - PUTPROP(props, "java.vendor.url.bug", VENDOR_URL_BUG); > > > - > > > > > > Aren't you removing "PUTPROP(props, "java.version", > VERSION_SHORT)"; > > > too eagerly here? > > > > I don't think so. > > Well, my point was more about the following: For this partial backport > it should be sufficient to only remove PUTPROP calls for *vendor* > related properties. I.e. this isn't part of 4947890 while the others > are. I agree it shouldn't matter from a functional perspective. It's > just a bit confusing. Ah, I see. This part of the change was already done in an earlier fix to improve startup performance: JDK-8185496. Hm, I think as 8242154 is a carveout of JDK-4947890 anyway, I think it's ok to be included. I will, however, reference JDK-8185496 in the bug description of JDK-8242154, too. Ok with you? Thanks Christoph From gnu.andrew at redhat.com Tue Apr 14 20:33:14 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 21:33:14 +0100 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <4e0b23ad-fbf1-376b-5c3d-3d75df0cb2b0@redhat.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> <4e0b23ad-fbf1-376b-5c3d-3d75df0cb2b0@redhat.com> Message-ID: On 14/04/2020 21:06, Aleksey Shipilev wrote: > On 4/14/20 9:56 PM, Andrew John Hughes wrote: >> Here are the remaining changes for the jdk11u repository: >> >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ > > *) I believe at least some hunks here are not correct: > https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/doc/building.md.sdiff.html -- 11u still uses > "linux-x64-normal-server-release". > > Otherwise looks fine. > >> Ok to push? > > Yes, I think so. > Yes :-( I guess we'll have to patch that up in 11u-dev. Sorry about that. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Tue Apr 14 20:31:40 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 14 Apr 2020 21:31:40 +0100 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> Message-ID: On 14/04/2020 21:01, Langer, Christoph wrote: > Hi Andrew, > > these look good to me. Please push ?? > > Best regards > Christoph > > Thanks to yourself & Aleksey. Pushed. Do you want to handle the sync to 11u-dev or shall I? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From christoph.langer at sap.com Tue Apr 14 20:36:39 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Apr 2020 20:36:39 +0000 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> Message-ID: Hi Andrew, thanks for pushing. We'll handle the sync over to jdk11u-dev. Best regards Christoph > -----Original Message----- > From: Andrew John Hughes > Sent: Dienstag, 14. April 2020 22:32 > To: Langer, Christoph ; 'jdk-updates- > dev at openjdk.java.net' > Subject: Re: [RFR] [11u] 11.0.7+10 / 11.0.7-ga > > > > On 14/04/2020 21:01, Langer, Christoph wrote: > > Hi Andrew, > > > > these look good to me. Please push ?? > > > > Best regards > > Christoph > > > > > > Thanks to yourself & Aleksey. Pushed. > > Do you want to handle the sync to 11u-dev or shall I? > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew From yan at azul.com Wed Apr 15 07:15:17 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 15 Apr 2020 10:15:17 +0300 Subject: [RFR] [13u] 13.0.3+3 / 13.0.3-ga Message-ID: <66af94c3-fc79-24bf-9b17-20c0573c0314@azul.com> Hi all, after unembargo,there were the changes hold for jdk13u: JDK-8231785: Improved socket permissions JDK-8236201: Better Scanner conversions JDK-8235274: Enhance typing of methods JDK-8234841: Enhance buffering of byte buffers JDK-8234825: Better Headings for HTTP Servers JDK-8234027: Better JCEKS key support JDK-8225603: Enhancement for big integers JDK-8224541: Better mapping of serial ENUMs JDK-8233245: More adaptive sockets JDK-8234408: Improve TLS session handling JDK-8227542: Manifest improved jar headers JDK-8231415: Better signatures in XML JDK-8224549: Less Blocking Array Queues JDK-8232581: Improve TLS verification JDK-8229733: TLS message handling improvements JDK-8232424: More constrained algorithms JDK-8235691: Enhance TLS connectivity JDK-8233250: Better X11 rendering JDK-8223904: Improve Nashorn matching JDK-8223898: Forward references to Nashorn JDK-8227467: Better class method invocations JDK-8233410: Better Build Scripting JDK-8226346: Build better binary builders JDK-8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap For some reason I misunderstood the procedure and pushed them few hours ago: mea culpa! This set of changes is marked jdk-13.0.3+3. Is it OK to tag it jdk-13.0.3-ga and merge to jdk13u-dev? Thank you! --yan From shade at redhat.com Wed Apr 15 07:22:24 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 09:22:24 +0200 Subject: [RFR] [13u] 13.0.3+3 / 13.0.3-ga In-Reply-To: <66af94c3-fc79-24bf-9b17-20c0573c0314@azul.com> References: <66af94c3-fc79-24bf-9b17-20c0573c0314@azul.com> Message-ID: On 4/15/20 9:15 AM, Yuri Nesterenko wrote: > Is it OK to tag it jdk-13.0.3-ga and merge to jdk13u-dev? Yes, sure. -- Thanks, -Aleksey From yan at azul.com Wed Apr 15 07:32:09 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 15 Apr 2020 10:32:09 +0300 Subject: [RFR] [13u] 13.0.3+3 / 13.0.3-ga In-Reply-To: References: <66af94c3-fc79-24bf-9b17-20c0573c0314@azul.com> Message-ID: <576c4e9f-15e4-3180-4e5d-5bfaf4167531@azul.com> Thank you, Aleksey! On 15.04.2020 10:22, Aleksey Shipilev wrote: > On 4/15/20 9:15 AM, Yuri Nesterenko wrote: >> Is it OK to tag it jdk-13.0.3-ga and merge to jdk13u-dev? > > Yes, sure. > From doko at ubuntu.com Wed Apr 15 11:26:22 2020 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 15 Apr 2020 13:26:22 +0200 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> Message-ID: <970919ef-4357-f5da-04e0-a5678d70e61f@ubuntu.com> On 4/14/20 9:56 PM, Andrew John Hughes wrote: > Here are the remaining changes for the jdk11u repository: > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ compared to 11.0.7+9, this doesn't survive a bootcycle build, crashing the VM on at least amd64 and i386. From sgehwolf at redhat.com Wed Apr 15 11:45:40 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 15 Apr 2020 13:45:40 +0200 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <970919ef-4357-f5da-04e0-a5678d70e61f@ubuntu.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> <970919ef-4357-f5da-04e0-a5678d70e61f@ubuntu.com> Message-ID: <9aa83e443405e123c40ece172cfde60066a0d186.camel@redhat.com> On Wed, 2020-04-15 at 13:26 +0200, Matthias Klose wrote: > On 4/14/20 9:56 PM, Andrew John Hughes wrote: > > Here are the remaining changes for the jdk11u repository: > > > > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ > > compared to 11.0.7+9, this doesn't survive a bootcycle build, crashing the VM on > at least amd64 and i386. Thanks for the info. There must be more to it, though. Bootcycle build for vanilla JDK 11.0.7+10 worked fine. That was on a RHEL 6 machine: https://adoptopenjdk.net/upstream.html?variant=openjdk11&ga=ga On which toolchain does this reproduce? Thanks, Severin From doko at ubuntu.com Wed Apr 15 11:50:52 2020 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 15 Apr 2020 13:50:52 +0200 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <9aa83e443405e123c40ece172cfde60066a0d186.camel@redhat.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> <970919ef-4357-f5da-04e0-a5678d70e61f@ubuntu.com> <9aa83e443405e123c40ece172cfde60066a0d186.camel@redhat.com> Message-ID: On 4/15/20 1:45 PM, Severin Gehwolf wrote: > On Wed, 2020-04-15 at 13:26 +0200, Matthias Klose wrote: >> On 4/14/20 9:56 PM, Andrew John Hughes wrote: >>> Here are the remaining changes for the jdk11u repository: >>> >>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ >> >> compared to 11.0.7+9, this doesn't survive a bootcycle build, crashing the VM on >> at least amd64 and i386. > > Thanks for the info. There must be more to it, though. Bootcycle build > for vanilla JDK 11.0.7+10 worked fine. That was on a RHEL 6 machine: > > https://adoptopenjdk.net/upstream.html?variant=openjdk11&ga=ga > > On which toolchain does this reproduce? that's Debian unstable (GCC 9.3, binutils 2.34, glibc-2.30) and Ubuntu 20.04 (GCC 9.3, binutils 2.34, glibc 2.31). Suspecting toolchain issues, I rebuilt with GCC 8.4 with the same result. Note that hardening flags (-fPIE, -fstack-protector-strong) are used. The 13.0.3+3 release builds fine with a bootcycle build. Matthias From gnu.andrew at redhat.com Wed Apr 15 12:31:12 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 Apr 2020 13:31:12 +0100 Subject: [RFR] [11u] 11.0.7+10 / 11.0.7-ga In-Reply-To: <970919ef-4357-f5da-04e0-a5678d70e61f@ubuntu.com> References: <432ffbce-b41a-1b7f-6e8d-2df908079a6e@redhat.com> <970919ef-4357-f5da-04e0-a5678d70e61f@ubuntu.com> Message-ID: On 15/04/2020 12:26, Matthias Klose wrote: > On 4/14/20 9:56 PM, Andrew John Hughes wrote: >> Here are the remaining changes for the jdk11u repository: >> >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/11.0.7/ > > compared to 11.0.7+9, this doesn't survive a bootcycle build, crashing the VM on > at least amd64 and i386. > >From discussion with Matthias on IRC, this looks like the same issue we hit yesterday on some builds: V [libjvm.so+0xc3ce2c] SharedPathsMiscInfo::check()+0x3c Issue appears to be that JDK-8226406 was backported to 11.0.7, but not https://bugs.openjdk.java.net/browse/JDK-8228407 Will post an RFR for this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 15 13:37:03 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 Apr 2020 14:37:03 +0100 Subject: OpenJDK 11.0.7 Released Message-ID: We are pleased to announce the release of OpenJDK 11.0.7. The source tarball is available from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.7-ga.tar.xz The tarball is accompanied by a digital signature available at: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.7-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: 6c30a76bfc3de30d1db1c55dd23ac7ef5380c4d77c26523ce3ba061a83ec4a1f openjdk-11.0.7-ga.tar.xz 86f9c287a6977e66c8657184d8f8b615c9b9a0dd413fd33823e74b36de1b748b openjdk-11.0.7-ga.tar.xz.sig The checksums can be downloaded from: * https://openjdk-sources.osci.io/openjdk11/openjdk-11.0.7-ga.sha256 New in release OpenJDK 11.0.7 (2020-04-14): =========================================== Live versions of these release notes can be found at: * https://bitly.com/oj1107 * https://builds.shipilev.net/backports-monitor/release-notes-11.0.7.txt * Security fixes - JDK-8223898, CVE-2020-2754: Forward references to Nashorn - JDK-8223904, CVE-2020-2755: Improve Nashorn matching - JDK-8224541, CVE-2020-2756: Better mapping of serial ENUMs - JDK-8224549, CVE-2020-2757: Less Blocking Array Queues - JDK-8225603: Enhancement for big integers - JDK-8226346: Build better binary builders - JDK-8227467: Better class method invocations - JDK-8227542: Manifest improved jar headers - JDK-8229733: TLS message handling improvements - JDK-8231415, CVE-2020-2773: Better signatures in XML - JDK-8231785: Improved socket permissions - JDK-8232424, CVE-2020-2778: More constrained algorithms - JDK-8232581, CVE-2020-2767: Improve TLS verification - JDK-8233250: Better X11 rendering - JDK-8233410: Better Build Scripting - JDK-8234027: Better JCEKS key support - JDK-8234408, CVE-2020-2781: Improve TLS session handling - JDK-8234825, CVE-2020-2800: Better Headings for HTTP Servers - JDK-8234841, CVE-2020-2803: Enhance buffering of byte buffers - JDK-8235274, CVE-2020-2805: Enhance typing of methods - JDK-8235691, CVE-2020-2816: Enhance TLS connectivity - JDK-8236201, CVE-2020-2830: Better Scanner conversions - JDK-8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap * Other changes - JDK-4919790: Errors in alert ssl message does not reflect the actual certificate status - JDK-4949105: Access Bridge lacks html tags parsing - JDK-7092821: java.security.Provider.getService() is synchronized and became scalability bottleneck - JDK-7143743: Potential memory leak with zip provider - JDK-8005819: Support cross-realm MSSFU - JDK-8042383: [TEST_BUG] Test javax/swing/plaf/basic/BasicMenuUI/4983388/bug4983388.java fails with shortcuts on menus do not work - JDK-8068184: Fix for JDK-8032832 caused a deadlock - JDK-8145845: [AOT] NullPointerException in compiler/whitebox/GetCodeHeapEntriesTest.java - JDK-8152988: [AOT] Update test batch definitions to include aot-ed java.base module mode into hs-comp testing - JDK-8160926: FLAGS_COMPILER_CHECK_ARGUMENTS doesn't handle cross-compilation - JDK-8163083: SocketListeningConnector does not allow invocations with port 0 - JDK-8163251: Hard coded loop limit prevents reading of smart card data greater than 8k - JDK-8167276: jvmci/compilerToVM/MaterializeVirtualObjectTest.java fails with -XX:-EliminateAllocations - JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false - JDK-8176556: java/awt/dnd/ImageTransferTest/ImageTransferTest.java fails for JFIF - JDK-8178798: Two compiler/aot/verification/vmflags tests fail by timeout with UseAVX=3 - JDK-8183107: PKCS11 regression regarding checkKeySize - JDK-8185005: Improve performance of ThreadMXBean.getThreadInfo(long ids[], int maxDepth) - JDK-8189633: Missing -Xcheck:jni checking for DeleteWeakGlobalRef - JDK-8189861: Refactor CacheFind - JDK-8193042: NativeLookup::lookup_critical_entry() should only load shared library once - JDK-8193596: java/net/DatagramPacket/ReuseBuf.java failed due to timeout - JDK-8194944: Regression automated test 'open/test/jdk/javax/swing/JInternalFrame/8145896/TestJInternalFrameMaximize.java' fails - JDK-8196467: javax/swing/JInternalFrame/Test6325652.java fails - JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE - JDK-8198321: javax/swing/JEditorPane/5076514/bug5076514.java fails - JDK-8198398: Test javax/swing/JColorChooser/Test6199676.java fails in mach5 - JDK-8199072: Test javax/swing/GroupLayout/6613904/bug6613904.java is unstable - JDK-8200432: javadoc fails with ClassCastException on {@link byte[]} - JDK-8201349: build broken when configured with --with-zlib=bundled on gcc 7.3 - JDK-8201355: Avoid native memory allocation in sun.security.mscapi.PRNG.generateSeed - JDK-8201513: nsk/jvmti/IterateThroughHeap/filter-* are broken - JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3 - JDK-8203687: javax/net/ssl/compatibility/Compatibility.java supports TLS 1.3 - JDK-8203904: javax/swing/JSplitPane/4816114/bug4816114.java: The divider location is wrong - JDK-8203911: Test runtime/modules/getModuleJNI/GetModule fails with -Xcheck:jni - JDK-8204525: [TESTBUG] runtime/NMT/MallocStressTest.java ran out of java heap - JDK-8204529: gc/TestAllocateHeapAtMultiple.java fail with Agent 7 timed out - JDK-8204551: Event descriptions are truncated in logs - JDK-8206963: [AOT] bug with multiple class loaders - JDK-8207367: 10 vmTestbase/nsk/jdi tests timed out when running with jtreg - JDK-8207832: serviceability/sa/ClhsdbCDSCore.java failed with "Couldn't find core file location" - JDK-8207938: At step6,Click Add button,case failed automatically. - JDK-8208157: requires.VMProps throws NPE for missing properties in "release" file - JDK-8208379: compiler/jvmci/events/JvmciNotifyInstallEventTest.java failed with "Got unexpected event count after 2nd install attempt: expected 9 to equal 2" - JDK-8208658: Make CDS archived heap regions usable even if compressed oop encoding has changed - JDK-8208715: Conversion of milliseconds to nanoseconds in UNIXProcess contains bug - JDK-8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) - JDK-8209385: CDS runtime classpath checking is too strict when only classes from the system modules are archived - JDK-8209389: SIGSEGV in WalkOopAndArchiveClosure::do_oop_work. - JDK-8209418: Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2 - JDK-8209494: Create a test for SwingSet InternalFrameDemo - JDK-8209499: Create test for SwingSet EditorPaneDemo - JDK-8209574: [AOT] breakpoint events are generated in different threads does not meet expected count - JDK-8209686: cleanup arguments to PhaseIdealLoop() constructor - JDK-8209789: Synchronize test/jdk/sanity/client/lib/jemmy with code-tools/jemmy/v2 - JDK-8209802: Garbage collectors should register JFR types themselves to avoid build errors. - JDK-8209807: improve handling exception in requires.VMProps - JDK-8209817: stack is executable when building with Clang on Linux - JDK-8209824: Improve the code coverage for ThreadLocal - JDK-8209826: Undefined reference to os::write after JDK-8209657 (filemap.hpp cleanup) - JDK-8209850: Allow NamedThreads to use GlobalCounter critical sections - JDK-8209976: Improve iteration over non-JavaThreads - JDK-8209993: Create a test for SwingSet3 ToolTipDemo - JDK-8210024: JFR calls virtual is_Java_thread from ~Thread() - JDK-8210052: Enable testing for all the available look and feels in SwingSet3 demo tests - JDK-8210055: Enable different look and feel tests in SwingSet3 demo tests - JDK-8210057: Enable different look and feels in SwingSet3 demo test InternalFrameDemoTest - JDK-8210058: Algorithmic Italic font leans opposite angle in Printing - JDK-8210220: [AOT] jdwp test cases are failing with error # ERROR: TEST FAILED: Cought IOException while receiving event packet - JDK-8210289: ArchivedKlassSubGraphInfoRecord is incomplete - JDK-8210459: Add support for generating compile_commands.json - JDK-8210476: sun/security/mscapi/PrngSlow.java fails with Still too slow - JDK-8210512: [Testbug] vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java fails with unexpected size of ClassLoaderReference.referringObjects - JDK-8210523: runtime/appcds/cacheObject/DifferentHeapSizes.java crash - JDK-8210632: Add key exchange algorithm to javax/net/ssl/TLSCommon/CipherSuite.java - JDK-8210699: Problem list tests which times out in Xcomp mode - JDK-8210793: [JVMCI] AllocateCompileIdTest.java failed to find DiagnosticCommand.class - JDK-8210910: Create test for FileChooserDemo - JDK-8210994: Create test for SwingSet3 FrameDemo - JDK-8211139: Increase timeout value in all tests under jdk/sanity/client/SwingSet/src - JDK-8211160: Handle different look and feels in JInternalFrameOperator - JDK-8211211: vmTestbase/metaspace/stressDictionary/StressDictionary.java timeout - JDK-8211322: Reduce the timeout of tooltip in SwingSet2DemoTest - JDK-8211443: Enable different look and feels in SwingSet3 demo test SplitPaneDemoTest - JDK-8211703: JInternalFrame : java.lang.AssertionError: cannot find the internal frame - JDK-8211781: re-building fails after changing Graal sources - JDK-8212897: Some improvements in the EditorPaneDemotest - JDK-8212903: [TestBug] Tests test/jdk/javax/swing/LookAndFeel/8145547/DemandGTK2.sh and DemandGTK3.sh fail on Ubuntu 18.04 LTS - JDK-8213009: Refactoring existing SunMSCAPI classes - JDK-8213010: Supporting keys created with certmgr.exe - JDK-8213168: Enable different look and feel tests in SwingSet3 demo test FileChooserDemoTest - JDK-8213348: jdk.internal.vm.compiler.management service providers missing in module descriptor - JDK-8213906: Update arm devkits with libXrandr headers - JDK-8213908: AssertionError in DeferredAttr at setOverloadKind - JDK-8214124: [TESTBUG] Bugs in runtime/NMT/MallocStressTest.java - JDK-8214344: C2: assert(con.basic_type() != T_ILLEGAL) failed: elembt=byte; loadbt=void; unsigned=0 - JDK-8214345: infinite recursion while checking super class - JDK-8214471: Enable different look and feel tests in SwingSet3 demo test ToolTipDemoTest - JDK-8214534: Setting of THIS_FILE in the build is broken - JDK-8214557: Filter out VM flags which don't affect AOT code generation - JDK-8214578: [macos] Problem with backslashes on macOS/JIS keyboard: Java ignores system settings - JDK-8214840: runtime/NMT/MallocStressTest.java timed out - JDK-8214850: Rename vm_operations.?pp files to vmOperations.?pp files - JDK-8214904: Test8004741.java failed due to "Too few ThreadDeath hits; expected at least 6 but saw only 5" - JDK-8215322: add @file support to jaotc - JDK-8215355: Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1) - JDK-8215396: JTabbedPane preferred size calculation is wrong for SCROLL_TAB_LAYOUT - JDK-8216180: [AOT] compiler/intrinsics/bigInteger/TestMulAdd.java crashed with AOT enabled - JDK-8216353: Use utility APIs introduced in org/netbeans/jemmy/util/LookAndFeel class in client sanity test cases - JDK-8216354: Syntax error in toolchain_windows.m4 - JDK-8216472: (se) Stack overflow during selection operation leads to crash (win) - JDK-8216535: tools/jimage/JImageExtractTest.java timed out - JDK-8217235: Create automated test for SwingSet ColorChooserDemoTest - JDK-8217297: Add support for multiple look and feel for SwingSet SliderDemoTest - JDK-8217338: [Containers] Improve systemd slice memory limit support - JDK-8217613: [AOT] TEST_OPTS_AOT_MODULES doesn't work on mac - JDK-8217634: RunTest documentation and usability update - JDK-8217717: ZGC: Broken oop map in C1 load barrier stub - JDK-8217728: Speed up incremental rerun of "make hotspot" - JDK-8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs - JDK-8218662: Allow 204 responses with Content-Length:0 - JDK-8218882: NET_Writev is declared, NET_WriteV is defined - JDK-8218889: Improperly use of the Optional API - JDK-8219205: JFR file without license header - JDK-8219597: (bf) Heap buffer state changes could provoke unexpected exceptions - JDK-8219723: javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases - JDK-8220348: [ntintel] asserts about copying unaligned array - JDK-8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" - JDK-8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" - JDK-8220479: java/nio/channels/Selector/SelectWithConsumer.java failed at testTwoChannels() - JDK-8220613: java/util/Arrays/TimSortStackSize2.java times out with fastdebug build - JDK-8220688: [TESTBUG] runtime/NMT/MallocStressTest.java timed out - JDK-8220786: Create new switch to redirect error reporting output to stdout or stderr - JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl - JDK-8221312: test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java failed - JDK-8221851: Use of THIS_FILE in hotspot invalidates precompiled header on Linux/GCC - JDK-8221885: Add intermittent test in the JavaSound to the ProblemList - JDK-8222264: Windows incremental build is broken with JDK-8217728 - JDK-8222391: javax/net/ssl/compatibility/Compatibility.java should be more flexible - JDK-8222448: java/lang/reflect/PublicMethods/PublicMethodsTest.java times out - JDK-8222519: ButtonDemoScreenshotTest fails randomly with "still state to be reached" - JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException - JDK-8223003: SunMSCAPI keys are not cleaned up - JDK-8223063: Support CNG RSA keys - JDK-8223158: Docked MacBook cannot start any Java Swing applications - JDK-8223260: NamingManager should cache InitialContextFactory - JDK-8223464: Improve version string for Oracle CI builds - JDK-8223558: Java does not render Myanmar script correctly - JDK-8223627: jdk-13+20 bundle name contains null instead of ea - JDK-8223638: Replace wildcard address with loopback or local host in tests - part 6 - JDK-8223678: Add Visual Studio Code workspace generation support (for native code) - JDK-8223727: com/sun/jndi/ldap/privconn/RunTest.java failed due to hang in LdapRequest.getReplyBer - JDK-8223769: Assert triggers with -XX:+StressReflectiveCode - JDK-8224187: Refactor arraycopy_prologue to allow ZGC read barriers on arraycopy - JDK-8224475: JTextPane does not show images in HTML rendering - JDK-8224673: Adjust permission for delayed starting of debugging - JDK-8224705: Tests that need to be problem-listed or have printer resources - JDK-8224778: test/jdk/demo/jfc/J2Ddemo/J2DdemoTest.java cannot find J2Ddemo.jar - JDK-8224821: java/awt/Focus/NoAutotransferToDisabledCompTest/NoAutotransferToDisabledCompTest.java fails linux-x64 - JDK-8224830: test/jdk/java/awt/Focus/ModalExcludedWindowClickTest/ModalExcludedWindowClickTest.java fails on linux-x64 - JDK-8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 - JDK-8224905: java/lang/ProcessBuilder/Basic.java#id1 failed with stream closed - JDK-8225007: java/awt/print/PrinterJob/LandscapeStackOverflow.java may hang - JDK-8225105: java/awt/Focus/ShowFrameCheckForegroundTest/ShowFrameCheckForegroundTest.java fails in Windows 10 - JDK-8225117: java/math/BigInteger/SymmetricRangeTests.java fails with ParseException - JDK-8225128: Add exception for expiring DocuSign root to VerifyCACerts test - JDK-8225130: Add exception for expiring Comodo roots to VerifyCACerts test - JDK-8225144: [macos] In Aqua L&F backspace key does not delete when Shift is pressed - JDK-8225180: SignedObject with invalid Key not throwing the InvalidKeyException in Windows - JDK-8225182: JNI exception pending in DestroyXIMCallback of awt_InputMethod.c:1327 - JDK-8225199: [Graal] compiler/jvmci/compilerToVM/IsMatureVsReprofileTest.java fails with -XX:CompileThresholdScaling=0.1 - JDK-8225305: ProblemList java/lang/invoke/VarHandles tests - JDK-8225350: compiler/jvmci/compilerToVM/IsCompilableTest.java timed out - JDK-8225430: Replace wildcard address with loopback or local host in tests - part 14 - JDK-8225435: Upgrade IANA Language Subtag Registry to the latest for JDK14 - JDK-8225487: giflib legal file is missing attribution for openbsd-reallocarray.c - JDK-8225567: Wrong file headers with 8202414 fix changeset - JDK-8225684: [AOT] vmTestbase/vm/oom/production/AlwaysOOMProduction tests fail with AOTed java.base - JDK-8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 - JDK-8225797: OldObjectSample event creates unexpected amount of checkpoint data - JDK-8226381: ProblemList java/lang/reflect/PublicMethods/PublicMethodsTest.java - JDK-8226406: JVM fails to detect mismatched or corrupt CDS archive - JDK-8226608: Hide the onjcmd option from the help output - JDK-8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys - JDK-8227112: exclude compiler/intrinsics/sha/sanity tests from AOT runs - JDK-8227324: Upgrade to freetype 2.10.1 - JDK-8227528: TestAbortVMOnSafepointTimeout.java failed due to "RuntimeException: 'Safepoint sync time longer than' missing from stdout/stderr" - JDK-8227645: Some tests in serviceability/sa run with fixed -Xmx values and risk running out of memory - JDK-8227646: [TESTBUG] appcds/SharedArchiveConsistency timed out - JDK-8227662: freetype seeks to index at the end of the font data - JDK-8228479: Correct the format of ColorChooserDemoTest - JDK-8228613: java.security.Provider#getServices order is no longer deterministic - JDK-8228969: 2019-09-28 public suffix list update - JDK-8229236: CriticalJNINatives: dll handling should be done in native thread state - JDK-8229345: Memory leak due to vtable stubs not being shared on SPARC - JDK-8229888: (zipfs) Updating an existing zip file does not preserve original permissions - JDK-8229994: assert(false) failed: Bad graph detected in get_early_ctrl_for_expensive - JDK-8230004: jdk/internal/jimage/JImageOpenTest.java runs no test - JDK-8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception - JDK-8230390: Problemlist SA tests with AOT - JDK-8230400: Missing constant pool entry for a method in stacktrace - JDK-8230459: Test failed to resume JVMCI CompilerThread - JDK-8230480: check malloc/calloc results in java.desktop - JDK-8230597: Update GIFlib library to the 5.2.1 - JDK-8230611: infinite loop in LogOutputList::wait_until_no_readers() - JDK-8230624: [TESTBUG] Problemlist JFR compiler/TestCodeSweeper.java - JDK-8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken - JDK-8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout - JDK-8231025: Incorrect method tag offset for big endian platform - JDK-8231081: TestMetadataRetention fails due to missing symbol id - JDK-8231387: java.security.Provider.getService returns random result due to race condition with mutating methods in the same class - JDK-8231430: C2: Memory stomp in max_array_length() for T_ILLEGAL type - JDK-8231445: check ZALLOC return values in awt coding - JDK-8231507: Update Apache Santuario (XML Signature) to version 2.1.4 - JDK-8231584: Deadlock with ClassLoader.findLibrary and System.loadLibrary call - JDK-8231753: use more Posix functionality in aix os::print_os_info - JDK-8231810: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF" - JDK-8232003: (fs) Files.write can leak file descriptor in the exception case - JDK-8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small - JDK-8232060: add some initializations using sigemptyset in os_aix.cpp - JDK-8232154: Update Mesa 3-D Headers to version 19.2.1 - JDK-8232167: Visual Studio install found through --with-tools-dir value is discarded - JDK-8232170: FSInfo#getJarClassPath throws an exception not declared in its throws clause - JDK-8232200: [macos 10.15] Windows in fullscreen tests jumps around the screen - JDK-8232207: Linux os::available_memory re-reads cgroup configuration on every invocation - JDK-8232224: [TESTBUG] problemlist JFR TestLargeRootSet.java - JDK-8232370: Refactor some com.sun.jdi tests to enable IDE integration - JDK-8232433: [macos 10.15] java/awt/Window/LocationAtScreenCorner/LocationAtScreenCorner.java may fail - JDK-8232571: Add missing SIGINFO signal - JDK-8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled - JDK-8232713: Update BCEL version to 6.3.1 in license file - JDK-8232806: Introduce a system property to disable eager lambda initialization - JDK-8232834: RunTest sometimes fails to produce valid exitcode.txt - JDK-8232880: Update test documentation with additional settings for client UI tooltip tests - JDK-8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures. - JDK-8233018: Add a new test to verify that DatagramSocket is not interruptible - JDK-8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit - JDK-8233032: assert(in_bb(n)) failed: must be - JDK-8233078: fix minimal VM build on Linux ppc64(le) - JDK-8233328: fix minimal VM build on Linux s390x - JDK-8233383: Various minor fixes - JDK-8233466: aarch64: remove unnecessary load of mdo when profiling return and parameters type - JDK-8233491: Crash in AdapterHandlerLibrary::get_adapter with CDS due to code cache exhaustion - JDK-8233529: loopTransform.cpp:2984: Error: assert(p_f->Opcode() == Op_IfFalse) failed - JDK-8233548: Update CUP to v0.11b - JDK-8233649: Update ProblemList.txt to exclude failing headful tests on macos - JDK-8233656: assert(d->is_CFG() && n->is_CFG()) failed: must have CFG nodes - JDK-8233657: Intermittent NPE in Component.validate() - JDK-8234288: Turkey Time Zone returns incorrect time zone name - JDK-8234323: NULL-check return value of SurfaceData_InitOps on macosx - JDK-8234339: replace JLI_StrTok in java_md_solinux.c - JDK-8234340: Bump update version for OpenJDK: jdk-11.0.7 - JDK-8234350: assert(mode == ControlAroundStripMined && (use == sfpt || !use->is_reachable_from_root())) failed: missed a node - JDK-8234386: [macos] NPE was thrown at expanding Choice from maximized frame - JDK-8234397: add OS uptime information to os::print_os_info output - JDK-8234423: Modifying ArrayList.subList().subList() resets modCount of subList - JDK-8234466: Class loading deadlock involving X509Factory#commitEvent() - JDK-8234501: remove obsolete NET_ReadV - JDK-8234525: enable link-time section-gc for linux s390x to remove unused code - JDK-8234610: MaxVectorSize set wrongly when UseAVX=3 is specified after JDK-8221092 - JDK-8234617: C1: Incorrect result of field load due to missing narrowing conversion - JDK-8234723: javax/net/ssl/TLS tests support TLSv1.3 - JDK-8234724: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java supports TLSv1.3 - JDK-8234741: enhance os::get_core_path on macOS - JDK-8234769: Duplicate attribution in freetype.md - JDK-8234786: Fix for JDK-8214578 breaks OS X 10.12 compatibility - JDK-8234809: set relro in linker flags when building with gcc - JDK-8234824: java/nio/channels/SocketChannel/AdaptSocket.java fails on Windows 10 - JDK-8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version - JDK-8235288: AVX 512 instructions inadvertently used on Xeon for small vector width operations - JDK-8235325: build failure on Linux after 8235243 - JDK-8235383: C1 compilation fails with -XX:+PrintIRDuringConstruction -XX:+Verbose - JDK-8235489: handle return values of sscanf calls in hotspot - JDK-8235509: Backport for JDK-8209657 Refactor filemap.hpp to simplify integration with Serviceability Agent. - JDK-8235510: java.util.zip.CRC32 performance drop after 8200067 - JDK-8235563: [TESTBUG] appcds/CommandLineFlagComboNegative.java does not handle archive mapping failure - JDK-8235637: jhsdb jmap from OpenJDK 11.0.5 doesn't work if prelink is enabled - JDK-8235671: enhance print_rlimit_info in os_posix - JDK-8235744: PIT: test/jdk/javax/swing/text/html/TestJLabelWithHTMLText.java times out in linux-x64 - JDK-8235904: Infinite loop when rendering huge lines - JDK-8235998: [c2] Memory leaks during tracing after '8224193: stringStream should not use Resource Area'. - JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 - JDK-8236140: assert(!VerifyHashTableKeys || _hash_lock == 0) failed: remove node from hash table before modifying it - JDK-8236179: C1 register allocation error with T_ADDRESS - JDK-8236488: Support for configure option --with-native-debug-symbols=internal is impossible on Windows - JDK-8236500: Windows ucrt.dll should be looked up in versioned WINSDK subdirectory - JDK-8236709: struct SwitchRange in HS violates C++ One Definition Rule - JDK-8236848: [JDK 11u] make run-test-tier1 fails after backport of JDK-8232834 - JDK-8236873: Worker has a deadlock bug - JDK-8237217: Incorrect G1StringDedupEntry type used in StringDedupTable destructor - JDK-8237368: Problem with NullPointerException in RMI TCPEndpoint.read - JDK-8237375: SimpleThresholdPolicy misses CounterDecay timestamp initialization - JDK-8237508: Simplify JarFile.isInitializing - JDK-8237540: Missing files in backport of JDK-8210910 - JDK-8237541: Missing files in backport of JDK-8236528 - JDK-8237600: Test SunJSSEFIPSInit fails on Ubuntu - JDK-8237819: s390x - remove unused pd_zero_to_words_large - JDK-8237869: exclude jtreg test security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java because of instabilities - JDK-8237879: make 4.3 breaks build - JDK-8237945: CTW: C2 compilation fails with assert(just_allocated_object(alloc_ctl) == ptr) failed: most recent allo - JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary - JDK-8238247: CTW runner should sweep nmethods more aggressively - JDK-8238366: CTW runner closes standard output on exit - JDK-8238438: SuperWord::co_locate_pack picks memory state of first instead of last load - JDK-8238502: sunmscapi.dll causing EXCEPTION_ACCESS_VIOLATION - JDK-8238534: Deep sign macOS bundles before bundle archive is being created - JDK-8238591: CTW: Split applications/ctw/modules/jdk_localedata.java - JDK-8238596: AVX enabled by default for Skylake even when unsupported - JDK-8238811: C2: assert(i >= req() || i == 0 || is_Region() || is_Phi()) with -XX:+VerifyGraphEdges - JDK-8239005: [TESTBUG] test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPages.java: exeinvoke.c: must initialize static state before calling do_overflow() - JDK-8239466: Loss of precision in counter decay calculation in 11u backport of JDK-8237375 - JDK-8239856: [ntintel] asserts about copying unaligned array element - JDK-8240724: [test] jdk11 downport of 8224475 misses binary file test/jdk/javax/swing/JTextPane/arrow.png - JDK-8241296: Segfault in JNIHandleBlock::oops_do() Notes on individual issues: =========================== security-libs/javax.xml.crypto: JDK-8239467: Apache Santuario Library Updated to Version 2.1.4 ============================================================== The Apache Santuario library has been upgraded to version 2.1.4. As a result, a new system property `com.sun.org.apache.xml.internal.security.parser.pool-size` has been introduced. This new system property sets the pool size of the internal `DocumentBuilder` cache used when processing XML Signatures. The function is equivalent to the `org.apache.xml.security.parser.pool-size` system property used in Apache Santuario and has the same default value of 20. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From gnu.andrew at redhat.com Wed Apr 15 13:46:24 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 Apr 2020 14:46:24 +0100 Subject: [11u] [RFR] JDK-8228407: JVM crashes with shared archive file mismatch Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8228407 Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8228407/ It seems JDK-8226406 [0] was backported for 11.0.7, but not this follow-up regression fix. Both Matthias Klose & I have seen build failures as a result. I believe these start to occur when the shared archive file is generated by a build that includes 11.0.7+3 where JDK-8226406 was integrated. At least, this is why we only spotted it late in 11.0.7 production when new builds started using earlier EA builds to bootstrap. The backport to 11u is largely clean. The only difference is due to the addition of the is_static parameter by JDK-8207812: "Implement Dynamic CDS Archive" in jdk/jdk. Ok for jdk11u-dev? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From sgehwolf at redhat.com Wed Apr 15 13:50:52 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 15 Apr 2020 15:50:52 +0200 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u In-Reply-To: References: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> Message-ID: On Tue, 2020-04-14 at 20:18 +0000, Langer, Christoph wrote: > Hi Severin, > > > > > in System.c: > > > > > > > > - PUTPROP(props, "java.version", VERSION_SHORT); > > > > - PUTPROP(props, "java.vendor", VENDOR); > > > > - PUTPROP(props, "java.vendor.url", VENDOR_URL); > > > > - PUTPROP(props, "java.vendor.url.bug", VENDOR_URL_BUG); > > > > - > > > > > > > > Aren't you removing "PUTPROP(props, "java.version", > > VERSION_SHORT)"; > > > > too eagerly here? > > > > > > I don't think so. > > > > Well, my point was more about the following: For this partial backport > > it should be sufficient to only remove PUTPROP calls for *vendor* > > related properties. I.e. this isn't part of 4947890 while the others > > are. I agree it shouldn't matter from a functional perspective. It's > > just a bit confusing. > > Ah, I see. This part of the change was already done in an earlier fix > to improve startup performance: JDK-8185496. Hm, I think as 8242154 > is a carveout of JDK-4947890 anyway, I think it's ok to be included. > I will, however, reference JDK-8185496 in the bug description of JDK- > 8242154, too. Ok with you? OK. Thanks, Severin From sgehwolf at redhat.com Wed Apr 15 14:03:33 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 15 Apr 2020 16:03:33 +0200 Subject: OpenJDK 11.0.7 Released In-Reply-To: References: Message-ID: On Wed, 2020-04-15 at 14:37 +0100, Andrew John Hughes wrote: > We are pleased to announce the release of OpenJDK 11.0.7. The OpenJDK Project Build to go with this is here: https://adoptopenjdk.net/upstream.html?variant=openjdk11&ga=ga Thanks, Severin From yan at azul.com Wed Apr 15 14:38:26 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 15 Apr 2020 17:38:26 +0300 Subject: OpenJDK 13.0.3 released Message-ID: <4f577942-e3e9-8ee0-c573-8c540d478f1a@azul.com> Let me announce the release of OpenJDK 13.0.3. The release sources are in the usual place, get them to build from https://hg.openjdk.java.net/jdk-updates/jdk13u Read-only mirror also available on GitHub thanks to the Skara team: https://github.com/openjdk/jdk13u A list of fixes please see below. Also, a nicely generated list could be found at A. Shipilev's site: https://builds.shipilev.net/backports-monitor/release-notes-13.0.3.txt ============================================ Security fixes: JDK-8238960: linux-i586 builds are inconsistent as the newly build jdk is not able to reserve enough space for object heap JDK-8226346: Build better binary builders JDK-8233410: Better Build Scripting JDK-8227467: Better class method invocations JDK-8223898: Forward references to Nashorn JDK-8223904: Improve Nashorn matching JDK-8233250: Better X11 rendering JDK-8235691: Enhance TLS connectivity JDK-8232424: More constrained algorithms JDK-8229733: TLS message handling improvements JDK-8232581: Improve TLS verification JDK-8224549: Less Blocking Array Queues JDK-8231415: Better signatures in XML JDK-8227542: Manifest improved jar headers JDK-8234408: Improve TLS session handling JDK-8233245: More adaptive sockets JDK-8224541: Better mapping of serial ENUMs JDK-8225603: Enhancement for big integers JDK-8234027: Better JCEKS key support JDK-8234825: Better Headings for HTTP Servers JDK-8234841: Enhance buffering of byte buffers JDK-8235274: Enhance typing of methods JDK-8236201: Better Scanner conversions JDK-8231785: Improved socket permissions Other fixes: JDK-8234080: jdk/nio/zipfs/CRCWriteTest.java fails JDK-8232879: Writing out data with the Zip File System leads to a CRC failure JDK-8068184: Fix for JDK-8032832 caused a deadlock JDK-8233529: loopTransform.cpp:2984: Error: assert(p_f->Opcode() == Op_IfFalse) failed JDK-8232539: SIGSEGV in C2 Node::unique_ctrl_out JDK-8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode JDK-8231665: 8231055 broke escapeAnalysis/TestSelfArrayCopy.java JDK-8231055: C2: arraycopy with same non escaping src and dest but different positions causes wrong execution JDK-8234350: assert(mode == ControlAroundStripMined && (use == sfpt || !use->is_reachable_from_root())) failed: missed a node JDK-8233032: assert(in_bb(n)) failed: must be JDK-8237368: Problem with NullPointerException in RMI TCPEndpoint.read JDK-8230597: Update GIFlib library to the 5.2.1 JDK-8238596: AVX enabled by default for Skylake even when unsupported JDK-8234610: MaxVectorSize set wrongly when UseAVX=3 is specified after JDK-8221092 JDK-8221092: UseAVX=3 has performance degredation on Skylake (X7) processors JDK-8230235: Rendering HTML with empty img attribute and documentBaseKey cause Exception JDK-8232874: Add missing test for 8230062 JDK-8230062: assert(i == p->size()-1) failed: must be last element of the pack JDK-8232154: Update Mesa 3-D Headers to version 19.2.1 JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 JDK-8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop JDK-8233656: assert(d->is_CFG() && n->is_CFG()) failed: must have CFG nodes JDK-8234906: [TESTBUG] TestDivZeroCheckControl fails for client VMs due to Unrecognized VM option LoopUnrollLimit JDK-8230671: x86_32 build failures after JDK-8229496 JDK-8229496: SIGFPE (division by zero) in C2 OSR compiled method JDK-8241489: restore missed in backports tests for 8229016, 8239787 JDK-8228969: 2019-09-28 public suffix list update JDK-8229450: C2 compilation fails with assert(found_sfpt) failed JDK-8230061: # assert(mode == ControlAroundStripMined && use == sfpt) failed: missed a node JDK-8231222: fix pkcs11 P11_DEBUG guarded native traces JDK-8230861: missing ReleaseStringUTFChars in Java_sun_security_pkcs11_wrapper_PKCS11_connect JDK-8229767: Typo in java.security: Sasl.createClient and Sasl.createServer JDK-8228835: Memory leak in PKCS11 provider when using AES GCM JDK-8133489: Better messaging for PKIX path validation matching JDK-8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures. JDK-8229437: assert(is_aligned(ref, HeapWordSize)) failed: invariant JDK-8227528: TestAbortVMOnSafepointTimeout.java failed due to "RuntimeException: 'Safepoint sync time longer than' missing from stdout/stderr" JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary JDK-8235687: Contents/MacOS/libjli.dylib cannot be a symlink JDK-8229016: C2 scalarization crashes with assert(node->Opcode() == Op_CastP2X) failed: ConvP2XNode required JDK-8228578: fix CFData object leak in macosx KeystoreImpl.m JDK-8005819: Support cross-realm MSSFU JDK-8239787: AArch64: String.indexOf may incorrectly handle empty strings JDK-8231507: Update Apache Santuario (XML Signature) to version 2.1.4 That's it for now; we continue at https://hg.openjdk.java.net/jdk-updates/jdk13u-dev You are welcome! Thanks, --yan From rob.mckenna at oracle.com Wed Apr 15 14:48:30 2020 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 15 Apr 2020 15:48:30 +0100 Subject: [Updates Communication] 14.0.1 security patches pushed Message-ID: <20200415144830.GA2989@DESKTOP-JNNKIHU.localdomain> 14.0.1 security patches pushed to http://hg.openjdk.java.net/jdk-updates/jdk14u -Rob From martinrb at google.com Wed Apr 15 15:49:16 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 15 Apr 2020 08:49:16 -0700 Subject: OpenJDK 11.0.7 Released In-Reply-To: References: Message-ID: Looks like there's a bad backport in jdk-11.0.7, causing doclint to report an apparently bogus error: (but 14.0.1 is OK) $ (cat Foo.java; set -x; for v in 11.0.6+10 11.0.7+10 14.0.1+7; do ~/jdk/jdk-$v/bin/javac -Xdoclint Foo.java; done) package foo; import java.io.ObjectStreamField; /** blah */ class Foo { /** blah */ private Object[] objects; /** * @serialField objects Object[] blah */ private static final ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("objects", Object[].class), }; } +/bin/zsh:175> v=11.0.6+10 +/bin/zsh:175> /usr/local/google/home/martinrb/jdk/jdk-11.0.6+10/bin/javac -Xdoclint Foo.java +/bin/zsh:175> v=11.0.7+10 +/bin/zsh:175> /usr/local/google/home/martinrb/jdk/jdk-11.0.7+10/bin/javac -Xdoclint Foo.java Foo.java:10: error: array type not allowed here * @serialField objects Object[] blah ^ 1 error +/bin/zsh:175> v=14.0.1+7 +/bin/zsh:175> /usr/local/google/home/martinrb/jdk/jdk-14.0.1+7/bin/javac -Xdoclint Foo.java From shade at redhat.com Wed Apr 15 16:48:29 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Apr 2020 18:48:29 +0200 Subject: OpenJDK 11.0.7 Released In-Reply-To: References: Message-ID: <2b48a04b-d150-926c-d73e-324751d2cf74@redhat.com> Hi Martin, On 4/15/20 5:49 PM, Martin Buchholz wrote: > +/bin/zsh:175> /usr/local/google/home/martinrb/jdk/jdk-11.0.7+10/bin/javac > -Xdoclint Foo.java > Foo.java:10: error: array type not allowed here > * @serialField objects Object[] blah > ^ > 1 error > +/bin/zsh:175> v=14.0.1+7 > +/bin/zsh:175> /usr/local/google/home/martinrb/jdk/jdk-14.0.1+7/bin/javac > -Xdoclint Foo.java I suspect it is caused by: https://bugs.openjdk.java.net/browse/JDK-8200432 ...and here is the fix: https://bugs.openjdk.java.net/browse/JDK-8214571 Your test passes with JDK-8214571 applied. Unfortunately, there was no issue link between the two, even though JDK-8214571 was tagged "regression". I'll work on backporting JDK-8214571. -- Thanks, -Aleksey From jianglizhou at google.com Wed Apr 15 17:21:42 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 15 Apr 2020 10:21:42 -0700 Subject: [11u] [RFR] JDK-8228407: JVM crashes with shared archive file mismatch In-Reply-To: References: Message-ID: Hi Andrew, It looks good to me. Best, Jiangli On Wed, Apr 15, 2020 at 6:48 AM Andrew John Hughes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228407 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8228407/ > > It seems JDK-8226406 [0] was backported for 11.0.7, but not this > follow-up regression fix. Both Matthias Klose & I have seen build > failures as a result. I believe these start to occur when the shared > archive file is generated by a build that includes 11.0.7+3 where > JDK-8226406 was integrated. At least, this is why we only spotted it > late in 11.0.7 production when new builds started using earlier EA > builds to bootstrap. > > The backport to 11u is largely clean. The only difference is due to the > addition of the is_static parameter by JDK-8207812: "Implement Dynamic > CDS Archive" in jdk/jdk. > > Ok for jdk11u-dev? > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > https://keybase.io/gnu_andrew > From gnu.andrew at redhat.com Wed Apr 15 18:27:25 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 15 Apr 2020 19:27:25 +0100 Subject: [11u] [RFR] JDK-8228407: JVM crashes with shared archive file mismatch In-Reply-To: References: Message-ID: <4e1f0ecf-7689-bd36-f5d9-d66274ecd249@redhat.com> On 15/04/2020 18:21, Jiangli Zhou wrote: > Hi Andrew, > > It looks good to me. > > Best, > > Jiangli > > On Wed, Apr 15, 2020 at 6:48 AM Andrew John Hughes > wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228407 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8228407/ >> >> It seems JDK-8226406 [0] was backported for 11.0.7, but not this >> follow-up regression fix. Both Matthias Klose & I have seen build >> failures as a result. I believe these start to occur when the shared >> archive file is generated by a build that includes 11.0.7+3 where >> JDK-8226406 was integrated. At least, this is why we only spotted it >> late in 11.0.7 production when new builds started using earlier EA >> builds to bootstrap. >> >> The backport to 11u is largely clean. The only difference is due to the >> addition of the is_static parameter by JDK-8207812: "Implement Dynamic >> CDS Archive" in jdk/jdk. >> >> Ok for jdk11u-dev? >> >> Thanks, >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> https://keybase.io/gnu_andrew >> > Thanks. I've flagged this for approval. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 https://keybase.io/gnu_andrew From goetz.lindenmaier at sap.com Fri Apr 17 11:08:41 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 17 Apr 2020 11:08:41 +0000 Subject: [11u] RFR(S): 8237474: Default SSLEngine should create in server role Message-ID: Hi, I would like to downport this for parity with 11.0.8-oracle. I had to resolve the copyrights. Further, in src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java, method engineGetDefaultSSLParameters() is to be patched. engineGetDefaultSSLParameters() was introduced in 12 by "8209031: SSLSocket should throw an exception when configuring DTLS" https://bugs.openjdk.java.net/browse/JDK-8209031, which is implemented in https://bugs.openjdk.java.net/browse/JDK-8208641. I dropped the change to this method as it's not in 11. http://cr.openjdk.java.net/~goetz/wr20/8237474-SSLEngine_server_role-jdk11/01/ original change: https://bugs.openjdk.java.net/browse/JDK-8237474 https://hg.openjdk.java.net/jdk/jdk/rev/74384366ec1d Best regards, Goetz. From christoph.langer at sap.com Fri Apr 17 15:17:46 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 17 Apr 2020 15:17:46 +0000 Subject: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK 11u In-Reply-To: References: <3caf65aa5fa7e5c8ff2c97199de012b50bb6e70b.camel@redhat.com> Message-ID: Thanks, Severin. I'm pushing this now. > -----Original Message----- > From: Severin Gehwolf > Sent: Mittwoch, 15. April 2020 15:51 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8242154: Backport parts of JDK-4947890 to OpenJDK > 11u > > On Tue, 2020-04-14 at 20:18 +0000, Langer, Christoph wrote: > > Hi Severin, > > > > > > > in System.c: > > > > > > > > > > - PUTPROP(props, "java.version", VERSION_SHORT); > > > > > - PUTPROP(props, "java.vendor", VENDOR); > > > > > - PUTPROP(props, "java.vendor.url", VENDOR_URL); > > > > > - PUTPROP(props, "java.vendor.url.bug", VENDOR_URL_BUG); > > > > > - > > > > > > > > > > Aren't you removing "PUTPROP(props, "java.version", > > > VERSION_SHORT)"; > > > > > too eagerly here? > > > > > > > > I don't think so. > > > > > > Well, my point was more about the following: For this partial backport > > > it should be sufficient to only remove PUTPROP calls for *vendor* > > > related properties. I.e. this isn't part of 4947890 while the others > > > are. I agree it shouldn't matter from a functional perspective. It's > > > just a bit confusing. > > > > Ah, I see. This part of the change was already done in an earlier fix > > to improve startup performance: JDK-8185496. Hm, I think as 8242154 > > is a carveout of JDK-4947890 anyway, I think it's ok to be included. > > I will, however, reference JDK-8185496 in the bug description of JDK- > > 8242154, too. Ok with you? > > OK. > > Thanks, > Severin From christoph.langer at sap.com Fri Apr 17 15:22:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 17 Apr 2020 15:22:41 +0000 Subject: [11u] RFR: 8232080: jlink plugins for vendor information and command-line options In-Reply-To: <0917d8fb8b78853e84cbb2405fe8d6f6ca5ad8d5.camel@redhat.com> References: <0917d8fb8b78853e84cbb2405fe8d6f6ca5ad8d5.camel@redhat.com> Message-ID: Hi Severin, thanks also for this review. I'm pushing this as well and I've requested JDK-8239557 for approval. Cheers Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Freitag, 10. April 2020 16:03 > To: Langer, Christoph ; jdk-updates- > dev at openjdk.java.net > Subject: Re: [11u] RFR: 8232080: jlink plugins for vendor information and > command-line options > > Hi Christoph, > > On Sun, 2020-04-05 at 14:18 +0000, Langer, Christoph wrote: > > Hi, > > > > now, please review the backport of JDK-8232080: jlink plugins for > > vendor information and command-line options. It's part of Oracle's > > 11.0.7 and contains valuable functionality for downstream vendors and > > jlinkers. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232080 > > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6c255334120d > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232080.11u.0/ > > This looks good to me. Nice work! > > > Its prerequisite is the backport of 8242154: Backport parts of JDK- > > 4947890 to OpenJDK 11u which I posted yesterday [0]. > > > > With that change in place, I had to do the following: > > - resolve src/hotspot/share/classfile/classLoader.cpp > > - ignore src/hotspot/share/runtime/vmStructs.cpp, which does not apply > > - resolve src/hotspot/share/utilities/vmError.cpp > > - resolve src/java.base/share/classes/java/lang/VersionProps.java > > - ignore > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java > which does not apply > > Right. JDK-8217845 isn't in OpenJDK 11u. OK. > > > I furthermore changed the version information of ASM to ASM6 (instead > > of ASM7) since that's the level in JDK11. But functionality-wise > > that's no problem. Everything used is part of ASM6 as well. > > > > With this patch I plan to push backports of JDK-8233137, JDK-8233291 > > and JDK-8234696 as they contain follow-up fixes. > > Please also consider JDK-8239557 in this batch. > > Thanks, > Severin > > > Thanks > > Christoph > > > > [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020- > April/002955.html > > From matthias.baesken at sap.com Mon Apr 20 08:04:53 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 20 Apr 2020 08:04:53 +0000 Subject: RFR [jdk11]: 8211301: [macos] support full window content options Message-ID: Hello, please review the jdk11 backport of 8211301 . I had to adjust the change slightly compared to jdk/jdk . Bug/ jdk11 webrev : https://bugs.openjdk.java.net/browse/JDK-8211301 http://cr.openjdk.java.net/~mbaesken/webrevs/8211301_0_jdk11/ original jdk/jdk webrev : http://hg.openjdk.java.net/jdk/jdk/rev/85fb403c0141 Best regards, Matthias From goetz.lindenmaier at sap.com Mon Apr 20 13:18:38 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Apr 2020 13:18:38 +0000 Subject: [11u] RFR(M) Message-ID: Hi, I am downporting this for parity with 11.0.8-oracle. I had to resolve the copyrith three times, and the problemlist. http://cr.openjdk.java.net/~goetz/wr20/8176359-Maximezedbounds_multi_screen-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8176359 https://hg.openjdk.java.net/jdk/client/rev/2777408b8281 Best regards, Goetz. From goetz.lindenmaier at sap.com Mon Apr 20 13:19:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Apr 2020 13:19:53 +0000 Subject: FW: [11u] RFR(M) 8176359 Frame#setMaximizedbounds not working properly in multi screen environments Message-ID: Hi, ... now with proper subject ... I am downporting this for parity with 11.0.8-oracle. I had to resolve the copyrith three times, and the problemlist. http://cr.openjdk.java.net/~goetz/wr20/8176359-Maximezedbounds_multi_screen-jdk11/01/ Please review. https://bugs.openjdk.java.net/browse/JDK-8176359 https://hg.openjdk.java.net/jdk/client/rev/2777408b8281 Best regards, Goetz. From christoph.langer at sap.com Tue Apr 21 10:53:53 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Apr 2020 10:53:53 +0000 Subject: RFR [jdk11]: 8211301: [macos] support full window content options In-Reply-To: References: Message-ID: Hi Matthias, it would be nice if you could give a little hint on what place you had to modify ??. I assume it was the first hunk in src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m? There, I think it would align better with the upstream patch, if you would as well change the indentation of ?type |= NSClosableWindowMask? and ?type |= NSResizableWindowMask? as was done upstream. Can you please do that before pushing? Otherwise, looks good. No need to see another webrev. Best regards Christoph From: Baesken, Matthias Sent: Montag, 20. April 2020 10:05 To: jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph Subject: RFR [jdk11]: 8211301: [macos] support full window content options Hello, please review the jdk11 backport of 8211301 . I had to adjust the change slightly compared to jdk/jdk . Bug/ jdk11 webrev : https://bugs.openjdk.java.net/browse/JDK-8211301 http://cr.openjdk.java.net/~mbaesken/webrevs/8211301_0_jdk11/ original jdk/jdk webrev : http://hg.openjdk.java.net/jdk/jdk/rev/85fb403c0141 Best regards, Matthias From matthias.baesken at sap.com Tue Apr 21 11:09:07 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 21 Apr 2020 11:09:07 +0000 Subject: RFR [jdk11]: 8211301: [macos] support full window content options In-Reply-To: References: Message-ID: Thanks for the review ! I?ll do the adjustment you mentioned, before I push the change . Best regards, Matthias From: Langer, Christoph Sent: Dienstag, 21. April 2020 12:54 To: Baesken, Matthias ; jdk-updates-dev at openjdk.java.net Subject: RE: RFR [jdk11]: 8211301: [macos] support full window content options Hi Matthias, it would be nice if you could give a little hint on what place you had to modify ??. I assume it was the first hunk in src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m? There, I think it would align better with the upstream patch, if you would as well change the indentation of ?type |= NSClosableWindowMask? and ?type |= NSResizableWindowMask? as was done upstream. Can you please do that before pushing? Otherwise, looks good. No need to see another webrev. Best regards Christoph From: Baesken, Matthias > Sent: Montag, 20. April 2020 10:05 To: jdk-updates-dev at openjdk.java.net Cc: Langer, Christoph > Subject: RFR [jdk11]: 8211301: [macos] support full window content options Hello, please review the jdk11 backport of 8211301 . I had to adjust the change slightly compared to jdk/jdk . Bug/ jdk11 webrev : https://bugs.openjdk.java.net/browse/JDK-8211301 http://cr.openjdk.java.net/~mbaesken/webrevs/8211301_0_jdk11/ original jdk/jdk webrev : http://hg.openjdk.java.net/jdk/jdk/rev/85fb403c0141 Best regards, Matthias From goetz.lindenmaier at sap.com Tue Apr 21 13:51:53 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 21 Apr 2020 13:51:53 +0000 Subject: [11u]: RFR(S): 8221823: Requested JDialog width is ignored Message-ID: Hi, I please need review for this downport for parity with 11.0.8-oracle: http://cr.openjdk.java.net/~goetz/wr20/8221823-JDialog_width_ignored-jdk11/01/ The problemlist patch does not apply. The tests are not problemlisted in 11u for windows. One of them is Problemlisted for mac, though. I left that line in place. Further I had to change a switch expression to a switch Statement in the test, else it would not compile. Original change: https://bugs.openjdk.java.net/browse/JDK-8221823 https://hg.openjdk.java.net/jdk/jdk/rev/19adbbca4307 Best regards, Goetz. From christoph.langer at sap.com Tue Apr 21 14:40:36 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Apr 2020 14:40:36 +0000 Subject: [11u] RFR(M) 8176359 Frame#setMaximizedbounds not working properly in multi screen environments In-Reply-To: References: Message-ID: Hi Goetz, this looks good to me. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Montag, 20. April 2020 15:20 > To: jdk-updates-dev > Subject: [CAUTION] FW: [11u] RFR(M) 8176359 Frame#setMaximizedbounds > not working properly in multi screen environments > > Hi, > > ... now with proper subject ... > > I am downporting this for parity with 11.0.8-oracle. > I had to resolve the copyrith three times, and the problemlist. > http://cr.openjdk.java.net/~goetz/wr20/8176359- > Maximezedbounds_multi_screen-jdk11/01/ > > Please review. > https://bugs.openjdk.java.net/browse/JDK-8176359 > https://hg.openjdk.java.net/jdk/client/rev/2777408b8281 > > Best regards, > Goetz. From christoph.langer at sap.com Tue Apr 21 15:10:29 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 21 Apr 2020 15:10:29 +0000 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: References: Message-ID: Hi Andrew, what's your status on this? Can we expect you to bring this fix in for 11.0.8 and 8u262? For 11u, we haven't backed out JDK-8231584 yet. So I'd like to either see your fix going in or to have a decision about a backout. Maybe in 11u we can also live with the backport of the upstream patch... I'm not sure. Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Andrew Haley > Sent: Dienstag, 17. M?rz 2020 17:50 > To: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Subject: RFD: What do we do about programs which set sys_paths to null? > > [ People who know all this stuff already, please feel free to skip > this introduction. ] > > This is a request for discussion about support for some programs that > do something illegal, not at all supported. I'd like to make this work > as intended by users, even though it's unsupported. Which seems odd, > but I still think we should do it. > > There is a long-established hack (going back about 20 years) which > allows Java programs to set the property "java.library.path" > dynamically. You might need to do this if you're a Java program which > extracts a shared library from a jarfile, puts it in a tmpdir > somewhere, then loads that library. > > People discovered that even though you can set "java.library.path" in > a program, it doesn't work as intended because the property is only > read once at boot time, and it is then cached in the static field > ClassLoader.usr_paths. So, people discovered that if they set > "java.library.path" then set set ClassLoader.sys_paths to null, then > called ClassLoader.loadLibrary, it works. Something like this: > > Class loaderClass = ClassLoader.class; > Field userPaths = loaderClass.getDeclaredField( "sys_paths" ); > userPaths.setAccessible( true ); > userPaths.set( null, null ); > > See the answer here, for example: > https://community.oracle.com/thread/1551225?start=15&tstart=0 > > This worked because ClassLoader.loadLibrary() did this: > > if (sys_paths == null) { > usr_paths = initializePath("java.library.path"); > sys_paths = initializePath("sun.boot.library.path"); > } > > The paths got re-initialized. > > The back-ported fix for "8231584: Deadlock with > ClassLoader.findLibrary and System.loadLibrary call", broke this > hack. The code that lazily re-initializes usr_paths and sys_paths has > gone. However, there was another important change: > ClassLoader.loadLibrary0(), which calls ClassLoader.loadLibrary, is no > longer synchronized, so there may now be concurrent accesses to > ClassLoader.loadLibrary(). > > [ The proposed fix. ] > > I'd like to add this patch to 8u and 11u: > > --- a/src/java.base/share/classes/java/lang/ClassLoader.java Mon Feb 03 > 09:39:39 2020 +0100 > +++ b/src/java.base/share/classes/java/lang/ClassLoader.java Tue Mar 17 > 16:24:10 2020 +0000 > @@ -2562,7 +2562,7 @@ > > // The paths searched for libraries > private static String usr_paths[]; > - private static String sys_paths[]; > + private static volatile String sys_paths[]; > > private static String[] initializePath(String propName) { > String ldPath = System.getProperty(propName, ""); > @@ -2620,6 +2620,10 @@ > boolean isAbsolute) { > ClassLoader loader = > (fromClass == null) ? null : fromClass.getClassLoader(); > + if (sys_paths == null) { > + usr_paths = initializePath("java.library.path"); > + sys_paths = initializePath("sun.boot.library.path"); > + } > assert sys_paths != null : "should be initialized at this point"; > assert usr_paths != null : "should be initialized at this point"; > > This patch does nothing unless sys_paths has been set to null. There > is some slight slowdown because a non-volatile read of sys_paths is > now volatile, but it's IMO insignificant and in any case it's less > than the overhead of the synchronized loadLibrary0(). > > I do not believe that this introduces a race when the user sets > sys_paths to null because > > setProperty("java.library.path") happens before (write volatile sys_paths) > (Program order) > (write volatile sys_paths) synchronizes with (read volatile sys_paths) > (read volatile sys_paths) happens before getProperty("java.lbrary.path") > (Program order) > > If the user sets sys_paths to null before setting "java.library.path" > there is indeed a race and their program might not work, but there > always was a race anyway. > > I think we should do this for 8u and 11u. My justification is that even > though this is an ugly hack, it satisfies a real need and we don't want > to break users' programs in an update. > > What do you think? > > -- > 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 aph at redhat.com Tue Apr 21 15:19:55 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2020 16:19:55 +0100 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: References: Message-ID: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> On 4/21/20 4:10 PM, Langer, Christoph wrote: > what's your status on this? Can we expect you to bring this fix in > for 11.0.8 and 8u262? > > For 11u, we haven't backed out JDK-8231584 yet. So I'd like to > either see your fix going in or to have a decision about a > backout. Maybe in 11u we can also live with the backport of the > upstream patch... I'm not sure. Jeez, I dunno. Every option I can think of is horrible. If I had to guess, I'd say that what we have now is the least bad. 8u continues to work, and the people making the jump to 11 will perhaps find the workarounds they need. But some of the workarounds people use instead of setting sys_paths to null are even worse. Like this one: final Field fieldUsrPaths = ClassLoader.class.getDeclaredField("usr_paths"); fieldUsrPaths.setAccessible(true); fieldUsrPaths.set(System.class.getClassLoader(), usr_paths); This will work in 8u. Maybe we should add a test case to 8u to that we check that both this and the sys_paths-to-null hack keep working. I think that we'd better keep 11 as it is, in the hope that people transitioning to 8 will also transition to fixing the code. -- 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 Apr 21 15:40:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 21 Apr 2020 17:40:18 +0200 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> References: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> Message-ID: <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> On Tue, 2020-04-21 at 16:19 +0100, Andrew Haley wrote: > I think that we'd better keep 11 as it is, in the hope that people > transitioning to 8 will also transition to fixing the code. s/8/11/ +1 Thanks, Severin From aph at redhat.com Tue Apr 21 16:05:10 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Apr 2020 17:05:10 +0100 Subject: RFD: What do we do about programs which set sys_paths to null? In-Reply-To: <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> References: <34fd134b-52ad-a494-3de8-ef9dfdb53644@redhat.com> <47c40da707b7869e449460a52195ace2f95af3dd.camel@redhat.com> Message-ID: On 4/21/20 4:40 PM, Severin Gehwolf wrote: > On Tue, 2020-04-21 at 16:19 +0100, Andrew Haley wrote: >> I think that we'd better keep 11 as it is, in the hope that people >> transitioning to 8 will also transition to fixing the code. > > s/8/11/ Ah, yes, transitioning to 11. Thx. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Apr 22 10:37:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Apr 2020 12:37:39 +0200 Subject: [14] RFR 8240873: Shenandoah: Short-cut arraycopy barriers Message-ID: Original RFE: https://bugs.openjdk.java.net/browse/JDK-8240873 https://hg.openjdk.java.net/jdk/jdk/rev/cc0ffb1d0458 The context is different, because 15 did HeapWord* -> oop conversions on many paths. The whole thing would be followed by other changes that drop volatiles/atomics from update_watermark. 14u webrev: https://cr.openjdk.java.net/~shade/8240873/webrev.14u.01/ Testing: hotspot_gc_shenandoah -- Thanks, -Aleksey From sgehwolf at redhat.com Wed Apr 22 17:00:12 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 22 Apr 2020 19:00:12 +0200 Subject: [11u] RFR: 8243059: Build fails when --with-vendor-name contains a comma Message-ID: <65bb3954617207ec8c2aa2df17f7dec6e6d29f7b.camel@redhat.com> Hi, Could I please get a review of this 11u backport of a build fix? The jdk/jdk patch does not apply cleanly since JDK-8222510[1] isn't in OpenJDK 11u. I.e. this makes the context different and the patch failing to apply. I've manually ported the patch. The gist is: $(VERSION_CFLAGS) => $$(VERSION_CFLAGS) Bug: https://bugs.openjdk.java.net/browse/JDK-8243059 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8243059/jdk11/01/webrev/ original change: https://hg.openjdk.java.net/jdk/jdk/rev/dff3aabdc2f3 Testing: Build fails before, passes after patch. java.vendor property is as expected when it includes commas. Thoughts? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8222510 From aph at redhat.com Thu Apr 23 15:59:32 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Apr 2020 16:59:32 +0100 Subject: [11u] RFR: 8243059: Build fails when --with-vendor-name contains a comma In-Reply-To: <65bb3954617207ec8c2aa2df17f7dec6e6d29f7b.camel@redhat.com> References: <65bb3954617207ec8c2aa2df17f7dec6e6d29f7b.camel@redhat.com> Message-ID: On 4/22/20 6:00 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8243059 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8243059/jdk11/01/webrev/ > original change: https://hg.openjdk.java.net/jdk/jdk/rev/dff3aabdc2f3 > > Testing: Build fails before, passes after patch. java.vendor property > is as expected when it includes commas. Sure, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From cthalinger at twitter.com Fri Apr 24 18:14:35 2020 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 24 Apr 2020 19:14:35 +0100 Subject: [11u] RFR: 8236211: [Graal] compiler/graalunit/GraphTest.java is skipped in all testing Message-ID: <7B5F6F9C-E662-40A5-8B5F-902D8F5E1EAA@twitter.com> https://bugs.openjdk.java.net/browse/JDK-8236211 https://hg.openjdk.java.net/jdk/jdk/rev/9a36b6a6d502 http://cr.openjdk.java.net/~twisti/8236211/webrev/index.html The patches doesn?t apply cleanly but only because of copyright year differences and other small things: $ hg import --partial 8236211.patch applying 8236211.patch patching file test/hotspot/jtreg/compiler/graalunit/GraphTest.java Hunk #1 FAILED at 0 Hunk #2 FAILED at 24 2 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/GraphTest.java.rej patching file test/hotspot/jtreg/compiler/graalunit/NodesTest.java Hunk #1 FAILED at 0 Hunk #2 FAILED at 24 2 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/NodesTest.java.rej patching file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt Hunk #1 FAILED at 9 Hunk #2 succeeded at 15 with fuzz 2 (offset -5 lines). 1 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt.rej patching file test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java Hunk #1 FAILED at 0 1 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java.rej patch applied partially (fix the .rej files and run `hg commit --amend`) From hohensee at amazon.com Mon Apr 27 16:39:38 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 27 Apr 2020 16:39:38 +0000 Subject: [11u] RFR: 8236211: [Graal] compiler/graalunit/GraphTest.java is skipped in all testing Message-ID: <46DA3A33-F792-4F0C-B119-C917A633D039@amazon.com> Lgtm. Paul ?On 4/24/20, 11:17 AM, "jdk-updates-dev on behalf of Christian Thalinger" wrote: https://bugs.openjdk.java.net/browse/JDK-8236211 https://hg.openjdk.java.net/jdk/jdk/rev/9a36b6a6d502 http://cr.openjdk.java.net/~twisti/8236211/webrev/index.html The patches doesn?t apply cleanly but only because of copyright year differences and other small things: $ hg import --partial 8236211.patch applying 8236211.patch patching file test/hotspot/jtreg/compiler/graalunit/GraphTest.java Hunk #1 FAILED at 0 Hunk #2 FAILED at 24 2 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/GraphTest.java.rej patching file test/hotspot/jtreg/compiler/graalunit/NodesTest.java Hunk #1 FAILED at 0 Hunk #2 FAILED at 24 2 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/NodesTest.java.rej patching file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt Hunk #1 FAILED at 9 Hunk #2 succeeded at 15 with fuzz 2 (offset -5 lines). 1 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt.rej patching file test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java Hunk #1 FAILED at 0 1 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java.rej patch applied partially (fix the .rej files and run `hg commit --amend`) From cthalinger at twitter.com Mon Apr 27 18:29:28 2020 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 27 Apr 2020 19:29:28 +0100 Subject: [11u] RFR: 8236211: [Graal] compiler/graalunit/GraphTest.java is skipped in all testing In-Reply-To: <46DA3A33-F792-4F0C-B119-C917A633D039@amazon.com> References: <46DA3A33-F792-4F0C-B119-C917A633D039@amazon.com> Message-ID: <5419DB3C-C8C1-41E7-8677-8FB1CFB254C5@twitter.com> Thanks! Pushed. > On Apr 27, 2020, at 5:39 PM, Hohensee, Paul wrote: > > Lgtm. > > Paul > > ?On 4/24/20, 11:17 AM, "jdk-updates-dev on behalf of Christian Thalinger" wrote: > > https://bugs.openjdk.java.net/browse/JDK-8236211 > https://hg.openjdk.java.net/jdk/jdk/rev/9a36b6a6d502 > http://cr.openjdk.java.net/~twisti/8236211/webrev/index.html > > The patches doesn?t apply cleanly but only because of copyright year differences and other small things: > > $ hg import --partial 8236211.patch > applying 8236211.patch > patching file test/hotspot/jtreg/compiler/graalunit/GraphTest.java > Hunk #1 FAILED at 0 > Hunk #2 FAILED at 24 > 2 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/GraphTest.java.rej > patching file test/hotspot/jtreg/compiler/graalunit/NodesTest.java > Hunk #1 FAILED at 0 > Hunk #2 FAILED at 24 > 2 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/NodesTest.java.rej > patching file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt > Hunk #1 FAILED at 9 > Hunk #2 succeeded at 15 with fuzz 2 (offset -5 lines). > 1 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt.rej > patching file test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java > Hunk #1 FAILED at 0 > 1 out of 2 hunks FAILED -- saving rejects to file test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java.rej > patch applied partially > (fix the .rej files and run `hg commit --amend`) > > From christoph.langer at sap.com Mon Apr 27 18:43:41 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 Apr 2020 18:43:41 +0000 Subject: [11u] RFR: 8236211: [Graal] compiler/graalunit/GraphTest.java is skipped in all testing In-Reply-To: <5419DB3C-C8C1-41E7-8677-8FB1CFB254C5@twitter.com> References: <46DA3A33-F792-4F0C-B119-C917A633D039@amazon.com> <5419DB3C-C8C1-41E7-8677-8FB1CFB254C5@twitter.com> Message-ID: Hi Chris, > Thanks! Pushed. seems like you're not quite familiar with the jdk-updates process yet ?? I can recommend 2 nice Wiki pages for reading: https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix TL;DR: Before you are allowed to push, a maintainer needs to label the bug with "jdk11u-fix-yes". OK, in your case, it's a simple test fix that got a review, so no objections, I've labeled it accordingly. Please take care next time... Cheers Christoph > > > On Apr 27, 2020, at 5:39 PM, Hohensee, Paul > wrote: > > > > Lgtm. > > > > Paul > > > > ?On 4/24/20, 11:17 AM, "jdk-updates-dev on behalf of Christian Thalinger" > cthalinger at twitter.com> wrote: > > > > https://bugs.openjdk.java.net/browse/JDK-8236211 > > https://hg.openjdk.java.net/jdk/jdk/rev/9a36b6a6d502 > > http://cr.openjdk.java.net/~twisti/8236211/webrev/index.html > > > > The patches doesn?t apply cleanly but only because of copyright year > differences and other small things: > > > > $ hg import --partial 8236211.patch > > applying 8236211.patch > > patching file test/hotspot/jtreg/compiler/graalunit/GraphTest.java > > Hunk #1 FAILED at 0 > > Hunk #2 FAILED at 24 > > 2 out of 2 hunks FAILED -- saving rejects to file > test/hotspot/jtreg/compiler/graalunit/GraphTest.java.rej > > patching file test/hotspot/jtreg/compiler/graalunit/NodesTest.java > > Hunk #1 FAILED at 0 > > Hunk #2 FAILED at 24 > > 2 out of 2 hunks FAILED -- saving rejects to file > test/hotspot/jtreg/compiler/graalunit/NodesTest.java.rej > > patching file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt > > Hunk #1 FAILED at 9 > > Hunk #2 succeeded at 15 with fuzz 2 (offset -5 lines). > > 1 out of 2 hunks FAILED -- saving rejects to file > test/hotspot/jtreg/compiler/graalunit/TestPackages.txt.rej > > patching file > test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java > > Hunk #1 FAILED at 0 > > 1 out of 2 hunks FAILED -- saving rejects to file > test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java. > rej > > patch applied partially > > (fix the .rej files and run `hg commit --amend`) > > > > From christoph.langer at sap.com Tue Apr 28 07:30:36 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 Apr 2020 07:30:36 +0000 Subject: [11u]: RFR(S): 8221823: Requested JDialog width is ignored In-Reply-To: References: Message-ID: Hi Goetz, I think the problem list entries exist in 11u-dev. I find them in lines 520 and 521 of test/jdk/ProblemList.txt in my repo. Can you please check this again? Best regards Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Lindenmaier, Goetz > Sent: Dienstag, 21. April 2020 15:52 > To: jdk-updates-dev > Subject: [CAUTION] [11u]: RFR(S): 8221823: Requested JDialog width is > ignored > > Hi, > > I please need review for this downport for parity with 11.0.8-oracle: > http://cr.openjdk.java.net/~goetz/wr20/8221823-JDialog_width_ignored- > jdk11/01/ > > The problemlist patch does not apply. > The tests are not problemlisted in 11u for windows. One of them is > Problemlisted for mac, though. I left that line in place. > > Further I had to change a switch expression to a switch > Statement in the test, else it would not compile. > > Original change: > https://bugs.openjdk.java.net/browse/JDK-8221823 > https://hg.openjdk.java.net/jdk/jdk/rev/19adbbca4307 > > Best regards, > Goetz. From linzang at tencent.com Tue Apr 28 08:05:45 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 28 Apr 2020 08:05:45 +0000 Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Message-ID: Hi All, May I have your help to review this tiny patch, it is a clean backport of 8241638. And this patch also include the backport of 8243539, which is the fix of the copyright update issue of 8241638. Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11/ Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin From linzang at tencent.com Tue Apr 28 15:20:19 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 28 Apr 2020 15:20:19 +0000 Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: References: Message-ID: <04EDAAFD-10B0-4F9B-B947-E44AD2C672C5@tencent.com> Hi Christoph, After rethink of it, I think making two separate patches for backport may be more reasonable, which makes the commit log clear. I will made the patches ASAP and then ask your help to reivew,Thanks! BRs, Lin From: "linzang(??)" Date: Tuesday, April 28, 2020 at 4:05 PM To: "Langer, Christoph" , "jdk-updates-dev at openjdk.java.net" Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi All, May I have your help to review this tiny patch, it is a clean backport of 8241638. And this patch also include the backport of 8243539, which is the fix of the copyright update issue of 8241638. Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11/ Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin From cthalinger at twitter.com Tue Apr 28 16:22:52 2020 From: cthalinger at twitter.com (Christian Thalinger) Date: Tue, 28 Apr 2020 17:22:52 +0100 Subject: [11u] RFR: 8236211: [Graal] compiler/graalunit/GraphTest.java is skipped in all testing In-Reply-To: References: <46DA3A33-F792-4F0C-B119-C917A633D039@amazon.com> <5419DB3C-C8C1-41E7-8677-8FB1CFB254C5@twitter.com> Message-ID: Ahh, damn! I knew I?d do something wrong. Sorry. Will be more careful next time! > On Apr 27, 2020, at 7:43 PM, Langer, Christoph wrote: > > Hi Chris, > >> Thanks! Pushed. > > seems like you're not quite familiar with the jdk-updates process yet ?? > > I can recommend 2 nice Wiki pages for reading: > https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u > https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix > > TL;DR: Before you are allowed to push, a maintainer needs to label the bug with "jdk11u-fix-yes". > > OK, in your case, it's a simple test fix that got a review, so no objections, I've labeled it accordingly. Please take care next time... > > Cheers > Christoph > >> >>> On Apr 27, 2020, at 5:39 PM, Hohensee, Paul >> wrote: >>> >>> Lgtm. >>> >>> Paul >>> >>> ?On 4/24/20, 11:17 AM, "jdk-updates-dev on behalf of Christian Thalinger" >> > cthalinger at twitter.com> wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8236211 >>> https://hg.openjdk.java.net/jdk/jdk/rev/9a36b6a6d502 >>> http://cr.openjdk.java.net/~twisti/8236211/webrev/index.html >>> >>> The patches doesn?t apply cleanly but only because of copyright year >> differences and other small things: >>> >>> $ hg import --partial 8236211.patch >>> applying 8236211.patch >>> patching file test/hotspot/jtreg/compiler/graalunit/GraphTest.java >>> Hunk #1 FAILED at 0 >>> Hunk #2 FAILED at 24 >>> 2 out of 2 hunks FAILED -- saving rejects to file >> test/hotspot/jtreg/compiler/graalunit/GraphTest.java.rej >>> patching file test/hotspot/jtreg/compiler/graalunit/NodesTest.java >>> Hunk #1 FAILED at 0 >>> Hunk #2 FAILED at 24 >>> 2 out of 2 hunks FAILED -- saving rejects to file >> test/hotspot/jtreg/compiler/graalunit/NodesTest.java.rej >>> patching file test/hotspot/jtreg/compiler/graalunit/TestPackages.txt >>> Hunk #1 FAILED at 9 >>> Hunk #2 succeeded at 15 with fuzz 2 (offset -5 lines). >>> 1 out of 2 hunks FAILED -- saving rejects to file >> test/hotspot/jtreg/compiler/graalunit/TestPackages.txt.rej >>> patching file >> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java >>> Hunk #1 FAILED at 0 >>> 1 out of 2 hunks FAILED -- saving rejects to file >> test/hotspot/jtreg/compiler/graalunit/common/GraalUnitTestLauncher.java. >> rej >>> patch applied partially >>> (fix the .rej files and run `hg commit --amend`) >>> >>> > From linzang at tencent.com Tue Apr 28 16:33:26 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Tue, 28 Apr 2020 16:33:26 +0000 Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <04EDAAFD-10B0-4F9B-B947-E44AD2C672C5@tencent.com> References: <04EDAAFD-10B0-4F9B-B947-E44AD2C672C5@tencent.com> Message-ID: <7C085FBE-3315-4D35-8B0C-0485629D4F07@tencent.com> Hi Christoph, Here is the updated patches: Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11_01/ issue: https://bugs.openjdk.java.net/browse/JDK-8243539 webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev11_01/ would you like to help review? Thanks! BRs, Lin From: "linzang(??)" Date: Tuesday, April 28, 2020 at 11:20 PM To: "Langer, Christoph" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi Christoph, After rethink of it, I think making two separate patches for backport may be more reasonable, which makes the commit log clear. I will made the patches ASAP and then ask your help to reivew,Thanks! BRs, Lin From: "linzang(??)" Date: Tuesday, April 28, 2020 at 4:05 PM To: "Langer, Christoph" , "jdk-updates-dev at openjdk.java.net" Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi All, May I have your help to review this tiny patch, it is a clean backport of 8241638. And this patch also include the backport of 8243539, which is the fix of the copyright update issue of 8241638. Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11/ Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin From hohensee at amazon.com Tue Apr 28 17:15:15 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 28 Apr 2020 17:15:15 +0000 Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Message-ID: <9C19913D-6501-43B7-B1C2-B52F5458796D@amazon.com> Lgtm, too. Paul ?On 4/28/20, 9:38 AM, "jdk-updates-dev on behalf of linzang(??)" wrote: Hi Christoph, Here is the updated patches: Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11_01/ issue: https://bugs.openjdk.java.net/browse/JDK-8243539 webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev11_01/ would you like to help review? Thanks! BRs, Lin From: "linzang(??)" Date: Tuesday, April 28, 2020 at 11:20 PM To: "Langer, Christoph" , "jdk-updates-dev at openjdk.java.net" Subject: Re: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi Christoph, After rethink of it, I think making two separate patches for backport may be more reasonable, which makes the commit log clear. I will made the patches ASAP and then ask your help to reivew,Thanks! BRs, Lin From: "linzang(??)" Date: Tuesday, April 28, 2020 at 4:05 PM To: "Langer, Christoph" , "jdk-updates-dev at openjdk.java.net" Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi All, May I have your help to review this tiny patch, it is a clean backport of 8241638. And this patch also include the backport of 8243539, which is the fix of the copyright update issue of 8241638. Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11/ Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin From akashche at redhat.com Wed Apr 29 14:17:26 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 29 Apr 2020 15:17:26 +0100 Subject: [11u] RFR: 8184157: (ch) AsynchronousFileChannel hangs with internal error when reading locked file Message-ID: Hi, Please review the backport of 8184157 to 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8184157 , review links are included there in "links to" section. Original change: https://hg.openjdk.java.net/jdk/jdk/rev/67cce1b84a9a 11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8184157/webrev.00/ 11u exported patch with original attribution: https://cr.openjdk.java.net/~akasko/jdk11u/8184157/67cce1b84a9a_11u.patch Patch applies almost cleanly to 11u, only a trivial change is needed for copyright year ("2018" to "2013") in WindowsAsynchronousFileChannelImpl.java . Test is included with the patch. While I was unable to reproduce the problem with 1000 iterations, it is reproduced always with 100000 iterations. Also ran relevant regression and compatibility tests. PS: regarding 13u, patch applies cleanly to 13u-dev, added jdk13u-fix-request label to the issue. -- -Alex From akashche at redhat.com Wed Apr 29 14:19:22 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Wed, 29 Apr 2020 15:19:22 +0100 Subject: [13u, 11u] RFR: 8236441: Bound MulticastSocket fails when setting outbound interface on Windows Message-ID: <576bb103-43da-351c-2e60-d94628590f1c@redhat.com> Hi, Please review backports of 8236441 to 13u and 11u: Bug: https://bugs.openjdk.java.net/browse/JDK-8236441 Original change: https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde Original review thread: https://mail.openjdk.java.net/pipermail/net-dev/2019-December/013458.html Patches to NetworkInterface_winXP.c and TwoStacksPlainDatagramSocketImpl.c apply cleanly to both 13u and 11u. Minor changes were required for IPMulticastIF.java test. 13u webrev: https://cr.openjdk.java.net/~akasko/jdk13u/8236441/webrev.00/ Test is changed in 13 because behaviour of getOption(IP_MULTICAST_IF) was changed in 14 in JDK-8233307 [1]. So in testGetOptionBound and testGetOptionUnbound this line [2]: assertEquals(ms.getOption(IP_MULTICAST_IF), null); was changed to: NetworkInterface ni = ms.getOption(IP_MULTICAST_IF); if (null != ni) { // JDK-8233307: return value changed assertEquals(ni.getName(), null); } 11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8236441/webrev.00/ In addition to the change above, jdk.test.lib.net.IPSupport class was added in 13 in 8220673 [3] and 8223652 [4]. It is not clear, whether these changes to test code should be backported to 11u. In the webrev above usage of IPSupport is removed (this line [5]). If it is preferred to have these changes backported to 11 before 8236441 - please let me know, I can work on backporting them. Besides that, jdk.test.lib.NetworkConfiguration in 11u lacks multicastInterfaces method that was added in 8207404 [6]. Likewise the above, it is not clear whether this change should be backported to 11u, so its call [7] is changed from: nc.multicastInterfaces(true) to: Stream.concat(nc.ip4MulticastInterfaces(), nc.ip6MulticastInterfaces()).distinct() Testing: test is included with the patch, also ran regression and compatibility tests for MulticastSocket. PS: regarding 13u, it is not clear, what would be the correct process for such backports: whether it should be backported to 13 first and to 11 only after that, whether it should go to 13 at all (P2 issue, but not security related) etc. From the local backporting process point of view, checking the patch with 13 first, and then moving to 11 and 8 seems to be the most convenient. [1] https://bugs.openjdk.java.net/browse/JDK-8233307 [2] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.158 [3] https://bugs.openjdk.java.net/browse/JDK-8220673 [4] https://bugs.openjdk.java.net/browse/JDK-8223652 [5] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.59 [6] https://bugs.openjdk.java.net/browse/JDK-8207404 [7] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.69 -- -Alex From christoph.langer at sap.com Wed Apr 29 22:28:19 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 29 Apr 2020 22:28:19 +0000 Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <7C085FBE-3315-4D35-8B0C-0485629D4F07@tencent.com> References: <04EDAAFD-10B0-4F9B-B947-E44AD2C672C5@tencent.com> <7C085FBE-3315-4D35-8B0C-0485629D4F07@tencent.com> Message-ID: Hi Lin, looks good to me, too. As written in the bug, I?ll sponsor this after one additional round in SAP?s regression testing.. I?ve got one hint: For future backports you could export the original fix with hg export ?git ? and then qimport the resulting file into jdk11u-dev and make your adaptions via hg qrefresh. This will keep the patch metadata (patch comment and Reviewed-by attributions) intact and will ease sponsoring from a webrev. Thanks & Best regards Christoph From: linzang(??) Sent: Dienstag, 28. April 2020 18:33 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi Christoph, Here is the updated patches: Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11_01/ issue: https://bugs.openjdk.java.net/browse/JDK-8243539 webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev11_01/ would you like to help review? Thanks! BRs, Lin From: "linzang(??)" > Date: Tuesday, April 28, 2020 at 11:20 PM To: "Langer, Christoph" >, "jdk-updates-dev at openjdk.java.net" > Subject: Re: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi Christoph, After rethink of it, I think making two separate patches for backport may be more reasonable, which makes the commit log clear. I will made the patches ASAP and then ask your help to reivew,Thanks! BRs, Lin From: "linzang(??)" > Date: Tuesday, April 28, 2020 at 4:05 PM To: "Langer, Christoph" >, "jdk-updates-dev at openjdk.java.net" > Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi All, May I have your help to review this tiny patch, it is a clean backport of 8241638. And this patch also include the backport of 8243539, which is the fix of the copyright update issue of 8241638. Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11/ Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin From linzang at tencent.com Thu Apr 30 02:23:31 2020 From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=) Date: Thu, 30 Apr 2020 02:23:31 +0000 Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: References: <04EDAAFD-10B0-4F9B-B947-E44AD2C672C5@tencent.com> <7C085FBE-3315-4D35-8B0C-0485629D4F07@tencent.com> Message-ID: <9BC9C8C9-7744-4B66-8EE4-440444E63066@tencent.com> Hi Christoph, Thanks for your guidance, I will follow them next time. BRs, Lin From: "Langer, Christoph" Date: Thursday, April 30, 2020 at 6:28 AM To: "linzang(??)" , "jdk-updates-dev at openjdk.java.net" Cc: "Hohensee, Paul" Subject: RE: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) Hi Lin, looks good to me, too. As written in the bug, I?ll sponsor this after one additional round in SAP?s regression testing.. I?ve got one hint: For future backports you could export the original fix with hg export ?git ? and then qimport the resulting file into jdk11u-dev and make your adaptions via hg qrefresh. This will keep the patch metadata (patch comment and Reviewed-by attributions) intact and will ease sponsoring from a webrev. Thanks & Best regards Christoph From: linzang(??) Sent: Dienstag, 28. April 2020 18:33 To: Langer, Christoph ; jdk-updates-dev at openjdk.java.net Subject: Re: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi Christoph, Here is the updated patches: Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11_01/ issue: https://bugs.openjdk.java.net/browse/JDK-8243539 webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev11_01/ would you like to help review? Thanks! BRs, Lin From: "linzang(??)" > Date: Tuesday, April 28, 2020 at 11:20 PM To: "Langer, Christoph" >, "jdk-updates-dev at openjdk.java.net" > Subject: Re: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi Christoph, After rethink of it, I think making two separate patches for backport may be more reasonable, which makes the commit log clear. I will made the patches ASAP and then ask your help to reivew,Thanks! BRs, Lin From: "linzang(??)" > Date: Tuesday, April 28, 2020 at 4:05 PM To: "Langer, Christoph" >, "jdk-updates-dev at openjdk.java.net" > Subject: [11u] Backport 8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set Hi All, May I have your help to review this tiny patch, it is a clean backport of 8241638. And this patch also include the backport of 8243539, which is the fix of the copyright update issue of 8241638. Webrev: http://cr.openjdk.java.net/~lzang/8241638/11u/webrev11/ Issues: https://bugs.openjdk.java.net/browse/JDK-8241638 https://bugs.openjdk.java.net/browse/JDK-8243539 Thanks! BRs, Lin From shade at redhat.com Thu Apr 30 18:38:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Apr 2020 20:38:10 +0200 Subject: [14] RFR (M) 8242082: Shenandoah: Purge Traversal mode Message-ID: <3dd27b04-0039-50ec-9e31-2f5dedfbd332@redhat.com> Original fix: https://bugs.openjdk.java.net/browse/JDK-8242082 https://hg.openjdk.java.net/jdk/jdk/rev/d8d2145c205c The context is quite different due to missing Traversal-related backports. Otherwise it is pretty straightforward. 14u webrev: https://cr.openjdk.java.net/~shade/8242082/webrev.14u.01/ Testing: hotspot_gc_shenandoah, tier{1,2,3} with Shenandoah -- Thanks, -Aleksey From rkennke at redhat.com Thu Apr 30 20:46:40 2020 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 30 Apr 2020 22:46:40 +0200 Subject: [14] RFR (M) 8242082: Shenandoah: Purge Traversal mode In-Reply-To: <3dd27b04-0039-50ec-9e31-2f5dedfbd332@redhat.com> References: <3dd27b04-0039-50ec-9e31-2f5dedfbd332@redhat.com> Message-ID: <14d2b416-71ca-289d-64c9-22e64906c215@redhat.com> Looks good, thanks! Roman > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8242082 > https://hg.openjdk.java.net/jdk/jdk/rev/d8d2145c205c > > The context is quite different due to missing Traversal-related backports. Otherwise it is pretty > straightforward. > > 14u webrev: > https://cr.openjdk.java.net/~shade/8242082/webrev.14u.01/ > > Testing: hotspot_gc_shenandoah, tier{1,2,3} with Shenandoah >