From bourges.laurent at gmail.com Mon May 4 08:15:01 2020 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 4 May 2020 10:15:01 +0200 Subject: RFR: 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: Message-ID: Andrew, Could you approve this 8u fix request ? If yes, I will push it and work on 11th patch. Cheers, Laurent Le mer. 22 avr. 2020 ? 07:18, Alexander Scherbatiy < alexander.scherbatiy at bell-sw.com> a ?crit : > The fix looks good to me. > > Thanks, > Alexander. > On 17.04.2020 14:10, Laurent Bourg?s wrote: > > Could someone review this 8u RFR ? > > PS: next 5 patches will be harder to prepare & review. > > Thanks, > Laurent > > Le mar. 14 avr. 2020 ? 21:20, Laurent Bourg?s > a ?crit : > >> Please review this 10th patch to backport the Marlin renderer from jdk9. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8148886 >> patch: >> http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/m10.8148886.patch >> webrev: >> http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/webrev-8148886.0/ >> unshuffled patch: >> http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/unshuffled/8-m10.8148886.patch >> >> Changes: >> - RendererContext.java: fixed few chunks due to missing changes (Cleaner >> API can not be used in jdk8) >> - fixed Version: to 0.7.3.2 >> >> Complete diff between unshuffled & proposed patch: >> >> --- >> /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/unshuffled/8-m10.8148886.patch >> +++ >> /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/m10.8148886.patch >> @@ -772,10 +772,10 @@ >> - * @see MarlinRenderingEngine#REF_TYPE >> - */ >> - final Object reference; >> - // Smallest object used as Cleaner's parent reference >> - final Object cleanerObj = new Object(); >> // dirty flag indicating an exception occured during pipeline in >> pathTo() >> -@@ -101,7 +98,7 @@ >> + boolean dirty = false; >> + // dynamic array caches kept using weak reference (low memory >> footprint) >> +@@ -99,7 +96,7 @@ >> /** >> * Constructor >> * >> @@ -784,7 +784,7 @@ >> */ >> RendererContext(final String name) { >> if (logCreateContext) { >> -@@ -124,20 +121,6 @@ >> +@@ -122,20 +119,6 @@ >> >> stroker = new Stroker(this); >> dasher = new Dasher(this); >> @@ -819,7 +819,7 @@ >> >> public final class Version { >> >> -- private static final String version = "marlin-0.7.3-Unsafe-OpenJDK"; >> +- private static final String version = "marlin-0.7.2-Unsafe-OpenJDK"; >> + private static final String version = >> "marlin-0.7.3.2-Unsafe-OpenJDK"; >> >> public static String getVersion() { >> >> Cheers, >> Laurent >> > From sgehwolf at redhat.com Mon May 4 13:58:23 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 04 May 2020 15:58:23 +0200 Subject: RFR: [8u] JDK-8035949: Remove unused macro USE_SELECT and clean up Unix version of net_util_md.{c,h} In-Reply-To: References: Message-ID: On Thu, 2020-04-30 at 03:00 +0100, Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8035949 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8035949/webrev.01/ > > This is the first of two backports to cleanup unused #include directives > and dead code in the networking stack. The initial motivation was to > resolve build breakage due to the upcoming release of glibc 2.32, which > removes the long deprecated sys/sysctl.h [0]. I agree we should fix build issues due to removal of sys/sysctl.h on Linux in newer glibc releases. However, rather than backporting two patches, I'd suggest to point-fix it. After all, sys/sysctl.h are unused includes on Linux: diff --git a/src/solaris/native/java/net/PlainDatagramSocketImpl.c b/src/solaris/native/java/net/PlainDatagramSocketImpl.c --- a/src/solaris/native/java/net/PlainDatagramSocketImpl.c +++ b/src/solaris/native/java/net/PlainDatagramSocketImpl.c @@ -41,7 +41,6 @@ #endif #ifdef __linux__ #include -#include #include #include diff --git a/src/solaris/native/java/net/PlainSocketImpl.c b/src/solaris/native/java/net/PlainSocketImpl.c --- a/src/solaris/native/java/net/PlainSocketImpl.c +++ b/src/solaris/native/java/net/PlainSocketImpl.c @@ -43,7 +43,6 @@ #endif #ifdef __linux__ #include -#include #endif #include "jvm.h" This builds fine for me with a glibc which no longer provides sys/sysctl.h and risk seems significantly lower going down this route. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Tue May 5 05:58:45 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 5 May 2020 06:58:45 +0100 Subject: RFR: [8u] JDK-8035949: Remove unused macro USE_SELECT and clean up Unix version of net_util_md.{c,h} In-Reply-To: References: Message-ID: <55be0c7b-4021-5010-6024-ff9bae595c5b@redhat.com> On 04/05/2020 14:58, Severin Gehwolf wrote: > On Thu, 2020-04-30 at 03:00 +0100, Andrew John Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8035949 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8035949/webrev.01/ >> >> This is the first of two backports to cleanup unused #include directives >> and dead code in the networking stack. The initial motivation was to >> resolve build breakage due to the upcoming release of glibc 2.32, which >> removes the long deprecated sys/sysctl.h [0]. > > I agree we should fix build issues due to removal of sys/sysctl.h on > Linux in newer glibc releases. However, rather than backporting two > patches, I'd suggest to point-fix it. After all, sys/sysctl.h are > unused includes on Linux: > > diff --git a/src/solaris/native/java/net/PlainDatagramSocketImpl.c b/src/solaris/native/java/net/PlainDatagramSocketImpl.c > --- a/src/solaris/native/java/net/PlainDatagramSocketImpl.c > +++ b/src/solaris/native/java/net/PlainDatagramSocketImpl.c > @@ -41,7 +41,6 @@ > #endif > #ifdef __linux__ > #include > -#include > #include > #include > > diff --git a/src/solaris/native/java/net/PlainSocketImpl.c b/src/solaris/native/java/net/PlainSocketImpl.c > --- a/src/solaris/native/java/net/PlainSocketImpl.c > +++ b/src/solaris/native/java/net/PlainSocketImpl.c > @@ -43,7 +43,6 @@ > #endif > #ifdef __linux__ > #include > -#include > #endif > > #include "jvm.h" > > This builds fine for me with a glibc which no longer provides > sys/sysctl.h and risk seems significantly lower going down this route. > > Thoughts? > > Thanks, > Severin > I see little risk in this minimal cleanup or I wouldn't have posted it for review. -- 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 May 5 06:09:59 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 5 May 2020 07:09:59 +0100 Subject: OpenJDK 8u262-b01 EA Released Message-ID: <68a3d053-f9d7-3b10-3059-89febc3e13cd@redhat.com> I've made available an early access source bundle for 8u262, based on the tag jdk8u262-b01: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b01-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b01-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: b30368ac540588cf1a7387e718888a854a7055a0d4937e0355bb7ff0ced5fa71 openjdk8u262-b01-ea.tar.xz 0abab2594bbf3d33880cdafa6e77db91ceaf83af331132b73f74e9b947777793 openjdk8u262-b01-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b01-ea.sha256 x86_64 binaries, both with and without JFR, are available here, thanks to Severin Gehwolf: https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/tag/jdk8u262-b01 Changes in 8u262-b01: - JDK-4949105: Access Bridge lacks html tags parsing - JDK-8003209: JFR events for network utilization - JDK-8028431: NullPointerException in DerValue.equals(DerValue) - JDK-8030680: 292 cleanup from default method code assessment - JDK-8035633: TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently - JDK-8041626: Shutdown tracing event - JDK-8041915: Move 8 awt tests to OpenJDK regression tests tree - JDK-8141056: Erroneous assignment in HeapRegionSet.cpp - JDK-8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates - JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" - JDK-8165675: Trace event for thread park has incorrect unit for timeout - JDK-8176182: 4 security tests are not run - JDK-8178910: Problemlist sample tests - JDK-8183925: Decouple crash protection from watcher thread - JDK-8191393: Random crashes during cfree+0x1c - JDK-8195817: JFR.stop should require name of recording - JDK-8195818: JFR.start should increase autogenerated name by one - JDK-8195819: Remove recording=x from jcmd JFR.check output - JDK-8199712: Flight Recorder - JDK-8202578: Revisit location for class unload events - JDK-8202835: jfr/event/os/TestSystemProcess.java fails on missing events - JDK-8203287: Zero fails to build after JDK-8199712 (Flight Recorder) - JDK-8203346: JFR: Inconsistent signature of jfr_add_string_constant - JDK-8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording - JDK-8203921: JFR thread sampling is missing fixes from JDK-8194552 - JDK-8203929: Limit amount of data for JFR.dump - JDK-8205516: JFR tool - JDK-8207392: [PPC64] Implement JFR profiling - JDK-8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it - JDK-8209960: -Xlog:jfr* doesn't work with the JFR - JDK-8210024: JFR calls virtual is_Java_thread from ~Thread() - JDK-8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 - JDK-8211239: Build fails without JFR: empty JFR events signatures mismatch - JDK-8212232: Wrong metadata for the configuration of the cutoff for old object sample events - JDK-8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions - JDK-8213421: Line number information for execution samples always 0 - JDK-8213617: JFR should record the PID of the recorded process - JDK-8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. - JDK-8213914: [TESTBUG] Several JFR VM events are not covered by tests - JDK-8213917: [TESTBUG] Shutdown JFR event is not covered by test - JDK-8213966: The ZGC JFR events should be marked as experimental - JDK-8214542: JFR: Old Object Sample event slow on a deep heap in debug builds - JDK-8214750: Unnecessary

tags in jfr classes - JDK-8214896: JFR Tool left files behind - JDK-8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError - JDK-8214925: JFR tool fails to execute - JDK-8215175: Inconsistencies in JFR event metadata - JDK-8215237: jdk.jfr.Recording javadoc does not compile - JDK-8215284: Reduce noise induced by periodic task getFileSize() - JDK-8215355: Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1) - JDK-8215362: JFR GTest JfrTestNetworkUtilization fails - JDK-8215771: The jfr tool should pretty print reference chains - JDK-8216064: -XX:StartFlightRecording:settings= doesn't work properly - JDK-8216486: Possibility of integer overflow in JfrThreadSampler::run() - JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp - JDK-8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps - JDK-8216578: Remove unused/obsolete method in JFR code - JDK-8216995: Clean up JFR command line processing - JDK-8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT - JDK-8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent - JDK-8218935: Make jfr strncpy uses GCC 8.x friendly - JDK-8223147: JFR Backport - JDK-8223689: Add JFR Thread Sampling Support - JDK-8223690: Add JFR BiasedLock Event Support - JDK-8223691: Add JFR G1 Region Type Change Event Support - JDK-8223692: Add JFR G1 Heap Summary Event Support - JDK-8224172: assert(jfr_is_event_enabled(id)) failed: invariant - JDK-8224475: JTextPane does not show images in HTML rendering - JDK-8226253: JAWS reports wrong number of radio buttons when buttons are hidden. - JDK-8226779: [TESTBUG] Test JFR API from Java agent - JDK-8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys - JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory - JDK-8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" - JDK-8229366: JFR backport allows unchecked writing to memory - JDK-8229401: Fix JFR code cache test failures - JDK-8229708: JFR backport code does not initialize - JDK-8229873: 8229401 broke jdk8u-jfr-incubator - JDK-8230448: [test] JFRSecurityTestSuite.java is failing on Windows - JDK-8230707: JFR related tests are failing - JDK-8230782: Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false - JDK-8230856: Java_java_net_NetworkInterface_getByName0 on unix misses ReleaseStringUTFChars in early return - JDK-8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 - JDK-8231995: two jtreg tests failed after 8229366 is fixed - JDK-8233623: Add classpath exception to copyright in EventHandlerProxyCreator.java file - JDK-8236002: CSR for JFR backport suggests not leaving out the package-info - JDK-8236008: Some backup files were accidentally left in the hotspot tree - JDK-8236074: Missed package-info - JDK-8236174: Should update javadoc since tags - JDK-8238076: Fix OpenJDK 7 Bootstrap Broken by JFR Backport - JDK-8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 - JDK-8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB - JDK-8238589: Necessary code cleanup in JFR for JDK8u - JDK-8238590: Enable JFR by default during compilation in 8u - JDK-8239055: Wrong implementation of VMState.hasListener - JDK-8239476: JDK-8238589 broke windows build by moving OrderedPair - JDK-8239479: minimal1 and zero builds are failing - JDK-8239867: correct over use of INCLUDE_JFR macro - JDK-8240375: Disable JFR by default for July 2020 release - JDK-8241444: Metaspace::_class_vsm not initialized if compressed class pointers are disabled - JDK-8241902: AIX Build broken after integration of JDK-8223147 (JFR Backport) - JDK-8242788: Non-PCH build is broken after JDK-8191393 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 jaroslav.bachorik at datadoghq.com Wed May 6 07:37:57 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 6 May 2020 09:37:57 +0200 Subject: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data In-Reply-To: <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com> References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com> Message-ID: Hi Dennghui, Thanks for taking care of this. The change looks good but with the usual disclaimer "I am not a reviewer". Cheers, -JB- On Wed, May 6, 2020 at 7:25 AM Denghui Dong wrote: > > Hi Jaroslav, > > Sorry for the late reply due to a long holiday. > > > 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > > L113 and L116 - perhaps the commented out asserts can be removed > > completely? > fixed. > > > 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > > L158 - `module_lock` - > `package_lock`? > fixed. > > Thanks for the comments. > Webrev is still located in http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00 > > Cheers, > Denghui Dong > > ------------------------------------------------------------------ > From:Jaroslav Bachor?k > Send Time:2020?4?29?(???) 18:49 > To:???(??) > Cc:jdk8u-dev > Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data > > Hi Denghui, > > I have validated that the backport contains the changes from the > original changeset and that the conflicts were resolved correctly. > > I have only two minor comments: > > 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > L113 and L116 - perhaps the commented out asserts can be removed > completely? > 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > L158 - `module_lock` - > `package_lock`? > > Cheers, > > -JB- > > On Sun, Apr 26, 2020 at 3:52 PM Denghui Dong > wrote: > > > > Hi team, > > Please review the following backport. > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8225797 > > Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2a13c6785ad2 > > Webrev: http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/ > > > > Some code has been commented out because those facilities(e.g. Module and Package) is not supported in 8u, > > so the original patch can not apply cleanly. Matter of fact, the backport is mostly manual. > > I put all reject files in http://cr.openjdk.java.net/~ddong/8225797/rej/ > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > Cheers, > > Denghui Dong From denghui.ddh at alibaba-inc.com Wed May 6 09:01:51 2020 From: denghui.ddh at alibaba-inc.com (=?UTF-8?B?6JGj55m76L6JKOWNk+aYgik=?=) Date: Wed, 06 May 2020 17:01:51 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIDgyMjU3OTc6IFtiYWNrcG9ydF0gT2xkT2JqZWN0U2FtcGxlIGV2ZW50?= =?UTF-8?B?IGNyZWF0ZXMgdW5leHBlY3RlZCBhbW91bnQgb2YgY2hlY2twb2ludCBkYXRh?= In-Reply-To: <8225cc35-fa62-4df2-b7a4-689b9f0726e6.> References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com>, <8225cc35-fa62-4df2-b7a4-689b9f0726e6.> Message-ID: <0be06b28-6912-4f5d-84e5-5edf8833f92b.denghui.ddh@alibaba-inc.com> Thank you, Jaroslav! @Mario, Could you review this backport? Denghui Dong ------------------------------------------------------------------ From:Jaroslav Bachor?k Send Time:2020?5?6?(???) 15:38 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data Hi Dennghui, Thanks for taking care of this. The change looks good but with the usual disclaimer "I am not a reviewer". Cheers, -JB- On Wed, May 6, 2020 at 7:25 AM Denghui Dong wrote: > > Hi Jaroslav, > > Sorry for the late reply due to a long holiday. > > > 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > > L113 and L116 - perhaps the commented out asserts can be removed > > completely? > fixed. > > > 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > > L158 - `module_lock` - > `package_lock`? > fixed. > > Thanks for the comments. > Webrev is still located in http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00 > > Cheers, > Denghui Dong > > ------------------------------------------------------------------ > From:Jaroslav Bachor?k > Send Time:2020?4?29?(???) 18:49 > To:???(??) > Cc:jdk8u-dev > Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data > > Hi Denghui, > > I have validated that the backport contains the changes from the > original changeset and that the conflicts were resolved correctly. > > I have only two minor comments: > > 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > L113 and L116 - perhaps the commented out asserts can be removed > completely? > 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > L158 - `module_lock` - > `package_lock`? > > Cheers, > > -JB- > > On Sun, Apr 26, 2020 at 3:52 PM Denghui Dong > wrote: > > > > Hi team, > > Please review the following backport. > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8225797 > > Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2a13c6785ad2 > > Webrev: http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/ > > > > Some code has been commented out because those facilities(e.g. Module and Package) is not supported in 8u, > > so the original patch can not apply cleanly. Matter of fact, the backport is mostly manual. > > I put all reject files in http://cr.openjdk.java.net/~ddong/8225797/rej/ > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > Cheers, > > Denghui Dong From neugens at redhat.com Wed May 6 10:36:49 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 6 May 2020 12:36:49 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Hi Jaroslav, Sorry I dropped the ball on this one, I went through the changes and they all seem good to me. We need a maintainer to set the jdk8u-fix-yes flag before you can push, but the review is ok. Cheers, Mario On Fri, Apr 24, 2020 at 12:20 PM Jaroslav Bachor?k wrote: > > Resending again in plain text to make the filters pass. > > ---------- Forwarded message --------- > From: Jaroslav Bachor?k > Date: Mon, Apr 20, 2020 at 4:02 PM > Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() > and Jfr:on_vm_start() start-up order for correct option parsing > To: jdk8u-dev > > > Please review the following backport > > JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 > Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ > > The backport patch applied rather cleanly, not considering several > offset adjustments. > The only part that required an additional change was modifying the > place where java lang classes initialization happens in thread.cpp - > those classes need to be initialized before 'Jfr::on_create_vm_2()' is > called. In order to achieve this I just moved around the whole > codeblock related to java lang classes initialization. > > All tests from jdk_jfr are passing after this patch has been applied. > > Thanks! > > -JB- > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Wed May 6 14:02:34 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 06 May 2020 16:02:34 +0200 Subject: Regression in test sun/misc/Version/Version.java with 8u262-b01 Message-ID: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> Hi, This is a heads-up that jtreg test sun/misc/Version/Version.java is failing since 8u262-b01 (worked last with 8u252 batch). Failure looks like this: jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1 JDK version = 1.8.0_262-b1 1.8.0_6-b1 ----------System.err:(13/788)---------- java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1 at Version.main(Version.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'. I'm looking into it. Thanks, Severin From abrygin at azul.com Wed May 6 14:31:23 2020 From: abrygin at azul.com (Andrew Brygin) Date: Wed, 6 May 2020 17:31:23 +0300 Subject: Regression in test sun/misc/Version/Version.java with 8u262-b01 In-Reply-To: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> References: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> Message-ID: <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> The root cause of the problem is that jdk_version_info and jvm_version_info structures store the update number in 8bit fields. 262 is 0x106, so now the update number does not fit the fields capacity, and after truncation we see update number 6 instead of 262. Note that the same problem exists in openjdk7 starting January 2020. Thanks, Andrew On 06/05/2020 17:02, Severin Gehwolf wrote: > Hi, > > This is a heads-up that jtreg test sun/misc/Version/Version.java is > failing since 8u262-b01 (worked last with 8u252 batch). Failure looks > like this: > > jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1 > JDK version = 1.8.0_262-b1 1.8.0_6-b1 > ----------System.err:(13/788)---------- > java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1 > at Version.main(Version.java:47) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.lang.Thread.run(Thread.java:748) > > The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'. > > I'm looking into it. > > Thanks, > Severin > From sgehwolf at redhat.com Wed May 6 15:59:14 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 06 May 2020 17:59:14 +0200 Subject: Regression in test sun/misc/Version/Version.java with 8u262-b01 In-Reply-To: <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> References: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> Message-ID: Hi Andrew, On Wed, 2020-05-06 at 17:31 +0300, Andrew Brygin wrote: > The root cause of the problem is that jdk_version_info and > jvm_version_info structures store the update number in 8bit fields. > > 262 is 0x106, so now the update number does not fit the fields capacity, > and after truncation we see update number 6 instead of 262. Thanks for this. That's right. (gdb) 100 info->update_version = jdk_update_version; (gdb) p jdk_update_version $8 = 262 (gdb) p info->update_version $10 = 6 Since 2^8-1 = 255 > 252 we start to see this issue with the 262 update cycle. Thanks, Severin > Note that the same problem exists in openjdk7 starting January 2020. > > Thanks, > Andrew > > On 06/05/2020 17:02, Severin Gehwolf wrote: > > Hi, > > > > This is a heads-up that jtreg test sun/misc/Version/Version.java is > > failing since 8u262-b01 (worked last with 8u252 batch). Failure looks > > like this: > > > > jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1 > > JDK version = 1.8.0_262-b1 1.8.0_6-b1 > > ----------System.err:(13/788)---------- > > java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1 > > at Version.main(Version.java:47) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > at java.lang.Thread.run(Thread.java:748) > > > > The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'. > > > > I'm looking into it. > > > > Thanks, > > Severin > > From adinn at redhat.com Thu May 7 09:53:24 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 10:53:24 +0100 Subject: Fwd: [aarch64-port-dev ] RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: References: Message-ID: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> Forwarding to also include jdk8u-dev -------- Forwarded Message -------- Subject: [aarch64-port-dev ] RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered Date: Thu, 7 May 2020 10:14:00 +0100 From: Andrew Haley To: aarch64-port-dev at openjdk.java.net This is Nick Gasson's patch, stripped of the changes that were due to adaptations made because of later changes to MacroAssembler. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.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 adinn at redhat.com Thu May 7 09:53:59 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 10:53:59 +0100 Subject: Fwd: [aarch64-port-dev ] RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 In-Reply-To: References: Message-ID: Forwarding to also include jdk8u-dev -------- Forwarded Message -------- Subject: [aarch64-port-dev ] RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 Date: Thu, 7 May 2020 10:14:23 +0100 From: Andrew Haley To: aarch64-port-dev at openjdk.java.net The final patch for this bug was very complex and did not apply to jdk8u. This patch is almost identical to Dmitrij Pochepko's first proposal, so he still gets the credit. It is also far, far simpler than the final patch. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.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 adinn at redhat.com Thu May 7 09:54:31 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 10:54:31 +0100 Subject: Fwd: [aarch64-port-dev ] RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: Message-ID: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Forwarding to also include jdk8u-dev -------- Forwarded Message -------- Subject: [aarch64-port-dev ] RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command Date: Thu, 7 May 2020 10:14:29 +0100 From: Andrew Haley To: aarch64-port-dev at openjdk.java.net This is a somewhat cut-down and adjusted version of Nick Gasson's patch, which also rearranged code elsewhere. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413.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 sgehwolf at redhat.com Thu May 7 10:20:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 12:20:05 +0200 Subject: Regression in test sun/misc/Version/Version.java with 8u262-b01 In-Reply-To: <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> References: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> Message-ID: Hi, On Wed, 2020-05-06 at 17:31 +0300, Andrew Brygin wrote: > The root cause of the problem is that jdk_version_info and > jvm_version_info structures store the update number in 8bit fields. > > 262 is 0x106, so now the update number does not fit the fields capacity, > and after truncation we see update number 6 instead of 262. > > Note that the same problem exists in openjdk7 starting January 2020. > > Thanks, > Andrew > > On 06/05/2020 17:02, Severin Gehwolf wrote: > > Hi, > > > > This is a heads-up that jtreg test sun/misc/Version/Version.java is > > failing since 8u262-b01 (worked last with 8u252 batch). Failure looks > > like this: > > > > jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1 > > JDK version = 1.8.0_262-b1 1.8.0_6-b1 > > ----------System.err:(13/788)---------- > > java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1 > > at Version.main(Version.java:47) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > at java.lang.Thread.run(Thread.java:748) > > > > The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'. > > > > I'm looking into it. I've created this bug to track this: https://bugs.openjdk.java.net/browse/JDK-8244548 Thanks, Severin From adinn at redhat.com Thu May 7 10:32:02 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 11:32:02 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> References: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> Message-ID: <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> On 07/05/2020 10:53, Andrew Dinn wrote: > This is Nick Gasson's patch, stripped of the changes that were due > to adaptations made because of later changes to MacroAssembler. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.patch Well, this patch looks fine apart from the small detail that the line at which it is to be applied is wrong. I managed to apply it but only with a suitable fuzz: "Hunk #1 succeeded at 3333 with fuzz 1 (offset -1506 lines)." Is the line number disparity there because this is /literally/ the original jdk13u patch Nick suggested on the mail thread? Or is there something else I have missed? That aside I entirely agree that this is the correct /backport/ patch. It precisely fixes the original problem without pulling in all the gubbins that was approrpiate upstream in order to remove technical debt. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From abrygin at azul.com Thu May 7 10:33:04 2020 From: abrygin at azul.com (Andrew Brygin) Date: Thu, 7 May 2020 13:33:04 +0300 Subject: Regression in test sun/misc/Version/Version.java with 8u262-b01 In-Reply-To: References: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> Message-ID: Hello Severin, thanks for creating the bug. Just a minor question regarding the proposed change for jdk_version_info: shall we reduce the size of reserved1 field from 16 to 8 in order to preserve the size of the whole structure? Thanks, Andrew On 07/05/2020 13:20, Severin Gehwolf wrote: > Hi, > > On Wed, 2020-05-06 at 17:31 +0300, Andrew Brygin wrote: >> The root cause of the problem is that jdk_version_info and >> jvm_version_info structures store the update number in 8bit fields. >> >> 262 is 0x106, so now the update number does not fit the fields capacity, >> and after truncation we see update number 6 instead of 262. >> >> Note that the same problem exists in openjdk7 starting January 2020. >> >> Thanks, >> Andrew >> >> On 06/05/2020 17:02, Severin Gehwolf wrote: >>> Hi, >>> >>> This is a heads-up that jtreg test sun/misc/Version/Version.java is >>> failing since 8u262-b01 (worked last with 8u252 batch). Failure looks >>> like this: >>> >>> jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1 >>> JDK version = 1.8.0_262-b1 1.8.0_6-b1 >>> ----------System.err:(13/788)---------- >>> java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1 >>> at Version.main(Version.java:47) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >>> at java.lang.Thread.run(Thread.java:748) >>> >>> The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'. >>> >>> I'm looking into it. > > I've created this bug to track this: > https://bugs.openjdk.java.net/browse/JDK-8244548 > > Thanks, > Severin > From adinn at redhat.com Thu May 7 10:43:01 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 11:43:01 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 In-Reply-To: References: Message-ID: On 07/05/2020 10:53, Andrew Dinn wrote: > Forwarding to also include jdk8u-dev > > > -------- Forwarded Message -------- > Subject: [aarch64-port-dev ] RFR: Backport: 8216989: > CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does > not check for zero length on AARCH64 > Date: Thu, 7 May 2020 10:14:23 +0100 > From: Andrew Haley > To: aarch64-port-dev at openjdk.java.net > > The final patch for this bug was very complex and did not apply to > jdk8u. This patch is almost identical to Dmitrij Pochepko's first > proposal, so he still gets the credit. It is also far, far simpler > than the final patch. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.patch Hmm, indeed, unbelievably simpler and yet still correct. All those layers of abstraction the upstream patch had to work its way through must be buying us something though, surely? ;-> regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Thu May 7 10:47:43 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 11:47:43 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> References: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Message-ID: On 07/05/2020 10:54, Andrew Dinn wrote: > Forwarding to also include jdk8u-dev > > > -------- Forwarded Message -------- > Subject: [aarch64-port-dev ] RFR: Backport: 8209413: AArch64: NPE in > clhsdb jstack command > Date: Thu, 7 May 2020 10:14:29 +0100 > From: Andrew Haley > To: aarch64-port-dev at openjdk.java.net > > This is a somewhat cut-down and adjusted version of Nick Gasson's > patch, which also rearranged code elsewhere. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413.patch Something is definitely wrong here as I cannot apply this patch without failures: [adinn at localhost jdk8u-aarch64-shenandoah]$ hg -R hotspot/ patch 8209413.patch.diff applying 8209413.patch.diff patching file src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Hunk #1 FAILED at 0 1 out of 3 hunks FAILED -- saving rejects to file src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp.rej patching file src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Hunk #2 FAILED at 1119 1 out of 2 hunks FAILED -- saving rejects to file src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp.rej abort: patch failed to apply Am I doing something wrong? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Thu May 7 11:42:44 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 13:42:44 +0200 Subject: Regression in test sun/misc/Version/Version.java with 8u262-b01 In-Reply-To: References: <5efef4cce36a20855980f78995b3d858990f437a.camel@redhat.com> <62cd68b6-710d-6cef-a318-f9b6a94f1893@azul.com> Message-ID: Hi Andrew, On Thu, 2020-05-07 at 13:33 +0300, Andrew Brygin wrote: > Hello Severin, > > thanks for creating the bug. > > Just a minor question regarding the proposed change for > jdk_version_info: shall we reduce the size of reserved1 field from 16 > to 8 in order to preserve the size of the whole structure? It's a possibility. Let's decide on that when I propose for review. Sound good? Thanks, Severin > Thanks, > Andrew > > On 07/05/2020 13:20, Severin Gehwolf wrote: > > Hi, > > > > On Wed, 2020-05-06 at 17:31 +0300, Andrew Brygin wrote: > > > The root cause of the problem is that jdk_version_info and > > > jvm_version_info structures store the update number in 8bit fields. > > > > > > 262 is 0x106, so now the update number does not fit the fields capacity, > > > and after truncation we see update number 6 instead of 262. > > > > > > Note that the same problem exists in openjdk7 starting January 2020. > > > > > > Thanks, > > > Andrew > > > > > > On 06/05/2020 17:02, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > This is a heads-up that jtreg test sun/misc/Version/Version.java is > > > > failing since 8u262-b01 (worked last with 8u252 batch). Failure looks > > > > like this: > > > > > > > > jdkVersionInfo: input=1.8.0_262-ea-b01 output=1.8.0_262-b1 > > > > JDK version = 1.8.0_262-b1 1.8.0_6-b1 > > > > ----------System.err:(13/788)---------- > > > > java.lang.RuntimeException: Unmatched version: 1.8.0_262-b1 vs 1.8.0_6-b1 > > > > at Version.main(Version.java:47) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > at java.lang.reflect.Method.invoke(Method.java:498) > > > > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > > > > at java.lang.Thread.run(Thread.java:748) > > > > > > > > The issue is that sun.misc.Version.jdkUpdateVersion() returns '6' rather than '262'. > > > > > > > > I'm looking into it. > > > > I've created this bug to track this: > > https://bugs.openjdk.java.net/browse/JDK-8244548 > > > > Thanks, > > Severin > > From sgehwolf at redhat.com Thu May 7 12:22:00 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 14:22:00 +0200 Subject: [8u] RFR(XS): 8243059: Build fails when --with-vendor-name contains a comma Message-ID: <4d539698e2fcd4ce606e62723cdd9d815b0af473.camel@redhat.com> Hi, Could I please get a review of this OpenJDK 8u backport for JDK- 8243059? The build system is wildly different to JDK 11 and later, thus is the patch. In turns out on JDK 8, SetupLauncher isn't using eval() so the evaluation of the comma too early isn't an issue there. However, on JDK 8u, the same issue is present when COMPANY_NAME is being evaluated too early in SetupArchive. COMPANY_NAME may contain a comma an that breaks the embedded rule for creating the jars. Bug: https://bugs.openjdk.java.net/browse/JDK-8243059 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8243059/jdk8/01/webrev/ Testing: building with --with-vendor-name="foo, bar". Fails before, passes after patch. Thoughts? Thanks, Severin From aph at redhat.com Thu May 7 12:53:33 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 13:53:33 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> References: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> Message-ID: On 5/7/20 11:32 AM, Andrew Dinn wrote: > On 07/05/2020 10:53, Andrew Dinn wrote: >> This is Nick Gasson's patch, stripped of the changes that were due >> to adaptations made because of later changes to MacroAssembler. >> >> http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.patch > Well, this patch looks fine apart from the small detail that the line at > which it is to be applied is wrong. I managed to apply it but only with > a suitable fuzz: > > "Hunk #1 succeeded at 3333 with fuzz 1 (offset -1506 lines)." > > Is the line number disparity there because this is /literally/ the > original jdk13u patch Nick suggested on the mail thread? Or is there > something else I have missed? I have no idea! I'm surprised that hg import looks 1506 lines away. > That aside I entirely agree that this is the correct /backport/ patch. > It precisely fixes the original problem without pulling in all the > gubbins that was approrpiate upstream in order to remove technical debt. OK. -- 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 Thu May 7 12:54:09 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 13:54:09 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 In-Reply-To: References: Message-ID: <504a1c4e-c685-da94-c7c0-3ca742dbec94@redhat.com> On 5/7/20 11:43 AM, Andrew Dinn wrote: > On 07/05/2020 10:53, Andrew Dinn wrote: >> Forwarding to also include jdk8u-dev >> >> >> -------- Forwarded Message -------- >> Subject: [aarch64-port-dev ] RFR: Backport: 8216989: >> CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does >> not check for zero length on AARCH64 >> Date: Thu, 7 May 2020 10:14:23 +0100 >> From: Andrew Haley >> To: aarch64-port-dev at openjdk.java.net >> >> The final patch for this bug was very complex and did not apply to >> jdk8u. This patch is almost identical to Dmitrij Pochepko's first >> proposal, so he still gets the credit. It is also far, far simpler >> than the final patch. >> >> http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.patch > Hmm, indeed, unbelievably simpler and yet still correct. All those > layers of abstraction the upstream patch had to work its way through > must be buying us something though, surely? ;-> You might like to think so; I couldn't possibly comment. -- 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 nick.gasson at arm.com Thu May 7 10:48:25 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 07 May 2020 18:48:25 +0800 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> References: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> Message-ID: <85mu6kaume.fsf@arm.com> On 05/07/20 18:32 pm, Andrew Dinn wrote: > > That aside I entirely agree that this is the correct /backport/ patch. > It precisely fixes the original problem without pulling in all the > gubbins that was approrpiate upstream in order to remove technical debt. > Looks right to me too. It's the same as an earlier version of the patch before it was changed to use cmpxchg. -- Thanks, Nick From sgehwolf at redhat.com Thu May 7 13:22:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 15:22:42 +0200 Subject: Options for fixing JapanEraNameCompatTest in OpenJDK 8u In-Reply-To: <0ebbb2ba3cb1f77df2db36958aa7a627cf09310e.camel@redhat.com> References: <0ebbb2ba3cb1f77df2db36958aa7a627cf09310e.camel@redhat.com> Message-ID: <331592ac8717012b6b4dc2b588620ca5fa4329d3.camel@redhat.com> Hi, On Tue, 2020-03-10 at 19:56 +0100, Severin Gehwolf wrote: > Hi, > > One of the failing tier1 tests in OpenJDK 8u is: > test/java/util/Calendar/JapanEraNameCompatTest.java > > It fails with: > java.lang.AssertionError: expected [Reiva] but found [\u0420\u0435\u0438\u0432\u0430] > at org.testng.Assert.fail(Assert.java:94) > test JapanEraNameCompatTest.testChronoJapanEraDisplayName(no, "Reiwa", "R"): failure > java.lang.AssertionError: expected [R] but found [Reiwa] > > I've looked into this and the test got added with the 8u backport of > JDK-8218781[1]. The reason why this fails for 8u and not for 11u is > because the locale data in 8u is different. I assume the 8u backport[2] > of 8218781 didn't include JavaTimeSupplementary_sr_Latn.java and > JavaTimeSupplementary_no.java changes since the prerequisite JDK- > 8008577[3] is not present in JDK 8u. Rightfully so. I don't think we'd > want to backport JDK-8008577 (switch to CLDR Locale Data by default) in > 8u. Long story short, we'd have two options to fix the test in 8u: > > Option 1: > Include necessary bits from JDK-8008577 and missing pieces from the > original JDK-8218781 changes for 'sr-Latn', 'no', 'sv', 'nl', 'lt', > 'in', 'hr' locales. 'sr-Latn' and 'no' are the ones which the test > exercises (webrev only includes 'sr-Latn' and 'no' locales for now): > http://cr.openjdk.java.net/~sgehwolf/webrevs/JapanEraNameCompatTest/option1/webrev/ > > Option 2: > Accept the fact that locale data for sr-Latn and no (and others) are > inferior to 11u locale data in the JRE provider and "fix" the test to > not exercise those locales. Other missing locales work because they > fall back to root locale: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JapanEraNameCompatTest/option2/webrev/ > > Either way this calls for an 8u-only bug and fix IMO. > > I'd propose to go with option 1. If consensus is that, I'll propose > this for review. Thoughts? Anyone? > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8218781 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5cf8e52254c2 > [3] https://bugs.openjdk.java.net/browse/JDK-8008577 From aph at redhat.com Thu May 7 13:38:56 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 14:38:56 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Message-ID: On 5/7/20 11:47 AM, Andrew Dinn wrote: > > [adinn at localhost jdk8u-aarch64-shenandoah]$ hg -R hotspot/ patch > 8209413.patch.diff > applying 8209413.patch.diff > patching file src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp > Hunk #1 FAILED at 0 > 1 out of 3 hunks FAILED -- saving rejects to file > src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp.rej > patching file src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp > Hunk #2 FAILED at 1119 > 1 out of 2 hunks FAILED -- saving rejects to file > src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp.rej > abort: patch failed to apply > > Am I doing something wrong? No. The machine I was using is unstable, and the third time I logged back in to restart the tests I, er, seem to have used an old tree. Argh. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413-v2.patch > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > P.S. If you start your sig with the line "-- " it'll make life easier for people who reply to you. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu May 7 14:27:51 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 15:27:51 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Message-ID: <0c7bb876-9992-1827-0924-9418da52545f@redhat.com> On 07/05/2020 14:38, Andrew Haley wrote: > No. The machine I was using is unstable, and the third time I logged back > in to restart the tests I, er, seem to have used an old tree. Argh. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413-v2.patch Ok, so I note that you chose to ignore the updates to stubGenerator_aarch64.cpp and macroAssembler_aarch64.cpp. I assume not because they are incorrect but because they were not needed to fix this specific issue? That seems entirely reasonable to me. The changes you have chosen to apply all look good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sgehwolf at redhat.com Thu May 7 15:09:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 17:09:05 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result Message-ID: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Hi, Please review this OpenJDK 8u fix for an issue where the update version as configured via --with-update-version=XXX might overflow in internal JDK structures and thus, will get reported wrong. In particular, only 1 byte is being reserved for the update versions internally. That is, it works fine up to a configured update version of 255 (2^8 - 1). We've passed that in OpenJDK 8u with the 8u262 cycle currently in EA. Hence, we are now seeing this issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8244548 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/02/ testing: Linux tier 1 The proposed fix is to extend the update_version field in jdk_version_info from 8 to 16 bit and to use 16 bit of the jvm_version integer in jvm_version_info. Thus, the new upper bound for update version number is 2^16-1 => 65535 which should be sufficient. I don't think OpenJDK 8u will live that long ;-) jvm_version_info.jvm_version currently holds this quadruplet: Most significant 8 bits => major version, followed by 8 bits => minor version, followed by 8 bits => micro version, followed by 8 bits => build version. Note that JVM minor version represents the update version as passed in via configure and the micro version is currently not used (always 0). See vm_version.cpp lines 100-102 where only major, minor and build number are ever been set. Knowing this, we can still preserve the same behavior after patch by defining JVM_VERSION_MICRO to 0 for any version. For jdk_version_info the fix is simpler, since the update_version is a separate field for which I've extended it to 16 bit. Andrew Brygin suggested to reduce the reserved1 field from currently 16 bit to 8 bit since we are extending update_version by 8 bits, thus making the whole structure grow. I'm not sure reducing reserved1 to 8 bits so as to not grow the structure would be necessary, but I'd be happy to do so if there is such consensus. Thoughts? Thanks, Severin From stooke at redhat.com Thu May 7 15:55:13 2020 From: stooke at redhat.com (Simon Tooke) Date: Thu, 7 May 2020 11:55:13 -0400 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: (disclaimer: I am not a reviewer) I believe it's a "good thing" to shrink the reserved1 bitfield, as I suspect the entire struct grows by 4 bytes otherwise. Original: 644 unsigned int jdk_version; /* Consists of major, minor, micro (n.n.n) */ 1645 /* and build number (xx) */ 1646 unsigned int update_version : 8; /* Update release version (uu) */ 1647 unsigned int special_update_version : 8; /* Special update release version (c)*/ 1648 unsigned int reserved1 : 16; 1649 unsigned int reserved2; The proposed patch: 44 unsigned int jdk_version; /* Consists of major, minor, micro (n.n.n) */ 1645 /* and build number (xx) */ 1646 unsigned int update_version : 16; /* Update release version (uu) */ 1647 unsigned int special_update_version : 8; /* Special update release version (c)*/ 1648 unsigned int reserved1 : 16; 1649 unsigned int reserved2; Note that the original sum of bitfields is 32 bits, so it will fit into a 4 byte int (which it is surrounded by) The proposed sum of bitfields is 40 bits, which will probably cause a new 4 byte bitfield to be generated under the hood. -Simon On 2020-05-07 11:09 a.m., Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u fix for an issue where the update version > as configured via --with-update-version=XXX might overflow in internal > JDK structures and thus, will get reported wrong. In particular, only 1 > byte is being reserved for the update versions internally. That is, it > works fine up to a configured update version of 255 (2^8 - 1). We've > passed that in OpenJDK 8u with the 8u262 cycle currently in EA. Hence, > we are now seeing this issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244548 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/02/ > testing: Linux tier 1 > > The proposed fix is to extend the update_version field in > jdk_version_info from 8 to 16 bit and to use 16 bit of the jvm_version > integer in jvm_version_info. Thus, the new upper bound for update > version number is 2^16-1 => 65535 which should be sufficient. I don't > think OpenJDK 8u will live that long ;-) > > jvm_version_info.jvm_version currently holds this quadruplet: > > Most significant 8 bits => major version, followed by 8 bits => minor > version, followed by 8 bits => micro version, followed by 8 bits => > build version. Note that JVM minor version represents the update > version as passed in via configure and the micro version is currently > not used (always 0). See vm_version.cpp lines 100-102 where only major, > minor and build number are ever been set. Knowing this, we can still > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > 0 for any version. > > For jdk_version_info the fix is simpler, since the update_version is a > separate field for which I've extended it to 16 bit. Andrew Brygin > suggested to reduce the reserved1 field from currently 16 bit to 8 bit > since we are extending update_version by 8 bits, thus making the whole > structure grow. I'm not sure reducing reserved1 to 8 bits so as to not > grow the structure would be necessary, but I'd be happy to do so if > there is such consensus. > > Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Thu May 7 16:45:04 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 18:45:04 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: <5985721d33ebed06e5d1d23dddae7b9c4f5acc79.camel@redhat.com> Hi Simon, On Thu, 2020-05-07 at 11:55 -0400, Simon Tooke wrote: > (disclaimer: I am not a reviewer) Thanks for the review. > > I believe it's a "good thing" to shrink the reserved1 bitfield, as I > suspect the entire struct grows by 4 bytes otherwise. > > > Original: > > 644 unsigned int jdk_version; /* Consists of major, minor, micro (n.n.n) > */ 1645 /* and build number (xx) */ 1646 unsigned int update_version : > 8; /* Update release version (uu) */ 1647 unsigned int > special_update_version : 8; /* Special update release version (c)*/ 1648 > unsigned int reserved1 : 16; 1649 unsigned int reserved2; The proposed > patch: 44 unsigned int jdk_version; /* Consists of major, minor, micro > (n.n.n) */ 1645 /* and build number (xx) */ 1646 unsigned int > update_version : 16; /* Update release version (uu) */ 1647 unsigned int > special_update_version : 8; /* Special update release version (c)*/ 1648 > unsigned int reserved1 : 16; 1649 unsigned int reserved2; Note that the > original sum of bitfields is 32 bits, so it will fit into a 4 byte int > (which it is surrounded by) The proposed sum of bitfields is 40 bits, > which will probably cause a new 4 byte bitfield to be generated under > the hood. Sure. Updated webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/03/ Thanks, Severin > -Simon > > > On 2020-05-07 11:09 a.m., Severin Gehwolf wrote: > > Hi, > > > > Please review this OpenJDK 8u fix for an issue where the update version > > as configured via --with-update-version=XXX might overflow in internal > > JDK structures and thus, will get reported wrong. In particular, only 1 > > byte is being reserved for the update versions internally. That is, it > > works fine up to a configured update version of 255 (2^8 - 1). We've > > passed that in OpenJDK 8u with the 8u262 cycle currently in EA. Hence, > > we are now seeing this issue. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244548 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/02/ > > testing: Linux tier 1 > > > > The proposed fix is to extend the update_version field in > > jdk_version_info from 8 to 16 bit and to use 16 bit of the jvm_version > > integer in jvm_version_info. Thus, the new upper bound for update > > version number is 2^16-1 => 65535 which should be sufficient. I don't > > think OpenJDK 8u will live that long ;-) > > > > jvm_version_info.jvm_version currently holds this quadruplet: > > > > Most significant 8 bits => major version, followed by 8 bits => minor > > version, followed by 8 bits => micro version, followed by 8 bits => > > build version. Note that JVM minor version represents the update > > version as passed in via configure and the micro version is currently > > not used (always 0). See vm_version.cpp lines 100-102 where only major, > > minor and build number are ever been set. Knowing this, we can still > > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > > 0 for any version. > > > > For jdk_version_info the fix is simpler, since the update_version is a > > separate field for which I've extended it to 16 bit. Andrew Brygin > > suggested to reduce the reserved1 field from currently 16 bit to 8 bit > > since we are extending update_version by 8 bits, thus making the whole > > structure grow. I'm not sure reducing reserved1 to 8 bits so as to not > > grow the structure would be necessary, but I'd be happy to do so if > > there is such consensus. > > > > Thoughts? > > > > Thanks, > > Severin > > From mbalao at redhat.com Thu May 7 17:56:44 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 7 May 2020 14:56:44 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> Message-ID: <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> Hi, To proceed with the review of this proposal, we agreed on the following: * There will be a rebase of Webrev.04 to get TLS-related files from 11.0.7 * Webrev.05 will be based on 8u262 (so no changes between 8u242 / 8uMR3 and 8u262 should be missing) * Files replaced will appear as new files in the changeset, and changes on top of them will appear in a separate patch * This view is mainly for reviewing purposes. We will then decide how to make it visible in the repository. * Current test failures on sun/security/ssl will be fixed * No regressions should be observable in JDK-tier1, JDK-tier2 and sun/security/ssl * As a review strategy, I'll separate patch changes in 2 groups: * Changes within sun/security/ssl namespace * Focus will be on changes required on top of replaced files to work on 8u * This should work as a coherent unit, implementation of the SunJSSE provider and javax.net.ssl API * Changes out of sun/security/ssl namespace * Focus will be on each particular change * File replacement is not expected here * For each group, I need to understand the rational behind each change and the implications on other files (involved changesets scope) * We will document these findings in the public list (here) * Azul may decide to propose a fallback scheme to bring the 'legacy' 8u TLS engine as a configurable non-default provider. This was not strictly required as part of my review but we will certainly evaluate it. * More independent reviewers are welcomed. So far, there are internal reviewers from Azul and externals from Red Hat. * Target date for inclusion is still under discussion; but most of the review work is expected for the end of May. Thanks, Martin.- From sergei.tsypanov at yandex.ru Fri May 8 07:23:16 2020 From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=) Date: Fri, 08 May 2020 09:23:16 +0200 Subject: Backport of JDK-8054221 into JDK 8u Message-ID: <138351588920305@mail.yandex.ru> Hello, https://bugs.openjdk.java.net/browse/JDK-8054221 fixed in JDK9 significantly improves performance of StringJoiner by replacing inner StringBuilder with String[]. I've backported the changes into JDK8u (patch attached) and measured performance with this benchmark: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g", "-XX:+UseParallelGC"}) public class StringJoinerBenchmark { @Benchmark public String stringJoiner(Data data) { return joinWithStringJoiner(data.stringArray); } private static String joinWithStringJoiner(String[] stringArray) { StringJoiner joiner = new StringJoiner(",", "[", "]"); for (String str : stringArray) { joiner.add(str); } return joiner.toString(); } @State(Scope.Thread) public static class Data { @Param({"1", "5", "10", "100"}) private int length; @Param({"1", "5", "10", "100"}) private int count; private String[] stringArray; @Setup public void setup() { stringArray = new String[count]; String alphabet = "abcdefghijklmnopqrstuvwxyz"; for (int i = 0; i < count; i++) { stringArray[i] = randomString(alphabet, length); } } private String randomString(String alphabet, int length) { char[] chars = alphabet.toCharArray(); ThreadLocalRandom random = ThreadLocalRandom.current(); StringBuilder sb = new StringBuilder(length); for (int i = 0; i < length; i++) { char c = chars[random.nextInt(chars.length)]; sb.append(c); } return sb.toString(); } } } On my machine I've got the following results (full output is available on https://gist.github.com/stsypanov/ee7483c6e4f3d5a711743a531baa049f): Benchmark (count) (length) original patched Units stringJoiner 1 1 39.4 ? 0.5 40.4 ? 0.1 ns/op stringJoiner 1 5 41.1 ? 0.5 41.5 ? 0.1 ns/op stringJoiner 1 10 45.0 ? 1.0 42.6 ? 0.2 ns/op stringJoiner 1 100 111.3 ? 4.0 54.3 ? 0.1 ns/op stringJoiner 5 1 102.3 ? 2.9 76.3 ? 0.3 ns/op stringJoiner 5 5 124.9 ? 3.8 77.9 ? 0.4 ns/op stringJoiner 5 10 146.8 ? 1.5 84.9 ? 0.3 ns/op stringJoiner 5 100 425.0 ? 6.7 194.0 ? 0.7 ns/op stringJoiner 10 1 204.1 ? 1.3 158.1 ? 0.9 ns/op stringJoiner 10 5 266.1 ? 167.3 166.0 ? 0.7 ns/op stringJoiner 10 10 258.7 ? 5.6 179.1 ? 0.6 ns/op stringJoiner 10 100 932.0 ? 33.4 454.1 ? 2.2 ns/op stringJoiner 100 1 1771.4 ? 39.5 1360.0 ? 21.0 ns/op stringJoiner 100 5 2083.9 ? 42.2 1495.2 ? 23.6 ns/op stringJoiner 100 10 2104.1 ? 24.7 1719.9 ? 19.2 ns/op stringJoiner 100 100 7042.0 ? 162.9 4068.2 ? 112.8 ns/op stringJoiner:?gc.alloc.rate.norm 1 1 168.0 ? 0.0 120.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 1 5 176.0 ? 0.0 136.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 1 10 184.0 ? 0.0 152.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 1 100 1016.0 ? 0.0 520.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 5 1 184.0 ? 0.0 152.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 5 5 312.0 ? 0.0 232.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 5 10 520.0 ? 0.0 328.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 5 100 4328.0 ? 0.0 2136.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 10 1 296.0 ? 0.0 280.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 10 5 536.0 ? 0.0 440.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 10 10 936.0 ? 0.0 632.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 10 100 8648.0 ? 0.0 4232.0 ? 0.0 B/op stringJoiner:?gc.alloc.rate.norm 100 1 1744.0 ? 0.0 1976.0 ? 5.4 B/op stringJoiner:?gc.alloc.rate.norm 100 5 6032.0 ? 0.0 3576.0 ? 5.4 B/op stringJoiner:?gc.alloc.rate.norm 100 10 7032.0 ? 0.0 5576.0 ? 5.4 B/op stringJoiner:?gc.alloc.rate.norm 100 100 73056.0 ? 0.0 41576.0 ? 5.4 B/op The backport demonstrates significant improvement both for average time and consumed memory. StringJoiner is widely used in JDK and in client code (esp. when using Collectors.joining()) so I think this is a valuable improvement. Can we apply the attached patch to upcoming version of JDK8u? Regards, Sergey Tsypanov -------------- next part -------------- A non-text attachment was scrubbed... Name: sj.patch Type: text/x-diff Size: 15845 bytes Desc: not available URL: From sgehwolf at redhat.com Fri May 8 08:07:48 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 8 May 2020 10:07:48 +0200 Subject: [8u] RFR(XS): 8244461: [JDK 8u] Build fails with glibc 2.32 Message-ID: Hi, Please review this OpenJDK 8u (and 7u) specific patch which fixes a build failure with upcoming glibc 2.32 release. This isn't an issue in later JDKs because headers got cleaned up by JDK-8167481. Bringing this back into OpenJDK 8u together with dependencies for this two liner fix seems overkill and bears more risk. Hence, a point-fix for OpenJDK 8u (and possibly 7u). Note that sys/sysctl.h removals are in Linux specific ifdef branches and sysctl isn't being used in those files anyway. From a functionality perspective this should be a no-op. Bug: https://bugs.openjdk.java.net/browse/JDK-8244461 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244461/01/webrev/ Testing: Build on Linux system with preview release of glibc 2.32 now works, failed before. Thoughts? Thanks, Severin From aph at redhat.com Fri May 8 12:53:38 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 8 May 2020 13:53:38 +0100 Subject: [8u] RFR(XS): 8244461: [JDK 8u] Build fails with glibc 2.32 In-Reply-To: References: Message-ID: <23d513d9-2ef3-30dc-4de7-b24981747b12@redhat.com> On 5/8/20 9:07 AM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8244461 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244461/01/webrev/ > > Testing: Build on Linux system with preview release of glibc 2.32 now > works, failed before. > > Thoughts? OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Fri May 8 13:00:29 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 8 May 2020 15:00:29 +0200 Subject: [8u] RFR(XS): 8244461: [JDK 8u] Build fails with glibc 2.32 In-Reply-To: <23d513d9-2ef3-30dc-4de7-b24981747b12@redhat.com> References: <23d513d9-2ef3-30dc-4de7-b24981747b12@redhat.com> Message-ID: Hi Andrew, On Fri, May 8, 2020 at 2:53 PM Andrew Haley wrote: > > On 5/8/20 9:07 AM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244461 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244461/01/webrev/ > > > > Testing: Build on Linux system with preview release of glibc 2.32 now > > works, failed before. > > > > Thoughts? > > OK. Thanks for the review! Cheers, Severin From sgehwolf at redhat.com Fri May 8 13:17:12 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 8 May 2020 15:17:12 +0200 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers Message-ID: Hi, Please review this OpenJDK 8u backport of JDK-8233880. It's a one-liner change which updates the toolchain.m4 code so as to recognize multi-digit GCC versions. For example Fedora 32 comes with GCC 10 and falls afoul this check. As a result, a configure warning is being produced and crucial flags won't get added for compilation. This results in a broken build on such systems. Details are in: https://bugs.openjdk.java.net/browse/JDK-8244538 The original JDK 14 patch doesn't apply cleanly post path- unshuffeling, because even though JDK-8151841[1] is in 8u, JDK-8034788[2] later regressed the COMPILER_VERSION_NUMBER sed expression to its prior JDK-8151841 form. After this patch, this will be corrected again and will include JDK-8233880 changes. Bug: https://bugs.openjdk.java.net/browse/JDK-8233880 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233880/01/webrev/ Testing: Build prior this patch on F32 with -fcommon (crashes on java -version). Passes after. Thoughts? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8151841 [2] https://bugs.openjdk.java.net/browse/JDK-8034788 From ebaron at redhat.com Fri May 8 18:58:28 2020 From: ebaron at redhat.com (Elliott Baron) Date: Fri, 8 May 2020 14:58:28 -0400 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: References: Message-ID: Hi, On 2020-04-16 7:54 p.m., Elliott Baron wrote: > Hi, > > I'd like to request a review to backport 8177334 to 8u. > > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8177334 > http://hg.openjdk.java.net/jdk/jdk/rev/3810c9a2efa1 > > The JDK 11 fix did not apply cleanly. Below, I have detailed the > modifications I made in order to backport this fix to 8u. There are some > major changes that I believe may require some discussion, and many minor > changes outlined after those. The changes within each section are listed > roughly in order of the patch. > > Thank you to Martin Balao for his assistance in tracking down the > dependencies for this fix. > > I should point out that there are some known bugfixes that fix problems > introduced by this update. These should probably go into the same 8u > update as this fix. They are: > - 8217878: ENVELOPING XML signature no longer works > - 8218629: XML Digital Signature throws NAMESPACE_ERR exception on > OpenJDK 11, works 8/9/10 (I believe this is the same fix as above) > - 8236645: JDK 8u231 introduces a regression with incompatible handling > of XML messages > > 8u webrev: > https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.00/ Has anyone had a chance to take a look at this yet? > > [snip] Thanks, Elliott From aph at redhat.com Sun May 10 14:36:05 2020 From: aph at redhat.com (Andrew Haley) Date: Sun, 10 May 2020 15:36:05 +0100 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: References: Message-ID: On 5/8/20 2:17 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8233880 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233880/01/webrev/ > > Testing: Build prior this patch on F32 with -fcommon (crashes on java > -version). Passes after. > > Thoughts? That looks fine; I presume the apparently spurious diffs are because you used a different version of autoconf to generate generated-configure.sh. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Mon May 11 07:43:29 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 May 2020 09:43:29 +0200 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: References: Message-ID: Hi Andrew, On Sun, May 10, 2020 at 4:36 PM Andrew Haley wrote: > > On 5/8/20 2:17 PM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233880 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233880/01/webrev/ > > > > Testing: Build prior this patch on F32 with -fcommon (crashes on java > > -version). Passes after. > > > > Thoughts? > > That looks fine; I presume the apparently spurious diffs are because > you used a different version of autoconf to generate generated-configure.sh. Thanks for the review! Yes, generated-configure.sh changes are due to version skew of autoconf being used. I'll try to generate configure on an older machine so as to avoid this before pushing. Does that sound ok? Cheers, Severin From fweimer at redhat.com Mon May 11 07:58:29 2020 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 11 May 2020 09:58:29 +0200 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: (Severin Gehwolf's message of "Mon, 11 May 2020 09:43:29 +0200") References: Message-ID: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> * Severin Gehwolf: > Thanks for the review! Yes, generated-configure.sh changes are due to > version skew of autoconf being used. I'll try to generate configure on > an older machine so as to avoid this before pushing. Does that sound > ok? THe runstatedir changes come and go (even in the jdk8u-dev history), depending on whether Debian's autoconf is used, which patches its autoconf 2.69 build to handle runstatedir. There hasn't been an autoconf upstream release in many, many years, so going back to older versions will not solve this. If you want to avoid this change, you either have to use Debian's autoconf, or back it out manually. Thanks, Florian From sgehwolf at redhat.com Mon May 11 08:19:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 11 May 2020 10:19:42 +0200 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> References: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian, On Mon, May 11, 2020 at 9:58 AM Florian Weimer wrote: > > * Severin Gehwolf: > > > Thanks for the review! Yes, generated-configure.sh changes are due to > > version skew of autoconf being used. I'll try to generate configure on > > an older machine so as to avoid this before pushing. Does that sound > > ok? > > THe runstatedir changes come and go (even in the jdk8u-dev history), > depending on whether Debian's autoconf is used, which patches its > autoconf 2.69 build to handle runstatedir. There hasn't been an > autoconf upstream release in many, many years, so going back to older > versions will not solve this. If you want to avoid this change, you > either have to use Debian's autoconf, or back it out manually. OK. Thanks for the heads-up. Cheers, Severin From aph at redhat.com Mon May 11 09:35:58 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 May 2020 10:35:58 +0100 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> References: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> Message-ID: On 5/11/20 8:58 AM, Florian Weimer wrote: > * Severin Gehwolf: > >> Thanks for the review! Yes, generated-configure.sh changes are due to >> version skew of autoconf being used. I'll try to generate configure on >> an older machine so as to avoid this before pushing. Does that sound >> ok? > > THe runstatedir changes come and go (even in the jdk8u-dev history), > depending on whether Debian's autoconf is used, which patches its > autoconf 2.69 build to handle runstatedir. There hasn't been an > autoconf upstream release in many, many years, so going back to older > versions will not solve this. If you want to avoid this change, you > either have to use Debian's autoconf, or back it out manually. I guess it doesn't matter. Having said that, it's a timely reminder of how random distro-isms end up in OpenJDK by accident. And I am *so* *happy* that autoconf is stable upstream. I remember when it was changing rapidly, and that was a nightmare. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Mon May 11 12:18:26 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 13:18:26 +0100 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> References: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> Message-ID: On 11/05/2020 08:58, Florian Weimer wrote: > * Severin Gehwolf: > >> Thanks for the review! Yes, generated-configure.sh changes are due to >> version skew of autoconf being used. I'll try to generate configure on >> an older machine so as to avoid this before pushing. Does that sound >> ok? > > THe runstatedir changes come and go (even in the jdk8u-dev history), > depending on whether Debian's autoconf is used, which patches its > autoconf 2.69 build to handle runstatedir. There hasn't been an > autoconf upstream release in many, many years, so going back to older > versions will not solve this. If you want to avoid this change, you > either have to use Debian's autoconf, or back it out manually. > > Thanks, > Florian > And this is why checking in generated files should be avoided. I'm glad it's gone in later OpenJDK versions. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From fweimer at redhat.com Mon May 11 12:24:13 2020 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 11 May 2020 14:24:13 +0200 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: (Andrew Haley's message of "Mon, 11 May 2020 10:35:58 +0100") References: <87zhaehpi2.fsf@oldenburg2.str.redhat.com> Message-ID: <87ftc6ek2a.fsf@oldenburg2.str.redhat.com> * Andrew Haley: > On 5/11/20 8:58 AM, Florian Weimer wrote: >> * Severin Gehwolf: >> >>> Thanks for the review! Yes, generated-configure.sh changes are due to >>> version skew of autoconf being used. I'll try to generate configure on >>> an older machine so as to avoid this before pushing. Does that sound >>> ok? >> >> THe runstatedir changes come and go (even in the jdk8u-dev history), >> depending on whether Debian's autoconf is used, which patches its >> autoconf 2.69 build to handle runstatedir. There hasn't been an >> autoconf upstream release in many, many years, so going back to older >> versions will not solve this. If you want to avoid this change, you >> either have to use Debian's autoconf, or back it out manually. > > I guess it doesn't matter. Having said that, it's a timely reminder > of how random distro-isms end up in OpenJDK by accident. The flip side is that distributions carry different patches or use sed to patch configure scripts. > And I am *so* *happy* that autoconf is stable upstream. I remember when > it was changing rapidly, and that was a nightmare. A new upstream release is in the works: It's true that in the past, you had to have multiple autoconf versions installed and use the right version depending on the project. But at least distributions where providing you with a reasonable choice of autoconf (and automake) versions. Today, you can't easily get Debian's autoconf on Fedora and vice versa, which is clearly not an ideal situation. Thanks, Florian From neugens at redhat.com Mon May 11 12:23:55 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 11 May 2020 14:23:55 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Hi Jaroslav, I went back to that and I noticed some minor things while comparing it to the original patch. I see you have a number of commented out blocks, I think those should be removed, I can see how this may become a problem when backporting additional fixes. For example: +void Jfr::on_create_vm_1() { + //jio_fprintf(defaultStream::error_stream(), "openjdk version \"1.8.0-internal-debug\"\n"); + if (!JfrRecorder::on_create_vm_1()) { + vm_exit_during_initialization("Failure when starting JFR on_create_vm_1"); } Also, you changed the assert in linkResolver.cpp, at first I thought this was intentional, but there no such change in jdk11. Perhaps it may be dropped? Cheers, Mario On Wed, May 6, 2020 at 12:36 PM Mario Torre wrote: > > Hi Jaroslav, > > Sorry I dropped the ball on this one, I went through the changes and > they all seem good to me. > > We need a maintainer to set the jdk8u-fix-yes flag before you can > push, but the review is ok. > > Cheers, > Mario > > > On Fri, Apr 24, 2020 at 12:20 PM Jaroslav Bachor?k > wrote: > > > > Resending again in plain text to make the filters pass. > > > > ---------- Forwarded message --------- > > From: Jaroslav Bachor?k > > Date: Mon, Apr 20, 2020 at 4:02 PM > > Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() > > and Jfr:on_vm_start() start-up order for correct option parsing > > To: jdk8u-dev > > > > > > Please review the following backport > > > > JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 > > Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ > > > > The backport patch applied rather cleanly, not considering several > > offset adjustments. > > The only part that required an additional change was modifying the > > place where java lang classes initialization happens in thread.cpp - > > those classes need to be initialized before 'Jfr::on_create_vm_2()' is > > called. In order to achieve this I just moved around the whole > > codeblock related to java lang classes initialization. > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > Thanks! > > > > -JB- > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From gnu.andrew at redhat.com Mon May 11 13:54:42 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 14:54:42 +0100 Subject: [8u] RFR(XS): 8244461: [JDK 8u] Build fails with glibc 2.32 In-Reply-To: References: Message-ID: <9f930ae8-a364-0cac-7adb-844ded1128c0@redhat.com> On 08/05/2020 09:07, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u (and 7u) specific patch which fixes a > build failure with > upcoming glibc 2.32 release. This isn't an issue in later JDKs because > headers got cleaned > up by JDK-8167481. Bringing this back into OpenJDK 8u together with > dependencies for this > two liner fix seems overkill and bears more risk. Hence, a point-fix > for OpenJDK 8u (and > possibly 7u). Note that sys/sysctl.h removals are in Linux specific > ifdef branches and sysctl > isn't being used in those files anyway. From a functionality > perspective this should be a no-op. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244461 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244461/01/webrev/ > > Testing: Build on Linux system with preview release of glibc 2.32 now > works, failed before. > > Thoughts? > > Thanks, > Severin > Looks ok to me and fixed the Fedora build. Approved. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From johannes.rudolph at lightbend.com Mon May 11 12:46:40 2020 From: johannes.rudolph at lightbend.com (Johannes Rudolph) Date: Mon, 11 May 2020 14:46:40 +0200 Subject: New ALPN API introduced in 8u252 vs. later JDKs' --release 8 support Message-ID: Hi there, 8u252 backported new APIs to support ALPN in TLS. We'd like to be able to compile this code also with later JDKs using the `--release 8` flag. However, that is currently not possible because the latest versions of OpenJDK 11 does not (yet?) know about these new methods and compilation fails on JDK 11: ? /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64/bin/javac --release 8 Test.java Test.java:3: error: cannot find symbol engine.setHandshakeApplicationProtocolSelector(null); ^ symbol: method setHandshakeApplicationProtocolSelector() location: variable engine of type SSLEngine ? /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64/bin/java --version openjdk 11.0.7 2020-04-14 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode) Will the symbol lists that back the `--release` feature be updated? Or are they a rather conservative approximation of what APIs older JDKs provide? Who is driving the process to regenerate the symbol lists? Workarounds would be not to compile on JDK 11 for now or to go back to a reflection based approach for calling the new methods. Johannes From aph at redhat.com Mon May 11 14:56:38 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 May 2020 15:56:38 +0100 Subject: Rejected AArch64 jdk8u backports Message-ID: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> I've been going though AArch64 jdk8u backports. The following backports should (probably) NOT be done in 8u; reasons follow. 8219006: AArch64: Register corruption in slow subtype check Only affects debug builds; patch is fiddly and risky. 8219698: aarch64: SIGILL triggered when specifying unsupported hardware features Only happens due to user error: the problem is between keyboard and chair. 8219993: AArch64: Compiled CI stubs are unsafely modified This is a rather theoretical bug in that the AArch64 back end modifies stubs in a way that IMO doesn't conform to the AArch64 memory model. However, the fix is complicated and the problem has never manifested in any test cases, so it's better to leave it as it is in 8u. 8222412: AARCH64: multiple instructions encoding issues Big and intrusive, fixes no user-visible bugs, so not appropriate for 8u. 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 Serviceability test. Not important. 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl C2 enhancement. Might break things, small performance improvement, hard to test, so not for 8u. 8233912: aarch64: minor improvements of atomic operations Another rather theoretical patch that fixes no known bugs. 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes Summary: try to map CDS shared space at 4G aligned address on AArch64 Not applicable to 8u. 8235385: AArch64: Crash on aarch64 JDK due to long offset This is a real bug but it requires a very contrived test case to trigger it and the fix is complex. Probably not worth it. 8237512: AArch64: aarch64TestHook leaks a BufferBlob Only gets triggered in debug builds. Not important for 8u. 8237524: AArch64: String.compareTo() may return incorrect result Code being patched does not exist in 8u. 8239787: AArch64: String.indexOf may incorrectly handle empty strings Likewise 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 Enhancement-only 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 gnu.andrew at redhat.com Mon May 11 17:38:59 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 18:38:59 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: On 07/05/2020 16:55, Simon Tooke wrote: > (disclaimer: I am not a reviewer) > > > I believe it's a "good thing" to shrink the reserved1 bitfield, as I > suspect the entire struct grows by 4 bytes otherwise. > > > Original: > > 644 unsigned int jdk_version; /* Consists of major, minor, micro (n.n.n) > */ 1645 /* and build number (xx) */ 1646 unsigned int update_version : > 8; /* Update release version (uu) */ 1647 unsigned int > special_update_version : 8; /* Special update release version (c)*/ 1648 > unsigned int reserved1 : 16; 1649 unsigned int reserved2; The proposed > patch: 44 unsigned int jdk_version; /* Consists of major, minor, micro > (n.n.n) */ 1645 /* and build number (xx) */ 1646 unsigned int > update_version : 16; /* Update release version (uu) */ 1647 unsigned int > special_update_version : 8; /* Special update release version (c)*/ 1648 > unsigned int reserved1 : 16; 1649 unsigned int reserved2; Note that the > original sum of bitfields is 32 bits, so it will fit into a 4 byte int > (which it is surrounded by) The proposed sum of bitfields is 40 bits, > which will probably cause a new 4 byte bitfield to be generated under > the hood. > > -Simon > > I don't know what happened here, but this is nearly impossible to read as one unbroken line of text. Can you add some line breaks? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon May 11 17:43:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 18:43:56 +0100 Subject: Rejected AArch64 jdk8u backports In-Reply-To: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> Message-ID: <651fe7c2-bcca-a157-bbbe-ecbc00f9c7fe@redhat.com> On 11/05/2020 15:56, Andrew Haley wrote: > I've been going though AArch64 jdk8u backports. > The following backports should (probably) NOT be done in 8u; reasons follow. > > > 8219006: AArch64: Register corruption in slow subtype check > > Only affects debug builds; patch is fiddly and risky. > > 8219698: aarch64: SIGILL triggered when specifying unsupported hardware features > > Only happens due to user error: the problem is between keyboard and chair. > > 8219993: AArch64: Compiled CI stubs are unsafely modified > > This is a rather theoretical bug in that the AArch64 back end modifies > stubs in a way that IMO doesn't conform to the AArch64 memory > model. However, the fix is complicated and the problem has never > manifested in any test cases, so it's better to leave it as it is in > 8u. > > 8222412: AARCH64: multiple instructions encoding issues > > Big and intrusive, fixes no user-visible bugs, so not appropriate for > 8u. > > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > > Serviceability test. Not important. > > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > > C2 enhancement. Might break things, small performance improvement, > hard to test, so not for 8u. > > 8233912: aarch64: minor improvements of atomic operations > > Another rather theoretical patch that fixes no known bugs. > > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > Summary: try to map CDS shared space at 4G aligned address on AArch64 > > Not applicable to 8u. > > 8235385: AArch64: Crash on aarch64 JDK due to long offset > > This is a real bug but it requires a very contrived test case to > trigger it and the fix is complex. Probably not worth it. > > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > > Only gets triggered in debug builds. Not important for 8u. > > 8237524: AArch64: String.compareTo() may return incorrect result > > Code being patched does not exist in 8u. > > 8239787: AArch64: String.indexOf may incorrectly handle empty strings > > Likewise > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > > Enhancement-only patch. > Is there a reason a lot of recent AArch64 posts have also been CCed to the 8u-dev list? Upstream 8u does not currently have an AArch64 port. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon May 11 17:54:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 18:54:51 +0100 Subject: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers In-Reply-To: References: Message-ID: On 08/05/2020 14:17, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport of JDK-8233880. It's a > one-liner change which updates the toolchain.m4 code so as to > recognize multi-digit GCC versions. For example Fedora 32 comes > with GCC 10 and falls afoul this check. As a result, a configure > warning is being produced and crucial flags won't get added for > compilation. This results in a broken build on such systems. > > Details are in: > https://bugs.openjdk.java.net/browse/JDK-8244538 > > The original JDK 14 patch doesn't apply cleanly post path- > unshuffeling, because even though JDK-8151841[1] is in 8u, > JDK-8034788[2] later regressed the > COMPILER_VERSION_NUMBER sed expression to its prior > JDK-8151841 form. After this patch, this will be corrected again > and will include JDK-8233880 changes. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233880 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233880/01/webrev/ > > Testing: Build prior this patch on F32 with -fcommon (crashes on java > -version). Passes after. > > Thoughts? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8151841 > [2] https://bugs.openjdk.java.net/browse/JDK-8034788 > That JDK-8034788 seems to have regressed quite a lot :-( Change looks fine. I was able to do a clean generation of configure, so I've approved and pushed 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 From martinrb at google.com Mon May 11 17:54:53 2020 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 May 2020 10:54:53 -0700 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: On Thu, May 7, 2020 at 8:18 AM Severin Gehwolf wrote: > Thus, the new upper bound for update > version number is 2^16-1 => 65535 which should be sufficient. I don't > think OpenJDK 8u will live that long ;-) Everyone expected 256 to be sufficient for update release numbering, before the gaps in the numbering scheme were introduced! I don't know how we ended up with 2 mod 10. From stooke at redhat.com Mon May 11 18:22:42 2020 From: stooke at redhat.com (Simon Tooke) Date: Mon, 11 May 2020 14:22:42 -0400 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: <7d9ede6d-3757-c235-0e4c-53821b6907ef@redhat.com> That's horrible.? I will try again.? My wife claims I tell anecdotes like that too. Original: 1644???? unsigned int jdk_version;??? /* Consists of major, minor, micro (n.n.n) */ 1645???????????????????????????? ? ? ? ? ? ?? ??? ? /* and build number (xx) */ 1646???? unsigned int update_version : 8;???????? /* Update release version (uu) */ 1647???? unsigned int special_update_version : 8; /* Special update release version (c)*/ 1648???? unsigned int reserved1 : 16; 1649???? unsigned int reserved2; The proposed patch: 1644???? unsigned int jdk_version;?? /* Consists of major, minor, micro (n.n.n) */ 1645???????????????????????? ? ? ? ? ? ? ???? ? ? ? /* and build number (xx) */ 1646???? unsigned int update_version : 16;??????? /* Update release version (uu) */ 1647???? unsigned int special_update_version : 8; /* Special update release version (c)*/ 1648???? unsigned int reserved1 : 16; 1649???? unsigned int reserved2; Note that the original sum of bitfields is 32 bits, so it will fit into a 4 byte int (which it is surrounded by) The proposed sum of bitfields is 40 bits, which will probably cause a new 4 byte bitfield to be generated under the hood. -Simon On 2020-05-11 1:38 p.m., Andrew Hughes wrote: > > On 07/05/2020 16:55, Simon Tooke wrote: >> (disclaimer: I am not a reviewer) >> >> >> I believe it's a "good thing" to shrink the reserved1 bitfield, as I >> suspect the entire struct grows by 4 bytes otherwise. >> >> >> Original: >> >> 644 unsigned int jdk_version; /* Consists of major, minor, micro (n.n.n) >> */ 1645 /* and build number (xx) */ 1646 unsigned int update_version : >> 8; /* Update release version (uu) */ 1647 unsigned int >> special_update_version : 8; /* Special update release version (c)*/ 1648 >> unsigned int reserved1 : 16; 1649 unsigned int reserved2; The proposed >> patch: 44 unsigned int jdk_version; /* Consists of major, minor, micro >> (n.n.n) */ 1645 /* and build number (xx) */ 1646 unsigned int >> update_version : 16; /* Update release version (uu) */ 1647 unsigned int >> special_update_version : 8; /* Special update release version (c)*/ 1648 >> unsigned int reserved1 : 16; 1649 unsigned int reserved2; Note that the >> original sum of bitfields is 32 bits, so it will fit into a 4 byte int >> (which it is surrounded by) The proposed sum of bitfields is 40 bits, >> which will probably cause a new 4 byte bitfield to be generated under >> the hood. >> >> -Simon >> >> > I don't know what happened here, but this is nearly impossible to read > as one unbroken line of text. Can you add some line breaks? > > Thanks, From gnu.andrew at redhat.com Mon May 11 18:57:55 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 19:57:55 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <7d9ede6d-3757-c235-0e4c-53821b6907ef@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <7d9ede6d-3757-c235-0e4c-53821b6907ef@redhat.com> Message-ID: On 11/05/2020 19:22, Simon Tooke wrote: > That's horrible.? I will try again.? My wife claims I tell anecdotes > like that too. > > Original: > > 1644???? unsigned int jdk_version;??? /* Consists of major, minor, micro > (n.n.n) */ > 1645???????????????????????????? ? ? ? ? ? ?? ??? ? /* and build number > (xx) */ > 1646???? unsigned int update_version : 8;???????? /* Update release > version (uu) */ > 1647???? unsigned int special_update_version : 8; /* Special update > release version (c)*/ > 1648???? unsigned int reserved1 : 16; > 1649???? unsigned int reserved2; > > The proposed patch: > > 1644???? unsigned int jdk_version;?? /* Consists of major, minor, micro > (n.n.n) */ > 1645???????????????????????? ? ? ? ? ? ? ???? ? ? ? /* and build number > (xx) */ > 1646???? unsigned int update_version : 16;??????? /* Update release > version (uu) */ > 1647???? unsigned int special_update_version : 8; /* Special update > release version (c)*/ > 1648???? unsigned int reserved1 : 16; > 1649???? unsigned int reserved2; > > Note that the original sum of bitfields is 32 bits, so it will fit into > a 4 byte int (which it is surrounded by) > The proposed sum of bitfields is 40 bits, which will probably cause a > new 4 byte bitfield to be generated under the hood. > > -Simon Thanks. That's a lot more readable :-) Do we have any idea how much the three later fields are used in the wild? In particular, could we not just steal those eight bits from 'special_update_version' (whatever that is) and keep the sum the same? This would only apply to versions where update_version is broken already, so reinterpretation of a structure of the existing size seems safer than increasing the size by eight bits. In code, unsigned int jdk_version; unsigned int update_version : 16; unsigned int reserved1 : 16; unsigned int reserved2; or, if we're wary about losing the name special_update_version, we could shrink reserved1: unsigned int jdk_version; unsigned int update_version : 16; unsigned int special_update_version : 8; unsigned int reserved1 : 8; unsigned int reserved2; Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From bradford.wetmore at oracle.com Mon May 11 19:22:46 2020 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 11 May 2020 12:22:46 -0700 Subject: Fwd: New ALPN API introduced in 8u252 vs. later JDKs' --release 8 support In-Reply-To: <387096af-3da8-0e50-a9b9-6a34b3b4cc6e@redhat.com> References: <387096af-3da8-0e50-a9b9-6a34b3b4cc6e@redhat.com> Message-ID: I've filed: https://bugs.openjdk.java.net/browse/JDK-8244763 Thanks for pointing this out. Brad On 5/11/2020 10:42 AM, Andrew Hughes wrote: > > Seems like something more for 11u+ than 8u... > > -------- Forwarded Message -------- > Subject: New ALPN API introduced in 8u252 vs. later JDKs' --release 8 > support > Date: Mon, 11 May 2020 14:46:40 +0200 > From: Johannes Rudolph > To: jdk8u-dev at openjdk.java.net > > Hi there, > > 8u252 backported new APIs to support ALPN in TLS. We'd like to be able to > compile this code also with later JDKs using the `--release 8` flag. > However, that is currently not possible because the latest versions of > OpenJDK 11 does not (yet?) know about these new methods and compilation > fails on JDK 11: > > ? /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64/bin/javac --release 8 Test.java > Test.java:3: error: cannot find symbol > engine.setHandshakeApplicationProtocolSelector(null); > ^ > symbol: method setHandshakeApplicationProtocolSelector() > location: variable engine of type SSLEngine > > ? /usr/lib/jvm/adoptopenjdk-11-hotspot-amd64/bin/java --version > openjdk 11.0.7 2020-04-14 > OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.7+10) > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.7+10, mixed mode) > > Will the symbol lists that back the `--release` feature be updated? Or are > they a rather conservative approximation of what APIs older JDKs provide? > Who is driving the process to regenerate the symbol lists? > > Workarounds would be not to compile on JDK 11 for now or to go back to a > reflection based approach for calling the new methods. > > Johannes > > From adinn at redhat.com Mon May 11 20:28:18 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 May 2020 21:28:18 +0100 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <651fe7c2-bcca-a157-bbbe-ecbc00f9c7fe@redhat.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> <651fe7c2-bcca-a157-bbbe-ecbc00f9c7fe@redhat.com> Message-ID: On 11/05/2020 18:43, Andrew Hughes wrote: > > Is there a reason a lot of recent AArch64 posts have also been CCed to > the 8u-dev list? Upstream 8u does not currently have an AArch64 port. I think that was just me forwarding a few reviews. It wasn't necessary but I thought it might be useful for those subscribing to the updates list to know about the decisions being made and the rationale for them. I suppose we /may/ still see the AArch64 port upstreamed into jdk8u at some stage. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From nick.gasson at arm.com Tue May 12 02:25:44 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 12 May 2020 10:25:44 +0800 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> Message-ID: <854ksl99ef.fsf@arm.com> > > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > > Only gets triggered in debug builds. Not important for 8u. > I think the leak is still there in release builds: the BufferBlob is allocated in aarch64TestHook() which is called from ICache::initialize(). That then calls into entry() in assembler_aarch64.cpp which does nothing if ASSERT is not defined. -- Thanks, Nick From aph at redhat.com Tue May 12 08:41:35 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 09:41:35 +0100 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <854ksl99ef.fsf@arm.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> <854ksl99ef.fsf@arm.com> Message-ID: <2a16887d-1453-8d05-36ee-ea468ff0e3a4@redhat.com> On 5/12/20 3:25 AM, Nick Gasson wrote: >> >> 8237512: AArch64: aarch64TestHook leaks a BufferBlob >> >> Only gets triggered in debug builds. Not important for 8u. >> > > I think the leak is still there in release builds: the BufferBlob is > allocated in aarch64TestHook() which is called from > ICache::initialize(). That then calls into entry() in > assembler_aarch64.cpp which does nothing if ASSERT is not defined. Oh poo, you're right. Thanks, I'll fix it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Tue May 12 08:53:07 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 May 2020 10:53:07 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <7d9ede6d-3757-c235-0e4c-53821b6907ef@redhat.com> Message-ID: <4cc48d3ade76bb35e97d61f462b0e3323351692a.camel@redhat.com> Hi, Thanks for looking at this! On Mon, 2020-05-11 at 19:57 +0100, Andrew Hughes wrote: > > On 11/05/2020 19:22, Simon Tooke wrote: > > That's horrible. I will try again. My wife claims I tell anecdotes > > like that too. > > > > Original: > > > > 1644 unsigned int jdk_version; /* Consists of major, minor, micro > > (n.n.n) */ > > 1645 /* and build number > > (xx) */ > > 1646 unsigned int update_version : 8; /* Update release > > version (uu) */ > > 1647 unsigned int special_update_version : 8; /* Special update > > release version (c)*/ > > 1648 unsigned int reserved1 : 16; > > 1649 unsigned int reserved2; > > > > The proposed patch: > > > > 1644 unsigned int jdk_version; /* Consists of major, minor, micro > > (n.n.n) */ > > 1645 /* and build number > > (xx) */ > > 1646 unsigned int update_version : 16; /* Update release > > version (uu) */ > > 1647 unsigned int special_update_version : 8; /* Special update > > release version (c)*/ > > 1648 unsigned int reserved1 : 16; > > 1649 unsigned int reserved2; > > > > Note that the original sum of bitfields is 32 bits, so it will fit into > > a 4 byte int (which it is surrounded by) > > The proposed sum of bitfields is 40 bits, which will probably cause a > > new 4 byte bitfield to be generated under the hood. > > > > -Simon > > Thanks. That's a lot more readable :-) > > Do we have any idea how much the three later fields are used in the > wild? I, for one, have no idea :-( > In particular, could we not just steal those eight bits from > 'special_update_version' (whatever that is) and keep the sum the same? See below. > This would only apply to versions where update_version is broken > already, so reinterpretation of a structure of the existing size seems > safer than increasing the size by eight bits. Sure. webrev 03 should preserve the size. > In code, > > unsigned int jdk_version; > unsigned int update_version : 16; > unsigned int reserved1 : 16; > unsigned int reserved2; > > or, if we're wary about losing the name special_update_version, we could special_update_version seems at least be referenced in code. So we would have to change those references. Given that, I'd go with reducing reserved1 as that doesn't seem to be used. > shrink reserved1: > > unsigned int jdk_version; > unsigned int update_version : 16; > unsigned int special_update_version : 8; > unsigned int reserved1 : 8; > unsigned int reserved2; This is what webrev 03 does: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/03/ Does that look OK to you? Thanks, Severin From jaroslav.bachorik at datadoghq.com Tue May 12 11:02:13 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 12 May 2020 13:02:13 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Hi Mario, thanks for the review and I apologize for the escaped non-needed commented out code. Everything is cleaned up now and should correspond to 11u backport. Webrev 01: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.01/ Cheers, -JB- On Mon, May 11, 2020 at 2:24 PM Mario Torre wrote: > > Hi Jaroslav, > > I went back to that and I noticed some minor things while comparing it > to the original patch. > > I see you have a number of commented out blocks, I think those should > be removed, I can see how this may become a problem when backporting > additional fixes. For example: > > +void Jfr::on_create_vm_1() { > + //jio_fprintf(defaultStream::error_stream(), "openjdk version > \"1.8.0-internal-debug\"\n"); > + if (!JfrRecorder::on_create_vm_1()) { > + vm_exit_during_initialization("Failure when starting JFR on_create_vm_1"); > } > > Also, you changed the assert in linkResolver.cpp, at first I thought > this was intentional, but there no such change in jdk11. Perhaps it > may be dropped? > > Cheers, > Mario > > > On Wed, May 6, 2020 at 12:36 PM Mario Torre wrote: > > > > Hi Jaroslav, > > > > Sorry I dropped the ball on this one, I went through the changes and > > they all seem good to me. > > > > We need a maintainer to set the jdk8u-fix-yes flag before you can > > push, but the review is ok. > > > > Cheers, > > Mario > > > > > > On Fri, Apr 24, 2020 at 12:20 PM Jaroslav Bachor?k > > wrote: > > > > > > Resending again in plain text to make the filters pass. > > > > > > ---------- Forwarded message --------- > > > From: Jaroslav Bachor?k > > > Date: Mon, Apr 20, 2020 at 4:02 PM > > > Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() > > > and Jfr:on_vm_start() start-up order for correct option parsing > > > To: jdk8u-dev > > > > > > > > > Please review the following backport > > > > > > JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 > > > Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ > > > > > > The backport patch applied rather cleanly, not considering several > > > offset adjustments. > > > The only part that required an additional change was modifying the > > > place where java lang classes initialization happens in thread.cpp - > > > those classes need to be initialized before 'Jfr::on_create_vm_2()' is > > > called. In order to achieve this I just moved around the whole > > > codeblock related to java lang classes initialization. > > > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > > > Thanks! > > > > > > -JB- > > > > > > > > > -- > > 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 aph at redhat.com Tue May 12 12:02:34 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 13:02:34 +0100 Subject: RFR: Backport: 823751: AArch64: aarch64TestHook leaks a BufferBlob Message-ID: <011c1f56-974a-91e8-7956-11dfd2c1a0f6@redhat.com> This is Nick Gasson's patch, adjusted but not changed in any significant way: http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8237512.webrev/ Just out of curiosity, I looked at when this bug dates from, and I see # User aph # Date 1342803468 -3600 # Fri Jul 20 17:57:48 2012 +0100 Assembler bug fixes diff -r 0267a9670f59 -r f561ffc8c13f src/cpu/aarch64/vm/aarch64Test.cpp --- a/src/cpu/aarch64/vm/aarch64Test.cpp Fri Jul 20 12:39:25 2012 +0100 +++ b/src/cpu/aarch64/vm/aarch64Test.cpp Fri Jul 20 17:57:48 2012 +0100 @@ -17,7 +17,7 @@ void aarch64TestHook() { - BufferBlob* b = BufferBlob::create("aarch64Test", 5000); + BufferBlob* b = BufferBlob::create("aarch64Test", 500000); This was right at the beginning, when we were writing the assembler, and I needed some way to make sure the generated code was correct but we had no hardware. It's hard to remember what I was thinking, but I guess I thought that this was only test code, so it didn't matter. How wrong can you be? ?? Memo to self: don't do that again. -- 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 May 12 13:07:17 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 14:07:17 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: <808419e3-316b-381d-f636-606aadff39b6@redhat.com> On 5/7/20 4:09 PM, Severin Gehwolf wrote: > jvm_version_info.jvm_version currently holds this quadruplet: > > Most significant 8 bits => major version, followed by 8 bits => minor > version, followed by 8 bits => micro version, followed by 8 bits => > build version. Note that JVM minor version represents the update > version as passed in via configure and the micro version is currently > not used (always 0). See vm_version.cpp lines 100-102 where only major, > minor and build number are ever been set. Knowing this, we can still > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > 0 for any version. This is tricky. JVM_GetVersionInfo is a function exported by libjvm.so, and the version is simply encoded as unsigned int Abstract_VM_Version::jvm_version() { return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | (Abstract_VM_Version::vm_build_number() & 0xFF); } I guess we could argue that this is for JVM-JDK internal use only, and no-one else cares. Or we could encode it in a different way such that at least we have a jvm_version that is monotonically increasing, perhaps by (ab)using the lower 8 bits of the version, the vm_build_number. But I guess I'm being paranoid, and no tools are going to care about minor versions anyway,even if they do call JVM_GetVersionInfo. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Tue May 12 13:19:35 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 May 2020 14:19:35 +0100 Subject: [aarch64-port-dev ] RFR: Backport: 823751: AArch64: aarch64TestHook leaks a BufferBlob In-Reply-To: <011c1f56-974a-91e8-7956-11dfd2c1a0f6@redhat.com> References: <011c1f56-974a-91e8-7956-11dfd2c1a0f6@redhat.com> Message-ID: On 12/05/2020 13:02, Andrew Haley wrote: > This is Nick Gasson's patch, adjusted but not changed in any significant > way: > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8237512.webrev/ Well, the patch doesn't really need a review but anyway it's reviewed. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Tue May 12 13:52:28 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 14:52:28 +0100 Subject: Options for fixing JapanEraNameCompatTest in OpenJDK 8u In-Reply-To: <331592ac8717012b6b4dc2b588620ca5fa4329d3.camel@redhat.com> References: <0ebbb2ba3cb1f77df2db36958aa7a627cf09310e.camel@redhat.com> <331592ac8717012b6b4dc2b588620ca5fa4329d3.camel@redhat.com> Message-ID: On 5/7/20 2:22 PM, Severin Gehwolf wrote: > I'd propose to go with option 1. If consensus is that, I'll propose > this for review. Thoughts? 1 LGTM. -- 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 May 12 13:53:20 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 14:53:20 +0100 Subject: [8u] RFR(XS): 8243059: Build fails when --with-vendor-name contains a comma In-Reply-To: <4d539698e2fcd4ce606e62723cdd9d815b0af473.camel@redhat.com> References: <4d539698e2fcd4ce606e62723cdd9d815b0af473.camel@redhat.com> Message-ID: <0207dc6c-d0be-2988-a4f9-241e8f2d3d6e@redhat.com> On 5/7/20 1:22 PM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8243059 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8243059/jdk8/01/webrev/ > > Testing: building with --with-vendor-name="foo, bar". Fails before, > passes after patch. > > Thoughts? OK, 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 sgehwolf at redhat.com Tue May 12 14:14:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 May 2020 16:14:45 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <808419e3-316b-381d-f636-606aadff39b6@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> Message-ID: <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> Hi Andrew, Thanks for looking at this. On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: > On 5/7/20 4:09 PM, Severin Gehwolf wrote: > > jvm_version_info.jvm_version currently holds this quadruplet: > > > > Most significant 8 bits => major version, followed by 8 bits => minor > > version, followed by 8 bits => micro version, followed by 8 bits => > > build version. Note that JVM minor version represents the update > > version as passed in via configure and the micro version is currently > > not used (always 0). See vm_version.cpp lines 100-102 where only major, > > minor and build number are ever been set. Knowing this, we can still > > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > > 0 for any version. > > This is tricky. JVM_GetVersionInfo is a function exported by > libjvm.so, and the version is simply encoded as > > unsigned int Abstract_VM_Version::jvm_version() { > return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | > ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | > (Abstract_VM_Version::vm_build_number() & 0xFF); > } > > I guess we could argue that this is for JVM-JDK internal use only, and > no-one else cares. > > Or we could encode it in a different way such that at least we have a > jvm_version that is monotonically increasing, perhaps by (ab)using the > lower 8 bits of the version, the vm_build_number. But I guess I'm > being paranoid, and no tools are going to care about minor versions > anyway,even if they do call JVM_GetVersionInfo. Yes, this is indeed tricky. The trouble is that Abstract_VM_Version::vm_build_number() actually holds the configured JDK build number, we can't really use it. It's already being used. (gdb) 99 100 _vm_major_version = atoi(vm_major_ver); 101 _vm_minor_version = atoi(vm_minor_ver); 102 _vm_build_number = atoi(vm_build_num); 103 104 os::free(vm_version); 105 _initialized = true; 106 } 107 108 #if defined(_LP64) (gdb) p _vm_build_number $1 = 2 The only bits which seem unused are bits 8 through 16 of this unsigned int. So even if JVM_GetVersionInfo *is* being used somewhere in the wild, it *should* continue to work. Hence, the proposal to now also use those unused bits for the minor version. Thoughts? Thanks, Severin From sgehwolf at redhat.com Tue May 12 15:21:03 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 May 2020 17:21:03 +0200 Subject: Options for fixing JapanEraNameCompatTest in OpenJDK 8u In-Reply-To: References: <0ebbb2ba3cb1f77df2db36958aa7a627cf09310e.camel@redhat.com> <331592ac8717012b6b4dc2b588620ca5fa4329d3.camel@redhat.com> Message-ID: <3c1865020be84de9dc1ecb37c031e8b50d270b7a.camel@redhat.com> On Tue, 2020-05-12 at 14:52 +0100, Andrew Haley wrote: > On 5/7/20 2:22 PM, Severin Gehwolf wrote: > > I'd propose to go with option 1. If consensus is that, I'll propose > > this for review. Thoughts? > > 1 LGTM. Thanks. I've filed JDK-8244843[1] to track this. Cheers, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8244843 From gnu.andrew at redhat.com Tue May 12 17:13:50 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 12 May 2020 18:13:50 +0100 Subject: Options for fixing JapanEraNameCompatTest in OpenJDK 8u In-Reply-To: <0ebbb2ba3cb1f77df2db36958aa7a627cf09310e.camel@redhat.com> References: <0ebbb2ba3cb1f77df2db36958aa7a627cf09310e.camel@redhat.com> Message-ID: On 10/03/2020 18:56, Severin Gehwolf wrote: > Hi, > > One of the failing tier1 tests in OpenJDK 8u is: > test/java/util/Calendar/JapanEraNameCompatTest.java > > It fails with: > java.lang.AssertionError: expected [Reiva] but found [\u0420\u0435\u0438\u0432\u0430] > at org.testng.Assert.fail(Assert.java:94) > test JapanEraNameCompatTest.testChronoJapanEraDisplayName(no, "Reiwa", "R"): failure > java.lang.AssertionError: expected [R] but found [Reiwa] > > I've looked into this and the test got added with the 8u backport of > JDK-8218781[1]. The reason why this fails for 8u and not for 11u is > because the locale data in 8u is different. I assume the 8u backport[2] > of 8218781 didn't include JavaTimeSupplementary_sr_Latn.java and > JavaTimeSupplementary_no.java changes since the prerequisite JDK- > 8008577[3] is not present in JDK 8u. Rightfully so. I don't think we'd > want to backport JDK-8008577 (switch to CLDR Locale Data by default) in > 8u. Long story short, we'd have two options to fix the test in 8u: > > Option 1: > Include necessary bits from JDK-8008577 and missing pieces from the > original JDK-8218781 changes for 'sr-Latn', 'no', 'sv', 'nl', 'lt', > 'in', 'hr' locales. 'sr-Latn' and 'no' are the ones which the test > exercises (webrev only includes 'sr-Latn' and 'no' locales for now): > http://cr.openjdk.java.net/~sgehwolf/webrevs/JapanEraNameCompatTest/option1/webrev/ > > Option 2: > Accept the fact that locale data for sr-Latn and no (and others) are > inferior to 11u locale data in the JRE provider and "fix" the test to > not exercise those locales. Other missing locales work because they > fall back to root locale: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JapanEraNameCompatTest/option2/webrev/ > > Either way this calls for an 8u-only bug and fix IMO. > > I'd propose to go with option 1. If consensus is that, I'll propose > this for review. Thoughts? > > Thanks, > Severin > > [1] https://bugs.openjdk.java.net/browse/JDK-8218781 > [2] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/5cf8e52254c2 > [3] https://bugs.openjdk.java.net/browse/JDK-8008577 > Option 1 is what I proposed when the test was first imported [0] and I feel that's still the right course of action. It's significant work to cherry-pick the required changes though, which is why I haven't had time to look into it since. [0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-June/009667.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue May 12 17:18:55 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 12 May 2020 18:18:55 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <4cc48d3ade76bb35e97d61f462b0e3323351692a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <7d9ede6d-3757-c235-0e4c-53821b6907ef@redhat.com> <4cc48d3ade76bb35e97d61f462b0e3323351692a.camel@redhat.com> Message-ID: <686c45c5-67a6-0f09-393c-7fc609e7bba6@redhat.com> On 12/05/2020 09:53, Severin Gehwolf wrote: snip... >> In code, >> >> unsigned int jdk_version; >> unsigned int update_version : 16; >> unsigned int reserved1 : 16; >> unsigned int reserved2; >> >> or, if we're wary about losing the name special_update_version, we could > > special_update_version seems at least be referenced in code. So we > would have to change those references. Given that, I'd go with reducing > reserved1 as that doesn't seem to be used. Yeah, can you tell I thought better of this, even as I was writing the e-mail? ;-) > >> shrink reserved1: >> >> unsigned int jdk_version; >> unsigned int update_version : 16; >> unsigned int special_update_version : 8; >> unsigned int reserved1 : 8; >> unsigned int reserved2; > > This is what webrev 03 does: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/03/ > > Does that look OK to you? This looks ok to me. I hadn't realised reserved1 was actually not reserved, but used for the build number. I think it's still fine though, as I can't recall seeing the build number go over 255 pre-GA, never mind in an update release. If we've done over 255 weeks of build promotions before a release, we have other problems. Maybe a rename is in order as part of this. I can't see reserved1 referenced anywhere in the codebase, and it's actually confusing that all the extraction code actually refers to it as the build number. reserved2 could then simply become reserved. > > Thanks, > Severin > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexey at azul.com Tue May 12 18:34:34 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 12 May 2020 18:34:34 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> Message-ID: Hello Martin, Thank you for coordinating the review process for this feature. As you suggested I?ve rebased TLS1.3 implementation. Now it is based on the 11.0.7 and applicable to 8u262 The full version of the patch is located at: http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/full/ This patch includes the following bug fixes (in addition to listed previously): JDK-8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 JDK-8218889: Improperly use of the Optional API JDK-4919790: Errors in alert ssl message does not reflect the actual certificate status JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl JDK-8229733: TLS message handling improvements JDK-8232424: More constrained algorithms JDK-8232581: Improve TLS verification JDK-8235691: Enhance TLS connectivity As suggested, I?ve split out the patch into the set of steps for better understanding the origin of the files and changes. 1) Remove files of original TLSv1.2 implementation that are not required for TLSv1.3 implementation. http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step0/ 2) Add TLSv1.3 implementation classes from 11.0.7 http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step1/ This patch also includes changes in the java.security property file and adds TLSv1.3 protocol definition in the SunJSSE provider class 3) Remove DTLS protocol implementation http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step2/ 4) Fix JDK 8 compatibility issues http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step3/ In most cases these changes related to using a class from another package or different language constructions. Also, this fix includes changes in the HandshakeHash class caused by the absence of MessageDigestSpi2 interface 5) Exclude JDK-8148188 (JFR security events) as it is not supported in 8u yet http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step4/ 6) Backport JDK-8038893 (Recertify certificate matching) for TLSv1.3 http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step5/ 7) OCSP stapling support http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step6/ OCSP is disabled by default on the client and server side. 8) Add TLS_KRB5 cipher suites according to RFC-2712 http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step7/ This functionality was excluded from the TLSv1.3 implementation in JDK11 Backport TLS_KRB5 cipher suites from the JDK8u 9) update for jtreg tests http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test/ This part is not separated yet. I?m going to sort it in the next iteration. Also, this patch does not include porting of the sun/security/pkcs11/sslecc tests. It's in progress. JCK8c tests passed, javax/net/ssl and sun/security/ssl jtreg test passed. tier1 and tier2 tests (except of sun/security/pkcs11/sslecc) are passed. Please verify that the keystore files in the test/sun/security/ssl/etc directory are updated by the patch Regards Alexey > On 7 May 2020, at 20:56, Martin Balao wrote: > > Hi, > > To proceed with the review of this proposal, we agreed on the following: > > * There will be a rebase of Webrev.04 to get TLS-related files from 11.0.7 > * Webrev.05 will be based on 8u262 (so no changes between 8u242 / > 8uMR3 and 8u262 should be missing) > > * Files replaced will appear as new files in the changeset, and changes > on top of them will appear in a separate patch > * This view is mainly for reviewing purposes. We will then decide how > to make it visible in the repository. > > * Current test failures on sun/security/ssl will be fixed > * No regressions should be observable in JDK-tier1, JDK-tier2 and > sun/security/ssl > > * As a review strategy, I'll separate patch changes in 2 groups: > * Changes within sun/security/ssl namespace > * Focus will be on changes required on top of replaced files to work > on 8u > * This should work as a coherent unit, implementation of the SunJSSE > provider and javax.net.ssl API > * Changes out of sun/security/ssl namespace > * Focus will be on each particular change > * File replacement is not expected here > * For each group, I need to understand the rational behind each change > and the implications on other files (involved changesets scope) > * We will document these findings in the public list (here) > > * Azul may decide to propose a fallback scheme to bring the 'legacy' 8u > TLS engine as a configurable non-default provider. This was not strictly > required as part of my review but we will certainly evaluate it. > > * More independent reviewers are welcomed. So far, there are internal > reviewers from Azul and externals from Red Hat. > > * Target date for inclusion is still under discussion; but most of the > review work is expected for the end of May. > > Thanks, > Martin.- > From sgehwolf at redhat.com Tue May 12 18:40:57 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 May 2020 20:40:57 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <686c45c5-67a6-0f09-393c-7fc609e7bba6@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <7d9ede6d-3757-c235-0e4c-53821b6907ef@redhat.com> <4cc48d3ade76bb35e97d61f462b0e3323351692a.camel@redhat.com> <686c45c5-67a6-0f09-393c-7fc609e7bba6@redhat.com> Message-ID: <04f064cca41f0f5e86ded049976586371b045e97.camel@redhat.com> On Tue, 2020-05-12 at 18:18 +0100, Andrew Hughes wrote: > > On 12/05/2020 09:53, Severin Gehwolf wrote: > > snip... > > > > In code, > > > > > > unsigned int jdk_version; > > > unsigned int update_version : 16; > > > unsigned int reserved1 : 16; > > > unsigned int reserved2; > > > > > > or, if we're wary about losing the name special_update_version, we could > > > > special_update_version seems at least be referenced in code. So we > > would have to change those references. Given that, I'd go with reducing > > reserved1 as that doesn't seem to be used. > > Yeah, can you tell I thought better of this, even as I was writing the > e-mail? ;-) :) > > > shrink reserved1: > > > > > > unsigned int jdk_version; > > > unsigned int update_version : 16; > > > unsigned int special_update_version : 8; > > > unsigned int reserved1 : 8; > > > unsigned int reserved2; > > > > This is what webrev 03 does: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/03/ > > > > Does that look OK to you? > > This looks ok to me. Thanks for the review! > I hadn't realised reserved1 was actually not reserved, but used for the > build number. I think it's still fine though, as I can't recall seeing > the build number go over 255 pre-GA, never mind in an update release. If > we've done over 255 weeks of build promotions before a release, we have > other problems. This sounds strange. Where do you see reserved1 being accessed as build number? For jdk_version_info the build number is part of the 32 bit unsigned int 'jdk_version_info.jdk_version'. That remains unchanged. What we *do* change with is bit-fields after the jdk_version integer. It's jvm_version_info.jvm_version which includes unused bits as part of the major, minor, micro, build quadruplet. micro is unused there, hence the proposal that we extend minor (the JDK update version) so that it can fit up to a max of 2^16-1. It beats me who came up with those weird conventions. > Maybe a rename is in order as part of this. I can't see reserved1 > referenced anywhere in the codebase, and it's actually confusing that > all the extraction code actually refers to it as the build number. > reserved2 could then simply become reserved. I don't think that makes sense and would rather avoid more churn. Am I missing something? Thanks, Severin From denghui.ddh at alibaba-inc.com Wed May 13 01:56:20 2020 From: denghui.ddh at alibaba-inc.com (Denghui Dong) Date: Wed, 13 May 2020 09:56:20 +0800 Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSIDgyMjU3OTc6IFtiYWNrcG9ydF0gT2xkT2JqZWN0U2FtcGxlIGV2ZW50?= =?UTF-8?B?IGNyZWF0ZXMgdW5leHBlY3RlZCBhbW91bnQgb2YgY2hlY2twb2ludCBkYXRh?= In-Reply-To: <0be06b28-6912-4f5d-84e5-5edf8833f92b.denghui.ddh@alibaba-inc.com> References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com>, <8225cc35-fa62-4df2-b7a4-689b9f0726e6.>, <0be06b28-6912-4f5d-84e5-5edf8833f92b.denghui.ddh@alibaba-inc.com> Message-ID: <4b66d9ea-6e80-47da-87f9-030da0a8845b.denghui.ddh@alibaba-inc.com> Gentle ping? ------------------------------------------------------------------ From:???(??) Send Time:2020?5?6?(???) 17:01 To:jdk8u-dev ; "Jaroslav Bachor?k" ; Mario Torre Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data Thank you, Jaroslav! @Mario, Could you review this backport? Denghui Dong ------------------------------------------------------------------ From:Jaroslav Bachor?k Send Time:2020?5?6?(???) 15:38 To:???(??) ; jdk8u-dev Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data Hi Dennghui, Thanks for taking care of this. The change looks good but with the usual disclaimer "I am not a reviewer". Cheers, -JB- On Wed, May 6, 2020 at 7:25 AM Denghui Dong wrote: > > Hi Jaroslav, > > Sorry for the late reply due to a long holiday. > > > 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > > L113 and L116 - perhaps the commented out asserts can be removed > > completely? > fixed. > > > 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > > L158 - `module_lock` - > `package_lock`? > fixed. > > Thanks for the comments. > Webrev is still located in http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00 > > Cheers, > Denghui Dong > > ------------------------------------------------------------------ > From:Jaroslav Bachor?k > Send Time:2020?4?29?(???) 18:49 > To:???(??) > Cc:jdk8u-dev > Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data > > Hi Denghui, > > I have validated that the backport contains the changes from the > original changeset and that the conflicts were resolved correctly. > > I have only two minor comments: > > 1. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > L113 and L116 - perhaps the commented out asserts can be removed > completely? > 2. http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > L158 - `module_lock` - > `package_lock`? > > Cheers, > > -JB- > > On Sun, Apr 26, 2020 at 3:52 PM Denghui Dong > wrote: > > > > Hi team, > > Please review the following backport. > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8225797 > > Original patch: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2a13c6785ad2 > > Webrev: http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/ > > > > Some code has been commented out because those facilities(e.g. Module and Package) is not supported in 8u, > > so the original patch can not apply cleanly. Matter of fact, the backport is mostly manual. > > I put all reject files in http://cr.openjdk.java.net/~ddong/8225797/rej/ > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > Cheers, > > Denghui Dong From neugens at redhat.com Wed May 13 11:07:50 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 13 May 2020 13:07:50 +0200 Subject: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data In-Reply-To: <4b66d9ea-6e80-47da-87f9-030da0a8845b.denghui.ddh@alibaba-inc.com> References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com> , <8225cc35-fa62-4df2-b7a4-689b9f0726e6.> , <0be06b28-6912-4f5d-84e5-5edf8833f92b.denghui.ddh@alibaba-inc.com> <4b66d9ea-6e80-47da-87f9-030da0a8845b.denghui.ddh@alibaba-inc.com> Message-ID: <923950d4f0c4bd8e50ec02a79d43b87aa8014d6a.camel@redhat.com> On Wed, 2020-05-13 at 09:56 +0800, Denghui Dong wrote: > Gentle ping? > Hi Denghui, Sorry, the patch is really big so it's taking some time, but I asked some help ;) The two things that come quickly though are the commented out code blocks and the backport bug manually created. For the first, I think it's better to remove all those blocks of commented code, they will just make it more difficult to apply further fixes, also all those XXX don't really make a lot of sense to anyone else but the person who is working on the backport or the feature in the first place, they should not be present. If we have the need for them, it means the backport is not complete and should be addressed, alternatively a bug should be filed with the proper description of the problem. I know we let some of those slip in the JFR backport, but that wasn't really fully intentional. Regarding the backport bug, it will be created automatically for you when you do commit, so you don't need to create them manually. The patch looks good otherwise, but I need a bit more time before completing the review. Cheers, Mario > ------------------------------------------------------------------ > From:???(??) > Send Time:2020?5?6?(???) 17:01 > To:jdk8u-dev ; "Jaroslav Bachor?k" < > jaroslav.bachorik at datadoghq.com>; Mario Torre > Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event > creates unexpected amount of checkpoint data > > Thank you, Jaroslav! > > @Mario, Could you review this backport? > > Denghui Dong > ------------------------------------------------------------------ > From:Jaroslav Bachor?k > Send Time:2020?5?6?(???) 15:38 > To:???(??) ; jdk8u-dev < > jdk8u-dev at openjdk.java.net> > Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event > creates unexpected amount of checkpoint data > > Hi Dennghui, > > Thanks for taking care of this. The change looks good but with the > usual disclaimer "I am not a reviewer". > > Cheers, > > -JB- > > On Wed, May 6, 2020 at 7:25 AM Denghui Dong < > denghui.ddh at alibaba-inc.com> wrote: > > Hi Jaroslav, > > > > Sorry for the late reply due to a long holiday. > > > > > 1. > > > http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > > > L113 and L116 - perhaps the commented out asserts can be removed > > > completely? > > fixed. > > > > > 2. > > > http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > > > L158 - `module_lock` - > `package_lock`? > > fixed. > > > > Thanks for the comments. > > Webrev is still located in > > http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00 > > > > Cheers, > > Denghui Dong > > > > ------------------------------------------------------------------ > > From:Jaroslav Bachor?k > > Send Time:2020?4?29?(???) 18:49 > > To:???(??) > > Cc:jdk8u-dev > > Subject:Re: [8u] RFR 8225797: [backport] OldObjectSample event > > creates unexpected amount of checkpoint data > > > > Hi Denghui, > > > > I have validated that the backport contains the changes from the > > original changeset and that the conflicts were resolved correctly. > > > > I have only two minor comments: > > > > 1. > > http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp.sdiff.html > > L113 and L116 - perhaps the commented out asserts can be removed > > completely? > > 2. > > http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp.sdiff.html > > L158 - `module_lock` - > `package_lock`? > > > > Cheers, > > > > -JB- > > > > On Sun, Apr 26, 2020 at 3:52 PM Denghui Dong > > wrote: > > > Hi team, > > > Please review the following backport. > > > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8225797 > > > Original patch: > > > https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2a13c6785ad2 > > > Webrev: http://cr.openjdk.java.net/~ddong/8225797/8u/webrev.00/ > > > > > > Some code has been commented out because those facilities(e.g. > > > Module and Package) is not supported in 8u, > > > so the original patch can not apply cleanly. Matter of fact, the > > > backport is mostly manual. > > > I put all reject files in > > > http://cr.openjdk.java.net/~ddong/8225797/rej/ > > > > > > All tests from jdk_jfr are passing after this patch has been > > > applied. > > > > > > Cheers, > > > Denghui Dong -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From sgehwolf at redhat.com Wed May 13 14:59:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 May 2020 16:59:42 +0200 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails Message-ID: Hi, Could somebody please review this fix for the failing JapanEraNameCompatTest.java test (part of tier1)? The reason why it's failing is that there are missing locale data for no and sr_Latn which are exercised by the test. The original backport of JDK-8219781 didn't include those as the changed sections in the JDK 11 patch didn't exist in 8u. Those extra sections got introduced with JDK-8008577 or JDK- 8145136. This patch adds locale data for locales left out in the JDK-8219781 8u backport, except for JavaTimeSupplementary_in.java. That file doesn't exist at all in 8u, hence I've left that out. Missing locale info has been retrieved from JDK-8008577 and JDK-8145136 both of which aren't suitable to get backported to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8244843 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/01/webrev/ Testing: tier1. One less test failure, namely JapanEraNameCompatTest, no longer fails. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Wed May 13 15:11:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 16:11:02 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> Message-ID: On 12/05/2020 15:14, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for looking at this. > > On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: >> On 5/7/20 4:09 PM, Severin Gehwolf wrote: >>> jvm_version_info.jvm_version currently holds this quadruplet: >>> >>> Most significant 8 bits => major version, followed by 8 bits => minor >>> version, followed by 8 bits => micro version, followed by 8 bits => >>> build version. Note that JVM minor version represents the update >>> version as passed in via configure and the micro version is currently >>> not used (always 0). See vm_version.cpp lines 100-102 where only major, >>> minor and build number are ever been set. Knowing this, we can still >>> preserve the same behavior after patch by defining JVM_VERSION_MICRO to >>> 0 for any version. >> >> This is tricky. JVM_GetVersionInfo is a function exported by >> libjvm.so, and the version is simply encoded as >> >> unsigned int Abstract_VM_Version::jvm_version() { >> return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | >> ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | >> (Abstract_VM_Version::vm_build_number() & 0xFF); >> } >> >> I guess we could argue that this is for JVM-JDK internal use only, and >> no-one else cares. >> >> Or we could encode it in a different way such that at least we have a >> jvm_version that is monotonically increasing, perhaps by (ab)using the >> lower 8 bits of the version, the vm_build_number. But I guess I'm >> being paranoid, and no tools are going to care about minor versions >> anyway,even if they do call JVM_GetVersionInfo. > > Yes, this is indeed tricky. The trouble is that > Abstract_VM_Version::vm_build_number() actually holds the configured > JDK build number, we can't really use it. It's already being used. > > (gdb) > 99 > 100 _vm_major_version = atoi(vm_major_ver); > 101 _vm_minor_version = atoi(vm_minor_ver); > 102 _vm_build_number = atoi(vm_build_num); > 103 > 104 os::free(vm_version); > 105 _initialized = true; > 106 } > 107 > 108 #if defined(_LP64) > (gdb) p _vm_build_number > $1 = 2 > > The only bits which seem unused are bits 8 through 16 of this unsigned > int. So even if JVM_GetVersionInfo *is* being used somewhere in the > wild, it *should* continue to work. Hence, the proposal to now also use > those unused bits for the minor version. > > Thoughts? > > Thanks, > Severin > The April release of OpenJDK 7u has the values: Major version: 24, minor version: 5, micro version: 0, build number: 2 when it should be 24.261-b02. So we already have a situation that could be potentially be misinterpreted as an old JDK version, 7u5 b02, using the current interpretation of the structure. 8u will see similar issues if we make no change in this cycle. As the micro version appears to have always been zero, it seems pretty safe to just hard-code this value and instead use all 16 bits of the interpreted value for the micro version. In terms of backwards compatibility, if a micro version greater than zero is read using the old method, this will be an indicator that it needs to be re-interpreted as a 16-bit value. The current value for 7 is 402980866 (0001 1000 0000 0101 0000 0000 0000 0010) which thus gets interpreted as above. The new method encodes the same version numbers as 402720002 (0001 1000 0000 0001 0000 0101 0000 0010) which can be read back as major 24, minor 261, micro 0 and build 2 using the updated decoding. If the old decoding is used, we get major 24, minor 1, micro 5 and build 2. As micro is usually set to zero, updated code should be able to use this to instead use the new interpretation, while, in the worst case, stale code will get a unique, if incorrect, version. As 7u releases are oddly numbered and increment in tens, we won't hit a case where the second byte (the old micro version) is zero. With 8u, this will happen where the update version is a multiple of 256 (e.g. 8u512, 8u1792, ...) Regarding the contract of this API, it is generally used only for interactions between the JVM and the class library. jvm.h is not included in the JDK image. Attempts to follow the API when CACAO & JamVM were still trying to work with OpenJDK suggest it has been unstable even across update releases [0] [1]. [0] https://icedtea.classpath.org/hg/icedtea7/rev/810d698ffdfb [1] https://icedtea.classpath.org/hg/icedtea7/rev/139f2a8f085d -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexey at azul.com Wed May 13 15:59:03 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 13 May 2020 15:59:03 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> Message-ID: Hello, Please find the patch for sun/security/pkcs11/sslecc regression tests : http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test.sslecc/ Now I do not see any regressions in the tiers test run Alexey > On 12 May 2020, at 21:35, Alexey Bakhtin wrote: > > Hello Martin, > > Thank you for coordinating the review process for this feature. > As you suggested I?ve rebased TLS1.3 implementation. > Now it is based on the 11.0.7 and applicable to 8u262 > The full version of the patch is located at: http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/full/ > > This patch includes the following bug fixes (in addition to listed previously): > JDK-8225766: Curve in certificate should not affect signature scheme when using TLSv1.3 > JDK-8236039: JSSE Client does not accept status_request extension in CertificateRequest messages for TLS 1.3 > JDK-8218889: Improperly use of the Optional API > JDK-4919790: Errors in alert ssl message does not reflect the actual certificate status > JDK-8221270: Duplicated synchronized keywords in SSLSocketImpl > JDK-8229733: TLS message handling improvements > JDK-8232424: More constrained algorithms > JDK-8232581: Improve TLS verification > JDK-8235691: Enhance TLS connectivity > > As suggested, I?ve split out the patch into the set of steps for better understanding the origin of the files and changes. > 1) Remove files of original TLSv1.2 implementation that are not required for TLSv1.3 implementation. > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step0/ > 2) Add TLSv1.3 implementation classes from 11.0.7 > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step1/ > This patch also includes changes in the java.security property file and adds TLSv1.3 protocol definition in the SunJSSE provider class > 3) Remove DTLS protocol implementation > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step2/ > 4) Fix JDK 8 compatibility issues > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step3/ > In most cases these changes related to using a class from another package or different language constructions. > Also, this fix includes changes in the HandshakeHash class caused by the absence of MessageDigestSpi2 interface > 5) Exclude JDK-8148188 (JFR security events) as it is not supported in 8u yet > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step4/ > 6) Backport JDK-8038893 (Recertify certificate matching) for TLSv1.3 > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step5/ > 7) OCSP stapling support > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step6/ > OCSP is disabled by default on the client and server side. > 8) Add TLS_KRB5 cipher suites according to RFC-2712 > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step7/ > This functionality was excluded from the TLSv1.3 implementation in JDK11 > Backport TLS_KRB5 cipher suites from the JDK8u > 9) update for jtreg tests > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test/ > This part is not separated yet. I?m going to sort it in the next iteration. > Also, this patch does not include porting of the sun/security/pkcs11/sslecc tests. It's in progress. > > JCK8c tests passed, javax/net/ssl and sun/security/ssl jtreg test passed. > tier1 and tier2 tests (except of sun/security/pkcs11/sslecc) are passed. > Please verify that the keystore files in the test/sun/security/ssl/etc directory are updated by the patch > > Regards > Alexey > >> On 7 May 2020, at 20:56, Martin Balao wrote: >> >> Hi, >> >> To proceed with the review of this proposal, we agreed on the following: >> >> * There will be a rebase of Webrev.04 to get TLS-related files from 11.0.7 >> * Webrev.05 will be based on 8u262 (so no changes between 8u242 / >> 8uMR3 and 8u262 should be missing) >> >> * Files replaced will appear as new files in the changeset, and changes >> on top of them will appear in a separate patch >> * This view is mainly for reviewing purposes. We will then decide how >> to make it visible in the repository. >> >> * Current test failures on sun/security/ssl will be fixed >> * No regressions should be observable in JDK-tier1, JDK-tier2 and >> sun/security/ssl >> >> * As a review strategy, I'll separate patch changes in 2 groups: >> * Changes within sun/security/ssl namespace >> * Focus will be on changes required on top of replaced files to work >> on 8u >> * This should work as a coherent unit, implementation of the SunJSSE >> provider and javax.net.ssl API >> * Changes out of sun/security/ssl namespace >> * Focus will be on each particular change >> * File replacement is not expected here >> * For each group, I need to understand the rational behind each change >> and the implications on other files (involved changesets scope) >> * We will document these findings in the public list (here) >> >> * Azul may decide to propose a fallback scheme to bring the 'legacy' 8u >> TLS engine as a configurable non-default provider. This was not strictly >> required as part of my review but we will certainly evaluate it. >> >> * More independent reviewers are welcomed. So far, there are internal >> reviewers from Azul and externals from Red Hat. >> >> * Target date for inclusion is still under discussion; but most of the >> review work is expected for the end of May. >> >> Thanks, >> Martin.- >> > From gnu.andrew at redhat.com Wed May 13 16:37:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 17:37:00 +0100 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: References: Message-ID: On 13/05/2020 15:59, Severin Gehwolf wrote: > Hi, > > Could somebody please review this fix for the failing > JapanEraNameCompatTest.java test (part of tier1)? The reason why it's > failing is that there are missing locale data for no and sr_Latn which > are exercised by the test. The original backport of JDK-8219781 didn't > include those as the changed sections in the JDK 11 patch didn't exist > in 8u. Those extra sections got introduced with JDK-8008577 or JDK- > 8145136. This also includes the JDK-8219781 changes for these locales. I think it's worth mentioning all three bug IDs in the summary text so they appear in a keyword search. Changes for these locales look ok to me. > > This patch adds locale data for locales left out in the JDK-8219781 8u > backport, except for JavaTimeSupplementary_in.java. That file doesn't > exist at all in 8u, hence I've left that out. This doesn't make sense to me. The in locale is present in sun/text/resources, but the only one without JavaTimeSupplementary_*: $ for locales in $(find jdk/src/share/classes/sun/text/resources/ -maxdepth 1 -mindepth 1 -type d) > do > locale=$(basename ${locales}) > echo ${locale}; ls ${locales}/JavaTimeSupplementary_${locale}* > done pt jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java ro jdk/src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java hr jdk/src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java es jdk/src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java de jdk/src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java in ls: cannot access 'jdk/src/share/classes/sun/text/resources/in/JavaTimeSupplementary_in*': No such file or directory tr jdk/src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java sk jdk/src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java mk jdk/src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java ca jdk/src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java iw jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java is jdk/src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java lv jdk/src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java sq jdk/src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java vi jdk/src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java hu jdk/src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java ms jdk/src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java no jdk/src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java et jdk/src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java da jdk/src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java sr jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java th jdk/src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java it jdk/src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java bg jdk/src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java lt jdk/src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java el jdk/src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java pl jdk/src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java ja jdk/src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java ru jdk/src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java be jdk/src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java fi jdk/src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java cs jdk/src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java hi jdk/src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java en jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java sv jdk/src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java ga jdk/src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java fr jdk/src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java zh jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java uk jdk/src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java nl jdk/src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java ko jdk/src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java ar jdk/src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java mt jdk/src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java sl jdk/src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java The file is introduced in JDK-8145136. Why not just take it from there and update with the changes in JDK-8219781? The test passes for this locale (as it does for nl, which is updated in this patch) because the values are the same as for the base locale (English). but there are other translations in that file which are missing in 8u. > > Missing locale info has been retrieved from JDK-8008577 and JDK-8145136 > both of which aren't suitable to get backported to 8u. Agreed. The problem with these changesets is they attempt to do everything in bulk. It's a problem I've seen with such changes before. We don't want to backport the CLDR update, but the updates to legacy locale data should be ok. We did used to get locale data updates with most CPUs. I haven't seen those since we switched to the current update system, which is a little worrying. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244843 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/01/webrev/ > > Testing: tier1. One less test failure, namely JapanEraNameCompatTest, > no longer fails. > > Thoughts? > I guess the number of people hitting the lack of a Serbian translation of a Japanese era name in the Latin character set was small, but it's good to have this fixed. Thanks for looking into it. > Thanks, > Severin > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed May 13 16:52:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 17:52:16 +0100 Subject: [8u] RFR: 8146612: C2: Precedence edges specification violated In-Reply-To: <87v9n4ie2h.fsf@redhat.com> References: <87v9n4ie2h.fsf@redhat.com> Message-ID: On 16/03/2020 14:12, Roland Westrelin wrote: > > Change does not apply cleanly to 8u in node.hpp (copyright change) and > node.cpp: (copyright change and methods > Node::del_req()/Node::del_req_ordered()). The 8u change is identical to > the one from 11u but code in Node::del_req()/Node::del_req_ordered() > changed abit. This is required in order to backport 8214862: assert(proj > != __null) at compile.cpp:3251. > > http://cr.openjdk.java.net/~roland/8146612.8u/webrev.00/ > > Initial change: > https://bugs.openjdk.java.net/browse/JDK-8146612 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6615ec051d9 > > Tested with tier1. > > Roland. > Looks ok to me (change the same, bar addition of err_msg wrapper) Approved for 8u. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Wed May 13 19:26:19 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 May 2020 21:26:19 +0200 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: References: Message-ID: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> Hi Andrew, Thanks for looking at this. On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: > On 13/05/2020 15:59, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review this fix for the failing > > JapanEraNameCompatTest.java test (part of tier1)? The reason why it's > > failing is that there are missing locale data for no and sr_Latn which > > are exercised by the test. The original backport of JDK-8219781 didn't > > include those as the changed sections in the JDK 11 patch didn't exist > > in 8u. Those extra sections got introduced with JDK-8008577 or JDK- > > 8145136. > > This also includes the JDK-8219781 changes for these locales. I think > it's worth mentioning all three bug IDs in the summary text so they > appear in a keyword search. OK, done. > Changes for these locales look ok to me. > > > This patch adds locale data for locales left out in the JDK-8219781 8u > > backport, except for JavaTimeSupplementary_in.java. That file doesn't > > exist at all in 8u, hence I've left that out. > > This doesn't make sense to me. The in locale is present in > sun/text/resources, but the only one without JavaTimeSupplementary_*: Sorry for not being clear. I meant that there is no JavaTimeSupplementary_in.java in 8u (prior this patch). > $ for locales in $(find jdk/src/share/classes/sun/text/resources/ > -maxdepth 1 -mindepth 1 -type d) > > do > > locale=$(basename ${locales}) > > echo ${locale}; ls ${locales}/JavaTimeSupplementary_${locale}* > > done > pt > jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java > jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java > ro > jdk/src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java > hr > jdk/src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java > es > jdk/src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java > de > jdk/src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java > in > ls: cannot access > 'jdk/src/share/classes/sun/text/resources/in/JavaTimeSupplementary_in*': > No such file or directory > tr > jdk/src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java > sk > jdk/src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java > mk > jdk/src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java > ca > jdk/src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java > iw > jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java > jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java > is > jdk/src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java > lv > jdk/src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java > sq > jdk/src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java > vi > jdk/src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java > hu > jdk/src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java > ms > jdk/src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java > no > jdk/src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java > et > jdk/src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java > da > jdk/src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java > sr > jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java > jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java > th > jdk/src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java > it > jdk/src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java > bg > jdk/src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java > lt > jdk/src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java > el > jdk/src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java > pl > jdk/src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java > ja > jdk/src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java > ru > jdk/src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java > be > jdk/src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java > fi > jdk/src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java > cs > jdk/src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java > hi > jdk/src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java > en > jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java > jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java > jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java > sv > jdk/src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java > ga > jdk/src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java > fr > jdk/src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java > zh > jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java > jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java > uk > jdk/src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java > nl > jdk/src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java > ko > jdk/src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java > ar > jdk/src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java > mt > jdk/src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java > sl > jdk/src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java > > The file is introduced in JDK-8145136. Why not just take it from there > and update with the changes in JDK-8219781? Sure. Done now: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/02/webrev/ > The test passes for this locale (as it does for nl, which is updated in > this patch) because the values are the same as for the base locale > (English). but there are other translations in that file which are > missing in 8u. > > > Missing locale info has been retrieved from JDK-8008577 and JDK-8145136 > > both of which aren't suitable to get backported to 8u. > > Agreed. > > The problem with these changesets is they attempt to do everything in > bulk. It's a problem I've seen with such changes before. We don't want > to backport the CLDR update, but the updates to legacy locale data > should be ok. How does the updated webrev above look to you? > We did used to get locale data updates with most CPUs. I haven't seen > those since we switched to the current update system, which is a little > worrying. Good point. Thanks, Severin > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244843 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/01/webrev/ > > > > Testing: tier1. One less test failure, namely JapanEraNameCompatTest, > > no longer fails. > > > > Thoughts? > > > > I guess the number of people hitting the lack of a Serbian translation > of a Japanese era name in the Latin character set was small, but it's > good to have this fixed. Thanks for looking into it. > > > Thanks, > > Severin > > From gnu.andrew at redhat.com Wed May 13 22:31:47 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 23:31:47 +0100 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set(Internet mail) In-Reply-To: <4EA5C01E-D93E-4B9D-85CA-8CAF8AE9438D@tencent.com> References: <50DB97FE-1E39-4B84-B302-AD832843E871@amazon.com> <66D21DA6-0F63-4F10-9548-D07820924AE5@tencent.com> <4EA5C01E-D93E-4B9D-85CA-8CAF8AE9438D@tencent.com> Message-ID: <7d0b306e-fb32-5430-8e80-72e5e76c2a01@redhat.com> On 28/04/2020 17:14, linzang(??) wrote: > Hi Paul and Xin, > Here are the latest patches: > Issue: https://bugs.openjdk.java.net/browse/JDK-8241638 > Webrev: http://cr.openjdk.java.net/~lzang/8241638/8u/webrev03/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8243539 > Webrev: http://cr.openjdk.java.net/~lzang/8243539/webrev8u/ > Thanks! > > > BRs, > Lin > This version seemed to be missing the CounterGet spacing correction present in HEAD & 11u. I've reinstated it, approved and pushed the change: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/2bfb640ed266 Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed May 13 22:33:32 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 23:33:32 +0100 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> Message-ID: <915621fb-b85e-eaf2-49d5-84cd51d5af6a@redhat.com> On 24/04/2020 00:19, Liu, Xin wrote: > Hi, Zang, > > I am now a reviewer. I just offer helps to eyeball trivial issues. > > The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. No. The only situation in which a formal review should be skipped is when all that is required is the automated conversion of the file paths, using the unshuffle scripts. When manual work needs to be done, at least a cursory check is required. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From xxinliu at amazon.com Wed May 13 22:59:07 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 13 May 2020 22:59:07 +0000 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: <915621fb-b85e-eaf2-49d5-84cd51d5af6a@redhat.com> References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> <915621fb-b85e-eaf2-49d5-84cd51d5af6a@redhat.com> Message-ID: Hi, Andrew, Got it. I see why "cursory check" is necessary. Thank you to catch that! if (JLI_IsTraceLauncher()) { - end = CounterGet(); + end = CounterGet(); I made a typo. I am not* a reviewer. I will pay attention to the cursory things when I offer voluntary reviewing. Thanks, --lx ?On 5/13/20, 3:38 PM, "Andrew Hughes" wrote: On 24/04/2020 00:19, Liu, Xin wrote: > Hi, Zang, > > I am now a reviewer. I just offer helps to eyeball trivial issues. > > The patch is almost a clean backport. As long as you declare the patch can apply to jdk8u cleanly, I think you can skip the formal review. No. The only situation in which a formal review should be skipped is when all that is required is the automated conversion of the file paths, using the unshuffle scripts. When manual work needs to be done, at least a cursory check is required. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Thu May 14 20:08:23 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 14 May 2020 17:08:23 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> Message-ID: <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> Hi Alexey, I'll be reviewing step by step, starting with 0 now and running test suites in parallel. Step 0 ........................... A few comments / questions: * Shouldn't we include sun/security/ssl/EphemeralKeyManager.java, sun/security/ssl/JsseJce.java, sun/security/util/HostnameChecker.java and sun/security/ssl/SunJSSE.java as part of the files deleted by Step 0? * I see changes for all of them in 8196584 and, according to our strategy, they are in sun/security/ssl directory and will be file-replaced. * I'm okay if you prefer to keep sun/security/ssl/EphemeralKeyManager.java out of this group because the change in 8196584 was just a copyright date update -I'm not sure why because the file was not modified-. * Why was sun/security/ssl/KeyManagerFactoryImpl.java not modified? I see a change in 8196584. Some files are within sun/security/ssl but are not deleted by Step 0 and are not deleted or modified by 8196584 either (because they don't exist by the time 8196584 was applied, see 8038089): * classes/sun/security/ssl/KerberosClientKeyExchange.java * classes/sun/security/ssl/Krb5Helper.java * classes/sun/security/ssl/Krb5Proxy.java In the case of KerberosClientKeyExchange.java, I've seen it's modified by Step 7. A few questions: * Did you file-replaced KerberosClientKeyExchange.java * If this file is not in 11u, why do we need it in 8u? * Are Krb5Helper.java and Krb5Proxy.java used? * I assume they are for the same reason than my 1st question, but want to check just in case. Thanks, Martin.- From alexey at azul.com Thu May 14 21:09:29 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 14 May 2020 21:09:29 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> Message-ID: Hi Matrin, Thank you for review. I?ve decided to keep some original files in the sun.securyti.ssl package in case of no functional modifications. I think it indicates that these files are version independent and better shows what is changed in these files from one version to another. Please also see my comments below Regards Alexey > On 14 May 2020, at 23:08, Martin Balao wrote: > > Hi Alexey, > > I'll be reviewing step by step, starting with 0 now and running test > suites in parallel. > > Step 0 > ........................... > > A few comments / questions: > > * Shouldn't we include sun/security/ssl/EphemeralKeyManager.java, > sun/security/ssl/JsseJce.java, sun/security/util/HostnameChecker.java > and sun/security/ssl/SunJSSE.java as part of the files deleted by Step 0? > * I see changes for all of them in 8196584 and, according to our > strategy, they are in sun/security/ssl directory and will be file-replaced. SunJSSE class was hardly changed by JDK-7092821 in JDK11.0.7 JDK-7092821 is not part of JDK8, so I had two options: 1) use 11.0.7 version and revert JDK-7092821(huge changes) 2) use 8u262 version and add TLSv1.3 protocol definition (small changes) I decided to keep 8u262 version. In my opinion it better shows real modification in this file JsseJCE class in 11.0.7 was modified to remove TLS_KRB5 feature. The rest changes are code formatting. I decided to keep original version of this file and show required modification in the step 7 (TLSv1.3: RFC-2712 support). This file also contains small modification on the step, but final version of this file is not identical to 11.0.7. It is 8u262 version with required modifications HostNameChecker class is not located in the sun/security/ssl file. As I remember, we decided to not replace files outside of sun/security/ssl but show and describe changes. The changes in this file are related to JDK-8038893 and shown on the separate step 5 > * I'm okay if you prefer to keep > sun/security/ssl/EphemeralKeyManager.java out of this group because the > change in 8196584 was just a copyright date update -I'm not sure why > because the file was not modified-. > > * Why was sun/security/ssl/KeyManagerFactoryImpl.java not modified? I > see a change in 8196584. The only changes in this file - is code formatting. I decided to keep original JDK8u version because of no functional modification in the JDK11.0.7 version > > Some files are within sun/security/ssl but are not deleted by Step 0 and > are not deleted or modified by 8196584 either (because they don't exist > by the time 8196584 was applied, see 8038089): > > * classes/sun/security/ssl/KerberosClientKeyExchange.java > * classes/sun/security/ssl/Krb5Helper.java > * classes/sun/security/ssl/Krb5Proxy.java > > In the case of KerberosClientKeyExchange.java, I've seen it's modified > by Step 7. A few questions: > > * Did you file-replaced KerberosClientKeyExchange.java > * If this file is not in 11u, why do we need it in 8u? > > * Are Krb5Helper.java and Krb5Proxy.java used? > * I assume they are for the same reason than my 1st question, but want > to check just in case. These files are related to RFC-2712 support. This feature is declared in JDK8u but deprecated in 11u Some customers could still use this feature, so we can not just remove it in JDk8u. As soon as JDK11 does not have this feature I've kept old files related to RFC-2712 and added missing functionality in the step 7 > > Thanks, > Martin.- > From gnu.andrew at redhat.com Fri May 15 05:53:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 May 2020 06:53:49 +0100 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> References: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> Message-ID: On 13/05/2020 20:26, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for looking at this. > No problem. Thanks for taking it on. > On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: >> On 13/05/2020 15:59, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review this fix for the failing >>> JapanEraNameCompatTest.java test (part of tier1)? The reason why it's >>> failing is that there are missing locale data for no and sr_Latn which >>> are exercised by the test. The original backport of JDK-8219781 didn't >>> include those as the changed sections in the JDK 11 patch didn't exist >>> in 8u. Those extra sections got introduced with JDK-8008577 or JDK- >>> 8145136. >> >> This also includes the JDK-8219781 changes for these locales. I think >> it's worth mentioning all three bug IDs in the summary text so they >> appear in a keyword search. > > OK, done. I was thinking more along the lines: Summary: Backports hr, lt, in, nl, no, sr_Latn & sv changes from 8008577, 8145136 & 8219781 Do we want this to appear as a backport bug of those issues? > >> Changes for these locales look ok to me. >> >>> This patch adds locale data for locales left out in the JDK-8219781 8u >>> backport, except for JavaTimeSupplementary_in.java. That file doesn't >>> exist at all in 8u, hence I've left that out. >> >> This doesn't make sense to me. The in locale is present in >> sun/text/resources, but the only one without JavaTimeSupplementary_*: > > Sorry for not being clear. I meant that there is no > JavaTimeSupplementary_in.java in 8u (prior this patch). Yeah, I got that. I just didn't understand why you didn't just add the file. snip... > > Sure. Done now: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/02/webrev/ > ... > > How does the updated webrev above look to you? > Only issue with the patch itself is java.time.japanese.short.Eras is missing the new Reiwa era. I guess this is because 11u has JDK-8159943, which refactors these files so they share blocks where possible, before JDK-8219781. Thus, there is only one block to change in 11u, but it's a shared block which is then used from both java.time.japanese.short.Eras & java.time.japanese.long.Eras Looking at JDK-8219781 again, it is huge, but I don't think it actually changes much of the existing locales, just refactors them and adds some missing ones. I'm pondering whether a backport is worthwhile to avoid the duplication issue in future (without the LocaleData.java code changes). I guess it depends how likely it is we'll see more changes to locale data. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri May 15 05:56:54 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 May 2020 06:56:54 +0100 Subject: RFR(s): 8241638: [backport] launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set In-Reply-To: References: <87677EE3-CA02-4C29-B261-C13B25BB630B@tencent.com> <6AD583C2-249E-49C5-B6F9-3FB6F9F2D00D@amazon.com> <915621fb-b85e-eaf2-49d5-84cd51d5af6a@redhat.com> Message-ID: <56518a03-cb0a-2432-b96b-dedd4303029c@redhat.com> On 13/05/2020 23:59, Liu, Xin wrote: > Hi, Andrew, > > Got it. I see why "cursory check" is necessary. Thank you to catch that! > if (JLI_IsTraceLauncher()) { > - end = CounterGet(); > + end = CounterGet(); > > I made a typo. I am not* a reviewer. > I will pay attention to the cursory things when I offer voluntary reviewing. > > Thanks, > --lx > No worries. I usually start by getting both the 11u and the proposed 8u changes and doing a diff between them. That immediately stood out when I did that. I'm a little confused as to why it got lost, because the 11u patch applied fine to those files when I tried. It's only the Makefile that needed manual work. Anyway, these things get easier with experience :-) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri May 15 06:10:27 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 May 2020 07:10:27 +0100 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> Message-ID: On 05/04/2020 20:44, Sergey Nazarkin wrote: > Thanks, Andrew. In simpler case 8037866(Replace the Fun class in tests with lambdas) only misses a part of MOAT.java that was introduced by 8014066(ArrayList#removeRange): > > $cat test/java/util/Collection/MOAT.java.rej > --- MOAT.java > +++ MOAT.java > @@ -728,8 +722,8 @@ > l.listIterator(0); > l.listIterator(l.size()); > THROWS(IndexOutOfBoundsException.class, > - new Fun(){void f(){l.listIterator(-1);}}, > - new Fun(){void f(){l.listIterator(l.size() + 1);}}); > + () -> l.listIterator(-1), > + () -> l.listIterator(l.size() + 1)); > > if (l instanceof AbstractList) { > try { > > Final patchset would be > > 1) http://cr.openjdk.java.net/~snazarki/webrev/8037866/ > 2) http://cr.openjdk.java.net/~snazarki/webrev/8067796/ > > > > Sergey Nazarkin > Sorry for the delay on this. 8037866 looks fine to me and we shouldn't introduce 8014066, which may change java.util.ArrayList behaviour. I'll look at 8067796 again once 8037866 is pushed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Fri May 15 08:45:03 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 May 2020 10:45:03 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> Message-ID: <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Hi, On Wed, 2020-05-13 at 16:11 +0100, Andrew Hughes wrote: > On 12/05/2020 15:14, Severin Gehwolf wrote: > > Hi Andrew, > > > > Thanks for looking at this. > > > > On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: > > > On 5/7/20 4:09 PM, Severin Gehwolf wrote: > > > > jvm_version_info.jvm_version currently holds this quadruplet: > > > > > > > > Most significant 8 bits => major version, followed by 8 bits => minor > > > > version, followed by 8 bits => micro version, followed by 8 bits => > > > > build version. Note that JVM minor version represents the update > > > > version as passed in via configure and the micro version is currently > > > > not used (always 0). See vm_version.cpp lines 100-102 where only major, > > > > minor and build number are ever been set. Knowing this, we can still > > > > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > > > > 0 for any version. > > > > > > This is tricky. JVM_GetVersionInfo is a function exported by > > > libjvm.so, and the version is simply encoded as > > > > > > unsigned int Abstract_VM_Version::jvm_version() { > > > return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | > > > ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | > > > (Abstract_VM_Version::vm_build_number() & 0xFF); > > > } > > > > > > I guess we could argue that this is for JVM-JDK internal use only, and > > > no-one else cares. > > > > > > Or we could encode it in a different way such that at least we have a > > > jvm_version that is monotonically increasing, perhaps by (ab)using the > > > lower 8 bits of the version, the vm_build_number. But I guess I'm > > > being paranoid, and no tools are going to care about minor versions > > > anyway,even if they do call JVM_GetVersionInfo. > > > > Yes, this is indeed tricky. The trouble is that > > Abstract_VM_Version::vm_build_number() actually holds the configured > > JDK build number, we can't really use it. It's already being used. > > > > (gdb) > > 99 > > 100 _vm_major_version = atoi(vm_major_ver); > > 101 _vm_minor_version = atoi(vm_minor_ver); > > 102 _vm_build_number = atoi(vm_build_num); > > 103 > > 104 os::free(vm_version); > > 105 _initialized = true; > > 106 } > > 107 > > 108 #if defined(_LP64) > > (gdb) p _vm_build_number > > $1 = 2 > > > > The only bits which seem unused are bits 8 through 16 of this unsigned > > int. So even if JVM_GetVersionInfo *is* being used somewhere in the > > wild, it *should* continue to work. Hence, the proposal to now also use > > those unused bits for the minor version. > > > > Thoughts? > > > > Thanks, > > Severin > > > > The April release of OpenJDK 7u has the values: > > Major version: 24, minor version: 5, micro version: 0, build number: 2 > > when it should be 24.261-b02. So we already have a situation that could > be potentially be misinterpreted as an old JDK version, 7u5 b02, using > the current interpretation of the structure. 8u will see similar issues > if we make no change in this cycle. Yes. I believe we need to get this fixed. The earlier in the 262 update cycle the better. > As the micro version appears to have always been zero, it seems pretty > safe to just hard-code this value and instead use all 16 bits of the > interpreted value for the micro version. In terms of backwards > compatibility, if a micro version greater than zero is read using the > old method, this will be an indicator that it needs to be > re-interpreted as a 16-bit value. As Andrew Hughes mentioned below, the only way to see the difference post-patch would be for somebody to use old jvm.h defines *and* use a supposedly a JDK private API (JVM_GetVersionInfo). It is an exported symbol, but as Andrew Hughes pointed out, for JDK <=> hotspot communication. On the other hand, the chance of somebody using forbidden (access restricted), yet available API via sun.misc.Version is more likely. Of which the following are broken (see my latest comment on the bug[1]): sun.misc.Version.jvmMinorVersion() sun.misc.Version.jdkUpdateVersion() Post patch the above are fixed, but somebody using JVM_GetVersionInfo directly with old jvm.h macros would get for 8u262-b03 (pseudo code): #define JVM_VERSION_MAJOR(version) ((version & 0xFF000000) >> 24) #define JVM_VERSION_MINOR(version) ((version & 0x00FF0000) >> 16) #define JVM_VERSION_MICRO(version) ((version & 0x0000FF00) >> 8) #define JVM_VERSION_BUILD(version) ((version & 0x000000FF)) jvm_version_info info; [ call JVM_GetVersionInfo, etc. ] JVM_VERSION_MAJOR(info.jvm_version) // => 25 JVM_VERSION_MINOR(info.jvm_version) // => 1 JVM_VERSION_MICRO(info.jvm_version) // => 6 JVM_VERSION_BUILD(info.jvm_version) // => 3 So, minor, micro would be wrong. Question is what's more likely in use today in the wild? JVM_GetVersionInfo or sun.misc.Version. > The current value for 7 is 402980866 > (0001 1000 0000 0101 0000 0000 0000 0010) > which thus gets interpreted as above. > > The new method encodes the same version numbers as 402720002 > (0001 1000 0000 0001 0000 0101 0000 0010) > > which can be read back as major 24, minor 261, micro 0 and build 2 using > the updated decoding. > > If the old decoding is used, we get major 24, minor 1, micro 5 and build > 2. As micro is usually set to zero, updated code should be able to use > this to instead use the new interpretation, while, in the worst case, > stale code will get a unique, if incorrect, version. Yes. So, Andrew Haley, what's the verdict on this one? There is a risk, yes. Not fixing the bug seems riskier, though. Thoughts? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8244548?focusedCommentId=14338519&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14338519 From sgehwolf at redhat.com Fri May 15 09:22:59 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 May 2020 11:22:59 +0200 Subject: [8u] RFR: 8244843: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: References: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> Message-ID: <3037e70f07846eda25fdf67e3b022e4ce30fb458.camel@redhat.com> Hi Andrew, Sigh, I only now realized that the bug number was missing the subject. Fixed now. On Fri, 2020-05-15 at 06:53 +0100, Andrew Hughes wrote: > On 13/05/2020 20:26, Severin Gehwolf wrote: > > Hi Andrew, > > > > Thanks for looking at this. > > > > No problem. Thanks for taking it on. > > > On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: > > > On 13/05/2020 15:59, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could somebody please review this fix for the failing > > > > JapanEraNameCompatTest.java test (part of tier1)? The reason why it's > > > > failing is that there are missing locale data for no and sr_Latn which > > > > are exercised by the test. The original backport of JDK-8219781 didn't > > > > include those as the changed sections in the JDK 11 patch didn't exist > > > > in 8u. Those extra sections got introduced with JDK-8008577 or JDK- > > > > 8145136. > > > > > > This also includes the JDK-8219781 changes for these locales. I think > > > it's worth mentioning all three bug IDs in the summary text so they > > > appear in a keyword search. > > > > OK, done. > > I was thinking more along the lines: > > Summary: Backports hr, lt, in, nl, no, sr_Latn & sv changes from > 8008577, 8145136 & 8219781 Sure. Changed that. > Do we want this to appear as a backport bug of those issues? > > > > Changes for these locales look ok to me. > > > > > > > This patch adds locale data for locales left out in the JDK-8219781 8u > > > > backport, except for JavaTimeSupplementary_in.java. That file doesn't > > > > exist at all in 8u, hence I've left that out. > > > > > > This doesn't make sense to me. The in locale is present in > > > sun/text/resources, but the only one without JavaTimeSupplementary_*: > > > > Sorry for not being clear. I meant that there is no > > JavaTimeSupplementary_in.java in 8u (prior this patch). > > Yeah, I got that. I just didn't understand why you didn't just add the file. > > snip... > > > Sure. Done now: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/02/webrev/ > > > ... > > How does the updated webrev above look to you? > > > > Only issue with the patch itself is java.time.japanese.short.Eras is > missing the new Reiwa era. I guess this is because 11u has JDK-8159943, > which refactors these files so they share blocks where possible, before > JDK-8219781. Thus, there is only one block to change in 11u, but it's a > shared block which is then used from both java.time.japanese.short.Eras > & java.time.japanese.long.Eras Should be fixed in 03 here. Thanks for the catch: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/03/webrev/ Thoughts? Thanks, Severin From neugens at redhat.com Fri May 15 12:01:29 2020 From: neugens at redhat.com (Mario Torre) Date: Fri, 15 May 2020 14:01:29 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Much better, thank you! The patch is good to go for my side, we still need to wait for the maintainer to change the status to jdk8u-fix-yes before you can push though. Cheers, Mario On Tue, May 12, 2020 at 1:02 PM Jaroslav Bachor?k wrote: > > Hi Mario, > > thanks for the review and I apologize for the escaped non-needed > commented out code. > Everything is cleaned up now and should correspond to 11u backport. > > Webrev 01: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.01/ > > Cheers, > > -JB- > > On Mon, May 11, 2020 at 2:24 PM Mario Torre wrote: > > > > Hi Jaroslav, > > > > I went back to that and I noticed some minor things while comparing it > > to the original patch. > > > > I see you have a number of commented out blocks, I think those should > > be removed, I can see how this may become a problem when backporting > > additional fixes. For example: > > > > +void Jfr::on_create_vm_1() { > > + //jio_fprintf(defaultStream::error_stream(), "openjdk version > > \"1.8.0-internal-debug\"\n"); > > + if (!JfrRecorder::on_create_vm_1()) { > > + vm_exit_during_initialization("Failure when starting JFR on_create_vm_1"); > > } > > > > Also, you changed the assert in linkResolver.cpp, at first I thought > > this was intentional, but there no such change in jdk11. Perhaps it > > may be dropped? > > > > Cheers, > > Mario > > > > > > On Wed, May 6, 2020 at 12:36 PM Mario Torre wrote: > > > > > > Hi Jaroslav, > > > > > > Sorry I dropped the ball on this one, I went through the changes and > > > they all seem good to me. > > > > > > We need a maintainer to set the jdk8u-fix-yes flag before you can > > > push, but the review is ok. > > > > > > Cheers, > > > Mario > > > > > > > > > On Fri, Apr 24, 2020 at 12:20 PM Jaroslav Bachor?k > > > wrote: > > > > > > > > Resending again in plain text to make the filters pass. > > > > > > > > ---------- Forwarded message --------- > > > > From: Jaroslav Bachor?k > > > > Date: Mon, Apr 20, 2020 at 4:02 PM > > > > Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() > > > > and Jfr:on_vm_start() start-up order for correct option parsing > > > > To: jdk8u-dev > > > > > > > > > > > > Please review the following backport > > > > > > > > JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 > > > > Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ > > > > > > > > The backport patch applied rather cleanly, not considering several > > > > offset adjustments. > > > > The only part that required an additional change was modifying the > > > > place where java lang classes initialization happens in thread.cpp - > > > > those classes need to be initialized before 'Jfr::on_create_vm_2()' is > > > > called. In order to achieve this I just moved around the whole > > > > codeblock related to java lang classes initialization. > > > > > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > > > > > Thanks! > > > > > > > > -JB- > > > > > > > > > > > > > -- > > > 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 jaroslav.bachorik at datadoghq.com Fri May 15 12:55:24 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 15 May 2020 14:55:24 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Great, thanks! On Fri, May 15, 2020 at 2:02 PM Mario Torre wrote: > > Much better, thank you! > > The patch is good to go for my side, we still need to wait for the > maintainer to change the status to jdk8u-fix-yes before you can push > though. > > Cheers, > Mario > > On Tue, May 12, 2020 at 1:02 PM Jaroslav Bachor?k > wrote: > > > > Hi Mario, > > > > thanks for the review and I apologize for the escaped non-needed > > commented out code. > > Everything is cleaned up now and should correspond to 11u backport. > > > > Webrev 01: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.01/ > > > > Cheers, > > > > -JB- > > > > On Mon, May 11, 2020 at 2:24 PM Mario Torre wrote: > > > > > > Hi Jaroslav, > > > > > > I went back to that and I noticed some minor things while comparing it > > > to the original patch. > > > > > > I see you have a number of commented out blocks, I think those should > > > be removed, I can see how this may become a problem when backporting > > > additional fixes. For example: > > > > > > +void Jfr::on_create_vm_1() { > > > + //jio_fprintf(defaultStream::error_stream(), "openjdk version > > > \"1.8.0-internal-debug\"\n"); > > > + if (!JfrRecorder::on_create_vm_1()) { > > > + vm_exit_during_initialization("Failure when starting JFR on_create_vm_1"); > > > } > > > > > > Also, you changed the assert in linkResolver.cpp, at first I thought > > > this was intentional, but there no such change in jdk11. Perhaps it > > > may be dropped? > > > > > > Cheers, > > > Mario > > > > > > > > > On Wed, May 6, 2020 at 12:36 PM Mario Torre wrote: > > > > > > > > Hi Jaroslav, > > > > > > > > Sorry I dropped the ball on this one, I went through the changes and > > > > they all seem good to me. > > > > > > > > We need a maintainer to set the jdk8u-fix-yes flag before you can > > > > push, but the review is ok. > > > > > > > > Cheers, > > > > Mario > > > > > > > > > > > > On Fri, Apr 24, 2020 at 12:20 PM Jaroslav Bachor?k > > > > wrote: > > > > > > > > > > Resending again in plain text to make the filters pass. > > > > > > > > > > ---------- Forwarded message --------- > > > > > From: Jaroslav Bachor?k > > > > > Date: Mon, Apr 20, 2020 at 4:02 PM > > > > > Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() > > > > > and Jfr:on_vm_start() start-up order for correct option parsing > > > > > To: jdk8u-dev > > > > > > > > > > > > > > > Please review the following backport > > > > > > > > > > JIRA. : https://bugs.openjdk.java.net/browse/JDK-8233197 > > > > > Webrev. : http://cr.openjdk.java.net/~jbachorik/8233197/ > > > > > > > > > > The backport patch applied rather cleanly, not considering several > > > > > offset adjustments. > > > > > The only part that required an additional change was modifying the > > > > > place where java lang classes initialization happens in thread.cpp - > > > > > those classes need to be initialized before 'Jfr::on_create_vm_2()' is > > > > > called. In order to achieve this I just moved around the whole > > > > > codeblock related to java lang classes initialization. > > > > > > > > > > All tests from jdk_jfr are passing after this patch has been applied. > > > > > > > > > > Thanks! > > > > > > > > > > -JB- > > > > > > > > > > > > > > > > > -- > > > > 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 aph at redhat.com Fri May 15 13:29:26 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2020 14:29:26 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Message-ID: On 5/15/20 9:45 AM, Severin Gehwolf wrote: > So, Andrew Haley, what's the verdict on this one? There is a risk, yes. > Not fixing the bug seems riskier, though. Thoughts? Thanks for the detailed explanation. I think we have to keep sun.misc.Version working correctly but sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff such as AOT compilation and class data sharing keep working I think we're OK. It's not great, but it's an almost-inevitable consequence of using a one-byte field for the minor version and bumping releases by 10. -- 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 Fri May 15 13:35:12 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2020 14:35:12 +0100 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: On 5/15/20 1:01 PM, Mario Torre wrote: > The patch is good to go for my side, we still need to wait for the > maintainer to change the status to jdk8u-fix-yes before you can push > though. I'm tempted to say yes. However, I get frightened whenever I see any change to HotSpot initialization code, particularly things that change the order in which classes are initialized. Can you make the early call to initialize_class(vmSymbols::java_lang_Class()) JFR-only? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Fri May 15 14:24:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 May 2020 16:24:18 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Message-ID: <6e023f46cec38601e6cd15356f971ab5d6cd99e2.camel@redhat.com> On Fri, 2020-05-15 at 14:29 +0100, Andrew Haley wrote: > On 5/15/20 9:45 AM, Severin Gehwolf wrote: > > So, Andrew Haley, what's the verdict on this one? There is a risk, yes. > > Not fixing the bug seems riskier, though. Thoughts? > > Thanks for the detailed explanation. > > I think we have to keep sun.misc.Version working correctly but > sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff > such as AOT compilation and class data sharing keep working I think > we're OK. It's not great, but it's an almost-inevitable consequence of > using a one-byte field for the minor version and bumping releases by > 10. Agreed. Thanks for the review. I've requested 8u approval for this bug. Cheers, Severin From jaroslav.bachorik at datadoghq.com Fri May 15 15:53:50 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Fri, 15 May 2020 17:53:50 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Hi Andrew, On Fri, May 15, 2020 at 3:35 PM Andrew Haley wrote: > > On 5/15/20 1:01 PM, Mario Torre wrote: > > The patch is good to go for my side, we still need to wait for the > > maintainer to change the status to jdk8u-fix-yes before you can push > > though. > > I'm tempted to say yes. However, I get frightened whenever I see any > change to HotSpot initialization code, particularly things that change > the order in which classes are initialized. Can you make the early > call to initialize_class(vmSymbols::java_lang_Class()) JFR-only? I can try that. Let me get back with the result. -JB- > > -- > 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 snazarkin at azul.com Fri May 15 16:30:12 2020 From: snazarkin at azul.com (Sergey Nazarkin) Date: Fri, 15 May 2020 16:30:12 +0000 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> Message-ID: <00ABA8D5-3374-477F-97B3-B39642E115AA@azul.com> Thanks, Andrew! 8037866 was pushed. Sergey Nazarkin > On May 15, 2020, at 09:10, Andrew Hughes wrote: > > > > On 05/04/2020 20:44, Sergey Nazarkin wrote: >> Thanks, Andrew. In simpler case 8037866(Replace the Fun class in tests with lambdas) only misses a part of MOAT.java that was introduced by 8014066(ArrayList#removeRange): >> >> $cat test/java/util/Collection/MOAT.java.rej >> --- MOAT.java >> +++ MOAT.java >> @@ -728,8 +722,8 @@ >> l.listIterator(0); >> l.listIterator(l.size()); >> THROWS(IndexOutOfBoundsException.class, >> - new Fun(){void f(){l.listIterator(-1);}}, >> - new Fun(){void f(){l.listIterator(l.size() + 1);}}); >> + () -> l.listIterator(-1), >> + () -> l.listIterator(l.size() + 1)); >> >> if (l instanceof AbstractList) { >> try { >> >> Final patchset would be >> >> 1) http://cr.openjdk.java.net/~snazarki/webrev/8037866/ >> 2) http://cr.openjdk.java.net/~snazarki/webrev/8067796/ >> >> >> >> Sergey Nazarkin >> > > Sorry for the delay on this. > > 8037866 looks fine to me and we shouldn't introduce 8014066, which may > change java.util.ArrayList behaviour. > > I'll look at 8067796 again once 8037866 is pushed. > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexey at azul.com Sun May 17 11:44:34 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Sun, 17 May 2020 11:44:34 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> Message-ID: <349F01F2-4E33-4164-A708-E7BD0253FCF2@azul.com> Hello All, Could you please review additional patch for the 8u TLSv1.3 implementation. This patch turns off TLSv1.3 protocol on the default client configuration. TLSv1.3 still can be enabled on the client side: - via the existing SSLSocket/SSLEngine/SSLParameters/SSLContext API - via the jdk.tls.client.protocols property - via the https.protocols property Webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step10/ Regards Alexey From gnu.andrew at redhat.com Sun May 17 18:22:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sun, 17 May 2020 19:22:19 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Message-ID: <38d5c8bb-5be7-af41-786a-5621a118f8fd@redhat.com> On 15/05/2020 14:29, Andrew Haley wrote: > On 5/15/20 9:45 AM, Severin Gehwolf wrote: >> So, Andrew Haley, what's the verdict on this one? There is a risk, yes. >> Not fixing the bug seems riskier, though. Thoughts? > > Thanks for the detailed explanation. > > I think we have to keep sun.misc.Version working correctly but > sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff > such as AOT compilation and class data sharing keep working I think > we're OK. It's not great, but it's an almost-inevitable consequence of > using a one-byte field for the minor version and bumping releases by > 10. > I see little to no risk in changing this. Anyone using 7u261 or later, or 8u262 or later, is going to get an overflowed minor JVM version and an overflowed upgrade JDK version even if we do nothing at all. What we can do is attempt to fix things in a way that doesn't change the size of the structure, just the interpretation of its contents, as proposed here. Calling code that adapts to the modified version will then be able to get the correct values. Code that doesn't will be just as broken as if we'd made no change. Arguably, even that case will be a little better, as with a non-zero micro value, the incorrect version will at least be distinct from older versions. This is for 7u & 8u, which don't have AOT compilation, so that shouldn't be an issue. I'll be approving this for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sgehwolf at redhat.com Mon May 18 09:08:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 18 May 2020 11:08:18 +0200 Subject: [8u] RFR: 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format Message-ID: <7afbfa4c0a30f76a424f0e40c6c80d015fb7e91b.camel@redhat.com> Hi, Please review this 8u backport of JDK-8150986. It's a clean backport except for the copyright change. In the 8u252 cycle JDK-8144732 got backported which now makes the test fail. Bug: https://bugs.openjdk.java.net/browse/JDK-8150986 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8150986/01/webrev/ Testing: Test fails prior patch, passes after. Thoughts? Thanks, Severin From andrey at azul.com Mon May 18 10:30:08 2020 From: andrey at azul.com (Andrey Petushkov) Date: Mon, 18 May 2020 13:30:08 +0300 Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC Message-ID: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com> Dear All, please consider the following patch to add missing package information into JFR backport https://cr.openjdk.java.net/~apetushkov/8245167/ Originally the package info was omitted due to dependency on jigsaw functionality and hence it was thought it's not much relevant for jdk8. However it turns out it's widely used (e.g. by JMC). So it makes sense to implement it in jdk8-specific way The author of the code is Aleksei Semenov Verified by JMC and jfr jtreg tests, including the fixed jdk/jfr/event/runtime/TestClassLoadEvent Thanks, Andrey From jvanek at redhat.com Mon May 18 14:03:55 2020 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 18 May 2020 16:03:55 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place Message-ID: hi! This is third, hopefully last, reincarnation of this backport. Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time. It is jdk11-like version of the patch. However after above was agreed, an issue concerning backport of https://bugs.openjdk.java.net/browse/JDK-8168772 ( http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised. If there is no intention to backport 8168772 ever, then my current patch is good to go. If not, then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was commited, but 8168772 have to follow after it. I do not feel exactly voulenteered ino backporting of 8168772 Thanx! J. -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From mbalao at redhat.com Mon May 18 15:34:12 2020 From: mbalao at redhat.com (Martin Balao) Date: Mon, 18 May 2020 12:34:12 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> Message-ID: <655f2b55-f44f-4d6a-84e5-f7fb083a2b30@redhat.com> Hi Alexey, On 5/14/20 6:09 PM, Alexey Bakhtin wrote: > I?ve decided to keep some original files in the sun.securyti.ssl package in case of no functional modifications. > I think it indicates that these files are version independent and better shows what is changed in these files from one version to another. Yes, I see your point. Except for SunJSSE -where there are stronger reasons-, looks like a trade-off between keeping the history and being consistent with the strategy. We can keep these files then; I'll document them as an exception. > SunJSSE class was hardly changed by JDK-7092821 in JDK11.0.7 > JDK-7092821 is not part of JDK8, so I had two options: > 1) use 11.0.7 version and revert JDK-7092821(huge changes) > 2) use 8u262 version and add TLSv1.3 protocol definition (small changes) > I decided to keep 8u262 version. In my opinion it better shows real modification in this file Hardly or severely changed? I see quite a few changes. We will need a backport of 7092821 to JDK-8 for parity with Oracle's JDK, but I understand the inconvenience of doing it as part of the TLS 1.3 backport because the changeset essentially affects files out of sun.security.ssl. I agree with the decision you made here. > JsseJCE class in 11.0.7 was modified to remove TLS_KRB5 feature. The rest changes are code formatting. > I decided to keep original version of this file and show required modification in the step 7 (TLSv1.3: RFC-2712 support). This file also contains small modification on the step, but final version of this file is not identical to 11.0.7. It is 8u262 version with required modifications Ok. > > HostNameChecker class is not located in the sun/security/ssl file. As I remember, we decided to not replace files outside of sun/security/ssl but show and describe changes. The changes in this file are related to JDK-8038893 > and shown on the separate step 5 Oh, my fault there! Sorry. >> >> * Why was sun/security/ssl/KeyManagerFactoryImpl.java not modified? I >> see a change in 8196584. > > The only changes in this file - is code formatting. I decided to keep original > JDK8u version because of no functional modification in the JDK11.0.7 version > Hmm... I don't agree with this one. I suggest to align the file to 11.0.7 (doing file-replacement, to be consistent) and avoid a potential conflict in the future due to formatting when backporting a patch to JDK-8. >> >> Some files are within sun/security/ssl but are not deleted by Step 0 and >> are not deleted or modified by 8196584 either (because they don't exist >> by the time 8196584 was applied, see 8038089): >> >> * classes/sun/security/ssl/KerberosClientKeyExchange.java >> * classes/sun/security/ssl/Krb5Helper.java >> * classes/sun/security/ssl/Krb5Proxy.java >> >> In the case of KerberosClientKeyExchange.java, I've seen it's modified >> by Step 7. A few questions: >> >> * Did you file-replaced KerberosClientKeyExchange.java >> * If this file is not in 11u, why do we need it in 8u? >> >> * Are Krb5Helper.java and Krb5Proxy.java used? >> * I assume they are for the same reason than my 1st question, but want >> to check just in case. > > These files are related to RFC-2712 support. This feature is declared in JDK8u but deprecated in 11u > Some customers could still use this feature, so we can not just remove it in JDk8u. As soon as JDK11 does not have this feature I've kept old files related to RFC-2712 and added missing functionality in the step 7 Oh, absolutely. Thanks for clarifying that. Thanks, Martin.- From gnu.andrew at redhat.com Tue May 19 01:23:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 May 2020 02:23:03 +0100 Subject: [8u] RFR(XS): 8243059: Build fails when --with-vendor-name contains a comma In-Reply-To: <4d539698e2fcd4ce606e62723cdd9d815b0af473.camel@redhat.com> References: <4d539698e2fcd4ce606e62723cdd9d815b0af473.camel@redhat.com> Message-ID: <8e5bf87a-81ae-c4b8-feef-b0489647cbd1@redhat.com> On 07/05/2020 13:22, Severin Gehwolf wrote: > Hi, > > Could I please get a review of this OpenJDK 8u backport for JDK- > 8243059? The build system is wildly different to JDK 11 and later, thus > is the patch. In turns out on JDK 8, SetupLauncher isn't using eval() > so the evaluation of the comma too early isn't an issue there. However, > on JDK 8u, the same issue is present when COMPANY_NAME is being > evaluated too early in SetupArchive. COMPANY_NAME may contain a comma > an that breaks the embedded rule for creating the jars. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243059 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8243059/jdk8/01/webrev/ > > Testing: building with --with-vendor-name="foo, bar". Fails before, > passes after patch. > > Thoughts? > > Thanks, > Severin > Looks good to me. Thanks. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue May 19 01:24:55 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 May 2020 02:24:55 +0100 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: References: Message-ID: <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com> On 18/05/2020 15:03, Jiri Vanek wrote: > hi! > > This is third, hopefully last, reincarnation of this backport. > Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time. > It is jdk11-like version of the patch. > > However after above was agreed, an issue concerning backport of > https://bugs.openjdk.java.net/browse/JDK-8168772 ( > http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised. > > If there is no intention to backport 8168772 ever, then my current patch is good to go. If not, > then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was > commited, but 8168772 have to follow after it. > I do not feel exactly voulenteered ino backporting of 8168772 > > Thanx! > J. > Thanks for looking into this again. I'll have a look at the feasibility of JDK-8168772 and get back to you. I'm tending towards just applying this as previously reviewed, but it may be that JDK-8168772, though long, applies nearly cleanly and it's preferable to have 8u & 11u working the same. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue May 19 01:26:37 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 May 2020 02:26:37 +0100 Subject: [8u] RFR: 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format In-Reply-To: <7afbfa4c0a30f76a424f0e40c6c80d015fb7e91b.camel@redhat.com> References: <7afbfa4c0a30f76a424f0e40c6c80d015fb7e91b.camel@redhat.com> Message-ID: <20a1d199-eb7d-1451-f222-3513b30d0639@redhat.com> On 18/05/2020 10:08, Severin Gehwolf wrote: > Hi, > > Please review this 8u backport of JDK-8150986. It's a clean backport > except for the copyright change. In the 8u252 cycle JDK-8144732 got > backported which now makes the test fail. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8150986 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8150986/01/webrev/ > > Testing: Test fails prior patch, passes after. > > Thoughts? > > Thanks, > Severin > Looks fine. Thanks. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jvanek at redhat.com Tue May 19 07:44:19 2020 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 19 May 2020 09:44:19 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com> References: <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com> Message-ID: On 5/19/20 3:24 AM, Andrew Hughes wrote: > > > On 18/05/2020 15:03, Jiri Vanek wrote: >> hi! >> >> This is third, hopefully last, reincarnation of this backport. >> Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time. >> It is jdk11-like version of the patch. >> >> However after above was agreed, an issue concerning backport of >> https://bugs.openjdk.java.net/browse/JDK-8168772 ( >> http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised. >> >> If there is no intention to backport 8168772 ever, then my current patch is good to go. If not, >> then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was >> commited, but 8168772 have to follow after it. >> I do not feel exactly voulenteered ino backporting of 8168772 >> >> Thanx! >> J. >> > > Thanks for looking into this again. > > I'll have a look at the feasibility of JDK-8168772 and get back to you. > > I'm tending towards just applying this as previously reviewed, but it > may be that JDK-8168772, though long, applies nearly cleanly and it's > preferable to have 8u & 11u working the same. Ok. Will try that too. Thanx! > > Thanks, > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From jvanek at redhat.com Tue May 19 12:32:21 2020 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 19 May 2020 14:32:21 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: References: <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com> Message-ID: On 5/19/20 9:44 AM, Jiri Vanek wrote: > On 5/19/20 3:24 AM, Andrew Hughes wrote: >> >> >> On 18/05/2020 15:03, Jiri Vanek wrote: >>> hi! >>> >>> This is third, hopefully last, reincarnation of this backport. >>> Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time. >>> It is jdk11-like version of the patch. >>> >>> However after above was agreed, an issue concerning backport of >>> https://bugs.openjdk.java.net/browse/JDK-8168772 ( >>> http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised. >>> >>> If there is no intention to backport 8168772 ever, then my current patch is good to go. If not, >>> then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was >>> commited, but 8168772 have to follow after it. >>> I do not feel exactly voulenteered ino backporting of 8168772 >>> >>> Thanx! >>> J. >>> >> >> Thanks for looking into this again. >> >> I'll have a look at the feasibility of JDK-8168772 and get back to you. >> >> I'm tending towards just applying this as previously reviewed, but it >> may be that JDK-8168772, though long, applies nearly cleanly and it's >> preferable to have 8u & 11u working the same. > > Ok. Will try that too. Thanx! Afer applying 8154313 as jdk8 as possible, applying 8168772: atching file common/autoconf/generated-configure.sh Hunk #1 FAILED at 5093. 1 out of 1 hunk FAILED -- saving rejects to file common/autoconf/generated-configure.sh.rej patching file common/autoconf/spec.gmk.in Hunk #1 FAILED at 265. Hunk #2 FAILED at 788. 2 out of 2 hunks FAILED -- saving rejects to file common/autoconf/spec.gmk.in.rej patching file make/Javadoc.gmk Hunk #1 FAILED at 22. Hunk #2 FAILED at 171. Hunk #3 FAILED at 355. Hunk #4 FAILED at 1742. 4 out of 4 hunks FAILED -- saving rejects to file make/Javadoc.gmk.rej patching file make/Main.gmk Hunk #1 FAILED at 341. Hunk #2 FAILED at 683. Hunk #3 FAILED at 812. Hunk #4 FAILED at 860. Hunk #5 FAILED at 872. Hunk #6 FAILED at 911. 6 out of 6 hunks FAILED -- saving rejects to file make/Main.gmk.rej can't find file to patch at input line 2731 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -r f37e46c2e8f6 -r db49e4e492e0 make/MainSupport.gmk |--- a/make/MainSupport.gmk Wed Oct 26 09:44:20 2016 +0200 |+++ b/make/MainSupport.gmk Wed Oct 26 16:00:26 2016 +0200 -------------------------- File to patch: Skip this patch? [y] y Skipping patch. 2 out of 2 hunks ignored That backport moreover means to rewrite it. >> >> Thanks, >> > > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From mbalao at redhat.com Tue May 19 19:11:34 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 19 May 2020 16:11:34 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> Message-ID: <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> Hi, I've finished running the series of tests that I understand is most relevant for TLS 1.3. This is a summary of the what I found: * JDK-8 Tier 1 * No regressions found * JDK-8 Tier 2 * No regressions found * sun/security/pkcs11 * No regressions found * sun/security/ssl * Note: comparison against 11.0.7-ga because it's the test suite that represents best the new TLS engine * No regressions found * However, there are a number of extra tests in 8 relocated from sun/net/www, javax/net/ssl and com/sun/net/ssl to sun/security/ssl * Why is that? One more question: have you ran TCK? Thanks, Martin.- From mbalao at redhat.com Tue May 19 22:09:26 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 19 May 2020 19:09:26 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> Message-ID: Hi, I verified the following changes on Step 1: * SunJSSE.java * TLSv1.3 protocol definition added. * The hook that adds 'Object' as a template parameter is not necessary because in JDK-8 it's already there * JDK-8 does not have 8078468 that removes it * No additional changes in 8196584 * Ok * java.security-os * Verified that the file was updated for all supported OSs * Verified that the content is identical to java.security in 8196584 * Ok * All files in the changeset are new files, except for the 6 java-security-os modifications * Ok * All new files are within sun/security/ssl directory, as planned * Ok * Files once Step 1 is applied that are not present in JDK 11.0.7 * krb5 directory (with KerberosClientKeyExchangeImpl.java, KerberosPreMasterSecret.java and Krb5ProxyImpl.java inside) * KerberosClientKeyExchange.java * Krb5Helper.java * Krb5Proxy.java * I'm ok with keeping the Kerberos code, as said in [0]. * All the files in JDK 11.0.7 are identical to those added by Step 1, except for: * DTLSInputRecord.java * Not added by Step 1 * If we are going to have a patch that removes DTLS (Step 2), I suggest to add this file now and remove it later. Looks to me that not adding this file now is mixing some parts of Step 2, and making it harder to understand for the one who looks at Step 1 only. * DTLSOutputRecord.java * Not added by Step 1 - see above * DTLSRecord.java * Not added by Step 1 - see above * EphemeralKeyManager.java * This should be fixed in Step 0, in my opinion * HelloVerifyRequest.java * Why? * SunJSSE.java * Ok, we will accept this for the reasons stated in [1]. * JsseJce.java * Even though the Kerberos part won't be removed, I suggest to align all the trivial format changes; so when backporting future changes we avoid unnecessary conflicts there. * KeyManagerFactoryImpl.java * This should be fixed in Step 0, in my opinion Overall, I suggest as a general criteria to avoid including steps 'from the future' even if that means adding a file to be removed later. Even though I can understand the exceptions we did for Kerberos and SunJSSE.java, they are still around my head... I'm not 100% convinced. On a final note, I suggest to open different JIRA bugs for each Step. We can handle each Step as a Subtask of a Master ticket. We will have 10 separate reviews, against each proposal. Thanks, Martin.- -- [0] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011735.html [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011717.html From alexey at azul.com Wed May 20 10:49:04 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 20 May 2020 10:49:04 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> Message-ID: <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> Hello Martin, About extra tests in JDK8: These tests and packages exist in JDK8 since initial implementation. The sun/security/ssl test directory in JDK11 has a little bit different structure: the same tests located in different subdirectories in JDK8 and JD11. I did not replace TLS 11.0.7 tests but merge them keeping original directory structure. May be I should apply the same review strategy for the TLS tests too : remove 8u tests, replace with 11u tests, change 8u only tests. Alexey > On 19 May 2020, at 22:11, Martin Balao wrote: > > Hi, > > I've finished running the series of tests that I understand is most > relevant for TLS 1.3. > > This is a summary of the what I found: > > * JDK-8 Tier 1 > * No regressions found > > * JDK-8 Tier 2 > * No regressions found > > * sun/security/pkcs11 > * No regressions found > > * sun/security/ssl > * Note: comparison against 11.0.7-ga because it's the test suite that > represents best the new TLS engine > * No regressions found > * However, there are a number of extra tests in 8 relocated from > sun/net/www, javax/net/ssl and com/sun/net/ssl to sun/security/ssl > * Why is that? > > One more question: have you ran TCK? > > Thanks, > Martin.- From mbalao at redhat.com Wed May 20 14:27:31 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 20 May 2020 11:27:31 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> Message-ID: <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> On 5/20/20 7:49 AM, Alexey Bakhtin wrote: > Hello Martin, > > About extra tests in JDK8: > These tests and packages exist in JDK8 since initial implementation. The sun/security/ssl test directory in JDK11 has a little bit different structure: the same tests located in different subdirectories in JDK8 and JD11. I did not replace TLS 11.0.7 tests but merge them keeping original directory structure. > May be I should apply the same review strategy for the TLS tests too : remove 8u tests, replace with 11u tests, change 8u only tests. Oh, I see. There are several tests in JDK-8 which in JDK-11 are located in a different directory (out of sun/security/ssl). In example, /sun/security/ssl/sun/net/www/protocol/https/NewImpl directory in JDK-8 is located in /jdk/sun/net/www/protocol/https/NewImpl in JDK-11. That's the reason why I noticed so many more tests when comparing jtreg executions between 8 and 11. I've seen you did not replaced those files in JDK-8 -at least the 5 files I compared have differences with their JDK-11 version-. My question is: how are we sure that we don't need updates from JDK-11? In particular, I wonder if we are preventing TLS 1.3 code to be exercised. And I'm also concerned about the failures there (list at the end of this mail [1]). Thanks, Martin.- -- [1] - Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/EngineCloseOnAlert.java Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/IllegalHandshakeMessage.java Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/IllegalRecordVersion.java Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java FAILED: sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java Error: sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java Error: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java From alexey at azul.com Wed May 20 16:24:28 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 20 May 2020 16:24:28 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> Message-ID: <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> Hi Martin, Thank you. I?m agree with you. I have to synchronise location of the TLS regression tests. Otherwise it is easy to miss test updates and as result get some regression in the implementation. As for errors you mentioned: All tests ( except of CipherSuitesInOrder.java ) are marked as ignored in the JDK11.0.7 and new implementation, so it is expected failures. We have to wait test or implementation fixes in JDK11 and then backport them to JDK8. CipherSuitesInOrder.java was ignored in the initial TLS1.3 implementation but fixed by JDK-8234728. I did not update it in the patch. I will update it as part of TLS tests location refactoring. Regards Alexey > On 20 May 2020, at 17:27, Martin Balao wrote: > > > I've seen you did not replaced those files in JDK-8 -at least the 5 > files I compared have differences with their JDK-11 version-. My > question is: how are we sure that we don't need updates from JDK-11? In > particular, I wonder if we are preventing TLS 1.3 code to be exercised. > And I'm also concerned about the failures there (list at the end of this > mail [1]). > > Thanks, > Martin.- > > -- > [1] - > > Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/Basics.java > Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java > Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java > Error: > sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/EngineCloseOnAlert.java > Error: > sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/IllegalHandshakeMessage.java > Error: > sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/IllegalRecordVersion.java > Error: sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/TestAllSuites.java > FAILED: sun/security/ssl/javax/net/ssl/NewAPIs/CheckMyTrustedKeystore.java > Error: sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java > Error: > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java > From mbalao at redhat.com Wed May 20 16:35:29 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 20 May 2020 13:35:29 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> Message-ID: <43bab359-69d5-c1d0-9a9d-f089f8a80bcd@redhat.com> Hi Alexey, Thanks! Look forward into the new tests patch then. Any thoughts on the Step 0 and Step 1 comments? Regards, Martin.- On 5/20/20 1:24 PM, Alexey Bakhtin wrote: > Hi Martin, > > Thank you. I?m agree with you. I have to synchronise location of the TLS regression tests. Otherwise it is easy to miss test updates and as result get some regression in the implementation. > > As for errors you mentioned: > All tests ( except of CipherSuitesInOrder.java ) are marked as ignored in the JDK11.0.7 and new implementation, so it is expected failures. We have to wait test or implementation fixes in JDK11 and then backport them to JDK8. > > CipherSuitesInOrder.java was ignored in the initial TLS1.3 implementation but fixed by JDK-8234728. I did not update it in the patch. > I will update it as part of TLS tests location refactoring. > > Regards > Alexey > From gnu.andrew at redhat.com Wed May 20 20:41:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 May 2020 21:41:39 +0100 Subject: [8u] RFR: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() Message-ID: <7e130cfe-7402-5835-a511-4810fb0ad126@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8028591 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8028591/webrev.01/ Simple range check additions that have been in OpenJDK since 9u. On the Oracle parity list for 8u26{1,2}. Modifications for the backport are the result of security fixes that have been applied to 8u since the fix was made earlier in the 9u lifecycle: * The check on validBits in src/share/classes/sun/security/util/DerInputStream.java was already added by JDK-8168714: "Tighten ECDSA validation" * The len was already assigned to a variable in src/share/classes/sun/security/util/ObjectIdentifier.java for JDK-8168705: "Better ObjectIdentifier validation" which checked the upper bound. Also, the copyright header change is redundant as JDK-8175251: "Failed to load RSA private key from pkcs12" already bumped it to 2017. Ok for 8u262? Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jaroslav.bachorik at datadoghq.com Wed May 20 21:30:19 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Wed, 20 May 2020 23:30:19 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: On Fri, May 15, 2020 at 5:53 PM Jaroslav Bachor?k wrote: > > Hi Andrew, > > On Fri, May 15, 2020 at 3:35 PM Andrew Haley wrote: > > > > On 5/15/20 1:01 PM, Mario Torre wrote: > > > The patch is good to go for my side, we still need to wait for the > > > maintainer to change the status to jdk8u-fix-yes before you can push > > > though. > > > > I'm tempted to say yes. However, I get frightened whenever I see any > > change to HotSpot initialization code, particularly things that change > > the order in which classes are initialized. Can you make the early > > call to initialize_class(vmSymbols::java_lang_Class()) JFR-only? > > I can try that. Let me get back with the result. I put the early java_lang_Class initialization in `#if INCLUDE_JFR` block. The original java_lang_Class initialization location was enclosed in an inverted `#if INCLUDE_JFR` block to ensure the original behaviour if JFR is not enabled in build config. Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.02/ Thanks, -JB- > > -JB- > > > > > -- > > 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 jvanek at redhat.com Thu May 21 06:43:42 2020 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 21 May 2020 08:43:42 +0200 Subject: [8u] RFR Backport JDK-8154313, Generated javadoc scattered all over the place In-Reply-To: References: <1f558726-4374-d2fc-e86f-62e35cb73630@redhat.com> Message-ID: ping please do not let it rot! On 5/19/20 2:32 PM, Jiri Vanek wrote: > On 5/19/20 9:44 AM, Jiri Vanek wrote: >> On 5/19/20 3:24 AM, Andrew Hughes wrote: >>> >>> >>> On 18/05/2020 15:03, Jiri Vanek wrote: >>>> hi! >>>> >>>> This is third, hopefully last, reincarnation of this backport. >>>> Refreshed - http://cr.openjdk.java.net/~jvanek/8154313/ - as it was approved last time. >>>> It is jdk11-like version of the patch. >>>> >>>> However after above was agreed, an issue concerning backport of >>>> https://bugs.openjdk.java.net/browse/JDK-8168772 ( >>>> http://hg.openjdk.java.net/jdk9/jdk9/rev/db49e4e492e0 ), which is quite huge was raised. >>>> >>>> If there is no intention to backport 8168772 ever, then my current patch is good to go. If not, >>>> then the 8154313 (http://hg.openjdk.java.net/jdk9/jdk9/rev/ec69c5bf68a6) should be applied as it was >>>> commited, but 8168772 have to follow after it. >>>> I do not feel exactly voulenteered ino backporting of 8168772 >>>> >>>> Thanx! >>>> J. >>>> >>> >>> Thanks for looking into this again. >>> >>> I'll have a look at the feasibility of JDK-8168772 and get back to you. >>> >>> I'm tending towards just applying this as previously reviewed, but it >>> may be that JDK-8168772, though long, applies nearly cleanly and it's >>> preferable to have 8u & 11u working the same. >> >> Ok. Will try that too. Thanx! > Afer applying 8154313 as jdk8 as possible, applying 8168772: > > atching file common/autoconf/generated-configure.sh > Hunk #1 FAILED at 5093. > 1 out of 1 hunk FAILED -- saving rejects to file common/autoconf/generated-configure.sh.rej > patching file common/autoconf/spec.gmk.in > Hunk #1 FAILED at 265. > Hunk #2 FAILED at 788. > 2 out of 2 hunks FAILED -- saving rejects to file common/autoconf/spec.gmk.in.rej > patching file make/Javadoc.gmk > Hunk #1 FAILED at 22. > Hunk #2 FAILED at 171. > Hunk #3 FAILED at 355. > Hunk #4 FAILED at 1742. > 4 out of 4 hunks FAILED -- saving rejects to file make/Javadoc.gmk.rej > patching file make/Main.gmk > Hunk #1 FAILED at 341. > Hunk #2 FAILED at 683. > Hunk #3 FAILED at 812. > Hunk #4 FAILED at 860. > Hunk #5 FAILED at 872. > Hunk #6 FAILED at 911. > 6 out of 6 hunks FAILED -- saving rejects to file make/Main.gmk.rej > can't find file to patch at input line 2731 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -r f37e46c2e8f6 -r db49e4e492e0 make/MainSupport.gmk > |--- a/make/MainSupport.gmk Wed Oct 26 09:44:20 2016 +0200 > |+++ b/make/MainSupport.gmk Wed Oct 26 16:00:26 2016 +0200 > -------------------------- > File to patch: > Skip this patch? [y] y > Skipping patch. > 2 out of 2 hunks ignored > > > That backport moreover means to rewrite it. >>> >>> Thanks, >>> >> >> > > -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek at redhat.com M: +420775390109 From zgu at redhat.com Thu May 21 12:31:36 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 21 May 2020 08:31:36 -0400 Subject: [8u] RFR (XS) 8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout In-Reply-To: References: Message-ID: <2f9c5aab-e053-84e3-bdf4-168b1e2cc521@redhat.com> Backport looks good. -Zhengyu On 3/16/20 6:15 AM, Aleksey Shipilev wrote: > Original fix: > https://bugs.openjdk.java.net/browse/JDK-8153430 > https://hg.openjdk.java.net/jdk/jdk/rev/92cf8efd381d > > MletParserLocaleTest.java was added by JDK-7065236 only in 9, so that hunk does not apply. > ParserInfiniteLoopTest.java hunk applies cleanly. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8153430/webrev.8u.01/ > > Testing: affected test > From alexey at azul.com Thu May 21 13:08:32 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 13:08:32 +0000 Subject: [8u] TLSv1.3 RFR: 8245467: Remove 8u TLSv1.2 implementation files Message-ID: <3C14EABD-EDDC-4915-A699-DD1D1D333E26@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the first part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245467 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245467/webrev.v0/ This patch remove 8u TLSv1.2 implementation files and fixes issues discussed in [2] and [3] [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011735.html [3] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011717.html Regards Alexey From alexey at azul.com Thu May 21 13:08:35 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 13:08:35 +0000 Subject: [8u] TLSv1.3 RFR: 8245468: Add TLSv1.3 implementation classes from 11.0.7 Message-ID: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the second part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245468 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245468/webrev.v0/ This patch adds TLSv1.3 implementation classes from 11.0.7 and fixes issues discussed in [2] The patch should be applied after the patch for JDK-8245467 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011742.html Regards Alexey From alexey at azul.com Thu May 21 13:23:34 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 13:23:34 +0000 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation Message-ID: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the third part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245469 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245469/webrev.v0/ This patch removes DTLS protocol support from TLS implementation. There are no plans to support DTLS protocol in JDK8u The patch should be applied after the patch for JDK-8245468 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html Regards Alexey From alexey at azul.com Thu May 21 13:33:39 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 13:33:39 +0000 Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues Message-ID: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the forth part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245470 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245470/webrev.v0/ This patch fixes common build issues caused by changes related to using a class from another package or different language constructions. Also, this patch includes changes in the HandshakeHash class caused by the absence of MessageDigestSpi2 interface in JDK8 The patch should be applied after the patch for JDK-8245469 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html Regards Alexey From alexey at azul.com Thu May 21 13:42:49 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 13:42:49 +0000 Subject: [8u] TLSv1.3 RFR: 8245471: Revert JDK-8148188 Message-ID: <747A85CF-F4F9-48C2-8218-6B5D94D09BD0@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the fifth part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245471 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245471/webrev.v0/ This patch excludes JDK-8148188 (JFR security events) as it is not supported in openJDK8u yet The patch should be applied after the patch for JDK-8245470 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html Regards Alexey From alexey at azul.com Thu May 21 13:54:08 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 13:54:08 +0000 Subject: [8u] TLSv1.3 RFR: 8245472: Backport JDK-8038893 for TLSv1.3 Message-ID: <99606DDF-ABD2-4F94-9B6B-3C6CBA3E77E0@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the sixth part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245472 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v0/ This patch backports JDK-8038893 (Recertify certificate matching) for TLSv1.3 The patch should be applied after the patch for JDK-8245471 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html Regards Alexey From alexey at azul.com Thu May 21 14:02:43 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 14:02:43 +0000 Subject: [8u] TLSv1.3 RFR: 8245473: OCSP stapling support Message-ID: Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the seventh part of backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245473 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245473/webrev.v0/ This patch adds OCSP stapling support (JEP 249) OCSP stapling is disabled by default on the client and server side. The patch should be applied after the patch for JDK-8245472 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html Regards Alexey From alexey at azul.com Thu May 21 14:12:28 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 14:12:28 +0000 Subject: [8u] TLSv1.3 RFR: 8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 Message-ID: <4F18F95F-3BC4-4BEA-8A7C-C75F4AD07930@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the eighth part of the backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245474 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245474/webrev.v0/ Support for TLS_KRB5 cipher suites were excluded from the TLSv1.3 implementation in JDK11 TLS_KRB5 cipher suites support is backported back from the original JDK8u implementation The patch should be applied after the patch for JDK-8245473 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html [2] - https://tools.ietf.org/html/rfc2712 Regards Alexey From alexey at azul.com Thu May 21 14:19:24 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 14:19:24 +0000 Subject: [8u] TLSv1.3 RFR: 8245476: Disable TLSv1.3 protocol in the ClientHello message by default Message-ID: Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u This is the ninth part of the backport discussed in the thread [1] JBS task: https://bugs.openjdk.java.net/browse/JDK-8245476 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245476/webrev.v0/ This patch turns off TLSv1.3 protocol on the default client configuration. TLSv1.3 still can be enabled on the client-side: - via the existing SSLSocket/SSLEngine/SSLParameters/SSLContext API - via the jdk.tls.client.protocols property - via the https.protocols property The patch should be applied after the patch for JDK-8245474 [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html Regards Alexey From alexey at azul.com Thu May 21 14:21:18 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 14:21:18 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <43bab359-69d5-c1d0-9a9d-f089f8a80bcd@redhat.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> <43bab359-69d5-c1d0-9a9d-f089f8a80bcd@redhat.com> Message-ID: <745EEBB4-2292-4ABB-8155-40E1119773F7@azul.com> Hi Martin, I?m agree with your comments about Step 0 and Step 1 As you suggested I?ve started separate threads to discuss patches for particular steps. Review of the Step 0 is moved to thread [1] Review of the Step 1 is moved to thread [2] Review of the Step 3 is moved to thread [3] Review of the Step 4 is moved to thread [4] Review of the Step 5 is moved to thread [5] Review of the Step 6 is moved to thread [6] Review of the Step 7 is moved to thread [7] Review of the Step 8 is moved to thread [8] Review of the Step 9 is moved to thread [9] This thread still can be used to discuss common questions. [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011751.html [2] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011752.html [3] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011753.html [4] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011754.html [5] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011755.html [6] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011756.html [7] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011757.html [8] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011758.html [9] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011759.html Regards Alexey > On 20 May 2020, at 19:35, Martin Balao wrote: > > Hi Alexey, > > Thanks! Look forward into the new tests patch then. > > Any thoughts on the Step 0 and Step 1 comments? > > Regards, > Martin.- > From mbalao at redhat.com Thu May 21 14:42:32 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 21 May 2020 11:42:32 -0300 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: <745EEBB4-2292-4ABB-8155-40E1119773F7@azul.com> References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> <43bab359-69d5-c1d0-9a9d-f089f8a80bcd@redhat.com> <745EEBB4-2292-4ABB-8155-40E1119773F7@azul.com> Message-ID: Hi Alexey, This is very much appreciated. On 5/21/20 11:21 AM, Alexey Bakhtin wrote: > Review of the Step 3 is moved to thread [3] Just for reference, there is an off-by-one from [3] (which is Step 2). One question: will the test changes be handled as Step 9? Thanks, Martin.- From alexey at azul.com Thu May 21 14:53:06 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 14:53:06 +0000 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> <43bab359-69d5-c1d0-9a9d-f089f8a80bcd@redhat.com> <745EEBB4-2292-4ABB-8155-40E1119773F7@azul.com> Message-ID: Hi Martin, Yes, the tests will be posted as a separate step, may be several steps for better review process. I?m trying to adjust test location between JDK8 and JDK11. For now you can use tests posted in the previous patches : http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test/ http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test.sslecc/ http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step10/ Alexey > On 21 May 2020, at 17:42, Martin Balao wrote: > > Hi Alexey, > > This is very much appreciated. > > On 5/21/20 11:21 AM, Alexey Bakhtin wrote: >> Review of the Step 3 is moved to thread [3] > > Just for reference, there is an off-by-one from [3] (which is Step 2). > > One question: will the test changes be handled as Step 9? > > Thanks, > Martin.- > From mbalao at redhat.com Thu May 21 16:51:49 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 21 May 2020 13:51:49 -0300 Subject: [8u] TLSv1.3 RFR: 8245467: Remove 8u TLSv1.2 implementation files In-Reply-To: <3C14EABD-EDDC-4915-A699-DD1D1D333E26@azul.com> References: <3C14EABD-EDDC-4915-A699-DD1D1D333E26@azul.com> Message-ID: <091b9276-f27d-375d-7cd5-db465ef98f07@redhat.com> On 5/21/20 10:08 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > Hi, For documentation purposes I'll explain here why we believe Step 0 is indeed the first thing to do. Step 0 is the deletion of all the files under sun/security/ssl directory that will be either file-replaced or deleted by TLS 1.3 related patches. What we are accomplishing is to clear the sun/security/ssl directory to place a brand-new implementation of the TLS engine (SunJSSE provider, implementing the javax.net.ssl API). No file out of sun/security/ssl is to be file-replaced, in the sense of containing an unnoticed accumulation of changesets. Thus, for any file out of sun/security/ssl we will go through each change individually in following Steps. We understand that: 1) the TLS engine (under sun.security.ssl namespace) can be considered a coherent unit and accept the collapse of all TLS 1.3 related patches -up to 11.0.7- as a starting point; and, 2) make it clear through separated and incremental patches what is needed to integrate it into JDK-8 -so anyone can review and make sense of it-. Not deleting modified files in Step 0 (files that exist before and after TLS 1.3) would create a collection of changes in the repository that is hard to understand because it includes a number of patches collapsed into one. The reason to collapse these changes (do file-replacing) is justified by time and resources constraints. Even though a patch-by-patch backport would be ideal -in my opinion-, I'm okay with going through this path as long as we take reasonable assurances to minimize risks. In regards to the repository history, we are introducing a 'limitation' with the approach taken when tracking changes back in two ways: 1) tracking changes to the legacy TLS engine won't be possible because history has a hard stop with a whole new file committed; and, 2) tracking TLS engine changes between 8196584 (which is the TLS 1.3 implementation) and 11.0.7 with granularity won't be possible. Given that the TLS engine was completely rewritten, I'm inclined to think that there won't be a need to establish a relationship to the previous TLS engine code. In fact, 8196584 is not a collection of small incremental patches that allow you to follow the history; but a large changeset and a new start. Changes after 8196584 are mostly stabilization and security fixes, which could have been in 8196584. In the worst case, a lookup in the 11u repository would be needed to analyze individual changesets. I don't expect this to happen frequently because even if there were a bug, it will probably be analyzed/fixed in 11u first -given that the TLS engine will be the same-: I don't expect many bugs in code within sun.security.ssl to be 8u specific. The fact that we replaced all the files -including superfluous changes such as code formatting- increases the chances that a JDK-11 fix applies cleanly to JDK-8. I went through the list of files deleted by 8245467 (Step 0)/webrev.v0 AND through the list of files deleted or modified by 8196584. All the deleted files deleted by 8245467 (Step 0) are within the sun/security/ssl directory, as expected. There are a few files deleted by 8196584 which were not deleted by 8245467 (Step 0) because they have never been introduced to JDK-8. I'll list them below, grouped by bug ID: * 8046321: JEP 249: OCSP Stapling for TLS * classes/sun/security/ssl/CertStatusReqExtension.java * classes/sun/security/ssl/CertStatusReqItemV2.java * classes/sun/security/ssl/CertStatusReqListV2Extension.java * classes/sun/security/ssl/OCSPStatusRequest.java * classes/sun/security/ssl/StatusRequest.java * classes/sun/security/ssl/StatusRequestType.java * classes/sun/security/ssl/StatusResponseManager.java * classes/sun/security/ssl/UnknownStatusRequest.java * 8043758: JEP 219: Datagram Transport Layer Security (DTLS) * classes/sun/security/ssl/Ciphertext.java * classes/sun/security/ssl/DTLSInputRecord.java * classes/sun/security/ssl/DTLSOutputRecord.java * classes/sun/security/ssl/DTLSRecord.java * classes/sun/security/ssl/HelloCookieManager.java * classes/sun/security/ssl/MaxFragmentLengthExtension.java * classes/sun/security/ssl/Plaintext.java * classes/sun/security/ssl/SSLEngineInputRecord.java * classes/sun/security/ssl/SSLEngineOutputRecord.java * classes/sun/security/ssl/SSLRecord.java * classes/sun/security/ssl/SSLSocketInputRecord.java * classes/sun/security/ssl/SSLSocketOutputRecord.java * 8038089: TLS optional support for Kerberos cipher suites needs to be re-examined * classes/sun/security/ssl/ClientKeyExchange.java * classes/sun/security/ssl/ClientKeyExchangeService.java * classes/sun/security/krb5/internal/ssl/KerberosPreMasterSecret.java * classes/sun/security/krb5/internal/ssl/Krb5KeyExchangeService.java * 8140436: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS * classes/sun/security/ssl/NamedGroup.java * classes/sun/security/ssl/NamedGroupType.java * classes/sun/security/ssl/PredefinedDHParameterSpecs.java * classes/sun/security/ssl/SupportedGroupsExtension.java There are a few files deleted by 8245467 (Step 0) that were not deleted by 8196584 because by the time 8196584 was introduced, previous changesets already deleted them. I'll list them below, grouped by bug ID: * 8043758: JEP 219: Datagram Transport Layer Security (DTLS) * classes/sun/security/ssl/EngineArgs.java * classes/sun/security/ssl/EngineInputRecord.java * classes/sun/security/ssl/EngineOutputRecord.java * classes/sun/security/ssl/EngineWriter.java * 8140436: Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS * classes/sun/security/ssl/EllipticCurvesExtension.java Some files are out of sun/security/ssl, we they are not deleted by Step 0: * conf/security/java.security * classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java * classes/sun/security/jgss/GSSCaller.java * classes/sun/security/jgss/LoginConfigImpl.java * classes/sun/security/krb5/EncryptedData.java * classes/module-info.java Some files are within sun/security/ssl but are not deleted by Step 0 and are not deleted or modified by 8196584 either: * classes/sun/security/ssl/KerberosClientKeyExchange.java * classes/sun/security/ssl/Krb5Helper.java * classes/sun/security/ssl/Krb5Proxy.java This is an exception because the Kerberos feature -removed in JDK-11- will stay in JDK-8 for compatibility reasons. We decided to preserve the repository history here, as the 'new file' hard-stop would add no value. The classes/sun/security/ssl/SunJSSE.java file was not deleted -even though it has been modified by 8196584- and is an exception too. The reason is that this file includes changes from 7092821, which escape sun/security/ssl and would be better handled separately. We could have done file-replacement here and created a new Step to remove them, but it is probably not worth the effort. Note that 7092821 is required for parity with Oracle's JDK and will be introduced later. At some point in the future, there should be almost no differences with JDK 11.0.7's SunJSSE.java file. With all that said, 8245467 (Step 0) webrev.v0 looks okay to me. Note: we had a previous iteration of Step 0 here [1], before splitting the discussion into multiple threads. If any other reviewer has comments related to Step 0 -or to the approach we have taken-, the time is *now* because changes in Step 0 may cause following Step patches to be re-generated in cascade. @Alexey: please hold the push until we review all the steps and a JDK-8 maintainer approves the series of patches. Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011716.html From aph at redhat.com Thu May 21 17:06:20 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 May 2020 18:06:20 +0100 Subject: [8u] TLSv1.3 RFR: 8245467: Remove 8u TLSv1.2 implementation files In-Reply-To: <091b9276-f27d-375d-7cd5-db465ef98f07@redhat.com> References: <3C14EABD-EDDC-4915-A699-DD1D1D333E26@azul.com> <091b9276-f27d-375d-7cd5-db465ef98f07@redhat.com> Message-ID: <7a6c03e9-2e17-91b2-f53d-cb793b40f796@redhat.com> On 5/21/20 5:51 PM, Martin Balao wrote: > With all that said, 8245467 (Step 0) webrev.v0 looks okay to me. > > Note: we had a previous iteration of Step 0 here [1], before splitting > the discussion into multiple threads. > > If any other reviewer has comments related to Step 0 -or to the approach > we have taken-, the time is *now* because changes in Step 0 may cause > following Step patches to be re-generated in cascade. > > @Alexey: please hold the push until we review all the steps and a JDK-8 > maintainer approves the series of patches. That sounds right. -- 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 mbalao at redhat.com Thu May 21 20:10:30 2020 From: mbalao at redhat.com (Martin Balao) Date: Thu, 21 May 2020 17:10:30 -0300 Subject: [8u] RFR: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <7e130cfe-7402-5835-a511-4810fb0ad126@redhat.com> References: <7e130cfe-7402-5835-a511-4810fb0ad126@redhat.com> Message-ID: <121555d0-c382-65d7-7172-c7b3c7967cde@redhat.com> On 5/20/20 5:41 PM, Andrew Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8028591 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8028591/webrev.01/ > > Simple range check additions that have been in OpenJDK since 9u. On the > Oracle parity list for 8u26{1,2}. Thanks for contributing this backport. > Modifications for the backport are the result of security fixes that > have been applied to 8u since the fix was made earlier in the 9u lifecycle: > > * The check on validBits in > src/share/classes/sun/security/util/DerInputStream.java was already > added by JDK-8168714: "Tighten ECDSA validation" Yes, I verified that the patch does not need the validBits because the current code already has it. > > * The len was already assigned to a variable in > src/share/classes/sun/security/util/ObjectIdentifier.java for > JDK-8168705: "Better ObjectIdentifier validation" which checked the > upper bound. > Yes, that's correct. > Also, the copyright header change is redundant as JDK-8175251: "Failed > to load RSA private key from pkcs12" already bumped it to 2017. > Yes, that's right. Copyright's last date is 2017 in DerInputStream.java. > Ok for 8u262? Looks good to me. From gnu.andrew at redhat.com Thu May 21 20:34:23 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 21 May 2020 21:34:23 +0100 Subject: [8u] RFR: 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() In-Reply-To: <121555d0-c382-65d7-7172-c7b3c7967cde@redhat.com> References: <7e130cfe-7402-5835-a511-4810fb0ad126@redhat.com> <121555d0-c382-65d7-7172-c7b3c7967cde@redhat.com> Message-ID: <0b2c93d8-f2cc-1114-3118-44aca06742a6@redhat.com> On 21/05/2020 21:10, Martin Balao wrote: > On 5/20/20 5:41 PM, Andrew Hughes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028591 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8028591/webrev.01/ >> >> Simple range check additions that have been in OpenJDK since 9u. On the >> Oracle parity list for 8u26{1,2}. > > Thanks for contributing this backport. > >> Modifications for the backport are the result of security fixes that >> have been applied to 8u since the fix was made earlier in the 9u lifecycle: >> >> * The check on validBits in >> src/share/classes/sun/security/util/DerInputStream.java was already >> added by JDK-8168714: "Tighten ECDSA validation" > > Yes, I verified that the patch does not need the validBits because the > current code already has it. > >> >> * The len was already assigned to a variable in >> src/share/classes/sun/security/util/ObjectIdentifier.java for >> JDK-8168705: "Better ObjectIdentifier validation" which checked the >> upper bound. >> > > Yes, that's correct. > >> Also, the copyright header change is redundant as JDK-8175251: "Failed >> to load RSA private key from pkcs12" already bumped it to 2017. >> > > Yes, that's right. Copyright's last date is 2017 in DerInputStream.java. > >> Ok for 8u262? > > Looks good to me. > Thanks. I'll flag 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 From gnu.andrew at redhat.com Fri May 22 01:31:41 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 22 May 2020 02:31:41 +0100 Subject: OpenJDK 8u262-b02 & 8u262-b03 EA Released Message-ID: I've made available early access source bundles for 8u262, based on the tag jdk8u262-b02: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b02-ea.tar.xz and jdk8u262-b03: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b03-ea.tar.xz The tarballs are accompanied by digital signatures available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b02-ea.tar.xz.sig https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b03-ea.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: ea1ca3fe99abe68146b83692df4989e1f8e851a03afce57d62ebae3b35e67367 openjdk8u262-b02-ea.tar.xz 1340d874e1f3d93b00b8066f4dbe8eb553ef617db8b30d5f3dacbe855dc6189c openjdk8u262-b02-ea.tar.xz.sig df5295865ac7f12e74a3c2dfcadb910f0fb5fcd9d36b4188b450bd553841cb47 openjdk8u262-b03-ea.tar.xz abfb720574dffe642d2cce52b5e5ace803f615936612328bc781bbf5c90fec73 openjdk8u262-b03-ea.tar.xz.sig These are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b02-ea.sha256 https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b03-ea.sha256 Changes in 8u262-b02: - JDK-8130737: AffineTransformOp can't handle child raster with non-zero x-offset - JDK-8172559: [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java - JDK-8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout - JDK-8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges - JDK-8242883: Incomplete backport of JDK-8078268: backport test part Changes in 8u262-b03: - JDK-8037866: Replace the Fun class in tests with lambdas - JDK-8146612: C2: Precedence edges specification violated - JDK-8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format - JDK-8229888: (zipfs) Updating an existing zip file does not preserve original permissions - JDK-8230597: Update GIFlib library to the 5.2.1 - JDK-8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in early return - JDK-8233880: Support compilers with multi-digit major version numbers - JDK-8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed - JDK-8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set - JDK-8243059: Build fails when --with-vendor-name contains a comma - JDK-8243474: [TESTBUG] removed three tests of 0 bytes - JDK-8244461: [JDK 8u] Build fails with glibc 2.32 - JDK-8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result I've also updated the wiki with the current 8u262 schedule, the proposed schedule for 8u272 and 8u-specific advice on contributions: https://wiki.openjdk.java.net/display/jdk8u/Main Note that the day for build promotions is now officially Friday, which represents the reality of what has tended to happen with recent ones anyway. I think this better encapsulates each build promotion within the working week and gives time for promotion and testing over the weekend. It also means you get an extra couple of days before rampdown next Friday :-) Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri May 22 01:50:06 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 22 May 2020 02:50:06 +0100 Subject: RFR: 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering In-Reply-To: References: Message-ID: <35d72f5f-72d8-58c4-05d4-079707e34df3@redhat.com> On 14/04/2020 20:20, Laurent Bourg?s wrote: > Please review this 10th patch to backport the Marlin renderer from jdk9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8148886 > patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/m10.8148886.patch > webrev: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/webrev-8148886.0/ > unshuffled patch: > http://cr.openjdk.java.net/~lbourges/marlin8u/marlin-8.10/unshuffled/8-m10.8148886.patch > > Changes: > - RendererContext.java: fixed few chunks due to missing changes (Cleaner > API can not be used in jdk8) I presume you just mean the context is different because 8u doesn't have the cleanerObj? I don't see much of a diff. > - fixed Version: to 0.7.3.2 > > Complete diff between unshuffled & proposed patch: > > --- > /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/unshuffled/8-m10.8148886.patch > +++ /home/bourgesl/libs/graphics-rasterizer/wr/marlin-8.10/m10.8148886.patch > @@ -772,10 +772,10 @@ > - * @see MarlinRenderingEngine#REF_TYPE > - */ > - final Object reference; > - // Smallest object used as Cleaner's parent reference > - final Object cleanerObj = new Object(); > // dirty flag indicating an exception occured during pipeline in > pathTo() > -@@ -101,7 +98,7 @@ > + boolean dirty = false; > + // dynamic array caches kept using weak reference (low memory > footprint) > +@@ -99,7 +96,7 @@ > /** > * Constructor > * > @@ -784,7 +784,7 @@ > */ > RendererContext(final String name) { > if (logCreateContext) { > -@@ -124,20 +121,6 @@ > +@@ -122,20 +119,6 @@ > > stroker = new Stroker(this); > dasher = new Dasher(this); > @@ -819,7 +819,7 @@ > > public final class Version { > > -- private static final String version = "marlin-0.7.3-Unsafe-OpenJDK"; > +- private static final String version = "marlin-0.7.2-Unsafe-OpenJDK"; > + private static final String version = "marlin-0.7.3.2-Unsafe-OpenJDK"; > > public static String getVersion() { > > Cheers, > Laurent > I also see some differences in src/share/classes/sun/java2d/pipe/AAShapePipe.java but it seems to just be whitespace differences. Ok for 8u-dev. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From felix.yang at huawei.com Fri May 22 04:34:06 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 22 May 2020 04:34:06 +0000 Subject: [8u] RFR 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in Message-ID: Hi, Original bug: https://bugs.openjdk.java.net/browse/JDK-8244407 https://hg.openjdk.java.net/jdk/jdk/rev/c9f5a16d6980 Original patch doesn't apply cleanly due to conflict on the copyright header update and file path difference, no other conflicts witnessed. 8u webrev: http://cr.openjdk.java.net/~fyang/8244407-8u-backport/ Testing: Run full jtreg test with a x86-64 & aarch64 release build. OK to backport? Thanks, Felix From felix.yang at huawei.com Fri May 22 08:36:04 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 22 May 2020 08:36:04 +0000 Subject: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on OpenJDK Message-ID: Hi, 8u-specific bug: https://bugs.openjdk.java.net/browse/JDK-8245617 ObjectSizeCalculator is not supported for the latest openjdk 8u release, as indicated by the test case. Method getEffectiveMemoryLayoutSpecification in ObjectSizeCalculator.java is expecting a vmName which starts with "Java HotSpot(TM) ". For openjdk 8u release, we have a vmName like: "OpenJDK 64-Bit Server VM". Fix is trivial: diff -r f5a3d8f60cf5 src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java --- a/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Tue May 19 05:11:20 2020 +0100 +++ b/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Fri May 22 15:50:37 2020 +0800 @@ -396,7 +396,8 @@ */ public static MemoryLayoutSpecification getEffectiveMemoryLayoutSpecification() { final String vmName = System.getProperty("java.vm.name"); - if (vmName == null || !vmName.startsWith("Java HotSpot(TM) ")) { + if (vmName == null + || (!vmName.startsWith("OpenJDK ") && !vmName.startsWith("Java HotSpot(TM) "))) { throw new UnsupportedOperationException( "ObjectSizeCalculator only supported on HotSpot VM"); } Is there a good place to incorporate the test case? Thanks, Felix From aph at redhat.com Fri May 22 09:30:27 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 May 2020 10:30:27 +0100 Subject: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on OpenJDK In-Reply-To: References: Message-ID: <207160e1-5ed0-3970-073a-26138147854e@redhat.com> On 5/22/20 9:36 AM, Yangfei (Felix) wrote: > 8u-specific bug: https://bugs.openjdk.java.net/browse/JDK-8245617 > ObjectSizeCalculator is not supported for the latest openjdk 8u release, as indicated by the test case. > Method getEffectiveMemoryLayoutSpecification in ObjectSizeCalculator.java is expecting a vmName which starts with "Java HotSpot(TM) ". > For openjdk 8u release, we have a vmName like: "OpenJDK 64-Bit Server VM". > > Fix is trivial: > diff -r f5a3d8f60cf5 src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java > --- a/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Tue May 19 05:11:20 2020 +0100 > +++ b/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Fri May 22 15:50:37 2020 +0800 > @@ -396,7 +396,8 @@ > */ > public static MemoryLayoutSpecification getEffectiveMemoryLayoutSpecification() { > final String vmName = System.getProperty("java.vm.name"); > - if (vmName == null || !vmName.startsWith("Java HotSpot(TM) ")) { > + if (vmName == null > + || (!vmName.startsWith("OpenJDK ") && !vmName.startsWith("Java HotSpot(TM) "))) { > throw new UnsupportedOperationException( > "ObjectSizeCalculator only supported on HotSpot VM"); > } This code looks almost absurdly fragile. Does it do anything useful at all? I suppose it'd give you an error message if you tried to run it on J9. Anyway, never mind, it's not worth spending any more time thinking about. Your patch is OK, 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 alexey at azul.com Fri May 22 13:33:17 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Fri, 22 May 2020 13:33:17 +0000 Subject: [8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location Message-ID: <63736D64-D1AE-4FD2-96BE-A23A745E8CCB@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u JBS task: https://bugs.openjdk.java.net/browse/JDK-8245477 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v0/ This is a first part of TLS test update. JDK11 and JDK8 has a different directory structure for TLS related tests. As result it is easy to miss test update and get regression. To fix this issue TLS test location should be adjusted between JDK11 and JDK8 This patch relocates 8u TLS related tests to the directories similar to JDK11. Also this patch fixes references to keystore and template files caused by test relocation No one test removed, only moved to another directory. No regression after the test relocation when executed against 8u262 After update, TLS related tests are located in subdirectories: - javax/net/ssl - sun/security/ssl - com/sun/net/ssl - sun/net/www/httpstest - sun/net/www/protocol/https Regards Alexey From mbalao at redhat.com Fri May 22 19:41:14 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 22 May 2020 16:41:14 -0300 Subject: [8u] TLSv1.3 RFR: 8245468: Add TLSv1.3 implementation classes from 11.0.7 In-Reply-To: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com> References: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com> Message-ID: <7c094555-de0d-7b40-0abd-81dc30fb8236@redhat.com> On 5/21/20 10:08 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u Hi, The initial review for 8245468 (Step 1) is here [1], previous to splitting the discussion into multiple threads. In webrev.v0 I could verify that: * DTLSInputRecord.java, DTLSOutputRecord.java and DTLSRecord.java * Were added as new files and are identical to 11.0.7 * Will be removed in a later step, when removing DTLS * Ok * EphemeralKeyManager.java added as a new file (identical to 11.0.7) * Ok * JsseJce.java (identical to 11.0.7) * Added as a new file. Kerberos changes will be re-added in a later step. * Ok * HelloVerifyRequest.java (identical to 11.0.7) * Added as a new file * Ok * KeyManagerFactoryImpl.java (identical to 11.0.7) * Added as a new file * Ok * No other changes * Ok 8245468 (Step 1) webrev.v0 looks good to me. Please hold the push until the whole series is review-approved and approved by a JDK-8 maintainer. Thanks, Martin.- -- [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011742.html From felix.yang at huawei.com Sat May 23 01:31:46 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sat, 23 May 2020 01:31:46 +0000 Subject: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on OpenJDK In-Reply-To: <207160e1-5ed0-3970-073a-26138147854e@redhat.com> References: <207160e1-5ed0-3970-073a-26138147854e@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Friday, May 22, 2020 5:30 PM > To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' > > Subject: Re: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on > OpenJDK > > On 5/22/20 9:36 AM, Yangfei (Felix) wrote: > > > 8u-specific bug: https://bugs.openjdk.java.net/browse/JDK-8245617 > > ObjectSizeCalculator is not supported for the latest openjdk 8u release, as > indicated by the test case. > > Method getEffectiveMemoryLayoutSpecification in > ObjectSizeCalculator.java is expecting a vmName which starts with "Java > HotSpot(TM) ". > > For openjdk 8u release, we have a vmName like: "OpenJDK 64-Bit Server > VM". > > > > Fix is trivial: > > diff -r f5a3d8f60cf5 > src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java > > --- a/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Tue > May 19 05:11:20 2020 +0100 > > +++ b/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Fri > May 22 15:50:37 2020 +0800 > > @@ -396,7 +396,8 @@ > > */ > > public static MemoryLayoutSpecification > getEffectiveMemoryLayoutSpecification() { > > final String vmName = System.getProperty("java.vm.name"); > > - if (vmName == null || !vmName.startsWith("Java HotSpot(TM) ")) { > > + if (vmName == null > > + || (!vmName.startsWith("OpenJDK ") && > > + !vmName.startsWith("Java HotSpot(TM) "))) { > > throw new UnsupportedOperationException( > > "ObjectSizeCalculator only supported on HotSpot VM"); > > } > > This code looks almost absurdly fragile. Does it do anything useful at all? > I suppose it'd give you an error message if you tried to run it on J9. Indeed. The code is there since 2013. > Anyway, never mind, it's not worth spending any more time thinking about. > > Your patch is OK, thanks. Thanks for the quick review. Will push this trivial change. Felix From gnu.andrew at redhat.com Sat May 23 10:41:41 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 23 May 2020 11:41:41 +0100 Subject: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on OpenJDK In-Reply-To: References: <207160e1-5ed0-3970-073a-26138147854e@redhat.com> Message-ID: On 23/05/2020 02:31, Yangfei (Felix) wrote: > > >> -----Original Message----- >> From: Andrew Haley [mailto:aph at redhat.com] >> Sent: Friday, May 22, 2020 5:30 PM >> To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' >> >> Subject: Re: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on >> OpenJDK >> >> On 5/22/20 9:36 AM, Yangfei (Felix) wrote: >> >>> 8u-specific bug: https://bugs.openjdk.java.net/browse/JDK-8245617 >>> ObjectSizeCalculator is not supported for the latest openjdk 8u release, as >> indicated by the test case. >>> Method getEffectiveMemoryLayoutSpecification in >> ObjectSizeCalculator.java is expecting a vmName which starts with "Java >> HotSpot(TM) ". >>> For openjdk 8u release, we have a vmName like: "OpenJDK 64-Bit Server >> VM". >>> >>> Fix is trivial: >>> diff -r f5a3d8f60cf5 >> src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java >>> --- a/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Tue >> May 19 05:11:20 2020 +0100 >>> +++ b/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Fri >> May 22 15:50:37 2020 +0800 >>> @@ -396,7 +396,8 @@ >>> */ >>> public static MemoryLayoutSpecification >> getEffectiveMemoryLayoutSpecification() { >>> final String vmName = System.getProperty("java.vm.name"); >>> - if (vmName == null || !vmName.startsWith("Java HotSpot(TM) ")) { >>> + if (vmName == null >>> + || (!vmName.startsWith("OpenJDK ") && >>> + !vmName.startsWith("Java HotSpot(TM) "))) { >>> throw new UnsupportedOperationException( >>> "ObjectSizeCalculator only supported on HotSpot VM"); >>> } >> >> This code looks almost absurdly fragile. Does it do anything useful at all? >> I suppose it'd give you an error message if you tried to run it on J9. > > Indeed. The code is there since 2013. For the record, this is only not applicable to 11u and later because it was removed by JDK-8189617. At the time of removal, it still had this code, unfixed for OpenJDK. It seems trying to fix this was actually the motivation for removing it altogether, because it's completely broken with the OpenJDK 9 module & versioning changes: https://bugs.openjdk.java.net/browse/JDK-8171934 I've reopened that and this fix to 8u should be pushed under that ID. 8245617 has been closed as a dupe. > >> Anyway, never mind, it's not worth spending any more time thinking about. >> >> Your patch is OK, thanks. > > Thanks for the quick review. Will push this trivial change. > > Felix > Pushes to jdk8u require jdk8u-fix-yes (https://wiki.openjdk.java.net/display/jdk8u/Main, step #11). Please flag JDK-8171934 with a jdk8u-fix-request and I'll approve. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Sat May 23 10:48:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 23 May 2020 11:48:11 +0100 Subject: [8u] RFR: 8244843: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: <3037e70f07846eda25fdf67e3b022e4ce30fb458.camel@redhat.com> References: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> <3037e70f07846eda25fdf67e3b022e4ce30fb458.camel@redhat.com> Message-ID: <04a578a7-4577-924f-4dc1-8741e3bddb8e@redhat.com> On 15/05/2020 10:22, Severin Gehwolf wrote: > Hi Andrew, > > Sigh, I only now realized that the bug number was missing the > subject. Fixed now. > snip... >>> >> >> Only issue with the patch itself is java.time.japanese.short.Eras is >> missing the new Reiwa era. I guess this is because 11u has JDK-8159943, >> which refactors these files so they share blocks where possible, before >> JDK-8219781. Thus, there is only one block to change in 11u, but it's a >> shared block which is then used from both java.time.japanese.short.Eras >> & java.time.japanese.long.Eras > > Should be fixed in 03 here. Thanks for the catch: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/03/webrev/ > > Thoughts? > > Thanks, > Severin > I thought I replied to this about a week ago, but I can find no trace of doing so :/ Anyway, this version looks fine. Please flag with jdk8u-fix-request and let's get it fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From alexey at azul.com Sun May 24 17:21:59 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Sun, 24 May 2020 17:21:59 +0000 Subject: [8u] TLSv1.3 RFR: 8245653: Remove 8u TLS tests Message-ID: <4B5D3740-810E-442A-A583-A62B3BA731CD@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u JBS task: https://bugs.openjdk.java.net/browse/JDK-8245653 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v0/ This is a second part of TLS test update. This patch removes tests that are not valid for the new TLS implementation and should be replaced by JDK11.0.7 tests This patch should be applied after the JDK-8245477 After the test is applied all remaining tests should pass with new TLS implementation Regards Alexey From alexey at azul.com Sun May 24 18:05:25 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Sun, 24 May 2020 18:05:25 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 Message-ID: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u JBS task: https://bugs.openjdk.java.net/browse/JDK-8245681 Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v0/ This is a third part of TLS test update. This patch adds TLS related regression tests from the JDK11.0.7 implementation. This patch should be applied after the JDK-8245653 After the patch is applied all regression tests should pass successfully with new TLS implementation Some notes for this patch: - I had to exclude javax/net/ssl/HttpsURLConnection/Equals.java test ( marked as @ignore ) This test verifies changes introduced by JDK-8055299 [1]. May be we should backport JDK-8055299 in terms of this TLSv1.3 implementation - Test sun/security/ssl/SSLSocketImpl/ClientTimeout.java is ignored in 11.0.7 but will fixed in 11.0.8 by JDK-8239798 [2]. JDK-8239798 fixes backward compatibility issue between JDK11 and JDK8 for TLS connection. It seems this fix should be added to the new TLS implementation for JDK8u - I've fixed trivial build issue in the sun/security/ec/TestEC.java - I?ve fixed sun/security/krb5/auto/SSL.java test. Test change is caused by new implementation of RFC2712 for TLSv1.3 [3] [1] - https://bugs.openjdk.java.net/browse/JDK-8055299 [2] - https://bugs.openjdk.java.net/browse/JDK-8239798 [3] - http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245474/webrev.v0/ Regards Alexey From felix.yang at huawei.com Mon May 25 00:58:28 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 25 May 2020 00:58:28 +0000 Subject: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on OpenJDK In-Reply-To: References: <207160e1-5ed0-3970-073a-26138147854e@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Saturday, May 23, 2020 6:42 PM > To: Yangfei (Felix) ; Andrew Haley > ; 'jdk8u-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on > OpenJDK > snip... > > For the record, this is only not applicable to 11u and later because it was > removed by JDK-8189617. > > At the time of removal, it still had this code, unfixed for OpenJDK. > It seems trying to fix this was actually the motivation for removing it > altogether, because it's completely broken with the OpenJDK 9 module & > versioning changes: > > https://bugs.openjdk.java.net/browse/JDK-8171934 > > I've reopened that and this fix to 8u should be pushed under that ID. > 8245617 has been closed as a dupe. Thanks for the info. Webrev: http://cr.openjdk.java.net/~fyang/8171934/webrev.00/ > > > >> Anyway, never mind, it's not worth spending any more time thinking > about. > >> > >> Your patch is OK, thanks. > > > > Thanks for the quick review. Will push this trivial change. > > > > Felix > > > > Pushes to jdk8u require jdk8u-fix-yes > (https://wiki.openjdk.java.net/display/jdk8u/Main, step #11). Please flag > JDK-8171934 with a jdk8u-fix-request and I'll approve. I have labeled JDK-8171934 with jdk8u-fix-request. Please take a look. Felix From gnu.andrew at redhat.com Mon May 25 02:09:05 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 03:09:05 +0100 Subject: [8u] RFR 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in In-Reply-To: References: Message-ID: <818cc8fa-99e2-2f58-b2f0-3f1d9e3a8055@redhat.com> On 22/05/2020 05:34, Yangfei (Felix) wrote: > Hi, > > Original bug: > https://bugs.openjdk.java.net/browse/JDK-8244407 > https://hg.openjdk.java.net/jdk/jdk/rev/c9f5a16d6980 > > Original patch doesn't apply cleanly due to conflict on the copyright header update and file path difference, no other conflicts witnessed. > > 8u webrev: > http://cr.openjdk.java.net/~fyang/8244407-8u-backport/ > > Testing: Run full jtreg test with a x86-64 & aarch64 release build. > > OK to backport? > > Thanks, > Felix > Copyright header changes should only be dropped if the existing year is the same or later than that in the patch. In this case, the patch updates the year to 2020, but 8u only has 2017, so the change should be manually applied to bump the file in 8u to 2020. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From felix.yang at huawei.com Mon May 25 02:18:34 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 25 May 2020 02:18:34 +0000 Subject: [8u] RFR 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in In-Reply-To: <818cc8fa-99e2-2f58-b2f0-3f1d9e3a8055@redhat.com> References: <818cc8fa-99e2-2f58-b2f0-3f1d9e3a8055@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Monday, May 25, 2020 10:09 AM > To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' > > Subject: Re: [8u] RFR 8244407: JVM crashes after transformation in C2 > IdealLoopTree::split_fall_in > > > > On 22/05/2020 05:34, Yangfei (Felix) wrote: > > Hi, > > > > Original bug: > > https://bugs.openjdk.java.net/browse/JDK-8244407 > > https://hg.openjdk.java.net/jdk/jdk/rev/c9f5a16d6980 > > > > Original patch doesn't apply cleanly due to conflict on the copyright header > update and file path difference, no other conflicts witnessed. > > > > 8u webrev: > > http://cr.openjdk.java.net/~fyang/8244407-8u-backport/ > > > > Testing: Run full jtreg test with a x86-64 & aarch64 release build. > > > > OK to backport? > > > > Thanks, > > Felix > > > > Copyright header changes should only be dropped if the existing year is the > same or later than that in the patch. In this case, the patch updates the year > to 2020, but 8u only has 2017, so the change should be manually applied to > bump the file in 8u to 2020. Do you mean this file: src/share/vm/opto/loopnode.cpp? I read this before: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011224.html Is there anything different for this case? Thanks, Felix From gnu.andrew at redhat.com Mon May 25 05:33:16 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 06:33:16 +0100 Subject: [8u] RFR 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in In-Reply-To: References: <818cc8fa-99e2-2f58-b2f0-3f1d9e3a8055@redhat.com> Message-ID: On 25/05/2020 03:18, Yangfei (Felix) wrote: > Hi, > >> -----Original Message----- >> From: Andrew Hughes [mailto:gnu.andrew at redhat.com] >> Sent: Monday, May 25, 2020 10:09 AM >> To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' >> >> Subject: Re: [8u] RFR 8244407: JVM crashes after transformation in C2 >> IdealLoopTree::split_fall_in >> >> >> >> On 22/05/2020 05:34, Yangfei (Felix) wrote: >>> Hi, >>> >>> Original bug: >>> https://bugs.openjdk.java.net/browse/JDK-8244407 >>> https://hg.openjdk.java.net/jdk/jdk/rev/c9f5a16d6980 >>> >>> Original patch doesn't apply cleanly due to conflict on the copyright header >> update and file path difference, no other conflicts witnessed. >>> >>> 8u webrev: >>> http://cr.openjdk.java.net/~fyang/8244407-8u-backport/ >>> >>> Testing: Run full jtreg test with a x86-64 & aarch64 release build. >>> >>> OK to backport? >>> >>> Thanks, >>> Felix >>> >> >> Copyright header changes should only be dropped if the existing year is the >> same or later than that in the patch. In this case, the patch updates the year >> to 2020, but 8u only has 2017, so the change should be manually applied to >> bump the file in 8u to 2020. > > Do you mean this file: src/share/vm/opto/loopnode.cpp? > I read this before: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-February/011224.html > Is there anything different for this case? > > Thanks, > Felix > I believe that was in reference to a copyright change being created for the backport. In this case, the copyright header change has wrongly been removed, when compared to the original patch. It should be reinstated. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon May 25 06:05:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 07:05:35 +0100 Subject: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on OpenJDK In-Reply-To: References: <207160e1-5ed0-3970-073a-26138147854e@redhat.com> Message-ID: <76df8d0d-b96e-ccf1-b791-dc1b253f5fbd@redhat.com> On 25/05/2020 01:58, Yangfei (Felix) wrote: > > >> -----Original Message----- >> From: Andrew Hughes [mailto:gnu.andrew at redhat.com] >> Sent: Saturday, May 23, 2020 6:42 PM >> To: Yangfei (Felix) ; Andrew Haley >> ; 'jdk8u-dev at openjdk.java.net' > dev at openjdk.java.net> >> Subject: Re: [8u] RFR(XS) 8245617: ObjectSizeCalculator is not supported on >> OpenJDK >> > > snip... > >> >> For the record, this is only not applicable to 11u and later because it was >> removed by JDK-8189617. >> >> At the time of removal, it still had this code, unfixed for OpenJDK. >> It seems trying to fix this was actually the motivation for removing it >> altogether, because it's completely broken with the OpenJDK 9 module & >> versioning changes: >> >> https://bugs.openjdk.java.net/browse/JDK-8171934 >> >> I've reopened that and this fix to 8u should be pushed under that ID. >> 8245617 has been closed as a dupe. > > Thanks for the info. > Webrev: http://cr.openjdk.java.net/~fyang/8171934/webrev.00/ > >>> >>>> Anyway, never mind, it's not worth spending any more time thinking >> about. >>>> >>>> Your patch is OK, thanks. >>> >>> Thanks for the quick review. Will push this trivial change. >>> >>> Felix >>> >> >> Pushes to jdk8u require jdk8u-fix-yes >> (https://wiki.openjdk.java.net/display/jdk8u/Main, step #11). Please flag >> JDK-8171934 with a jdk8u-fix-request and I'll approve. > > I have labeled JDK-8171934 with jdk8u-fix-request. Please take a look. > > Felix > Thanks. Approved and pushed, will be part of jdk8u262-b04. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon May 25 06:06:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 07:06:38 +0100 Subject: [8u] RFR: Backport of 8067796 (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null In-Reply-To: <00ABA8D5-3374-477F-97B3-B39642E115AA@azul.com> References: <11F4B16A-212E-4805-AF6A-46B8760278EB@azul.com> <586f5546-4614-565a-dc5f-8c62aff09782@redhat.com> <2b42427a-6485-4c36-fbb2-ff7f4eedf08b@redhat.com> <23C95150-015E-417C-AEF9-5E3E389896DA@azul.com> <87c7205e-5b55-f95c-0800-72c4e0aa408c@redhat.com> <00ABA8D5-3374-477F-97B3-B39642E115AA@azul.com> Message-ID: On 15/05/2020 17:30, Sergey Nazarkin wrote: > Thanks, Andrew! 8037866 was pushed. > > > Sergey Nazarkin > > Thanks Sergey! Approved and pushed 8067796, will be part of jdk8u262-b04. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon May 25 06:08:51 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 07:08:51 +0100 Subject: [8u] RFR: 8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE In-Reply-To: References: <9FDC0DA0-10A8-4603-97BF-AB85F4954389@amazon.com> <5b6eb7c0facc02856ef72ca8d941f95ae2c4c041.camel@redhat.com> Message-ID: On 21/04/2020 11:06, Severin Gehwolf wrote: > Hi Andrew, > > On Tue, 2020-02-18 at 12:25 +0000, Andrew Hughes wrote: >> >> On 29/11/2019 16:42, Severin Gehwolf wrote: >>> On Fri, 2019-11-29 at 16:09 +0000, Hohensee, Paul wrote: >>>> Looks good. >>> >>> Thanks for the review, Paul! >>> >>>> Separately, how difficult would it be to backport the SA test infra? Should we consider doing it? >>> >>> I haven't looked at it in detail, but it may be something we should >>> consider doing. I doubt it's difficult, but it'll be a chunk of work. >>> >>> It basically amounts to looking at >>> test/hotspot/jtreg/serviceability/sa/ and checking what functionality >>> exists in 8u then porting it over. Not sure how much of the other test >>> support libraries would need to get backported too. >>> >>> Thanks, >>> Severin >>> >>>> Thanks, >>>> Paul >>>> >> >> Could we not include the tests but ProblemList them for now? I'm very >> wary of just dropping tests on the floor, because it means someone else >> needs to find and restore them under a separate bug later. You probably >> need to knock the 'jtreg' out of the path so it fits into the current >> OpenJDK 8u setup. > > In JDK 8u there is only one ProblemList.txt (in jdk repo). So there is > no easy way to problem list a test out of the box. I could remove the > @test annotation so that it doesn't run. Is such an approach going to > help anybody, though? It'll just not run and would need another bug to > get enabled anyway. Of course I can do that if you insist (like in > [1]), but it opens up the door for it to bit-rot. > > Personally, it's either biting the bullet and backporting the entire SA > testing infra (and this test). Or not having this test at all. For > reference (and adhoc testing), there would be the JDK 11 test to fall > back on. I'm strongly for the latter in this case. > >> JDK-8081037: "serviceability/sa/ tests time out on Windows" (introduces >> LingeredApp.java) and JDK-8190198: "SA: Framework for writing 'jhsdb >> clhsdb' commands tests and testcases for some of the commands" seem to >> be the key issues here, but there are probably others. > > Right. Do we really need to bring in two more bugs for this small fix > in SA code, though? There is a balance to strike. It's hard enough to > get fixes in. Even without backporting 2 other dependencies for tests. > Getting 8u test code into a state where 11u is will require some > significant amount of work across the board :-/ > > Thanks, > Severin > > [1] http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196969/jdk8/02/webrev/ > I think it's preferable to have it there, even disabled, than expecting someone to know about it on some future date when the dependent tests are added. It's also easier to fix it up by adding one line back than it is to dig out the original changeset. Worst case, we can always delete it later. Approved and pushed v02, will be part of jdk8u262-b04. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Mon May 25 06:16:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 07:16:49 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> Message-ID: On 03/04/2020 10:18, Andrew Haley wrote: > On 4/3/20 4:44 AM, Andrew Hughes wrote: >> >> On 02/04/2020 09:36, Andrew Haley wrote: >>> On 4/1/20 6:54 PM, Andrew Hughes wrote: >>>> * src/share/vm/runtime/os.{c,h}pp >>>> If we're going to add strdup_check_oom, I think this should be done by >>>> backporting JDK-6424123 [1] so it's used consistently throughout the >>>> codebase rather than just the two call sites in this patch. >>> >>> I strongly disagree that we should import such a patch into JDK 8 for >>> this reason. >>> >>> It's a judgement call, of course. We have two desiderata here: those >>> of consistently backporting patches and minimizing changes. As JDK 8 >>> matures, minimizing change has become more and more important, and it's >>> perfectly OK to snip small fragments of patches such as this in order >>> to minimize change. >>> >>> Of course I'm aware of the other side of the argument, but I don't >>> think it's as important. >> >> And I strongly disagree with turning 8u into a unmaintainable mass of >> partial chunks of code from various changesets. > > I have no intention of doing that, but pulling in large and otherwise > unnecessary changesets for single functions should not be done in a > release of a mature product. > > Here is my reasoning. The need for stability and the minimization of > churn increases over time. People use JDK 8 because they want that > stability, and every patch carries some risk. So, ecause it is now a > mature piece of software, patches should be minimal where they > reasonably can. The practice of, by default, pulling in dependencies > from later releases is too risky: they might well be broken in ways > that the old version wasn't, and they may depend on other changes in > the recent code base. > > Now, that doesn't mean that such dependent changesets must *never* be > pulled in, especially when they are needed by several backports. But > if dependency changesets substantially multiply the size of a change, > as they do in this case, this should not be done. > > I am aware that this does not ease the life of the maintainers, but > that isn't the goal. Stability is. It's not about making life easier for maintainers; reviewing and approving more patches means the opposite. My concern is that the more 8u diverges from later versions, and uses its own bespoke version of fixes, the greater the knowledge and experience needed for someone to work on it. We're already struggling to keep up as it is. Each case has to be considered separately, according to risk and the changes involved. It's not a guarantee of stability to just not make changes. If it leads to the changes that are made to 8u being unique to that codebase, and not as widely tested as something that has been in later versions for years, we will introduce more 8u-specific bugs. In short, there is no easy answer and no one size fits all solution. > > We need to discuss this issue some more, with a view to producing some > updated guidelines. > >> In this case, it would lead to a strdup failure being handled >> differently, depending on where in the code it occurred. >> The alternative would be to use os::strdup directly and avoid >> introducing this function. This was how JDK-8155968 already handled >> this issue. > > That sounds like an excellent idea. I'll prepare a new patch. > New patch looks good. I've approved and pushed it, so it will be part of jdk8u262-b04. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From felix.yang at huawei.com Mon May 25 11:05:20 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 25 May 2020 11:05:20 +0000 Subject: [8u] RFR 8244407: JVM crashes after transformation in C2 IdealLoopTree::split_fall_in In-Reply-To: References: <818cc8fa-99e2-2f58-b2f0-3f1d9e3a8055@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Hughes [mailto:gnu.andrew at redhat.com] > Sent: Monday, May 25, 2020 1:33 PM > To: Yangfei (Felix) ; 'jdk8u-dev at openjdk.java.net' > > Subject: Re: [8u] RFR 8244407: JVM crashes after transformation in C2 > IdealLoopTree::split_fall_in > > Snip... > > > > I believe that was in reference to a copyright change being created for the > backport. > > In this case, the copyright header change has wrongly been removed, when > compared to the original patch. It should be reinstated. Thanks. Now I see the point. New webrev: http://cr.openjdk.java.net/~fyang/8244407-8u-backport/webrev.01 Felix From neugens at redhat.com Mon May 25 12:15:51 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 25 May 2020 14:15:51 +0200 Subject: RFR: backport of 8239819 Message-ID: Hi all, i would like to backpor the following bug to jdk8u: https://bugs.openjdk.java.net/browse/JDK-8239819 The patch applies almost cleanly, the obvious exception is the copyright year but also a line in the src/solaris/classes/sun/awt/X11/XToolkit.java caused by the presence of a field that isn't there anymore in the original patch, so this probably needs a quick review: http://cr.openjdk.java.net/~neugens/8239819/webrev.00/ I tested with the usual jtregs and manually and can't see any problem. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From akashche at redhat.com Mon May 25 19:48:43 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 25 May 2020 20:48:43 +0100 Subject: [8u] RFC: 8172695: (scanner) java/util/Scanner/ScanTest.java fails Message-ID: Hi, I'd like to solicit comments and suggestions about the backport of JDK-8172695 to 8u. Jira issue: https://bugs.openjdk.java.net/browse/JDK-8172695 There were a number of changes to ScanTest and to Scanner itself in 9+, so to backport 8172695 cleanly the following issues need to be backported as well: 8132206: move ScanTest.java into OpenJDK 8132745: TEST_BUG: minor cleanup of java/util/Scanner/ScanTest.java 8072722: add stream support to Scanner [excluding public API changes] 8139414: java.util.Scanner hasNext() returns true, next() throws NoSuchElementException 8159545: closed/java/io/Console/TestConsole.java failed with exit code 1 [not public, see: https://hg.openjdk.java.net/jdk/jdk/rev/e5d52546ba3a ] 8166261: Scanner.nextInt(int) (and similar methods) throws PatternSyntaxException 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if English Locale unavailable What would be the preferred way to bring this to 8u? Is it better to backport these changes one by one, or just take 8172695 and modify it for 8u? Should bugfixes to Scanner itself (8139414 and 8166261) be backported in latter case? -- -Alex From akashche at redhat.com Mon May 25 19:48:54 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Mon, 25 May 2020 20:48:54 +0100 Subject: [8u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions In-Reply-To: References: <09d61305-07c1-d493-60af-7e96e0bfc7b3@redhat.com> <7366bd30-b282-656a-1c2e-0cc336f815ef@redhat.com> Message-ID: <7bb6c886-2435-2e83-2c89-007ae99f5028@redhat.com> On 04/04/2020 12:28 PM, Alex Kashchenko wrote: > On 04/02/2020 04:46 AM, Andrew Hughes wrote: >> On 26/03/2020 23:15, Alex Kashchenko wrote: >>> Hi, >>> >>> Please review the backport of JDK-8229888 to 8u: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229888 >>> >>> Original review thread: >>> http://mail.openjdk.java.net/pipermail/nio-dev/2019-December/006894.html >>> >>> 11u changeset: >>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/57fd597352b8 >>> >>> 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.00/ >>> >>> 8u patch is very close to 11u one: ZipFileSystem part is the same, test >>> is changed to replace API not available in 8u, changes to policy file >>> are not included. >>> >> >> It would be helpful if you could explain why such changes had to be >> made, rather than leaving the reviewer to guess. >> >> The test changes are fairly clear, though the replacement for Set.of, >> createSet, returns a modifiable set, whereas of returns an unmodifiable >> set. This doesn't really matter for a test case, but may in JDK code. >> >> It could also potentially be simplified to just: >> >> ???? private static Set createSet(Object... entries) { >> ????Set set = new LinkedHashSet<>(Arrays.asList(entries)); >> ????return Collections.unmodifiableSet(set); >> ???? } > > Thanks for the review! I simplified this part of test removing > createSet() helper: > > https://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.01/ > >> >> I'm not sure why the policy file change is unnecessary. I would guess >> it's because the zipfs code is only demo code in 8u, but it would be >> good to have more reassurance. > > AFAIU these changes to policy file are only necessary for jdk9+ with > JPMS, some details on this policy change in jdk11: > > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002644.html > > > https://mail.openjdk.java.net/pipermail/nio-dev/2019-March/005978.html Gentle reminder. -- -Alex From ebaron at redhat.com Mon May 25 20:53:38 2020 From: ebaron at redhat.com (Elliott Baron) Date: Mon, 25 May 2020 16:53:38 -0400 Subject: [8u] RFR Backport 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 In-Reply-To: References: Message-ID: <9491cfd6-18b3-aeff-e7d3-8ec4fc0c77e8@redhat.com> Hi, On 2020-05-08 2:58 p.m., Elliott Baron wrote: > Hi, > > On 2020-04-16 7:54 p.m., Elliott Baron wrote: >> Hi, >> >> I'd like to request a review to backport 8177334 to 8u. >> >> Original fix: >> https://bugs.openjdk.java.net/browse/JDK-8177334 >> http://hg.openjdk.java.net/jdk/jdk/rev/3810c9a2efa1 >> >> The JDK 11 fix did not apply cleanly. Below, I have detailed the >> modifications I made in order to backport this fix to 8u. There are >> some major changes that I believe may require some discussion, and >> many minor changes outlined after those. The changes within each >> section are listed roughly in order of the patch. >> >> Thank you to Martin Balao for his assistance in tracking down the >> dependencies for this fix. >> >> I should point out that there are some known bugfixes that fix >> problems introduced by this update. These should probably go into the >> same 8u update as this fix. They are: >> - 8217878: ENVELOPING XML signature no longer works >> - 8218629: XML Digital Signature throws NAMESPACE_ERR exception on >> OpenJDK 11, works 8/9/10 (I believe this is the same fix as above) >> - 8236645: JDK 8u231 introduces a regression with incompatible >> handling of XML messages >> >> 8u webrev: >> https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.00/ > > Has anyone had a chance to take a look at this yet? > >> >> [snip] Here is an updated webrev that fixes conflicts introduced by 8231415: Better signatures in XML. 8u webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8177334/webrev.01/ Thanks, Elliott From adinn at redhat.com Tue May 26 08:57:01 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 26 May 2020 09:57:01 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> Message-ID: Hi Andrew(s) On 25/05/2020 07:16, Andrew Hughes wrote: > > > On 03/04/2020 10:18, Andrew Haley wrote: . . . >> Here is my reasoning. The need for stability and the minimization of >> churn increases over time. People use JDK 8 because they want that >> stability, and every patch carries some risk. So, ecause it is now a >> mature piece of software, patches should be minimal where they >> reasonably can. The practice of, by default, pulling in dependencies >> from later releases is too risky: they might well be broken in ways >> that the old version wasn't, and they may depend on other changes in >> the recent code base. >> >> Now, that doesn't mean that such dependent changesets must *never* be >> pulled in, especially when they are needed by several backports. But >> if dependency changesets substantially multiply the size of a change, >> as they do in this case, this should not be done. >> >> I am aware that this does not ease the life of the maintainers, but >> that isn't the goal. Stability is. > > It's not about making life easier for maintainers; reviewing and > approving more patches means the opposite. My concern is that the more > 8u diverges from later versions, and uses its own bespoke version of > fixes, the greater the knowledge and experience needed for someone to > work on it. We're already struggling to keep up as it is. Well, that's one direction of travel. This is, however, a two way street. The more jdk8u pulls in changes from later versions instead of using its own bespoke version of fixes, the more likely it is that one of those changes is going to be based on assumptions baked into the upstream repo code that clash with assumptions baked into jdk8u repo code. Understanding why something is breaking the jdk8u rules and how that can be squared with what the the rest of the jdk8u code does is an equal peril. The danger is subtle errors where we fall foul of races, corner cases, re-orderings of control or synchronization, different interpretation of the same values in the same flags, counters or object fields. The problems that may arise in this way cannot really easily be avoided by adapting a patch as it is backported, even less so by pulling in more patches. The obvious safeguards that are provided by getting the code to compile and pass tests won't remove this sort of risk. The only way to avoid those errors as you pull in ever more changes is to backport everything so that the design decisions that constrain how jdk8u operates have all been replaced with the upstream ones. However, that's clearly not the destination we need to aim for. None of these complex, subtle risks can be avoided via a simple, mechanical process. All of them require the application of careful judgement and a deep knowledge of the code bases involved. The more releases there are between the original version of a patch and it's application downstream the more thinking there needs to be. Given enough distance (and with many patches we have more than enough distance even between jdk11u and jdk8u) we can no longer afford to proceed by tweaking an upstream patch, even less so by pulling in all the apparatus it depends on. We have to think about the bug (or perf issue), think about what that bug means in the context of jdk8u and then think about designing a patch that fixes it from the point of view of jdk8u. The original patch /may/ do the job, or /may/ guide us to the right fix. However, if the upstream patch is dependent on a lot of other changes not present in jdk8u then that's a flashing red light saying that this patch won't do and that a custom patch is a better, safer bet. > Each case has to be considered separately, according to risk and the > changes involved. It's not a guarantee of stability to just not make > changes. If it leads to the changes that are made to 8u being unique to > that codebase, and not as widely tested as something that has been in > later versions for years, we will introduce more 8u-specific bugs. In > short, there is no easy answer and no one size fits all solution. Yes, that is right. However, I agree with Andrew that we need to have a very healthy mistrust of any patch that requires us to pull other changes in its wake. Upstream fixes may legitimately depend on other upstream fixes because ... well, they were already there and, when added, one can assume they were known to be necessary and safe in that upstream context. Downstream fixes should normally only presume the presence of such a dependency if there is a compelling need to have that dependency /in its own right/. If not then the default assumption has to be that a downstream fix should be sought without relying on that upstream dependency. Pulling in multiple patches simply because that was a legitimate upstream choice is a very slippery and dangerous slope. regards, Andrew Dinn ----------- From jaroslav.bachorik at datadoghq.com Tue May 26 10:12:46 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Tue, 26 May 2020 12:12:46 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Gentle ping? On Wed, May 20, 2020 at 11:30 PM Jaroslav Bachor?k wrote: > > On Fri, May 15, 2020 at 5:53 PM Jaroslav Bachor?k > wrote: > > > > Hi Andrew, > > > > On Fri, May 15, 2020 at 3:35 PM Andrew Haley wrote: > > > > > > On 5/15/20 1:01 PM, Mario Torre wrote: > > > > The patch is good to go for my side, we still need to wait for the > > > > maintainer to change the status to jdk8u-fix-yes before you can push > > > > though. > > > > > > I'm tempted to say yes. However, I get frightened whenever I see any > > > change to HotSpot initialization code, particularly things that change > > > the order in which classes are initialized. Can you make the early > > > call to initialize_class(vmSymbols::java_lang_Class()) JFR-only? > > > > I can try that. Let me get back with the result. > > I put the early java_lang_Class initialization in `#if INCLUDE_JFR` > block. The original java_lang_Class initialization location was > enclosed in an inverted `#if INCLUDE_JFR` block to ensure the original > behaviour if JFR is not enabled in build config. > > Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.02/ > > Thanks, > > -JB- > > > > > -JB- > > > > > > > > -- > > > 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 neugens at redhat.com Tue May 26 12:59:36 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 26 May 2020 14:59:36 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: Hi Jaroslav, The patch looks good to me, just a minor nit (but I don't need a re-review for this change) is to check the indentation of the preprocessor: + #if INCLUDE_JFR + // The VM creates & returns objects of this class. Make sure it's initialized. + initialize_class(vmSymbols::java_lang_Class(), CHECK_0); + #endif Should indent at beginning of the line, like: +#if INCLUDE_JFR + // The VM creates & returns objects of this class. Make sure it's initialized. + initialize_class(vmSymbols::java_lang_Class(), CHECK_0); +#endif Likewise the block below that. We still need Andrew to approve before you can push though ;) Cheers, Mario On Tue, May 26, 2020 at 12:13 PM Jaroslav Bachor?k wrote: > > Gentle ping? > > On Wed, May 20, 2020 at 11:30 PM Jaroslav Bachor?k > wrote: > > > > On Fri, May 15, 2020 at 5:53 PM Jaroslav Bachor?k > > wrote: > > > > > > Hi Andrew, > > > > > > On Fri, May 15, 2020 at 3:35 PM Andrew Haley wrote: > > > > > > > > On 5/15/20 1:01 PM, Mario Torre wrote: > > > > > The patch is good to go for my side, we still need to wait for the > > > > > maintainer to change the status to jdk8u-fix-yes before you can push > > > > > though. > > > > > > > > I'm tempted to say yes. However, I get frightened whenever I see any > > > > change to HotSpot initialization code, particularly things that change > > > > the order in which classes are initialized. Can you make the early > > > > call to initialize_class(vmSymbols::java_lang_Class()) JFR-only? > > > > > > I can try that. Let me get back with the result. > > > > I put the early java_lang_Class initialization in `#if INCLUDE_JFR` > > block. The original java_lang_Class initialization location was > > enclosed in an inverted `#if INCLUDE_JFR` block to ensure the original > > behaviour if JFR is not enabled in build config. > > > > Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/hotspot/webrev.02/ > > > > Thanks, > > > > -JB- > > > > > > > > -JB- > > > > > > > > > > > -- > > > > 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 > > > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From aph at redhat.com Tue May 26 14:22:59 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 May 2020 15:22:59 +0100 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: Message-ID: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> On 26/05/2020 13:59, Mario Torre wrote: > The patch looks good to me, just a minor nit (but I don't need a > re-review for this change) is to check the indentation of the > preprocessor: > > + #if INCLUDE_JFR > + // The VM creates & returns objects of this class. Make sure it's > initialized. > + initialize_class(vmSymbols::java_lang_Class(), CHECK_0); > + #endif > > Should indent at beginning of the line, like: > > +#if INCLUDE_JFR > + // The VM creates & returns objects of this class. Make sure it's > initialized. > + initialize_class(vmSymbols::java_lang_Class(), CHECK_0); > +#endif > > Likewise the block below that. > > We still need Andrew to approve before you can push though ;) It says here that "an agent can initialize JFR in response to the JVMTI VMStart event." Can't we test if this has in fact happened? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Tue May 26 21:25:15 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 26 May 2020 22:25:15 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> Message-ID: <4d056da6-a924-8927-f8f4-6da6fbe40952@redhat.com> On 26/05/2020 09:57, Andrew Dinn wrote: > Hi Andrew(s) > > On 25/05/2020 07:16, Andrew Hughes wrote: >> >> >> On 03/04/2020 10:18, Andrew Haley wrote: > . . . >>> Here is my reasoning. The need for stability and the minimization of >>> churn increases over time. People use JDK 8 because they want that >>> stability, and every patch carries some risk. So, ecause it is now a >>> mature piece of software, patches should be minimal where they >>> reasonably can. The practice of, by default, pulling in dependencies >>> from later releases is too risky: they might well be broken in ways >>> that the old version wasn't, and they may depend on other changes in >>> the recent code base. >>> >>> Now, that doesn't mean that such dependent changesets must *never* be >>> pulled in, especially when they are needed by several backports. But >>> if dependency changesets substantially multiply the size of a change, >>> as they do in this case, this should not be done. >>> >>> I am aware that this does not ease the life of the maintainers, but >>> that isn't the goal. Stability is. >> >> It's not about making life easier for maintainers; reviewing and >> approving more patches means the opposite. My concern is that the more >> 8u diverges from later versions, and uses its own bespoke version of >> fixes, the greater the knowledge and experience needed for someone to >> work on it. We're already struggling to keep up as it is. > > Well, that's one direction of travel. This is, however, a two way > street. The more jdk8u pulls in changes from later versions instead of > using its own bespoke version of fixes, the more likely it is that one > of those changes is going to be based on assumptions baked into the > upstream repo code that clash with assumptions baked into jdk8u repo > code. Understanding why something is breaking the jdk8u rules and how > that can be squared with what the the rest of the jdk8u code does is an > equal peril. > > The danger is subtle errors where we fall foul of races, corner cases, > re-orderings of control or synchronization, different interpretation of > the same values in the same flags, counters or object fields. The > problems that may arise in this way cannot really easily be avoided by > adapting a patch as it is backported, even less so by pulling in more > patches. The obvious safeguards that are provided by getting the code to > compile and pass tests won't remove this sort of risk. The only way to > avoid those errors as you pull in ever more changes is to backport > everything so that the design decisions that constrain how jdk8u > operates have all been replaced with the upstream ones. However, that's > clearly not the destination we need to aim for. > > None of these complex, subtle risks can be avoided via a simple, > mechanical process. All of them require the application of careful > judgement and a deep knowledge of the code bases involved. The more > releases there are between the original version of a patch and it's > application downstream the more thinking there needs to be. Given enough > distance (and with many patches we have more than enough distance even > between jdk11u and jdk8u) we can no longer afford to proceed by tweaking > an upstream patch, even less so by pulling in all the apparatus it > depends on. We have to think about the bug (or perf issue), think about > what that bug means in the context of jdk8u and then think about > designing a patch that fixes it from the point of view of jdk8u. The > original patch /may/ do the job, or /may/ guide us to the right fix. > However, if the upstream patch is dependent on a lot of other changes > not present in jdk8u then that's a flashing red light saying that this > patch won't do and that a custom patch is a better, safer bet. > >> Each case has to be considered separately, according to risk and the >> changes involved. It's not a guarantee of stability to just not make >> changes. If it leads to the changes that are made to 8u being unique to >> that codebase, and not as widely tested as something that has been in >> later versions for years, we will introduce more 8u-specific bugs. In >> short, there is no easy answer and no one size fits all solution. > > Yes, that is right. However, I agree with Andrew that we need to have a > very healthy mistrust of any patch that requires us to pull other > changes in its wake. Upstream fixes may legitimately depend on other > upstream fixes because ... well, they were already there and, when > added, one can assume they were known to be necessary and safe in that > upstream context. Downstream fixes should normally only presume the > presence of such a dependency if there is a compelling need to have that > dependency /in its own right/. If not then the default assumption has to > be that a downstream fix should be sought without relying on that > upstream dependency. Pulling in multiple patches simply because that was > a legitimate upstream choice is a very slippery and dangerous slope. > > regards, > > > Andrew Dinn > ----------- > Completely agree. My aim was to balance what aph said, rather than suggest that we go to the other extreme. I also think we need to be very aware of the growing expertise needed to maintain 8u. Thank you for expanding on this in more detail. My experience of working on backports for 6u & 7u over the last decade or so suggests that no situation is ever the same as another. In one case, you may need to completely rewrite the fix (common with HotSpot, where there are often significant refactorings and major reworkings). In another, it may make sense to backport a dependent change, because it's low risk and very likely to be a dependency of other future changes (common with testing infrastructure) When I look a a proposed backport, I like to see that potential dependencies have been considered, even if it is then decided to work around them. My concern with the initial version of this patch was that it lifted a function from another fix, but without the accompanying changes that made use of that function. Thus, we ended up with a case where 8u had a mix of behaviour; the new cases in the backported patch would use the new function, while older cases didn't (in contrast to later OpenJDK versions). The final version we pushed backports less of the original patch and I feel is better for it. To end on a positive note, I'm glad to say we tend to have more information available to make these decisions these days than we have in the past, thanks to greater transparency and in particular, the vulnerability group. In the past, we have had to go the route of backporting more than would be desirable, simply because it is the safest way to ensure an issue is fixed, when you have little to no knowledge of the original problem. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mbalao at redhat.com Wed May 27 01:06:53 2020 From: mbalao at redhat.com (Martin Balao) Date: Tue, 26 May 2020 22:06:53 -0300 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation In-Reply-To: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> References: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> Message-ID: <66c2b78d-7624-b4ad-93d3-b401953014ed@redhat.com> On 5/21/20 10:23 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > Hi, A few comments below: ------------------------------------ * OutputRecord.java, introduced by 8196584 * d13Encrypt -> Should probably be removed. * d10Encrypt -> Should probably be removed. ------------------------------------ * OutputRecord.java / InputRecord.java * Not a big deal but I wonder if we should keep hook methods (such as initHandshaker, finishHandshaker, launchRetransmission, isEmpty, expectingFinishFlight) and their calls. Even though there would be no action because DTLSInputRecord and DTLSOutputRecord were removed, we can minimize code changes and perhaps avoid work in the future if used by other OutputRecord/InputRecord subclasses. On the other hand, it would be 'nop' code currently. I'm not sure, just raised this point to think loudly. Opinions here are welcomed. ------------------------------------ * SSLContextImpl.java * I understand that the comment "// Used for DTLS in server mode only." is probably wrong because this is defined in TLS 1.3 (section 4.2.2) and is not DTLS 1.3 specific -even though it makes more sense for UPD connections than TCP-. Looking into the code, seems to me that it is not only used in SunJSSE's DTLS 1.3 but could be used in TLS 1.3. However, that comment should be fixed in main line and then backported. Otherwise, we would be introducing an improvement that applies to main line in the update release first. This is for the same reason that we will keep the "// DTLS cookie exchange manager" related comment. ------------------------------------ * SSLEngineImpl.java deltaDsts -= dsts[i].remaining(); } - return new SSLEngineResult(status, hsStatus, deltaSrcs, deltaDsts, - ciphertext != null ? ciphertext.recordSN : -1L); + return new SSLEngineResult(status, hsStatus, deltaSrcs, deltaDsts); } private Ciphertext encode( You probably decided this change because 8043758 (not in JDK-8) is the one that introduces the SSLEngineResult public constructor that takes the sequenceNumber as the last argument. However, TLS 1.3 uses this constructor so it's not DTLS specific. This is obviously a problem because a public API is being modified. I need to understand the consequences of not providing this API (and the corresponding SSLEngineResult::sequenceNumber function counterpart). Please let me know of your thoughts on this point. ------------------------------------ * BaseSSLSocketImpl.java Why are those methods (introduced by 8040062) removed? ------------------------------------ * SSLConfiguration.java I'd only replace enableRetransmissions with 'false' and avoid other inferences -even if they look correct-. ------------------------------------ Thanks, Martin.- From aph at redhat.com Wed May 27 09:22:43 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2020 10:22:43 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <4d056da6-a924-8927-f8f4-6da6fbe40952@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> <4d056da6-a924-8927-f8f4-6da6fbe40952@redhat.com> Message-ID: On 26/05/2020 22:25, Andrew Hughes wrote: > > Completely agree. My aim was to balance what aph said, rather than > suggest that we go to the other extreme. > I also think we need to be very aware of the growing expertise > needed to maintain 8u. Thank you for expanding on this in more > detail. I'm very grateful for Andrew Dinn's reply. In particular I was startled by the idea that backporting dependent changes might in some way deskill the process, such that the knowledge and experience needed for someone to work on backports is reduced. > When I look a a proposed backport, I like to see that potential > dependencies have been considered, even if it is then decided to > work around them. Fair enough, consider them, but I will repeat a crucial part of what Andrew Dinn wrote: >> Downstream fixes should normally only presume the presence of such >> a dependency if there is a compelling need to have that dependency >> /in its own right/. If not then the default assumption has to be >> that a downstream fix should be sought without relying on that >> upstream dependency. A direct consequence of this is that backporting a dependency has to be justified in a strong way: it should be needed. > My experience of working on backports for 6u & 7u over the last > decade or so suggests that no situation is ever the same as > another. In one case, you may need to completely rewrite the fix > (common with HotSpot, where there are often significant refactorings > and major reworkings). In another, it may make sense to backport a > dependent change, because it's low risk and very likely to be a > dependency of other future changes (common with testing > infrastructure) It is not appropriate to import dependent patches simply because they might be needed by future patches or in order to reduce the divergence between 8u and trunk. I'm happy enough with this for test code, but not for changes to the runtime code. I'm aware that this constitutes a change to the way that maintenance of JDK updates has been done for some time. However, as JDK 8u matures it is a necessary change. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alexey at azul.com Wed May 27 09:30:05 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 09:30:05 +0000 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation In-Reply-To: <66c2b78d-7624-b4ad-93d3-b401953014ed@redhat.com> References: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> <66c2b78d-7624-b4ad-93d3-b401953014ed@redhat.com> Message-ID: <0B0C36F2-5BF7-40E7-8CC9-12B13CADAA4F@azul.com> Hello Martin, Thank you very much for your great work on this reviews. Please see my comments below and find updated webrev at : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245469/webrev.v1/ Regards Alexey > On 27 May 2020, at 04:06, Martin Balao wrote: > > On 5/21/20 10:23 AM, Alexey Bakhtin wrote: >> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u >> > > Hi, > > A few comments below: > > ------------------------------------ > > * OutputRecord.java, introduced by 8196584 > * d13Encrypt -> Should probably be removed. > * d10Encrypt -> Should probably be removed. > Thank you. You are right. This methods no make sense any more - removed. > ------------------------------------ > > * OutputRecord.java / InputRecord.java > > * Not a big deal but I wonder if we should keep hook methods (such as > initHandshaker, finishHandshaker, launchRetransmission, isEmpty, > expectingFinishFlight) and their calls. Even though there would be no > action because DTLSInputRecord and DTLSOutputRecord were removed, we can > minimize code changes and perhaps avoid work in the future if used by > other OutputRecord/InputRecord subclasses. On the other hand, it would > be 'nop' code currently. I'm not sure, just raised this point to think > loudly. Opinions here are welcomed. > I would suggest to remove these methods as it makes 8u code more cleaner and readable. > ------------------------------------ > > * SSLContextImpl.java > * I understand that the comment "// Used for DTLS in server mode > only." is probably wrong because this is defined in TLS 1.3 (section > 4.2.2) and is not DTLS 1.3 specific -even though it makes more sense for > UPD connections than TCP-. Looking into the code, seems to me that it is > not only used in SunJSSE's DTLS 1.3 but could be used in TLS 1.3. > However, that comment should be fixed in main line and then backported. > Otherwise, we would be introducing an improvement that applies to main > line in the update release first. This is for the same reason that we > will keep the "// DTLS cookie exchange manager" related comment. OK. I?ve reverted the comment and created a bug: https://bugs.openjdk.java.net/browse/JDK-8245937 > > ------------------------------------ > > * SSLEngineImpl.java > > deltaDsts -= dsts[i].remaining(); > } > > - return new SSLEngineResult(status, hsStatus, deltaSrcs, deltaDsts, > - ciphertext != null ? ciphertext.recordSN : -1L); > + return new SSLEngineResult(status, hsStatus, deltaSrcs, deltaDsts); > } > > private Ciphertext encode( > > You probably decided this change because 8043758 (not in JDK-8) is the > one that introduces the SSLEngineResult public constructor that takes > the sequenceNumber as the last argument. However, TLS 1.3 uses this > constructor so it's not DTLS specific. This is obviously a problem > because a public API is being modified. > > I need to understand the consequences of not providing this API (and the > corresponding SSLEngineResult::sequenceNumber function counterpart). > Please let me know of your thoughts on this point. In my understanding, DTLS messages over UDP could be reordered in case of received using SSLEngine unwrap() method. The sequence number in SSLEngineResult helps to restore the real sequence. > > ------------------------------------ > > * BaseSSLSocketImpl.java > > Why are those methods (introduced by 8040062) removed? These methods are implementation of java.net.Socket public API methods not available in the JDK8 You are right. These methods are not related to removal of DTLS protocol. These changes should go to the next patch JDK-8245470 Fixed The patch for JDK-8245470 will be updated later > > ------------------------------------ > > * SSLConfiguration.java > > I'd only replace enableRetransmissions with 'false' and avoid other > inferences -even if they look correct-. > It is similar to changes in the OutputRecord.java / InputRecord.java classes. If we leave enableRetransmissions in the code it could lead to misleading that retransmission could be enabled or used. I'd suggest to remove it. > ------------------------------------ > > Thanks, > Martin.- > From volker.simonis at gmail.com Wed May 27 10:35:03 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 May 2020 12:35:03 +0200 Subject: [8u] RFR : TLSv1.3 protocol support In-Reply-To: References: <07336f05-586a-f2e1-a5af-785277e8bbde@redhat.com> <0885E817-09BD-49EE-884B-7C27ABF5920F@azul.com> <555B5889-D687-42A4-9CAB-6B0C823FEE2A@azul.com> <9a891e38-eb26-bb32-57ea-57b886059ca3@redhat.com> <2e076ddc-77db-ba95-6b47-ec944499e495@redhat.com> <097d3267-45d5-52b8-aad3-ebec417d4cb9@redhat.com> <8E0A9C28-C170-49EA-BC92-C8466FC72036@azul.com> <441c7801-ffbd-d641-d9fe-76920a8caac8@redhat.com> <2B1C2D4B-8058-49A5-8E10-71B4284262BD@azul.com> <43bab359-69d5-c1d0-9a9d-f089f8a80bcd@redhat.com> <745EEBB4-2292-4ABB-8155-40E1119773F7@azul.com> Message-ID: Just for reference I post the umbrella task here which, as far as I can see, hasn't been mentioned: JDK-8245466: Backport TLSv1.3 protocol implementation https://bugs.openjdk.java.net/browse/JDK-8245466 This umbrella tasks contains the following 12 subtasks: 1. JDK-8245467: Remove 8u TLSv1.2 implementation files https://bugs.openjdk.java.net/browse/JDK-8245467 2. JDK-8245468: Add TLSv1.3 implementation classes from 11.0.7 https://bugs.openjdk.java.net/browse/JDK-8245468 3. JDK-8245469: Remove DTLS protocol implementation https://bugs.openjdk.java.net/browse/JDK-8245469 4. JDK-8245470: Fix JDK8 compatibility issues https://bugs.openjdk.java.net/browse/JDK-8245470 5. JDK-8245471: Revert JDK-8148188 https://bugs.openjdk.java.net/browse/JDK-8245471 6. JDK-8245472: Backport JDK-8038893 for TLSv1.3 https://bugs.openjdk.java.net/browse/JDK-8245472 7. JDK-8245473: OCSP stapling support https://bugs.openjdk.java.net/browse/JDK-8245473 8. JDK-8245474: Add TLS_KRB5 cipher suites support according to RFC-2712 https://bugs.openjdk.java.net/browse/JDK-8245474 9. JDK-8245476: Disable TLSv1.3 protocol in the ClientHello message by default https://bugs.openjdk.java.net/browse/JDK-8245476 10. JDK-8245477: Adjust TLS tests location https://bugs.openjdk.java.net/browse/JDK-8245477 11. JDK-8245653: Remove 8u TLS tests https://bugs.openjdk.java.net/browse/JDK-8245653 12. JDK-8245681: Add TLSv1.3 regression test from 11.0.7 https://bugs.openjdk.java.net/browse/JDK-8245681 Thanks a lot for sorting this out so far! Best regards, Volker On Thu, May 21, 2020 at 4:53 PM Alexey Bakhtin wrote: > > Hi Martin, > > Yes, the tests will be posted as a separate step, may be several steps for better review process. > I?m trying to adjust test location between JDK8 and JDK11. > For now you can use tests posted in the previous patches : > > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test/ > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/test.sslecc/ > http://cr.openjdk.java.net/~abakhtin/tls1.3/webrev.v5/step10/ > > Alexey > > > On 21 May 2020, at 17:42, Martin Balao wrote: > > > > Hi Alexey, > > > > This is very much appreciated. > > > > On 5/21/20 11:21 AM, Alexey Bakhtin wrote: > >> Review of the Step 3 is moved to thread [3] > > > > Just for reference, there is an off-by-one from [3] (which is Step 2). > > > > One question: will the test changes be handled as Step 9? > > > > Thanks, > > Martin.- > > > From neugens at redhat.com Wed May 27 11:44:33 2020 From: neugens at redhat.com (Mario Torre) Date: Wed, 27 May 2020 13:44:33 +0200 Subject: RFR: 8245167: Top package in method profiling shows "null" in JMC In-Reply-To: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com> References: <85c3d007-0c22-1aa5-6a8e-6f5374bf6f01@azul.com> Message-ID: Hi Andrey, I went through the patch and it looks good. As we discussed offline, I have doubts and concerns about the handling in "package_from_name" of packages that start with L but this is part of the original patch and not specific to the backport, so I think this should be handled upstream later and explore if there are indeed issues. I'm CC'ing Andrew Haley and Andrew Dinn to request the approval and a second eye if necessary. Cheers, Mario On Mon, May 18, 2020 at 12:30 PM Andrey Petushkov wrote: > > Dear All, > > please consider the following patch to add missing package information > into JFR backport > https://cr.openjdk.java.net/~apetushkov/8245167/ > > Originally the package info was omitted due to dependency on jigsaw > functionality and hence it was thought it's not much relevant for jdk8. > However it turns out it's widely used (e.g. by JMC). So it makes sense > to implement it in jdk8-specific way > > The author of the code is Aleksei Semenov > > Verified by JMC and jfr jtreg tests, including the fixed > jdk/jfr/event/runtime/TestClassLoadEvent > > Thanks, > Andrey > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From yan at azul.com Wed May 27 12:36:13 2020 From: yan at azul.com (Yuri Nesterenko) Date: Wed, 27 May 2020 15:36:13 +0300 Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues In-Reply-To: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com> References: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com> Message-ID: Hi Alexey, this one may be the easiest of them all. I read it and it looks good to me. Even 1.8d instead of PROVIDER_VER in JcceJse.java is OK: it would never change! Thank you! --yan On 21.05.2020 16:33, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > > This is the forth part of backport discussed in the thread [1] > > JBS task: https://bugs.openjdk.java.net/browse/JDK-8245470 > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245470/webrev.v0/ > > This patch fixes common build issues caused by changes related to using a class from another package or different language constructions. > Also, this patch includes changes in the HandshakeHash class caused by the absence of MessageDigestSpi2 interface in JDK8 > > The patch should be applied after the patch for JDK-8245469 > > [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011664.html > > Regards > Alexey > From mbalao at redhat.com Wed May 27 15:32:13 2020 From: mbalao at redhat.com (Martin Balao) Date: Wed, 27 May 2020 12:32:13 -0300 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation In-Reply-To: <0B0C36F2-5BF7-40E7-8CC9-12B13CADAA4F@azul.com> References: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> <66c2b78d-7624-b4ad-93d3-b401953014ed@redhat.com> <0B0C36F2-5BF7-40E7-8CC9-12B13CADAA4F@azul.com> Message-ID: <9388e8cc-66c5-84fc-2d48-7bcd9587a83a@redhat.com> Hi Alexey, On 5/27/20 6:30 AM, Alexey Bakhtin wrote: > Please see my comments below and find updated webrev at : > http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245469/webrev.v1/ Thanks. I'll reply inline below and then send a separate mail with my review. >> * OutputRecord.java / InputRecord.java >> >> * Not a big deal but I wonder if we should keep hook methods (such as >> initHandshaker, finishHandshaker, launchRetransmission, isEmpty, >> expectingFinishFlight) and their calls. Even though there would be no >> action because DTLSInputRecord and DTLSOutputRecord were removed, we can >> minimize code changes and perhaps avoid work in the future if used by >> other OutputRecord/InputRecord subclasses. On the other hand, it would >> be 'nop' code currently. I'm not sure, just raised this point to think >> loudly. Opinions here are welcomed. >> > > I would suggest to remove these methods as it makes 8u code more cleaner and readable. > See below. > > OK. I?ve reverted the comment and created a bug: > https://bugs.openjdk.java.net/browse/JDK-8245937 Thanks. > >> >> ------------------------------------ >> >> * SSLEngineImpl.java >> >> deltaDsts -= dsts[i].remaining(); >> } >> >> - return new SSLEngineResult(status, hsStatus, deltaSrcs, deltaDsts, >> - ciphertext != null ? ciphertext.recordSN : -1L); >> + return new SSLEngineResult(status, hsStatus, deltaSrcs, deltaDsts); >> } >> >> private Ciphertext encode( >> >> You probably decided this change because 8043758 (not in JDK-8) is the >> one that introduces the SSLEngineResult public constructor that takes >> the sequenceNumber as the last argument. However, TLS 1.3 uses this >> constructor so it's not DTLS specific. This is obviously a problem >> because a public API is being modified. >> >> I need to understand the consequences of not providing this API (and the >> corresponding SSLEngineResult::sequenceNumber function counterpart). >> Please let me know of your thoughts on this point. > > In my understanding, DTLS messages over UDP could be reordered in case of > received using SSLEngine unwrap() method. The sequence number in SSLEngineResult > helps to restore the real sequence. Okay, then we can conclude that this API won't be needed/used for TLS 1.3 SSLEngine. >> >> * SSLConfiguration.java >> >> I'd only replace enableRetransmissions with 'false' and avoid other >> inferences -even if they look correct-. >> > > It is similar to changes in the OutputRecord.java / InputRecord.java classes. > If we leave enableRetransmissions in the code it could lead to misleading that retransmission > could be enabled or used. > I'd suggest to remove it. Hmm.. yes, part of this comment is related to OutputRecord.java / InputRecord.java. I understand your point about cleaning up the code. But the other side of the argument is that we now have the burden of supporting 8u-specifics in future backports. In other words, if we have a conflict near this code -which is now more likely-, we will probably need to think about fragmentation again and why the code is different than in 11u. As said before, I see arguments on both sides and even though I'm a bit more inclined to keep the code as similar as possible, I'm okay if you want to go the remove way. Regards, Martin.- From gnu.andrew at redhat.com Wed May 27 18:06:18 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 19:06:18 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> <4d056da6-a924-8927-f8f4-6da6fbe40952@redhat.com> Message-ID: <60eec900-5c00-e6ab-8a1a-34b077bff94b@redhat.com> On 27/05/2020 10:22, Andrew Haley wrote: > On 26/05/2020 22:25, Andrew Hughes wrote: >> >> Completely agree. My aim was to balance what aph said, rather than >> suggest that we go to the other extreme. > >> I also think we need to be very aware of the growing expertise >> needed to maintain 8u. Thank you for expanding on this in more >> detail. > > I'm very grateful for Andrew Dinn's reply. In particular I was > startled by the idea that backporting dependent changes might in some > way deskill the process, such that the knowledge and experience needed > for someone to work on backports is reduced. I'd be startled too. I'm not aware of anyone suggesting such a thing. My point was that each bespoke 8u solution increases the amount of 8u-specific knowledge someone needs when approaching a backport. Specifically, if a fix was implemented differently in 8u, and their backport builds on top of this using assumptions that are true in later OpenJDK versions, they need to be aware of this and adjust the backport accordingly. It does not imply that backporting dependent changes somehow decreases the required baseline knowledge, simply that it doesn't increase it to the same extent. > >> When I look a a proposed backport, I like to see that potential >> dependencies have been considered, even if it is then decided to >> work around them. > > Fair enough, consider them, but I will repeat a crucial part of what > Andrew Dinn wrote: > >>> Downstream fixes should normally only presume the presence of such >>> a dependency if there is a compelling need to have that dependency >>> /in its own right/. If not then the default assumption has to be >>> that a downstream fix should be sought without relying on that >>> upstream dependency. > > A direct consequence of this is that backporting a dependency has to > be justified in a strong way: it should be needed. As I said, I don't disagree with this. You can't make such a judgement without considering what the potential backports are first. > >> My experience of working on backports for 6u & 7u over the last >> decade or so suggests that no situation is ever the same as >> another. In one case, you may need to completely rewrite the fix >> (common with HotSpot, where there are often significant refactorings >> and major reworkings). In another, it may make sense to backport a >> dependent change, because it's low risk and very likely to be a >> dependency of other future changes (common with testing >> infrastructure) > > It is not appropriate to import dependent patches simply because they > might be needed by future patches or in order to reduce the divergence > between 8u and trunk. I'm happy enough with this for test code, but > not for changes to the runtime code. Testing was exactly the example of this I gave above. > > I'm aware that this constitutes a change to the way that maintenance of > JDK updates has been done for some time. However, as JDK 8u matures > it is a necessary change. > Not that I'm aware of. I've certainly refused approval to backports before that I've felt are unnecessary and potentially disruptive. I'm struggling to see where we disagree here. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed May 27 18:12:23 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 19:12:23 +0100 Subject: [8u] RFR: 8229888: (zipfs) Updating an existing zip file does not preserve original permissions In-Reply-To: <7bb6c886-2435-2e83-2c89-007ae99f5028@redhat.com> References: <09d61305-07c1-d493-60af-7e96e0bfc7b3@redhat.com> <7366bd30-b282-656a-1c2e-0cc336f815ef@redhat.com> <7bb6c886-2435-2e83-2c89-007ae99f5028@redhat.com> Message-ID: <4c023da2-5510-340b-197a-0ee0b929a170@redhat.com> On 25/05/2020 20:48, Alex Kashchenko wrote: > On 04/04/2020 12:28 PM, Alex Kashchenko wrote: >> On 04/02/2020 04:46 AM, Andrew Hughes wrote: >>> On 26/03/2020 23:15, Alex Kashchenko wrote: >>>> Hi, >>>> >>>> Please review the backport of JDK-8229888 to 8u: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229888 >>>> >>>> Original review thread: >>>> http://mail.openjdk.java.net/pipermail/nio-dev/2019-December/006894.html >>>> >>>> >>>> 11u changeset: >>>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/57fd597352b8 >>>> >>>> 8u webrev: http://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.00/ >>>> >>>> 8u patch is very close to 11u one: ZipFileSystem part is the same, test >>>> is changed to replace API not available in 8u, changes to policy file >>>> are not included. >>>> >>> >>> It would be helpful if you could explain why such changes had to be >>> made, rather than leaving the reviewer to guess. >>> >>> The test changes are fairly clear, though the replacement for Set.of, >>> createSet, returns a modifiable set, whereas of returns an unmodifiable >>> set. This doesn't really matter for a test case, but may in JDK code. >>> >>> It could also potentially be simplified to just: >>> >>> ???? private static Set createSet(Object... entries) { >>> ????Set set = new LinkedHashSet<>(Arrays.asList(entries)); >>> ????return Collections.unmodifiableSet(set); >>> ???? } >> >> Thanks for the review! I simplified this part of test removing >> createSet() helper: >> >> https://cr.openjdk.java.net/~akasko/jdk8u/8229888/webrev.01/ >> >>> >>> I'm not sure why the policy file change is unnecessary. I would guess >>> it's because the zipfs code is only demo code in 8u, but it would be >>> good to have more reassurance. >> >> AFAIU these changes to policy file are only necessary for jdk9+ with >> JPMS, some details on this policy change in jdk11: >> >> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002644.html >> >> >> https://mail.openjdk.java.net/pipermail/nio-dev/2019-March/005978.html > > Gentle reminder. > This was fine and went into b03: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011767.html Sorry, I thought I'd replied with a thumbs up before approving and pushing. That makes two e-mails that seem to have vanished into the ether around that time :/ -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed May 27 19:08:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 20:08:07 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko Message-ID: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates Committer. Alex is doing active backporting work for 8u [1], particularly with regard to Windows support. Making him a committer would aid this backporting work by avoiding the need for someone else to push his fixes. Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. Only current OpenJDK 8 Updates Committers (and above) [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. [0] https://openjdk.java.net/census#akasko [1] https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(akasko)+or+desc(%22akashche%40redhat.com%22))+and+not+merge() [2] http://openjdk.java.net/census#jdk8u [3] http://openjdk.java.net/projects/#committer-vote -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Wed May 27 19:09:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 27 May 2020 20:09:19 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko In-Reply-To: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> References: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> Message-ID: <9623c6a1-e8d0-9a3d-ec4c-8ce56cc60096@redhat.com> On 27/05/2020 20:08, Andrew Hughes wrote: > I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates > Committer. > > Alex is doing active backporting work for 8u [1], particularly with > regard to Windows support. Making him a committer would aid this > backporting work by avoiding the need for someone else to push his fixes. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK 8 Updates Committers (and above) [2] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] https://openjdk.java.net/census#akasko > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(akasko)+or+desc(%22akashche%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > Vote: Yes -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From stooke at redhat.com Wed May 27 19:20:14 2020 From: stooke at redhat.com (Simon Tooke) Date: Wed, 27 May 2020 15:20:14 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko In-Reply-To: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> References: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> Message-ID: <4c00115d-32da-726a-8a33-3012b5185c48@redhat.com> vote: yes. On 2020-05-27 3:08 p.m., Andrew Hughes wrote: > I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates > Committer. > > Alex is doing active backporting work for 8u [1], particularly with > regard to Windows support. Making him a committer would aid this > backporting work by avoiding the need for someone else to push his fixes. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK 8 Updates Committers (and above) [2] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] https://openjdk.java.net/census#akasko > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(akasko)+or+desc(%22akashche%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote From zgu at redhat.com Wed May 27 20:02:16 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 27 May 2020 16:02:16 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko In-Reply-To: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> References: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> Message-ID: <39c532f4-a5f1-a99b-9887-f4c3172e3490@redhat.com> Vote: yes -Zhengyu On 5/27/20 3:08 PM, Andrew Hughes wrote: > I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates > Committer. > > Alex is doing active backporting work for 8u [1], particularly with > regard to Windows support. Making him a committer would aid this > backporting work by avoiding the need for someone else to push his fixes. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK 8 Updates Committers (and above) [2] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] https://openjdk.java.net/census#akasko > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(akasko)+or+desc(%22akashche%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > From adinn at redhat.com Thu May 28 07:55:46 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 May 2020 08:55:46 +0100 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko In-Reply-To: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> References: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> Message-ID: <8e087d23-74d0-4596-b26c-0787180501e3@redhat.com> Vote: yes On 27/05/2020 20:08, Andrew Hughes wrote: > I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates > Committer. > > Alex is doing active backporting work for 8u [1], particularly with > regard to Windows support. Making him a committer would aid this > backporting work by avoiding the need for someone else to push his fixes. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK 8 Updates Committers (and above) [2] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] https://openjdk.java.net/census#akasko > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(akasko)+or+desc(%22akashche%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From gnu.andrew at redhat.com Thu May 28 08:29:39 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2020 09:29:39 +0100 Subject: OpenJDK 8u262-b04 EA Released Message-ID: I've made available an early access source bundle for 8u262, based on the tag jdk8u262-b04: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b04-ea.tar.xz The tarball is accompanied by a digital signature available at: https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b04-ea.tar.xz.sig This is signed by our new Red Hat OpenJDK key (openjdk at redhat.com): PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net) Fingerprint = CA5F 11C6 CE22 644D 42C6 AC44 92EF 8D39 DC13 168F SHA256 checksums: 29075eb0c88e978104223052f5e409bcc5ce8dfb88c8d1fb6b6310e23f425b18 openjdk8u262-b04-ea.tar.xz d2e04223fc1692bc20c27c0e5f4fe61edad1ae738a07095bc1ff6a2613a299de openjdk8u262-b04-ea.tar.xz.sig They are listed at https://openjdk-sources.osci.io/openjdk8/openjdk8u262-b04-ea.sha256 x86_64 binaries for GNU/Linux & Windows are available here, thanks to Severin Gehwolf: https://adoptopenjdk.net/upstream.html?variant=openjdk8&ga=ea Changes in 8u262-b04: - JDK-8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() - JDK-8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null - JDK-8076475: Misuses of strncpy/strncat - JDK-8148886: SEGV in sun.java2d.marlin.Renderer._endRendering - JDK-8171934: ObjectSizeCalculator.getEffectiveMemoryLayoutSpecification() does not recognize OpenJDK's HotSpot VM - JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE - JDK-8243539: Copyright info (Year) should be updated for fix of 8241638 - JDK-8244777: ClassLoaderStats VM Op uses constant hash value Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From adinn at redhat.com Thu May 28 08:31:08 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 May 2020 09:31:08 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <60eec900-5c00-e6ab-8a1a-34b077bff94b@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> <4d056da6-a924-8927-f8f4-6da6fbe40952@redhat.com> <60eec900-5c00-e6ab-8a1a-34b077bff94b@redhat.com> Message-ID: <3b9a68c1-f41b-63af-ce7e-74478cb2dcb6@redhat.com> On 27/05/2020 19:06, Andrew Hughes wrote: > I'm struggling to see where we disagree here. I think we are mostly disagreeing over emphasis -- which always risks straying into the arena of angels dancing on pinheads (or, to add a dash of Bertrand Russell to Rumsfeld's epistemological categories, unknowable unknowns -- which in epistemic terms implies a very pink-about-the-gills type of fish). Rather than enter that arena might I suggest we restate our agreement over, and *emphasize* for future reference, this one key maxim regarding backporting of dependent upstream fixes: Downstream fixes should normally only presume the presence of a dependent upstream fix if there is a compelling need to have that dependency /in its own right/. If not then the default assumption has to be that a downstream fix should be sought without relying on that upstream dependency. That's not absolute because we are all reasonable people and need to allow for and accept well reasoned arguments. However, it does mean pulling in extra patches needs to be provided with such good reasons (in an RFC thread). regards, Andrew Dinn ----------- From jaroslav.bachorik at datadoghq.com Thu May 28 09:08:02 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 28 May 2020 11:08:02 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> References: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> Message-ID: On Tue, May 26, 2020 at 4:23 PM Andrew Haley wrote: > > On 26/05/2020 13:59, Mario Torre wrote: > > The patch looks good to me, just a minor nit (but I don't need a > > re-review for this change) is to check the indentation of the > > preprocessor: > > > > + #if INCLUDE_JFR > > + // The VM creates & returns objects of this class. Make sure it's > > initialized. > > + initialize_class(vmSymbols::java_lang_Class(), CHECK_0); > > + #endif > > > > Should indent at beginning of the line, like: > > > > +#if INCLUDE_JFR > > + // The VM creates & returns objects of this class. Make sure it's > > initialized. > > + initialize_class(vmSymbols::java_lang_Class(), CHECK_0); > > +#endif > > > > Likewise the block below that. > > > > We still need Andrew to approve before you can push though ;) > > It says here that > > "an agent can initialize JFR in response to the JVMTI VMStart event." > > Can't we test if this has in fact happened? I guess so. But such a test is not a part of the original changeset. Is it necessary to be extending the scope of the original patch (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)? -JB- > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From adinn at redhat.com Thu May 28 10:06:38 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 28 May 2020 11:06:38 +0100 Subject: [8u] RFR 8225797: [backport] OldObjectSample event creates unexpected amount of checkpoint data In-Reply-To: <923950d4f0c4bd8e50ec02a79d43b87aa8014d6a.camel@redhat.com> References: <64ccf973-bb1f-420d-bea2-9254e0375602.denghui.ddh@alibaba-inc.com> <1e362a84-ffe7-4229-917b-4cf08bb6b67a.denghui.ddh@alibaba-inc.com> <8225cc35-fa62-4df2-b7a4-689b9f0726e6.> <0be06b28-6912-4f5d-84e5-5edf8833f92b.denghui.ddh@alibaba-inc.com> <4b66d9ea-6e80-47da-87f9-030da0a8845b.denghui.ddh@alibaba-inc.com> <923950d4f0c4bd8e50ec02a79d43b87aa8014d6a.camel@redhat.com> Message-ID: <8cb4655f-541d-653c-2c8c-05d5cb8e083e@redhat.com> Hi Denghui, On 13/05/2020 12:07, Mario Torre wrote: > On Wed, 2020-05-13 at 09:56 +0800, Denghui Dong wrote: >> Gentle ping? >> > > Hi Denghui, > > Sorry, the patch is really big so it's taking some time, but I asked > some help ;) This is a very complex patch which has been very hard to review. The difficulty is not just the obvious problem of the complexity of the code under modification. It is compounded by the fact that the diff algorithm used to construct the patch files has selected different 'match lines' when distinguishing the start and extent of jdk8u differences from those used to establish the start and extent of jdk11u differences. So, although the two patches mostly contain the same additions in the same order and the same deletions in the same order these additions and deletions are interleaved differently from one patch file to the other. That has made it very hard to subtract apparent changes which in reality turn out to be no-ops from the changes actually needed to make the jdk11u fix work on jdk8u. Also, retention/update of all the commented out code relating to modules and packages has not helped. I agree with Mario that this commented out code is best deleted (and arguably should have been in the initial backport). Retaining commented out code in a downstream repo in order to mark omissions from the upstream version is always going to be a losing game. It simply introduces noise and code/comment-rot into the process. It is much clearer and simpler to have no module-related code in the jdk8u repo and not have to review edits to commented out module code in backport patches. Arguably this problem could be handled as a separate issue -- there may well be commented out code blocks that are not updated by this patch. However, I'd like to see the process started here by ensuring that any commented out blocks that are updated or replaced with new commented code by the current patch are instead just replaced with nothing. Any remaining cleanup can happen later. Finally, while the set of .rej files linked in the original post does help to clarify locations where application the jdk11u patch to jdk8u was not straightforward that isn't really enough to explain 1) why the patch failed to apply and 2) what needed to be done to remedy the situation. I would very much prefer an account of both of those before accepting this patch. For example, was the failure down to a minor difference in layout, a failure to match because an upstream change was not present or a difference arising because of a disparity in design or features between the jdk8u and jdk11u JVMs. At the very least a few lines of explanation per .rej file would be helpful. That would allow me to make a much more confident assessment of the correctness of the backport and will also stand as a record of what was needed for later reference in case any problems arise when this goes into production use. On the plus side this change is pretty much self-contained, only really affecting the JFR code and, in particular, the leak analysis part of that code. So, whatever risk the lack of clarity over precisely what has been changed implies is /probably/ fairly tightly localized to users of JFR who enable leak analysis. Since that function is effectively broken anyway I'm not extremely concerned about allowing this patch to go into the release. I'd still like to see the rationale for the changes before agreeing that though. So, to sum up before this can be pushed I'd like to see 1) a revised patch with the commented out code deleted and 2) for each .rej file a summary of what was changed between jdk11u and jdk8u and why. I'll take another look once those are provided. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From asemenov at azul.com Thu May 28 12:19:05 2020 From: asemenov at azul.com (Aleksei Semenov) Date: Thu, 28 May 2020 12:19:05 +0000 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation Message-ID: <04c01ce5dbc24939bfe9f98ac97bd8e9@azul.com> On 5/21/20 10:23 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > Hi. I have discovered that copyright year is changed in a couple of files - CipherSuite.java and SSLEngineImpl.java. Imho, the change is not related to removing DTLS protocol and there is no sense to change the year only in these files. Thanks, Aleksei. From aph at redhat.com Thu May 28 12:34:39 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2020 13:34:39 +0100 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> Message-ID: <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com> On 28/05/2020 10:08, Jaroslav Bachor?k wrote: > I guess so. But such a test is not a part of the original changeset. > Is it necessary to be extending the scope of the original patch > (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)? Yes please. 8u is old code, and your first task is not to break it. If this involves being more defensive than upstream, that's fine. Class initialization order at startup is notoriously sensitive and responsible for breaking things in subtle ways. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Thu May 28 13:10:30 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2020 14:10:30 +0100 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com> References: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com> Message-ID: On 28/05/2020 13:34, Andrew Haley wrote: > On 28/05/2020 10:08, Jaroslav Bachor?k wrote: >> I guess so. But such a test is not a part of the original changeset. >> Is it necessary to be extending the scope of the original patch >> (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)? > > Yes please. 8u is old code, and your first task is not to break it. If > this involves being more defensive than upstream, that's fine. Class > initialization order at startup is notoriously sensitive and responsible > for breaking things in subtle ways. > There's also no reason such a change could not then be forwardported to later versions. If a bug is filed for this, the 8u fix can be committed under both 8233197 & the new ID, and then the test change alone posted for review in later versions. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu May 28 13:36:13 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2020 14:36:13 +0100 Subject: RFR: 8u: 8076475: Misuses of strncpy/strncat In-Reply-To: <3b9a68c1-f41b-63af-ce7e-74478cb2dcb6@redhat.com> References: <9cd4e59e-3036-2469-85cf-7c045e0d30cc@redhat.com> <97ba787e-2551-0d4f-20c6-4f77c66743b1@redhat.com> <6faa032b-4c08-8f50-f239-87f8b5b571a0@redhat.com> <19d143d5-7284-1f64-d2a0-3eb30dd2220c@redhat.com> <5eaf28fd-3bf5-fbc1-2288-a2c623719cd5@redhat.com> <4d056da6-a924-8927-f8f4-6da6fbe40952@redhat.com> <60eec900-5c00-e6ab-8a1a-34b077bff94b@redhat.com> <3b9a68c1-f41b-63af-ce7e-74478cb2dcb6@redhat.com> Message-ID: <4e244984-b596-65a1-0111-388322e01288@redhat.com> On 28/05/2020 09:31, Andrew Dinn wrote: > On 27/05/2020 19:06, Andrew Hughes wrote: > >> I'm struggling to see where we disagree here. > I think we are mostly disagreeing over emphasis -- which always risks > straying into the arena of angels dancing on pinheads (or, to add a dash > of Bertrand Russell to Rumsfeld's epistemological categories, unknowable > unknowns -- which in epistemic terms implies a very pink-about-the-gills > type of fish). > > Rather than enter that arena might I suggest we restate our agreement > over, and *emphasize* for future reference, this one key maxim regarding > backporting of dependent upstream fixes: > > Downstream fixes should normally only presume the presence of a > dependent upstream fix if there is a compelling need to have that > dependency /in its own right/. If not then the default assumption has to > be that a downstream fix should be sought without relying on that > upstream dependency. > > That's not absolute because we are all reasonable people and need to > allow for and accept well reasoned arguments. However, it does mean > pulling in extra patches needs to be provided with such good reasons (in > an RFC thread). > > regards, > > > Andrew Dinn > ----------- > No argument from me on that. My concern here has always been the stage prior to that; ensuring that the required research into the original context and any dependent fixes has taken place. Without knowing why the code is different, it is possible to miss implicit assumptions in the patch being backported. As you said, the bug and patch need to be considered in the context of 8u. To do that, you first need to understand the original context in which the fix was made. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu May 28 13:57:46 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2020 14:57:46 +0100 Subject: [8u] RFC: 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: References: Message-ID: <344b9a11-4c4e-fe60-665d-f66b1c97a06c@redhat.com> On 25/05/2020 20:48, Alex Kashchenko wrote: > Hi, > > I'd like to solicit comments and suggestions about the backport of > JDK-8172695 to 8u. > > Jira issue: https://bugs.openjdk.java.net/browse/JDK-8172695 > > There were a number of changes to ScanTest and to Scanner itself in 9+, > so to backport 8172695 cleanly the following issues need to be > backported as well: > > 8132206: move ScanTest.java into OpenJDK This is an obvious pre-requisite and more testing is almost always good. > 8132745: TEST_BUG: minor cleanup of java/util/Scanner/ScanTest.java Minor one-liner change to the new test, so fine. > 8072722: add stream support to Scanner [excluding public API changes] This is a feature so we should work around this if possible. Which later parts depend on this? > 8139414: java.util.Scanner hasNext() returns true, next() throws > NoSuchElementException This looks like a contained fix with virtue in its own right, but I'm concerned about changing established behaviour on 8u. The current behaviour is, however, a spec violation. > 8159545: closed/java/io/Console/TestConsole.java failed with exit code 1 > [not public, see: https://hg.openjdk.java.net/jdk/jdk/rev/e5d52546ba3a ] Looks like a follow-on to the last bug, but unhelpful being private > 8166261: Scanner.nextInt(int) (and similar methods) throws > PatternSyntaxException Changes the specification of public methods, so no. > 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if > English Locale unavailable > Test only change is fine. > What would be the preferred way to bring this to 8u? Is it better to > backport these changes one by one, or just take 8172695 and modify it > for 8u? Should bugfixes to Scanner itself (8139414 and 8166261) be > backported in latter case? > So 8132206, 8132745, 8139414, 8159545, 8186157 & 8172695. Most of those are test only changes and the two Scanner changes fix bugs with test cases that are viable backports in their own right. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From ebaron at redhat.com Thu May 28 14:05:30 2020 From: ebaron at redhat.com (Elliott Baron) Date: Thu, 28 May 2020 10:05:30 -0400 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko In-Reply-To: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> References: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> Message-ID: Vote: yes On 2020-05-27 3:08 p.m., Andrew Hughes wrote: > I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates > Committer. > > Alex is doing active backporting work for 8u [1], particularly with > regard to Windows support. Making him a committer would aid this > backporting work by avoiding the need for someone else to push his fixes. > > Votes are due by 19h00 UTC on Wednesday, the 10th of June, 2020. > > Only current OpenJDK 8 Updates Committers (and above) [2] are eligible > to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > [0] https://openjdk.java.net/census#akasko > [1] > https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/log?revcount=200&rev=(author(akasko)+or+desc(%22akashche%40redhat.com%22))+and+not+merge() > [2] http://openjdk.java.net/census#jdk8u > [3] http://openjdk.java.net/projects/#committer-vote > From abrygin at azul.com Thu May 28 15:11:50 2020 From: abrygin at azul.com (Andrew Brygin) Date: Thu, 28 May 2020 18:11:50 +0300 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation In-Reply-To: <9388e8cc-66c5-84fc-2d48-7bcd9587a83a@redhat.com> References: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> <66c2b78d-7624-b4ad-93d3-b401953014ed@redhat.com> <0B0C36F2-5BF7-40E7-8CC9-12B13CADAA4F@azul.com> <9388e8cc-66c5-84fc-2d48-7bcd9587a83a@redhat.com> Message-ID: Hello Martin, On 27/05/2020 18:32, Martin Balao wrote: > > On 5/27/20 6:30 AM, Alexey Bakhtin wrote: >> >> It is similar to changes in the OutputRecord.java / InputRecord.java classes. >> If we leave enableRetransmissions in the code it could lead to misleading that retransmission >> could be enabled or used. >> I'd suggest to remove it. > > Hmm.. yes, part of this comment is related to OutputRecord.java / > InputRecord.java. I understand your point about cleaning up the code. > But the other side of the argument is that we now have the burden of > supporting 8u-specifics in future backports. In other words, if we have > a conflict near this code -which is now more likely-, we will probably > need to think about fragmentation again and why the code is different > than in 11u. As said before, I see arguments on both sides and even > though I'm a bit more inclined to keep the code as similar as possible, > I'm okay if you want to go the remove way. > I would vote for the removal of the unused code. I understand the point that the similarity with 11u would make future backports more convenient in some cases. However, the implementations in 8u and 11u will be different anyway, and I think that the some decrease of fragmentation does not worth the risk of a misleading inducted by unused code. Thanks, Andrew From sgehwolf at redhat.com Thu May 28 15:15:11 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 28 May 2020 17:15:11 +0200 Subject: CFV: New OpenJDK 8 Updates Committer: Alex Kashchenko In-Reply-To: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> References: <3358d8c0-4944-7ff1-3042-12728c116c53@redhat.com> Message-ID: <6c70d9a24c4fd7551afb1ebc902d53cd9ca77d82.camel@redhat.com> Vote: yes On Wed, 2020-05-27 at 20:08 +0100, Andrew Hughes wrote: > I hereby nominate Alex Kashchenko (akasko) [0] to OpenJDK 8 Updates > Committer. From dcherepanov at azul.com Thu May 28 16:07:46 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 28 May 2020 19:07:46 +0300 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> Message-ID: <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> Hi Alexey, On 24.05.2020 21:05, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > > JBS task: https://bugs.openjdk.java.net/browse/JDK-8245681 > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v0/ > > This is a third part of TLS test update. When I tried to apply patches, I got conflicts in the last step. There are a lot of rejects due to the fact that new test files already exist. For example, the third part (of test update) adds new file - test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java which existed before and was moved by the first part (of test update)? from test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java to test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java Could you please double check that it's the latest version of webrev? Thanks Dmitry From jaroslav.bachorik at datadoghq.com Thu May 28 16:25:55 2020 From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=) Date: Thu, 28 May 2020 18:25:55 +0200 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com> Message-ID: On Thu, May 28, 2020 at 3:10 PM Andrew Hughes wrote: > > > > On 28/05/2020 13:34, Andrew Haley wrote: > > On 28/05/2020 10:08, Jaroslav Bachor?k wrote: > >> I guess so. But such a test is not a part of the original changeset. > >> Is it necessary to be extending the scope of the original patch > >> (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)? > > > > Yes please. 8u is old code, and your first task is not to break it. If > > this involves being more defensive than upstream, that's fine. Class > > initialization order at startup is notoriously sensitive and responsible > > for breaking things in subtle ways. > > > > There's also no reason such a change could not then be forwardported to > later versions. If a bug is filed for this, the 8u fix can be committed > under both 8233197 & the new ID, and then the test change alone posted > for review in later versions. Well, there might be a reason - there is no 'native test' support in JDK 8 AFAIK. There are not even any JVMTI native agent jtreg tests - so no harness for building a native agent (on all supported platforms). And to be honest, I don't feel like writing all that support from scratch. If I am missing something and there indeed is a support for testing JVMTI agents, please let me know and I will add a test. Thanks! -JB- > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From alexey at azul.com Thu May 28 16:56:01 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 28 May 2020 16:56:01 +0000 Subject: [8u] TLSv1.3 RFR: 8245681: Add TLSv1.3 regression test from 11.0.7 In-Reply-To: <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> References: <7D92607F-B8F0-4E84-B6C2-5E2AB4E42824@azul.com> <04f0d809-2f53-5335-9828-72b198bf369f@azul.com> Message-ID: Hello Dmitry, Yes, you are right. I?ve uploaded non-incremental webrev for the JDK-8245653 "Remove 8u TLS tests? by mistake. I?ve updated it in the same location : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245653/webrev.v0/ JDK-8245681 should be applied cleanly now Thank you Alexey > On 28 May 2020, at 19:07, Dmitry Cherepanov wrote: > > Hi Alexey, > > On 24.05.2020 21:05, Alexey Bakhtin wrote: >> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u >> >> JBS task: https://bugs.openjdk.java.net/browse/JDK-8245681 >> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245681/webrev.v0/ >> >> This is a third part of TLS test update. > > When I tried to apply patches, I got conflicts in the last step. There are a lot of rejects due to the fact that new test files already exist. > > For example, the third part (of test update) adds new file - test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java > which existed before and was moved by the first part (of test update) from test/sun/security/ssl/javax/net/ssl/ALPN/SSLEngineAlpnTest.java to test/javax/net/ssl/ALPN/SSLEngineAlpnTest.java > > Could you please double check that it's the latest version of webrev? > > Thanks > > Dmitry > From akashche at redhat.com Thu May 28 18:51:10 2020 From: akashche at redhat.com (Alex Kashchenko) Date: Thu, 28 May 2020 19:51:10 +0100 Subject: [8u] RFC: 8172695: (scanner) java/util/Scanner/ScanTest.java fails In-Reply-To: <344b9a11-4c4e-fe60-665d-f66b1c97a06c@redhat.com> References: <344b9a11-4c4e-fe60-665d-f66b1c97a06c@redhat.com> Message-ID: <9c830cd9-ba5d-5f9b-f464-c313cbfbcc44@redhat.com> Thanks for your comments! On 05/28/2020 02:57 PM, Andrew Hughes wrote: > On 25/05/2020 20:48, Alex Kashchenko wrote: >> Hi, >> >> I'd like to solicit comments and suggestions about the backport of >> JDK-8172695 to 8u. >> >> Jira issue: https://bugs.openjdk.java.net/browse/JDK-8172695 >> >> There were a number of changes to ScanTest and to Scanner itself in 9+, >> so to backport 8172695 cleanly the following issues need to be >> backported as well: >> >> 8132206: move ScanTest.java into OpenJDK > > This is an obvious pre-requisite and more testing is almost always good. > >> 8132745: TEST_BUG: minor cleanup of java/util/Scanner/ScanTest.java > > Minor one-liner change to the new test, so fine. > >> 8072722: add stream support to Scanner [excluding public API changes] > > This is a feature so we should work around this if possible. Which later > parts depend on this? This commit includes a cleanup to ScanTest: https://hg.openjdk.java.net/jdk/jdk/rev/174fd1116b9d#l2.1 The idea is to backport all changes to ScanTest, except streamCloseTest() and streamComodTest() methods. Changes to private methods of Scanner (excluding new public methods and spec changes) also may be included. 8139414 depends on some of these changes. >> 8139414: java.util.Scanner hasNext() returns true, next() throws >> NoSuchElementException > > This looks like a contained fix with virtue in its own right, but I'm > concerned about changing established behaviour on 8u. The current > behaviour is, however, a spec violation. > >> 8159545: closed/java/io/Console/TestConsole.java failed with exit code 1 >> [not public, see: https://hg.openjdk.java.net/jdk/jdk/rev/e5d52546ba3a ] > > Looks like a follow-on to the last bug, but unhelpful being private > >> 8166261: Scanner.nextInt(int) (and similar methods) throws >> PatternSyntaxException > > Changes the specification of public methods, so no. > >> 8186157: (scanner) Modify java/util/Scanner/ScanTest.java to fail if >> English Locale unavailable >> > > Test only change is fine. > >> What would be the preferred way to bring this to 8u? Is it better to >> backport these changes one by one, or just take 8172695 and modify it >> for 8u? Should bugfixes to Scanner itself (8139414 and 8166261) be >> backported in latter case? >> > > So 8132206, 8132745, 8139414, 8159545, 8186157 & 8172695. Most of those > are test only changes and the two Scanner changes fix bugs with test > cases that are viable backports in their own right. I'll proceed with backporting these changes. -- -Alex From dcherepanov at azul.com Thu May 28 19:08:45 2020 From: dcherepanov at azul.com (Dmitry Cherepanov) Date: Thu, 28 May 2020 22:08:45 +0300 Subject: [8u] TLSv1.3 RFR: 8245468: Add TLSv1.3 implementation classes from 11.0.7 In-Reply-To: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com> References: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com> Message-ID: On 21.05.2020 16:08, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > > This is the second part of backport discussed in the thread [1] > > JBS task: https://bugs.openjdk.java.net/browse/JDK-8245468 > Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245468/webrev.v0/ > > This patch adds TLSv1.3 implementation classes from 11.0.7 and fixes issues discussed in [2] When building 8u repo with all patched applied, I?m getting a build failure. ?/src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java:643: error: method does not override or implement a method from a supertype ??? @Override It looks like, as a part of this step, we automatically (and unintentionally?) included the patch for JDK-8040062 but it depends on new API added by JDK-8036979 (not in 8u). Thanks Dmitry From alexey at azul.com Thu May 28 19:37:22 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 28 May 2020 19:37:22 +0000 Subject: [8u] TLSv1.3 RFR: 8245468: Add TLSv1.3 implementation classes from 11.0.7 In-Reply-To: References: <73945910-57FE-4612-90DB-5E91F131EA07@azul.com> Message-ID: <599CBA8A-19D4-45D0-A173-09F916258999@azul.com> Hello Dmitry, Thank you for review. These methods of the BaseSSLSocketImpl class were initially removed in the first version of JDK-8245469 patch : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245469/webrev.v0/ As part of review findings [1], it was decided to move these modifications to JDK-8245470. I?ve updated JDK-8245469 webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245469/webrev.v1/ but do not update JDK-8245470 webrev yet. I planed to update it as part of JDK-8245470 review. To fix build issues you can just delete setOption / getOption / supportedOptions methods from the src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java [1] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011799.html Regards Alexey > On 28 May 2020, at 22:08, Dmitry Cherepanov wrote: > > On 21.05.2020 16:08, Alexey Bakhtin wrote: >> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u >> >> This is the second part of backport discussed in the thread [1] >> >> JBS task: https://bugs.openjdk.java.net/browse/JDK-8245468 >> Webrev: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245468/webrev.v0/ >> >> This patch adds TLSv1.3 implementation classes from 11.0.7 and fixes issues discussed in [2] > > When building 8u repo with all patched applied, I?m getting a build failure. > > ?/src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java:643: error: method does not override or implement a method from a supertype > @Override > > It looks like, as a part of this step, we automatically (and unintentionally?) included the patch for JDK-8040062 but it depends on new API added by JDK-8036979 (not in 8u). > > Thanks > > Dmitry > > From mbalao at redhat.com Fri May 29 03:51:27 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 29 May 2020 00:51:27 -0300 Subject: [8u] TLSv1.3 RFR: 8245469: Remove DTLS protocol implementation In-Reply-To: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> References: <568DF894-DA5A-4EC9-B643-B2EB1351F9DE@azul.com> Message-ID: <640d169f-432c-092b-a011-23c8465059de@redhat.com> On 5/21/20 10:23 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > Hi, The reason why we need 8245469 (Step 2) is because TLS files added to sun/security/ssl as part of 8245468 (Step 1) include changes from "JEP 219: Datagram Transport Layer Security (DTLS)" 8043758 [1]. JEP 219 (pushed to main line [2] previous to 8196584 [3]) involves specification changes and will not be backported to JDK-8 at this time. 8245469 (Step 2) should be a revert of the changes introduced by 8043758 (and follow up patches, including 8196584) but limited to sun/security/ssl directory (because 8245468 did not add files in other directories). A few easy checks first: * No files should be added * Ok * No files out of sun/security/ssl should be added, deleted or modified * Ok * Files deleted by 8043758 should not be present after 8245469 (Step 2) * classes/sun/security/ssl/EngineArgs.java * classes/sun/security/ssl/EngineInputRecord.java * classes/sun/security/ssl/EngineOutputRecord.java * classes/sun/security/ssl/EngineWriter.java * Ok * There shouldn't be any "dtls" (case insensitive) words in sun/security/ssl * Ok, exceptions are correct. * There shouldn't be any file named with "dtls" (case insensitive) in sun/security/ssl * Ok The strategy to review this change is as follows: 1) Go through the list of files added or modified by 8043758 and manually verify how changes on those files are reverted by 8245469 (Step 2). Analyzing how a change is reverted is an involved task because there are changes introduced by 8043758 which are essential for 8196584 and should not be reverted. On the other hand, 8196584 (or any other patch after 8043758) may refactor code and "re-introduce" DTLS changes in places different than where 8043758 originally affected. This is how I'll proceed: have a look at the change in 8043758, see if it's reverted by 8196584 or refactored and moved to a different place, see how 8245469 deals with it, grep in the actual file for "DTLS", "(D)TLS" and "HELLO_VERIFY" words (case insensitive and all possible variations) as the last check. It's not feasible to manually analyze all other patches manually in the time constraints we have: that's a risk I'll take here. The other risk is that going through these changes without considering the whole TLS engine context may me loose sight of what's going on semantically. There are two factors that work as a mitigation to some extent: 1) code compilation (if there were a symbol reference not satisfied, the compiler would catch it), 2) DTLS-specific code is usually protected under "if" clauses (so even if a trace is left, may be dead code not compromising functionality, CPU performance or security). 2) Verify that 8245469 (Step 2) includes nothing else or that any other inclusions are justified. Here we go with #1: * classes/sun/security/ssl/AppInputStream.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/AppOutputStream.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/Authenticator.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/CipherBox.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/CipherSuite.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/Ciphertext.java (new) * Change by change manual analysis. * Ok * classes/sun/security/ssl/ClientAuthType.java (new) * Change by change manual analysis. * Ok * classes/sun/security/ssl/ClientHandshaker.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/DTLSInputRecord.java (new) * File deleted. Deletion makes sense as all code here is DTLS specific. * Ok * classes/sun/security/ssl/DTLSOutputRecord.java (new) * File deleted. Deletion makes sense as all code here is DTLS specific. * Ok * classes/sun/security/ssl/DTLSRecord.java (new) * File deleted. Deletion makes sense as all code here is DTLS specific. * Ok * classes/sun/security/ssl/Debug.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/HandshakeHash.java (modified) * Change by change manual analysis. * I'm okay with removing the reference to SSLHandshake.HELLO_VERIFY_REQUEST.id. Good catch! * Ok * classes/sun/security/ssl/HandshakeInStream.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/HandshakeMessage.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/HandshakeOutStream.java (modified) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/HandshakeStateManager.java (new) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/Handshaker.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/HelloCookieManager.java (new) * Change by change manual analysis. * Ok * classes/sun/security/ssl/HelloExtensions.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/InputRecord.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/MAC.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/MaxFragmentLengthExtension.java (new) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/OutputRecord.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/Plaintext.java (new) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/ProtocolList.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/ProtocolVersion.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/RSAClientKeyExchange.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/RandomCookie.java (modified) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/Record.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/RecordType.java (new) * Added by 8043758 but removed by 8180856, so 8245469 did not have the necessity of removing it. * Ok * classes/sun/security/ssl/SSLContextImpl.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/SSLEngineImpl.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/SSLEngineInputRecord.java (new) * Change by change manual analysis. * Ok * classes/sun/security/ssl/SSLEngineOutputRecord.java (new) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/SSLRecord.java (new) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/SSLServerSocketImpl.java (modified) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/SSLSessionImpl.java (modified) * Change by change manual analysis. * Ok * classes/sun/security/ssl/SSLSocketImpl.java (modified) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/SSLSocketInputRecord.java (new) * Change by change manual analysis. * Ok * classes/sun/security/ssl/SSLSocketOutputRecord.java (new) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/ServerHandshaker.java (modified) * Changes introduced by 8043758. Completely deleted by 8196584. No traces in 8245469. File does not exist after 8245469. * Ok * classes/sun/security/ssl/SunJSSE.java (modified) * DTLS changes not added by 8245468. * Ok * classes/sun/security/ssl/X509KeyManagerImpl.java (modified) * Change by change manual analysis. No changes required for 8245469. * Ok * classes/sun/security/ssl/X509TrustManagerImpl.java (modified) * Change by change manual analysis. No changes required for 8245469. * Ok Here we go with #2: * classes/sun/security/ssl/Alert.java (modified) * Ok * classes/sun/security/ssl/BaseSSLSocketImpl.java (modified) * Ok, after deleted methods were re-introduced for v1. * classes/sun/security/ssl/CipherType.java (modified) * Ok * classes/sun/security/ssl/ClientHello.java (modified) * Ok * classes/sun/security/ssl/ConnectionContext.java (modified) * Ok * classes/sun/security/ssl/ContentType.java (modified) * Ok * classes/sun/security/ssl/Finished.java (modified) * Ok * classes/sun/security/ssl/HelloVerifyRequest.java (deleted) * Ok * classes/sun/security/ssl/MaxFragExtension.java (modified) * Ok * classes/sun/security/ssl/SSLCipher.java (modified) * Ok * classes/sun/security/ssl/SSLConfiguration.java (modified) * Ok * classes/sun/security/ssl/SSLExtensions.java (modified) * Ok * classes/sun/security/ssl/SSLHandshake.java (modified) * Ok * classes/sun/security/ssl/SSLKeyExchange.java (modified) * Ok * classes/sun/security/ssl/SSLMasterKeyDerivation.java (modified) * Ok * classes/sun/security/ssl/SSLTrafficKeyDerivation.java (modified) * Ok * classes/sun/security/ssl/SSLTransport.java (modified) * Ok * classes/sun/security/ssl/ServerHello.java (modified) * Ok * classes/sun/security/ssl/StatusResponseManager.java (modified) * Ok * classes/sun/security/ssl/TransportContext.java (modified) * Ok Note: there are previous comments -part of this review- here [4] [5]. With that said, 8245469 (Step 2) v1 looks good to me. Please hold the push until the whole series is review-approved and maintainer-approved. Thanks, Martin.- -- [1] - https://bugs.openjdk.java.net/browse/JDK-8043758 [2] - https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6721ff11d592 [3] - https://bugs.openjdk.java.net/browse/JDK-8196584 [4] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011797.html [5] - https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-May/011803.html From aph at redhat.com Fri May 29 08:58:07 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 May 2020 09:58:07 +0100 Subject: [8u] RFR 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing In-Reply-To: References: <9b771cf1-9e4a-3047-47fe-b8574d916b17@redhat.com> <9d9768ab-acaa-4ec8-0a79-6867b5aff292@redhat.com> Message-ID: <231de1ec-ab25-4fb8-bf59-345190f8540a@redhat.com> On 28/05/2020 17:25, Jaroslav Bachor?k wrote: > On Thu, May 28, 2020 at 3:10 PM Andrew Hughes wrote: >> >> >> >> On 28/05/2020 13:34, Andrew Haley wrote: >>> On 28/05/2020 10:08, Jaroslav Bachor?k wrote: >>>> I guess so. But such a test is not a part of the original changeset. >>>> Is it necessary to be extending the scope of the original patch >>>> (https://hg.openjdk.java.net/jdk/jdk/rev/127ca611f19b)? >>> >>> Yes please. 8u is old code, and your first task is not to break it. If >>> this involves being more defensive than upstream, that's fine. Class >>> initialization order at startup is notoriously sensitive and responsible >>> for breaking things in subtle ways. >> >> There's also no reason such a change could not then be forwardported to >> later versions. If a bug is filed for this, the 8u fix can be committed >> under both 8233197 & the new ID, and then the test change alone posted >> for review in later versions. > > Well, there might be a reason - there is no 'native test' support in > JDK 8 AFAIK. There are not even any JVMTI native agent jtreg tests - > so no harness for building a native agent (on all supported > platforms). And to be honest, I don't feel like writing all that > support from scratch. If I am missing something and there indeed is a > support for testing JVMTI agents, please let me know and I will add a > test. No problem. Like I said, there's no reason that 8u shouldn't have this even when upstream doesn't, and there's a very good reason we need it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mbalao at redhat.com Fri May 29 18:41:16 2020 From: mbalao at redhat.com (Martin Balao) Date: Fri, 29 May 2020 15:41:16 -0300 Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues In-Reply-To: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com> References: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com> Message-ID: <13d50c06-6c26-2f78-9d09-0408b7725b6e@redhat.com> On 5/21/20 10:33 AM, Alexey Bakhtin wrote: > Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u > Hi, A few questions and comments below: * I found several compilation errors. Isn't Step 3 supposed to be the one that makes the code compile in JDK-8? In case it's not, I wish you could clarify what are the expectations for Step 3 and where are will these errors be addressed. * HandshakeContext.java Why is casting needed in JDK-8 and not needed in JDK-11? (I was going to check this myself compiling but found several compilation errors, and I do not realize of the difference looking at the ByteBuffer API only). I guess this question applies to SSLCipher.java, SSLSocketInputRecord.java and SSLEngineInputRecord.java too. * HandshakeHash.java This does not look good to me because we are loosing functionality that was available in JDK-8 and is available in JDK-11. In particular, for P11 sensitive keys we cannot extract the key bytes in plain (keyBytes will be null indeed), but we can still use PKCS#11 primitives to get the key digest [1]. In JDK-8, this was available here [2] [3]. Have you considered using the JDK-11 MessageDigestSpi2 + Delegate approach? Shouldn't involve any new public API [4]. * JsseJce.java Have you considered backporting SecurityConstants.java part of 8130181 [5] and use PROVIDER_VER in JsseJce.java * SSLLogger.java Can't we leverage on PlatformLogger values directly? For each value, there should be a corresponding one. In case there is a good reason why not, we might want to think of moving the code to a more reusable place. * RandomCookie.java / RenegoInfoExtension.java Have you analyzed the performance implication of not having vectorized / intrinsics for the comparison? * SSLSessionContextImpl.java Can't we use GetPropertyAction::privilegedGetProperty? * X509TrustManagerImpl.java Why is this change needed? Thanks, Martin.- -- [1] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c0dd958bb895/src/share/classes/sun/security/pkcs11/P11Digest.java#l236 [2] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c0dd958bb895/src/share/classes/sun/security/ssl/HandshakeMessage.java#l1738 [3] - http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c0dd958bb895/src/share/classes/sun/security/ssl/HandshakeMessage.java#l1784 [4] - https://bugs.openjdk.java.net/browse/JDK-8165275 [5] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6c96af8a34b2#l12.1 From jonathanjoo at google.com Fri May 29 22:11:19 2020 From: jonathanjoo at google.com (Jonathan Joo) Date: Fri, 29 May 2020 18:11:19 -0400 Subject: Backport of JDK-8178374 to jdk8u Message-ID: Hello, first time contributor to OpenJDK here. I have a backport for JDK-8178374 available for jdk8u. Below is the diff - it has been built and tested on a local jdk8u build. Please let me know if you would like any context/info about this patch. Note that I did have to change the paths from the original fix to work with the jdk8u branch structure, but the code itself was a clean merge. Thank you, ~ Jonathan ------------ diff --git a/src/share/classes/javax/crypto/CipherSpi.java b/src/share/classes/javax/crypto/CipherSpi.java --- a/src/share/classes/javax/crypto/CipherSpi.java +++ b/src/share/classes/javax/crypto/CipherSpi.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -755,6 +755,7 @@ public abstract class CipherSpi { return 0; } int outLenNeeded = engineGetOutputSize(inLen); + if (output.remaining() < outLenNeeded) { throw new ShortBufferException("Need at least " + outLenNeeded + " bytes of space in output buffer"); @@ -762,98 +763,77 @@ public abstract class CipherSpi { boolean a1 = input.hasArray(); boolean a2 = output.hasArray(); - - if (a1 && a2) { - byte[] inArray = input.array(); - int inOfs = input.arrayOffset() + inPos; - byte[] outArray = output.array(); + int total = 0; + byte[] inArray, outArray; + if (a2) { // output has an accessible byte[] + outArray = output.array(); int outPos = output.position(); int outOfs = output.arrayOffset() + outPos; - int n; - if (isUpdate) { - n = engineUpdate(inArray, inOfs, inLen, outArray, outOfs); - } else { - n = engineDoFinal(inArray, inOfs, inLen, outArray, outOfs); - } - input.position(inLimit); - output.position(outPos + n); - return n; - } else if (!a1 && a2) { - int outPos = output.position(); - byte[] outArray = output.array(); - int outOfs = output.arrayOffset() + outPos; - byte[] inArray = new byte[getTempArraySize(inLen)]; - int total = 0; - do { - int chunk = Math.min(inLen, inArray.length); - if (chunk > 0) { - input.get(inArray, 0, chunk); + + if (a1) { // input also has an accessible byte[] + inArray = input.array(); + int inOfs = input.arrayOffset() + inPos; + if (isUpdate) { + total = engineUpdate(inArray, inOfs, inLen, outArray, outOfs); + } else { + total = engineDoFinal(inArray, inOfs, inLen, outArray, outOfs); } - int n; - if (isUpdate || (inLen != chunk)) { - n = engineUpdate(inArray, 0, chunk, outArray, outOfs); - } else { - n = engineDoFinal(inArray, 0, chunk, outArray, outOfs); - } - total += n; - outOfs += n; - inLen -= chunk; - } while (inLen > 0); - output.position(outPos + total); - return total; - } else { // output is not backed by an accessible byte[] - byte[] inArray; - int inOfs; - if (a1) { - inArray = input.array(); - inOfs = input.arrayOffset() + inPos; - } else { + input.position(inLimit); + } else { // input does not have accessible byte[] inArray = new byte[getTempArraySize(inLen)]; - inOfs = 0; + do { + int chunk = Math.min(inLen, inArray.length); + if (chunk > 0) { + input.get(inArray, 0, chunk); + } + int n; + if (isUpdate || (inLen > chunk)) { + n = engineUpdate(inArray, 0, chunk, outArray, outOfs); + } else { + n = engineDoFinal(inArray, 0, chunk, outArray, outOfs); + } + total += n; + outOfs += n; + inLen -= chunk; + } while (inLen > 0); } - byte[] outArray = new byte[getTempArraySize(outLenNeeded)]; - int outSize = outArray.length; - int total = 0; - boolean resized = false; - do { - int chunk = - Math.min(inLen, (outSize == 0? inArray.length : outSize)); - if (!a1 && !resized && chunk > 0) { - input.get(inArray, 0, chunk); - inOfs = 0; + output.position(outPos + total); + } else { // output does not have an accessible byte[] + if (a1) { // but input has an accessible byte[] + inArray = input.array(); + int inOfs = input.arrayOffset() + inPos; + if (isUpdate) { + outArray = engineUpdate(inArray, inOfs, inLen); + } else { + outArray = engineDoFinal(inArray, inOfs, inLen); + } + input.position(inLimit); + if (outArray != null && outArray.length != 0) { + output.put(outArray); + total = outArray.length; } - try { + } else { // input also does not have an accessible byte[] + inArray = new byte[getTempArraySize(inLen)]; + do { + int chunk = Math.min(inLen, inArray.length); + if (chunk > 0) { + input.get(inArray, 0, chunk); + } int n; - if (isUpdate || (inLen != chunk)) { - n = engineUpdate(inArray, inOfs, chunk, outArray, 0); + if (isUpdate || (inLen > chunk)) { + outArray = engineUpdate(inArray, 0, chunk); } else { - n = engineDoFinal(inArray, inOfs, chunk, outArray, 0); + outArray = engineDoFinal(inArray, 0, chunk); } - resized = false; - inOfs += chunk; + if (outArray != null && outArray.length != 0) { + output.put(outArray); + total += outArray.length; + } inLen -= chunk; - if (n > 0) { - output.put(outArray, 0, n); - total += n; - } - } catch (ShortBufferException e) { - if (resized) { - // we just resized the output buffer, but it still - // did not work. Bug in the provider, abort - throw (ProviderException)new ProviderException - ("Could not determine buffer size").initCause(e); - } - // output buffer is too small, realloc and try again - resized = true; - outSize = engineGetOutputSize(chunk); - outArray = new byte[outSize]; - } - } while (inLen > 0); - if (a1) { - input.position(inLimit); + } while (inLen > 0); } - return total; } + return total; } /** diff --git a/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java new file mode 100644 --- /dev/null +++ b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java @@ -0,0 +1,165 @@ +/* + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * @test + * @bug 8178374 + * @summary Test GCM decryption with various types of input/output + * ByteBuffer objects + * @key randomness + */ + +import java.nio.ByteBuffer; +import java.security.*; +import java.util.Random; + +import javax.crypto.Cipher; +import javax.crypto.SecretKey; +import javax.crypto.AEADBadTagException; +import javax.crypto.spec.*; + +public class TestGCMWithByteBuffer { + + private static Random random = new SecureRandom(); + private static int dataSize = 4096; // see javax.crypto.CipherSpi + private static int multiples = 3; + + public static void main(String args[]) throws Exception { + Provider[] provs = Security.getProviders(); + for (Provider p : provs) { + try { + Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding", p); + test(cipher); + } catch (NoSuchAlgorithmException nsae) { + // skip testing due to no support + continue; + } + } + } + + private static void test(Cipher cipher) throws Exception { + System.out.println("Testing " + cipher.getProvider()); + + boolean failedOnce = false; + Exception failedReason = null; + + int tagLen = 96; // in bits + byte[] keyBytes = new byte[16]; + random.nextBytes(keyBytes); + byte[] dataChunk = new byte[dataSize]; + random.nextBytes(dataChunk); + + SecretKey key = new SecretKeySpec(keyBytes, "AES"); + // re-use key bytes as IV as the real test is buffer calculation + GCMParameterSpec s = new GCMParameterSpec(tagLen, keyBytes); + + /* + * Iterate through various sizes to make sure that the code works with + * internal temp buffer size 4096. + */ + for (int t = 1; t <= multiples; t++) { + int size = t * dataSize; + + System.out.println("\nTesting data size: " + size); + + try { + decrypt(cipher, key, s, dataChunk, t, + ByteBuffer.allocate(dataSize), + ByteBuffer.allocate(size), + ByteBuffer.allocateDirect(dataSize), + ByteBuffer.allocateDirect(size)); + } catch (Exception e) { + System.out.println("\tFailed with data size " + size); + failedOnce = true; + failedReason = e; + } + } + if (failedOnce) { + throw failedReason; + } + System.out.println("\n=> Passed..."); + } + + private enum TestVariant { + HEAP_HEAP, HEAP_DIRECT, DIRECT_HEAP, DIRECT_DIRECT + }; + + private static void decrypt(Cipher cipher, SecretKey key, + GCMParameterSpec s, byte[] dataChunk, int multiples, + ByteBuffer heapIn, ByteBuffer heapOut, ByteBuffer directIn, + ByteBuffer directOut) throws Exception { + + ByteBuffer inBB = null; + ByteBuffer outBB = null; + + // try various combinations of input/output + for (TestVariant tv : TestVariant.values()) { + System.out.println(" " + tv); + + switch (tv) { + case HEAP_HEAP: + inBB = heapIn; + outBB = heapOut; + break; + case HEAP_DIRECT: + inBB = heapIn; + outBB = directOut; + break; + case DIRECT_HEAP: + inBB = directIn; + outBB = heapOut; + break; + case DIRECT_DIRECT: + inBB = directIn; + outBB = directOut; + break; + } + + // prepare input and output buffers + inBB.clear(); + inBB.put(dataChunk); + + outBB.clear(); + + try { + // Always re-init the Cipher object so cipher is in + // a good state for future testing + cipher.init(Cipher.DECRYPT_MODE, key, s); + + for (int i = 0; i < multiples; i++) { + inBB.flip(); + cipher.update(inBB, outBB); + if (inBB.hasRemaining()) { + throw new Exception("buffer not empty"); + } + } + // finish decryption and process all data buffered + cipher.doFinal(inBB, outBB); + throw new RuntimeException("Error: doFinal completed without exception"); + } catch (AEADBadTagException ex) { + System.out.println("Expected AEADBadTagException thrown"); + continue; + } + } + } +} From martinrb at google.com Fri May 29 23:03:09 2020 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 May 2020 16:03:09 -0700 Subject: Backport of JDK-8178374 to jdk8u In-Reply-To: References: Message-ID: I'll help my colleague Jonathan with this change. Jonathan, I had trouble applying this patch because line breaks were "helpfully" inserted e.g. + total = engineUpdate(inArray, inOfs, inLen, outArray, outOfs); Not sure which bit of software to blame. If you copy-paste ordinary text into a Plain text mode message, that ought to preserve the whitespace. From jonathanjoo at google.com Fri May 29 23:09:56 2020 From: jonathanjoo at google.com (Jonathan Joo) Date: Fri, 29 May 2020 19:09:56 -0400 Subject: Backport of JDK-8178374 to jdk8u In-Reply-To: References: Message-ID: Hmm, not sure why that happened. Does this work? (On my end the whitespace seems to be fine) ------- diff --git a/src/share/classes/javax/crypto/CipherSpi.java b/src/share/classes/javax/crypto/CipherSpi.java --- a/src/share/classes/javax/crypto/CipherSpi.java +++ b/src/share/classes/javax/crypto/CipherSpi.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -755,6 +755,7 @@ public abstract class CipherSpi { return 0; } int outLenNeeded = engineGetOutputSize(inLen); + if (output.remaining() < outLenNeeded) { throw new ShortBufferException("Need at least " + outLenNeeded + " bytes of space in output buffer"); @@ -762,98 +763,77 @@ public abstract class CipherSpi { boolean a1 = input.hasArray(); boolean a2 = output.hasArray(); - - if (a1 && a2) { - byte[] inArray = input.array(); - int inOfs = input.arrayOffset() + inPos; - byte[] outArray = output.array(); + int total = 0; + byte[] inArray, outArray; + if (a2) { // output has an accessible byte[] + outArray = output.array(); int outPos = output.position(); int outOfs = output.arrayOffset() + outPos; - int n; - if (isUpdate) { - n = engineUpdate(inArray, inOfs, inLen, outArray, outOfs); - } else { - n = engineDoFinal(inArray, inOfs, inLen, outArray, outOfs); - } - input.position(inLimit); - output.position(outPos + n); - return n; - } else if (!a1 && a2) { - int outPos = output.position(); - byte[] outArray = output.array(); - int outOfs = output.arrayOffset() + outPos; - byte[] inArray = new byte[getTempArraySize(inLen)]; - int total = 0; - do { - int chunk = Math.min(inLen, inArray.length); - if (chunk > 0) { - input.get(inArray, 0, chunk); + + if (a1) { // input also has an accessible byte[] + inArray = input.array(); + int inOfs = input.arrayOffset() + inPos; + if (isUpdate) { + total = engineUpdate(inArray, inOfs, inLen, outArray, outOfs); + } else { + total = engineDoFinal(inArray, inOfs, inLen, outArray, outOfs); } - int n; - if (isUpdate || (inLen != chunk)) { - n = engineUpdate(inArray, 0, chunk, outArray, outOfs); - } else { - n = engineDoFinal(inArray, 0, chunk, outArray, outOfs); - } - total += n; - outOfs += n; - inLen -= chunk; - } while (inLen > 0); - output.position(outPos + total); - return total; - } else { // output is not backed by an accessible byte[] - byte[] inArray; - int inOfs; - if (a1) { - inArray = input.array(); - inOfs = input.arrayOffset() + inPos; - } else { + input.position(inLimit); + } else { // input does not have accessible byte[] inArray = new byte[getTempArraySize(inLen)]; - inOfs = 0; + do { + int chunk = Math.min(inLen, inArray.length); + if (chunk > 0) { + input.get(inArray, 0, chunk); + } + int n; + if (isUpdate || (inLen > chunk)) { + n = engineUpdate(inArray, 0, chunk, outArray, outOfs); + } else { + n = engineDoFinal(inArray, 0, chunk, outArray, outOfs); + } + total += n; + outOfs += n; + inLen -= chunk; + } while (inLen > 0); } - byte[] outArray = new byte[getTempArraySize(outLenNeeded)]; - int outSize = outArray.length; - int total = 0; - boolean resized = false; - do { - int chunk = - Math.min(inLen, (outSize == 0? inArray.length : outSize)); - if (!a1 && !resized && chunk > 0) { - input.get(inArray, 0, chunk); - inOfs = 0; + output.position(outPos + total); + } else { // output does not have an accessible byte[] + if (a1) { // but input has an accessible byte[] + inArray = input.array(); + int inOfs = input.arrayOffset() + inPos; + if (isUpdate) { + outArray = engineUpdate(inArray, inOfs, inLen); + } else { + outArray = engineDoFinal(inArray, inOfs, inLen); + } + input.position(inLimit); + if (outArray != null && outArray.length != 0) { + output.put(outArray); + total = outArray.length; } - try { + } else { // input also does not have an accessible byte[] + inArray = new byte[getTempArraySize(inLen)]; + do { + int chunk = Math.min(inLen, inArray.length); + if (chunk > 0) { + input.get(inArray, 0, chunk); + } int n; - if (isUpdate || (inLen != chunk)) { - n = engineUpdate(inArray, inOfs, chunk, outArray, 0); + if (isUpdate || (inLen > chunk)) { + outArray = engineUpdate(inArray, 0, chunk); } else { - n = engineDoFinal(inArray, inOfs, chunk, outArray, 0); + outArray = engineDoFinal(inArray, 0, chunk); } - resized = false; - inOfs += chunk; + if (outArray != null && outArray.length != 0) { + output.put(outArray); + total += outArray.length; + } inLen -= chunk; - if (n > 0) { - output.put(outArray, 0, n); - total += n; - } - } catch (ShortBufferException e) { - if (resized) { - // we just resized the output buffer, but it still - // did not work. Bug in the provider, abort - throw (ProviderException)new ProviderException - ("Could not determine buffer size").initCause(e); - } - // output buffer is too small, realloc and try again - resized = true; - outSize = engineGetOutputSize(chunk); - outArray = new byte[outSize]; - } - } while (inLen > 0); - if (a1) { - input.position(inLimit); + } while (inLen > 0); } - return total; } + return total; } /** diff --git a/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java new file mode 100644 --- /dev/null +++ b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java @@ -0,0 +1,165 @@ +/* + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/** + * @test + * @bug 8178374 + * @summary Test GCM decryption with various types of input/output + * ByteBuffer objects + * @key randomness + */ + +import java.nio.ByteBuffer; +import java.security.*; +import java.util.Random; + +import javax.crypto.Cipher; +import javax.crypto.SecretKey; +import javax.crypto.AEADBadTagException; +import javax.crypto.spec.*; + +public class TestGCMWithByteBuffer { + + private static Random random = new SecureRandom(); + private static int dataSize = 4096; // see javax.crypto.CipherSpi + private static int multiples = 3; + + public static void main(String args[]) throws Exception { + Provider[] provs = Security.getProviders(); + for (Provider p : provs) { + try { + Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding", p); + test(cipher); + } catch (NoSuchAlgorithmException nsae) { + // skip testing due to no support + continue; + } + } + } + + private static void test(Cipher cipher) throws Exception { + System.out.println("Testing " + cipher.getProvider()); + + boolean failedOnce = false; + Exception failedReason = null; + + int tagLen = 96; // in bits + byte[] keyBytes = new byte[16]; + random.nextBytes(keyBytes); + byte[] dataChunk = new byte[dataSize]; + random.nextBytes(dataChunk); + + SecretKey key = new SecretKeySpec(keyBytes, "AES"); + // re-use key bytes as IV as the real test is buffer calculation + GCMParameterSpec s = new GCMParameterSpec(tagLen, keyBytes); + + /* + * Iterate through various sizes to make sure that the code works with + * internal temp buffer size 4096. + */ + for (int t = 1; t <= multiples; t++) { + int size = t * dataSize; + + System.out.println("\nTesting data size: " + size); + + try { + decrypt(cipher, key, s, dataChunk, t, + ByteBuffer.allocate(dataSize), + ByteBuffer.allocate(size), + ByteBuffer.allocateDirect(dataSize), + ByteBuffer.allocateDirect(size)); + } catch (Exception e) { + System.out.println("\tFailed with data size " + size); + failedOnce = true; + failedReason = e; + } + } + if (failedOnce) { + throw failedReason; + } + System.out.println("\n=> Passed..."); + } + + private enum TestVariant { + HEAP_HEAP, HEAP_DIRECT, DIRECT_HEAP, DIRECT_DIRECT + }; + + private static void decrypt(Cipher cipher, SecretKey key, + GCMParameterSpec s, byte[] dataChunk, int multiples, + ByteBuffer heapIn, ByteBuffer heapOut, ByteBuffer directIn, + ByteBuffer directOut) throws Exception { + + ByteBuffer inBB = null; + ByteBuffer outBB = null; + + // try various combinations of input/output + for (TestVariant tv : TestVariant.values()) { + System.out.println(" " + tv); + + switch (tv) { + case HEAP_HEAP: + inBB = heapIn; + outBB = heapOut; + break; + case HEAP_DIRECT: + inBB = heapIn; + outBB = directOut; + break; + case DIRECT_HEAP: + inBB = directIn; + outBB = heapOut; + break; + case DIRECT_DIRECT: + inBB = directIn; + outBB = directOut; + break; + } + + // prepare input and output buffers + inBB.clear(); + inBB.put(dataChunk); + + outBB.clear(); + + try { + // Always re-init the Cipher object so cipher is in + // a good state for future testing + cipher.init(Cipher.DECRYPT_MODE, key, s); + + for (int i = 0; i < multiples; i++) { + inBB.flip(); + cipher.update(inBB, outBB); + if (inBB.hasRemaining()) { + throw new Exception("buffer not empty"); + } + } + // finish decryption and process all data buffered + cipher.doFinal(inBB, outBB); + throw new RuntimeException("Error: doFinal completed without exception"); + } catch (AEADBadTagException ex) { + System.out.println("Expected AEADBadTagException thrown"); + continue; + } + } + } +} On Fri, May 29, 2020 at 7:03 PM Martin Buchholz wrote: > > I'll help my colleague Jonathan with this change. > > Jonathan, I had trouble applying this patch because line breaks were > "helpfully" inserted e.g. > > + total = engineUpdate(inArray, inOfs, inLen, > outArray, outOfs); > > Not sure which bit of software to blame. > If you copy-paste ordinary text into a Plain text mode message, that > ought to preserve the whitespace. From jonathanjoo at google.com Fri May 29 23:11:17 2020 From: jonathanjoo at google.com (Jonathan Joo) Date: Fri, 29 May 2020 19:11:17 -0400 Subject: Backport of JDK-8178374 to jdk8u In-Reply-To: References: Message-ID: I'm seeing that prior to sending my email (in plain text mode), the whitespace looks OK, but once I send it there seems to be problems.... On Fri, May 29, 2020 at 7:09 PM Jonathan Joo wrote: > > Hmm, not sure why that happened. Does this work? (On my end the > whitespace seems to be fine) > > ------- > > diff --git a/src/share/classes/javax/crypto/CipherSpi.java > b/src/share/classes/javax/crypto/CipherSpi.java > --- a/src/share/classes/javax/crypto/CipherSpi.java > +++ b/src/share/classes/javax/crypto/CipherSpi.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1997, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1997, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -755,6 +755,7 @@ public abstract class CipherSpi { > return 0; > } > int outLenNeeded = engineGetOutputSize(inLen); > + > if (output.remaining() < outLenNeeded) { > throw new ShortBufferException("Need at least " + outLenNeeded > + " bytes of space in output buffer"); > @@ -762,98 +763,77 @@ public abstract class CipherSpi { > > boolean a1 = input.hasArray(); > boolean a2 = output.hasArray(); > - > - if (a1 && a2) { > - byte[] inArray = input.array(); > - int inOfs = input.arrayOffset() + inPos; > - byte[] outArray = output.array(); > + int total = 0; > + byte[] inArray, outArray; > + if (a2) { // output has an accessible byte[] > + outArray = output.array(); > int outPos = output.position(); > int outOfs = output.arrayOffset() + outPos; > - int n; > - if (isUpdate) { > - n = engineUpdate(inArray, inOfs, inLen, outArray, outOfs); > - } else { > - n = engineDoFinal(inArray, inOfs, inLen, outArray, outOfs); > - } > - input.position(inLimit); > - output.position(outPos + n); > - return n; > - } else if (!a1 && a2) { > - int outPos = output.position(); > - byte[] outArray = output.array(); > - int outOfs = output.arrayOffset() + outPos; > - byte[] inArray = new byte[getTempArraySize(inLen)]; > - int total = 0; > - do { > - int chunk = Math.min(inLen, inArray.length); > - if (chunk > 0) { > - input.get(inArray, 0, chunk); > + > + if (a1) { // input also has an accessible byte[] > + inArray = input.array(); > + int inOfs = input.arrayOffset() + inPos; > + if (isUpdate) { > + total = engineUpdate(inArray, inOfs, inLen, > outArray, outOfs); > + } else { > + total = engineDoFinal(inArray, inOfs, inLen, > outArray, outOfs); > } > - int n; > - if (isUpdate || (inLen != chunk)) { > - n = engineUpdate(inArray, 0, chunk, outArray, outOfs); > - } else { > - n = engineDoFinal(inArray, 0, chunk, outArray, outOfs); > - } > - total += n; > - outOfs += n; > - inLen -= chunk; > - } while (inLen > 0); > - output.position(outPos + total); > - return total; > - } else { // output is not backed by an accessible byte[] > - byte[] inArray; > - int inOfs; > - if (a1) { > - inArray = input.array(); > - inOfs = input.arrayOffset() + inPos; > - } else { > + input.position(inLimit); > + } else { // input does not have accessible byte[] > inArray = new byte[getTempArraySize(inLen)]; > - inOfs = 0; > + do { > + int chunk = Math.min(inLen, inArray.length); > + if (chunk > 0) { > + input.get(inArray, 0, chunk); > + } > + int n; > + if (isUpdate || (inLen > chunk)) { > + n = engineUpdate(inArray, 0, chunk, outArray, outOfs); > + } else { > + n = engineDoFinal(inArray, 0, chunk, outArray, outOfs); > + } > + total += n; > + outOfs += n; > + inLen -= chunk; > + } while (inLen > 0); > } > - byte[] outArray = new byte[getTempArraySize(outLenNeeded)]; > - int outSize = outArray.length; > - int total = 0; > - boolean resized = false; > - do { > - int chunk = > - Math.min(inLen, (outSize == 0? inArray.length : outSize)); > - if (!a1 && !resized && chunk > 0) { > - input.get(inArray, 0, chunk); > - inOfs = 0; > + output.position(outPos + total); > + } else { // output does not have an accessible byte[] > + if (a1) { // but input has an accessible byte[] > + inArray = input.array(); > + int inOfs = input.arrayOffset() + inPos; > + if (isUpdate) { > + outArray = engineUpdate(inArray, inOfs, inLen); > + } else { > + outArray = engineDoFinal(inArray, inOfs, inLen); > + } > + input.position(inLimit); > + if (outArray != null && outArray.length != 0) { > + output.put(outArray); > + total = outArray.length; > } > - try { > + } else { // input also does not have an accessible byte[] > + inArray = new byte[getTempArraySize(inLen)]; > + do { > + int chunk = Math.min(inLen, inArray.length); > + if (chunk > 0) { > + input.get(inArray, 0, chunk); > + } > int n; > - if (isUpdate || (inLen != chunk)) { > - n = engineUpdate(inArray, inOfs, chunk, outArray, 0); > + if (isUpdate || (inLen > chunk)) { > + outArray = engineUpdate(inArray, 0, chunk); > } else { > - n = engineDoFinal(inArray, inOfs, chunk, outArray, 0); > + outArray = engineDoFinal(inArray, 0, chunk); > } > - resized = false; > - inOfs += chunk; > + if (outArray != null && outArray.length != 0) { > + output.put(outArray); > + total += outArray.length; > + } > inLen -= chunk; > - if (n > 0) { > - output.put(outArray, 0, n); > - total += n; > - } > - } catch (ShortBufferException e) { > - if (resized) { > - // we just resized the output buffer, but it still > - // did not work. Bug in the provider, abort > - throw (ProviderException)new ProviderException > - ("Could not determine buffer size").initCause(e); > - } > - // output buffer is too small, realloc and try again > - resized = true; > - outSize = engineGetOutputSize(chunk); > - outArray = new byte[outSize]; > - } > - } while (inLen > 0); > - if (a1) { > - input.position(inLimit); > + } while (inLen > 0); > } > - return total; > } > + return total; > } > > /** > diff --git a/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java > b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java > new file mode 100644 > --- /dev/null > +++ b/test/javax/crypto/CipherSpi/TestGCMWithByteBuffer.java > @@ -0,0 +1,165 @@ > +/* > + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/** > + * @test > + * @bug 8178374 > + * @summary Test GCM decryption with various types of input/output > + * ByteBuffer objects > + * @key randomness > + */ > + > +import java.nio.ByteBuffer; > +import java.security.*; > +import java.util.Random; > + > +import javax.crypto.Cipher; > +import javax.crypto.SecretKey; > +import javax.crypto.AEADBadTagException; > +import javax.crypto.spec.*; > + > +public class TestGCMWithByteBuffer { > + > + private static Random random = new SecureRandom(); > + private static int dataSize = 4096; // see javax.crypto.CipherSpi > + private static int multiples = 3; > + > + public static void main(String args[]) throws Exception { > + Provider[] provs = Security.getProviders(); > + for (Provider p : provs) { > + try { > + Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding", p); > + test(cipher); > + } catch (NoSuchAlgorithmException nsae) { > + // skip testing due to no support > + continue; > + } > + } > + } > + > + private static void test(Cipher cipher) throws Exception { > + System.out.println("Testing " + cipher.getProvider()); > + > + boolean failedOnce = false; > + Exception failedReason = null; > + > + int tagLen = 96; // in bits > + byte[] keyBytes = new byte[16]; > + random.nextBytes(keyBytes); > + byte[] dataChunk = new byte[dataSize]; > + random.nextBytes(dataChunk); > + > + SecretKey key = new SecretKeySpec(keyBytes, "AES"); > + // re-use key bytes as IV as the real test is buffer calculation > + GCMParameterSpec s = new GCMParameterSpec(tagLen, keyBytes); > + > + /* > + * Iterate through various sizes to make sure that the code works with > + * internal temp buffer size 4096. > + */ > + for (int t = 1; t <= multiples; t++) { > + int size = t * dataSize; > + > + System.out.println("\nTesting data size: " + size); > + > + try { > + decrypt(cipher, key, s, dataChunk, t, > + ByteBuffer.allocate(dataSize), > + ByteBuffer.allocate(size), > + ByteBuffer.allocateDirect(dataSize), > + ByteBuffer.allocateDirect(size)); > + } catch (Exception e) { > + System.out.println("\tFailed with data size " + size); > + failedOnce = true; > + failedReason = e; > + } > + } > + if (failedOnce) { > + throw failedReason; > + } > + System.out.println("\n=> Passed..."); > + } > + > + private enum TestVariant { > + HEAP_HEAP, HEAP_DIRECT, DIRECT_HEAP, DIRECT_DIRECT > + }; > + > + private static void decrypt(Cipher cipher, SecretKey key, > + GCMParameterSpec s, byte[] dataChunk, int multiples, > + ByteBuffer heapIn, ByteBuffer heapOut, ByteBuffer directIn, > + ByteBuffer directOut) throws Exception { > + > + ByteBuffer inBB = null; > + ByteBuffer outBB = null; > + > + // try various combinations of input/output > + for (TestVariant tv : TestVariant.values()) { > + System.out.println(" " + tv); > + > + switch (tv) { > + case HEAP_HEAP: > + inBB = heapIn; > + outBB = heapOut; > + break; > + case HEAP_DIRECT: > + inBB = heapIn; > + outBB = directOut; > + break; > + case DIRECT_HEAP: > + inBB = directIn; > + outBB = heapOut; > + break; > + case DIRECT_DIRECT: > + inBB = directIn; > + outBB = directOut; > + break; > + } > + > + // prepare input and output buffers > + inBB.clear(); > + inBB.put(dataChunk); > + > + outBB.clear(); > + > + try { > + // Always re-init the Cipher object so cipher is in > + // a good state for future testing > + cipher.init(Cipher.DECRYPT_MODE, key, s); > + > + for (int i = 0; i < multiples; i++) { > + inBB.flip(); > + cipher.update(inBB, outBB); > + if (inBB.hasRemaining()) { > + throw new Exception("buffer not empty"); > + } > + } > + // finish decryption and process all data buffered > + cipher.doFinal(inBB, outBB); > + throw new RuntimeException("Error: doFinal completed > without exception"); > + } catch (AEADBadTagException ex) { > + System.out.println("Expected AEADBadTagException thrown"); > + continue; > + } > + } > + } > +} > > On Fri, May 29, 2020 at 7:03 PM Martin Buchholz wrote: > > > > I'll help my colleague Jonathan with this change. > > > > Jonathan, I had trouble applying this patch because line breaks were > > "helpfully" inserted e.g. > > > > + total = engineUpdate(inArray, inOfs, inLen, > > outArray, outOfs); > > > > Not sure which bit of software to blame. > > If you copy-paste ordinary text into a Plain text mode message, that > > ought to preserve the whitespace. From martinrb at google.com Fri May 29 23:53:42 2020 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 May 2020 16:53:42 -0700 Subject: Backport of JDK-8178374 to jdk8u In-Reply-To: References: Message-ID: I removed the line breaks in the obvious way manually. I created a webrev for Jonathan's change here: http://cr.openjdk.java.net/~martin/webrevs/jdk8/backport-JDK-8178374/ Further work over at https://bugs.openjdk.java.net/browse/JDK-8178374 From alexey at azul.com Sat May 30 19:40:47 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Sat, 30 May 2020 19:40:47 +0000 Subject: [8u] TLSv1.3 RFR: 8245470: Fix JDK8 compatibility issues In-Reply-To: <13d50c06-6c26-2f78-9d09-0408b7725b6e@redhat.com> References: <28880149-F691-4B28-A900-96DD0A40CD9A@azul.com> <13d50c06-6c26-2f78-9d09-0408b7725b6e@redhat.com> Message-ID: <70AC9E7E-280D-412D-AA4C-A527DCC87165@azul.com> Hi Martin, Thank you very much for review and comments. Please see my comments below. Updated webrev : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245470/webrev.v1/ Regards Alexey > On 29 May 2020, at 21:41, Martin Balao wrote: > > On 5/21/20 10:33 AM, Alexey Bakhtin wrote: >> Please review changes required to backport TLSv1.3 protocol from JDK11.0.7 to JDK8u >> > > Hi, > > A few questions and comments below: > > * I found several compilation errors. Isn't Step 3 supposed to be the > one that makes the code compile in JDK-8? In case it's not, I wish you > could clarify what are the expectations for Step 3 and where are will > these errors be addressed. It was not supposed to make all classes compilable on this step A lot of classes will be changed in subsequent steps and I did not want to make double work: - Fix compilation errors in methods that will be changed in the next steps - Double task for reviewer : review changes that will be excluded later The name of the step could be misleading but at this step I just fixed general compilation errors. The known issues that fixed in later steps: - Finished.java Fixed in JDK-8245471: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245471/webrev.v0/ - KerberosClientKeyExchange.java krb5/KerberosClientKeyExchangeImpl.java and krb5/KerberosPreMasterSecret.java Fixed in JDK-8245474 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245474/webrev.v0/ - X509TrustManagerImpl.java Fixed in JDK-8245473 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245473/webrev.v0/ and JDK-8245472 : http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245472/webrev.v0/ > > * HandshakeContext.java > > Why is casting needed in JDK-8 and not needed in JDK-11? (I was going to > check this myself compiling but found several compilation errors, and I > do not realize of the difference looking at the ByteBuffer API only). I > guess this question applies to SSLCipher.java, SSLSocketInputRecord.java > and SSLEngineInputRecord.java too. Actually, I do not know Why JDK11 allows such downcasting without explicit cast > > * HandshakeHash.java > > This does not look good to me because we are loosing functionality that > was available in JDK-8 and is available in JDK-11. In particular, for > P11 sensitive keys we cannot extract the key bytes in plain (keyBytes > will be null indeed), but we can still use PKCS#11 primitives to get the > key digest [1]. In JDK-8, this was available here [2] [3]. Have you > considered using the JDK-11 MessageDigestSpi2 + Delegate approach? > Shouldn't involve any new public API [4]. Thank you You are absolutely right. I have to use JDK8 implementation of digestKey Fixed > > * JsseJce.java > > Have you considered backporting SecurityConstants.java part of 8130181 > [5] and use PROVIDER_VER in JsseJce.java > Thank you. Fixed. PROVIDER_VER is added to SecurityConstants. SunJSSE.jave is also updated > * SSLLogger.java > > Can't we leverage on PlatformLogger values directly? For each value, > there should be a corresponding one. In case there is a good reason why > not, we might want to think of moving the code to a more reusable place. I have updated it to use java.util.logging.Logger Internal Level enum is changed to java.util.logging.Level Also, I?ve made possible to register app Logger. It was not possible in the first version. > > * RandomCookie.java / RenegoInfoExtension.java > > Have you analyzed the performance implication of not having vectorized / > intrinsics for the comparison? No, I did not analyzed it. I understand possible performance impact but it could be optimized later. > > * SSLSessionContextImpl.java > > Can't we use GetPropertyAction::privilegedGetProperty? I have updated it as recommended in the JDK8 GetIntegerAction class > > * X509TrustManagerImpl.java > > Why is this change needed? > ExtendedSSLSession does not contain getStatusResponses() public API method. This method is part of JEP-249 : OCSP Stapling for TLS [1] It is possible to implement and use OCSP Stapling without public API. However, these changes should be moved to the step responsible for OCSP stapling support - JDK-8245473 Fixed > Thanks, > Martin.- > > -- > [1] - > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c0dd958bb895/src/share/classes/sun/security/pkcs11/P11Digest.java#l236 > [2] - > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c0dd958bb895/src/share/classes/sun/security/ssl/HandshakeMessage.java#l1738 > [3] - > http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/c0dd958bb895/src/share/classes/sun/security/ssl/HandshakeMessage.java#l1784 > [4] - https://bugs.openjdk.java.net/browse/JDK-8165275 > [5] - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6c96af8a34b2#l12.1 > [1] - https://bugs.openjdk.java.net/browse/JDK-8046321 From tianshi at amazon.com Fri May 29 17:26:49 2020 From: tianshi at amazon.com (Shi, Tianmin) Date: Fri, 29 May 2020 17:26:49 -0000 Subject: 8006205: [TESTBUG] NEED_TEST: please JTREGIFY test/compiler/7177917/Test7177917.java In-Reply-To: References: Message-ID: <81225DA4-6BC0-45CD-9C4B-F244487C57FA@amazon.com> Please review this test bug backport to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8006205 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c2304140ed64 Original file change from commit:https://hg.openjdk.java.net/jdk/jdk/file/c2304140ed64/hotspot/test/compiler/c2/Test7177917.java Webrev: http://cr.openjdk.java.net/~phh/8006205/webrev.8u.00/ The backport is simple, but is not clean because in 8 there is no @module and no need for @library to run the test. Test: jtreg -jdk:[testjdk] jdk8u-dev/hotspot/test/compiler/7177917 Test results: passed: 1 From tianshi at amazon.com Fri May 29 17:27:54 2020 From: tianshi at amazon.com (Shi, Tianmin) Date: Fri, 29 May 2020 17:27:54 -0000 Subject: RFR: 8006205: [TESTBUG] NEED_TEST: please JTREGIFY test/compiler/7177917/Test7177917.java Message-ID: Please review this test bug backport to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8006205 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c2304140ed64 Original file change from commit:https://hg.openjdk.java.net/jdk/jdk/file/c2304140ed64/hotspot/test/compiler/c2/Test7177917.java Webrev: http://cr.openjdk.java.net/~phh/8006205/webrev.8u.00/ The backport is simple, but is not clean because in 8 there is no @module and no need for @library to run the test.