From akashche at redhat.com  Sun Mar  1 12:03:00 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Sun, 1 Mar 2020 12:03:00 +0000
Subject: [11u] RFR: 8232854: URLClassLoader.close() doesn't close cached JAR
 file on Windows when load() fails
Message-ID: <361f077a-6d89-6de4-c613-2fed37a4c269@redhat.com>

Hi,

Please review the fix to JDK-8232854 for 11u:

Jira issue: https://bugs.openjdk.java.net/browse/JDK-8232854

Webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8232854/webrev.00/

Patch is implemented based on a test code included with the Jira issue. 
It fixes the case, when URLClassLoader is created with URL, that stars 
with "jar:file:" and ends with non-root path inside JAR like 
"foo.jar!/somedir/".

Codepath in this case includes URLClassPath.Loader class, that requires 
special handling when resources are loaded from a JAR file. Issue with 
closing JAR file (on classloader close) on this codepath was previously 
fixed in JDK-6896088:

Jira issue: https://bugs.openjdk.java.net/browse/JDK-6896088

Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/3af394bb6f59

This fix is complementary to 6896088, it is filling the "jarfile" field 
in URLClassPath.Loader class (to be able to close the JAR file later) in 
case, when requested resource failed to be loaded from this JAR. Note, 
that getJarFile() on URLConnection to original resource cannot be used 
in this case, because this method checks that requested resource is 
valid. URLConnection to the root URL in this JAR is used instead.

There probably exist more elegant solutions to this problem. This patch 
is fix-only and should not affect any existing logic in URLClassPath.

Test included with this fix is similar to 
java/net/URLClassLoader/B6896088.java test. It uses specific JAR 
structure (with a classfile inside "somedir" directory that is not a 
part of class package) and checks JAR file closing after both successful 
and failed load attempts. Test fails on Windows without this patch, on 
Linux it always passes.


-- 
-Alex


From volker.simonis at gmail.com  Mon Mar  2 13:30:00 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 2 Mar 2020 14:30:00 +0100
Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri
 Nesterenko
In-Reply-To: <20200226181202.GE24113@yoga>
References: <20200226181202.GE24113@yoga>
Message-ID: <CA+3eh12XZC1gg7KURyeAwEE2LtEAJ_NmVs3picPY8gA7vXbTVg@mail.gmail.com>

Vote: yes


Rob McKenna <rob.mckenna at oracle.com> schrieb am Mi., 26. Feb. 2020, 19:11:

> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Yuri Nesterenko as future lead maintainer.
>
> Votes are due by the 3rd of March.
>
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
>
> For Lazy Consensus voting instructions, see [2].
>
>   -Rob
>
> [0]
> http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
>

From gnu.andrew at redhat.com  Mon Mar  2 15:28:22 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 2 Mar 2020 15:28:22 +0000
Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK
 libraries"
In-Reply-To: <CA+3eh11hXne_PhkhwQgD4LvqUg6T-aDgKE2zO7jO6APOAnHycg@mail.gmail.com>
References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com>
 <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com>
 <CA+3eh11hXne_PhkhwQgD4LvqUg6T-aDgKE2zO7jO6APOAnHycg@mail.gmail.com>
Message-ID: <0032884d-060f-d40a-1a0e-9353899a2130@redhat.com>

On 28/02/2020 09:07, Volker Simonis wrote:
> On Thu, Feb 27, 2020 at 3:44 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>>
>> Hi Andrew,
>>
>> On Thu, 2020-02-27 at 04:52 +0000, Andrew Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232748
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/
>>>
>>> This patch adds targets to the build so that static versions of the JDK
>>> native libraries can be built, using static-libs-image. Such static
>>> versions of the libraries are required for consumption by Graal.
>>>
>>> With JDK-8210459 now in 11u, this is a largely clean backport, aside
>>> from some context changes, due to additional targets (JCov, JMH) being
>>> present in trunk:
>>>
>>> * In make/Bundles.gmk, 11u does not have jcov-bundles
>>> * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles
>>> * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR, etc or
>>> JCOV_BUNDLE_NAME.
>>> * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't
>>> include jmh and jcov.
>>>
>>> Building the new target, static-libs-image, succeeded. This should have
>>> no effect on other targets.
>>
>> Unfortunately this patch doesn't work. While a build of static-libs-
>> image succeeds, it doesn't create the image in build/<config-
>> name>/images. Expected is this:
>>
>> $ find build/linux-x86_64-normal-server-release/images/static-libs/
>> build/linux-x86_64-normal-server-release/images/static-libs/
>> build/linux-x86_64-normal-server-release/images/static-libs/lib
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pkcs11.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pcsc.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnio.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libprefs.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjava.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjli.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnet.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjimage.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjaas.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libfdlibm.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2gss.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libsunec.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjsig.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libextnet.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libverify.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libzip.a
>>
>> The reason for this is that FindFiles isn't available in JDK 11u. I had
>> to do these modifications to your patch to make it work:
>>
>> diff --git a/make/Bundles.gmk b/make/Bundles.gmk
>> --- a/make/Bundles.gmk
>> +++ b/make/Bundles.gmk
>> @@ -367,7 +367,7 @@
>>  ################################################################################
>>
>>  ifneq ($(filter static-libs-bundles, $(MAKECMDGOALS)), )
>> -  STATIC_LIBS_BUNDLE_FILES := $(call FindFiles, $(STATIC_LIBS_IMAGE_DIR))
>> +  STATIC_LIBS_BUNDLE_FILES := $(shell $(FIND) $(STATIC_LIBS_IMAGE_DIR))
>>
>>    ifeq ($(OPENJDK_TARGET_OS)-$(DEBUG_LEVEL), macosx-release)
>>      STATIC_LIBS_BUNDLE_SUBDIR := $(JDK_MACOSX_CONTENTS_SUBDIR)/Home
>> diff --git a/make/StaticLibsImage.gmk b/make/StaticLibsImage.gmk
>> --- a/make/StaticLibsImage.gmk
>> +++ b/make/StaticLibsImage.gmk
>> @@ -42,7 +42,7 @@
>>        SRC := $(SUPPORT_OUTPUTDIR)/native/$m, \
>>        DEST := $(STATIC_LIBS_IMAGE_DIR)/lib, \
>>        FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \
>> -          $(call FindFiles, $(SUPPORT_OUTPUTDIR)/native/$m/*/static)), \
>> +          $(shell $(FIND) $(SUPPORT_OUTPUTDIR)/native/$m/*/static)), \
>>    )) \
>>    $(eval TARGETS += $$(COPY_STATIC_LIBS_$m)) \
>>  )
>>
>> This uses FIND directly, but there ought to be a (convoluted?) way to
>> use CacheFind instead of FindFiles in 11u. Maybe build-dev folks could
>> help there?
>>

Right. Seems odd to me that make doesn't fail because of this, or even
issue a warning as far as I can see.

> 
> Hi Severin, Andrew,
> 
> there's no magic behind calling "CacheFind", you can just replace
> FindFiles by CacheFind. I've just did it and a test build with "make
> static-libs-image" resulted in the following output which seems to be
> correct:
> 
> $ find images/static-libs/
> images/static-libs/
> images/static-libs/lib
> images/static-libs/lib/libjaas.a
> images/static-libs/lib/libnet.a
> images/static-libs/lib/libzip.a
> images/static-libs/lib/libfdlibm.a
> images/static-libs/lib/libprefs.a
> images/static-libs/lib/libnio.a
> images/static-libs/lib/libextnet.a
> images/static-libs/lib/libj2pcsc.a
> images/static-libs/lib/libjimage.a
> images/static-libs/lib/libsunec.a
> images/static-libs/lib/libjava.a
> images/static-libs/lib/libjsig.a
> images/static-libs/lib/libj2gss.a
> images/static-libs/lib/libverify.a
> images/static-libs/lib/libjli.a
> images/static-libs/lib/libj2pkcs11.a
> 
> I've uploaded the updated webrev for your convenience to:
> 
> http://cr.openjdk.java.net/~simonis/webrevs/2020/8232748.02/
> 
> While I think replacing "FindFiles" by "CacheFind" in this downport is
> OK, we might also consider to downport "8189861: Refactor CacheFind"
> which introduced "FindFiles".
> 
> I think this might be useful because it was introduced in jdk13, so
> there might be other downports in the future which might depend on it
> and benefit from it being in jdk11u. We recently had another downport
> (8223678: Add Visual Studio Code workspace generation support (for
> native code)) which required "AssertEquals", something that's
> introduced by "8189861" as well. Andrew asked if it would make sense
> to downport the "AssertEquals" macro and I wnated to answer that it
> will probably make sense if we see another downport requiring it. Now,
> even before I answered we have this situation :) (this downport
> doesn't exactly require "AssertEquals" but "FindFiles" which was
> introduced with the same change).
> 
> On the other hand "8189861: Refactor CacheFind" which introduced
> "FindFiles" isn't trivial to downport. I've just did a quick check and
> it require manual resolving in several files (even if I ignore the
> copyright-headers for now). I think I could volunteer to do it, but it
> would definitely require some work. Maybe now, where we'te at the
> beginning of 11.0.8 it's a good point in time to do such a change?
> 
> I'll leave the final decision up to Andrew?
> 
> Best regards,
> Volker
> 
>> Thanks,
>> Severin
>>
> 

I'll look at backporting 8189861. Seems it gives us two functions we
need for the price of one backport.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


From zgu at redhat.com  Mon Mar  2 15:54:08 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 2 Mar 2020 10:54:08 -0500
Subject: [14u] RFR 8237632: Shenandoah: accept NULL fwdptr to cooperate with
 JVMTI and JFR
Message-ID: <017a29cf-d773-819d-46ee-0f4d633302a9@redhat.com>

Hi,

I would like to backport this patch to 14u.

Shenandoah and JVMTI/JFR leakprofiler all use object mark word's 
'marked' pattern, but for different purpose. Without this patch, it can 
result fatal crash for Shenandoah, as it interpreters JVMTI/JFR visited 
objects as forwarding objects.

The original patch does not apply cleanly, mainly due to line shifts and 
missing JDK-8236888 in JDK14u.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8237632
Original code review: 
https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-February/028693.html

14u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/14u/webrev.00/


Test:
   hotspot_gc_shenandoah
   vmTestbase_nsk_jvmti
   vmTestbase_nsk_jdi

Thanks,

-Zhengyu


From zgu at redhat.com  Mon Mar  2 16:05:08 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 2 Mar 2020 11:05:08 -0500
Subject: [14u] RFR 8237632: Shenandoah: accept NULL fwdptr to cooperate
 with JVMTI and JFR
In-Reply-To: <017a29cf-d773-819d-46ee-0f4d633302a9@redhat.com>
References: <017a29cf-d773-819d-46ee-0f4d633302a9@redhat.com>
Message-ID: <8cc385a0-834b-0c97-f6ef-f8b6a633fc68@redhat.com>


On 3/2/20 10:54 AM, Zhengyu Gu wrote:
> Hi,
> 
> I would like to backport this patch to 14u.
> 
> Shenandoah and JVMTI/JFR leakprofiler all use object mark word's 
> 'marked' pattern, but for different purpose. Without this patch, it can 
> result fatal crash for Shenandoah, as it interpreters JVMTI/JFR visited 
> objects as forwarding objects.
> 
> The original patch does not apply cleanly, mainly due to line shifts and 
> missing JDK-8236888 in JDK14u.

Sorry, wrong bug Id, JDK-8236888 -> JDK-8237963.

-Zhengyu


> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8237632
> Original code review: 
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-February/028693.html 
> 
> 
> 14u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/14u/webrev.00/
> 
> 
> Test:
>  ? hotspot_gc_shenandoah
>  ? vmTestbase_nsk_jvmti
>  ? vmTestbase_nsk_jdi
> 
> Thanks,
> 
> -Zhengyu
> 


From shade at redhat.com  Mon Mar  2 16:10:36 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 2 Mar 2020 17:10:36 +0100
Subject: [14u] RFR 8237632: Shenandoah: accept NULL fwdptr to cooperate
 with JVMTI and JFR
In-Reply-To: <017a29cf-d773-819d-46ee-0f4d633302a9@redhat.com>
References: <017a29cf-d773-819d-46ee-0f4d633302a9@redhat.com>
Message-ID: <93296dd4-78dd-5a9e-5ac2-7ca1f8b04756@redhat.com>

On 3/2/20 4:54 PM, Zhengyu Gu wrote:
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8237632

The label should be jdk14u-fix-request? Unless you want to push this into JDK 14 RC, which is the
whole other story.

> 14u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/14u/webrev.00/

14u backport looks good.

-- 
Thanks,
-Aleksey


From jaroslav.bachorik at datadoghq.com  Mon Mar  2 16:19:00 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Mon, 2 Mar 2020 17:19:00 +0100
Subject: [11u] RFR: 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
Message-ID: <CAPb8aJ7cvK_o3tnpdYY_biN63dAHuC4h1pxWBy25mhw9r3U9NA@mail.gmail.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8233197
Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/webrev/

Please, review this patch backporting JDK-8233197 to JDK 11u. The original
fix prevents a JVM crash when starting a JFR in agent premain.

The patch applies rather cleanly with only 2 conflicts in jfrRecord.cpp due
to changes in JFR args processing and method renamings (
http://cr.openjdk.java.net/~jbachorik/8233197/webrev/jfrRecorder.cpp.rej).

All jdk/jfr tests have been run successfully with this patch applied.

Thanks,

-JB-

From zgu at redhat.com  Mon Mar  2 16:38:35 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 2 Mar 2020 11:38:35 -0500
Subject: [14u] RFR 8237632: Shenandoah: accept NULL fwdptr to cooperate
 with JVMTI and JFR
In-Reply-To: <93296dd4-78dd-5a9e-5ac2-7ca1f8b04756@redhat.com>
References: <017a29cf-d773-819d-46ee-0f4d633302a9@redhat.com>
 <93296dd4-78dd-5a9e-5ac2-7ca1f8b04756@redhat.com>
Message-ID: <d43e7bdf-bfed-d4a2-c925-bb032541930b@redhat.com>



On 3/2/20 11:10 AM, Aleksey Shipilev wrote:
> On 3/2/20 4:54 PM, Zhengyu Gu wrote:
>> Original bug: https://bugs.openjdk.java.net/browse/JDK-8237632
> 
> The label should be jdk14u-fix-request? Unless you want to push this into JDK 14 RC, which is the
> whole other story.
> 
>> 14u Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/14u/webrev.00/
> 
> 14u backport looks good.

Thanks, Aleksey.

-Zhengyu

> 


From christoph.langer at sap.com  Tue Mar  3 07:57:46 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Mar 2020 07:57:46 +0000
Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
 file does not preserve original permissions
In-Reply-To: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

I think you need to add "permission java.lang.RuntimePermission "accessUserInformation";" to src/java.base/share/lib/security/default.policy, grant codeBase "jrt:/jdk.zipfs". That was originally introduced by JDK-8213031: http://hg.openjdk.java.net/jdk/jdk/rev/bf325b739c8a. We see 3 test failures with your current patch which should hopefully be resolved by that.

As for refactoring regarding the missing java.nio.file.FileSystems.newFileSystem(Path path, Map<String,?> env) API in JDK11, I suggest you use zipFile.toUri() as was done in this backport already: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f8b2e95a1d41. That way you'll avoid the need for the helper method " public static FileSystem newFileSystem(Path path, Map<String,?> env)" that you introduced in ZipFSPermissionsTest.

Best regards
Christoph
 

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Freitag, 28. Februar 2020 09:53
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
> file does not preserve original permissions
> 
> Hello, please  review the downport of
> 8229888: (zipfs) Updating an existing zip file does not preserve original
> permissions
> 
> to jdk11u. The change is in 11.0.7-oracle so it would be good to have it in
> OpenJDK 11 as well.
> 
> The change touches
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java  and test related
> files.
> I had to add imports to ZipFileSystem.java, and had to adjust the test file
> test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java
> because jdk11   misses  java.nio.file.FileSystems.newFileSystem(Path path,
> Map<String,?> env) .
> 
> 
> bug :
> https://bugs.openjdk.java.net/browse/JDK-8229888
> 
> 
> original jdk/jdk change :
> https://hg.openjdk.java.net/jdk/jdk/rev/798c0903fcd0
> 
> 
> adjusted jdk11u change :
> http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_0_jdk11/
> 
> 
> Thanks, Matthias

From christoph.langer at sap.com  Tue Mar  3 08:02:09 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Mar 2020 08:02:09 +0000
Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri
 Nesterenko
In-Reply-To: <20200226181202.GE24113@yoga>
References: <20200226181202.GE24113@yoga>
Message-ID: <AM0PR02MB571458A38A3CFC724CC1E11A8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Rob McKenna
> Sent: Mittwoch, 26. Februar 2020 19:12
> To: jdk-updates-dev at openjdk.java.net
> Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri
> Nesterenko
> 
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Yuri Nesterenko as future lead maintainer.
> 
> Votes are due by the 3rd of March.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>   -Rob
> 
> [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> February/002535.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus

From matthias.baesken at sap.com  Tue Mar  3 10:06:17 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 3 Mar 2020 10:06:17 +0000
Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
 file does not preserve original permissions
In-Reply-To: <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB4227D9A05E536E93234F91B393E40@AM0PR02MB4227.eurprd02.prod.outlook.com>


Hi Christoph ,

> , I suggest you use zipFile.toUri() as was done in this backport
> already: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f8b2e95a1d41.

Doing this leads to :

java.lang.IllegalArgumentException: Path component should be '/'
	at java.base/sun.nio.fs.UnixFileSystemProvider.checkUri(UnixFileSystemProvider.java:82)
	at java.base/sun.nio.fs.UnixFileSystemProvider.newFileSystem(UnixFileSystemProvider.java:91)
	at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:337)
	at java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:286)
	at ZipFSPermissionsTest.zip(ZipFSPermissionsTest.java:199)
	at ZipFSPermissionsTest.before(ZipFSPermissionsTest.java:90)


Best regards, Matthias

> 
> Hi Matthias,
> 
> I think you need to add "permission java.lang.RuntimePermission
> "accessUserInformation";" to src/java.base/share/lib/security/default.policy,
> grant codeBase "jrt:/jdk.zipfs". That was originally introduced by JDK-
> 8213031: http://hg.openjdk.java.net/jdk/jdk/rev/bf325b739c8a. We see 3
> test failures with your current patch which should hopefully be resolved by
> that.
> 
> As for refactoring regarding the missing
> java.nio.file.FileSystems.newFileSystem(Path path, Map<String,?> env) API
> in JDK11, I suggest you use zipFile.toUri() as was done in this backport
> already: http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f8b2e95a1d41.
> That way you'll avoid the need for the helper method " public static
> FileSystem newFileSystem(Path path, Map<String,?> env)" that you
> introduced in ZipFSPermissionsTest.
> 
> Best regards
> Christoph
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Baesken, Matthias
> > Sent: Freitag, 28. Februar 2020 09:53
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
> > file does not preserve original permissions
> >
> > Hello, please  review the downport of
> > 8229888: (zipfs) Updating an existing zip file does not preserve original
> > permissions
> >
> > to jdk11u. The change is in 11.0.7-oracle so it would be good to have it in
> > OpenJDK 11 as well.
> >
> > The change touches
> > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java  and test
> related
> > files.
> > I had to add imports to ZipFileSystem.java, and had to adjust the test file
> > test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java
> > because jdk11   misses  java.nio.file.FileSystems.newFileSystem(Path path,
> > Map<String,?> env) .
> >
> >
> > bug :
> > https://bugs.openjdk.java.net/browse/JDK-8229888
> >
> >
> > original jdk/jdk change :
> > https://hg.openjdk.java.net/jdk/jdk/rev/798c0903fcd0
> >
> >
> > adjusted jdk11u change :
> > http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_0_jdk11/
> >
> >
> > Thanks, Matthias

From matthias.baesken at sap.com  Tue Mar  3 12:38:10 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 3 Mar 2020 12:38:10 +0000
Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
 file does not preserve original permissions
References: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB4227DD5DE617A5CBA03AFCD693E40@AM0PR02MB4227.eurprd02.prod.outlook.com>

New webrev :


http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_1_jdk11/

this adds   permission java.lang.RuntimePermission "accessUserInformation";   to   default.policy  .
( In higher jdk versions  this change came with  Christophs changes ,  but here we need it too ).


Best regards, Matthias



> 
> Hi Christoph ,
> 
> > , I suggest you use zipFile.toUri() as was done in this backport
> > already: http://hg.openjdk.java.net/jdk-
> updates/jdk11u/rev/f8b2e95a1d41.
> 
> Doing this leads to :
> 
> java.lang.IllegalArgumentException: Path component should be '/'
> 	at
> java.base/sun.nio.fs.UnixFileSystemProvider.checkUri(UnixFileSystemProvid
> er.java:82)
> 	at
> java.base/sun.nio.fs.UnixFileSystemProvider.newFileSystem(UnixFileSystem
> Provider.java:91)
> 	at
> java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:337)
> 	at
> java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:286)
> 	at ZipFSPermissionsTest.zip(ZipFSPermissionsTest.java:199)
> 	at ZipFSPermissionsTest.before(ZipFSPermissionsTest.java:90)
> 
> 
> Best regards, Matthias
> 


From christoph.langer at sap.com  Tue Mar  3 12:47:27 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Mar 2020 12:47:27 +0000
Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
 file does not preserve original permissions
In-Reply-To: <AM0PR02MB4227D9A05E536E93234F91B393E40@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB4227D9A05E536E93234F91B393E40@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714D5A937905F8F3C8F886C8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

I think I was too quick... it should be:

FileSystems.newFileSystem(new URI("jar", zipFile.toUri().toString(), null), env)

You'll also have to change throws IOException to throws Exception for the zip method, since new URI throws URISyntaxException.

Best regards
Christoph


> -----Original Message-----
> From: Baesken, Matthias <matthias.baesken at sap.com>
> Sent: Dienstag, 3. M?rz 2020 11:06
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing
> zip file does not preserve original permissions
> 
> 
> Hi Christoph ,
> 
> > , I suggest you use zipFile.toUri() as was done in this backport
> > already: http://hg.openjdk.java.net/jdk-
> updates/jdk11u/rev/f8b2e95a1d41.
> 
> Doing this leads to :
> 
> java.lang.IllegalArgumentException: Path component should be '/'
> 	at
> java.base/sun.nio.fs.UnixFileSystemProvider.checkUri(UnixFileSystemProvid
> er.java:82)
> 	at
> java.base/sun.nio.fs.UnixFileSystemProvider.newFileSystem(UnixFileSystem
> Provider.java:91)
> 	at
> java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:337)
> 	at
> java.base/java.nio.file.FileSystems.newFileSystem(FileSystems.java:286)
> 	at ZipFSPermissionsTest.zip(ZipFSPermissionsTest.java:199)
> 	at ZipFSPermissionsTest.before(ZipFSPermissionsTest.java:90)
> 
> 
> Best regards, Matthias
> 
> >
> > Hi Matthias,
> >
> > I think you need to add "permission java.lang.RuntimePermission
> > "accessUserInformation";" to
> src/java.base/share/lib/security/default.policy,
> > grant codeBase "jrt:/jdk.zipfs". That was originally introduced by JDK-
> > 8213031: http://hg.openjdk.java.net/jdk/jdk/rev/bf325b739c8a. We see 3
> > test failures with your current patch which should hopefully be resolved by
> > that.
> >
> > As for refactoring regarding the missing
> > java.nio.file.FileSystems.newFileSystem(Path path, Map<String,?> env)
> API
> > in JDK11, I suggest you use zipFile.toUri() as was done in this backport
> > already: http://hg.openjdk.java.net/jdk-
> updates/jdk11u/rev/f8b2e95a1d41.
> > That way you'll avoid the need for the helper method " public static
> > FileSystem newFileSystem(Path path, Map<String,?> env)" that you
> > introduced in ZipFSPermissionsTest.
> >
> > Best regards
> > Christoph
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Baesken, Matthias
> > > Sent: Freitag, 28. Februar 2020 09:53
> > > To: jdk-updates-dev at openjdk.java.net
> > > Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing
> zip
> > > file does not preserve original permissions
> > >
> > > Hello, please  review the downport of
> > > 8229888: (zipfs) Updating an existing zip file does not preserve original
> > > permissions
> > >
> > > to jdk11u. The change is in 11.0.7-oracle so it would be good to have it in
> > > OpenJDK 11 as well.
> > >
> > > The change touches
> > > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java  and test
> > related
> > > files.
> > > I had to add imports to ZipFileSystem.java, and had to adjust the test file
> > > test/jdk/jdk/nio/zipfs/ZipFSPermissionsTest.java
> > > because jdk11   misses  java.nio.file.FileSystems.newFileSystem(Path
> path,
> > > Map<String,?> env) .
> > >
> > >
> > > bug :
> > > https://bugs.openjdk.java.net/browse/JDK-8229888
> > >
> > >
> > > original jdk/jdk change :
> > > https://hg.openjdk.java.net/jdk/jdk/rev/798c0903fcd0
> > >
> > >
> > > adjusted jdk11u change :
> > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_0_jdk11/
> > >
> > >
> > > Thanks, Matthias

From hohensee at amazon.com  Tue Mar  3 13:46:38 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 3 Mar 2020 13:46:38 +0000
Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri
 Nesterenko
In-Reply-To: <20200226181202.GE24113@yoga>
References: <20200226181202.GE24113@yoga>
Message-ID: <CF9DFEF0-2212-4CD7-BBDF-C89305CC6353@amazon.com>

Vote: yes

?On 2/26/20, 10:13 AM, "jdk-updates-dev on behalf of Rob McKenna" <jdk-updates-dev-bounces at openjdk.java.net on behalf of rob.mckenna at oracle.com> wrote:

    As the Project Lead, I would like to ask for your vote for the
    nomination [0] of Yuri Nesterenko as future lead maintainer.
    
    Votes are due by the 3rd of March.
    
    Only current JDK Updates Committers [1] are eligible to vote
    on this nomination.  Votes must be cast in the open by replying
    "Vote: yes" to this mail.
    
    For Lazy Consensus voting instructions, see [2].
    
      -Rob
    
    [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html
    [1] http://openjdk.java.net/census
    [2] http://openjdk.java.net/bylaws#lazy-consensus
    


From simone.bordet at gmail.com  Tue Mar  3 13:51:49 2020
From: simone.bordet at gmail.com (Simone Bordet)
Date: Tue, 3 Mar 2020 14:51:49 +0100
Subject: ALPN API backport and JDK version
Message-ID: <CAFWmRJ3b8UzBFZZ4gDuUNV7uGXf+Rk4XUwYzqTV8meHfSsTfOA@mail.gmail.com>

Hi,

as you may know, the Jetty Project created a `alpn-boot` jar with
modified sun.* classes to support ALPN in Java 8.
This certainly categorizes as a hack, but it allowed HTTP/2 to be
widely deployed and tested on Java clients and servers well before
Java 9 (with official ALPN APIs) and for those that did not upgrade
past Java 8 yet.

8u252 is scheduled to receive the backport of the ALPN API.

While code-wise it's not a big deal, build tools have a bigger problem.

AFAIK, build systems do not go beyond 3 digits for versioning Java, so
it's almost impossible to tell the difference between 1.8.0_242 and
1.8.0_252 when building, as they are both seen as 1.8.0.
My understanding is that this is done for max compatibility, as
vendors tend to put anything after the 3 digits in a way that is
impossible to parse and therefore establish an order (1.8.0_242 <
1.8.0_252) to be used in version ranges.

However, 8u242 and 8u252 are quite different with respect to the ALPN API (the
former requires alpn-boot, the latter does not).

It would help quite a lot if 1.8.0_252 could be renamed to 1.8.1.

This would allow build tools like Maven Enforcer to explicitly say
that a project can be built with only 1.8.0 and not 1.8.1 (to phase it
out - in our case that would be applied to Jetty 9.2.x and 9.3.x),
it would allow Maven Profiles to distinguish between the two (right
now it's not possible), allowing to configure Maven Compiler and Maven
Surefire (testing) with the extra options required (or not) by ALPN
(e.g. add bootclasspath or not), etc.

I imagine this would be quite useful to all projects that somehow
depend on the alpn-boot jar. By using a Maven profile (or equivalent), they
will be able to specify a correct command line (including bootclasspath or not)
and correct dependencies.

Do you think it will be possible to have a OpenJDK 1.8.1 instead of 1.8.0_252?

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From matthias.baesken at sap.com  Tue Mar  3 13:56:40 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 3 Mar 2020 13:56:40 +0000
Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
 file does not preserve original permissions
In-Reply-To: <AM0PR02MB5714D5A937905F8F3C8F886C8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB4227D9A05E536E93234F91B393E40@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB5714D5A937905F8F3C8F886C8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB4227EDFD49DD18BB9571A1DB93E40@AM0PR02MB4227.eurprd02.prod.outlook.com>

Thanks, new webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_2_jdk11/

Best regards, Matthias


> Hi Matthias,
> 
> I think I was too quick... it should be:
> 
> FileSystems.newFileSystem(new URI("jar", zipFile.toUri().toString(), null),
> env)
> 
> You'll also have to change throws IOException to throws Exception for the zip
> method, since new URI throws URISyntaxException.
> 
> Best regards
> Christoph
> 


From christoph.langer at sap.com  Tue Mar  3 14:09:04 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Mar 2020 14:09:04 +0000
Subject: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing zip
 file does not preserve original permissions
In-Reply-To: <AM0PR02MB4227EDFD49DD18BB9571A1DB93E40@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB42277E3C2E1AB729CEE026C593E80@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57146CD35837CEC0BE8BD65D8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB4227D9A05E536E93234F91B393E40@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB5714D5A937905F8F3C8F886C8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB4227EDFD49DD18BB9571A1DB93E40@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714B8E8BDF2AF05B7BF9EE08AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

I think this looks good now. In ZipFSPermissionsTest, you should update the Javadoc for method "zip" to have document "@throws Exception" instead of "@throws IOException", though, since this was changed.

Let's wait for the nightly test results and then I'll approve it tomorrow.

Best regards
Christoph

> -----Original Message-----
> From: Baesken, Matthias <matthias.baesken at sap.com>
> Sent: Dienstag, 3. M?rz 2020 14:57
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [CAUTION] [jdk11u] RFR: 8229888: (zipfs) Updating an existing
> zip file does not preserve original permissions
> 
> Thanks, new webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8229888_2_jdk11/
> 
> Best regards, Matthias
> 
> 
> > Hi Matthias,
> >
> > I think I was too quick... it should be:
> >
> > FileSystems.newFileSystem(new URI("jar", zipFile.toUri().toString(), null),
> > env)
> >
> > You'll also have to change throws IOException to throws Exception for the
> zip
> > method, since new URI throws URISyntaxException.
> >
> > Best regards
> > Christoph
> >


From christoph.langer at sap.com  Tue Mar  3 15:02:53 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Mar 2020 15:02:53 +0000
Subject: [11u] RFR: 8193879: Java debugger hangs on method invocation
Message-ID: <AM0PR02MB57140ABC135E8BBED75E91578AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

please review the backport of this JDI fix. The bug was recently opened by Oracle (was private before) and it already contained the jdk11u-fix-request and approval labels. So I looked into backporting. The change did not apply cleanly. The hunk for test/jdk/com/sun/jdi/lib/jdb/JdbTest.java does not apply since the file does not exist in 11u. In the test "test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java", I had to inline the method parseBreakpoints from JdbTest.java and also the coding of getTestSourcePath() which are used in head jdk/jdk.

With these modifications, the patch successfully runs through our testing and the new testcase passes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8193879
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8193879.11u/

Best regards
Christoph


From gil at azul.com  Tue Mar  3 15:33:18 2020
From: gil at azul.com (Gil Tene)
Date: Tue, 3 Mar 2020 15:33:18 +0000
Subject: ALPN API backport and JDK version
In-Reply-To: <CAFWmRJ3b8UzBFZZ4gDuUNV7uGXf+Rk4XUwYzqTV8meHfSsTfOA@mail.gmail.com>
References: <CAFWmRJ3b8UzBFZZ4gDuUNV7uGXf+Rk4XUwYzqTV8meHfSsTfOA@mail.gmail.com>
Message-ID: <5CA095AE-977E-4235-A97F-D4BFC024CADC@azul.com>

[Adding jdk8u-dev]

> On Mar 3, 2020, at 5:51 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> as you may know, the Jetty Project created a `alpn-boot` jar with
> modified sun.* classes to support ALPN in Java 8.
> This certainly categorizes as a hack, but it allowed HTTP/2 to be
> widely deployed and tested on Java clients and servers well before
> Java 9 (with official ALPN APIs) and for those that did not upgrade
> past Java 8 yet.
> 
> 8u252 is scheduled to receive the backport of the ALPN API.
> 
> While code-wise it's not a big deal, build tools have a bigger problem.
> 
> AFAIK, build systems do not go beyond 3 digits for versioning Java, so
> it's almost impossible to tell the difference between 1.8.0_242 and
> 1.8.0_252 when building, as they are both seen as 1.8.0.
> My understanding is that this is done for max compatibility, as
> vendors tend to put anything after the 3 digits in a way that is
> impossible to parse and therefore establish an order (1.8.0_242 <
> 1.8.0_252) to be used in version ranges.
> 
> However, 8u242 and 8u252 are quite different with respect to the ALPN API (the
> former requires alpn-boot, the latter does not).
> 
> It would help quite a lot if 1.8.0_252 could be renamed to 1.8.1.
> 
> This would allow build tools like Maven Enforcer to explicitly say
> that a project can be built with only 1.8.0 and not 1.8.1 (to phase it
> out - in our case that would be applied to Jetty 9.2.x and 9.3.x),
> it would allow Maven Profiles to distinguish between the two (right
> now it's not possible), allowing to configure Maven Compiler and Maven
> Surefire (testing) with the extra options required (or not) by ALPN
> (e.g. add bootclasspath or not), etc.
> 
> I imagine this would be quite useful to all projects that somehow
> depend on the alpn-boot jar. By using a Maven profile (or equivalent), they
> will be able to specify a correct command line (including bootclasspath or not)
> and correct dependencies.
> 
> Do you think it will be possible to have a OpenJDK 1.8.1 instead of 1.8.0_252?

IMO such a change to the versioning will likely break a tremendous number of
existing working code. so I would advise against it.

AFAIK, due to the (seemingly necessary up to this point, so no judgement
tones intended) reliance on modified sun.* classes in the Jetty ALPN implementation,
there is already a strong version dependency between the ALPN jar the
specific 8u version. See detailed list at https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions <https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html#alpn-versions> ,
showing that e.g. Jetty ALPN 8.1.13.v20181017 requires/is-required-for 8u191
and above. A mismatch between the Jetty ALPN version and the specific update
level of an 8u JRE/JDK will already break code using Jetty ALPN (I've personally
seen this in enough places that "check 8u version against to Jettty ALPN version"
is on my checklist for "usual suspects" when a new JDK install causes issues)

IMO the right way for Jetty ALPN to handle the new ALPN capability in 8u is for
the new/latest (and hopefully last) version of Jetty ALPN to target/match the version
of 8u that actually includes working built-in ALPN support (presumably 8u252
at this point), and that Jetty ALPN version would simply not include the sun.* classes
that previous versions had included to override the 8u internal functionality.
Assuming the API behavior remains the same (a big assumption, but one we should
probably check early), that should provide a smooth transition for setups that already
include Jetty ALPN. Yes, they would have the alpn-boot jar on the bootclasspath
"for no good reason", but things will continue to work just as they had before.

> 
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz


From sgehwolf at redhat.com  Tue Mar  3 15:34:15 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 03 Mar 2020 16:34:15 +0100
Subject: [11u] RFR: 8193879: Java debugger hangs on method invocation
In-Reply-To: <AM0PR02MB57140ABC135E8BBED75E91578AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57140ABC135E8BBED75E91578AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <b4840978062fd9c3d9488ea652bcb3fbdc572419.camel@redhat.com>

On Tue, 2020-03-03 at 15:02 +0000, Langer, Christoph wrote:
> The bug was recently
> opened by Oracle (was private before) and it already contained the
> jdk11u-fix-request and approval labels.

Well, looking at the history, the jdk11u-fix-yes label was added in
2018 by Rob Mckenna. I believe we should consider it invalid at this
point. I.e. remove them and add them back in following the usual
process.

Thanks,
Severin


From christoph.langer at sap.com  Tue Mar  3 15:47:08 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 3 Mar 2020 15:47:08 +0000
Subject: [11u] RFR: 8193879: Java debugger hangs on method invocation
In-Reply-To: <b4840978062fd9c3d9488ea652bcb3fbdc572419.camel@redhat.com>
References: <AM0PR02MB57140ABC135E8BBED75E91578AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <b4840978062fd9c3d9488ea652bcb3fbdc572419.camel@redhat.com>
Message-ID: <AM0PR02MB571407B77373240E2E0CE7DD8AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Severin,

good point. I removed the jdk11u-fix-yes label. Let's wait for a review then.

Cheers
Christoph

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Dienstag, 3. M?rz 2020 16:34
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: Baesken, Matthias <matthias.baesken at sap.com>
> Subject: Re: [11u] RFR: 8193879: Java debugger hangs on method invocation
> 
> On Tue, 2020-03-03 at 15:02 +0000, Langer, Christoph wrote:
> > The bug was recently
> > opened by Oracle (was private before) and it already contained the
> > jdk11u-fix-request and approval labels.
> 
> Well, looking at the history, the jdk11u-fix-yes label was added in
> 2018 by Rob Mckenna. I believe we should consider it invalid at this
> point. I.e. remove them and add them back in following the usual
> process.
> 
> Thanks,
> Severin


From simone.bordet at gmail.com  Tue Mar  3 16:22:28 2020
From: simone.bordet at gmail.com (Simone Bordet)
Date: Tue, 3 Mar 2020 17:22:28 +0100
Subject: ALPN API backport and JDK version
In-Reply-To: <5CA095AE-977E-4235-A97F-D4BFC024CADC@azul.com>
References: <CAFWmRJ3b8UzBFZZ4gDuUNV7uGXf+Rk4XUwYzqTV8meHfSsTfOA@mail.gmail.com>
 <5CA095AE-977E-4235-A97F-D4BFC024CADC@azul.com>
Message-ID: <CAFWmRJ3=VKzgAC+StBc47G+WY_PmiHzYxNZJCEmjPd+Z6nVeSw@mail.gmail.com>

Gil,

thanks for your insights, more inline.

On Tue, Mar 3, 2020 at 4:33 PM Gil Tene <gil at azul.com> wrote:
> IMO such a change to the versioning will likely break a tremendous number of
> existing working code. so I would advise against it.

Fair, the idea was to start a discussion and see where it was going.

> IMO the right way for Jetty ALPN to handle the new ALPN capability in 8u is for
> the new/latest (and hopefully last) version of Jetty ALPN to target/match the version
> of 8u that actually includes working built-in ALPN support (presumably 8u252
> at this point), and that Jetty ALPN version would simply not include the sun.* classes
> that previous versions had included to override the 8u internal functionality.
> Assuming the API behavior remains the same (a big assumption, but one we should
> probably check early), that should provide a smooth transition for setups that already
> include Jetty ALPN. Yes, they would have the alpn-boot jar on the bootclasspath
> "for no good reason", but things will continue to work just as they had before.

Just to clarify that the smooth transition for runtime behavior is
already the case.

The ALPN boot jar in the bootclasspath for no good reason is ok, but
eventually (given that JDK 8 is supported by vendors until 2030) at a
certain point one would like to get rid of it.
And that is where the difficult part comes, convincing the build tools
(I know Maven has, but I suspect others will have similar problems).

I mean, it's solvable (people will just start to write custom Maven
plugins that can handle the "_xyz" part), and everyone will write
their own solution.
Having 1.8.1 will be much easier and require no "creative"
customization of the build tool in use.

Do you have examples of 1.8.1 breaking existing code? Just curious.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

From shade at redhat.com  Tue Mar  3 16:51:48 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Mar 2020 17:51:48 +0100
Subject: [14] JDK-8225130 question
Message-ID: <40a42a82-d4ef-32da-e111-8c4573113434@redhat.com>

Hi,

Today, I had requested 14u backport for:
  https://bugs.openjdk.java.net/browse/JDK-8225130

...and got jdk14u-fix-yes. Imagine my surprise when I saw the 14.0.2 backport already done today:
  https://bugs.openjdk.java.net/browse/JDK-8240369

That's odd, but somewhat understandable.

Yet, there are *no* changesets in public repositories!
  https://hg.openjdk.java.net/jdk-updates/jdk14u/log?rev=8225130
  https://hg.openjdk.java.net/jdk-updates/jdk14u/log?rev=8240369

What gives? Is there some private jdk14u fork that hgupdater work on? Are Oracle committers push to
14u without following the Update Releases process?

-- 
Thanks,
-Aleksey


From gil at azul.com  Tue Mar  3 16:53:50 2020
From: gil at azul.com (Gil Tene)
Date: Tue, 3 Mar 2020 16:53:50 +0000
Subject: ALPN API backport and JDK version
In-Reply-To: <CAFWmRJ3=VKzgAC+StBc47G+WY_PmiHzYxNZJCEmjPd+Z6nVeSw@mail.gmail.com>
References: <CAFWmRJ3b8UzBFZZ4gDuUNV7uGXf+Rk4XUwYzqTV8meHfSsTfOA@mail.gmail.com>
 <5CA095AE-977E-4235-A97F-D4BFC024CADC@azul.com>
 <CAFWmRJ3=VKzgAC+StBc47G+WY_PmiHzYxNZJCEmjPd+Z6nVeSw@mail.gmail.com>
Message-ID: <9290DED4-F64B-47FA-B6A3-F8A2DA507A0C@azul.com>



> On Mar 3, 2020, at 8:22 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Gil,
> 
> thanks for your insights, more inline.
> 
> On Tue, Mar 3, 2020 at 4:33 PM Gil Tene <gil at azul.com> wrote:
>> IMO such a change to the versioning will likely break a tremendous number of
>> existing working code. so I would advise against it.
> 
> Fair, the idea was to start a discussion and see where it was going.
> 
>> IMO the right way for Jetty ALPN to handle the new ALPN capability in 8u is for
>> the new/latest (and hopefully last) version of Jetty ALPN to target/match the version
>> of 8u that actually includes working built-in ALPN support (presumably 8u252
>> at this point), and that Jetty ALPN version would simply not include the sun.* classes
>> that previous versions had included to override the 8u internal functionality.
>> Assuming the API behavior remains the same (a big assumption, but one we should
>> probably check early), that should provide a smooth transition for setups that already
>> include Jetty ALPN. Yes, they would have the alpn-boot jar on the bootclasspath
>> "for no good reason", but things will continue to work just as they had before.
> 
> Just to clarify that the smooth transition for runtime behavior is
> already the case.
> 
> The ALPN boot jar in the bootclasspath for no good reason is ok, but
> eventually (given that JDK 8 is supported by vendors until 2030) at a
> certain point one would like to get rid of it.
> And that is where the difficult part comes, convincing the build tools
> (I know Maven has, but I suspect others will have similar problems).
> 
> I mean, it's solvable (people will just start to write custom Maven
> plugins that can handle the "_xyz" part), and everyone will write
> their own solution.
> Having 1.8.1 will be much easier and require no "creative"
> customization of the build tool in use.
> 
> Do you have examples of 1.8.1 breaking existing code? Just curious.

E.g. Code that parses the "java.version" property, translates it to a double,
and then assumes Java 8 is == 1.8 (and that >1.8 is not Java 8) is common
case, and seems to be copied across many applications. Here is an example:

https://github.com/Col-E/Recaf/blob/257783d54713d9cd352c19ad93a11cb79a5670ba/src/main/java/me/coley/recaf/util/Dependencies.java#L34 <https://github.com/Col-E/Recaf/blob/257783d54713d9cd352c19ad93a11cb79a5670ba/src/main/java/me/coley/recaf/util/Dependencies.java#L34>

Some JDK installation tools out there assume "8" or "1.8" or 8uXYZ
for version names in either or in their internal configuration files, and do not
currently have support for saying something like 1.8.1uX.

E.g. Jabba tracks Java 8 versions in its internal json files with 1.8.u
(so assuming nothing between 1.8 and the u):
https://github.com/shyiko/jabba/blob/master/index.json <https://github.com/shyiko/jabba/blob/master/index.json>

And that's just off the top of my head.

> 
> Thanks!
> 
> --
> Simone Bordet
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz


From rob.mckenna at oracle.com  Tue Mar  3 17:10:39 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 3 Mar 2020 17:10:39 +0000
Subject: [14] JDK-8225130 question
In-Reply-To: <40a42a82-d4ef-32da-e111-8c4573113434@redhat.com>
References: <40a42a82-d4ef-32da-e111-8c4573113434@redhat.com>
Message-ID: <20200303171039.GA9097@yoga>

Sibabrata (cc'd) has pushed that fix to the CPU repo after it was
approved via the cpu fix approval process. (i.e. the approval process
that applies to all CPU content)

You are correct however, the fix should have been pushed via the open
repo. In order to avoid this issue in that repo I have approved the
14u fix request.

I think it would make sense for Sibabrata or I to push that changeset to
the open repo if you have no objections.

    -Rob

On 03/03/20 17:51, Aleksey Shipilev wrote:
> Hi,
> 
> Today, I had requested 14u backport for:
>   https://bugs.openjdk.java.net/browse/JDK-8225130
> 
> ...and got jdk14u-fix-yes. Imagine my surprise when I saw the 14.0.2 backport already done today:
>   https://bugs.openjdk.java.net/browse/JDK-8240369
> 
> That's odd, but somewhat understandable.
> 
> Yet, there are *no* changesets in public repositories!
>   https://hg.openjdk.java.net/jdk-updates/jdk14u/log?rev=8225130
>   https://hg.openjdk.java.net/jdk-updates/jdk14u/log?rev=8240369
> 
> What gives? Is there some private jdk14u fork that hgupdater work on? Are Oracle committers push to
> 14u without following the Update Releases process?
> 
> -- 
> Thanks,
> -Aleksey
> 

From shade at redhat.com  Tue Mar  3 17:13:46 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Mar 2020 18:13:46 +0100
Subject: [14] JDK-8225130 question
In-Reply-To: <20200303171039.GA9097@yoga>
References: <40a42a82-d4ef-32da-e111-8c4573113434@redhat.com>
 <20200303171039.GA9097@yoga>
Message-ID: <efbef5ca-8dca-0368-d3c2-dc9007588cf9@redhat.com>

On 3/3/20 6:10 PM, Rob McKenna wrote:
> Sibabrata (cc'd) has pushed that fix to the CPU repo after it was
> approved via the cpu fix approval process. (i.e. the approval process
> that applies to all CPU content)
> 
> You are correct however, the fix should have been pushed via the open
> repo. In order to avoid this issue in that repo I have approved the
> 14u fix request.

Yeah, my confusion stems from hgupdater creating 14.0.2, which my push was supposed to create. Not
sure what have happened if I pushed blindly after receiving jdk14u-fix-yes. Probably nothing.

> I think it would make sense for Sibabrata or I to push that changeset to
> the open repo if you have no objections.

Yes, please.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Mar  3 17:29:21 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Mar 2020 18:29:21 +0100
Subject: [14] RFR 8240217: Shenandoah: remove ShenandoahEvacAssist
Message-ID: <d78bed2d-7b4f-5df9-4647-97d94697b4f1@redhat.com>

Original RFE:
  https://bugs.openjdk.java.net/browse/JDK-8240217
  https://hg.openjdk.java.net/jdk/jdk/rev/c005ba590219

14u fix does not apply cleanly due to context changes. This is not a big deal, because the conflict
is in the hunk that removes the entire piece of code. 14u webrev:
  https://cr.openjdk.java.net/~shade/8240217/webrev.14u.01/

Testing: hotspot_gc_shenandoah

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Tue Mar  3 17:41:16 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 3 Mar 2020 18:41:16 +0100
Subject: [14] RFR 8240217: Shenandoah: remove ShenandoahEvacAssist
In-Reply-To: <d78bed2d-7b4f-5df9-4647-97d94697b4f1@redhat.com>
References: <d78bed2d-7b4f-5df9-4647-97d94697b4f1@redhat.com>
Message-ID: <65ac999b-3a97-4bff-f2a0-b3d711c4000b@redhat.com>

Looks good!

Thank you!
Roman


> Original RFE:
>   https://bugs.openjdk.java.net/browse/JDK-8240217
>   https://hg.openjdk.java.net/jdk/jdk/rev/c005ba590219
> 
> 14u fix does not apply cleanly due to context changes. This is not a big deal, because the conflict
> is in the hunk that removes the entire piece of code. 14u webrev:
>   https://cr.openjdk.java.net/~shade/8240217/webrev.14u.01/
> 
> Testing: hotspot_gc_shenandoah
> 


From rob.mckenna at oracle.com  Tue Mar  3 17:45:53 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Tue, 3 Mar 2020 17:45:53 +0000
Subject: [14] JDK-8225130 question
In-Reply-To: <efbef5ca-8dca-0368-d3c2-dc9007588cf9@redhat.com>
References: <40a42a82-d4ef-32da-e111-8c4573113434@redhat.com>
 <20200303171039.GA9097@yoga>
 <efbef5ca-8dca-0368-d3c2-dc9007588cf9@redhat.com>
Message-ID: <20200303174552.GB9097@yoga>

A hgupdater comment would simply have been added to the 14.0.2 record
noting your push.

    -Rob

On 03/03/20 18:13, Aleksey Shipilev wrote:
> On 3/3/20 6:10 PM, Rob McKenna wrote:
> > Sibabrata (cc'd) has pushed that fix to the CPU repo after it was
> > approved via the cpu fix approval process. (i.e. the approval process
> > that applies to all CPU content)
> > 
> > You are correct however, the fix should have been pushed via the open
> > repo. In order to avoid this issue in that repo I have approved the
> > 14u fix request.
> 
> Yeah, my confusion stems from hgupdater creating 14.0.2, which my push was supposed to create. Not
> sure what have happened if I pushed blindly after receiving jdk14u-fix-yes. Probably nothing.
> 
> > I think it would make sense for Sibabrata or I to push that changeset to
> > the open repo if you have no objections.
> 
> Yes, please.
> 
> -- 
> Thanks,
> -Aleksey
> 




From shade at redhat.com  Tue Mar  3 18:29:02 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 3 Mar 2020 19:29:02 +0100
Subject: [14] RFR 8240217: Shenandoah: remove ShenandoahEvacAssist
In-Reply-To: <65ac999b-3a97-4bff-f2a0-b3d711c4000b@redhat.com>
References: <d78bed2d-7b4f-5df9-4647-97d94697b4f1@redhat.com>
 <65ac999b-3a97-4bff-f2a0-b3d711c4000b@redhat.com>
Message-ID: <77f12493-a02e-2855-e301-c8fa89940d16@redhat.com>

Thanks, added fix-request.

-Aleksey

On 3/3/20 6:41 PM, Roman Kennke wrote:
> Looks good!
> 
> Thank you!
> Roman
> 
> 
>> Original RFE:
>>   https://bugs.openjdk.java.net/browse/JDK-8240217
>>   https://hg.openjdk.java.net/jdk/jdk/rev/c005ba590219
>>
>> 14u fix does not apply cleanly due to context changes. This is not a big deal, because the conflict
>> is in the hunk that removes the entire piece of code. 14u webrev:
>>   https://cr.openjdk.java.net/~shade/8240217/webrev.14u.01/
>>
>> Testing: hotspot_gc_shenandoah



From alexey.menkov at oracle.com  Tue Mar  3 23:56:45 2020
From: alexey.menkov at oracle.com (Alex Menkov)
Date: Tue, 3 Mar 2020 15:56:45 -0800
Subject: [13u-communication] CFV: 13u lead maintainer nomination for Yuri
 Nesterenko
In-Reply-To: <20200226181202.GE24113@yoga>
References: <20200226181202.GE24113@yoga>
Message-ID: <0b866048-7948-3887-61d4-2ca38b321dd5@oracle.com>

Vote: yes

--alex

On 02/26/2020 10:12, Rob McKenna wrote:
> As the Project Lead, I would like to ask for your vote for the
> nomination [0] of Yuri Nesterenko as future lead maintainer.
> 
> Votes are due by the 3rd of March.
> 
> Only current JDK Updates Committers [1] are eligible to vote
> on this nomination.  Votes must be cast in the open by replying
> "Vote: yes" to this mail.
> 
> For Lazy Consensus voting instructions, see [2].
> 
>    -Rob
> 
> [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002535.html
> [1] http://openjdk.java.net/census
> [2] http://openjdk.java.net/bylaws#lazy-consensus
> 

From matthias.baesken at sap.com  Wed Mar  4 12:41:05 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 4 Mar 2020 12:41:05 +0000
Subject: [11u] RFR: 8193879: Java debugger hangs on method invocation
In-Reply-To: <AM0PR02MB57140ABC135E8BBED75E91578AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57140ABC135E8BBED75E91578AE40@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB42279ED4A32C7486D8725DA993E50@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hi Christoph, looks good to me !

Best regards, Matthias



From: Langer, Christoph <christoph.langer at sap.com>
Sent: Dienstag, 3. M?rz 2020 16:03
To: jdk-updates-dev at openjdk.java.net
Cc: Baesken, Matthias <matthias.baesken at sap.com>
Subject: [11u] RFR: 8193879: Java debugger hangs on method invocation

Hi,

please review the backport of this JDI fix. The bug was recently opened by Oracle (was private before) and it already contained the jdk11u-fix-request and approval labels. So I looked into backporting. The change did not apply cleanly. The hunk for test/jdk/com/sun/jdi/lib/jdb/JdbTest.java does not apply since the file does not exist in 11u. In the test "test/jdk/com/sun/jdi/MethodInvokeWithTraceOnTest.java", I had to inline the method parseBreakpoints from JdbTest.java and also the coding of getTestSourcePath() which are used in head jdk/jdk.

With these modifications, the patch successfully runs through our testing and the new testcase passes.

Bug: https://bugs.openjdk.java.net/browse/JDK-8193879
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8193879.11u/

Best regards
Christoph


From matthias.baesken at sap.com  Wed Mar  4 15:00:44 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 4 Mar 2020 15:00:44 +0000
Subject: RFR [jdk11]: 8226795: compiler/tiered/Level2RecompilationTest.java
 fails when XX:TieredStopAtLevel=1/2/3 is set
Message-ID: <AM0PR02MB4227558FD9D59D966B74779C93E50@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello, please review  this downport of   8226795: compiler/tiered/Level2RecompilationTest.java fails when XX:TieredStopAtLevel=1/2/3 is set
To jdk11 .  I would like to have it in jdk11 too because it is in Oracle JDK11.

The patch applies mostly,  but  file   OSRFailureLevel4Test.java  is not in jdk11 ,
and there are changes in the  lines around  the patched lines so manual intervention is needed .



Bug :

https://bugs.openjdk.java.net/browse/JDK-8226795

Original webrev  :

https://hg.openjdk.java.net/jdk/jdk/rev/f1a5d48d0471

Jdk11 webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8226795_0_jdk11/



Thanks, Matthias

From rob.mckenna at oracle.com  Wed Mar  4 19:13:46 2020
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 4 Mar 2020 19:13:46 +0000
Subject: [13u Communication] New Lead Maintainer for the JDK13 Updates
 repository: Yuri Nesterenko
Message-ID: <20200304191346.GF9097@yoga>

Voting for Yuri Nesterenko as the new Lead Maintainer [0] for the JDK13
Updates repository has now closed.

Yes: 15
Veto: 0
Abstain: 0
Invalid: 1

According to the Bylaws definition of Lazy Consensus [1], this is
sufficient to approve the nomination.

[0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002598.html
[1] https://openjdk.java.net/bylaws#lazy-consensus

    -Rob


From rwestrel at redhat.com  Thu Mar  5 14:21:45 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 05 Mar 2020 15:21:45 +0100
Subject: [11u] RFR 8214862: assert(proj != __null) at compile.cpp:3251
Message-ID: <878skenapy.fsf@redhat.com>


Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8214862
  https://bugs.openjdk.java.net/browse/JDK-8214862
 
Original patch does not apply cleanly to 11u because for a couple of
files (compile.hpp and node.cpp) the code around the changed lines
doesn't strictly match what's recorded in the patch. The resulting
change is otherwise identical to the initial patch.
 
11u webrev:
  http://cr.openjdk.java.net/~roland/8214862.11u/webrev.00/
 
Testing: x86_64 build, verified new test fails without the patch and
runs fine with it, tier2
 
Thanks,
-Monty


From rwestrel at redhat.com  Thu Mar  5 14:32:10 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 05 Mar 2020 15:32:10 +0100
Subject: [11u] RFR 8214862: assert(proj != __null) at compile.cpp:3251
In-Reply-To: <878skenapy.fsf@redhat.com>
References: <878skenapy.fsf@redhat.com>
Message-ID: <874kv2na8l.fsf@redhat.com>


> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8214862

The initial change is:

http://hg.openjdk.java.net/jdk/jdk12/rev/c14b7b6a9b2f

Roland.


From rwestrel at redhat.com  Thu Mar  5 14:37:28 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 05 Mar 2020 15:37:28 +0100
Subject: [11u] RFR 8231550: C2: ShouldNotReachHere() in
 verify_strip_mined_scheduling
Message-ID: <8736amn9zr.fsf@redhat.com>


Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8231550
  https://hg.openjdk.java.net/jdk/jdk/rev/bada0782842a

Original patch does not apply cleanly to 11u because:

- in file loopnode.cpp, the implementation of
  PhaseIdealLoop::get_late_ctrl() is slightly different. Applied change
  is otherwise identical to original patch.

- the patch includes a shenandoah change that doesn't apply for 11u

- I add to provide an implementation for LoadBarrierNode::adr_type() for
  ZGC

11u webrev:
  http://cr.openjdk.java.net/~roland/8231550.11u/webrev.00/

Testing: x86_64 build, verified new test fails without the patch and
runs fine with it, tier2

Roland.


From vladimir.kozlov at oracle.com  Thu Mar  5 17:44:54 2020
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 5 Mar 2020 09:44:54 -0800
Subject: [11u] RFR 8214862: assert(proj != __null) at compile.cpp:3251
In-Reply-To: <878skenapy.fsf@redhat.com>
References: <878skenapy.fsf@redhat.com>
Message-ID: <8a79911d-4465-2a1d-ee84-c4d81d082aef@oracle.com>

Good.

Thanks,
Vladimir

On 3/5/20 6:21 AM, Roland Westrelin wrote:
> 
> Original bug:
>    https://bugs.openjdk.java.net/browse/JDK-8214862
>    https://bugs.openjdk.java.net/browse/JDK-8214862
>   
> Original patch does not apply cleanly to 11u because for a couple of
> files (compile.hpp and node.cpp) the code around the changed lines
> doesn't strictly match what's recorded in the patch. The resulting
> change is otherwise identical to the initial patch.
>   
> 11u webrev:
>    http://cr.openjdk.java.net/~roland/8214862.11u/webrev.00/
>   
> Testing: x86_64 build, verified new test fails without the patch and
> runs fine with it, tier2
>   
> Thanks,
> -Monty
> 

From gnu.andrew at redhat.com  Fri Mar  6 08:24:11 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 6 Mar 2020 08:24:11 +0000
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
Message-ID: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>

I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.

Simon has done work in the main JDK project [1] as well as backporting
work for  [2]. Making him a committer would aid this backporting work
by avoiding the need for someone else to push his fixes.

Votes are due by 21h00 UTC on the 20th of March, 2020.

Only current OpenJDK Updates Committers (and above) [3] 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 [4].

[0] https://openjdk.java.net/census#stooke
[1]
https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
[2]
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
[3] https://openjdk.java.net/census#jdk-updates
[4] http://openjdk.java.net/projects/#committer-vote

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 Mar  6 08:25:08 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 6 Mar 2020 08:25:08 +0000
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <4ba424c7-fcc8-0715-a62a-ec2c02ed7cff@redhat.com>



On 06/03/2020 08:24, Andrew Hughes wrote:
> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.
> 
> Simon has done work in the main JDK project [1] as well as backporting
> work for  [2]. Making him a committer would aid this backporting work
> by avoiding the need for someone else to push his fixes.
> 
> Votes are due by 21h00 UTC on the 20th of March, 2020.
> 
> Only current OpenJDK Updates Committers (and above) [3] 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 [4].
> 
> [0] https://openjdk.java.net/census#stooke
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [2]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [3] https://openjdk.java.net/census#jdk-updates
> [4] http://openjdk.java.net/projects/#committer-vote
> 
> Thanks,
> 

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 matthias.baesken at sap.com  Fri Mar  6 08:47:45 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 6 Mar 2020 08:47:45 +0000
Subject: RFR [jdk11]: 8226795:
 compiler/tiered/Level2RecompilationTest.java fails when
 XX:TieredStopAtLevel=1/2/3 is set
Message-ID: <AM0PR02MB4227372661F5029BE5D175F693E30@AM0PR02MB4227.eurprd02.prod.outlook.com>

Ping, may I get a review please ?



From: Baesken, Matthias
Sent: Mittwoch, 4. M?rz 2020 16:01
To: jdk-updates-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RFR [jdk11]: 8226795: compiler/tiered/Level2RecompilationTest.java fails when XX:TieredStopAtLevel=1/2/3 is set

Hello, please review  this downport of   8226795: compiler/tiered/Level2RecompilationTest.java fails when XX:TieredStopAtLevel=1/2/3 is set
To jdk11 .  I would like to have it in jdk11 too because it is in Oracle JDK11.

The patch applies mostly,  but  file   OSRFailureLevel4Test.java  is not in jdk11 ,
and there are changes in the  lines around  the patched lines so manual intervention is needed .



Bug :

https://bugs.openjdk.java.net/browse/JDK-8226795

Original webrev  :

https://hg.openjdk.java.net/jdk/jdk/rev/f1a5d48d0471

Jdk11 webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8226795_0_jdk11/



Thanks, Matthias

From goetz.lindenmaier at sap.com  Fri Mar  6 09:21:04 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Mar 2020 09:21:04 +0000
Subject: RFR [jdk11]: 8226795:
 compiler/tiered/Level2RecompilationTest.java fails when
 XX:TieredStopAtLevel=1/2/3 is set
In-Reply-To: <AM0PR02MB4227372661F5029BE5D175F693E30@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227372661F5029BE5D175F693E30@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB60497629CC88A239DBE0D88DECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

basically, the webrev looks good. 

But it's a pity you must skip the fix to OSRFailureLevel4Test.java.
This test was introduced by "8225019: Update JVMCI" which 
should be downported to 11, too. 
If 8225019 is downported later, we will omit the patch to the test.
Unfortunately, the test fails with current 11. Else I would 
have proposed to downport the whole test.

Maybe we should postpone this and ping once more for 
someone to downport 8225019 first?

Anyways, this is not critical for 11.0.7 as it's only a testbug, 
as you stated before, Matthias.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Freitag, 6. M?rz 2020 09:48
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: RFR [jdk11]: 8226795:
> compiler/tiered/Level2RecompilationTest.java fails when
> XX:TieredStopAtLevel=1/2/3 is set
> 
> Ping, may I get a review please ?
> 
> 
> 
> From: Baesken, Matthias
> Sent: Mittwoch, 4. M?rz 2020 16:01
> To: jdk-updates-dev at openjdk.java.net
> Cc: Langer, Christoph <christoph.langer at sap.com>
> Subject: RFR [jdk11]: 8226795: compiler/tiered/Level2RecompilationTest.java
> fails when XX:TieredStopAtLevel=1/2/3 is set
> 
> Hello, please review  this downport of   8226795:
> compiler/tiered/Level2RecompilationTest.java fails when
> XX:TieredStopAtLevel=1/2/3 is set
> To jdk11 .  I would like to have it in jdk11 too because it is in Oracle JDK11.
> 
> The patch applies mostly,  but  file   OSRFailureLevel4Test.java  is not in jdk11 ,
> and there are changes in the  lines around  the patched lines so manual
> intervention is needed .
> 
> 
> 
> Bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8226795
> 
> Original webrev  :
> 
> https://hg.openjdk.java.net/jdk/jdk/rev/f1a5d48d0471
> 
> Jdk11 webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8226795_0_jdk11/
> 
> 
> 
> Thanks, Matthias

From christoph.langer at sap.com  Fri Mar  6 09:26:23 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 6 Mar 2020 09:26:23 +0000
Subject: RFR [jdk11]: 8226795:
 compiler/tiered/Level2RecompilationTest.java fails when
 XX:TieredStopAtLevel=1/2/3 is set
In-Reply-To: <AM7PR02MB60497629CC88A239DBE0D88DECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227372661F5029BE5D175F693E30@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM7PR02MB60497629CC88A239DBE0D88DECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714E5680C2304193D026CB88AE30@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

in that case I'd opt for deferring this patch and try to get some traction on backporting JDK-8225019 first.

Best regards
Christoph

-----Original Message-----
From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com> 
Sent: Freitag, 6. M?rz 2020 10:21
To: Baesken, Matthias <matthias.baesken at sap.com>; jdk-updates-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: RFR [jdk11]: 8226795: compiler/tiered/Level2RecompilationTest.java fails when XX:TieredStopAtLevel=1/2/3 is set

Hi,

basically, the webrev looks good. 

But it's a pity you must skip the fix to OSRFailureLevel4Test.java.
This test was introduced by "8225019: Update JVMCI" which 
should be downported to 11, too. 
If 8225019 is downported later, we will omit the patch to the test.
Unfortunately, the test fails with current 11. Else I would 
have proposed to downport the whole test.

Maybe we should postpone this and ping once more for 
someone to downport 8225019 first?

Anyways, this is not critical for 11.0.7 as it's only a testbug, 
as you stated before, Matthias.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Freitag, 6. M?rz 2020 09:48
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: RFR [jdk11]: 8226795:
> compiler/tiered/Level2RecompilationTest.java fails when
> XX:TieredStopAtLevel=1/2/3 is set
> 
> Ping, may I get a review please ?
> 
> 
> 
> From: Baesken, Matthias
> Sent: Mittwoch, 4. M?rz 2020 16:01
> To: jdk-updates-dev at openjdk.java.net
> Cc: Langer, Christoph <christoph.langer at sap.com>
> Subject: RFR [jdk11]: 8226795: compiler/tiered/Level2RecompilationTest.java
> fails when XX:TieredStopAtLevel=1/2/3 is set
> 
> Hello, please review  this downport of   8226795:
> compiler/tiered/Level2RecompilationTest.java fails when
> XX:TieredStopAtLevel=1/2/3 is set
> To jdk11 .  I would like to have it in jdk11 too because it is in Oracle JDK11.
> 
> The patch applies mostly,  but  file   OSRFailureLevel4Test.java  is not in jdk11 ,
> and there are changes in the  lines around  the patched lines so manual
> intervention is needed .
> 
> 
> 
> Bug :
> 
> https://bugs.openjdk.java.net/browse/JDK-8226795
> 
> Original webrev  :
> 
> https://hg.openjdk.java.net/jdk/jdk/rev/f1a5d48d0471
> 
> Jdk11 webrev :
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8226795_0_jdk11/
> 
> 
> 
> Thanks, Matthias

From sgehwolf at redhat.com  Fri Mar  6 09:44:50 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Mar 2020 10:44:50 +0100
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <4e123d244c8497886600cfeeeeda5a41e54172b0.camel@redhat.com>

Vote: yes.

On Fri, 2020-03-06 at 08:24 +0000, Andrew Hughes wrote:
> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.
> 
> Simon has done work in the main JDK project [1] as well as backporting
> work for  [2]. Making him a committer would aid this backporting work
> by avoiding the need for someone else to push his fixes.
> 
> Votes are due by 21h00 UTC on the 20th of March, 2020.
> 
> Only current OpenJDK Updates Committers (and above) [3] 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 [4].
> 
> [0] https://openjdk.java.net/census#stooke
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [2]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [3] https://openjdk.java.net/census#jdk-updates
> [4] http://openjdk.java.net/projects/#committer-vote
> 
> Thanks,


From christoph.langer at sap.com  Fri Mar  6 09:53:38 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 6 Mar 2020 09:53:38 +0000
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <AM0PR02MB5714A03D355B1E163A1001D88AE30@AM0PR02MB5714.eurprd02.prod.outlook.com>

Vote: yes

/Christoph

-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of Andrew Hughes
Sent: Freitag, 6. M?rz 2020 09:24
To: jdk-updates-dev at openjdk.java.net
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke

I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.

Simon has done work in the main JDK project [1] as well as backporting
work for  [2]. Making him a committer would aid this backporting work
by avoiding the need for someone else to push his fixes.

Votes are due by 21h00 UTC on the 20th of March, 2020.

Only current OpenJDK Updates Committers (and above) [3] 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 [4].

[0] https://openjdk.java.net/census#stooke
[1]
https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
[2]
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
[3] https://openjdk.java.net/census#jdk-updates
[4] http://openjdk.java.net/projects/#committer-vote

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 goetz.lindenmaier at sap.com  Fri Mar  6 09:56:32 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Mar 2020 09:56:32 +0000
Subject: Help with downporting 8225019: Update JVMCI
In-Reply-To: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049946F429C58FA14DF6CD9ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

is there anybody in the community that is interested in JVMCI 
in jdk11u and could look into downporting this change?

If someone supplies the patch, I'll test and sponsor it.

Best regards,
  Goetz.




> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Freitag, 3. Januar 2020 17:33
> To: jdk-updates-dev at openjdk.java.net
> Cc: 'graal-dev at openjdk.java.net' <graal-dev at openjdk.java.net>; hotspot-
> compiler-dev at openjdk.java.net
> Subject: Help with downporting 8225019: Update JVMCI
> 
> Hi,
> 
> I am working on downporting 11.0.7-oracle fixes to OpenJDK
> 11.0.7.
> 
> I encountered "8225019: Update JVMCI" which is applying badly.
> It has lots of rejects. There are various places that are not
>  trivial to resolve.
> 
> I don't have any background in JVMCI/AOT and SAP does
> not use it (yet).
> I would appreciate if someone with appropriate background
> or interest could step up and bring this change to jdk11u-dev.
> 
> https://bugs.openjdk.java.net/browse/JDK-8225019
> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> May/034050.html
> 
> Best regards,
>   Goetz.

From yan at azul.com  Fri Mar  6 10:00:33 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Fri, 6 Mar 2020 13:00:33 +0300
Subject: [13u Communication] New Lead Maintainer for the JDK13 Updates
 repository: Yuri Nesterenko
In-Reply-To: <20200304191346.GF9097@yoga>
References: <20200304191346.GF9097@yoga>
Message-ID: <27c7cb00-c7e1-c0e9-668f-5f75786fbba3@azul.com>

Dear colleagues,
thank you! I'll try to do my best in this role.

--yan

On 04.03.2020 22:13, Rob McKenna wrote:
> Voting for Yuri Nesterenko as the new Lead Maintainer [0] for the JDK13
> Updates repository has now closed.
> 
> Yes: 15
> Veto: 0
> Abstain: 0
> Invalid: 1
> 
> According to the Bylaws definition of Lazy Consensus [1], this is
> sufficient to approve the nomination.
> 
> [0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002598.html
> [1] https://openjdk.java.net/bylaws#lazy-consensus
> 
>     -Rob
> 


From adinn at redhat.com  Fri Mar  6 10:35:16 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 6 Mar 2020 10:35:16 +0000
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <05b7feaa-aa9e-6579-3851-529af0aa8a9a@redhat.com>

Vote: yes

On 06/03/2020 08:24, Andrew Hughes wrote:
> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.
> 
> Simon has done work in the main JDK project [1] as well as backporting
> work for  [2]. Making him a committer would aid this backporting work
> by avoiding the need for someone else to push his fixes.
> 
> Votes are due by 21h00 UTC on the 20th of March, 2020.
> 
> Only current OpenJDK Updates Committers (and above) [3] 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 [4].
> 
> [0] https://openjdk.java.net/census#stooke
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [2]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [3] https://openjdk.java.net/census#jdk-updates
> [4] http://openjdk.java.net/projects/#committer-vote
> 
> Thanks,
> 

-- 
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 goetz.lindenmaier at sap.com  Fri Mar  6 10:41:36 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Mar 2020 10:41:36 +0000
Subject: [11u] RFR(S): 8232357: Compare version info of Santuario to legal
 notice
Message-ID: <AM7PR02MB6049BE60FD61BE3D86A6DCDEECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

I want to downport this for parity with 11.0.8-oracle.

Unfortunately the test uses Files.mismatch(), which is not
available in 11.
I copied the implementation of that method into the test
which fixes the issue.
Also, the comment is already there in XMLDSigRI.java, so
I omitted that:
http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/file/1e534c8cf25c/src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java#l138

Please review.
http://cr.openjdk.java.net/~goetz/wr20/8232357-Santuario_test-jdk11/01/

Original change:
https://bugs.openjdk.java.net/browse/JDK-8232357
https://hg.openjdk.java.net/jdk/jdk/rev/7322c48a84cf

Best regards,
  Goetz


From rwestrel at redhat.com  Fri Mar  6 10:49:10 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 06 Mar 2020 11:49:10 +0100
Subject: [11u] RFR 8214862: assert(proj != __null) at compile.cpp:3251
In-Reply-To: <8a79911d-4465-2a1d-ee84-c4d81d082aef@oracle.com>
References: <878skenapy.fsf@redhat.com>
 <8a79911d-4465-2a1d-ee84-c4d81d082aef@oracle.com>
Message-ID: <87o8t9lpw9.fsf@redhat.com>


Thanks for the review.

Roland.


From volker.simonis at gmail.com  Fri Mar  6 12:14:53 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 6 Mar 2020 13:14:53 +0100
Subject: Help with downporting 8225019: Update JVMCI
In-Reply-To: <AM7PR02MB6049946F429C58FA14DF6CD9ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <AM7PR02MB6049946F429C58FA14DF6CD9ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <CA+3eh11Z3Gc7Z7kSBzJbO7G_7qEu7iENosomZLtNK+=2GHppFQ@mail.gmail.com>

Hi Goetz,

I think Severin has recently started to work on this issue:
https://github.com/oracle/graal/issues/2196#issuecomment-593304532

Best regards,
Volker

On Fri, Mar 6, 2020 at 10:57 AM Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi,
>
> is there anybody in the community that is interested in JVMCI
> in jdk11u and could look into downporting this change?
>
> If someone supplies the patch, I'll test and sponsor it.
>
> Best regards,
>   Goetz.
>
>
>
>
> > -----Original Message-----
> > From: Lindenmaier, Goetz
> > Sent: Freitag, 3. Januar 2020 17:33
> > To: jdk-updates-dev at openjdk.java.net
> > Cc: 'graal-dev at openjdk.java.net' <graal-dev at openjdk.java.net>; hotspot-
> > compiler-dev at openjdk.java.net
> > Subject: Help with downporting 8225019: Update JVMCI
> >
> > Hi,
> >
> > I am working on downporting 11.0.7-oracle fixes to OpenJDK
> > 11.0.7.
> >
> > I encountered "8225019: Update JVMCI" which is applying badly.
> > It has lots of rejects. There are various places that are not
> >  trivial to resolve.
> >
> > I don't have any background in JVMCI/AOT and SAP does
> > not use it (yet).
> > I would appreciate if someone with appropriate background
> > or interest could step up and bring this change to jdk11u-dev.
> >
> > https://bugs.openjdk.java.net/browse/JDK-8225019
> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> > May/034050.html
> >
> > Best regards,
> >   Goetz.
>

From shade at redhat.com  Fri Mar  6 12:47:01 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Mar 2020 13:47:01 +0100
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <3c3afbe3-1915-fca6-e73c-fb77a567a076@redhat.com>

Vote: yes

On 3/6/20 9:24 AM, Andrew Hughes wrote:
> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Fri Mar  6 12:47:21 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Mar 2020 13:47:21 +0100
Subject: Help with downporting 8225019: Update JVMCI
In-Reply-To: <CA+3eh11Z3Gc7Z7kSBzJbO7G_7qEu7iENosomZLtNK+=2GHppFQ@mail.gmail.com>
References: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <AM7PR02MB6049946F429C58FA14DF6CD9ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <CA+3eh11Z3Gc7Z7kSBzJbO7G_7qEu7iENosomZLtNK+=2GHppFQ@mail.gmail.com>
Message-ID: <6e28fbc37eb96ce90437316c7bf0b114fb56b042.camel@redhat.com>

Hi,

On Fri, 2020-03-06 at 13:14 +0100, Volker Simonis wrote:
> Hi Goetz,
> 
> I think Severin has recently started to work on this issue:
> https://github.com/oracle/graal/issues/2196#issuecomment-593304532

Yes, but it's unclear whether or not we'll complete this for 11.0.7. 
11.0.8+ seems more likely at this point.

Thanks,
Severin

> Best regards,
> Volker
> 
> On Fri, Mar 6, 2020 at 10:57 AM Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> > Hi,
> > 
> > is there anybody in the community that is interested in JVMCI 
> > in jdk11u and could look into downporting this change?
> > 
> > If someone supplies the patch, I'll test and sponsor it.
> > 
> > Best regards,
> >   Goetz.
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Lindenmaier, Goetz
> > > Sent: Freitag, 3. Januar 2020 17:33
> > > To: jdk-updates-dev at openjdk.java.net
> > > Cc: 'graal-dev at openjdk.java.net' <graal-dev at openjdk.java.net>; hotspot-
> > > compiler-dev at openjdk.java.net
> > > Subject: Help with downporting 8225019: Update JVMCI
> > > 
> > > Hi,
> > > 
> > > I am working on downporting 11.0.7-oracle fixes to OpenJDK
> > > 11.0.7.
> > > 
> > > I encountered "8225019: Update JVMCI" which is applying badly.
> > > It has lots of rejects. There are various places that are not
> > >  trivial to resolve.
> > > 
> > > I don't have any background in JVMCI/AOT and SAP does
> > > not use it (yet).
> > > I would appreciate if someone with appropriate background
> > > or interest could step up and bring this change to jdk11u-dev.
> > > 
> > > https://bugs.openjdk.java.net/browse/JDK-8225019
> > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> > > May/034050.html
> > > 
> > > Best regards,
> > >   Goetz.


From goetz.lindenmaier at sap.com  Fri Mar  6 12:57:37 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Mar 2020 12:57:37 +0000
Subject: Help with downporting 8225019: Update JVMCI
In-Reply-To: <6e28fbc37eb96ce90437316c7bf0b114fb56b042.camel@redhat.com>
References: <VE1PR02MB5422C0155A40F8C742099109EC230@VE1PR02MB5422.eurprd02.prod.outlook.com>
 <AM7PR02MB6049946F429C58FA14DF6CD9ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <CA+3eh11Z3Gc7Z7kSBzJbO7G_7qEu7iENosomZLtNK+=2GHppFQ@mail.gmail.com>
 <6e28fbc37eb96ce90437316c7bf0b114fb56b042.camel@redhat.com>
Message-ID: <AM7PR02MB60499262035E73640805A0CBECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Severin,

that's great!  
11.0.8 is fine obviously!
This is good to know because then it makes sense to 
postpone changes that depend on it.

Best regards,
  Goetz.

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Freitag, 6. M?rz 2020 13:47
> To: Volker Simonis <volker.simonis at gmail.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net; hotspot-compiler-
> dev at openjdk.java.net; graal-dev at openjdk.java.net
> Subject: Re: Help with downporting 8225019: Update JVMCI
> 
> Hi,
> 
> On Fri, 2020-03-06 at 13:14 +0100, Volker Simonis wrote:
> > Hi Goetz,
> >
> > I think Severin has recently started to work on this issue:
> > https://github.com/oracle/graal/issues/2196#issuecomment-593304532
> 
> Yes, but it's unclear whether or not we'll complete this for 11.0.7.
> 11.0.8+ seems more likely at this point.
> 
> Thanks,
> Severin
> 
> > Best regards,
> > Volker
> >
> > On Fri, Mar 6, 2020 at 10:57 AM Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> > > Hi,
> > >
> > > is there anybody in the community that is interested in JVMCI
> > > in jdk11u and could look into downporting this change?
> > >
> > > If someone supplies the patch, I'll test and sponsor it.
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Lindenmaier, Goetz
> > > > Sent: Freitag, 3. Januar 2020 17:33
> > > > To: jdk-updates-dev at openjdk.java.net
> > > > Cc: 'graal-dev at openjdk.java.net' <graal-dev at openjdk.java.net>; hotspot-
> > > > compiler-dev at openjdk.java.net
> > > > Subject: Help with downporting 8225019: Update JVMCI
> > > >
> > > > Hi,
> > > >
> > > > I am working on downporting 11.0.7-oracle fixes to OpenJDK
> > > > 11.0.7.
> > > >
> > > > I encountered "8225019: Update JVMCI" which is applying badly.
> > > > It has lots of rejects. There are various places that are not
> > > >  trivial to resolve.
> > > >
> > > > I don't have any background in JVMCI/AOT and SAP does
> > > > not use it (yet).
> > > > I would appreciate if someone with appropriate background
> > > > or interest could step up and bring this change to jdk11u-dev.
> > > >
> > > > https://bugs.openjdk.java.net/browse/JDK-8225019
> > > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-
> > > > May/034050.html
> > > >
> > > > Best regards,
> > > >   Goetz.


From zgu at redhat.com  Fri Mar  6 13:51:41 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Fri, 6 Mar 2020 08:51:41 -0500
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <6fc98405-c232-1c01-5e51-dc40bede22c2@redhat.com>

Vote: yes

-Zhengyu

On 3/6/20 3:24 AM, Andrew Hughes wrote:
> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.
> 
> Simon has done work in the main JDK project [1] as well as backporting
> work for  [2]. Making him a committer would aid this backporting work
> by avoiding the need for someone else to push his fixes.
> 
> Votes are due by 21h00 UTC on the 20th of March, 2020.
> 
> Only current OpenJDK Updates Committers (and above) [3] 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 [4].
> 
> [0] https://openjdk.java.net/census#stooke
> [1]
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [2]
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [3] https://openjdk.java.net/census#jdk-updates
> [4] http://openjdk.java.net/projects/#committer-vote
> 
> Thanks,
> 


From matthias.baesken at sap.com  Fri Mar  6 14:33:20 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 6 Mar 2020 14:33:20 +0000
Subject: [jdk11] 8233649: Update ProblemList.txt to exclude failing headful
 tests on macos
Message-ID: <AM0PR02MB4227813A1CCED0710D57752893E30@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello, please review the jdk11 downport of    "8233649: Update ProblemList.txt to exclude failing headful tests on macos"  .
This change is in Oracle jdk 11.0.7 so it is beneficial to have it in OpenJDK 11 as well .

The patch did not apply cleanly so I had to adjust it a bit .


Bug/  jdk11  webrev :

https://bugs.openjdk.java.net/browse/JDK-8233649

http://cr.openjdk.java.net/~mbaesken/webrevs/8233649_0_jdk11/


old jdk/jdk webrev :   https://hg.openjdk.java.net/jdk/jdk/rev/119ae24bce3e


Thanks, Matthias




From shade at redhat.com  Fri Mar  6 15:20:50 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Mar 2020 16:20:50 +0100
Subject: [11u] RFR (S) 8231118: ARM32: Math tests failures
Message-ID: <fdded045-8446-5aad-265f-1277c3521133@redhat.com>

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8231118
  https://hg.openjdk.java.net/jdk/jdk/rev/f82f59ef79f0

Patch applies almost cleanly, but runs into conflict in sharedRuntime_arm.cpp, where jdk11u still
has Oracle's AArch64 port. Applied those hunks by hand. 11u webrev:
  https://cr.openjdk.java.net/~shade/8231118/webrev.11u.01/

Testing: arm32 cross build, spot-checking Math tests

-- 
Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Fri Mar  6 15:33:43 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Mar 2020 15:33:43 +0000
Subject: [jdk11] 8233649: Update ProblemList.txt to exclude failing
 headful tests on macos
In-Reply-To: <AM0PR02MB4227813A1CCED0710D57752893E30@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227813A1CCED0710D57752893E30@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049BADB2000AB73BE29E711ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Matthias, 

you are adding two additional excludes:

+javax/swing/JRadioButton/FocusTraversal/FocusTraversal.java 8221902 linux-all,macosx-all

+sanity/client/SwingSet/src/ToolTipDemoTest.java 8225012 windows-all,macosx-all

the excludes for linux-all and windows-all are not in the original change.

They were added here:
8222097: ProblemList tests that are failing recurringly and intermittently in PIT
https://bugs.openjdk.java.net/browse/JDK-8222097
http://hg.openjdk.java.net/jdk/jdk/rev/a67b9214cfab
and here
8225020: Problem list some sanity test failures
https://bugs.openjdk.java.net/browse/JDK-8225020
http://hg.openjdk.java.net/jdk/jdk/rev/4c730a3b5dd9

which both seem due to continuous failures and not specific
changes in jdk/jdk, so I think it's fine to do these additional 
excludes in 11, too.

So looks good, reviewed.

Best regards,
  Goetz.




> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Freitag, 6. M?rz 2020 15:33
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [jdk11] 8233649: Update ProblemList.txt to exclude failing
> headful tests on macos
> 
> Hello, please review the jdk11 downport of    "8233649: Update ProblemList.txt
> to exclude failing headful tests on macos"  .
> This change is in Oracle jdk 11.0.7 so it is beneficial to have it in OpenJDK 11 as
> well .
> 
> The patch did not apply cleanly so I had to adjust it a bit .
> 
> 
> Bug/  jdk11  webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8233649
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8233649_0_jdk11/
> 
> 
> old jdk/jdk webrev :   https://hg.openjdk.java.net/jdk/jdk/rev/119ae24bce3e
> 
> 
> Thanks, Matthias
> 
> 


From goetz.lindenmaier at sap.com  Fri Mar  6 15:46:31 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 6 Mar 2020 15:46:31 +0000
Subject: [11u] RFR (S) 8231118: ARM32: Math tests failures
In-Reply-To: <fdded045-8446-5aad-265f-1277c3521133@redhat.com>
References: <fdded045-8446-5aad-265f-1277c3521133@redhat.com>
Message-ID: <AM7PR02MB60492A648ED2DE26506AAF51ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Aleksey,

the downport looks fine.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Freitag, 6. M?rz 2020 16:21
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR (S) 8231118: ARM32: Math tests failures
> 
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8231118
>   https://hg.openjdk.java.net/jdk/jdk/rev/f82f59ef79f0
> 
> Patch applies almost cleanly, but runs into conflict in sharedRuntime_arm.cpp,
> where jdk11u still
> has Oracle's AArch64 port. Applied those hunks by hand. 11u webrev:
>   https://cr.openjdk.java.net/~shade/8231118/webrev.11u.01/
> 
> Testing: arm32 cross build, spot-checking Math tests
> 
> --
> Thanks,
> -Aleksey


From shade at redhat.com  Fri Mar  6 16:11:55 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Mar 2020 17:11:55 +0100
Subject: [11u] RFR (S) 8231118: ARM32: Math tests failures
In-Reply-To: <AM7PR02MB60492A648ED2DE26506AAF51ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <fdded045-8446-5aad-265f-1277c3521133@redhat.com>
 <AM7PR02MB60492A648ED2DE26506AAF51ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <026ff86d-9824-1217-5f78-6ddade535752@redhat.com>

On 3/6/20 4:46 PM, Lindenmaier, Goetz wrote:
> the downport looks fine.

Thank you. I added the tags, but I would also wait for Boris to ack this.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Fri Mar  6 16:28:06 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Mar 2020 17:28:06 +0100
Subject: [11u] RFR 8231550: C2: ShouldNotReachHere() in
 verify_strip_mined_scheduling
In-Reply-To: <8736amn9zr.fsf@redhat.com>
References: <8736amn9zr.fsf@redhat.com>
Message-ID: <64cf8466-daab-fd99-df37-7fbd36e906b0@redhat.com>

On 3/5/20 3:37 PM, Roland Westrelin wrote:
> - in file loopnode.cpp, the implementation of
>   PhaseIdealLoop::get_late_ctrl() is slightly different. Applied change
>   is otherwise identical to original patch.

Superficially, it looks good.

> - the patch includes a shenandoah change that doesn't apply for 11u

I added 11-shenandoah to affected-versions to catch that.

> - I add to provide an implementation for LoadBarrierNode::adr_type() for
>   ZGC

This looks safe, but we would probably like Nils to confirm.

-- 
Thanks,
-Aleksey


From shade at redhat.com  Fri Mar  6 16:31:33 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 6 Mar 2020 17:31:33 +0100
Subject: [11u] RFR(S): 8232357: Compare version info of Santuario to legal
 notice
In-Reply-To: <AM7PR02MB6049BE60FD61BE3D86A6DCDEECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB6049BE60FD61BE3D86A6DCDEECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <928d9550-67b9-4c34-9931-aa6e5aa445aa@redhat.com>

On 3/6/20 11:41 AM, Lindenmaier, Goetz wrote:
> Please review.
> http://cr.openjdk.java.net/~goetz/wr20/8232357-Santuario_test-jdk11/01/

Backport looks good. And the test passes, right?

-- 
Thanks,
-Aleksey


From linzang at tencent.com  Fri Mar  6 16:33:10 2020
From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=)
Date: Fri, 6 Mar 2020 16:33:10 +0000
Subject: [11u] fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
Message-ID: <0F19BB76-5DF8-450C-A74E-D201BB9B284B@tencent.com>

Hi,
     The 11u-dev repo fail to build with gcc 6.3.1, error message:
====================================================
        In file included from / Source/jdk11u-dev/src/hotspot/cpu/x86/assembler_x86.inline.hpp:30:0,
                 from / Source/jdk11u-dev/src/hotspot/share/asm/assembler.inline.hpp:30,
                 from / Source/jdk11u-dev/src/hotspot/share/precompiled/precompiled.hpp:32:
/Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp: In member function 'void G1CollectedHeap::complete_cleaning(BoolObjectClosure*, bool)':
/Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp:377:5: error: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     if (_code_blob == NULL) {
     ^~
/Source/jdk11u-dev/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3355:28: note: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' was declared here
     CompiledMethodIterator iter = CompiledMethodIterator();
                            ^~~~
cc1plus: all warnings being treated as errors

The build can success with ?disable-warnings-as-errors  or with simple change:
diff -r e5802f7424cf src/hotspot/share/code/codeCache.hpp
--- a/src/hotspot/share/code/codeCache.hpp      Fri May 24 13:52:33 2019 -0700
+++ b/src/hotspot/share/code/codeCache.hpp      Fri Mar 06 15:00:55 2020 +0800
@@ -322,6 +322,7 @@
  public:
   CodeBlobIterator(T* nm = NULL) {
+    _code_blob = NULL;
     if (Filter::heaps() == NULL) {
       return;
     }
diff -r e5802f7424cf src/hotspot/share/gc/shared/genCollectedHeap.cpp
--- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri May 24 13:52:33 2019 -0700
+++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri Mar 06 15:00:55 2020 +0800
@@ -1146,6 +1146,7 @@
   size_t min_size = 0;   // "first" makes this conceptually infinite.
   ScratchBlock **smallest_ptr, *smallest;
   ScratchBlock  *cur = *prev_ptr;
+  smallest_ptr = NULL;
   while (cur) {
     assert(*prev_ptr == cur, "just checking");
     if (first || cur->num_words < min_size) {
-----------------------------------------------------------

So could this be a fix ?

BRs,
Lin

From sgehwolf at redhat.com  Fri Mar  6 17:11:23 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 06 Mar 2020 18:11:23 +0100
Subject: 11u backport missing binary arrow.png: 8224475: JTextPane does not
 show images in HTML rendering
Message-ID: <6e839d6848e162f44e86fd2b737bd2a6d71d7c8c.camel@redhat.com>

Hi Matthias,

The JDK 11u backport of 8224475 does not include the arrow.png binary
file, while the jdk/jdk push included it.

I was working on the 8u backport and notices an NPE when running the
regression test from 11u due to arrow.png missing.

java.lang.NullPointerException
        at java.desktop/javax.swing.ImageIcon.<init>(ImageIcon.java:217)
        at TestJTextPaneHTMLRendering.createTestUI(TestJTextPaneHTMLRendering.java:148)
        at TestJTextPaneHTMLRendering.createUI(TestJTextPaneHTMLRendering.java:87)
        at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
        at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
        at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
        at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

It would be great if this could get fixed. Perhaps create an 11u
specific bug which just adds the binary?

Thanks,
Severin


From boris.ulasevich at bell-sw.com  Fri Mar  6 20:47:10 2020
From: boris.ulasevich at bell-sw.com (Boris Ulasevich)
Date: Fri, 6 Mar 2020 23:47:10 +0300
Subject: [11u] RFR (S) 8231118: ARM32: Math tests failures
In-Reply-To: <026ff86d-9824-1217-5f78-6ddade535752@redhat.com>
References: <fdded045-8446-5aad-265f-1277c3521133@redhat.com>
 <AM7PR02MB60492A648ED2DE26506AAF51ECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <026ff86d-9824-1217-5f78-6ddade535752@redhat.com>
Message-ID: <CAOhyNwDVd162-C3JovDpDw4HbbjZ7NdcxUwwkhcOSicNoNa+aw@mail.gmail.com>

Hi,

Thank you for doing this!
The change is good.

Boris

On Fri, Mar 6, 2020 at 7:12 PM Aleksey Shipilev <shade at redhat.com> wrote:

> On 3/6/20 4:46 PM, Lindenmaier, Goetz wrote:
> > the downport looks fine.
>
> Thank you. I added the tags, but I would also wait for Boris to ack this.
>
> --
> Thanks,
> -Aleksey
>
>

From neugens.limasoftware at gmail.com  Fri Mar  6 23:38:41 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Sat, 7 Mar 2020 00:38:41 +0100
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <CAGUMyaRyWcjqLvUNBtRb9iPkBrxM1qwQxCfmSTzaUCZzBwHnuw@mail.gmail.com>

Vote: yes

Cheers,
Mario

On Fri 6. Mar 2020 at 09:24, Andrew Hughes <gnu.andrew at redhat.com> wrote:

> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.
>
> Simon has done work in the main JDK project [1] as well as backporting
> work for  [2]. Making him a committer would aid this backporting work
> by avoiding the need for someone else to push his fixes.
>
> Votes are due by 21h00 UTC on the 20th of March, 2020.
>
> Only current OpenJDK Updates Committers (and above) [3] 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 [4].
>
> [0] https://openjdk.java.net/census#stooke
> [1]
>
> https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [2]
>
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
> [3] https://openjdk.java.net/census#jdk-updates
> [4] http://openjdk.java.net/projects/#committer-vote
>
> 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
>
> --
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From linzang at tencent.com  Sun Mar  8 08:23:02 2020
From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=)
Date: Sun, 8 Mar 2020 08:23:02 +0000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized]
Message-ID: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>

I made a tiny patch for this:
Please help to review.
Webrev: http://cr.openjdk.java.net/~lzang/11u/JDK-8240715/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8240715


BRs,
Lin

From: "linzang(??)" <linzang at tencent.com>
Date: Saturday, March 7, 2020 at 12:33 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: [11u] fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]

Hi,
     The 11u-dev repo fail to build with gcc 6.3.1, error message:
====================================================
        In file included from / Source/jdk11u-dev/src/hotspot/cpu/x86/assembler_x86.inline.hpp:30:0,
                 from / Source/jdk11u-dev/src/hotspot/share/asm/assembler.inline.hpp:30,
                 from / Source/jdk11u-dev/src/hotspot/share/precompiled/precompiled.hpp:32:
/Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp: In member function 'void G1CollectedHeap::complete_cleaning(BoolObjectClosure*, bool)':
/Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp:377:5: error: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     if (_code_blob == NULL) {
     ^~
/Source/jdk11u-dev/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3355:28: note: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' was declared here
     CompiledMethodIterator iter = CompiledMethodIterator();
                            ^~~~
cc1plus: all warnings being treated as errors

The build can success with ?disable-warnings-as-errors  or with simple change:
diff -r e5802f7424cf src/hotspot/share/code/codeCache.hpp
--- a/src/hotspot/share/code/codeCache.hpp      Fri May 24 13:52:33 2019 -0700
+++ b/src/hotspot/share/code/codeCache.hpp      Fri Mar 06 15:00:55 2020 +0800
@@ -322,6 +322,7 @@
  public:
   CodeBlobIterator(T* nm = NULL) {
+    _code_blob = NULL;
     if (Filter::heaps() == NULL) {
       return;
     }
diff -r e5802f7424cf src/hotspot/share/gc/shared/genCollectedHeap.cpp
--- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri May 24 13:52:33 2019 -0700
+++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri Mar 06 15:00:55 2020 +0800
@@ -1146,6 +1146,7 @@
   size_t min_size = 0;   // "first" makes this conceptually infinite.
   ScratchBlock **smallest_ptr, *smallest;
   ScratchBlock  *cur = *prev_ptr;
+  smallest_ptr = NULL;
   while (cur) {
     assert(*prev_ptr == cur, "just checking");
     if (first || cur->num_words < min_size) {
-----------------------------------------------------------

So could this be a fix ?

BRs,
Lin

From matthias.baesken at sap.com  Mon Mar  9 08:05:59 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 9 Mar 2020 08:05:59 +0000
Subject: 11u backport missing binary arrow.png: 8224475: JTextPane does
 not show images in HTML rendering
In-Reply-To: <6e839d6848e162f44e86fd2b737bd2a6d71d7c8c.camel@redhat.com>
References: <6e839d6848e162f44e86fd2b737bd2a6d71d7c8c.camel@redhat.com>
Message-ID: <AM0PR02MB42279B490E5F43801D00E78F93FE0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hi Severin, thanks for the heads up.

The jdk11 downport of 8224475 misses binary file test/jdk/javax/swing/JTextPane/arrow.png , this needs to be added to make the test work.


Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8240724

http://cr.openjdk.java.net/~mbaesken/webrevs/8240724_jdk11u/


Thanks, Matthias



> Hi Matthias,
> 
> The JDK 11u backport of 8224475 does not include the arrow.png binary
> file, while the jdk/jdk push included it.
> 
> I was working on the 8u backport and notices an NPE when running the
> regression test from 11u due to arrow.png missing.
> 
> java.lang.NullPointerException
>         at java.desktop/javax.swing.ImageIcon.<init>(ImageIcon.java:217)
>         at
> TestJTextPaneHTMLRendering.createTestUI(TestJTextPaneHTMLRendering.j
> ava:148)
>         at
> TestJTextPaneHTMLRendering.createUI(TestJTextPaneHTMLRendering.java:
> 87)
>         at
> java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java
> :313)
>         at
> java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:77
> 0)
>         at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
>         at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at
> java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doInterse
> ctionPrivilege(ProtectionDomain.java:85)
>         at
> java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
>         at
> java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Event
> DispatchThread.java:203)
>         at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDisp
> atchThread.java:124)
>         at
> java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Event
> DispatchThread.java:113)
>         at
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThr
> ead.java:109)
>         at
> java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThr
> ead.java:101)
>         at
> java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:
> 90)
> 
> It would be great if this could get fixed. Perhaps create an 11u
> specific bug which just adds the binary?
> 
> Thanks,
> Severin


From sgehwolf at redhat.com  Mon Mar  9 09:03:37 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 09 Mar 2020 10:03:37 +0100
Subject: 11u backport missing binary arrow.png: 8224475: JTextPane does
 not show images in HTML rendering
In-Reply-To: <AM0PR02MB42279B490E5F43801D00E78F93FE0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <6e839d6848e162f44e86fd2b737bd2a6d71d7c8c.camel@redhat.com>
 <AM0PR02MB42279B490E5F43801D00E78F93FE0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <4774df494cbc655b3b23bfac6b8f36481ee111b8.camel@redhat.com>

On Mon, 2020-03-09 at 08:05 +0000, Baesken, Matthias wrote:
> Bug/webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8240724
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8240724_jdk11u/

Looks good. Thanks for fixing this.

Cheers,
Severin


From christoph.langer at sap.com  Mon Mar  9 09:15:00 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 09:15:00 +0000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized]
In-Reply-To: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
References: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
Message-ID: <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Lin,

I compared the coding that you touch to the current versions in head and the code there seems quite the same or at least similar in regards to the possible warnings.

I rather suggest you do the change in jdk/jdk first and we'd then backport it? Or is there anything which speaks against doing this in head?

Cheers
Christoph


-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of linzang(??)
Sent: Sonntag, 8. M?rz 2020 09:23
To: jdk-updates-dev at openjdk.java.net
Subject: Re: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]

I made a tiny patch for this:
Please help to review.
Webrev: http://cr.openjdk.java.net/~lzang/11u/JDK-8240715/webrev/
Bug: https://bugs.openjdk.java.net/browse/JDK-8240715


BRs,
Lin

From: "linzang(??)" <linzang at tencent.com>
Date: Saturday, March 7, 2020 at 12:33 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: [11u] fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]

Hi,
     The 11u-dev repo fail to build with gcc 6.3.1, error message:
====================================================
        In file included from / Source/jdk11u-dev/src/hotspot/cpu/x86/assembler_x86.inline.hpp:30:0,
                 from / Source/jdk11u-dev/src/hotspot/share/asm/assembler.inline.hpp:30,
                 from / Source/jdk11u-dev/src/hotspot/share/precompiled/precompiled.hpp:32:
/Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp: In member function 'void G1CollectedHeap::complete_cleaning(BoolObjectClosure*, bool)':
/Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp:377:5: error: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     if (_code_blob == NULL) {
     ^~
/Source/jdk11u-dev/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3355:28: note: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' was declared here
     CompiledMethodIterator iter = CompiledMethodIterator();
                            ^~~~
cc1plus: all warnings being treated as errors

The build can success with ?disable-warnings-as-errors  or with simple change:
diff -r e5802f7424cf src/hotspot/share/code/codeCache.hpp
--- a/src/hotspot/share/code/codeCache.hpp      Fri May 24 13:52:33 2019 -0700
+++ b/src/hotspot/share/code/codeCache.hpp      Fri Mar 06 15:00:55 2020 +0800
@@ -322,6 +322,7 @@
  public:
   CodeBlobIterator(T* nm = NULL) {
+    _code_blob = NULL;
     if (Filter::heaps() == NULL) {
       return;
     }
diff -r e5802f7424cf src/hotspot/share/gc/shared/genCollectedHeap.cpp
--- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri May 24 13:52:33 2019 -0700
+++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri Mar 06 15:00:55 2020 +0800
@@ -1146,6 +1146,7 @@
   size_t min_size = 0;   // "first" makes this conceptually infinite.
   ScratchBlock **smallest_ptr, *smallest;
   ScratchBlock  *cur = *prev_ptr;
+  smallest_ptr = NULL;
   while (cur) {
     assert(*prev_ptr == cur, "just checking");
     if (first || cur->num_words < min_size) {
-----------------------------------------------------------

So could this be a fix ?

BRs,
Lin

From david.holmes at oracle.com  Mon Mar  9 09:19:35 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Mar 2020 19:19:35 +1000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized]
In-Reply-To: <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
 <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <a48c2f1c-1c08-9425-35e4-2736935a3bfd@oracle.com>

They look like false-positives flagged by gcc 6.3.1. IIRC these are not 
flagged in later gcc versions and it was decided not to "fix" them.

David

On 9/03/2020 7:15 pm, Langer, Christoph wrote:
> Hi Lin,
> 
> I compared the coding that you touch to the current versions in head and the code there seems quite the same or at least similar in regards to the possible warnings.
> 
> I rather suggest you do the change in jdk/jdk first and we'd then backport it? Or is there anything which speaks against doing this in head?
> 
> Cheers
> Christoph
> 
> 
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of linzang(??)
> Sent: Sonntag, 8. M?rz 2020 09:23
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
> 
> I made a tiny patch for this:
> Please help to review.
> Webrev: http://cr.openjdk.java.net/~lzang/11u/JDK-8240715/webrev/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240715
> 
> 
> BRs,
> Lin
> 
> From: "linzang(??)" <linzang at tencent.com>
> Date: Saturday, March 7, 2020 at 12:33 AM
> To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Subject: [11u] fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
> 
> Hi,
>       The 11u-dev repo fail to build with gcc 6.3.1, error message:
> ====================================================
>          In file included from / Source/jdk11u-dev/src/hotspot/cpu/x86/assembler_x86.inline.hpp:30:0,
>                   from / Source/jdk11u-dev/src/hotspot/share/asm/assembler.inline.hpp:30,
>                   from / Source/jdk11u-dev/src/hotspot/share/precompiled/precompiled.hpp:32:
> /Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp: In member function 'void G1CollectedHeap::complete_cleaning(BoolObjectClosure*, bool)':
> /Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp:377:5: error: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>       if (_code_blob == NULL) {
>       ^~
> /Source/jdk11u-dev/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3355:28: note: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' was declared here
>       CompiledMethodIterator iter = CompiledMethodIterator();
>                              ^~~~
> cc1plus: all warnings being treated as errors
> 
> The build can success with ?disable-warnings-as-errors  or with simple change:
> diff -r e5802f7424cf src/hotspot/share/code/codeCache.hpp
> --- a/src/hotspot/share/code/codeCache.hpp      Fri May 24 13:52:33 2019 -0700
> +++ b/src/hotspot/share/code/codeCache.hpp      Fri Mar 06 15:00:55 2020 +0800
> @@ -322,6 +322,7 @@
>    public:
>     CodeBlobIterator(T* nm = NULL) {
> +    _code_blob = NULL;
>       if (Filter::heaps() == NULL) {
>         return;
>       }
> diff -r e5802f7424cf src/hotspot/share/gc/shared/genCollectedHeap.cpp
> --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri May 24 13:52:33 2019 -0700
> +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri Mar 06 15:00:55 2020 +0800
> @@ -1146,6 +1146,7 @@
>     size_t min_size = 0;   // "first" makes this conceptually infinite.
>     ScratchBlock **smallest_ptr, *smallest;
>     ScratchBlock  *cur = *prev_ptr;
> +  smallest_ptr = NULL;
>     while (cur) {
>       assert(*prev_ptr == cur, "just checking");
>       if (first || cur->num_words < min_size) {
> -----------------------------------------------------------
> 
> So could this be a fix ?
> 
> BRs,
> Lin
> 

From linzang at tencent.com  Mon Mar  9 09:26:26 2020
From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=)
Date: Mon, 9 Mar 2020 09:26:26 +0000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized](Internet mail)
In-Reply-To: <a48c2f1c-1c08-9425-35e4-2736935a3bfd@oracle.com>
References: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
 <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <a48c2f1c-1c08-9425-35e4-2736935a3bfd@oracle.com>
Message-ID: <C91D59FD-F84B-4F77-A69A-4352AAB6E1D6@tencent.com>

Hi David, Christph, 
   I can not reproduce this issue with same gcc on Jdk/jdk. 
   So I  asked should this issue be fixed or not.
   It also makes wondering why jdk/jdk could pass build with same gcc 6.3.1 
   So if it was dicided not to fix, I will close the issue. 

BRs,
Lin

?On 2020/3/9, 5:20 PM, "David Holmes" <david.holmes at oracle.com> wrote:

    They look like false-positives flagged by gcc 6.3.1. IIRC these are not 
    flagged in later gcc versions and it was decided not to "fix" them.
    
    David
    
    On 9/03/2020 7:15 pm, Langer, Christoph wrote:
    > Hi Lin,
    > 
    > I compared the coding that you touch to the current versions in head and the code there seems quite the same or at least similar in regards to the possible warnings.
    > 
    > I rather suggest you do the change in jdk/jdk first and we'd then backport it? Or is there anything which speaks against doing this in head?
    > 
    > Cheers
    > Christoph
    > 
    > 
    > -----Original Message-----
    > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of linzang(??)
    > Sent: Sonntag, 8. M?rz 2020 09:23
    > To: jdk-updates-dev at openjdk.java.net
    > Subject: Re: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
    > 
    > I made a tiny patch for this:
    > Please help to review.
    > Webrev: http://cr.openjdk.java.net/~lzang/11u/JDK-8240715/webrev/
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8240715
    > 
    > 
    > BRs,
    > Lin
    > 
    > From: "linzang(??)" <linzang at tencent.com>
    > Date: Saturday, March 7, 2020 at 12:33 AM
    > To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
    > Subject: [11u] fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
    > 
    > Hi,
    >       The 11u-dev repo fail to build with gcc 6.3.1, error message:
    > ====================================================
    >          In file included from / Source/jdk11u-dev/src/hotspot/cpu/x86/assembler_x86.inline.hpp:30:0,
    >                   from / Source/jdk11u-dev/src/hotspot/share/asm/assembler.inline.hpp:30,
    >                   from / Source/jdk11u-dev/src/hotspot/share/precompiled/precompiled.hpp:32:
    > /Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp: In member function 'void G1CollectedHeap::complete_cleaning(BoolObjectClosure*, bool)':
    > /Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp:377:5: error: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    >       if (_code_blob == NULL) {
    >       ^~
    > /Source/jdk11u-dev/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3355:28: note: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' was declared here
    >       CompiledMethodIterator iter = CompiledMethodIterator();
    >                              ^~~~
    > cc1plus: all warnings being treated as errors
    > 
    > The build can success with ?disable-warnings-as-errors  or with simple change:
    > diff -r e5802f7424cf src/hotspot/share/code/codeCache.hpp
    > --- a/src/hotspot/share/code/codeCache.hpp      Fri May 24 13:52:33 2019 -0700
    > +++ b/src/hotspot/share/code/codeCache.hpp      Fri Mar 06 15:00:55 2020 +0800
    > @@ -322,6 +322,7 @@
    >    public:
    >     CodeBlobIterator(T* nm = NULL) {
    > +    _code_blob = NULL;
    >       if (Filter::heaps() == NULL) {
    >         return;
    >       }
    > diff -r e5802f7424cf src/hotspot/share/gc/shared/genCollectedHeap.cpp
    > --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri May 24 13:52:33 2019 -0700
    > +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri Mar 06 15:00:55 2020 +0800
    > @@ -1146,6 +1146,7 @@
    >     size_t min_size = 0;   // "first" makes this conceptually infinite.
    >     ScratchBlock **smallest_ptr, *smallest;
    >     ScratchBlock  *cur = *prev_ptr;
    > +  smallest_ptr = NULL;
    >     while (cur) {
    >       assert(*prev_ptr == cur, "just checking");
    >       if (first || cur->num_words < min_size) {
    > -----------------------------------------------------------
    > 
    > So could this be a fix ?
    > 
    > BRs,
    > Lin
    > 
    
    


From christoph.langer at sap.com  Mon Mar  9 09:57:56 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 09:57:56 +0000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized](Internet mail)
In-Reply-To: <C91D59FD-F84B-4F77-A69A-4352AAB6E1D6@tencent.com>
References: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
 <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <a48c2f1c-1c08-9425-35e4-2736935a3bfd@oracle.com>
 <C91D59FD-F84B-4F77-A69A-4352AAB6E1D6@tencent.com>
Message-ID: <AM0PR02MB571438ACE1DF94FB273982938AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

then maybe it's ok to have a jdk11u specific fix here. I'd like to get another opinion from folks involved in 11u, though...

Cheers
Christoph

-----Original Message-----
From: linzang(??) <linzang at tencent.com> 
Sent: Montag, 9. M?rz 2020 10:26
To: David Holmes <david.holmes at oracle.com>; Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net
Subject: Re: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized](Internet mail)

Hi David, Christph, 
   I can not reproduce this issue with same gcc on Jdk/jdk. 
   So I  asked should this issue be fixed or not.
   It also makes wondering why jdk/jdk could pass build with same gcc 6.3.1 
   So if it was dicided not to fix, I will close the issue. 

BRs,
Lin

?On 2020/3/9, 5:20 PM, "David Holmes" <david.holmes at oracle.com> wrote:

    They look like false-positives flagged by gcc 6.3.1. IIRC these are not 
    flagged in later gcc versions and it was decided not to "fix" them.
    
    David
    
    On 9/03/2020 7:15 pm, Langer, Christoph wrote:
    > Hi Lin,
    > 
    > I compared the coding that you touch to the current versions in head and the code there seems quite the same or at least similar in regards to the possible warnings.
    > 
    > I rather suggest you do the change in jdk/jdk first and we'd then backport it? Or is there anything which speaks against doing this in head?
    > 
    > Cheers
    > Christoph
    > 
    > 
    > -----Original Message-----
    > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of linzang(??)
    > Sent: Sonntag, 8. M?rz 2020 09:23
    > To: jdk-updates-dev at openjdk.java.net
    > Subject: Re: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
    > 
    > I made a tiny patch for this:
    > Please help to review.
    > Webrev: http://cr.openjdk.java.net/~lzang/11u/JDK-8240715/webrev/
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8240715
    > 
    > 
    > BRs,
    > Lin
    > 
    > From: "linzang(??)" <linzang at tencent.com>
    > Date: Saturday, March 7, 2020 at 12:33 AM
    > To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
    > Subject: [11u] fail to build with gcc 6.3.1 [-Werror=maybe-uninitialized]
    > 
    > Hi,
    >       The 11u-dev repo fail to build with gcc 6.3.1, error message:
    > ====================================================
    >          In file included from / Source/jdk11u-dev/src/hotspot/cpu/x86/assembler_x86.inline.hpp:30:0,
    >                   from / Source/jdk11u-dev/src/hotspot/share/asm/assembler.inline.hpp:30,
    >                   from / Source/jdk11u-dev/src/hotspot/share/precompiled/precompiled.hpp:32:
    > /Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp: In member function 'void G1CollectedHeap::complete_cleaning(BoolObjectClosure*, bool)':
    > /Source/jdk11u-dev/src/hotspot/share/code/codeCache.hpp:377:5: error: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' may be used uninitialized in this function [-Werror=maybe-uninitialized]
    >       if (_code_blob == NULL) {
    >       ^~
    > /Source/jdk11u-dev/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3355:28: note: 'iter.CodeBlobIterator<CompiledMethod, CompiledMethodFilter>::_code_blob' was declared here
    >       CompiledMethodIterator iter = CompiledMethodIterator();
    >                              ^~~~
    > cc1plus: all warnings being treated as errors
    > 
    > The build can success with ?disable-warnings-as-errors  or with simple change:
    > diff -r e5802f7424cf src/hotspot/share/code/codeCache.hpp
    > --- a/src/hotspot/share/code/codeCache.hpp      Fri May 24 13:52:33 2019 -0700
    > +++ b/src/hotspot/share/code/codeCache.hpp      Fri Mar 06 15:00:55 2020 +0800
    > @@ -322,6 +322,7 @@
    >    public:
    >     CodeBlobIterator(T* nm = NULL) {
    > +    _code_blob = NULL;
    >       if (Filter::heaps() == NULL) {
    >         return;
    >       }
    > diff -r e5802f7424cf src/hotspot/share/gc/shared/genCollectedHeap.cpp
    > --- a/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri May 24 13:52:33 2019 -0700
    > +++ b/src/hotspot/share/gc/shared/genCollectedHeap.cpp  Fri Mar 06 15:00:55 2020 +0800
    > @@ -1146,6 +1146,7 @@
    >     size_t min_size = 0;   // "first" makes this conceptually infinite.
    >     ScratchBlock **smallest_ptr, *smallest;
    >     ScratchBlock  *cur = *prev_ptr;
    > +  smallest_ptr = NULL;
    >     while (cur) {
    >       assert(*prev_ptr == cur, "just checking");
    >       if (first || cur->num_words < min_size) {
    > -----------------------------------------------------------
    > 
    > So could this be a fix ?
    > 
    > BRs,
    > Lin
    > 
    
    


From christoph.langer at sap.com  Mon Mar  9 10:36:25 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 10:36:25 +0000
Subject: [11u] RFR: 8240073: Fix 'test-make' build target in 11u
In-Reply-To: <CA+3eh10us=nLm8tk_s8RH9ALHtY=deL1kvYidk+i5+bOobgDsQ@mail.gmail.com>
References: <CA+3eh13HHBp5bzP0G4qWDOkq5OP0wcXvkwBv=s1LR0u7LZnJnQ@mail.gmail.com>
 <4BEE0678-3E37-41DD-A406-F5AE0A57536F@amazon.com>
 <CA+3eh10us=nLm8tk_s8RH9ALHtY=deL1kvYidk+i5+bOobgDsQ@mail.gmail.com>
Message-ID: <AM0PR02MB5714B45E6EF49A302032D7158AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

sorry for the delay. I didn't have so much time in the last two weeks but now I'm back full steam, tackling jdk11u build system again ??

So this one is really trivial, and should be done in any case. I've approved it.

Cheers
Christoph

-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of Volker Simonis
Sent: Freitag, 28. Februar 2020 10:25
To: Hohensee, Paul <hohensee at amazon.com>
Cc: build-dev <build-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Subject: Re: [11u] RFR: 8240073: Fix 'test-make' build target in 11u

On Wed, Feb 26, 2020 at 5:21 PM Hohensee, Paul <hohensee at amazon.com> wrote:
>
> Looks to me like the replaced store to KEYWORDS is dead (i.e., no uses of KEYWORDS that I could find in make and test/make). Lgtm.

Yes, that's exactly why we need this patch :)

"ParseKeywordVariableBody" in "make/common/MakeBase.gmk" initially
used "KEYWORDS" but when it was updated by "8212028: Use run-test
makefile framework for testing in Oracle's Mach5" to use
"SINGLE_KEYWORDS" instead, these two places were forgotten.

Thanks for reviewing,
Volker

>
> Thanks,
> Paul
>
> ?On 2/26/20, 3:19 AM, "build-dev on behalf of Volker Simonis" <build-dev-bounces at openjdk.java.net on behalf of volker.simonis at gmail.com> wrote:
>
>     Hi,
>
>     can I please have a review for the following tiny change which fixes
>     the 'test-make' build target in 11u:
>
>     http://cr.openjdk.java.net/~simonis/webrevs/2020/8240073/
>     https://bugs.openjdk.java.net/browse/JDK-8240073
>
>     This is a tiny fix for a problem introduced by JDK-8212028 (which has
>     already been downported to 11u) and fixed in jdk 12 as part of
>     JDK-8210958 (which hasn't been downported yet and probably won't be
>     donwported at all).
>
>     Instead of smuggling this fix into another downport, it has been
>     argued (https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-February/002533.html)
>     that it is cleaner to create an explicit issue for fixing it in 11u.
>
>     The fix is trivial (that's why it was done as part of JDK-8210958
>     without an extra bug ID) and only affects running "make test-make".
>
>     Thank you and best regards,
>     Volker
>
>

From aph at redhat.com  Mon Mar  9 11:10:46 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 9 Mar 2020 11:10:46 +0000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized](Internet mail)
In-Reply-To: <AM0PR02MB571438ACE1DF94FB273982938AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
 <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <a48c2f1c-1c08-9425-35e4-2736935a3bfd@oracle.com>
 <C91D59FD-F84B-4F77-A69A-4352AAB6E1D6@tencent.com>
 <AM0PR02MB571438ACE1DF94FB273982938AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <d3930f5d-9345-56df-ebcd-2ec20e3bde43@redhat.com>

On 3/9/20 9:57 AM, Langer, Christoph wrote:
> then maybe it's ok to have a jdk11u specific fix here.

No, not for this. It's a false positive in a particular GCC, and
that GCC could also be used to compile later versions of OpenJDK.
It makes no sense to fix it in 11u because it is not an 11u-specific
problem.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From linzang at tencent.com  Mon Mar  9 11:19:08 2020
From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=)
Date: Mon, 9 Mar 2020 11:19:08 +0000
Subject: [11u]RFR[S]:8240715: fail to build with gcc 6.3.1
 [-Werror=maybe-uninitialized](Internet mail)
In-Reply-To: <d3930f5d-9345-56df-ebcd-2ec20e3bde43@redhat.com>
References: <7699A98F-837E-43D0-AAD1-E3E6759E93E4@tencent.com>
 <AM0PR02MB5714A1A5058D610BD854E1D28AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <a48c2f1c-1c08-9425-35e4-2736935a3bfd@oracle.com>
 <C91D59FD-F84B-4F77-A69A-4352AAB6E1D6@tencent.com>
 <AM0PR02MB571438ACE1DF94FB273982938AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>,
 <d3930f5d-9345-56df-ebcd-2ec20e3bde43@redhat.com>
Message-ID: <6B99E311-B3C0-47A1-A57F-F7E21BD5A388@tencent.com>

Thanks all?So I think I can close this issue with ?not fix?.

BRs,
Lin


> ? 2020?3?9????7:11?Andrew Haley <aph at redhat.com> ???
> 
> ?On 3/9/20 9:57 AM, Langer, Christoph wrote:
>> then maybe it's ok to have a jdk11u specific fix here.
> 
> No, not for this. It's a false positive in a particular GCC, and
> that GCC could also be used to compile later versions of OpenJDK.
> It makes no sense to fix it in 11u because it is not an 11u-specific
> problem.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> 

From goetz.lindenmaier at sap.com  Mon Mar  9 13:25:21 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 9 Mar 2020 13:25:21 +0000
Subject: [11u] RFR(S): 8232357: Compare version info of Santuario to legal
 notice
In-Reply-To: <928d9550-67b9-4c34-9931-aa6e5aa445aa@redhat.com>
References: <AM7PR02MB6049BE60FD61BE3D86A6DCDEECE30@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <928d9550-67b9-4c34-9931-aa6e5aa445aa@redhat.com>
Message-ID: <AM7PR02MB6049E37176DC53E2692D0470ECFE0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Aleksey,

yes, the test passes.
Thanks for reviewing.

Best regards,
  Goetz.

> -----Original Message-----
> From: Aleksey Shipilev <shade at redhat.com>
> Sent: Freitag, 6. M?rz 2020 17:32
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8232357: Compare version info of Santuario to legal
> notice
>
> On 3/6/20 11:41 AM, Lindenmaier, Goetz wrote:
> > Please review.
> > http://cr.openjdk.java.net/~goetz/wr20/8232357-Santuario_test-jdk11/01/
>
> Backport looks good. And the test passes, right?
>
> --
> Thanks,
> -Aleksey


From christoph.langer at sap.com  Mon Mar  9 13:56:45 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 13:56:45 +0000
Subject: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk
Message-ID: <AM0PR02MB57144B4E6B63D15AECE3358D8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

please review this Oracle parity backport.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232572
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ae0af9fb3dbb
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u/

I had to manually bring some hunks to the right position in the file. The $$(call MakeTargetDir) does not yet exist as it was only introduced with JDK-8211724. So I just add the LogWarn call as first command in the recipe.

Thanks and best regards
Christoph


From christoph.langer at sap.com  Mon Mar  9 15:14:31 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 15:14:31 +0000
Subject: 11u RFR: 8232569: Use test image from different jib profile for
 testing
Message-ID: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

Please help reviewing this Oracle parity backport
Bug: https://bugs.openjdk.java.net/browse/JDK-8232569
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/559c46cd0e8b
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232569.11u/

I had to make several adaptions because some predecessors were missing regarding jcov. Will run the change through our nightly tests but I doubt the file is used there.

Is this file only used in internal Oracle builds or does it have use cases outside? (I guess this question unmasks my ignorance in that area ??)

Thanks
Christoph


From sgehwolf at redhat.com  Mon Mar  9 15:29:19 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 09 Mar 2020 16:29:19 +0100
Subject: 11u RFR: 8232569: Use test image from different jib profile for
 testing
In-Reply-To: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <d7b6cee7c2ec2436a420f9e6e6b24c731be9302b.camel@redhat.com>

On Mon, 2020-03-09 at 15:14 +0000, Langer, Christoph wrote:
> Is this file only used in internal Oracle builds or does it have use
> cases outside? (I guess this question unmasks my ignorance in that
> area ??)

I'd be curious about this too. There is little point in us backporting 
an Oracle-only build change if so.

Thanks,
Severin


From erik.joelsson at oracle.com  Mon Mar  9 15:43:52 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 9 Mar 2020 08:43:52 -0700
Subject: 11u RFR: 8232569: Use test image from different jib profile for
 testing
In-Reply-To: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <0ca6c1cb-0b4b-8c87-88ae-2a0d04df7bf7@oracle.com>


On 2020-03-09 08:14, Langer, Christoph wrote:
> Hi,
>
> Please help reviewing this Oracle parity backport
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232569
> Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/559c46cd0e8b
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232569.11u/
>
> I had to make several adaptions because some predecessors were missing regarding jcov. Will run the change through our nightly tests but I doubt the file is used there.
>
> Is this file only used in internal Oracle builds or does it have use cases outside? (I guess this question unmasks my ignorance in that area ??)

This file is only used by Oracle. It's used to interact with our 
dependency management and build configuration system ("jib"), which is 
internal. We keep it in the source code since this configuration is very 
highly version specific and frequently changes in lock step with other 
source code changes. While the exact meaning of the contents of the file 
isn't obvious to an external reader, certain things pertaining to how 
Oracle configures builds can still be gleaned from it and may be useful 
to some (current compiler versions, values of some configure options etc).

I would very much recommend against trying to merge changes here for 
OpenJDK update releases.

/Erik

> Thanks
> Christoph
>

From thomas.stuefe at gmail.com  Mon Mar  9 16:24:19 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 9 Mar 2020 17:24:19 +0100
Subject: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk
In-Reply-To: <AM0PR02MB57144B4E6B63D15AECE3358D8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57144B4E6B63D15AECE3358D8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUx5ZtP3=bJDZVFF29Sucb3GKtEt1_AnnRbW7kSff93CJA@mail.gmail.com>

LGTM.

..Thomas

On Mon, Mar 9, 2020 at 2:57 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> Hi,
>
> please review this Oracle parity backport.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232572
> Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ae0af9fb3dbb
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u/
>
> I had to manually bring some hunks to the right position in the file. The
> $$(call MakeTargetDir) does not yet exist as it was only introduced with
> JDK-8211724. So I just add the LogWarn call as first command in the recipe.
>
> Thanks and best regards
> Christoph
>
>

From christoph.langer at sap.com  Mon Mar  9 16:29:24 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 16:29:24 +0000
Subject: 11u RFR: 8232569: Use test image from different jib profile for
 testing
In-Reply-To: <0ca6c1cb-0b4b-8c87-88ae-2a0d04df7bf7@oracle.com>
References: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <0ca6c1cb-0b4b-8c87-88ae-2a0d04df7bf7@oracle.com>
Message-ID: <AM0PR02MB5714C23FA0ADF504D770AABC8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks Erik, for this clarification.

We won't backport it then.

Cheers
Christoph

-----Original Message-----
From: Erik Joelsson <erik.joelsson at oracle.com> 
Sent: Montag, 9. M?rz 2020 16:44
To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net
Cc: build-dev <build-dev at openjdk.java.net>
Subject: Re: 11u RFR: 8232569: Use test image from different jib profile for testing


On 2020-03-09 08:14, Langer, Christoph wrote:
> Hi,
>
> Please help reviewing this Oracle parity backport
> Bug: https://bugs.openjdk.java.net/browse/JDK-8232569
> Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/559c46cd0e8b
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232569.11u/
>
> I had to make several adaptions because some predecessors were missing regarding jcov. Will run the change through our nightly tests but I doubt the file is used there.
>
> Is this file only used in internal Oracle builds or does it have use cases outside? (I guess this question unmasks my ignorance in that area ??)

This file is only used by Oracle. It's used to interact with our 
dependency management and build configuration system ("jib"), which is 
internal. We keep it in the source code since this configuration is very 
highly version specific and frequently changes in lock step with other 
source code changes. While the exact meaning of the contents of the file 
isn't obvious to an external reader, certain things pertaining to how 
Oracle configures builds can still be gleaned from it and may be useful 
to some (current compiler versions, values of some configure options etc).

I would very much recommend against trying to merge changes here for 
OpenJDK update releases.

/Erik

> Thanks
> Christoph
>

From christoph.langer at sap.com  Mon Mar  9 16:49:34 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 9 Mar 2020 16:49:34 +0000
Subject: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk
In-Reply-To: <CAA-vtUx5ZtP3=bJDZVFF29Sucb3GKtEt1_AnnRbW7kSff93CJA@mail.gmail.com>
References: <AM0PR02MB57144B4E6B63D15AECE3358D8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CAA-vtUx5ZtP3=bJDZVFF29Sucb3GKtEt1_AnnRbW7kSff93CJA@mail.gmail.com>
Message-ID: <AM0PR02MB5714859AB4D4FAF198B56C588AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks, Thomas.

From: Thomas St?fe <thomas.stuefe at gmail.com>
Sent: Montag, 9. M?rz 2020 17:24
To: Langer, Christoph <christoph.langer at sap.com>
Cc: jdk-updates-dev at openjdk.java.net; build-dev <build-dev at openjdk.java.net>
Subject: Re: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk

LGTM.

..Thomas

On Mon, Mar 9, 2020 at 2:57 PM Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:
Hi,

please review this Oracle parity backport.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232572
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ae0af9fb3dbb
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u/

I had to manually bring some hunks to the right position in the file. The $$(call MakeTargetDir) does not yet exist as it was only introduced with JDK-8211724. So I just add the LogWarn call as first command in the recipe.

Thanks and best regards
Christoph

From matthias.baesken at sap.com  Tue Mar 10 09:17:23 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 10 Mar 2020 09:17:23 +0000
Subject: RFR [jdk11]: 8240792: backport of 8226653: [accessibility] Can edit
 text cell correctly, but Accessibility Tool reads nothing about editor
Message-ID: <AM0PR02MB4227392FFD988F7A529EE06D93FF0@AM0PR02MB4227.eurprd02.prod.outlook.com>



Hello, please review the jdk11 downport of

8226653: [accessibility] Can edit text cell correctly, but Accessibility Tool reads nothing about editor

8226653  is a closed bug, so I had to open a new one ( https://bugs.openjdk.java.net/browse/JDK-8240792 ) to track the downport.
The patch applies cleanly.


original bug :

https://bugs.openjdk.java.net/browse/JDK-8226653

new bug :

https://bugs.openjdk.java.net/browse/JDK-8240792

webrev jdk/jdk :

https://hg.openjdk.java.net/jdk/jdk/rev/04d80e7ad3f4


Thanks, Matthias

From goetz.lindenmaier at sap.com  Tue Mar 10 10:45:51 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 10 Mar 2020 10:45:51 +0000
Subject: 11u RFR: 8232569: Use test image from different jib profile for
 testing
In-Reply-To: <AM0PR02MB5714C23FA0ADF504D770AABC8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57146485F9303C0B21C55D848AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <0ca6c1cb-0b4b-8c87-88ae-2a0d04df7bf7@oracle.com>
 <AM0PR02MB5714C23FA0ADF504D770AABC8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB604942CE45B3452FE1564821ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

+1
I think this is a candidate for the label "openjdk-na" then.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Montag, 9. M?rz 2020 17:29
> To: Erik Joelsson <erik.joelsson at oracle.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: [CAUTION] RE: 11u RFR: 8232569: Use test image from different jib
> profile for testing
>
> Thanks Erik, for this clarification.
>
> We won't backport it then.
>
> Cheers
> Christoph
>
> -----Original Message-----
> From: Erik Joelsson <erik.joelsson at oracle.com>
> Sent: Montag, 9. M?rz 2020 16:44
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: 11u RFR: 8232569: Use test image from different jib profile for
> testing
>
>
> On 2020-03-09 08:14, Langer, Christoph wrote:
> > Hi,
> >
> > Please help reviewing this Oracle parity backport
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8232569
> > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/559c46cd0e8b
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232569.11u/
> >
> > I had to make several adaptions because some predecessors were missing
> regarding jcov. Will run the change through our nightly tests but I doubt the file
> is used there.
> >
> > Is this file only used in internal Oracle builds or does it have use cases
> outside? (I guess this question unmasks my ignorance in that area ??)
>
> This file is only used by Oracle. It's used to interact with our
> dependency management and build configuration system ("jib"), which is
> internal. We keep it in the source code since this configuration is very
> highly version specific and frequently changes in lock step with other
> source code changes. While the exact meaning of the contents of the file
> isn't obvious to an external reader, certain things pertaining to how
> Oracle configures builds can still be gleaned from it and may be useful
> to some (current compiler versions, values of some configure options etc).
>
> I would very much recommend against trying to merge changes here for
> OpenJDK update releases.
>
> /Erik
>
> > Thanks
> > Christoph
> >

From goetz.lindenmaier at sap.com  Tue Mar 10 11:12:00 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 10 Mar 2020 11:12:00 +0000
Subject: RFR [jdk11]: 8240792: backport of 8226653: [accessibility] Can
 edit text cell correctly, but Accessibility Tool reads nothing about editor
In-Reply-To: <AM0PR02MB4227392FFD988F7A529EE06D93FF0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227392FFD988F7A529EE06D93FF0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB60491378AB886D223A9CE273ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Matthias,

the change looks good.
I think you don't need a review as the change applies clean.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Dienstag, 10. M?rz 2020 10:17
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: [CAUTION] RFR [jdk11]: 8240792: backport of 8226653: [accessibility]
> Can edit text cell correctly, but Accessibility Tool reads nothing about editor
>
>
>
> Hello, please review the jdk11 downport of
>
> 8226653: [accessibility] Can edit text cell correctly, but Accessibility Tool reads
> nothing about editor
>
> 8226653  is a closed bug, so I had to open a new one (
> https://bugs.openjdk.java.net/browse/JDK-8240792 ) to track the downport.
> The patch applies cleanly.
>
>
> original bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8226653
>
> new bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8240792
>
> webrev jdk/jdk :
>
> https://hg.openjdk.java.net/jdk/jdk/rev/04d80e7ad3f4
>
>
> Thanks, Matthias

From matthias.baesken at sap.com  Tue Mar 10 15:19:18 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 10 Mar 2020 15:19:18 +0000
Subject: RFR [jdk11]: 8232880 : Update test documentation with additional
 settings for client UI tooltip tests
Message-ID: <AM0PR02MB4227AF44AA93B3B8F457115693FF0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello, please review  the following downport  of  8232880  to jdk11 .

The doc/testing.md  adjustment of the jdk/jdk  change  applies cleanly, and as expected the html needs to be regenerated from it with "make update-build-docs" .


https://bugs.openjdk.java.net/browse/JDK-8232880

http://cr.openjdk.java.net/~mbaesken/webrevs/8232880_jdk11/

Thanks, Matthias

From goetz.lindenmaier at sap.com  Tue Mar 10 16:01:43 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 10 Mar 2020 16:01:43 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882: Use
 fiber-friendly java.util.concurrent.locks in JSSE"
Message-ID: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket close"
for parity with 11.0.8-oracle.

Severin pointed me to [3], "8219991: New fix of the deadlock in
sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
introduced by [1]. I agree that it would make sense
to bring this fix to jdk11u-dev along with [1].

[1] applies clean to jdk11u-dev.
Unfortunately, [3] does not apply at all.

In jdk13 a major rework of JSSE was done:
[2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"

[2] removes the synchronized keywords from a lot of functions
in JSSE and replaces them by manual locking. [3] exploits
the new control flow within these reworked functions in
SSLSocketImpl.java. It needs to be designed differently
to apply directly on top of [1].

Instead, I propose to downport the changes of [2] to the only
file touched by [3], SSLSocketImpl.java.

I took the patch of [2] for SSLSocketImpl.java and patched
it on top of [1] to jdk11u-dev. It applies clean. On top
of this, [3] applies clean, too.

The SSLSocketImpl.java part of [2] uses a public lock
introduced in OutputRecord. I revoked this part of the change
as the changes to OutputRecord are not important here, so
it'd like to skip them. Here the partial webrev of the
revoked code:
http://cr.openjdk.java.net/~goetz/wr20/8240827-Downport_SSLSocketImpl_from_8221882-jdk11/01-revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.udiff.html

The locks introduced by [2] in SSLSocketImpl.java are private,
so there is no direct dependency to them in other code.

I ran the three changes through our nightly testing
and saw no issues.

Please review:
http://cr.openjdk.java.net/~goetz/wr20/8240827-Downport_SSLSocketImpl_from_8221882-jdk11/01/

Best regards,
  Goetz.

[1] "8209333: Socket reset issue for TLS 1.3 socket close"
https://bugs.openjdk.java.net/browse/JDK-8209333
http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c

[2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
https://bugs.openjdk.java.net/browse/JDK-8221882
http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3

[3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
https://bugs.openjdk.java.net/browse/JDK-8219991
http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From hohensee at amazon.com  Tue Mar 10 21:32:23 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 10 Mar 2020 21:32:23 +0000
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
Message-ID: <1D980D3A-03C1-47CE-9A18-136E51613058@amazon.com>

Vote: yes

?On 3/6/20, 12:25 AM, "jdk-updates-dev on behalf of Andrew Hughes" <jdk-updates-dev-bounces at openjdk.java.net on behalf of gnu.andrew at redhat.com> wrote:    
    
    I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.
    
    Simon has done work in the main JDK project [1] as well as backporting
    work for  [2]. Making him a committer would aid this backporting work
    by avoiding the need for someone else to push his fixes.
    
    Votes are due by 21h00 UTC on the 20th of March, 2020.
    
    Only current OpenJDK Updates Committers (and above) [3] 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 [4].
    
    [0] https://openjdk.java.net/census#stooke
    [1]
    https://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
    [2]
    https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/log?revcount=200&rev=(author(stooke)+or+desc(%22stooke%40redhat.com%22))+and+not+merge()
    [3] https://openjdk.java.net/census#jdk-updates
    [4] http://openjdk.java.net/projects/#committer-vote
    
    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 christoph.langer at sap.com  Wed Mar 11 08:58:34 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Mar 2020 08:58:34 +0000
Subject: [11u] RFR: 8189861: Refactor CacheFind
Message-ID: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

for the backports of "JDK-8223678 Add Visual Studio Code workspace generation support (for native code)" and "JDK-8232748 Build static versions of certain JDK libraries" it seems useful to first backport the refactoring of CacheFind. Furthermore it can improve performance in the Windows Build and will probably also be a nice base for future backports in the build system area.

I had to resolve several rejects because there is some code divergence between jdk11u-dev and the state of jdk13 at the time of the original change. But in fact, it was quite straightforward and I replaced all occurences of CacheFind with the new FindFiles function. Lots of the rejects were also just copyright years.

In make/hotspot/lib/CompileJvm.gmk, I effectively added the "$(call FillFindCache, $(JVM_SRC_DIRS))" statement which was only modified in the original change.

Please let me know what you think.

Bug: https://bugs.openjdk.java.net/browse/JDK-8189861
Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e297c7bb6469
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u/

Thanks & Best regards
Christoph


From sgehwolf at redhat.com  Wed Mar 11 09:49:52 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Mar 2020 10:49:52 +0100
Subject: [11u] RFR: 8189861: Refactor CacheFind
In-Reply-To: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>

Hi Christoph,

Thanks for doing this!

On Wed, 2020-03-11 at 08:58 +0000, Langer, Christoph wrote:
> Hi,
> 
> for the backports of "JDK-8223678 Add Visual Studio Code workspace
> generation support (for native code)" and "JDK-8232748 Build static
> versions of certain JDK libraries" it seems useful to first backport
> the refactoring of CacheFind. Furthermore it can improve performance
> in the Windows Build and will probably also be a nice base for future
> backports in the build system area.
> 
> I had to resolve several rejects because there is some code
> divergence between jdk11u-dev and the state of jdk13 at the time of
> the original change. But in fact, it was quite straightforward and I
> replaced all occurences of CacheFind with the new FindFiles function.
> Lots of the rejects were also just copyright years.
> 
> In make/hotspot/lib/CompileJvm.gmk, I effectively added the "$(call
> FillFindCache, $(JVM_SRC_DIRS))" statement which was only modified in
> the original change.

I believe we should omit this hunk in the 11u backport, because that
logic was added by JDK-8220383[1] which is not in OpenJDK 11u.

> Please let me know what you think.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189861
> Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e297c7bb6469
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u/

I've compared it to the original change and it looks good except for
the hunk in make/hotspot/lib/CompileJvm.gmk. Andrew's backport then
also works for getting the static-libs image built.

Thanks,
Severin

> Thanks & Best regards
> Christoph

[1] https://bugs.openjdk.java.net/browse/JDK-8220383



From christoph.langer at sap.com  Wed Mar 11 09:54:04 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Mar 2020 09:54:04 +0000
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
Message-ID: <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Volker,

> > Out of interest, is the AssertEquals macro something worth backporting
> > at some point? Generally, I find its worthwhile if people are going to
> > be doing the same replacement in multiple backports.
> >
> 
> I actually wanted to answer something like "..lets wait until we get
> another backport requiring this.." but already before answering we
> already ran into such a case (see my answer to the other thread
> "8232748: "Build static versions of certain JDK libraries"). The only
> problem is that "8189861: Refactor CacheFind" which introduced
> AssertEquals is not a trivial downport.
> 
> Please let me know what you think?

I've just proposed the backport of "8189861: Refactor CacheFind". Can you rebase your change on that and see if it works?

Best regards
Christoph


From christoph.langer at sap.com  Wed Mar 11 09:58:02 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Mar 2020 09:58:02 +0000
Subject: [11u] RFR: 8189861: Refactor CacheFind
In-Reply-To: <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>
References: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>
Message-ID: <AM0PR02MB5714ECA7A6B2E56C9E3AD9D88AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Severin,

thanks for the review.

> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189861
> > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e297c7bb6469
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u/
> 
> I've compared it to the original change and it looks good except for
> the hunk in make/hotspot/lib/CompileJvm.gmk. Andrew's backport then
> also works for getting the static-libs image built.

So you think we should have the hunk in make/hotspot/lib/CompileJvm.gmk or leave it out?

You should probably also make up your mind on whether it's 11.0.7 or 11.0.8. It applies to both repos and I test it with both. I guess, in the end it depends on how urgent the backport of "JDK-8232748 Build static versions of certain JDK libraries" is.

Best regards
Christoph


From sgehwolf at redhat.com  Wed Mar 11 10:20:16 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Mar 2020 11:20:16 +0100
Subject: [11u] RFR: 8189861: Refactor CacheFind
In-Reply-To: <AM0PR02MB5714ECA7A6B2E56C9E3AD9D88AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>
 <AM0PR02MB5714ECA7A6B2E56C9E3AD9D88AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <22460aec95031c690f78fa3f4f71feac73e9e293.camel@redhat.com>

Hi,

On Wed, 2020-03-11 at 09:58 +0000, Langer, Christoph wrote:
> Hi Severin,
> 
> thanks for the review.
> 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189861
> > > Original Change: http://hg.openjdk.java.net/jdk/jdk/rev/e297c7bb6469
> > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u/
> > 
> > I've compared it to the original change and it looks good except for
> > the hunk in make/hotspot/lib/CompileJvm.gmk. Andrew's backport then
> > also works for getting the static-libs image built.
> 
> So you think we should have the hunk in
> make/hotspot/lib/CompileJvm.gmk or leave it out?

Leave it out, please. If anything it should be part of a future 
JDK-8220383 backport.

> You should probably also make up your mind on whether it's 11.0.7 or
> 11.0.8. It applies to both repos and I test it with both. I guess, in
> the end it depends on how urgent the backport of "JDK-8232748 Build
> static versions of certain JDK libraries" is.

11.0.8 is fine.

Thanks,
Severin


From christoph.langer at sap.com  Wed Mar 11 12:47:17 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Mar 2020 12:47:17 +0000
Subject: [11u] RFR: 8189861: Refactor CacheFind
In-Reply-To: <22460aec95031c690f78fa3f4f71feac73e9e293.camel@redhat.com>
References: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>
 <AM0PR02MB5714ECA7A6B2E56C9E3AD9D88AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <22460aec95031c690f78fa3f4f71feac73e9e293.camel@redhat.com>
Message-ID: <AM0PR02MB5714456B19DEDD0134AA281F8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Severin,

> > So you think we should have the hunk in
> > make/hotspot/lib/CompileJvm.gmk or leave it out?
> 
> Leave it out, please. If anything it should be part of a future
> JDK-8220383 backport.

OK, I guess you're right. Here is the new webrev: http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u.1/

> > You should probably also make up your mind on whether it's 11.0.7 or
> > 11.0.8. It applies to both repos and I test it with both. I guess, in
> > the end it depends on how urgent the backport of "JDK-8232748 Build
> > static versions of certain JDK libraries" is.
> 
> 11.0.8 is fine.

I concur, so please feel free to approve at your convenience.

Cheers
Christoph


From jaroslav.bachorik at datadoghq.com  Wed Mar 11 13:20:30 2020
From: jaroslav.bachorik at datadoghq.com (=?UTF-8?Q?Jaroslav_Bachor=C3=ADk?=)
Date: Wed, 11 Mar 2020 14:20:30 +0100
Subject: [11u] RFR: 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ7cvK_o3tnpdYY_biN63dAHuC4h1pxWBy25mhw9r3U9NA@mail.gmail.com>
References: <CAPb8aJ7cvK_o3tnpdYY_biN63dAHuC4h1pxWBy25mhw9r3U9NA@mail.gmail.com>
Message-ID: <CAPb8aJ4y9attdUjQnJ0LkvzbUkRnOS3CMqAaVnYyJhziukJrxQ@mail.gmail.com>

Gentle ping?

On Mon, Mar 2, 2020 at 5:19 PM Jaroslav Bachor?k <
jaroslav.bachorik at datadoghq.com> wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8233197
> Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/webrev/
>
> Please, review this patch backporting JDK-8233197 to JDK 11u. The original
> fix prevents a JVM crash when starting a JFR in agent premain.
>
> The patch applies rather cleanly with only 2 conflicts in jfrRecord.cpp
> due to changes in JFR args processing and method renamings (
> http://cr.openjdk.java.net/~jbachorik/8233197/webrev/jfrRecorder.cpp.rej).
>
> All jdk/jfr tests have been run successfully with this patch applied.
>
> Thanks,
>
> -JB-
>

From christoph.langer at sap.com  Wed Mar 11 14:03:28 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 11 Mar 2020 14:03:28 +0000
Subject: RFR [jdk11]: 8232880 : Update test documentation with additional
 settings for client UI tooltip tests
In-Reply-To: <AM0PR02MB4227AF44AA93B3B8F457115693FF0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227AF44AA93B3B8F457115693FF0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57143B04430C559208AE15368AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

this looks good. Probably due to a different version of pandoc used, there are 2 minor diffs in testing.html but this seems fine.

Cheers
Christoph

From: Baesken, Matthias <matthias.baesken at sap.com>
Sent: Dienstag, 10. M?rz 2020 16:19
To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RFR [jdk11]: 8232880 : Update test documentation with additional settings for client UI tooltip tests

Hello, please review  the following downport  of  8232880  to jdk11 .

The doc/testing.md  adjustment of the jdk/jdk  change  applies cleanly, and as expected the html needs to be regenerated from it with "make update-build-docs" .


https://bugs.openjdk.java.net/browse/JDK-8232880

http://cr.openjdk.java.net/~mbaesken/webrevs/8232880_jdk11/

Thanks, Matthias

From sgehwolf at redhat.com  Wed Mar 11 14:52:38 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 11 Mar 2020 15:52:38 +0100
Subject: [11u] RFR: 8189861: Refactor CacheFind
In-Reply-To: <AM0PR02MB5714456B19DEDD0134AA281F8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>
 <AM0PR02MB5714ECA7A6B2E56C9E3AD9D88AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <22460aec95031c690f78fa3f4f71feac73e9e293.camel@redhat.com>
 <AM0PR02MB5714456B19DEDD0134AA281F8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <55cfc70d91fe7475b29233169125e67d3bd6b784.camel@redhat.com>

On Wed, 2020-03-11 at 12:47 +0000, Langer, Christoph wrote:
> OK, I guess you're right. Here is the new webrev: 
> http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u.1/

Looks good.

Thanks,
Severin


From maoliang.ml at alibaba-inc.com  Wed Mar 11 15:22:08 2020
From: maoliang.ml at alibaba-inc.com (Liang Mao)
Date: Wed, 11 Mar 2020 23:22:08 +0800
Subject: =?UTF-8?B?WzExdV0gQmFja3BvcnQgSkVQIDM0NiA6IFByb21wdGx5IFJldHVybiBVbnVzZWQgQ29tbWl0?=
 =?UTF-8?B?dGVkIE1lbW9yeSBmcm9tIEcx?=
Message-ID: <65c770e4-6f99-4c40-9f27-9a60d36c5085.maoliang.ml@alibaba-inc.com>

Hi All,

The JEP 346 in JDK12 is a very attractive feature which could save
significant memory and is very useful to the customers of Alibaba
 cloud. Jdk11u is the latest LTS version and will exist as a mainstream
version for a long time. I'd like to backport the corresponding patches.

There're total 12 changesets:
3 changesets of features and fixes that JEP346 depends on
3 changesets of code refinements that JEP346 depends on
6 changesets of JEP346 feature implementation and bug fixes

8 changesets can be just applied and only 4 have very few conflicts
needed to be resolved(less than 20 lines). I have listed the changesets
below in a timeline order. 

I have an initial test with these changesets based on jdk-11.0.7+4 on
test/hotspot/jtreg/gc/ and specjbb2015. Everything looks fine except
gc/survivorAlignment/TestPromotionToSurvivor.java failed both with
my build and reference build of jdk-11.0.7+4.

1) https://bugs.openjdk.java.net/browse/JDK-8208669
 GC changes to allow enabling -Wreorder 
No conflict apply.

2) https://bugs.openjdk.java.net/browse/JDK-8071913
 Filter out entries to free/uncommitted regions during iteration 
Conflicts:
    src/hotspot/share/gc/g1/g1RemSet.cpp
Webrev?http://cr.openjdk.java.net/~ddong/liangmao/8071913/webrev/

3) https://bugs.openjdk.java.net/browse/JDK-6490394
 G1: Allow heap shrinking / memory unmapping after reclaiming regions during Remark 
No conflict apply

4) https://bugs.openjdk.java.net/browse/JDK-8213898
 CDS dumping of springboot asserts in G1ArchiveAllocator::alloc_new_region 
No conflict apply

5) https://bugs.openjdk.java.net/browse/JDK-8193312
 Rename VM_CGC_Operation to VM_G1Concurrent 
Conflicts: (vm_operations.hpp already renamed vmOperations.hpp)
src/hotspot/share/runtime/vm_operations.hpp 
Webrev?http://cr.openjdk.java.net/~ddong/liangmao/8193312/webrev/

6) https://bugs.openjdk.java.net/browse/JDK-8214791
 Consistently name gc files containing VM operations 
Conflicts:(vm_operations.hpp already renamed vmOperations.hpp)
    src/hotspot/share/gc/cms/cmsVMOperations.hpp
    src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
Webrev?http://cr.openjdk.java.net/~ddong/liangmao/8214791/webrev/ 

7) https://bugs.openjdk.java.net/browse/JDK-8212657
 Implementation of JDK-8204089 Promptly Return Unused Committed Memory from G1 
No conflict apply

8) https://bugs.openjdk.java.net/browse/JDK-8215120
 32-bit build failures after JDK-8212657 (Promptly Return Unused Committed Memory from G1) 
No conflict apply

9) https://bugs.openjdk.java.net/browse/JDK-8215149
 TestOptionsWithRangesDynamic.java fails after JDK-8215120 
No conflict apply

10) https://bugs.openjdk.java.net/browse/JDK-8215548
 G1PeriodicGCSystemLoadThreshold needs to be a double 
No conflict apply

11) https://bugs.openjdk.java.net/browse/JDK-8216490
Spammy periodic GC log message contains random time stamp with periodic gc disabled
No conflict apply

12) https://bugs.openjdk.java.net/browse/JDK-8218880
 G1 crashes when issuing a periodic GC while the GCLocker is held 
Conflicts:
src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp (copyright)
build failure:
src/hotspot/share/gc/g1/g1CollectedHeap.cpp
    } else if (GCLocker::should_discard(cause, gc_count_before)) {
      // Return false to be consistent with VMOp failure due to
      // another collection slipping in after our gc_count but before
      // our request is processed.  _gc_locker collections upgraded by
      // GCLockerInvokesConcurrent are handled above and never discarded.
-       return;
+       return false;Webrev?http://cr.openjdk.java.net/~ddong/liangmao/8218880/webrev/ 


PS:
7) JDK-8212657 might have a build error of uninitialized variable:
src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp
bool G1YoungRemSetSamplingThread::should_start_periodic_gc() {
...
uintx time_since_last_gc;
11) JDK-8216490 will fix this.

Thanks,
Liang


From matthias.baesken at sap.com  Thu Mar 12 07:50:16 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Mar 2020 07:50:16 +0000
Subject: RFR [jdk11]:  8231810:
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently
 with "java.lang.Exception: Unexpected EOF"
Message-ID: <AM0PR02MB4227237142E6C64FEACAE76793FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello, please review the  jdk11 downport of   8231810 .
This is needed  for the jdk11 downport of  https://bugs.openjdk.java.net/browse/JDK-8234724 .

The change to

test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java

applies cleanly.
The change to

test/jdk/ProblemList.txt

does not apply , but is not needed .



Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8231810

http://cr.openjdk.java.net/~mbaesken/webrevs/8231810_jdk11/



( original  jdk/jdk webrev :  https://hg.openjdk.java.net/jdk/jdk/rev/dcf8e70d78d5  )


Thanks, Matthias

From thomas.stuefe at gmail.com  Thu Mar 12 08:02:08 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 12 Mar 2020 09:02:08 +0100
Subject: RFR [jdk11]: 8231810:
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
 fails intermittently with "java.lang.Exception: Unexpected EOF"
In-Reply-To: <AM0PR02MB4227237142E6C64FEACAE76793FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227237142E6C64FEACAE76793FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUw-37BJNkr_j96wF_qvV8UbSzTcwPsBaYGn=GqpvX9n0A@mail.gmail.com>

Hi Matthias,

looks good. I wish Mercurial diffs would ignore whitespace changes like
webrev seems to do, that would make comparing patches easier.

..Thomas

On Thu, Mar 12, 2020 at 8:51 AM Baesken, Matthias <matthias.baesken at sap.com>
wrote:

> Hello, please review the  jdk11 downport of   8231810 .
> This is needed  for the jdk11 downport of
> https://bugs.openjdk.java.net/browse/JDK-8234724 .
>
> The change to
>
> test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java
>
> applies cleanly.
> The change to
>
> test/jdk/ProblemList.txt
>
> does not apply , but is not needed .
>
>
>
> Bug/webrev :
>
> https://bugs.openjdk.java.net/browse/JDK-8231810
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8231810_jdk11/
>
>
>
> ( original  jdk/jdk webrev :
> https://hg.openjdk.java.net/jdk/jdk/rev/dcf8e70d78d5  )
>
>
> Thanks, Matthias
>

From christoph.langer at sap.com  Thu Mar 12 08:03:53 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 12 Mar 2020 08:03:53 +0000
Subject: RFR [jdk11]:  8231810:
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently
 with "java.lang.Exception: Unexpected EOF"
In-Reply-To: <AM0PR02MB4227237142E6C64FEACAE76793FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227237142E6C64FEACAE76793FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57140758147A3AE96F372E9C8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

that looks fine. Indeed, test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java wasn't problem listed in 11u.

Best regards
Christoph

From: Baesken, Matthias <matthias.baesken at sap.com>
Sent: Donnerstag, 12. M?rz 2020 08:50
To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RFR [jdk11]: 8231810: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF"

Hello, please review the  jdk11 downport of   8231810 .
This is needed  for the jdk11 downport of  https://bugs.openjdk.java.net/browse/JDK-8234724 .

The change to

test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java

applies cleanly.
The change to

test/jdk/ProblemList.txt

does not apply , but is not needed .



Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8231810

http://cr.openjdk.java.net/~mbaesken/webrevs/8231810_jdk11/



( original  jdk/jdk webrev :  https://hg.openjdk.java.net/jdk/jdk/rev/dcf8e70d78d5  )


Thanks, Matthias

From matthias.baesken at sap.com  Thu Mar 12 08:22:20 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 12 Mar 2020 08:22:20 +0000
Subject: RFR [jdk11]:  8231810:
 javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently
 with "java.lang.Exception: Unexpected EOF"
In-Reply-To: <AM0PR02MB57140758147A3AE96F372E9C8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227237142E6C64FEACAE76793FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR02MB57140758147A3AE96F372E9C8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB422761E2AB6B1B134079C1ED93FD0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hi Christoph and Thomas, thanks for the reviews .

From: Langer, Christoph <christoph.langer at sap.com>
Sent: Donnerstag, 12. M?rz 2020 09:04
To: Baesken, Matthias <matthias.baesken at sap.com>; jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Subject: RE: RFR [jdk11]: 8231810: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF"

Hi Matthias,

that looks fine. Indeed, test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java wasn't problem listed in 11u.

Best regards
Christoph

From: Baesken, Matthias <matthias.baesken at sap.com<mailto:matthias.baesken at sap.com>>
Sent: Donnerstag, 12. M?rz 2020 08:50
To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Subject: RFR [jdk11]: 8231810: javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java fails intermittently with "java.lang.Exception: Unexpected EOF"

Hello, please review the  jdk11 downport of   8231810 .
This is needed  for the jdk11 downport of  https://bugs.openjdk.java.net/browse/JDK-8234724 .

The change to

test/jdk/javax/net/ssl/templates/SSLSocketSSLEngineTemplate.java

applies cleanly.
The change to

test/jdk/ProblemList.txt

does not apply , but is not needed .



Bug/webrev :

https://bugs.openjdk.java.net/browse/JDK-8231810

http://cr.openjdk.java.net/~mbaesken/webrevs/8231810_jdk11/



( original  jdk/jdk webrev :  https://hg.openjdk.java.net/jdk/jdk/rev/dcf8e70d78d5  )


Thanks, Matthias

From sgehwolf at redhat.com  Thu Mar 12 10:25:19 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 12 Mar 2020 11:25:19 +0100
Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK
 libraries"
In-Reply-To: <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com>
References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com>
 <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com>
Message-ID: <8fb86173a8912d571e930eb2782e784d66fc6806.camel@redhat.com>

Hi Andrew,

On Thu, 2020-02-27 at 15:43 +0100, Severin Gehwolf wrote:
> On Thu, 2020-02-27 at 04:52 +0000, Andrew Hughes wrote:
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8232748
> > Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/
> > 
> > This patch adds targets to the build so that static versions of the JDK
> > native libraries can be built, using static-libs-image. Such static
> > versions of the libraries are required for consumption by Graal.
> > 
> > With JDK-8210459 now in 11u, this is a largely clean backport, aside
> > from some context changes, due to additional targets (JCov, JMH) being
> > present in trunk:
> > 
> > * In make/Bundles.gmk, 11u does not have jcov-bundles
> > * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles
> > * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR, etc or
> > JCOV_BUNDLE_NAME.
> > * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't
> > include jmh and jcov.

Right, those changes look fine to me.

Reviewed. Please add jdk11u-fix-request label to the bug.

> > Building the new target, static-libs-image, succeeded. This should have
> > no effect on other targets.
> 
> Unfortunately this patch doesn't work. While a build of static-libs-
> image succeeds, it doesn't create the image in build/<config-
> name>/images. Expected is this:
> 
> $ find build/linux-x86_64-normal-server-release/images/static-libs/
> build/linux-x86_64-normal-server-release/images/static-libs/
> build/linux-x86_64-normal-server-release/images/static-libs/lib
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pkcs11.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pcsc.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnio.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libprefs.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjava.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjli.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnet.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjimage.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjaas.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libfdlibm.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2gss.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libsunec.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjsig.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libextnet.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libverify.a
> build/linux-x86_64-normal-server-release/images/static-libs/lib/libzip.a
> 
> The reason for this is that FindFiles isn't available in JDK 11u.

Since Christoph backported JDK-8189861 to jdk11u-dev, the patch now
works as expected with FindFiles.

Thanks,
Severin


From christoph.langer at sap.com  Thu Mar 12 10:52:10 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 12 Mar 2020 10:52:10 +0000
Subject: [11u]: RFR 8235686: Add more custom hooks in Bundles.gmk
Message-ID: <AM0PR02MB57145AAC78DFB51D0A630C978AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

please help to review this Oracle-11.0.7 parity backport for the build system.

Bug: https://bugs.openjdk.java.net/browse/JDK-8235686
Original Change: https://hg.openjdk.java.net/jdk/jdk14/rev/91a3f092682f
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235686.11u/

The patch needed some trivial resolves and is preceded by JDK-8232572 which was already reviewed and will be pushed before this one.

Thanks
Christoph


From christoph.langer at sap.com  Thu Mar 12 10:53:52 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 12 Mar 2020 10:53:52 +0000
Subject: [11u] RFR: 8189861: Refactor CacheFind
In-Reply-To: <55cfc70d91fe7475b29233169125e67d3bd6b784.camel@redhat.com>
References: <AM0PR02MB57149C79679BA5F31A2FE8558AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <8338e197cdc5d058f3b54da4ea91795610e54941.camel@redhat.com>
 <AM0PR02MB5714ECA7A6B2E56C9E3AD9D88AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <22460aec95031c690f78fa3f4f71feac73e9e293.camel@redhat.com>
 <AM0PR02MB5714456B19DEDD0134AA281F8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <55cfc70d91fe7475b29233169125e67d3bd6b784.camel@redhat.com>
Message-ID: <AM0PR02MB57145FA87558DA1F219977A48AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks, Severin. I pushed it to jdk11u-dev now.

Cheers
Christoph


> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Mittwoch, 11. M?rz 2020 15:53
> To: Langer, Christoph <christoph.langer at sap.com>; Volker Simonis
> <volker.simonis at gmail.com>; Andrew Hughes <gnu.andrew at redhat.com>;
> jdk-updates-dev at openjdk.java.net
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: 8189861: Refactor CacheFind
> 
> On Wed, 2020-03-11 at 12:47 +0000, Langer, Christoph wrote:
> > OK, I guess you're right. Here is the new webrev:
> > http://cr.openjdk.java.net/~clanger/webrevs/8189861.11u.1/
> 
> Looks good.
> 
> Thanks,
> Severin


From christoph.langer at sap.com  Thu Mar 12 12:03:53 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 12 Mar 2020 12:03:53 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
Message-ID: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi all,

as you may or may not know, the GraalVM Community Edition (CE) supports OpenJDK 11 update releases. In order to do that, there exists a clone of the OpenJDK repository in the GraalVM GitHub space [0]. This fork, however, contains several additional patches, obviously mainly in the area of JVMCI and the Graal compiler. There seems to be a certain interest of the involved parties, that is, the GraalVM community, Oracle Labs and probably also the OpenJDK community, to keep these repositories as close as possible.

One motivation could be to allow building of GraalVM native images from OpenJDK distributions, such as mentioned in a GitHub issue raised against the graal project [1].

Another motivation probably comes from the Graal community to reduce the maintenance effort from merging the OpenJDK changes.

Furthermore, it has been policy in the OpenJDK 11 Updates project to try to follow what Oracle is doing in their JDK 11 LTS update releases. Lately, there obviously have been backports for JVMCI and Graal which completely don't match with the current state of OpenJDK 11u. When researching this I learned that the prerequisite of these kind of changes is a larger update of JVMCI and Graal. The basis for this change could be a commit from the labs-openjdk-11 Graal repository [2]. This would update JVMCI and Graal to the state of OpenJDK 13. More details can be taken out of the conversation of the GitHub issue [1].

I took this change, applied it to OpenJDK 11u-dev, resolved some conflicts and made sure it builds on all platforms (that we support in the SAP team). A prerequisite would also be a backport of JDK-8208686, at least the hotspot part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are contained in [3]. With this work applied, regression testing looks quite promising. There are a few test failures in the NMT area, some crashes with aot and a few minor Graal related test errors, but nothing that couldn't be solved with too much of effort, I guess. But I can't make any judgement on the state of the Graal compiler itself, since we don't have much test coverage for that in our infrastructure.

However, the main point for me is to get a discussion started. First of all it is about whether we want to have this kind of update at all in OpenJDK 11 Updates? If so, I'd need some help by people with expertise and test infrastructure for the Graal related part. That's nothing we can cover in the SAP team right now. If we decide against this update, we'll have give up our policy about following the Oracle 11 Updates for JVMCI/Graal.

Looking forward to get input about this.

Thanks and best regards
Christoph

[0] https://github.com/graalvm/labs-openjdk-11/
[1] https://github.com/oracle/graal/issues/2196
[2] https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
[3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
[4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/


From richard.reingruber at sap.com  Thu Mar 12 14:51:42 2020
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Thu, 12 Mar 2020 14:51:42 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
Message-ID: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>

Hi,
 
Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8235183
  https://hg.openjdk.java.net/jdk/jdk/rev/d8b5e32ffa2f
 
Original patch does not apply cleanly to 11u, because
src/java.base/share/classes/sun/security/ssl/NamedGroup.java is missing in
11u.
The NamedGroup.java modified by the original change was added in JDK13 with 
https://bugs.openjdk.java.net/browse/JDK-8171279

Subsequent changes (8226374, 8233954) added the comments to NamedGroup.java that are removed with
the original change.

Changes on other files _did_ apply cleanly.
 
11u webrev:
  http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
 
Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with fastdebug and release
builds on all platforms.

Thanks,
Richard.

From sgehwolf at redhat.com  Thu Mar 12 15:43:45 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 12 Mar 2020 16:43:45 +0100
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
Message-ID: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>

Hi,

Could I please get a review of this OpenJDK 11u port of JDK-8236921?
This patch is really only for developer convenience who prefer to build
their JDK from source and would like to build svm/graal with the
result. It adds a new make target, 'graal-builder-image' which then
produces an image in <images>/graal-builder-jdk which can be used to
build graal/svm.

This patch depends on the static-images libs backport[1]. Note that
even with that the JDK 15 patch does not apply cleanly because of some
context changes:

 * jcov-image target is not in JDK 11
 * Copyright dates differ in make/Main.gmk and
   make/autoconf/spec.gmk.in.

Fixed both manually.

Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236921/jdk11u/01/webrev/

Testing: built graal-builder-image target and with the result graal
master. Works fine.

Thanks,
Severin

[1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002740.html
    Hopefully to be integrated soon.


From goetz.lindenmaier at sap.com  Thu Mar 12 16:42:43 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 12 Mar 2020 16:42:43 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB60493276F67D8EBF613AD43EECFD0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Rich,

Change looks good. 

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Reingruber, Richard
> Sent: Thursday, March 12, 2020 3:52 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR 8235183: Remove the "HACK CODE" in
> comment
> 
> Hi,
> 
> Original bug:
>   https://bugs.openjdk.java.net/browse/JDK-8235183
>   https://hg.openjdk.java.net/jdk/jdk/rev/d8b5e32ffa2f
> 
> Original patch does not apply cleanly to 11u, because
> src/java.base/share/classes/sun/security/ssl/NamedGroup.java is missing in
> 11u.
> The NamedGroup.java modified by the original change was added in JDK13
> with
> https://bugs.openjdk.java.net/browse/JDK-8171279
> 
> Subsequent changes (8226374, 8233954) added the comments to
> NamedGroup.java that are removed with
> the original change.
> 
> Changes on other files _did_ apply cleanly.
> 
> 11u webrev:
>   http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
> 
> Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with
> fastdebug and release
> builds on all platforms.
> 
> Thanks,
> Richard.

From goetz.lindenmaier at sap.com  Thu Mar 12 17:11:38 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 12 Mar 2020 17:11:38 +0000
Subject: [11u]: RFR 8235686: Add more custom hooks in Bundles.gmk
In-Reply-To: <AM0PR02MB57145AAC78DFB51D0A630C978AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57145AAC78DFB51D0A630C978AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049C41221A0EADBFD62DFDBECFD0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Christoph,

The change looks good. Reviewed.

I think Volker wants to bring the FindFiles/CacheFind change to 11, 
which is in the problematic contexts. But I think we should not 
wait for that, as this is a oracle parity change.  It's trivial to resolve
anyways.

As Severin I think it's fine to push this to 11.0.8, after all we 
already have tag 7 in jdk11u, i.e. only two weeks to go.

Best regards,
  Goetz


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Thursday, March 12, 2020 11:52 AM
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: [CAUTION] [11u]: RFR 8235686: Add more custom hooks in
> Bundles.gmk
> 
> Hi,
> 
> please help to review this Oracle-11.0.7 parity backport for the build system.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8235686
> Original Change: https://hg.openjdk.java.net/jdk/jdk14/rev/91a3f092682f
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235686.11u/
> 
> The patch needed some trivial resolves and is preceded by JDK-8232572
> which was already reviewed and will be pushed before this one.
> 
> Thanks
> Christoph


From gnu.andrew at redhat.com  Thu Mar 12 18:11:44 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 12 Mar 2020 18:11:44 +0000
Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK
 libraries"
In-Reply-To: <8fb86173a8912d571e930eb2782e784d66fc6806.camel@redhat.com>
References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com>
 <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com>
 <8fb86173a8912d571e930eb2782e784d66fc6806.camel@redhat.com>
Message-ID: <d8a79bf5-8d0a-9014-06d1-9c4729f1af18@redhat.com>



On 12/03/2020 10:25, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Thu, 2020-02-27 at 15:43 +0100, Severin Gehwolf wrote:
>> On Thu, 2020-02-27 at 04:52 +0000, Andrew Hughes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232748
>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/
>>>
>>> This patch adds targets to the build so that static versions of the JDK
>>> native libraries can be built, using static-libs-image. Such static
>>> versions of the libraries are required for consumption by Graal.
>>>
>>> With JDK-8210459 now in 11u, this is a largely clean backport, aside
>>> from some context changes, due to additional targets (JCov, JMH) being
>>> present in trunk:
>>>
>>> * In make/Bundles.gmk, 11u does not have jcov-bundles
>>> * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles
>>> * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR, etc or
>>> JCOV_BUNDLE_NAME.
>>> * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't
>>> include jmh and jcov.
> 
> Right, those changes look fine to me.
> 
> Reviewed. Please add jdk11u-fix-request label to the bug.
> 
>>> Building the new target, static-libs-image, succeeded. This should have
>>> no effect on other targets.
>>
>> Unfortunately this patch doesn't work. While a build of static-libs-
>> image succeeds, it doesn't create the image in build/<config-
>> name>/images. Expected is this:
>>
>> $ find build/linux-x86_64-normal-server-release/images/static-libs/
>> build/linux-x86_64-normal-server-release/images/static-libs/
>> build/linux-x86_64-normal-server-release/images/static-libs/lib
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pkcs11.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2pcsc.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnio.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libprefs.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjava.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjli.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnet.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjimage.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjaas.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libfdlibm.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2gss.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libsunec.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjsig.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libextnet.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libverify.a
>> build/linux-x86_64-normal-server-release/images/static-libs/lib/libzip.a
>>
>> The reason for this is that FindFiles isn't available in JDK 11u.
> 
> Since Christoph backported JDK-8189861 to jdk11u-dev, the patch now
> works as expected with FindFiles.

Right, I get that on my build now. It would have been nice if you'd told
me to look for this in the first place before submitting the patch.

Bug flagged for approval.

> 
> 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  Thu Mar 12 18:27:19 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 12 Mar 2020 18:27:19 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>



On 12/03/2020 12:03, Langer, Christoph wrote:
> Hi all,
> 
> as you may or may not know, the GraalVM Community Edition (CE) supports OpenJDK 11 update releases. In order to do that, there exists a clone of the OpenJDK repository in the GraalVM GitHub space [0]. This fork, however, contains several additional patches, obviously mainly in the area of JVMCI and the Graal compiler. There seems to be a certain interest of the involved parties, that is, the GraalVM community, Oracle Labs and probably also the OpenJDK community, to keep these repositories as close as possible.
> 
> One motivation could be to allow building of GraalVM native images from OpenJDK distributions, such as mentioned in a GitHub issue raised against the graal project [1].
> 
> Another motivation probably comes from the Graal community to reduce the maintenance effort from merging the OpenJDK changes.
> 
> Furthermore, it has been policy in the OpenJDK 11 Updates project to try to follow what Oracle is doing in their JDK 11 LTS update releases. Lately, there obviously have been backports for JVMCI and Graal which completely don't match with the current state of OpenJDK 11u. When researching this I learned that the prerequisite of these kind of changes is a larger update of JVMCI and Graal. The basis for this change could be a commit from the labs-openjdk-11 Graal repository [2]. This would update JVMCI and Graal to the state of OpenJDK 13. More details can be taken out of the conversation of the GitHub issue [1].
> 
> I took this change, applied it to OpenJDK 11u-dev, resolved some conflicts and made sure it builds on all platforms (that we support in the SAP team). A prerequisite would also be a backport of JDK-8208686, at least the hotspot part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are contained in [3]. With this work applied, regression testing looks quite promising. There are a few test failures in the NMT area, some crashes with aot and a few minor Graal related test errors, but nothing that couldn't be solved with too much of effort, I guess. But I can't make any judgement on the state of the Graal compiler itself, since we don't have much test coverage for that in our infrastructure.
> 
> However, the main point for me is to get a discussion started. First of all it is about whether we want to have this kind of update at all in OpenJDK 11 Updates? If so, I'd need some help by people with expertise and test infrastructure for the Graal related part. That's nothing we can cover in the SAP team right now. If we decide against this update, we'll have give up our policy about following the Oracle 11 Updates for JVMCI/Graal.
> 
> Looking forward to get input about this.
> 
> Thanks and best regards
> Christoph
> 
> [0] https://github.com/graalvm/labs-openjdk-11/
> [1] https://github.com/oracle/graal/issues/2196
> [2] https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
> [3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
> [4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
> 

I'm aware of these changes for Graal and have been working on getting
some of them into OpenJDK 11u.

I don't think we should just apply these monolithic commits, but instead
work out the relevant issues in OpenJDK 13 being backported and do it
correctly. We want 11u to be as maintainable as possible.
-- 
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 neugens at redhat.com  Thu Mar 12 18:30:05 2020
From: neugens at redhat.com (Mario Torre)
Date: Thu, 12 Mar 2020 19:30:05 +0100
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
In-Reply-To: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
References: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
Message-ID: <CAJwKKma8BK=8FVG7dn-kVEA+jh5Jm3BjKfYzWsDHPAhHvxcEuA@mail.gmail.com>

Hi Severin,

The patch looks fine to me.

Cheers,
Mario

On Thu, Mar 12, 2020 at 4:43 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:
>
> Hi,
>
> Could I please get a review of this OpenJDK 11u port of JDK-8236921?
> This patch is really only for developer convenience who prefer to build
> their JDK from source and would like to build svm/graal with the
> result. It adds a new make target, 'graal-builder-image' which then
> produces an image in <images>/graal-builder-jdk which can be used to
> build graal/svm.
>
> This patch depends on the static-images libs backport[1]. Note that
> even with that the JDK 15 patch does not apply cleanly because of some
> context changes:
>
>  * jcov-image target is not in JDK 11
>  * Copyright dates differ in make/Main.gmk and
>    make/autoconf/spec.gmk.in.
>
> Fixed both manually.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236921/jdk11u/01/webrev/
>
> Testing: built graal-builder-image target and with the result graal
> master. Works fine.
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002740.html
>     Hopefully to be integrated soon.
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From adinn at redhat.com  Thu Mar 12 18:56:23 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 12 Mar 2020 18:56:23 +0000
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
In-Reply-To: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
References: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
Message-ID: <e0ccc809-5757-efe7-81c0-bd3b5c3a7237@redhat.com>


Hi Severin,

The patch looks good to me.

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

On 12/03/2020 15:43, Severin Gehwolf wrote:
> Could I please get a review of this OpenJDK 11u port of JDK-8236921?
> This patch is really only for developer convenience who prefer to build
> their JDK from source and would like to build svm/graal with the
> result. It adds a new make target, 'graal-builder-image' which then
> produces an image in <images>/graal-builder-jdk which can be used to
> build graal/svm.
> 
> This patch depends on the static-images libs backport[1]. Note that
> even with that the JDK 15 patch does not apply cleanly because of some
> context changes:
> 
>  * jcov-image target is not in JDK 11
>  * Copyright dates differ in make/Main.gmk and
>    make/autoconf/spec.gmk.in.
> 
> Fixed both manually.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236921/jdk11u/01/webrev/
> 
> Testing: built graal-builder-image target and with the result graal
> master. Works fine.
> 
> Thanks,
> Severin
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002740.html
>     Hopefully to be integrated soon.
> 


From gnu.andrew at redhat.com  Fri Mar 13 03:45:40 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 13 Mar 2020 03:45:40 +0000
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
In-Reply-To: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
References: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
Message-ID: <34811002-d594-a582-d87b-83f272d0cc9d@redhat.com>

On 12/03/2020 15:43, Severin Gehwolf wrote:
> Hi,
> 
> Could I please get a review of this OpenJDK 11u port of JDK-8236921?
> This patch is really only for developer convenience who prefer to build
> their JDK from source and would like to build svm/graal with the
> result. It adds a new make target, 'graal-builder-image' which then
> produces an image in <images>/graal-builder-jdk which can be used to
> build graal/svm.
> 
> This patch depends on the static-images libs backport[1]. Note that
> even with that the JDK 15 patch does not apply cleanly because of some
> context changes:
> 
>  * jcov-image target is not in JDK 11
>  * Copyright dates differ in make/Main.gmk and
>    make/autoconf/spec.gmk.in.
> 
> Fixed both manually.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8236921/jdk11u/01/webrev/
> 
> Testing: built graal-builder-image target and with the result graal
> master. Works fine.
> 
> Thanks,
> Severin
> 
> [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002740.html
>     Hopefully to be integrated soon.
> 

This webrev is a mess, I guess because it's not been applied against
trunk, but with 8232748 in your local tree as well. I don't see why you
didn't wait until 8232748 was pushed before creating this.

The patch itself looks fine, once reordered to match the 14u version
(not sure why the new file occurs first in the 14u version, but not in
yours). These are the same contextual issues that occurred with 8232748.
-- 
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 christoph.langer at sap.com  Fri Mar 13 07:55:59 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 07:55:59 +0000
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
In-Reply-To: <34811002-d594-a582-d87b-83f272d0cc9d@redhat.com>
References: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
 <34811002-d594-a582-d87b-83f272d0cc9d@redhat.com>
Message-ID: <AM0PR02MB5714C208686944F5B89E92788AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi there,

seems like we currently have a queue of backports that touch the build system. I suggest we apply them in them in the same order as they have been pushed to head. That would be:

1. JDK-8223678 Add Visual Studio Code workspace generation support (for native code)
2. JDK-8232572 Add hooks for custom output dir in Bundles.gmk
3. JDK-8232748 Build static versions of certain JDK libraries
4. JDK-8235686 Add more custom hooks in Bundles.gmk
5. JDK-8236921 Add build target to produce a JDK image suitable for a Graal/SVM build
and eventually I'm planning to backport
6. JDK-8237192 Generate stripped/public pdbs on Windows for jdk images

Applying them in order will probably help to have the least possible amount of rejects and manual resolves.

I'll go through the proposed patches now in that order and regenerate the patches where necessary. I'll post to the relevant review threads.

Cheers
Christoph


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Hughes
> Sent: Freitag, 13. M?rz 2020 04:46
> To: Severin Gehwolf <sgehwolf at redhat.com>; jdk-updates-dev <jdk-
> updates-dev at openjdk.java.net>
> Subject: Re: [11u] RFR(s): 8236921: Add build target to produce a JDK image
> suitable for a Graal/SVM build
> 
> On 12/03/2020 15:43, Severin Gehwolf wrote:
> > Hi,
> >
> > Could I please get a review of this OpenJDK 11u port of JDK-8236921?
> > This patch is really only for developer convenience who prefer to build
> > their JDK from source and would like to build svm/graal with the
> > result. It adds a new make target, 'graal-builder-image' which then
> > produces an image in <images>/graal-builder-jdk which can be used to
> > build graal/svm.
> >
> > This patch depends on the static-images libs backport[1]. Note that
> > even with that the JDK 15 patch does not apply cleanly because of some
> > context changes:
> >
> >  * jcov-image target is not in JDK 11
> >  * Copyright dates differ in make/Main.gmk and
> >    make/autoconf/spec.gmk.in.
> >
> > Fixed both manually.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8236921/jdk11u/01/webrev/
> >
> > Testing: built graal-builder-image target and with the result graal
> > master. Works fine.
> >
> > Thanks,
> > Severin
> >
> > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> March/002740.html
> >     Hopefully to be integrated soon.
> >
> 
> This webrev is a mess, I guess because it's not been applied against
> trunk, but with 8232748 in your local tree as well. I don't see why you
> didn't wait until 8232748 was pushed before creating this.
> 
> The patch itself looks fine, once reordered to match the 14u version
> (not sure why the new file occurs first in the 14u version, but not in
> yours). These are the same contextual issues that occurred with 8232748.
> --
> 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 christoph.langer at sap.com  Fri Mar 13 08:03:36 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 08:03:36 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
Message-ID: <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Andrew, all,

> -----Original Message-----
> From: Andrew Hughes <gnu.andrew at redhat.com>
> Sent: Donnerstag, 12. M?rz 2020 19:27
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
> <doug.simon at oracle.com>; Tom Rodriguez <tom.rodriguez at oracle.com>;
> Volker Simonis <volker.simonis at gmail.com>
> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
> 
> 
> 
> On 12/03/2020 12:03, Langer, Christoph wrote:
> > Hi all,
> >
> > as you may or may not know, the GraalVM Community Edition (CE)
> supports OpenJDK 11 update releases. In order to do that, there exists a
> clone of the OpenJDK repository in the GraalVM GitHub space [0]. This fork,
> however, contains several additional patches, obviously mainly in the area of
> JVMCI and the Graal compiler. There seems to be a certain interest of the
> involved parties, that is, the GraalVM community, Oracle Labs and probably
> also the OpenJDK community, to keep these repositories as close as possible.
> >
> > One motivation could be to allow building of GraalVM native images from
> OpenJDK distributions, such as mentioned in a GitHub issue raised against
> the graal project [1].
> >
> > Another motivation probably comes from the Graal community to reduce
> the maintenance effort from merging the OpenJDK changes.
> >
> > Furthermore, it has been policy in the OpenJDK 11 Updates project to try to
> follow what Oracle is doing in their JDK 11 LTS update releases. Lately, there
> obviously have been backports for JVMCI and Graal which completely don't
> match with the current state of OpenJDK 11u. When researching this I
> learned that the prerequisite of these kind of changes is a larger update of
> JVMCI and Graal. The basis for this change could be a commit from the labs-
> openjdk-11 Graal repository [2]. This would update JVMCI and Graal to the
> state of OpenJDK 13. More details can be taken out of the conversation of
> the GitHub issue [1].
> >
> > I took this change, applied it to OpenJDK 11u-dev, resolved some conflicts
> and made sure it builds on all platforms (that we support in the SAP team). A
> prerequisite would also be a backport of JDK-8208686, at least the hotspot
> part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are
> contained in [3]. With this work applied, regression testing looks quite
> promising. There are a few test failures in the NMT area, some crashes with
> aot and a few minor Graal related test errors, but nothing that couldn't be
> solved with too much of effort, I guess. But I can't make any judgement on
> the state of the Graal compiler itself, since we don't have much test coverage
> for that in our infrastructure.
> >
> > However, the main point for me is to get a discussion started. First of all it is
> about whether we want to have this kind of update at all in OpenJDK 11
> Updates? If so, I'd need some help by people with expertise and test
> infrastructure for the Graal related part. That's nothing we can cover in the
> SAP team right now. If we decide against this update, we'll have give up our
> policy about following the Oracle 11 Updates for JVMCI/Graal.
> >
> > Looking forward to get input about this.
> >
> > Thanks and best regards
> > Christoph
> >
> > [0] https://github.com/graalvm/labs-openjdk-11/
> > [1] https://github.com/oracle/graal/issues/2196
> > [2] https://github.com/graalvm/labs-openjdk-
> 11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
> > [3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
> > [4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
> >
> 
> I'm aware of these changes for Graal and have been working on getting
> some of them into OpenJDK 11u.
> 
> I don't think we should just apply these monolithic commits, but instead
> work out the relevant issues in OpenJDK 13 being backported and do it
> correctly. We want 11u to be as maintainable as possible.

I've got some sympathy with that approach. We can certainly have a look to identify the single changes and try to apply them one by one... It'll probably also help to identify the sources of regressions when we run into some.

But, the general question that needs to be answered before is: Do we want this to happen at all? Any opinions/thoughts?

Cheers
Christoph


From christoph.langer at sap.com  Fri Mar 13 08:43:14 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 08:43:14 +0000
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I recreated the webrev after backport of 8189861: Refactor CacheFind.

http://cr.openjdk.java.net/~clanger/webrevs/8223678.11u/

The only difference to the original proposal (http://cr.openjdk.java.net/~simonis/webrevs/2020/8223678/) is that no modification to test/make/TestMakeBase.gmk is necessary any more).

Please review ASAP, as this would be the first push in the series of build system backports.

Thanks
Christoph


> -----Original Message-----
> From: Langer, Christoph
> Sent: Mittwoch, 11. M?rz 2020 10:54
> To: Volker Simonis <volker.simonis at gmail.com>; Andrew Hughes
> <gnu.andrew at redhat.com>
> Cc: build-dev <build-dev at openjdk.java.net>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8223678: Add Visual Studio Code workspace
> generation support (for native code)
> 
> Hi Volker,
> 
> > > Out of interest, is the AssertEquals macro something worth backporting
> > > at some point? Generally, I find its worthwhile if people are going to
> > > be doing the same replacement in multiple backports.
> > >
> >
> > I actually wanted to answer something like "..lets wait until we get
> > another backport requiring this.." but already before answering we
> > already ran into such a case (see my answer to the other thread
> > "8232748: "Build static versions of certain JDK libraries"). The only
> > problem is that "8189861: Refactor CacheFind" which introduced
> > AssertEquals is not a trivial downport.
> >
> > Please let me know what you think?
> 
> I've just proposed the backport of "8189861: Refactor CacheFind". Can you
> rebase your change on that and see if it works?
> 
> Best regards
> Christoph


From christoph.langer at sap.com  Fri Mar 13 08:52:46 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 08:52:46 +0000
Subject: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk
In-Reply-To: <AM0PR02MB57144B4E6B63D15AECE3358D8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57144B4E6B63D15AECE3358D8AFE0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB5714C853D9F2F72AE33145AE8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I regenerated the webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u.1/

Still looks pretty much the same as before. Will push to jdk11u-dev after JDK-8223678.

Cheers
Christoph

From: Langer, Christoph
Sent: Montag, 9. M?rz 2020 14:57
To: jdk-updates-dev at openjdk.java.net
Cc: build-dev <build-dev at openjdk.java.net>
Subject: RFR [11u] 8232572: Add hooks for custom output dir in Bundles.gmk

Hi,

please review this Oracle parity backport.

Bug: https://bugs.openjdk.java.net/browse/JDK-8232572
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ae0af9fb3dbb
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8232572.11u/

I had to manually bring some hunks to the right position in the file. The $$(call MakeTargetDir) does not yet exist as it was only introduced with JDK-8211724. So I just add the LogWarn call as first command in the recipe.

Thanks and best regards
Christoph


From aph at redhat.com  Fri Mar 13 09:30:03 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2020 09:30:03 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
Message-ID: <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>

On 3/12/20 2:51 PM, Reingruber, Richard wrote:
>  
> 11u webrev:
>   http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
>  
> Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with fastdebug and release
> builds on all platforms.

This isn't suitable for a backport. It fixes no bugs, and has no
user-visible behaviour.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From christoph.langer at sap.com  Fri Mar 13 09:32:41 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 09:32:41 +0000
Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK
 libraries"
In-Reply-To: <d8a79bf5-8d0a-9014-06d1-9c4729f1af18@redhat.com>
References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com>
 <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com>
 <8fb86173a8912d571e930eb2782e784d66fc6806.camel@redhat.com>
 <d8a79bf5-8d0a-9014-06d1-9c4729f1af18@redhat.com>
Message-ID: <AM0PR02MB5714D4D3423C45634C5807928AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I've regenerated this webrev as well: http://cr.openjdk.java.net/~clanger/webrevs/8232748.11u/ (with JDK-8223678 and JDK-8232572 applied)

Patch content looks identical to the one already reviewed.

I'd volunteer to push this in order with the other patches.

Cheers
Christoph


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Hughes
> Sent: Donnerstag, 12. M?rz 2020 19:12
> To: Severin Gehwolf <sgehwolf at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: Re: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK
> libraries"
> 
> 
> 
> On 12/03/2020 10:25, Severin Gehwolf wrote:
> > Hi Andrew,
> >
> > On Thu, 2020-02-27 at 15:43 +0100, Severin Gehwolf wrote:
> >> On Thu, 2020-02-27 at 04:52 +0000, Andrew Hughes wrote:
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8232748
> >>> Webrev:
> https://cr.openjdk.java.net/~andrew/openjdk11/8232748/webrev.01/
> >>>
> >>> This patch adds targets to the build so that static versions of the JDK
> >>> native libraries can be built, using static-libs-image. Such static
> >>> versions of the libraries are required for consumption by Graal.
> >>>
> >>> With JDK-8210459 now in 11u, this is a largely clean backport, aside
> >>> from some context changes, due to additional targets (JCov, JMH) being
> >>> present in trunk:
> >>>
> >>> * In make/Bundles.gmk, 11u does not have jcov-bundles
> >>> * In make/Main.gmk, 11u does not have jcov-image or jcov-bundles
> >>> * In make/autoconf/spec.gmk.in, 11u does not have JMH_CORE_JAR,
> etc or
> >>> JCOV_BUNDLE_NAME.
> >>> * In make/conf/jib-profiles.js, the dependencies list in 11u doesn't
> >>> include jmh and jcov.
> >
> > Right, those changes look fine to me.
> >
> > Reviewed. Please add jdk11u-fix-request label to the bug.
> >
> >>> Building the new target, static-libs-image, succeeded. This should have
> >>> no effect on other targets.
> >>
> >> Unfortunately this patch doesn't work. While a build of static-libs-
> >> image succeeds, it doesn't create the image in build/<config-
> >> name>/images. Expected is this:
> >>
> >> $ find build/linux-x86_64-normal-server-release/images/static-libs/
> >> build/linux-x86_64-normal-server-release/images/static-libs/
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libj2pkcs11.a
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libj2pcsc.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnio.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libprefs.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjava.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjli.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libnet.a
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libjimage.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjaas.a
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libfdlibm.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libj2gss.a
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libsunec.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libjsig.a
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libextnet.a
> >> build/linux-x86_64-normal-server-release/images/static-
> libs/lib/libverify.a
> >> build/linux-x86_64-normal-server-release/images/static-libs/lib/libzip.a
> >>
> >> The reason for this is that FindFiles isn't available in JDK 11u.
> >
> > Since Christoph backported JDK-8189861 to jdk11u-dev, the patch now
> > works as expected with FindFiles.
> 
> Right, I get that on my build now. It would have been nice if you'd told
> me to look for this in the first place before submitting the patch.
> 
> Bug flagged for approval.
> 
> >
> > 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 christoph.langer at sap.com  Fri Mar 13 09:44:06 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 09:44:06 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
Message-ID: <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Andrew,

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Freitag, 13. M?rz 2020 10:30
> To: Reingruber, Richard <richard.reingruber at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
> 
> On 3/12/20 2:51 PM, Reingruber, Richard wrote:
> >
> > 11u webrev:
> >   http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
> >
> > Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with
> fastdebug and release
> > builds on all platforms.
> 
> This isn't suitable for a backport. It fixes no bugs, and has no
> user-visible behaviour.

Well, one could certainly see it that way. However, we always tried to backport what we found was backported to the equivalent Oracle release. Shall we change this policy?

After all, it improves some comments.

Best regards
Christoph


From matthias.baesken at sap.com  Fri Mar 13 09:56:09 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 13 Mar 2020 09:56:09 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
Message-ID: <AM0PR02MB422780E6DABA02FA5E9425DF93FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hi Andrew, in some cases it helps to backport also comment-changes like this , because it makes backporting follow-up changes  easier  (less diffs / easier patching).
And I estimate that there will be follow ups in the sun/security/ssl code   ,  where backporting is important .



Best regards, Matthias

------------------------------

Message: 3
Date: Fri, 13 Mar 2020 09:30:03 +0000
From: Andrew Haley <aph at redhat.com>
To: "Reingruber, Richard" <richard.reingruber at sap.com>,
	"jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
Message-ID: <6de39d56-fbf5-648b-31f8-c3c5386878b6 at redhat.com>
Content-Type: text/plain; charset=utf-8

On 3/12/20 2:51 PM, Reingruber, Richard wrote:
>  
> 11u webrev:
>   http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
>  
> Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with fastdebug and release
> builds on all platforms.

This isn't suitable for a backport. It fixes no bugs, and has no
user-visible behaviour.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From christoph.langer at sap.com  Fri Mar 13 09:56:55 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 09:56:55 +0000
Subject: [11u]: RFR 8235686: Add more custom hooks in Bundles.gmk
In-Reply-To: <AM7PR02MB6049C41221A0EADBFD62DFDBECFD0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM0PR02MB57145AAC78DFB51D0A630C978AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM7PR02MB6049C41221A0EADBFD62DFDBECFD0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57140F49B5AB0FA23872AF448AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Goetz,

thanks for the review.

This is the rebased webrev on 11u-dev after JDK-8223678, JDK-8232572 and JDK-8232748: http://cr.openjdk.java.net/~clanger/webrevs/8235686.11u.1/. The changes are obviously still the same but the context differs.

Will push it in order to 11u-dev (11.0.8).

Cheers
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Donnerstag, 12. M?rz 2020 18:12
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev <jdk-
> updates-dev at openjdk.java.net>
> Cc: build-dev <build-dev at openjdk.java.net>
> Subject: RE: [11u]: RFR 8235686: Add more custom hooks in Bundles.gmk
> 
> Hi Christoph,
> 
> The change looks good. Reviewed.
> 
> I think Volker wants to bring the FindFiles/CacheFind change to 11,
> which is in the problematic contexts. But I think we should not
> wait for that, as this is a oracle parity change.  It's trivial to resolve
> anyways.
> 
> As Severin I think it's fine to push this to 11.0.8, after all we
> already have tag 7 in jdk11u, i.e. only two weeks to go.
> 
> Best regards,
>   Goetz
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Langer, Christoph
> > Sent: Thursday, March 12, 2020 11:52 AM
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Cc: build-dev <build-dev at openjdk.java.net>
> > Subject: [CAUTION] [11u]: RFR 8235686: Add more custom hooks in
> > Bundles.gmk
> >
> > Hi,
> >
> > please help to review this Oracle-11.0.7 parity backport for the build
> system.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8235686
> > Original Change: https://hg.openjdk.java.net/jdk/jdk14/rev/91a3f092682f
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235686.11u/
> >
> > The patch needed some trivial resolves and is preceded by JDK-8232572
> > which was already reviewed and will be pushed before this one.
> >
> > Thanks
> > Christoph


From aph at redhat.com  Fri Mar 13 10:02:23 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2020 10:02:23 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>

Hi,

On 3/13/20 9:44 AM, Langer, Christoph wrote:
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
>> Behalf Of Andrew Haley
>> Sent: Freitag, 13. M?rz 2020 10:30
>> To: Reingruber, Richard <richard.reingruber at sap.com>; jdk-updates-
>> dev at openjdk.java.net
>> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
>>
>> On 3/12/20 2:51 PM, Reingruber, Richard wrote:
>>>
>>> 11u webrev:
>>>   http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
>>>
>>> Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with
>> fastdebug and release
>>> builds on all platforms.
>>
>> This isn't suitable for a backport. It fixes no bugs, and has no
>> user-visible behaviour.
>
> Well, one could certainly see it that way. However, we always tried
> to backport what we found was backported to the equivalent Oracle
> release.

How do you know? Presumably because you have access to Oracle's closed
source code.

> Shall we change this policy?

That policy exists because we don't want to have bugs in OpenJDK which
are fixed in Oracle's releases. There never has been any policy which
says that the source code should be identical, and that's impossible
anyway. It never occurred to me that anyone would interpret the policy
in such a way.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph at redhat.com  Fri Mar 13 10:05:50 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2020 10:05:50 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <AM0PR02MB422780E6DABA02FA5E9425DF93FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB422780E6DABA02FA5E9425DF93FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <cb8805e7-50f8-db82-5e4f-21338ddb29be@redhat.com>

Hi,

On 3/13/20 9:56 AM, Baesken, Matthias wrote:

> in some cases it helps to backport also comment-changes like this ,
> because it makes backporting follow-up changes easier (less diffs /
> easier patching).  And I estimate that there will be follow ups in
> the sun/security/ssl code , where backporting is important .

Hmm. Surely we can make that change when we backport the follow
ups. I don't see how changing comments in this way makes life any
easier, and it certainly adds more churn to the process.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From christoph.langer at sap.com  Fri Mar 13 10:24:02 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 10:24:02 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
Message-ID: <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Freitag, 13. M?rz 2020 11:02
> To: Langer, Christoph <christoph.langer at sap.com>; Reingruber, Richard
> <richard.reingruber at sap.com>; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
> 
> Hi,
> 
> On 3/13/20 9:44 AM, Langer, Christoph wrote:
> >> -----Original Message-----
> >> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> >> Behalf Of Andrew Haley
> >> Sent: Freitag, 13. M?rz 2020 10:30
> >> To: Reingruber, Richard <richard.reingruber at sap.com>; jdk-updates-
> >> dev at openjdk.java.net
> >> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
> >>
> >> On 3/12/20 2:51 PM, Reingruber, Richard wrote:
> >>>
> >>> 11u webrev:
> >>>   http://cr.openjdk.java.net/~rrich/webrevs/8235183.jdk11u/webrev.0/
> >>>
> >>> Testing: nightly tests @SAP, i.e. jck and jtreg, also in Xcomp mode with
> >> fastdebug and release
> >>> builds on all platforms.
> >>
> >> This isn't suitable for a backport. It fixes no bugs, and has no
> >> user-visible behaviour.
> >
> > Well, one could certainly see it that way. However, we always tried
> > to backport what we found was backported to the equivalent Oracle
> > release.
> 
> How do you know? Presumably because you have access to Oracle's closed
> source code.

No, we just know that this backport exists: https://bugs.openjdk.java.net/browse/JDK-8238957.

What Oracle effectively did in its closed code doesn't matter - they could have done anything.

> > Shall we change this policy?
> 
> That policy exists because we don't want to have bugs in OpenJDK which
> are fixed in Oracle's releases. There never has been any policy which
> says that the source code should be identical, and that's impossible
> anyway. It never occurred to me that anyone would interpret the policy
> in such a way.

Sure, the main motivation for that policy is to have all bugs fixed in OpenJDK that Oracle chose to fix.
For 11u, though, we have so far effectively backported everything we saw backported to Oracle, no matter if it were comment changes, license header changes etc.
I personally would rather continue with this. But if we chose to stop with that and be more picky about changes that don't affect the binary results, I have no strong emotions. We should just not reject this backport and later on approve others that fall into the same category.

You are the lead maintainer, you can set the rules ??

Cheers
Christoph


From christoph.langer at sap.com  Fri Mar 13 10:30:12 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 10:30:12 +0000
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
In-Reply-To: <34811002-d594-a582-d87b-83f272d0cc9d@redhat.com>
References: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
 <34811002-d594-a582-d87b-83f272d0cc9d@redhat.com>
Message-ID: <AM0PR02MB5714F4AAD20BA096E96C158B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I also regenerated this webrev: http://cr.openjdk.java.net/~clanger/webrevs/8236921.11u/

The patch is essentially the same. Will be the last in my queue to push.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Hughes
> Sent: Freitag, 13. M?rz 2020 04:46
> To: Severin Gehwolf <sgehwolf at redhat.com>; jdk-updates-dev <jdk-
> updates-dev at openjdk.java.net>
> Subject: Re: [11u] RFR(s): 8236921: Add build target to produce a JDK image
> suitable for a Graal/SVM build
> 
> On 12/03/2020 15:43, Severin Gehwolf wrote:
> > Hi,
> >
> > Could I please get a review of this OpenJDK 11u port of JDK-8236921?
> > This patch is really only for developer convenience who prefer to build
> > their JDK from source and would like to build svm/graal with the
> > result. It adds a new make target, 'graal-builder-image' which then
> > produces an image in <images>/graal-builder-jdk which can be used to
> > build graal/svm.
> >
> > This patch depends on the static-images libs backport[1]. Note that
> > even with that the JDK 15 patch does not apply cleanly because of some
> > context changes:
> >
> >  * jcov-image target is not in JDK 11
> >  * Copyright dates differ in make/Main.gmk and
> >    make/autoconf/spec.gmk.in.
> >
> > Fixed both manually.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> 8236921/jdk11u/01/webrev/
> >
> > Testing: built graal-builder-image target and with the result graal
> > master. Works fine.
> >
> > Thanks,
> > Severin
> >
> > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> March/002740.html
> >     Hopefully to be integrated soon.
> >
> 
> This webrev is a mess, I guess because it's not been applied against
> trunk, but with 8232748 in your local tree as well. I don't see why you
> didn't wait until 8232748 was pushed before creating this.
> 
> The patch itself looks fine, once reordered to match the 14u version
> (not sure why the new file occurs first in the 14u version, but not in
> yours). These are the same contextual issues that occurred with 8232748.
> --
> 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 Mar 13 10:43:14 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Mar 2020 11:43:14 +0100
Subject: [11u] RFR(s): 8236921: Add build target to produce a JDK image
 suitable for a Graal/SVM build
In-Reply-To: <AM0PR02MB5714C208686944F5B89E92788AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <7987592643d28b11777a771842c04122dc08861b.camel@redhat.com>
 <34811002-d594-a582-d87b-83f272d0cc9d@redhat.com>
 <AM0PR02MB5714C208686944F5B89E92788AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <84b81beb9d9aa7d91a1c2fdb3d2a1eb727d650c9.camel@redhat.com>

Hi,

On Fri, 2020-03-13 at 07:55 +0000, Langer, Christoph wrote:
> Hi there,
> 
> seems like we currently have a queue of backports that touch the build system. I suggest we apply them in them in the same order as they have been pushed to head. That would be:
> 
> 1. JDK-8223678 Add Visual Studio Code workspace generation support (for native code)
> 2. JDK-8232572 Add hooks for custom output dir in Bundles.gmk
> 3. JDK-8232748 Build static versions of certain JDK libraries
> 4. JDK-8235686 Add more custom hooks in Bundles.gmk
> 5. JDK-8236921 Add build target to produce a JDK image suitable for a Graal/SVM build
> and eventually I'm planning to backport
> 6. JDK-8237192 Generate stripped/public pdbs on Windows for jdk images
> 
> Applying them in order will probably help to have the least possible amount of rejects and manual resolves.
> 
> I'll go through the proposed patches now in that order and regenerate the patches where necessary. I'll post to the relevant review threads.

Fair enough. I'll try to review JDK-8223678.

Thanks,
Severin

> Cheers
> Christoph
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Andrew Hughes
> > Sent: Freitag, 13. M?rz 2020 04:46
> > To: Severin Gehwolf <sgehwolf at redhat.com>; jdk-updates-dev <jdk-
> > updates-dev at openjdk.java.net>
> > Subject: Re: [11u] RFR(s): 8236921: Add build target to produce a JDK image
> > suitable for a Graal/SVM build
> > 
> > On 12/03/2020 15:43, Severin Gehwolf wrote:
> > > Hi,
> > > 
> > > Could I please get a review of this OpenJDK 11u port of JDK-8236921?
> > > This patch is really only for developer convenience who prefer to build
> > > their JDK from source and would like to build svm/graal with the
> > > result. It adds a new make target, 'graal-builder-image' which then
> > > produces an image in <images>/graal-builder-jdk which can be used to
> > > build graal/svm.
> > > 
> > > This patch depends on the static-images libs backport[1]. Note that
> > > even with that the JDK 15 patch does not apply cleanly because of some
> > > context changes:
> > > 
> > >  * jcov-image target is not in JDK 11
> > >  * Copyright dates differ in make/Main.gmk and
> > >    make/autoconf/spec.gmk.in.
> > > 
> > > Fixed both manually.
> > > 
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236921
> > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
> > 8236921/jdk11u/01/webrev/
> > > Testing: built graal-builder-image target and with the result graal
> > > master. Works fine.
> > > 
> > > Thanks,
> > > Severin
> > > 
> > > [1] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> > March/002740.html
> > >     Hopefully to be integrated soon.
> > > 
> > 
> > This webrev is a mess, I guess because it's not been applied against
> > trunk, but with 8232748 in your local tree as well. I don't see why you
> > didn't wait until 8232748 was pushed before creating this.
> > 
> > The patch itself looks fine, once reordered to match the 14u version
> > (not sure why the new file occurs first in the 14u version, but not in
> > yours). These are the same contextual issues that occurred with 8232748.
> > --
> > 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 goetz.lindenmaier at sap.com  Fri Mar 13 12:02:05 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 13 Mar 2020 12:02:05 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <cb8805e7-50f8-db82-5e4f-21338ddb29be@redhat.com>
References: <AM0PR02MB422780E6DABA02FA5E9425DF93FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <cb8805e7-50f8-db82-5e4f-21338ddb29be@redhat.com>
Message-ID: <AM7PR02MB6049B114869CD6AC8BABDB24ECFA0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

I asked Richard to work on the changes in the query on the jdk11u 
project page. I want to get more people in our team working on this, 
as we didn't make the dev close of 11.0.7. So thanks Rich for helping
out!

As this change has no effect whatsoever, it makes no difference 
whether it is downported or not. (Obviously Oracle does not want
somebody to read through the code and find hints to hacks ... like
parties that have licensed the code ...)

For the query, we can flag it with openjdk-na.

For people that do their own query, and that wonder
that this is not downported, we can comment that it
is only a comment change and thus needs not be downported.
Well, they must read the bug all to the end up to the comment,
or they'll find out themselves by reading the patch.

But we can as well just push it ... then our code does not
mention hacks either ??

... but really not a big issue ...

Andrew, please decide and label the bug accordingly.

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Friday, March 13, 2020 11:06 AM
> To: Baesken, Matthias <matthias.baesken at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
> 
> Hi,
> 
> On 3/13/20 9:56 AM, Baesken, Matthias wrote:
> 
> > in some cases it helps to backport also comment-changes like this ,
> > because it makes backporting follow-up changes easier (less diffs /
> > easier patching).  And I estimate that there will be follow ups in
> > the sun/security/ssl code , where backporting is important .
> 
> Hmm. Surely we can make that change when we backport the follow
> ups. I don't see how changing comments in this way makes life any
> easier, and it certainly adds more churn to the process.
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From sgehwolf at redhat.com  Fri Mar 13 12:58:51 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Mar 2020 13:58:51 +0100
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <e52f213921c5953eb89fc430069a74df43b828f4.camel@redhat.com>

On Fri, 2020-03-13 at 08:43 +0000, Langer, Christoph wrote:
> http://cr.openjdk.java.net/~clanger/webrevs/8223678.11u/

LGTM.

Thanks,
Severin


From christoph.langer at sap.com  Fri Mar 13 13:10:06 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 13:10:06 +0000
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <AM0PR02MB5714D0C1FCEC699FC5D8E6A28AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <e52f213921c5953eb89fc430069a74df43b828f4.camel@redhat.com>
 <AM0PR02MB5714D0C1FCEC699FC5D8E6A28AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57147804D707A071BABC264D8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

I accidentally removed the list from the recipients, sending this again...


-------snip-------------------

Thanks, Severin.
 
could you please approve the item then, and as well JDK-8232572, JDK-
8232748 and JDK-8235686? I guess I can push all these after approval.
 
Cheers
Christoph


> > -----Original Message-----
> > From: Severin Gehwolf <sgehwolf at redhat.com>
> > Sent: Freitag, 13. M?rz 2020 13:59
> > To: Langer, Christoph <christoph.langer at sap.com>; Volker Simonis
> > <volker.simonis at gmail.com>; Andrew Hughes
> <gnu.andrew at redhat.com>
> > Cc: jdk-updates-dev at openjdk.java.net
> > Subject: Re: [11u] RFR: 8223678: Add Visual Studio Code workspace
> > generation support (for native code)
> >
> > On Fri, 2020-03-13 at 08:43 +0000, Langer, Christoph wrote:
> > > http://cr.openjdk.java.net/~clanger/webrevs/8223678.11u/
> >
> > LGTM.
> >
> > Thanks,
> > Severin


From sgehwolf at redhat.com  Fri Mar 13 13:28:37 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Mar 2020 14:28:37 +0100
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <AM0PR02MB57147804D707A071BABC264D8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <e52f213921c5953eb89fc430069a74df43b828f4.camel@redhat.com>
 <AM0PR02MB5714D0C1FCEC699FC5D8E6A28AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57147804D707A071BABC264D8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <99de03ad38ad867e38f012b7820cea8d78ce0041.camel@redhat.com>

On Fri, 2020-03-13 at 13:10 +0000, Langer, Christoph wrote:
> Thanks, Severin.
>  
> could you please approve the item then, and as well JDK-8232572, JDK-
> 8232748 and JDK-8235686? I guess I can push all these after approval.

Done. JDK-8236921 is one for you to approve. I don't want to approve my
own requests.

Thanks,
Severin


From christoph.langer at sap.com  Fri Mar 13 13:55:40 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 13:55:40 +0000
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <99de03ad38ad867e38f012b7820cea8d78ce0041.camel@redhat.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <e52f213921c5953eb89fc430069a74df43b828f4.camel@redhat.com>
 <AM0PR02MB5714D0C1FCEC699FC5D8E6A28AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57147804D707A071BABC264D8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <99de03ad38ad867e38f012b7820cea8d78ce0041.camel@redhat.com>
Message-ID: <AM0PR02MB5714394B866EA74394F7B3FC8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks for approving.

I have a last minute update to JDK-8223678, though. By working on a backport of another change (JDK-8237192), I recognized that the function "isTargetOs" does not exist in 11u. So I had to replace 2 occurences, one in make/common/MakeBase.gmk and the other in make/vscode/CreateVSCodeProject.gmk with the equivalent construct "ifeq ($(OPENJDK_TARGET_OS), windows)". People would probably have recognized this error only when working on Windows.

New webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223678.11u.1/

Best regards
Christoph



> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Freitag, 13. M?rz 2020 14:29
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev <jdk-
> updates-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: 8223678: Add Visual Studio Code workspace
> generation support (for native code)
> 
> On Fri, 2020-03-13 at 13:10 +0000, Langer, Christoph wrote:
> > Thanks, Severin.
> >
> > could you please approve the item then, and as well JDK-8232572, JDK-
> > 8232748 and JDK-8235686? I guess I can push all these after approval.
> 
> Done. JDK-8236921 is one for you to approve. I don't want to approve my
> own requests.
> 
> Thanks,
> Severin


From sgehwolf at redhat.com  Fri Mar 13 14:03:38 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 13 Mar 2020 15:03:38 +0100
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <AM0PR02MB5714394B866EA74394F7B3FC8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <e52f213921c5953eb89fc430069a74df43b828f4.camel@redhat.com>
 <AM0PR02MB5714D0C1FCEC699FC5D8E6A28AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57147804D707A071BABC264D8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <99de03ad38ad867e38f012b7820cea8d78ce0041.camel@redhat.com>
 <AM0PR02MB5714394B866EA74394F7B3FC8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <528ea9605f6da7635ef4eede7e9f06930c6e6c39.camel@redhat.com>

On Fri, 2020-03-13 at 13:55 +0000, Langer, Christoph wrote:
> I have a last minute update to JDK-8223678, though. By working on a
> backport of another change (JDK-8237192), I recognized that the
> function "isTargetOs" does not exist in 11u. So I had to replace 2
> occurences, one in make/common/MakeBase.gmk and the other in
> make/vscode/CreateVSCodeProject.gmk with the equivalent construct
> "ifeq ($(OPENJDK_TARGET_OS), windows)". People would probably have
> recognized this error only when working on Windows.
> 
> New webrev: http://cr.openjdk.java.net/~clanger/webrevs/8223678.11u.1/

Good catch! Still good.

Thanks,
Severin


From christoph.langer at sap.com  Fri Mar 13 14:04:57 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 14:04:57 +0000
Subject: [11u] RFR: 8223678: Add Visual Studio Code workspace generation
 support (for native code)
In-Reply-To: <528ea9605f6da7635ef4eede7e9f06930c6e6c39.camel@redhat.com>
References: <CA+3eh137eU3zSmjyyVvfSNbQCOAp4ZkB4kMGRsMmeZVvHij-kQ@mail.gmail.com>
 <971e7935-c61c-1dee-dc1e-0bc567695222@redhat.com>
 <CA+3eh12wX8W2=Gn=eKFq2jYTQr+XFcrCyVVk0d-ReofP=GnK=g@mail.gmail.com>
 <AM0PR02MB571420E83606AD3DC8E0B2FF8AFC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB571413619E7996FD23A3B4468AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <e52f213921c5953eb89fc430069a74df43b828f4.camel@redhat.com>
 <AM0PR02MB5714D0C1FCEC699FC5D8E6A28AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57147804D707A071BABC264D8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <99de03ad38ad867e38f012b7820cea8d78ce0041.camel@redhat.com>
 <AM0PR02MB5714394B866EA74394F7B3FC8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <528ea9605f6da7635ef4eede7e9f06930c6e6c39.camel@redhat.com>
Message-ID: <AM0PR02MB57143329AECB16D8CC7C01D78AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

OK, will push it then.

Cheers
Christoph

> -----Original Message-----
> From: Severin Gehwolf <sgehwolf at redhat.com>
> Sent: Freitag, 13. M?rz 2020 15:04
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev <jdk-
> updates-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: 8223678: Add Visual Studio Code workspace
> generation support (for native code)
> 
> On Fri, 2020-03-13 at 13:55 +0000, Langer, Christoph wrote:
> > I have a last minute update to JDK-8223678, though. By working on a
> > backport of another change (JDK-8237192), I recognized that the
> > function "isTargetOs" does not exist in 11u. So I had to replace 2
> > occurences, one in make/common/MakeBase.gmk and the other in
> > make/vscode/CreateVSCodeProject.gmk with the equivalent construct
> > "ifeq ($(OPENJDK_TARGET_OS), windows)". People would probably have
> > recognized this error only when working on Windows.
> >
> > New webrev:
> http://cr.openjdk.java.net/~clanger/webrevs/8223678.11u.1/
> 
> Good catch! Still good.
> 
> Thanks,
> Severin


From goetz.lindenmaier at sap.com  Fri Mar 13 14:21:28 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 13 Mar 2020 14:21:28 +0000
Subject: [11u] RFR(M): 8213250: CDS archive creation aborts due to metaspace
 object allocation failure
Message-ID: <AM7PR02MB6049AA4D6FEE33DD15249F7BECFA0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi

I would like to downport this [1] for parity with 11.0.8-oracle.

I had to resolve because in one context the InstandeKlass/Klass type differs.

Further the change depends on some previous changes in jdk/jdk.
I had to do the following changes in systemDictionaryShared.cpp:

Because [2] "8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files" 
is not in 11, the include of ClassLoaderDataGraph.hpp is not needed.

I had to undo the effects of [3] "8209301: JVM rename is_anonymous, host_klass to 
unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation":
is_unsafe_anonymous() --> is_anonymous()

The new SystemDictionaryShared::finalize_verification_constraints() locks the 
ClassLoaderDataGraph_lock. This lock was introduced by [4] "8210155: Lock 
ClassLoaderDataGraph Summary: In preparation for concurrent class unloading." and 
is not in 11. As I understand, 11 has no concurrent class loading, so this is not needed. 
Removed.

This webrev shows the edits I did after applying the change:
http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01-edits/

This is the resulting webrev:
http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01/

Please review.

Best regards,
  Goetz.

[1]
Original bug:
https://bugs.openjdk.java.net/browse/JDK-8213250 
http://hg.openjdk.java.net/jdk/jdk/rev/e0fd97beab7e
[2]
8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files
https://bugs.openjdk.java.net/browse/JDK-8209645
http://hg.openjdk.java.net/jdk/jdk/rev/db0c3952de52
[3]
8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead 
of Unsafe.defineAnonymousClass deprecation
https://bugs.openjdk.java.net/browse/JDK-8209301
http://hg.openjdk.java.net/jdk/jdk/rev/3e5d28e6de32
[4]
8210155: Lock ClassLoaderDataGraph Summary: In preparation for concurrent 
class unloading
https://bugs.openjdk.java.net/browse/JDK-8210155
http://hg.openjdk.java.net/jdk/jdk/rev/625a5bdde0c5




From goetz.lindenmaier at sap.com  Fri Mar 13 14:31:00 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 13 Mar 2020 14:31:00 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049455F078271B3654C7554ECFA0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Ping 

... anyone volunteering to review this?
It is needed for "8209333: Socket reset issue for TLS 1.3 socket close"

Best regards,
  Goetz.


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Tuesday, March 10, 2020 5:02 PM
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: [CAUTION] 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Hi,
> 
> I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> close"
> for parity with 11.0.8-oracle.
> 
> Severin pointed me to [3], "8219991: New fix of the deadlock in
> sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> introduced by [1]. I agree that it would make sense
> to bring this fix to jdk11u-dev along with [1].
> 
> [1] applies clean to jdk11u-dev.
> Unfortunately, [3] does not apply at all.
> 
> In jdk13 a major rework of JSSE was done:
> [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> [2] removes the synchronized keywords from a lot of functions
> in JSSE and replaces them by manual locking. [3] exploits
> the new control flow within these reworked functions in
> SSLSocketImpl.java. It needs to be designed differently
> to apply directly on top of [1].
> 
> Instead, I propose to downport the changes of [2] to the only
> file touched by [3], SSLSocketImpl.java.
> 
> I took the patch of [2] for SSLSocketImpl.java and patched
> it on top of [1] to jdk11u-dev. It applies clean. On top
> of this, [3] applies clean, too.
> 
> The SSLSocketImpl.java part of [2] uses a public lock
> introduced in OutputRecord. I revoked this part of the change
> as the changes to OutputRecord are not important here, so
> it'd like to skip them. Here the partial webrev of the
> revoked code:
> http://cr.openjdk.java.net/~goetz/wr20/8240827-
> Downport_SSLSocketImpl_from_8221882-jdk11/01-
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> diff.html
> 
> The locks introduced by [2] in SSLSocketImpl.java are private,
> so there is no direct dependency to them in other code.
> 
> I ran the three changes through our nightly testing
> and saw no issues.
> 
> Please review:
> http://cr.openjdk.java.net/~goetz/wr20/8240827-
> Downport_SSLSocketImpl_from_8221882-jdk11/01/
> 
> Best regards,
>   Goetz.
> 
> [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> https://bugs.openjdk.java.net/browse/JDK-8209333
> http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> 
> [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> https://bugs.openjdk.java.net/browse/JDK-8221882
> http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> 
> [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> https://bugs.openjdk.java.net/browse/JDK-8219991
> http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From matthias.baesken at sap.com  Fri Mar 13 14:31:41 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 13 Mar 2020 14:31:41 +0000
Subject: RFR: [jdk11] 8239462: jdk.hotspot.agent misses some
 ReleaseStringUTFChars calls in case of early returns
Message-ID: <AM0PR02MB4227D9D2ED30CF67EFCDB76293FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello, please review the backport of 8239462: jdk.hotspot.agent misses some ReleaseStringUTFChars calls in case of early returns  to jdk11.

I needed to change the jdk/jdk change a bit because in jdk11  LinuxDebuggerLocal.c  is C code and slightly different from    LinuxDebuggerLocal.cpp (C++)  in jdk/jdk   .



Bug/jdk11  webrev :

https://bugs.openjdk.java.net/browse/JDK-8239462

http://cr.openjdk.java.net/~mbaesken/webrevs/8239462_0_jdk11/

jdk/jdk webrev :
https://hg.openjdk.java.net/jdk/jdk/rev/61ee15b9a1ac

Thanks, Matthias

From aph at redhat.com  Fri Mar 13 15:27:32 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 13 Mar 2020 15:27:32 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
 <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>

On 3/13/20 10:24 AM, Langer, Christoph wrote:
>
>> -----Original Message-----
>> From: Andrew Haley <aph at redhat.com>
>> Sent: Freitag, 13. M?rz 2020 11:02
>> To: Langer, Christoph <christoph.langer at sap.com>; Reingruber, Richard
>> <richard.reingruber at sap.com>; jdk-updates-dev at openjdk.java.net
>> Subject: Re: [11u] RFR 8235183: Remove the "HACK CODE" in comment
>>
>> How do you know? Presumably because you have access to Oracle's closed
>> source code.
>
> No, we just know that this backport exists:
> https://bugs.openjdk.java.net/browse/JDK-8238957.

OK, I see.

>> That policy exists because we don't want to have bugs in OpenJDK which
>> are fixed in Oracle's releases. There never has been any policy which
>> says that the source code should be identical, and that's impossible
>> anyway. It never occurred to me that anyone would interpret the policy
>> in such a way.
>
> Sure, the main motivation for that policy is to have all bugs fixed
> in OpenJDK that Oracle chose to fix.
> For 11u, though, we have so far effectively backported everything we
> saw backported to Oracle, no matter if it were comment changes,
> license header changes etc.

That seems a little bit extreme, almost like we're making extra work
for ourselves because Oracle has done so. But thank you for that
explanation.

> I personally would rather continue with this. But if we chose to
> stop with that and be more picky about changes that don't affect the
> binary results, I have no strong emotions. We should just not reject
> this backport and later on approve others that fall into the same
> category.

Sure.

> You are the lead maintainer, you can set the rules ??

Yes, I understand that.

I can't guess why Oracle chose to backport this comment-only change,
but I believe that 11u is about fixing *significant* bugs, by which I
mean significant to *users*. Last year Aleksey Shipilev made the point
(rather forcefully!) that maintainers should still be able to reject
patches even if Oracle approved them. I suspect that the reason for
his reasoning was if Oracle decide to jump off a cliff, we shouldn't
jump with them. That isn't the case here, though: this patch is
harmless.

As has been pointed out, this is almost a zero-risk patch in that it
does nothing, but it's also a zero-gain patch in that it does nothing.
On the other hand it might mess up our statistics because there will
appear to be a patch Oracle backported but we didn't, and I can see
that will be misleading. It might even cause people to distrust us
because we're not fixing some bugs.

So I'm no longer sure. If you think it makes life easier for you to
apply patches which only affect source code, and they have equivalent
Oracle backports, go ahead. But let's not do so otherwise.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From martin.doerr at sap.com  Fri Mar 13 15:39:08 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 13 Mar 2020 15:39:08 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi G?tz,

I guess you don't want to backport the whole [2] because there are too many conflicts?

Technically, your partial backport of [2] looks good.

Are you planning to merge it with [3] before pushing?
I think [2] should not be flagged as backported when you only pick a subset of it.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Dienstag, 10. M?rz 2020 17:02
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Hi,
> 
> I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> close"
> for parity with 11.0.8-oracle.
> 
> Severin pointed me to [3], "8219991: New fix of the deadlock in
> sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> introduced by [1]. I agree that it would make sense
> to bring this fix to jdk11u-dev along with [1].
> 
> [1] applies clean to jdk11u-dev.
> Unfortunately, [3] does not apply at all.
> 
> In jdk13 a major rework of JSSE was done:
> [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> [2] removes the synchronized keywords from a lot of functions
> in JSSE and replaces them by manual locking. [3] exploits
> the new control flow within these reworked functions in
> SSLSocketImpl.java. It needs to be designed differently
> to apply directly on top of [1].
> 
> Instead, I propose to downport the changes of [2] to the only
> file touched by [3], SSLSocketImpl.java.
> 
> I took the patch of [2] for SSLSocketImpl.java and patched
> it on top of [1] to jdk11u-dev. It applies clean. On top
> of this, [3] applies clean, too.
> 
> The SSLSocketImpl.java part of [2] uses a public lock
> introduced in OutputRecord. I revoked this part of the change
> as the changes to OutputRecord are not important here, so
> it'd like to skip them. Here the partial webrev of the
> revoked code:
> http://cr.openjdk.java.net/~goetz/wr20/8240827-
> Downport_SSLSocketImpl_from_8221882-jdk11/01-
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> diff.html
> 
> The locks introduced by [2] in SSLSocketImpl.java are private,
> so there is no direct dependency to them in other code.
> 
> I ran the three changes through our nightly testing
> and saw no issues.
> 
> Please review:
> http://cr.openjdk.java.net/~goetz/wr20/8240827-
> Downport_SSLSocketImpl_from_8221882-jdk11/01/
> 
> Best regards,
>   Goetz.
> 
> [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> https://bugs.openjdk.java.net/browse/JDK-8209333
> http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> 
> [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> https://bugs.openjdk.java.net/browse/JDK-8221882
> http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> 
> [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> https://bugs.openjdk.java.net/browse/JDK-8219991
> http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From christoph.langer at sap.com  Fri Mar 13 15:39:02 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 15:39:02 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM7PR02MB6049455F078271B3654C7554ECFA0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM7PR02MB6049455F078271B3654C7554ECFA0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57141354551C998624013FC68AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Goetz,

I went through your changes and to me this looks good. Also the approach to take out a part of 8221882 and push it as a new bug (JDK-8240827) seems a good idea to me. As there were no regressions spotted, I'm confident with all this. I'll approve the backports.

Best regards
Christoph

> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Freitag, 13. M?rz 2020 15:31
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net>
> Cc: 'Severin Gehwolf' <sgehwolf at redhat.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Ping
> 
> ... anyone volunteering to review this?
> It is needed for "8209333: Socket reset issue for TLS 1.3 socket close"
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Tuesday, March 10, 2020 5:02 PM
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: [CAUTION] 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Hi,
> >
> > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> > close"
> > for parity with 11.0.8-oracle.
> >
> > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > introduced by [1]. I agree that it would make sense
> > to bring this fix to jdk11u-dev along with [1].
> >
> > [1] applies clean to jdk11u-dev.
> > Unfortunately, [3] does not apply at all.
> >
> > In jdk13 a major rework of JSSE was done:
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > [2] removes the synchronized keywords from a lot of functions
> > in JSSE and replaces them by manual locking. [3] exploits
> > the new control flow within these reworked functions in
> > SSLSocketImpl.java. It needs to be designed differently
> > to apply directly on top of [1].
> >
> > Instead, I propose to downport the changes of [2] to the only
> > file touched by [3], SSLSocketImpl.java.
> >
> > I took the patch of [2] for SSLSocketImpl.java and patched
> > it on top of [1] to jdk11u-dev. It applies clean. On top
> > of this, [3] applies clean, too.
> >
> > The SSLSocketImpl.java part of [2] uses a public lock
> > introduced in OutputRecord. I revoked this part of the change
> > as the changes to OutputRecord are not important here, so
> > it'd like to skip them. Here the partial webrev of the
> > revoked code:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > diff.html
> >
> > The locks introduced by [2] in SSLSocketImpl.java are private,
> > so there is no direct dependency to them in other code.
> >
> > I ran the three changes through our nightly testing
> > and saw no issues.
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> >
> > Best regards,
> >   Goetz.
> >
> > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > https://bugs.openjdk.java.net/browse/JDK-8209333
> > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> >
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > https://bugs.openjdk.java.net/browse/JDK-8221882
> > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> >
> > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > https://bugs.openjdk.java.net/browse/JDK-8219991
> > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From christoph.langer at sap.com  Fri Mar 13 15:44:30 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 15:44:30 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB571447A2793FFD69CBD7A7838AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Martin,

> Are you planning to merge it with [3] before pushing?

No, Goetz created a new Bug JDK-8240827 to have this separated out.

> I think [2] should not be flagged as backported when you only pick a subset
> of it.

It won't. JDK-8240827 will only have a "relates-to" link ??

> 
> Best regards,
> Martin

Cheers
Christoph

> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Dienstag, 10. M?rz 2020 17:02
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Hi,
> >
> > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> > close"
> > for parity with 11.0.8-oracle.
> >
> > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > introduced by [1]. I agree that it would make sense
> > to bring this fix to jdk11u-dev along with [1].
> >
> > [1] applies clean to jdk11u-dev.
> > Unfortunately, [3] does not apply at all.
> >
> > In jdk13 a major rework of JSSE was done:
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > [2] removes the synchronized keywords from a lot of functions
> > in JSSE and replaces them by manual locking. [3] exploits
> > the new control flow within these reworked functions in
> > SSLSocketImpl.java. It needs to be designed differently
> > to apply directly on top of [1].
> >
> > Instead, I propose to downport the changes of [2] to the only
> > file touched by [3], SSLSocketImpl.java.
> >
> > I took the patch of [2] for SSLSocketImpl.java and patched
> > it on top of [1] to jdk11u-dev. It applies clean. On top
> > of this, [3] applies clean, too.
> >
> > The SSLSocketImpl.java part of [2] uses a public lock
> > introduced in OutputRecord. I revoked this part of the change
> > as the changes to OutputRecord are not important here, so
> > it'd like to skip them. Here the partial webrev of the
> > revoked code:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > diff.html
> >
> > The locks introduced by [2] in SSLSocketImpl.java are private,
> > so there is no direct dependency to them in other code.
> >
> > I ran the three changes through our nightly testing
> > and saw no issues.
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> >
> > Best regards,
> >   Goetz.
> >
> > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > https://bugs.openjdk.java.net/browse/JDK-8209333
> > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> >
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > https://bugs.openjdk.java.net/browse/JDK-8221882
> > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> >
> > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > https://bugs.openjdk.java.net/browse/JDK-8219991
> > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From martin.doerr at sap.com  Fri Mar 13 15:44:23 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 13 Mar 2020 15:44:23 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB32976013154F69C825A673D99AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Ah, you backport the part of [2] as a separate issue which is not flagged as backport. This is fine with me.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Doerr, Martin
> Sent: Freitag, 13. M?rz 2020 16:39
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net>
> Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Hi G?tz,
> 
> I guess you don't want to backport the whole [2] because there are too many
> conflicts?
> 
> Technically, your partial backport of [2] looks good.
> 
> Are you planning to merge it with [3] before pushing?
> I think [2] should not be flagged as backported when you only pick a subset
> of it.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Dienstag, 10. M?rz 2020 17:02
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Hi,
> >
> > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> > close"
> > for parity with 11.0.8-oracle.
> >
> > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > introduced by [1]. I agree that it would make sense
> > to bring this fix to jdk11u-dev along with [1].
> >
> > [1] applies clean to jdk11u-dev.
> > Unfortunately, [3] does not apply at all.
> >
> > In jdk13 a major rework of JSSE was done:
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > [2] removes the synchronized keywords from a lot of functions
> > in JSSE and replaces them by manual locking. [3] exploits
> > the new control flow within these reworked functions in
> > SSLSocketImpl.java. It needs to be designed differently
> > to apply directly on top of [1].
> >
> > Instead, I propose to downport the changes of [2] to the only
> > file touched by [3], SSLSocketImpl.java.
> >
> > I took the patch of [2] for SSLSocketImpl.java and patched
> > it on top of [1] to jdk11u-dev. It applies clean. On top
> > of this, [3] applies clean, too.
> >
> > The SSLSocketImpl.java part of [2] uses a public lock
> > introduced in OutputRecord. I revoked this part of the change
> > as the changes to OutputRecord are not important here, so
> > it'd like to skip them. Here the partial webrev of the
> > revoked code:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > diff.html
> >
> > The locks introduced by [2] in SSLSocketImpl.java are private,
> > so there is no direct dependency to them in other code.
> >
> > I ran the three changes through our nightly testing
> > and saw no issues.
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> >
> > Best regards,
> >   Goetz.
> >
> > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > https://bugs.openjdk.java.net/browse/JDK-8209333
> > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> >
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > https://bugs.openjdk.java.net/browse/JDK-8221882
> > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> >
> > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > https://bugs.openjdk.java.net/browse/JDK-8219991
> > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From christoph.langer at sap.com  Fri Mar 13 16:15:14 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 16:15:14 +0000
Subject: [11u] RFR: 8235563: [TESTBUG]
 appcds/CommandLineFlagComboNegative.java does not handle archive mapping
 failure
Message-ID: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I guess this is the last review for a patch from the Oracle parity list for 11.0.7 that will make it into the release. It's a test only change.

The patch itself applies cleanly but it would result in test failures. I had to include a part from another change: http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8 (https://bugs.openjdk.java.net/browse/JDK-8204591). That part would remove the test execution for the disabled option -XX:+UseAppCDS, which doesn't fail as expected by the new logic..

Bug: https://bugs.openjdk.java.net/browse/JDK-8235563
Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6b8a675f35e1
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235563.11u/

Please review.

Thanks
Christoph


From calvin.cheung at oracle.com  Fri Mar 13 16:51:00 2020
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 13 Mar 2020 09:51:00 -0700
Subject: [11u] RFR: 8235563: [TESTBUG]
 appcds/CommandLineFlagComboNegative.java does not handle archive mapping
 failure
In-Reply-To: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <72bbadda-c3de-354b-d5ae-4af0da13c2a7@oracle.com>

Hi Christoph,

On 3/13/20 9:15 AM, Langer, Christoph wrote:
> Hi,
>
> I guess this is the last review for a patch from the Oracle parity list for 11.0.7 that will make it into the release. It's a test only change.
>
> The patch itself applies cleanly but it would result in test failures. I had to include a part from another change: http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8 (https://bugs.openjdk.java.net/browse/JDK-8204591). That part would remove the test execution for the disabled option -XX:+UseAppCDS, which doesn't fail as expected by the new logic..

The removed lines in your webrev was added for fixing 
https://bugs.openjdk.java.net/browse/JDK-8204563.

Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/50469fb301c4

I guess if you want to backport the fix for this bug as is, you'd need 
to backport JDK-8204563 as well.

thanks,

Calvin

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8235563
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6b8a675f35e1
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235563.11u/
>
> Please review.
>
> Thanks
> Christoph
>

From jianglizhou at google.com  Fri Mar 13 17:05:24 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 13 Mar 2020 10:05:24 -0700
Subject: [11u] RFR: 8235563: [TESTBUG]
 appcds/CommandLineFlagComboNegative.java
 does not handle archive mapping failure
In-Reply-To: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jy-3eB0dn=Gj182_oA68CwSP9V=ik_rbytPtrbDJhASZQ@mail.gmail.com>

Hi Christoph,

The modified backport looks good to me. The the partial change from
http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8
(https://bugs.openjdk.java.net/browse/JDK-8204591) looks okay. It's
for testing the obsolete UseAppCDS option and is not critical. The
diff is small enough and we can easily resolve any potential conflicts
in the future (if necessary).

Best regards,
Jiangli


On Fri, Mar 13, 2020 at 9:16 AM Langer, Christoph
<christoph.langer at sap.com> wrote:
>
> Hi,
>
> I guess this is the last review for a patch from the Oracle parity list for 11.0.7 that will make it into the release. It's a test only change.
>
> The patch itself applies cleanly but it would result in test failures. I had to include a part from another change: http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8 (https://bugs.openjdk.java.net/browse/JDK-8204591). That part would remove the test execution for the disabled option -XX:+UseAppCDS, which doesn't fail as expected by the new logic..
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8235563
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6b8a675f35e1
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235563.11u/
>
> Please review.
>
> Thanks
> Christoph
>

From christoph.langer at sap.com  Fri Mar 13 17:10:46 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 17:10:46 +0000
Subject: [11u] RFR: 8235563: [TESTBUG]
 appcds/CommandLineFlagComboNegative.java does not handle archive mapping
 failure
In-Reply-To: <72bbadda-c3de-354b-d5ae-4af0da13c2a7@oracle.com>
References: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <72bbadda-c3de-354b-d5ae-4af0da13c2a7@oracle.com>
Message-ID: <AM0PR02MB57147769E4974EAEBABAEA508AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Calvin,

> > I guess this is the last review for a patch from the Oracle parity list for 11.0.7
> that will make it into the release. It's a test only change.
> >
> > The patch itself applies cleanly but it would result in test failures. I had to
> include a part from another change:
> http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8
> (https://bugs.openjdk.java.net/browse/JDK-8204591). That part would
> remove the test execution for the disabled option -XX:+UseAppCDS, which
> doesn't fail as expected by the new logic..
> 
> The removed lines in your webrev was added for fixing
> https://bugs.openjdk.java.net/browse/JDK-8204563.
> 
> Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/50469fb301c4
> 
> I guess if you want to backport the fix for this bug as is, you'd need
> to backport JDK-8204563 as well.

JDK-8204563 is part of OpenJDK 11u already.

The problem is that the fix of JDK-8235563 adds an "assertAbnormalExit".  But -XX:+UseAppCDS won't exit abnormally. It'll return cleanly with returncode 0, always using "-XX:+UseAppCDS ".

Best regards
Christoph


From christoph.langer at sap.com  Fri Mar 13 17:11:29 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 17:11:29 +0000
Subject: [11u] RFR: 8235563: [TESTBUG]
 appcds/CommandLineFlagComboNegative.java does not handle archive mapping
 failure
In-Reply-To: <CALrW1jy-3eB0dn=Gj182_oA68CwSP9V=ik_rbytPtrbDJhASZQ@mail.gmail.com>
References: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <CALrW1jy-3eB0dn=Gj182_oA68CwSP9V=ik_rbytPtrbDJhASZQ@mail.gmail.com>
Message-ID: <AM0PR02MB57140713717E014EB776ED278AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks for the review, Jiangli.

> -----Original Message-----
> From: Jiangli Zhou <jianglizhou at google.com>
> Sent: Freitag, 13. M?rz 2020 18:05
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: Re: [11u] RFR: 8235563: [TESTBUG]
> appcds/CommandLineFlagComboNegative.java does not handle archive
> mapping failure
> 
> Hi Christoph,
> 
> The modified backport looks good to me. The the partial change from
> http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8
> (https://bugs.openjdk.java.net/browse/JDK-8204591) looks okay. It's
> for testing the obsolete UseAppCDS option and is not critical. The
> diff is small enough and we can easily resolve any potential conflicts
> in the future (if necessary).
> 
> Best regards,
> Jiangli
> 
> 
> On Fri, Mar 13, 2020 at 9:16 AM Langer, Christoph
> <christoph.langer at sap.com> wrote:
> >
> > Hi,
> >
> > I guess this is the last review for a patch from the Oracle parity list for 11.0.7
> that will make it into the release. It's a test only change.
> >
> > The patch itself applies cleanly but it would result in test failures. I had to
> include a part from another change:
> http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8
> (https://bugs.openjdk.java.net/browse/JDK-8204591). That part would
> remove the test execution for the disabled option -XX:+UseAppCDS, which
> doesn't fail as expected by the new logic..
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8235563
> > Original change: https://hg.openjdk.java.net/jdk/jdk/rev/6b8a675f35e1
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8235563.11u/
> >
> > Please review.
> >
> > Thanks
> > Christoph
> >

From calvin.cheung at oracle.com  Fri Mar 13 17:29:55 2020
From: calvin.cheung at oracle.com (Calvin Cheung)
Date: Fri, 13 Mar 2020 10:29:55 -0700
Subject: [11u] RFR: 8235563: [TESTBUG]
 appcds/CommandLineFlagComboNegative.java does not handle archive mapping
 failure
In-Reply-To: <AM0PR02MB57147769E4974EAEBABAEA508AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57146E98406EAFDBBFEF3D9B8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <72bbadda-c3de-354b-d5ae-4af0da13c2a7@oracle.com>
 <AM0PR02MB57147769E4974EAEBABAEA508AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <a00a6dd2-c64a-77a6-7049-223acf0596bf@oracle.com>


On 3/13/20 10:10 AM, Langer, Christoph wrote:
> Hi Calvin,
>
>>> I guess this is the last review for a patch from the Oracle parity list for 11.0.7
>> that will make it into the release. It's a test only change.
>>> The patch itself applies cleanly but it would result in test failures. I had to
>> include a part from another change:
>> http://hg.openjdk.java.net/jdk/jdk/rev/e34379f2a1c8
>> (https://bugs.openjdk.java.net/browse/JDK-8204591). That part would
>> remove the test execution for the disabled option -XX:+UseAppCDS, which
>> doesn't fail as expected by the new logic..
>>
>> The removed lines in your webrev was added for fixing
>> https://bugs.openjdk.java.net/browse/JDK-8204563.
>>
>> Changeset: http://hg.openjdk.java.net/jdk/jdk/rev/50469fb301c4
>>
>> I guess if you want to backport the fix for this bug as is, you'd need
>> to backport JDK-8204563 as well.
> JDK-8204563 is part of OpenJDK 11u already.
Ok. I haven't been following OpenJDK 11u closely.
>
> The problem is that the fix of JDK-8235563 adds an "assertAbnormalExit".  But -XX:+UseAppCDS won't exit abnormally. It'll return cleanly with returncode 0, always using "-XX:+UseAppCDS ".

Your patch looks good.

thanks,

Calvin

>
> Best regards
> Christoph
>

From gnu.andrew at redhat.com  Fri Mar 13 18:26:17 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 13 Mar 2020 18:26:17 +0000
Subject: [RFR] [11u] JDK-8232748: "Build static versions of certain JDK
 libraries"
In-Reply-To: <AM0PR02MB5714D4D3423C45634C5807928AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <9c9053d7-3f3e-17f1-ec1f-dadba6102214@redhat.com>
 <90baf4b54dec114854cb5286bcefda56e4d945e0.camel@redhat.com>
 <8fb86173a8912d571e930eb2782e784d66fc6806.camel@redhat.com>
 <d8a79bf5-8d0a-9014-06d1-9c4729f1af18@redhat.com>
 <AM0PR02MB5714D4D3423C45634C5807928AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <03405cef-1216-c013-6968-a96bb52e2950@redhat.com>



On 13/03/2020 09:32, Langer, Christoph wrote:
> Hi,
> 
> I've regenerated this webrev as well: http://cr.openjdk.java.net/~clanger/webrevs/8232748.11u/ (with JDK-8223678 and JDK-8232572 applied)
> 
> Patch content looks identical to the one already reviewed.
> 
> I'd volunteer to push this in order with the other patches.
> 
> Cheers
> Christoph
> 
> 

I'll push my own patches, 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 goetz.lindenmaier at sap.com  Sun Mar 15 20:19:15 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sun, 15 Mar 2020 20:19:15 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM0PR02MB57141354551C998624013FC68AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM7PR02MB6049455F078271B3654C7554ECFA0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR02MB57141354551C998624013FC68AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049AF6A5E2EF1698C464140ECF80@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Christoph, 

Thanks for reviewing. 

I'll wait a bit in case someone else has an opinion.  I'd appreciate a
second review as this is quite a complex change.

Best regards,
  Goetz

> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Friday, March 13, 2020 4:39 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net>
> Cc: 'Severin Gehwolf' <sgehwolf at redhat.com>
> Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Hi Goetz,
> 
> I went through your changes and to me this looks good. Also the approach to
> take out a part of 8221882 and push it as a new bug (JDK-8240827) seems a
> good idea to me. As there were no regressions spotted, I'm confident with all
> this. I'll approve the backports.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> > Sent: Freitag, 13. M?rz 2020 15:31
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> > <jdk-updates-dev at openjdk.java.net>
> > Cc: 'Severin Gehwolf' <sgehwolf at redhat.com>; Langer, Christoph
> > <christoph.langer at sap.com>
> > Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> > "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Ping
> >
> > ... anyone volunteering to review this?
> > It is needed for "8209333: Socket reset issue for TLS 1.3 socket close"
> >
> > Best regards,
> >   Goetz.
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Lindenmaier, Goetz
> > > Sent: Tuesday, March 10, 2020 5:02 PM
> > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > Subject: [CAUTION] 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > >
> > > Hi,
> > >
> > > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> > > close"
> > > for parity with 11.0.8-oracle.
> > >
> > > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > > introduced by [1]. I agree that it would make sense
> > > to bring this fix to jdk11u-dev along with [1].
> > >
> > > [1] applies clean to jdk11u-dev.
> > > Unfortunately, [3] does not apply at all.
> > >
> > > In jdk13 a major rework of JSSE was done:
> > > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > >
> > > [2] removes the synchronized keywords from a lot of functions
> > > in JSSE and replaces them by manual locking. [3] exploits
> > > the new control flow within these reworked functions in
> > > SSLSocketImpl.java. It needs to be designed differently
> > > to apply directly on top of [1].
> > >
> > > Instead, I propose to downport the changes of [2] to the only
> > > file touched by [3], SSLSocketImpl.java.
> > >
> > > I took the patch of [2] for SSLSocketImpl.java and patched
> > > it on top of [1] to jdk11u-dev. It applies clean. On top
> > > of this, [3] applies clean, too.
> > >
> > > The SSLSocketImpl.java part of [2] uses a public lock
> > > introduced in OutputRecord. I revoked this part of the change
> > > as the changes to OutputRecord are not important here, so
> > > it'd like to skip them. Here the partial webrev of the
> > > revoked code:
> > > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> > >
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > > diff.html
> > >
> > > The locks introduced by [2] in SSLSocketImpl.java are private,
> > > so there is no direct dependency to them in other code.
> > >
> > > I ran the three changes through our nightly testing
> > > and saw no issues.
> > >
> > > Please review:
> > > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > > https://bugs.openjdk.java.net/browse/JDK-8209333
> > > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> > >
> > > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > > https://bugs.openjdk.java.net/browse/JDK-8221882
> > > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> > >
> > > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > > https://bugs.openjdk.java.net/browse/JDK-8219991
> > > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From goetz.lindenmaier at sap.com  Sun Mar 15 20:25:22 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sun, 15 Mar 2020 20:25:22 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049813939225AE0F539CF82ECF80@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Martin, 

Thanks for reviewing.

I don't want to downport the whole change because in the other 
files public interfaces are changed. At least such public to other
classes in the module.

I opened a bug of its own for this so it's clearly documented 
that this is only a partial backport.  I'll push it as-is, with [3]
as follow up.  It will not be linked to [2] as backport.

Best regards,
  Goetz



> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Friday, March 13, 2020 4:39 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net>
> Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Hi G?tz,
> 
> I guess you don't want to backport the whole [2] because there are too many
> conflicts?
> 
> Technically, your partial backport of [2] looks good.
> 
> Are you planning to merge it with [3] before pushing?
> I think [2] should not be flagged as backported when you only pick a subset
> of it.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Dienstag, 10. M?rz 2020 17:02
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Hi,
> >
> > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> > close"
> > for parity with 11.0.8-oracle.
> >
> > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > introduced by [1]. I agree that it would make sense
> > to bring this fix to jdk11u-dev along with [1].
> >
> > [1] applies clean to jdk11u-dev.
> > Unfortunately, [3] does not apply at all.
> >
> > In jdk13 a major rework of JSSE was done:
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > [2] removes the synchronized keywords from a lot of functions
> > in JSSE and replaces them by manual locking. [3] exploits
> > the new control flow within these reworked functions in
> > SSLSocketImpl.java. It needs to be designed differently
> > to apply directly on top of [1].
> >
> > Instead, I propose to downport the changes of [2] to the only
> > file touched by [3], SSLSocketImpl.java.
> >
> > I took the patch of [2] for SSLSocketImpl.java and patched
> > it on top of [1] to jdk11u-dev. It applies clean. On top
> > of this, [3] applies clean, too.
> >
> > The SSLSocketImpl.java part of [2] uses a public lock
> > introduced in OutputRecord. I revoked this part of the change
> > as the changes to OutputRecord are not important here, so
> > it'd like to skip them. Here the partial webrev of the
> > revoked code:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > diff.html
> >
> > The locks introduced by [2] in SSLSocketImpl.java are private,
> > so there is no direct dependency to them in other code.
> >
> > I ran the three changes through our nightly testing
> > and saw no issues.
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> >
> > Best regards,
> >   Goetz.
> >
> > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > https://bugs.openjdk.java.net/browse/JDK-8209333
> > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> >
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > https://bugs.openjdk.java.net/browse/JDK-8221882
> > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> >
> > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > https://bugs.openjdk.java.net/browse/JDK-8219991
> > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From goetz.lindenmaier at sap.com  Sun Mar 15 21:15:51 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sun, 15 Mar 2020 21:15:51 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM0PR0202MB32976013154F69C825A673D99AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM0PR0202MB32976013154F69C825A673D99AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB604986640B47380EB8244970ECF80@AM7PR02MB6049.eurprd02.prod.outlook.com>

Thanks!

Having two downports I now push this.
Also, our testing is fine. The changes participated in several
nightly build and test cycles.

Beset regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Friday, March 13, 2020 4:44 PM
> To: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; jdk-updates-dev <jdk-updates-
> dev at openjdk.java.net>
> Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Ah, you backport the part of [2] as a separate issue which is not flagged as
> backport. This is fine with me.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Doerr, Martin
> > Sent: Freitag, 13. M?rz 2020 16:39
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> > <jdk-updates-dev at openjdk.java.net>
> > Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Hi G?tz,
> >
> > I guess you don't want to backport the whole [2] because there are too
> many
> > conflicts?
> >
> > Technically, your partial backport of [2] looks good.
> >
> > Are you planning to merge it with [3] before pushing?
> > I think [2] should not be flagged as backported when you only pick a subset
> > of it.
> >
> > Best regards,
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Lindenmaier, Goetz
> > > Sent: Dienstag, 10. M?rz 2020 17:02
> > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > >
> > > Hi,
> > >
> > > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> > > close"
> > > for parity with 11.0.8-oracle.
> > >
> > > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > > introduced by [1]. I agree that it would make sense
> > > to bring this fix to jdk11u-dev along with [1].
> > >
> > > [1] applies clean to jdk11u-dev.
> > > Unfortunately, [3] does not apply at all.
> > >
> > > In jdk13 a major rework of JSSE was done:
> > > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > >
> > > [2] removes the synchronized keywords from a lot of functions
> > > in JSSE and replaces them by manual locking. [3] exploits
> > > the new control flow within these reworked functions in
> > > SSLSocketImpl.java. It needs to be designed differently
> > > to apply directly on top of [1].
> > >
> > > Instead, I propose to downport the changes of [2] to the only
> > > file touched by [3], SSLSocketImpl.java.
> > >
> > > I took the patch of [2] for SSLSocketImpl.java and patched
> > > it on top of [1] to jdk11u-dev. It applies clean. On top
> > > of this, [3] applies clean, too.
> > >
> > > The SSLSocketImpl.java part of [2] uses a public lock
> > > introduced in OutputRecord. I revoked this part of the change
> > > as the changes to OutputRecord are not important here, so
> > > it'd like to skip them. Here the partial webrev of the
> > > revoked code:
> > > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> > >
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > > diff.html
> > >
> > > The locks introduced by [2] in SSLSocketImpl.java are private,
> > > so there is no direct dependency to them in other code.
> > >
> > > I ran the three changes through our nightly testing
> > > and saw no issues.
> > >
> > > Please review:
> > > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > > https://bugs.openjdk.java.net/browse/JDK-8209333
> > > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> > >
> > > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > > https://bugs.openjdk.java.net/browse/JDK-8221882
> > > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> > >
> > > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > > https://bugs.openjdk.java.net/browse/JDK-8219991
> > > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From goetz.lindenmaier at sap.com  Sun Mar 15 21:49:12 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Sun, 15 Mar 2020 21:49:12 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM7PR02MB604986640B47380EB8244970ECF80@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR0202MB32970B7BFF57F025AA64A0219AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM0PR0202MB32976013154F69C825A673D99AFA0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <AM7PR02MB604986640B47380EB8244970ECF80@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB60494C9DE4213D9855FB368CECF80@AM7PR02MB6049.eurprd02.prod.outlook.com>

... sorry meant 'reviews' not 'downports' ...

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Sunday, March 15, 2020 10:16 PM
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-dev <jdk-updates-
> dev at openjdk.java.net>
> Subject: [CAUTION] RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> Thanks!
> 
> Having two downports I now push this.
> Also, our testing is fine. The changes participated in several
> nightly build and test cycles.
> 
> Beset regards,
>   Goetz.
> 
> > -----Original Message-----
> > From: Doerr, Martin <martin.doerr at sap.com>
> > Sent: Friday, March 13, 2020 4:44 PM
> > To: Doerr, Martin <martin.doerr at sap.com>; Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com>; jdk-updates-dev <jdk-updates-
> > dev at openjdk.java.net>
> > Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> > "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > Ah, you backport the part of [2] as a separate issue which is not flagged as
> > backport. This is fine with me.
> >
> > Best regards,
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> > > Behalf Of Doerr, Martin
> > > Sent: Freitag, 13. M?rz 2020 16:39
> > > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> > > <jdk-updates-dev at openjdk.java.net>
> > > Subject: RE: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > >
> > > Hi G?tz,
> > >
> > > I guess you don't want to backport the whole [2] because there are too
> > many
> > > conflicts?
> > >
> > > Technically, your partial backport of [2] looks good.
> > >
> > > Are you planning to merge it with [3] before pushing?
> > > I think [2] should not be flagged as backported when you only pick a
> subset
> > > of it.
> > >
> > > Best regards,
> > > Martin
> > >
> > >
> > > > -----Original Message-----
> > > > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> > On
> > > > Behalf Of Lindenmaier, Goetz
> > > > Sent: Dienstag, 10. M?rz 2020 17:02
> > > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > > Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java
> > > > from "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > > >
> > > > Hi,
> > > >
> > > > I started downporting [1], "8209333: Socket reset issue for TLS 1.3
> socket
> > > > close"
> > > > for parity with 11.0.8-oracle.
> > > >
> > > > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > > > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > > > introduced by [1]. I agree that it would make sense
> > > > to bring this fix to jdk11u-dev along with [1].
> > > >
> > > > [1] applies clean to jdk11u-dev.
> > > > Unfortunately, [3] does not apply at all.
> > > >
> > > > In jdk13 a major rework of JSSE was done:
> > > > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > > >
> > > > [2] removes the synchronized keywords from a lot of functions
> > > > in JSSE and replaces them by manual locking. [3] exploits
> > > > the new control flow within these reworked functions in
> > > > SSLSocketImpl.java. It needs to be designed differently
> > > > to apply directly on top of [1].
> > > >
> > > > Instead, I propose to downport the changes of [2] to the only
> > > > file touched by [3], SSLSocketImpl.java.
> > > >
> > > > I took the patch of [2] for SSLSocketImpl.java and patched
> > > > it on top of [1] to jdk11u-dev. It applies clean. On top
> > > > of this, [3] applies clean, too.
> > > >
> > > > The SSLSocketImpl.java part of [2] uses a public lock
> > > > introduced in OutputRecord. I revoked this part of the change
> > > > as the changes to OutputRecord are not important here, so
> > > > it'd like to skip them. Here the partial webrev of the
> > > > revoked code:
> > > > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > > > Downport_SSLSocketImpl_from_8221882-jdk11/01-
> > > >
> > >
> >
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> > > > diff.html
> > > >
> > > > The locks introduced by [2] in SSLSocketImpl.java are private,
> > > > so there is no direct dependency to them in other code.
> > > >
> > > > I ran the three changes through our nightly testing
> > > > and saw no issues.
> > > >
> > > > Please review:
> > > > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> > > > Downport_SSLSocketImpl_from_8221882-jdk11/01/
> > > >
> > > > Best regards,
> > > >   Goetz.
> > > >
> > > > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > > > https://bugs.openjdk.java.net/browse/JDK-8209333
> > > > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> > > >
> > > > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > > > https://bugs.openjdk.java.net/browse/JDK-8221882
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> > > >
> > > > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > > > https://bugs.openjdk.java.net/browse/JDK-8219991
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b

From christoph.langer at sap.com  Mon Mar 16 08:46:52 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 16 Mar 2020 08:46:52 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
 <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>
Message-ID: <AM0PR02MB57149F667645024EDC3B656E8AF90@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

> I can't guess why Oracle chose to backport this comment-only change,
> but I believe that 11u is about fixing *significant* bugs, by which I
> mean significant to *users*. Last year Aleksey Shipilev made the point
> (rather forcefully!) that maintainers should still be able to reject
> patches even if Oracle approved them. I suspect that the reason for
> his reasoning was if Oracle decide to jump off a cliff, we shouldn't
> jump with them. That isn't the case here, though: this patch is
> harmless.

Just in case you hadn't been aware of it, we do reject/ignore some things that Oracle did. If you query for the label "openjdk-na" in JBS you'll find quite a bunch of items that don't apply to OpenJDK and won't show up in our stats. At the moment the count of this list is 64.

There are also changes like https://bugs.openjdk.java.net/browse/JDK-8232569 (Use test image from different jib profile for testing), where the change could apply to OpenJDK source code but we chose not to take it since the file that was edited there is only used in Oracle infrastructure.

> As has been pointed out, this is almost a zero-risk patch in that it
> does nothing, but it's also a zero-gain patch in that it does nothing.
> On the other hand it might mess up our statistics because there will
> appear to be a patch Oracle backported but we didn't, and I can see
> that will be misleading. It might even cause people to distrust us
> because we're not fixing some bugs.
> 
> So I'm no longer sure. If you think it makes life easier for you to
> apply patches which only affect source code, and they have equivalent
> Oracle backports, go ahead. But let's not do so otherwise.

OK, so, given that it's

a) harmless though effectless
b) we've always backported these kind of patches so far
and
c) backport work is done & reviewed,

I'll admit that backport.

Thanks and best regards
Christoph



From aph at redhat.com  Mon Mar 16 09:26:22 2020
From: aph at redhat.com (Andrew Haley)
Date: Mon, 16 Mar 2020 09:26:22 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <AM0PR02MB57149F667645024EDC3B656E8AF90@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
 <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>
 <AM0PR02MB57149F667645024EDC3B656E8AF90@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <dd6b967a-fc2f-39b8-7742-e4096152b141@redhat.com>

Hi,

On 3/16/20 8:46 AM, Langer, Christoph wrote:

>> I can't guess why Oracle chose to backport this comment-only change,
>> but I believe that 11u is about fixing *significant* bugs, by which I
>> mean significant to *users*. Last year Aleksey Shipilev made the point
>> (rather forcefully!) that maintainers should still be able to reject
>> patches even if Oracle approved them. I suspect that the reason for
>> his reasoning was if Oracle decide to jump off a cliff, we shouldn't
>> jump with them. That isn't the case here, though: this patch is
>> harmless.
>
> Just in case you hadn't been aware of it, we do reject/ignore some
> things that Oracle did. If you query for the label "openjdk-na" in
> JBS you'll find quite a bunch of items that don't apply to OpenJDK
> and won't show up in our stats. At the moment the count of this list
> is 64.
>
> There are also changes like
> https://bugs.openjdk.java.net/browse/JDK-8232569 (Use test image
> from different jib profile for testing), where the change could
> apply to OpenJDK source code but we chose not to take it since the
> file that was edited there is only used in Oracle infrastructure.

Yes, I get that.

>> As has been pointed out, this is almost a zero-risk patch in that it
>> does nothing, but it's also a zero-gain patch in that it does nothing.
>> On the other hand it might mess up our statistics because there will
>> appear to be a patch Oracle backported but we didn't, and I can see
>> that will be misleading. It might even cause people to distrust us
>> because we're not fixing some bugs.
>>
>> So I'm no longer sure. If you think it makes life easier for you to
>> apply patches which only affect source code, and they have equivalent
>> Oracle backports, go ahead. But let's not do so otherwise.
>
> OK, so, given that it's
>
> a) harmless though effectless
> b) we've always backported these kind of patches so far
> and
> c) backport work is done & reviewed,
>
> I'll admit that backport.

OK, fine. But b) is *not* a reason for anything. We're not bound to
tradition in that way, but obviously it does not help anyone working
on backports not to know what the ground rules are. So we need to try
to be consistent, but it's easy to fall into habits which become rules
by accident.

All of this email still applies, modulo the controversial (and
subsequently reverted) paragraph about "backports which have already
been approved by Oracle..."

  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-August/001578.html

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From yan at azul.com  Mon Mar 16 09:49:16 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Mon, 16 Mar 2020 12:49:16 +0300
Subject: [13u] jdk13u-dev repository
Message-ID: <634c00c8-752c-bb98-7857-d631586a2899@azul.com>

Hi,

now we have 13u split to jdk13u (master) [1] and jdk13u-dev (development) [2]
and plan to bump the update version of dev to 13.0.3.
Please don't push to master.
The rampdown will be rather short (almost non-existent).
A release date is April 14.

Thanks,
--Yuri

[1] http://hg.openjdk.java.net/jdk-updates/jdk13u/
[2] http://hg.openjdk.java.net/jdk-updates/jdk13u-dev/
[3] https://www.oracle.com/security-alerts/


From yan at azul.com  Mon Mar 16 10:25:46 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Mon, 16 Mar 2020 13:25:46 +0300
Subject: [13u] RFR: 8241051: Bump update version for OpenJDK: jdk-13.0.3
Message-ID: <c4950ca4-273e-771a-bc7b-96d1ff60b1a7@azul.com>

Hi,

to start a rather short development period of jdk-13.0.3, we need to bump the version in jdk13u-dev
Please review:
http://cr.openjdk.java.net/~yan/8241051/webrev.0/

JBS is already aware of 13.0.3, and a tag 13.0.3+0 will be set.

Date is April 14, as in https://www.oracle.com/security-alerts/

Thanks,
--yan


From shade at redhat.com  Mon Mar 16 10:27:14 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 16 Mar 2020 11:27:14 +0100
Subject: [13u] RFR: 8241051: Bump update version for OpenJDK: jdk-13.0.3
In-Reply-To: <c4950ca4-273e-771a-bc7b-96d1ff60b1a7@azul.com>
References: <c4950ca4-273e-771a-bc7b-96d1ff60b1a7@azul.com>
Message-ID: <9a550383-0b2b-505b-f8ec-c8f247532bf5@redhat.com>

On 3/16/20 11:25 AM, Yuri Nesterenko wrote:
> to start a rather short development period of jdk-13.0.3, we need to bump the version in jdk13u-dev
> Please review:
> http://cr.openjdk.java.net/~yan/8241051/webrev.0/

Looks good.

-- 
Thanks,
-Aleksey


From alexey at azul.com  Mon Mar 16 10:52:06 2020
From: alexey at azul.com (Alexey Bakhtin)
Date: Mon, 16 Mar 2020 10:52:06 +0000
Subject: [11u] RFR: 8239787: AArch64: String.indexOf may incorrectly handle
 empty strings.
Message-ID: <6B062A65-7796-494F-82A3-CDDF57816223@azul.com>

Original bug:
https://bugs.openjdk.java.net/browse/JDK-8239787
https://hg.openjdk.java.net/jdk/jdk/rev/a3a462ce27cd

Please, review this patch backporting JDK-8239787 to JDK 11u. The patch applies rather cleanly with only conflict in macroAssembler_aarch64.cpp caused by strict type cast added by JDK-8206895 in JDK13

11u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk11/8239787/webrev.v0/

Thank you
Alexey


From adinn at redhat.com  Mon Mar 16 10:58:07 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 16 Mar 2020 10:58:07 +0000
Subject: [11u] RFR: 8239787: AArch64: String.indexOf may incorrectly
 handle empty strings.
In-Reply-To: <6B062A65-7796-494F-82A3-CDDF57816223@azul.com>
References: <6B062A65-7796-494F-82A3-CDDF57816223@azul.com>
Message-ID: <3de89960-dc69-d04d-9ac5-28f602a6d4a9@redhat.com>

On 16/03/2020 10:52, Alexey Bakhtin wrote:
> Original bug:
> https://bugs.openjdk.java.net/browse/JDK-8239787
> https://hg.openjdk.java.net/jdk/jdk/rev/a3a462ce27cd
> 
> Please, review this patch backporting JDK-8239787 to JDK 11u. The patch applies rather cleanly with only conflict in macroAssembler_aarch64.cpp caused by strict type cast added by JDK-8206895 in JDK13
> 
> 11u webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk11/8239787/webrev.v0/
Looks 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 yan at azul.com  Mon Mar 16 11:06:12 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Mon, 16 Mar 2020 14:06:12 +0300
Subject: [13u] RFR: 8241051: Bump update version for OpenJDK: jdk-13.0.3
In-Reply-To: <9a550383-0b2b-505b-f8ec-c8f247532bf5@redhat.com>
References: <c4950ca4-273e-771a-bc7b-96d1ff60b1a7@azul.com>
 <9a550383-0b2b-505b-f8ec-c8f247532bf5@redhat.com>
Message-ID: <85f7c8a1-9b93-fc33-a74d-1a8a8b374e11@azul.com>

Thank you, Aleksey!
--yan

On 16.03.2020 13:27, Aleksey Shipilev wrote:
> On 3/16/20 11:25 AM, Yuri Nesterenko wrote:
>> to start a rather short development period of jdk-13.0.3, we need to bump the version in jdk13u-dev
>> Please review:
>> http://cr.openjdk.java.net/~yan/8241051/webrev.0/
> 
> Looks good.
> 


From gnu.andrew at redhat.com  Mon Mar 16 20:24:34 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 16 Mar 2020 20:24:34 +0000
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
 <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>
Message-ID: <7c355d05-2fce-9b2b-f996-cb88ca696941@redhat.com>



On 13/03/2020 15:27, Andrew Haley wrote:

snip...

> 
> I can't guess why Oracle chose to backport this comment-only change,
> but I believe that 11u is about fixing *significant* bugs, by which I
> mean significant to *users*. Last year Aleksey Shipilev made the point
> (rather forcefully!) that maintainers should still be able to reject
> patches even if Oracle approved them. I suspect that the reason for
> his reasoning was if Oracle decide to jump off a cliff, we shouldn't
> jump with them. That isn't the case here, though: this patch is
> harmless.
> 

I believe I also made the same point, though maybe less forcefully ;)

As a maintainer for 8u, I reserve the right to reject patches,
regardless of whether Oracle backported them or not, and equally I don't
regard "Oracle did it" as sufficient reason alone for a backport. This
is why I have been, and remain, against the idea of auto-approving such
patches, as has been suggested in the past.

Much as some at Oracle may believe it to be the other way around,
OpenJDK is the reference implementation and Oracle's tree is a fork of
this. We should not be slavishly following a private fork, which, by its
very nature, it is impossible to ever match exactly.
-- 
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 goetz.lindenmaier at sap.com  Tue Mar 17 06:57:12 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 17 Mar 2020 06:57:12 +0000
Subject: RFR: [jdk11] 8239462: jdk.hotspot.agent misses some
 ReleaseStringUTFChars calls in case of early returns
In-Reply-To: <AM0PR02MB4227D9D2ED30CF67EFCDB76293FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227D9D2ED30CF67EFCDB76293FA0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB6049A32EB6F7DDD5DA8CF526ECF60@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Matthias, 

Obviously, 11 and head are diverging, requiring more and
more adaptions of downports. 

The downport looks good, just like good old C ??

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Friday, March 13, 2020 3:32 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RFR: [jdk11] 8239462: jdk.hotspot.agent misses some
> ReleaseStringUTFChars calls in case of early returns
> 
> Hello, please review the backport of 8239462: jdk.hotspot.agent misses some
> ReleaseStringUTFChars calls in case of early returns  to jdk11.
> 
> I needed to change the jdk/jdk change a bit because in jdk11
> LinuxDebuggerLocal.c  is C code and slightly different from
> LinuxDebuggerLocal.cpp (C++)  in jdk/jdk   .
> 
> 
> 
> Bug/jdk11  webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8239462
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8239462_0_jdk11/
> 
> jdk/jdk webrev :
> https://hg.openjdk.java.net/jdk/jdk/rev/61ee15b9a1ac
> 
> Thanks, Matthias

From shade at redhat.com  Tue Mar 17 12:16:06 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 17 Mar 2020 13:16:06 +0100
Subject: [11u] RFR: 8233197: Invert JvmtiExport::post_vm_initialized() and
 Jfr:on_vm_start() start-up order for correct option parsing
In-Reply-To: <CAPb8aJ7cvK_o3tnpdYY_biN63dAHuC4h1pxWBy25mhw9r3U9NA@mail.gmail.com>
References: <CAPb8aJ7cvK_o3tnpdYY_biN63dAHuC4h1pxWBy25mhw9r3U9NA@mail.gmail.com>
Message-ID: <0f928ea7-e452-42f6-6429-b80d119106ef@redhat.com>

On 3/2/20 5:19 PM, Jaroslav Bachor?k wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233197
> Webrev: http://cr.openjdk.java.net/~jbachorik/8233197/webrev/

11u backport looks good to me.

-- 
Thanks,
-Aleksey


From snazy at snazy.de  Tue Mar 17 13:22:01 2020
From: snazy at snazy.de (Robert Stupp)
Date: Tue, 17 Mar 2020 14:22:01 +0100
Subject: Help requested, backport 8240629 to 11u + 14u
Message-ID: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>

Hi,

backporting JDK-8240629 ("argfiles parsing broken for argfiles with comment cross 4096 bytes chunk") to 11u + 14u is trivial. The original patch from jdk/jdk (Java 15) patch file applies cleanly to current jdk-updates/jdk11u + jdk-updates/jdk14u (no changes to the patch) and tests pass locally.

https://cr.openjdk.java.net/~shade/8240629/webrev.11u.01/ <https://cr.openjdk.java.net/~shade/8240629/webrev.11u.01/> (Thanks to Aleksey Shipilev for creating it!)

I could need some help (no JBS acount) to get the patch backported to 11u + 14u.

Cheers,
Robert

References:
https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2 <https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2>
https://bugs.openjdk.java.net/browse/JDK-8240629 <https://bugs.openjdk.java.net/browse/JDK-8240629>

patch file exported using 'hg export -r 58311:79371dab85c2 --git > 8240629.patch' + imported into my 11u+14u clones via qimport/qpush.



11u tests:


make run-test TEST=tier1

==============================
Test summary
==============================
  TEST                                              TOTAL  PASS  FAIL  ERROR   
  jtreg:test/hotspot/jtreg:tier1                     1297  1297     0   0   
  jtreg:test/jdk:tier1                               1860  1860     0    0   
  jtreg:test/langtools:tier1                         3902  3902     0    0   
  jtreg:test/nashorn:tier1                              0     0     0    0   
  jtreg:test/jaxp:tier1                                 0     0     0    0   
==============================
TEST SUCCESS

make run-test TEST=test/jdk/tools/launcher

==============================
Test summary
==============================
  TEST                                              TOTAL  PASS  FAIL  ERROR   
  jtreg:test/jdk/tools/launcher                        56    56     0    0   
==============================
TEST SUCCESS




14u tests:

make run-test TEST=tier1

==============================
Test summary
==============================
  TEST                                              TOTAL  PASS  FAIL  ERROR   
  jtreg:test/hotspot/jtreg:tier1                     1471  1471     0   0   
  jtreg:test/jdk:tier1                               1899  1899     0    0   
  jtreg:test/langtools:tier1                         4020  4020     0    0   
  jtreg:test/nashorn:tier1                              0     0     0    0   
  jtreg:test/jaxp:tier1                                 0     0     0    0   
==============================
TEST SUCCESS

make run-test TEST=test/jdk/tools/launcher

==============================
Test summary
==============================
  TEST                                              TOTAL  PASS  FAIL ERROR   
  jtreg:test/jdk/tools/launcher                        57    57     0     0   
==============================
TEST SUCCESS


From matthias.baesken at sap.com  Tue Mar 17 15:11:18 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 17 Mar 2020 15:11:18 +0000
Subject: RFR: [jdk11] 8225789: Empty method parameter type should generate
 ClassFormatError
Message-ID: <AM0PR02MB4227565F45784E6EA374BABB93F60@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello,
   please review the jdk11 backport of  8225789 .
Do bring the patch into jdk11  I had to confirm the length check  in ClassFileParser::verify_unqualified_name because
Of changes in the stride (the check itself integrates nicely).
Additionally the class file version in /test/hotspot/jtreg/runtime/classFileParserBug/EmptyUnqName.jasm
was adjusted to 55.

Bug/ jdk11 webrev :

https://bugs.openjdk.java.net/browse/JDK-8225789

http://cr.openjdk.java.net/~mbaesken/webrevs/8225789_jdk11/

( jdk/jdk change is : https://hg.openjdk.java.net/jdk/jdk/rev/360f8769d3dc  )

Thanks, Matthias

From aph at redhat.com  Tue Mar 17 16:49:52 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 17 Mar 2020 16:49:52 +0000
Subject: RFD: What do we do about programs which set sys_paths to null?
Message-ID: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>

[ People who know all this stuff already, please feel free to skip
this introduction. ]

This is a request for discussion about support for some programs that
do something illegal, not at all supported. I'd like to make this work
as intended by users, even though it's unsupported. Which seems odd,
but I still think we should do it.

There is a long-established hack (going back about 20 years) which
allows Java programs to set the property "java.library.path"
dynamically. You might need to do this if you're a Java program which
extracts a shared library from a jarfile, puts it in a tmpdir
somewhere, then loads that library.

People discovered that even though you can set "java.library.path" in
a program, it doesn't work as intended because the property is only
read once at boot time, and it is then cached in the static field
ClassLoader.usr_paths. So, people discovered that if they set
"java.library.path" then set set ClassLoader.sys_paths to null, then
called ClassLoader.loadLibrary, it works. Something like this:

   Class loaderClass = ClassLoader.class;
   Field userPaths = loaderClass.getDeclaredField( "sys_paths" );
   userPaths.setAccessible( true );
   userPaths.set( null, null );

See the answer here, for example:
https://community.oracle.com/thread/1551225?start=15&tstart=0

This worked because ClassLoader.loadLibrary() did this:

        if (sys_paths == null) {
            usr_paths = initializePath("java.library.path");
            sys_paths = initializePath("sun.boot.library.path");
        }

The paths got re-initialized.

The back-ported fix for "8231584: Deadlock with
ClassLoader.findLibrary and System.loadLibrary call", broke this
hack. The code that lazily re-initializes usr_paths and sys_paths has
gone. However, there was another important change:
ClassLoader.loadLibrary0(), which calls ClassLoader.loadLibrary, is no
longer synchronized, so there may now be concurrent accesses to
ClassLoader.loadLibrary().

[ The proposed fix. ]

I'd like to add this patch to 8u and 11u:

--- a/src/java.base/share/classes/java/lang/ClassLoader.java    Mon Feb 03 09:39:39 2020 +0100
+++ b/src/java.base/share/classes/java/lang/ClassLoader.java    Tue Mar 17 16:24:10 2020 +0000
@@ -2562,7 +2562,7 @@

     // The paths searched for libraries
     private static String usr_paths[];
-    private static String sys_paths[];
+    private static volatile String sys_paths[];

     private static String[] initializePath(String propName) {
         String ldPath = System.getProperty(propName, "");
@@ -2620,6 +2620,10 @@
                             boolean isAbsolute) {
         ClassLoader loader =
             (fromClass == null) ? null : fromClass.getClassLoader();
+        if (sys_paths == null) {
+            usr_paths = initializePath("java.library.path");
+            sys_paths = initializePath("sun.boot.library.path");
+        }
         assert sys_paths != null : "should be initialized at this point";
         assert usr_paths != null : "should be initialized at this point";

This patch does nothing unless sys_paths has been set to null. There
is some slight slowdown because a non-volatile read of sys_paths is
now volatile, but it's IMO insignificant and in any case it's less
than the overhead of the synchronized loadLibrary0().

I do not believe that this introduces a race when the user sets
sys_paths to null because

   setProperty("java.library.path") happens before (write volatile sys_paths)  (Program order)
   (write volatile sys_paths) synchronizes with (read volatile sys_paths)
   (read volatile sys_paths) happens before getProperty("java.lbrary.path") (Program order)

If the user sets sys_paths to null before setting "java.library.path"
there is indeed a race and their program might not work, but there
always was a race anyway.

I think we should do this for 8u and 11u. My justification is that even
though this is an ugly hack, it satisfies a real need and we don't want
to break users' programs in an update.

What do you think?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From mbalao at redhat.com  Tue Mar 17 16:54:16 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 17 Mar 2020 13:54:16 -0300
Subject: CFV: New OpenJDK Updates Committer: Simon Tooke
In-Reply-To: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
References: <14514ff6-2d07-72f5-866d-ab767af913f5@redhat.com>
Message-ID: <7be0c635-2dca-33a6-aab5-fd75f3cf42b2@redhat.com>

On 3/6/20 5:24 AM, Andrew Hughes wrote:
> I hereby nominate Simon Tooke (stooke) [0] to OpenJDK Updates Committer.

Vote: Yes


From mbalao at redhat.com  Tue Mar 17 17:06:28 2020
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 17 Mar 2020 14:06:28 -0300
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <e8bb57a9-76b3-0895-89e7-d5440b1f2fb6@redhat.com>

Hi Goetz,

Thanks for doing this work.

I'm a bit late here but will share my comments anyways (note: I'm not an
official reviewer).

Backported patches look good to me. My only question in that regard is
why do we need a call to "readLockedDeplete" from the "read" method here
[1]. Looks to me at first sight that "readLockedDeplete" will be called
anyways by "deplete" [2]; and if "deplete" were not called, then
"isClosing" will be false and the call in [1] won't be performed
anyways. Perhaps there is something obvious I'm not seeing. CC'ing
Xuelei for this just in case.

In regards to the backport patch, I'm not sure about decision taken on
OutputRecord's lock. My concern is that when we backport 8221882 we
forget about this and we end-up synchronizing against something
different in  SSLSocketImpl.java. Is it too much trouble to propagate
the changes to OutputRecord? I had a first look but you probably have
analyzed that better.

Thanks,
Martin.-

--
[1] - http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b#l1.75
[2] - http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b#l1.87


On 3/10/20 1:01 PM, Lindenmaier, Goetz wrote:
> Hi,
> 
> I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket close"
> for parity with 11.0.8-oracle.
> 
> Severin pointed me to [3], "8219991: New fix of the deadlock in
> sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> introduced by [1]. I agree that it would make sense
> to bring this fix to jdk11u-dev along with [1].
> 
> [1] applies clean to jdk11u-dev.
> Unfortunately, [3] does not apply at all.
> 
> In jdk13 a major rework of JSSE was done:
> [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> [2] removes the synchronized keywords from a lot of functions
> in JSSE and replaces them by manual locking. [3] exploits
> the new control flow within these reworked functions in
> SSLSocketImpl.java. It needs to be designed differently
> to apply directly on top of [1].
> 
> Instead, I propose to downport the changes of [2] to the only
> file touched by [3], SSLSocketImpl.java.
> 
> I took the patch of [2] for SSLSocketImpl.java and patched
> it on top of [1] to jdk11u-dev. It applies clean. On top
> of this, [3] applies clean, too.
> 
> The SSLSocketImpl.java part of [2] uses a public lock
> introduced in OutputRecord. I revoked this part of the change
> as the changes to OutputRecord are not important here, so
> it'd like to skip them. Here the partial webrev of the
> revoked code:
> http://cr.openjdk.java.net/~goetz/wr20/8240827-Downport_SSLSocketImpl_from_8221882-jdk11/01-revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.udiff.html
> 
> The locks introduced by [2] in SSLSocketImpl.java are private,
> so there is no direct dependency to them in other code.
> 
> I ran the three changes through our nightly testing
> and saw no issues.
> 
> Please review:
> http://cr.openjdk.java.net/~goetz/wr20/8240827-Downport_SSLSocketImpl_from_8221882-jdk11/01/
> 
> Best regards,
>   Goetz.
> 
> [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> https://bugs.openjdk.java.net/browse/JDK-8209333
> http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> 
> [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> https://bugs.openjdk.java.net/browse/JDK-8221882
> http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> 
> [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> https://bugs.openjdk.java.net/browse/JDK-8219991
> http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b
> 


From Junyuan.Zheng at microsoft.com  Tue Mar 17 18:22:14 2020
From: Junyuan.Zheng at microsoft.com (Junyuan Zheng)
Date: Tue, 17 Mar 2020 18:22:14 +0000
Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5 or
 older
Message-ID: <MWHPR21MB083096C1F557DF9983FF34AFE3F60@MWHPR21MB0830.namprd21.prod.outlook.com>

Hi,

I would like to backport JDK-8240972
("macOS codesign fail on macOS 10.13.5 or older") to 11u.

The original patch cannot be applied to 11u directly because of the change JDK-8239708 (https://bugs.openjdk.java.net/browse/JDK-8239708).

And here is the diff based on the current code:

```
--- a/make/autoconf/basics.m4
+++ b/make/autoconf/basics.m4
@@ -1228,12 +1228,25 @@ AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
       AC_MSG_CHECKING([if codesign certificate is present])
       $RM codesign-testfile
       $TOUCH codesign-testfile
-      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
+      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile 2>&AS_MESSAGE_LOG_FD \
+          >&AS_MESSAGE_LOG_FD || CODESIGN=
       $RM codesign-testfile
       if test "x$CODESIGN" = x; then
         AC_MSG_RESULT([no])
       else
         AC_MSG_RESULT([yes])
+        # Verify that the codesign has --option runtime
+        AC_MSG_CHECKING([if codesign has --option runtime])
+        $RM codesign-testfile
+        $TOUCH codesign-testfile
+        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile \
+            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
+        $RM codesign-testfile
+        if test "x$CODESIGN" = x; then
+          AC_MSG_ERROR([codesign does not have --option runtime. macOS 10.13.6 and above is required.])
+        else
+          AC_MSG_RESULT([yes])
+        fi
       fi
     fi
     BASIC_REQUIRE_PROGS(SETFILE, SetFile)
```

I also need a sponsor for this patch. Please let me know what you think.

Thanks,

Junyuan

From takiguc at linux.vnet.ibm.com  Wed Mar 18 01:32:04 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 18 Mar 2020 10:32:04 +0900
Subject: [11u] RDR: backport JDK-8235834, JDK-8239976, JDK-8239976
Message-ID: <5de955b69f9fbc768de1a9252a3a640a@linux.vnet.ibm.com>

Hello.

I got jdk11u-fix-yes for following bug ids.

JDK-8235834 IBM-943 charset encoder needs updating [1]
JDK-8239976 Put JDK-8239965 on the ProblemList.txt [2]
JDK-8239965 XMLEncoder/Test4625418.java fails due to "Error: Cp943 - 
can't read properly" [3]

Please apply changesets in the following order.

Changesets are:
JDK-8235834 9b33b25a7198 [4]
JDK-8239976 16973c5b27be [5]
JDK-8239976 e44b68e5bdaf [6]

I'd like to obtain a sponsor for them.

[1] https://bugs.openjdk.java.net/browse/JDK-8235834
[2] https://bugs.openjdk.java.net/browse/JDK-8239976
[3] https://bugs.openjdk.java.net/browse/JDK-8239965
[4] https://hg.openjdk.java.net/jdk/jdk/rev/9b33b25a7198
[5] https://hg.openjdk.java.net/jdk/jdk/rev/16973c5b27be
[6] https://hg.openjdk.java.net/jdk/jdk/rev/e44b68e5bdaf

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From david.holmes at oracle.com  Wed Mar 18 02:48:11 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Mar 2020 12:48:11 +1000
Subject: RFD: What do we do about programs which set sys_paths to null?
In-Reply-To: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
References: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
Message-ID: <8546141c-92d4-c3a0-72c7-0244e1d5b64e@oracle.com>

Hi Andrew,

This was already addressed in 8u:

https://bugs.openjdk.java.net/browse/JDK-8240521

Cheers,
David
-----

On 18/03/2020 2:49 am, Andrew Haley wrote:
> [ People who know all this stuff already, please feel free to skip
> this introduction. ]
> 
> This is a request for discussion about support for some programs that
> do something illegal, not at all supported. I'd like to make this work
> as intended by users, even though it's unsupported. Which seems odd,
> but I still think we should do it.
> 
> There is a long-established hack (going back about 20 years) which
> allows Java programs to set the property "java.library.path"
> dynamically. You might need to do this if you're a Java program which
> extracts a shared library from a jarfile, puts it in a tmpdir
> somewhere, then loads that library.
> 
> People discovered that even though you can set "java.library.path" in
> a program, it doesn't work as intended because the property is only
> read once at boot time, and it is then cached in the static field
> ClassLoader.usr_paths. So, people discovered that if they set
> "java.library.path" then set set ClassLoader.sys_paths to null, then
> called ClassLoader.loadLibrary, it works. Something like this:
> 
>     Class loaderClass = ClassLoader.class;
>     Field userPaths = loaderClass.getDeclaredField( "sys_paths" );
>     userPaths.setAccessible( true );
>     userPaths.set( null, null );
> 
> See the answer here, for example:
> https://community.oracle.com/thread/1551225?start=15&tstart=0
> 
> This worked because ClassLoader.loadLibrary() did this:
> 
>          if (sys_paths == null) {
>              usr_paths = initializePath("java.library.path");
>              sys_paths = initializePath("sun.boot.library.path");
>          }
> 
> The paths got re-initialized.
> 
> The back-ported fix for "8231584: Deadlock with
> ClassLoader.findLibrary and System.loadLibrary call", broke this
> hack. The code that lazily re-initializes usr_paths and sys_paths has
> gone. However, there was another important change:
> ClassLoader.loadLibrary0(), which calls ClassLoader.loadLibrary, is no
> longer synchronized, so there may now be concurrent accesses to
> ClassLoader.loadLibrary().
> 
> [ The proposed fix. ]
> 
> I'd like to add this patch to 8u and 11u:
> 
> --- a/src/java.base/share/classes/java/lang/ClassLoader.java    Mon Feb 03 09:39:39 2020 +0100
> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java    Tue Mar 17 16:24:10 2020 +0000
> @@ -2562,7 +2562,7 @@
> 
>       // The paths searched for libraries
>       private static String usr_paths[];
> -    private static String sys_paths[];
> +    private static volatile String sys_paths[];
> 
>       private static String[] initializePath(String propName) {
>           String ldPath = System.getProperty(propName, "");
> @@ -2620,6 +2620,10 @@
>                               boolean isAbsolute) {
>           ClassLoader loader =
>               (fromClass == null) ? null : fromClass.getClassLoader();
> +        if (sys_paths == null) {
> +            usr_paths = initializePath("java.library.path");
> +            sys_paths = initializePath("sun.boot.library.path");
> +        }
>           assert sys_paths != null : "should be initialized at this point";
>           assert usr_paths != null : "should be initialized at this point";
> 
> This patch does nothing unless sys_paths has been set to null. There
> is some slight slowdown because a non-volatile read of sys_paths is
> now volatile, but it's IMO insignificant and in any case it's less
> than the overhead of the synchronized loadLibrary0().
> 
> I do not believe that this introduces a race when the user sets
> sys_paths to null because
> 
>     setProperty("java.library.path") happens before (write volatile sys_paths)  (Program order)
>     (write volatile sys_paths) synchronizes with (read volatile sys_paths)
>     (read volatile sys_paths) happens before getProperty("java.lbrary.path") (Program order)
> 
> If the user sets sys_paths to null before setting "java.library.path"
> there is indeed a race and their program might not work, but there
> always was a race anyway.
> 
> I think we should do this for 8u and 11u. My justification is that even
> though this is an ugly hack, it satisfies a real need and we don't want
> to break users' programs in an update.
> 
> What do you think?
> 

From gnu.andrew at redhat.com  Wed Mar 18 05:00:56 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 18 Mar 2020 05:00:56 +0000
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
Message-ID: <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>



On 17/03/2020 13:22, Robert Stupp wrote:
> Hi,
> 
> backporting JDK-8240629 ("argfiles parsing broken for argfiles with comment cross 4096 bytes chunk") to 11u + 14u is trivial. The original patch from jdk/jdk (Java 15) patch file applies cleanly to current jdk-updates/jdk11u + jdk-updates/jdk14u (no changes to the patch) and tests pass locally.
> 
> https://cr.openjdk.java.net/~shade/8240629/webrev.11u.01/ <https://cr.openjdk.java.net/~shade/8240629/webrev.11u.01/> (Thanks to Aleksey Shipilev for creating it!)
> 
> I could need some help (no JBS acount) to get the patch backported to 11u + 14u.
> 
> Cheers,
> Robert
> 
> References:
> https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2 <https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2>
> https://bugs.openjdk.java.net/browse/JDK-8240629 <https://bugs.openjdk.java.net/browse/JDK-8240629>
> 
> patch file exported using 'hg export -r 58311:79371dab85c2 --git > 8240629.patch' + imported into my 11u+14u clones via qimport/qpush.
> 
> 
> 
> 11u tests:
> 
> 
> make run-test TEST=tier1
> 
> ==============================
> Test summary
> ==============================
>   TEST                                              TOTAL  PASS  FAIL  ERROR   
>   jtreg:test/hotspot/jtreg:tier1                     1297  1297     0   0   
>   jtreg:test/jdk:tier1                               1860  1860     0    0   
>   jtreg:test/langtools:tier1                         3902  3902     0    0   
>   jtreg:test/nashorn:tier1                              0     0     0    0   
>   jtreg:test/jaxp:tier1                                 0     0     0    0   
> ==============================
> TEST SUCCESS
> 
> make run-test TEST=test/jdk/tools/launcher
> 
> ==============================
> Test summary
> ==============================
>   TEST                                              TOTAL  PASS  FAIL  ERROR   
>   jtreg:test/jdk/tools/launcher                        56    56     0    0   
> ==============================
> TEST SUCCESS
> 
> 
> 
> 
> 14u tests:
> 
> make run-test TEST=tier1
> 
> ==============================
> Test summary
> ==============================
>   TEST                                              TOTAL  PASS  FAIL  ERROR   
>   jtreg:test/hotspot/jtreg:tier1                     1471  1471     0   0   
>   jtreg:test/jdk:tier1                               1899  1899     0    0   
>   jtreg:test/langtools:tier1                         4020  4020     0    0   
>   jtreg:test/nashorn:tier1                              0     0     0    0   
>   jtreg:test/jaxp:tier1                                 0     0     0    0   
> ==============================
> TEST SUCCESS
> 
> make run-test TEST=test/jdk/tools/launcher
> 
> ==============================
> Test summary
> ==============================
>   TEST                                              TOTAL  PASS  FAIL ERROR   
>   jtreg:test/jdk/tools/launcher                        57    57     0     0   
> ==============================
> TEST SUCCESS
> 

Hi Robert,

If the fix backports cleanly, you don't actually need a webrev; just
flagging the bug with the jdk[11,14]u-fix-request labels is sufficient.
I've done this for you now:

https://bugs.openjdk.java.net/browse/JDK-8240629

Incidentally, did you write this fix or just report the issue? I don't
see a Contributed-by field on the changeset to credit you, if it's the
former.

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 snazy at gmx.de  Wed Mar 18 07:51:19 2020
From: snazy at gmx.de (Robert Stupp)
Date: Wed, 18 Mar 2020 08:51:19 +0100
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
 <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
Message-ID: <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>

On Wed, 2020-03-18 at 05:00 +0000, Andrew Hughes wrote:
>
> Hi Robert,
>
> If the fix backports cleanly, you don't actually need a webrev; just
> flagging the bug with the jdk[11,14]u-fix-request labels is
> sufficient.
> I've done this for you now:
>
> https://bugs.openjdk.java.net/browse/JDK-8240629
>
> Incidentally, did you write this fix or just report the issue? I
> don't
> see a Contributed-by field on the changeset to credit you, if it's
> the
> former.
>
> Thanks,

Thank you Andrew!

I wrote an earlier version of the patch (without a unit test though).
But yea, no contributed-by (like before *sigh* for JDK-8202216).

Robert



From christoph.langer at sap.com  Wed Mar 18 08:15:55 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Mar 2020 08:15:55 +0000
Subject: [11u] RDR: backport JDK-8235834, JDK-8239976, JDK-8239976
In-Reply-To: <5de955b69f9fbc768de1a9252a3a640a@linux.vnet.ibm.com>
References: <5de955b69f9fbc768de1a9252a3a640a@linux.vnet.ibm.com>
Message-ID: <AM0PR02MB5714FE21D55C68DB3562B5188AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Ichiroh,

I'll sponsor these for you.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Ichiroh Takiguchi
> Sent: Mittwoch, 18. M?rz 2020 02:32
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RDR: backport JDK-8235834, JDK-8239976, JDK-8239976
>
> Hello.
>
> I got jdk11u-fix-yes for following bug ids.
>
> JDK-8235834 IBM-943 charset encoder needs updating [1]
> JDK-8239976 Put JDK-8239965 on the ProblemList.txt [2]
> JDK-8239965 XMLEncoder/Test4625418.java fails due to "Error: Cp943 -
> can't read properly" [3]
>
> Please apply changesets in the following order.
>
> Changesets are:
> JDK-8235834 9b33b25a7198 [4]
> JDK-8239976 16973c5b27be [5]
> JDK-8239976 e44b68e5bdaf [6]
>
> I'd like to obtain a sponsor for them.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8235834
> [2] https://bugs.openjdk.java.net/browse/JDK-8239976
> [3] https://bugs.openjdk.java.net/browse/JDK-8239965
> [4] https://hg.openjdk.java.net/jdk/jdk/rev/9b33b25a7198
> [5] https://hg.openjdk.java.net/jdk/jdk/rev/16973c5b27be
> [6] https://hg.openjdk.java.net/jdk/jdk/rev/e44b68e5bdaf
>
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From aph at redhat.com  Wed Mar 18 09:37:02 2020
From: aph at redhat.com (Andrew Haley)
Date: Wed, 18 Mar 2020 09:37:02 +0000
Subject: RFD: What do we do about programs which set sys_paths to null?
In-Reply-To: <8546141c-92d4-c3a0-72c7-0244e1d5b64e@oracle.com>
References: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
 <8546141c-92d4-c3a0-72c7-0244e1d5b64e@oracle.com>
Message-ID: <0068694e-b2e1-a672-b88e-329e83a5fc1c@redhat.com>

On 3/18/20 2:48 AM, David Holmes wrote:

> This was already addressed in 8u:
> 
> https://bugs.openjdk.java.net/browse/JDK-8240521

Sorry, I should have mentioned that.

That's not really a fix, because backing out the patch causes the deadlock
to return. What I'm proposing is a real fix for 11 and 8.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From goetz.lindenmaier at sap.com  Wed Mar 18 11:15:09 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 18 Mar 2020 11:15:09 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <e8bb57a9-76b3-0895-89e7-d5440b1f2fb6@redhat.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <e8bb57a9-76b3-0895-89e7-d5440b1f2fb6@redhat.com>
Message-ID: <AM7PR02MB6049F54BA80FD9FC0742AB59ECF70@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Martin,

Thanks for looking at this. 

> Backported patches look good to me. My only question in that regard is
> why do we need a call to "readLockedDeplete" from the "read" method here
> [1]. Looks to me at first sight that "readLockedDeplete" will be called
> anyways by "deplete" [2]; and if "deplete" were not called, then
> "isClosing" will be false and the call in [1] won't be performed
> anyways. Perhaps there is something obvious I'm not seeing. CC'ing
> Xuelei for this just in case.
Yes, I think this is a question for the original change. 

> In regards to the backport patch, I'm not sure about decision taken on
> OutputRecord's lock. My concern is that when we backport 8221882 we
> forget about this and we end-up synchronizing against something
> different in  SSLSocketImpl.java. Is it too much trouble to propagate
> the changes to OutputRecord? I had a first look but you probably have
> analyzed that better.
I tried to document well that I did some edits to the change for 
This file. This bug is linked to the orginal [2]. So if someone downports
[2] he should be able to find out about this.
Taking the whole change to 11 seems too risky to me.

Best regards,
  Goetz.


> 
> Thanks,
> Martin.-
> 
> --
> [1] - http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b#l1.75
> [2] - http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b#l1.87
> 
> 
> On 3/10/20 1:01 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I started downporting [1], "8209333: Socket reset issue for TLS 1.3 socket
> close"
> > for parity with 11.0.8-oracle.
> >
> > Severin pointed me to [3], "8219991: New fix of the deadlock in
> > sun.security.ssl.SSLSocketImpl", a follow-up that fixes an issue
> > introduced by [1]. I agree that it would make sense
> > to bring this fix to jdk11u-dev along with [1].
> >
> > [1] applies clean to jdk11u-dev.
> > Unfortunately, [3] does not apply at all.
> >
> > In jdk13 a major rework of JSSE was done:
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> >
> > [2] removes the synchronized keywords from a lot of functions
> > in JSSE and replaces them by manual locking. [3] exploits
> > the new control flow within these reworked functions in
> > SSLSocketImpl.java. It needs to be designed differently
> > to apply directly on top of [1].
> >
> > Instead, I propose to downport the changes of [2] to the only
> > file touched by [3], SSLSocketImpl.java.
> >
> > I took the patch of [2] for SSLSocketImpl.java and patched
> > it on top of [1] to jdk11u-dev. It applies clean. On top
> > of this, [3] applies clean, too.
> >
> > The SSLSocketImpl.java part of [2] uses a public lock
> > introduced in OutputRecord. I revoked this part of the change
> > as the changes to OutputRecord are not important here, so
> > it'd like to skip them. Here the partial webrev of the
> > revoked code:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> Downport_SSLSocketImpl_from_8221882-jdk11/01-
> revoked/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java.u
> diff.html
> >
> > The locks introduced by [2] in SSLSocketImpl.java are private,
> > so there is no direct dependency to them in other code.
> >
> > I ran the three changes through our nightly testing
> > and saw no issues.
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr20/8240827-
> Downport_SSLSocketImpl_from_8221882-jdk11/01/
> >
> > Best regards,
> >   Goetz.
> >
> > [1] "8209333: Socket reset issue for TLS 1.3 socket close"
> > https://bugs.openjdk.java.net/browse/JDK-8209333
> > http://hg.openjdk.java.net/jdk/jdk12/rev/8a61a04c456c
> >
> > [2] "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> > https://bugs.openjdk.java.net/browse/JDK-8221882
> > http://hg.openjdk.java.net/jdk/jdk/rev/dfba4e321ab3
> >
> > [3] "8219991: New fix of the deadlock in sun.security.ssl.SSLSocketImpl"
> > https://bugs.openjdk.java.net/browse/JDK-8219991
> > http://hg.openjdk.java.net/jdk/jdk/rev/ca251ef47e0b
> >


From mbalao at redhat.com  Wed Mar 18 14:15:26 2020
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 18 Mar 2020 11:15:26 -0300
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <AM7PR02MB6049F54BA80FD9FC0742AB59ECF70@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <e8bb57a9-76b3-0895-89e7-d5440b1f2fb6@redhat.com>
 <AM7PR02MB6049F54BA80FD9FC0742AB59ECF70@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <ce1bac3d-6451-b625-747f-3e668d0e64c1@redhat.com>

On 3/18/20 8:15 AM, Lindenmaier, Goetz wrote:
> Taking the whole change to 11 seems too risky to me.

I didn't mean the whole patch -which I agree that seems too risky- but
the OutputRecord part (so OutputRecord.java and SSLSocketImpl.java files
do not need to be modified again when backporting the rest of 8221882).

Thanks,
Martin.-


From christoph.langer at sap.com  Wed Mar 18 19:56:35 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Mar 2020 19:56:35 +0000
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
 <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
 <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>
Message-ID: <AM0PR02MB5714F1B4C8128EF5FAF5E8F08AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I just approved the backport for 11u. Andrew, I assume you'll want to sponsor it?

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Robert Stupp
> Sent: Mittwoch, 18. M?rz 2020 08:51
> To: Andrew Hughes <gnu.andrew at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: Help requested, backport 8240629 to 11u + 14u
> 
> On Wed, 2020-03-18 at 05:00 +0000, Andrew Hughes wrote:
> >
> > Hi Robert,
> >
> > If the fix backports cleanly, you don't actually need a webrev; just
> > flagging the bug with the jdk[11,14]u-fix-request labels is
> > sufficient.
> > I've done this for you now:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8240629
> >
> > Incidentally, did you write this fix or just report the issue? I
> > don't
> > see a Contributed-by field on the changeset to credit you, if it's
> > the
> > former.
> >
> > Thanks,
> 
> Thank you Andrew!
> 
> I wrote an earlier version of the patch (without a unit test though).
> But yea, no contributed-by (like before *sigh* for JDK-8202216).
> 
> Robert
> 


From christoph.langer at sap.com  Wed Mar 18 20:05:57 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 18 Mar 2020 20:05:57 +0000
Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
 or older
In-Reply-To: <MWHPR21MB083096C1F557DF9983FF34AFE3F60@MWHPR21MB0830.namprd21.prod.outlook.com>
References: <MWHPR21MB083096C1F557DF9983FF34AFE3F60@MWHPR21MB0830.namprd21.prod.outlook.com>
Message-ID: <AM0PR02MB571453669CA8951741C755F38AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Junyuan,

I think this looks good. I can approve&sponsor this for you. I think we want to get this into jdk14u as well.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Junyuan Zheng
> Sent: Dienstag, 17. M?rz 2020 19:22
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
> or older
> 
> Hi,
> 
> I would like to backport JDK-8240972
> ("macOS codesign fail on macOS 10.13.5 or older") to 11u.
> 
> The original patch cannot be applied to 11u directly because of the change
> JDK-8239708 (https://bugs.openjdk.java.net/browse/JDK-8239708).
> 
> And here is the diff based on the current code:
> 
> ```
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -1228,12 +1228,25 @@
> AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
>        AC_MSG_CHECKING([if codesign certificate is present])
>        $RM codesign-testfile
>        $TOUCH codesign-testfile
> -      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD \
> +          >&AS_MESSAGE_LOG_FD || CODESIGN=
>        $RM codesign-testfile
>        if test "x$CODESIGN" = x; then
>          AC_MSG_RESULT([no])
>        else
>          AC_MSG_RESULT([yes])
> +        # Verify that the codesign has --option runtime
> +        AC_MSG_CHECKING([if codesign has --option runtime])
> +        $RM codesign-testfile
> +        $TOUCH codesign-testfile
> +        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY"
> codesign-testfile \
> +            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +        $RM codesign-testfile
> +        if test "x$CODESIGN" = x; then
> +          AC_MSG_ERROR([codesign does not have --option runtime. macOS
> 10.13.6 and above is required.])
> +        else
> +          AC_MSG_RESULT([yes])
> +        fi
>        fi
>      fi
>      BASIC_REQUIRE_PROGS(SETFILE, SetFile)
> ```
> 
> I also need a sponsor for this patch. Please let me know what you think.
> 
> Thanks,
> 
> Junyuan

From denghui.ddh at alibaba-inc.com  Thu Mar 19 06:14:02 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Thu, 19 Mar 2020 14:14:02 +0800
Subject: =?UTF-8?B?WzExdV0gW0pGUl0gUkZSKFhYTCkgODIyNjUxMTogSW1wbGVtZW50IEpGUiBFdmVudCBTdHJl?=
 =?UTF-8?B?YW1pbmc=?=
Message-ID: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>

Hi team,

JDK 14 is now Generally Available, as one of the features, JFR Event Streaming is very attractive for us.

With JFR Event Streaming, we can more easily implement the continuous monitoring of Java application based on JFR in the container environment.

So I would like to backport JDK-8226511(Implement JFR Event Streaming) to 11u, please help us to review the patch.

Previously, we had a discussion at https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html, there are many companies interested in this

Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
Test (release/slow-debug on Linux): All JFR Event Streaming passed, and other JFR tests have the same result with the build without this patch

The original patch is large, and cannot be applied to 11u directly
All files that cannot be derectly applied are as follows:
    src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
    src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't exist in 11u)
    test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java (dosn't exist in 11u, introduced in JDK-8213914)
    src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
    src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
    src/jdk.jfr/share/conf/jfr/profile.jfc
    src/jdk.jfr/share/conf/jfr/default.jfc
    src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
    src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
    src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
    src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
    src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
    src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
    src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp (ClassLoaderDataGraph_lock doesn't exist in 11u)
    src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
    src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
    src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
    src/hotspot/share/jfr/utilities/jfrTypes.hpp
    src/hotspot/share/jfr/support/jfrThreadLocal.cpp
    src/hotspot/share/jfr/metadata/metadata.xml
    src/hotspot/share/runtime/mutexLocker.cpp
  test/jdk/ProblemList.txt

Also, we want to backport some other related issues to 11u:
    JDK-8233700: EventStream not closed
    JDK-8229209: test for cross-process JFR event streaming
    JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should clean up files
    JDK-8234684: JFR crashes when rotating the JFR output during assertion failure
    JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never called
    JDK-8234888: EventStream::close doesn't abort streaming thread 
    JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed due to timeout at testStartTwice()
    JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR TestCrossProcessStreaming
    JDK-8233111: Epoch shift synchronization point for Compiler threads
    JDK-8234059: Stress test fails with "Unexpected Exception in thread JFR Event Stream"
    JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and jdk.jfr.Recording::getFlushInterval
    JDK-8236263: Remove experimental streaming events
Most of them can directly apply to 11u, except 8233111, 8234059 and 8236263

Cheers,
Denghui Dong

From yan at azul.com  Thu Mar 19 09:10:35 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Thu, 19 Mar 2020 12:10:35 +0300
Subject: [11u, 13u] RFR: backport of 8231507: Update Apache Santuario (XML
 Signature) to version 2.1.4
In-Reply-To: <0e17fc42-4911-0221-d69b-8d4e78947f70@azul.com>
References: <a655a36c-a0ff-d95b-d86f-a4a6fb2ec11b@azul.com>
 <AM6PR02MB5541601261F7677D4DD2BCD08A550@AM6PR02MB5541.eurprd02.prod.outlook.com>
 <0e17fc42-4911-0221-d69b-8d4e78947f70@azul.com>
Message-ID: <5ddfa7ea-8d71-ff1d-9cdd-6fd00dc2d939@azul.com>

OK, thanks, taking to 13u, too...

--yan

On 12.12.2019 16:01, Fedor wrote:
> Hi Christoph,
> 
> Fix request comment has been added.
> 
> Thanks,
> Fedor
> 
> On 12.12.2019 13:55, Langer, Christoph wrote:
>> Hi Fedor,
>>
>> thanks for doing this backport. Change looks good - Reviewed.
>>
>> As for the JBS item: Please add a fix request comment with some justification for the backport and a
>> link to this review thread. Then I can approve it.
>>
>> Thanks & Best regards
>> Christoph
>>
>>> -----Original Message-----
>>> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
>>> Behalf Of Fedor
>>> Sent: Mittwoch, 11. Dezember 2019 15:36
>>> To: jdk-updates-dev at openjdk.java.net
>>> Subject: [11u,13u] RFR: backport of 8231507: Update Apache Santuario (XML
>>> Signature) to version 2.1.4
>>>
>>> Hello all,
>>>
>>> I would like to ask for review backport of JDK-8231507 (Update Apache
>>> Santuario (XML Signature) to version 2.1.4)
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8231507
>>> webrev: http://cr.openjdk.java.net/~fijiol/8231507/webrev.13u.00/
>>> tests: test/jdk/com/sun/org/apache/xml/ test/jdk/javax/xml/crypto/dsig/
>>>
>>> It mostly applied cleanly, the only merge-conflict was in comments of
>>> XMLDSigRI.java file, which was updated as in jdk14:
>>>
>>> ? >>>>>>>>>>>>>>>>
>>> @@ -134,7 +134,8 @@
>>> ?????? }
>>>
>>> ?????? public XMLDSigRI() {
>>> -??????? /* We are the XMLDSig provider */
>>> +??????? // This is the JDK XMLDSig provider, synced from
>>> +??????? // Apache Santuario XML Security for Java, version 2.1.4
>>> ?????????? super("XMLDSig", VER, INFO);
>>>
>>> ?????????? final Provider p = this;
>>> ? >>>>>>>>>>>>>>>>
>>>
>>>
>>> Thanks,
>>> Fedor
>>


From martin.doerr at sap.com  Thu Mar 19 10:20:21 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 19 Mar 2020 10:20:21 +0000
Subject: RFR: [jdk11] 8225789: Empty method parameter type should generate
 ClassFormatError
In-Reply-To: <AM0PR02MB4227565F45784E6EA374BABB93F60@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227565F45784E6EA374BABB93F60@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3297E3D225D625BD7F1A76549AF40@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Matthias,

looks good to me. Thanks for backporting.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Dienstag, 17. M?rz 2020 16:11
> To: jdk-updates-dev at openjdk.java.net
> Subject: RFR: [jdk11] 8225789: Empty method parameter type
> should generate ClassFormatError
> 
> Hello,
>    please review the jdk11 backport of  8225789 .
> Do bring the patch into jdk11  I had to confirm the length check  in
> ClassFileParser::verify_unqualified_name because
> Of changes in the stride (the check itself integrates nicely).
> Additionally the class file version in
> /test/hotspot/jtreg/runtime/classFileParserBug/EmptyUnqName.jasm
> was adjusted to 55.
> 
> Bug/ jdk11 webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8225789
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8225789_jdk11/
> 
> ( jdk/jdk change is : https://hg.openjdk.java.net/jdk/jdk/rev/360f8769d3dc  )
> 
> Thanks, Matthias

From matthias.baesken at sap.com  Thu Mar 19 10:24:23 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 19 Mar 2020 10:24:23 +0000
Subject: RFR: [jdk11] 8225789: Empty method parameter type should generate
 ClassFormatError
In-Reply-To: <AM0PR0202MB3297E3D225D625BD7F1A76549AF40@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR02MB4227565F45784E6EA374BABB93F60@AM0PR02MB4227.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297E3D225D625BD7F1A76549AF40@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB422746923391E8B47BD346A593F40@AM0PR02MB4227.eurprd02.prod.outlook.com>

Thanks for the review !

Best regards, Matthias

-----Original Message-----
From: Doerr, Martin <martin.doerr at sap.com> 
Sent: Donnerstag, 19. M?rz 2020 11:20
To: Baesken, Matthias <matthias.baesken at sap.com>; jdk-updates-dev at openjdk.java.net
Subject: RE: RFR: [jdk11] 8225789: Empty method parameter type should generate ClassFormatError

Hi Matthias,

looks good to me. Thanks for backporting.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Dienstag, 17. M?rz 2020 16:11
> To: jdk-updates-dev at openjdk.java.net
> Subject: RFR: [jdk11] 8225789: Empty method parameter type
> should generate ClassFormatError
> 
> Hello,
>    please review the jdk11 backport of  8225789 .
> Do bring the patch into jdk11  I had to confirm the length check  in
> ClassFileParser::verify_unqualified_name because
> Of changes in the stride (the check itself integrates nicely).
> Additionally the class file version in
> /test/hotspot/jtreg/runtime/classFileParserBug/EmptyUnqName.jasm
> was adjusted to 55.
> 
> Bug/ jdk11 webrev :
> 
> https://bugs.openjdk.java.net/browse/JDK-8225789
> 
> http://cr.openjdk.java.net/~mbaesken/webrevs/8225789_jdk11/
> 
> ( jdk/jdk change is : https://hg.openjdk.java.net/jdk/jdk/rev/360f8769d3dc  )
> 
> Thanks, Matthias

From erik.gahlin at oracle.com  Thu Mar 19 11:24:43 2020
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 19 Mar 2020 12:24:43 +0100
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
Message-ID: <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>

Hi,

JDK 14 has been out for one day and few have used it in production. The 
feature changes core aspects of the JFR implementation, such as the 
tagging mechanism and the parser. Event streaming is not something that 
can be turned on by an API call or a command line flag, it is always 
there. If there are bugs, it will likely impact ordinary use of JFR as well.

Erik

> Hi team,
>
> JDK 14 is now Generally Available, as one of the features, JFR Event Streaming is very attractive for us.
>
> With JFR Event Streaming, we can more easily implement the continuous monitoring of Java application based on JFR in the container environment.
>
> So I would like to backport JDK-8226511(Implement JFR Event Streaming) to 11u, please help us to review the patch.
>
> Previously, we had a discussion at https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html, there are many companies interested in this
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> Test (release/slow-debug on Linux): All JFR Event Streaming passed, and other JFR tests have the same result with the build without this patch
>
> The original patch is large, and cannot be applied to 11u directly
> All files that cannot be derectly applied are as follows:
>      src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
>      src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't exist in 11u)
>      test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java (dosn't exist in 11u, introduced in JDK-8213914)
>      src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
>      src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
>      src/jdk.jfr/share/conf/jfr/profile.jfc
>      src/jdk.jfr/share/conf/jfr/default.jfc
>      src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
>      src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
>      src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
>      src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
>      src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
>      src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
>      src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp (ClassLoaderDataGraph_lock doesn't exist in 11u)
>      src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
>      src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
>      src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
>      src/hotspot/share/jfr/utilities/jfrTypes.hpp
>      src/hotspot/share/jfr/support/jfrThreadLocal.cpp
>      src/hotspot/share/jfr/metadata/metadata.xml
>      src/hotspot/share/runtime/mutexLocker.cpp
>    test/jdk/ProblemList.txt
>
> Also, we want to backport some other related issues to 11u:
>      JDK-8233700: EventStream not closed
>      JDK-8229209: test for cross-process JFR event streaming
>      JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should clean up files
>      JDK-8234684: JFR crashes when rotating the JFR output during assertion failure
>      JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never called
>      JDK-8234888: EventStream::close doesn't abort streaming thread
>      JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed due to timeout at testStartTwice()
>      JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR TestCrossProcessStreaming
>      JDK-8233111: Epoch shift synchronization point for Compiler threads
>      JDK-8234059: Stress test fails with "Unexpected Exception in thread JFR Event Stream"
>      JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and jdk.jfr.Recording::getFlushInterval
>      JDK-8236263: Remove experimental streaming events
> Most of them can directly apply to 11u, except 8233111, 8234059 and 8236263
>
> Cheers,
> Denghui Dong

From goetz.lindenmaier at sap.com  Thu Mar 19 13:48:34 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 19 Mar 2020 13:48:34 +0000
Subject: ping: [11u] RFR(M): 8213250: CDS archive creation aborts due to
 metaspace object allocation failure
Message-ID: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

Could I please get a review for this downport?

Thanks!
  Goetz

> -----Original Message-----
> From: Lindenmaier, Goetz
> Sent: Friday, March 13, 2020 3:21 PM
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR(M): 8213250: CDS archive creation aborts due to
> metaspace object allocation failure
> 
> Hi
> 
> I would like to downport this [1] for parity with 11.0.8-oracle.
> 
> I had to resolve because in one context the InstandeKlass/Klass type differs.
> 
> Further the change depends on some previous changes in jdk/jdk.
> I had to do the following changes in systemDictionaryShared.cpp:
> 
> Because [2] "8209645: Split ClassLoaderData and ClassLoaderDataGraph into
> separate files"
> is not in 11, the include of ClassLoaderDataGraph.hpp is not needed.
> 
> I had to undo the effects of [3] "8209301: JVM rename is_anonymous,
> host_klass to
> unsafe specific terminology ahead of Unsafe.defineAnonymousClass
> deprecation":
> is_unsafe_anonymous() --> is_anonymous()
> 
> The new SystemDictionaryShared::finalize_verification_constraints() locks
> the
> ClassLoaderDataGraph_lock. This lock was introduced by [4] "8210155: Lock
> ClassLoaderDataGraph Summary: In preparation for concurrent class
> unloading." and
> is not in 11. As I understand, 11 has no concurrent class loading, so this is not
> needed.
> Removed.
> 
> This webrev shows the edits I did after applying the change:
> http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01-
> edits/
> 
> This is the resulting webrev:
> http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01/
> 
> Please review.
> 
> Best regards,
>   Goetz.
> 
> [1]
> Original bug:
> https://bugs.openjdk.java.net/browse/JDK-8213250
> http://hg.openjdk.java.net/jdk/jdk/rev/e0fd97beab7e
> [2]
> 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files
> https://bugs.openjdk.java.net/browse/JDK-8209645
> http://hg.openjdk.java.net/jdk/jdk/rev/db0c3952de52
> [3]
> 8209301: JVM rename is_anonymous, host_klass to unsafe specific
> terminology ahead
> of Unsafe.defineAnonymousClass deprecation
> https://bugs.openjdk.java.net/browse/JDK-8209301
> http://hg.openjdk.java.net/jdk/jdk/rev/3e5d28e6de32
> [4]
> 8210155: Lock ClassLoaderDataGraph Summary: In preparation for concurrent
> class unloading
> https://bugs.openjdk.java.net/browse/JDK-8210155
> http://hg.openjdk.java.net/jdk/jdk/rev/625a5bdde0c5
> 
> 


From thomas.stuefe at gmail.com  Thu Mar 19 15:36:58 2020
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 19 Mar 2020 16:36:58 +0100
Subject: ping: [11u] RFR(M): 8213250: CDS archive creation aborts due to
 metaspace object allocation failure
In-Reply-To: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <CAA-vtUw=u_8BijO9xB3A0GQxWxJV+J2d9H3fdpcUdx=h4dq3fw@mail.gmail.com>

Hi Goetz,

looks good to me.

Cheers, Thomas

On Thu, Mar 19, 2020 at 2:51 PM Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi,
>
> Could I please get a review for this downport?
>
> Thanks!
>   Goetz
>
> > -----Original Message-----
> > From: Lindenmaier, Goetz
> > Sent: Friday, March 13, 2020 3:21 PM
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR(M): 8213250: CDS archive creation aborts due to
> > metaspace object allocation failure
> >
> > Hi
> >
> > I would like to downport this [1] for parity with 11.0.8-oracle.
> >
> > I had to resolve because in one context the InstandeKlass/Klass type
> differs.
> >
> > Further the change depends on some previous changes in jdk/jdk.
> > I had to do the following changes in systemDictionaryShared.cpp:
> >
> > Because [2] "8209645: Split ClassLoaderData and ClassLoaderDataGraph into
> > separate files"
> > is not in 11, the include of ClassLoaderDataGraph.hpp is not needed.
> >
> > I had to undo the effects of [3] "8209301: JVM rename is_anonymous,
> > host_klass to
> > unsafe specific terminology ahead of Unsafe.defineAnonymousClass
> > deprecation":
> > is_unsafe_anonymous() --> is_anonymous()
> >
> > The new SystemDictionaryShared::finalize_verification_constraints() locks
> > the
> > ClassLoaderDataGraph_lock. This lock was introduced by [4] "8210155: Lock
> > ClassLoaderDataGraph Summary: In preparation for concurrent class
> > unloading." and
> > is not in 11. As I understand, 11 has no concurrent class loading, so
> this is not
> > needed.
> > Removed.
> >
> > This webrev shows the edits I did after applying the change:
> > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01-
> > edits/
> >
> > This is the resulting webrev:
> > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01/
> >
> > Please review.
> >
> > Best regards,
> >   Goetz.
> >
> > [1]
> > Original bug:
> > https://bugs.openjdk.java.net/browse/JDK-8213250
> > http://hg.openjdk.java.net/jdk/jdk/rev/e0fd97beab7e
> > [2]
> > 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate
> files
> > https://bugs.openjdk.java.net/browse/JDK-8209645
> > http://hg.openjdk.java.net/jdk/jdk/rev/db0c3952de52
> > [3]
> > 8209301: JVM rename is_anonymous, host_klass to unsafe specific
> > terminology ahead
> > of Unsafe.defineAnonymousClass deprecation
> > https://bugs.openjdk.java.net/browse/JDK-8209301
> > http://hg.openjdk.java.net/jdk/jdk/rev/3e5d28e6de32
> > [4]
> > 8210155: Lock ClassLoaderDataGraph Summary: In preparation for concurrent
> > class unloading
> > https://bugs.openjdk.java.net/browse/JDK-8210155
> > http://hg.openjdk.java.net/jdk/jdk/rev/625a5bdde0c5
> >
> >
>
>

From goetz.lindenmaier at sap.com  Thu Mar 19 15:39:21 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 19 Mar 2020 15:39:21 +0000
Subject: Fixes of copyright headers: Should we downport them?
Message-ID: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Andrew,

There are a row of changes fixing copyrights downported by Oracle to 11.0.8,
similar to this one:
https://bugs.openjdk.java.net/browse/JDK-8220414

See also 
https://bugs.openjdk.java.net/issues/?filter=38639

I'd consider them pretty pointless given the rules you set.
So should we skip them?
If so, I would mark them all as openjdk-na. 
(In my opinion we should downport them, but I'll follow 
your advice.)

Best regards,
  Goetz.

From jianglizhou at google.com  Thu Mar 19 19:25:12 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Thu, 19 Mar 2020 12:25:12 -0700
Subject: ping: [11u] RFR(M): 8213250: CDS archive creation aborts due to
 metaspace object allocation failure
In-Reply-To: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <CALrW1jx2uMafg++F01B7TdXKeok83B_MQyV63aYpsiEp=Uo+cw@mail.gmail.com>

Hi Goetz,

The backport looks good to me. I will also run some tests on my side
for the backport. Will report back to you.

Best,
Jiangli

On Thu, Mar 19, 2020 at 6:51 AM Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
>
> Hi,
>
> Could I please get a review for this downport?
>
> Thanks!
>   Goetz
>
> > -----Original Message-----
> > From: Lindenmaier, Goetz
> > Sent: Friday, March 13, 2020 3:21 PM
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR(M): 8213250: CDS archive creation aborts due to
> > metaspace object allocation failure
> >
> > Hi
> >
> > I would like to downport this [1] for parity with 11.0.8-oracle.
> >
> > I had to resolve because in one context the InstandeKlass/Klass type differs.
> >
> > Further the change depends on some previous changes in jdk/jdk.
> > I had to do the following changes in systemDictionaryShared.cpp:
> >
> > Because [2] "8209645: Split ClassLoaderData and ClassLoaderDataGraph into
> > separate files"
> > is not in 11, the include of ClassLoaderDataGraph.hpp is not needed.
> >
> > I had to undo the effects of [3] "8209301: JVM rename is_anonymous,
> > host_klass to
> > unsafe specific terminology ahead of Unsafe.defineAnonymousClass
> > deprecation":
> > is_unsafe_anonymous() --> is_anonymous()
> >
> > The new SystemDictionaryShared::finalize_verification_constraints() locks
> > the
> > ClassLoaderDataGraph_lock. This lock was introduced by [4] "8210155: Lock
> > ClassLoaderDataGraph Summary: In preparation for concurrent class
> > unloading." and
> > is not in 11. As I understand, 11 has no concurrent class loading, so this is not
> > needed.
> > Removed.
> >
> > This webrev shows the edits I did after applying the change:
> > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01-
> > edits/
> >
> > This is the resulting webrev:
> > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01/
> >
> > Please review.
> >
> > Best regards,
> >   Goetz.
> >
> > [1]
> > Original bug:
> > https://bugs.openjdk.java.net/browse/JDK-8213250
> > http://hg.openjdk.java.net/jdk/jdk/rev/e0fd97beab7e
> > [2]
> > 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files
> > https://bugs.openjdk.java.net/browse/JDK-8209645
> > http://hg.openjdk.java.net/jdk/jdk/rev/db0c3952de52
> > [3]
> > 8209301: JVM rename is_anonymous, host_klass to unsafe specific
> > terminology ahead
> > of Unsafe.defineAnonymousClass deprecation
> > https://bugs.openjdk.java.net/browse/JDK-8209301
> > http://hg.openjdk.java.net/jdk/jdk/rev/3e5d28e6de32
> > [4]
> > 8210155: Lock ClassLoaderDataGraph Summary: In preparation for concurrent
> > class unloading
> > https://bugs.openjdk.java.net/browse/JDK-8210155
> > http://hg.openjdk.java.net/jdk/jdk/rev/625a5bdde0c5
> >
> >
>

From hohensee at amazon.com  Thu Mar 19 22:14:30 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 19 Mar 2020 22:14:30 +0000
Subject: [11u] RFR 8238676: jni crashes on accessing it from process exit hook
Message-ID: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>

This is an Oracle 11.0.8 backport and does not apply cleanly to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238676
Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/80e4a066342d
11u backport webrev: http://cr.openjdk.java.net/~phh/8238676/webrev.11u.00/

The first hunk of JtregNativeHotspot.gmk didn?t apply cleanly because 11u doesn?t include JDK-8179317<https://bugs.openjdk.java.net/browse/JDK-8179317>. The first hunk of jni.cpp didn?t apply cleanly because 11u doesn?t include JDK-8234739<https://bugs.openjdk.java.net/browse/JDK-8234739>.

Successfully runs the jtreg runtime/jni tests with the two new tests included in the patch on Linux. I don?t have ready access to a Windows box, so I?d greatly appreciate it if someone could do a quick build/test on Windows for me.

Thanks,
Paul


From david.holmes at oracle.com  Thu Mar 19 22:24:07 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Mar 2020 08:24:07 +1000
Subject: [11u] RFR 8238676: jni crashes on accessing it from process exit
 hook
In-Reply-To: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>
References: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>
Message-ID: <1654f1fe-e8d8-1d89-eda1-39732ad02fc4@oracle.com>

Hi Paul,

This looks like an accurate backport to me.

Cheers,
David

On 20/03/2020 8:14 am, Hohensee, Paul wrote:
> This is an Oracle 11.0.8 backport and does not apply cleanly to 11u.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238676
> Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/80e4a066342d
> 11u backport webrev: http://cr.openjdk.java.net/~phh/8238676/webrev.11u.00/
> 
> The first hunk of JtregNativeHotspot.gmk didn?t apply cleanly because 11u doesn?t include JDK-8179317<https://bugs.openjdk.java.net/browse/JDK-8179317>. The first hunk of jni.cpp didn?t apply cleanly because 11u doesn?t include JDK-8234739<https://bugs.openjdk.java.net/browse/JDK-8234739>.
> 
> Successfully runs the jtreg runtime/jni tests with the two new tests included in the patch on Linux. I don?t have ready access to a Windows box, so I?d greatly appreciate it if someone could do a quick build/test on Windows for me.
> 
> Thanks,
> Paul
> 

From hohensee at amazon.com  Thu Mar 19 22:25:54 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 19 Mar 2020 22:25:54 +0000
Subject: [11u] RFR 8238676: jni crashes on accessing it from process exit
 hook
In-Reply-To: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>
References: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>
Message-ID: <DF562D70-F163-40C0-8B21-DC68AEE4BD66@amazon.com>

Typo: it?s the second hunk in jni.cpp, not the first.

From: "Hohensee, Paul" <hohensee at amazon.com>
Date: Thursday, March 19, 2020 at 3:14 PM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: [11u] RFR 8238676: jni crashes on accessing it from process exit hook

This is an Oracle 11.0.8 backport and does not apply cleanly to 11u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238676
Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/80e4a066342d
11u backport webrev: http://cr.openjdk.java.net/~phh/8238676/webrev.11u.00/

The first hunk of JtregNativeHotspot.gmk didn?t apply cleanly because 11u doesn?t include JDK-8179317<https://bugs.openjdk.java.net/browse/JDK-8179317>. The first hunk of jni.cpp didn?t apply cleanly because 11u doesn?t include JDK-8234739<https://bugs.openjdk.java.net/browse/JDK-8234739>.

Successfully runs the jtreg runtime/jni tests with the two new tests included in the patch on Linux. I don?t have ready access to a Windows box, so I?d greatly appreciate it if someone could do a quick build/test on Windows for me.

Thanks,
Paul


From hohensee at amazon.com  Thu Mar 19 22:28:42 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 19 Mar 2020 22:28:42 +0000
Subject: [11u] RFR 8238676: jni crashes on accessing it from process exit
 hook
In-Reply-To: <1654f1fe-e8d8-1d89-eda1-39732ad02fc4@oracle.com>
References: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>
 <1654f1fe-e8d8-1d89-eda1-39732ad02fc4@oracle.com>
Message-ID: <83BB6D2B-C882-44A0-A70A-E4A13E927C49@amazon.com>

Thanks for your review, David.

Paul

?On 3/19/20, 3:24 PM, "David Holmes" <david.holmes at oracle.com> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
    
    
    
    Hi Paul,
    
    This looks like an accurate backport to me.
    
    Cheers,
    David
    
    On 20/03/2020 8:14 am, Hohensee, Paul wrote:
    > This is an Oracle 11.0.8 backport and does not apply cleanly to 11u.
    >
    > Bug: https://bugs.openjdk.java.net/browse/JDK-8238676
    > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/80e4a066342d
    > 11u backport webrev: http://cr.openjdk.java.net/~phh/8238676/webrev.11u.00/
    >
    > The first hunk of JtregNativeHotspot.gmk didn?t apply cleanly because 11u doesn?t include JDK-8179317<https://bugs.openjdk.java.net/browse/JDK-8179317>. The first hunk of jni.cpp didn?t apply cleanly because 11u doesn?t include JDK-8234739<https://bugs.openjdk.java.net/browse/JDK-8234739>.
    >
    > Successfully runs the jtreg runtime/jni tests with the two new tests included in the patch on Linux. I don?t have ready access to a Windows box, so I?d greatly appreciate it if someone could do a quick build/test on Windows for me.
    >
    > Thanks,
    > Paul
    >
    


From christoph.langer at sap.com  Fri Mar 20 10:40:51 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 20 Mar 2020 10:40:51 +0000
Subject: RFD: What do we do about programs which set sys_paths to null?
In-Reply-To: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
References: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
Message-ID: <AM0PR02MB57142D22C6DE8088A1011C938AF50@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Andrew,

to me this looks like a good and feasible solution to restore old behavior while still keeping Runtime::load and Runtime::loadLibrary free from deadlock-prone synchronization.

Can you create a JBS bug for this and set it to 11-pool?

I'll run your fix through some regression testing in 11u. There we haven't backed out JDK-8231584 yet.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Dienstag, 17. M?rz 2020 17:50
> To: jdk-updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Subject: RFD: What do we do about programs which set sys_paths to null?
> 
> [ People who know all this stuff already, please feel free to skip
> this introduction. ]
> 
> This is a request for discussion about support for some programs that
> do something illegal, not at all supported. I'd like to make this work
> as intended by users, even though it's unsupported. Which seems odd,
> but I still think we should do it.
> 
> There is a long-established hack (going back about 20 years) which
> allows Java programs to set the property "java.library.path"
> dynamically. You might need to do this if you're a Java program which
> extracts a shared library from a jarfile, puts it in a tmpdir
> somewhere, then loads that library.
> 
> People discovered that even though you can set "java.library.path" in
> a program, it doesn't work as intended because the property is only
> read once at boot time, and it is then cached in the static field
> ClassLoader.usr_paths. So, people discovered that if they set
> "java.library.path" then set set ClassLoader.sys_paths to null, then
> called ClassLoader.loadLibrary, it works. Something like this:
> 
>    Class loaderClass = ClassLoader.class;
>    Field userPaths = loaderClass.getDeclaredField( "sys_paths" );
>    userPaths.setAccessible( true );
>    userPaths.set( null, null );
> 
> See the answer here, for example:
> https://community.oracle.com/thread/1551225?start=15&tstart=0
> 
> This worked because ClassLoader.loadLibrary() did this:
> 
>         if (sys_paths == null) {
>             usr_paths = initializePath("java.library.path");
>             sys_paths = initializePath("sun.boot.library.path");
>         }
> 
> The paths got re-initialized.
> 
> The back-ported fix for "8231584: Deadlock with
> ClassLoader.findLibrary and System.loadLibrary call", broke this
> hack. The code that lazily re-initializes usr_paths and sys_paths has
> gone. However, there was another important change:
> ClassLoader.loadLibrary0(), which calls ClassLoader.loadLibrary, is no
> longer synchronized, so there may now be concurrent accesses to
> ClassLoader.loadLibrary().
> 
> [ The proposed fix. ]
> 
> I'd like to add this patch to 8u and 11u:
> 
> --- a/src/java.base/share/classes/java/lang/ClassLoader.java    Mon Feb 03
> 09:39:39 2020 +0100
> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java    Tue Mar 17
> 16:24:10 2020 +0000
> @@ -2562,7 +2562,7 @@
> 
>      // The paths searched for libraries
>      private static String usr_paths[];
> -    private static String sys_paths[];
> +    private static volatile String sys_paths[];
> 
>      private static String[] initializePath(String propName) {
>          String ldPath = System.getProperty(propName, "");
> @@ -2620,6 +2620,10 @@
>                              boolean isAbsolute) {
>          ClassLoader loader =
>              (fromClass == null) ? null : fromClass.getClassLoader();
> +        if (sys_paths == null) {
> +            usr_paths = initializePath("java.library.path");
> +            sys_paths = initializePath("sun.boot.library.path");
> +        }
>          assert sys_paths != null : "should be initialized at this point";
>          assert usr_paths != null : "should be initialized at this point";
> 
> This patch does nothing unless sys_paths has been set to null. There
> is some slight slowdown because a non-volatile read of sys_paths is
> now volatile, but it's IMO insignificant and in any case it's less
> than the overhead of the synchronized loadLibrary0().
> 
> I do not believe that this introduces a race when the user sets
> sys_paths to null because
> 
>    setProperty("java.library.path") happens before (write volatile sys_paths)
> (Program order)
>    (write volatile sys_paths) synchronizes with (read volatile sys_paths)
>    (read volatile sys_paths) happens before getProperty("java.lbrary.path")
> (Program order)
> 
> If the user sets sys_paths to null before setting "java.library.path"
> there is indeed a race and their program might not work, but there
> always was a race anyway.
> 
> I think we should do this for 8u and 11u. My justification is that even
> though this is an ugly hack, it satisfies a real need and we don't want
> to break users' programs in an update.
> 
> What do you think?
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From akozlov at azul.com  Fri Mar 20 13:54:55 2020
From: akozlov at azul.com (Anton Kozlov)
Date: Fri, 20 Mar 2020 16:54:55 +0300
Subject: RFD: What do we do about programs which set sys_paths to null?
In-Reply-To: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
References: <e419f370-ea2a-cc90-a1be-641837bae747@redhat.com>
Message-ID: <1d019cc7-2bcb-a992-fe81-2404212a3e42@azul.com>

Hi,

On 17.03.2020 19:49, Andrew Haley wrote:
> --- a/src/java.base/share/classes/java/lang/ClassLoader.java    Mon Feb 03 09:39:39 2020 +0100
> +++ b/src/java.base/share/classes/java/lang/ClassLoader.java    Tue Mar 17 16:24:10 2020 +0000
> @@ -2562,7 +2562,7 @@
> 
>      // The paths searched for libraries
>      private static String usr_paths[];
> -    private static String sys_paths[];
> +    private static volatile String sys_paths[];
> 
>      private static String[] initializePath(String propName) {
>          String ldPath = System.getProperty(propName, "");
> @@ -2620,6 +2620,10 @@
>                              boolean isAbsolute) {
>          ClassLoader loader =
>              (fromClass == null) ? null : fromClass.getClassLoader();
> +        if (sys_paths == null) {
> +            usr_paths = initializePath("java.library.path");
> +            sys_paths = initializePath("sun.boot.library.path");
> +        }
>          assert sys_paths != null : "should be initialized at this point";
>          assert usr_paths != null : "should be initialized at this point";

The patch looks good to me

> I think we should do this for 8u and 11u. My justification is that even
> though this is an ugly hack, it satisfies a real need and we don't want
> to break users' programs in an update.

Agree

> I do not believe that this introduces a race when the user sets
> sys_paths to null because
> 
>    setProperty("java.library.path") happens before (write volatile sys_paths)  (Program order)
>    (write volatile sys_paths) synchronizes with (read volatile sys_paths)
>    (read volatile sys_paths) happens before getProperty("java.lbrary.path") (Program order)
> 

It's also worth to mention that usr_paths is never null. And once a thread re-initialized 
sys_paths and another thread sees new sys_paths, the another thread will see updated usr_paths
by the same reasoning with s/setProperty()/usr_paths = .../. So everything is good.

Thanks for addressing this!
-- Anton


From christoph.langer at sap.com  Fri Mar 20 14:50:04 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 20 Mar 2020 14:50:04 +0000
Subject: [11u]: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk
 images
Message-ID: <AM0PR02MB5714B8BF2B2AA982B98C4B4A8AF50@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

please help to review a backport of JDK-8237192 Generate stripped/public pdbs on Windows for jdk images to OpenJDK 11.

Bug: https://bugs.openjdk.java.net/browse/JDK-8237192
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/9b999cf5e13a
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237192.11u/

Apart from resolving some copyright year changes, I had to trivially resolve some hunks in  make/common/NativeCompilation.gmk, make/launcher/Launcher-java.base.gmk and make/scripts/compare.sh. In NativeCompilation.gmk, the variable $1_SYMBOLS_DIR of the original change had to be replaced with the equivalent $1_OUTPUT_DIR. Furthermore I had to replace calls to "isTargetOs" in the makefiles with equivalent constructs since that function is not available in 11.

Thanks
Christoph


From bevans at newrelic.com  Fri Mar 20 16:05:58 2020
From: bevans at newrelic.com (Ben Evans)
Date: Fri, 20 Mar 2020 17:05:58 +0100
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
Message-ID: <CAGw=733SUDHhqxRQxkp4kGFLeep5Kvp2ZrGYyBw4Qgc2zvbvwg@mail.gmail.com>

Hi Denghui,

This looks very interesting - thanks for your work so far.

How can we get started with it? Could we follow a similar model that used
to backport JFR (file) to OpenJDK 8 - by starting with a separate repo?

Martijn - how difficult would it be to have AdoptOpenJDK build binaries
from a separate 11u-jfr-streaming repo, if we were to do that?

Cheers,

Ben

On Thu, Mar 19, 2020 at 7:15 AM Denghui Dong <denghui.ddh at alibaba-inc.com>
wrote:

> Hi team,
>
> JDK 14 is now Generally Available, as one of the features, JFR Event
> Streaming is very attractive for us.
>
> With JFR Event Streaming, we can more easily implement the continuous
> monitoring of Java application based on JFR in the container environment.
>
> So I would like to backport JDK-8226511(Implement JFR Event Streaming) to
> 11u, please help us to review the patch.
>
> Previously, we had a discussion at
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html,
> there are many companies interested in this
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> Test (release/slow-debug on Linux): All JFR Event Streaming passed, and
> other JFR tests have the same result with the build without this patch
>
> The original patch is large, and cannot be applied to 11u directly
> All files that cannot be derectly applied are as follows:
>     src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
>     src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't exist
> in 11u)
>     test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java (dosn't
> exist in 11u, introduced in JDK-8213914)
>     src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
>     src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
>     src/jdk.jfr/share/conf/jfr/profile.jfc
>     src/jdk.jfr/share/conf/jfr/default.jfc
>     src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
>     src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
>     src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
>     src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
>     src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
>     src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
>     src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
> (ClassLoaderDataGraph_lock doesn't exist in 11u)
>     src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
>     src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
>     src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
>     src/hotspot/share/jfr/utilities/jfrTypes.hpp
>     src/hotspot/share/jfr/support/jfrThreadLocal.cpp
>     src/hotspot/share/jfr/metadata/metadata.xml
>     src/hotspot/share/runtime/mutexLocker.cpp
>   test/jdk/ProblemList.txt
>
> Also, we want to backport some other related issues to 11u:
>     JDK-8233700: EventStream not closed
>     JDK-8229209: test for cross-process JFR event streaming
>     JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should clean
> up files
>     JDK-8234684: JFR crashes when rotating the JFR output during assertion
> failure
>     JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never
> called
>     JDK-8234888: EventStream::close doesn't abort streaming thread
>     JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed
> due to timeout at testStartTwice()
>     JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR
> TestCrossProcessStreaming
>     JDK-8233111: Epoch shift synchronization point for Compiler threads
>     JDK-8234059: Stress test fails with "Unexpected Exception in thread
> JFR Event Stream"
>     JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and
> jdk.jfr.Recording::getFlushInterval
>     JDK-8236263: Remove experimental streaming events
> Most of them can directly apply to 11u, except 8233111, 8234059 and 8236263
>
> Cheers,
> Denghui Dong

From hohensee at amazon.com  Fri Mar 20 22:08:41 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 20 Mar 2020 22:08:41 +0000
Subject: [11u] RFR 8238676: jni crashes on accessing it from process exit
 hook
In-Reply-To: <83BB6D2B-C882-44A0-A70A-E4A13E927C49@amazon.com>
References: <76E65EE0-E90B-4405-B42F-F8598B44750F@amazon.com>
 <1654f1fe-e8d8-1d89-eda1-39732ad02fc4@oracle.com>
 <83BB6D2B-C882-44A0-A70A-E4A13E927C49@amazon.com>
Message-ID: <BCB0CB85-65F5-4343-82BC-4FB5BAEF4E89@amazon.com>

I got access to a Windows box, and the Hotspot JNI tests including the ones in the patch pass on it. I've tagged the issue with jdk11u-fix-request.

Thanks,
Paul

?On 3/19/20, 3:32 PM, "jdk-updates-dev on behalf of Hohensee, Paul" <jdk-updates-dev-bounces at openjdk.java.net on behalf of hohensee at amazon.com> wrote:

    Thanks for your review, David.
    
    Paul
    
    On 3/19/20, 3:24 PM, "David Holmes" <david.holmes at oracle.com> wrote:
    
        CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
        
        
        
        Hi Paul,
        
        This looks like an accurate backport to me.
        
        Cheers,
        David
        
        On 20/03/2020 8:14 am, Hohensee, Paul wrote:
        > This is an Oracle 11.0.8 backport and does not apply cleanly to 11u.
        >
        > Bug: https://bugs.openjdk.java.net/browse/JDK-8238676
        > Original changeset: https://hg.openjdk.java.net/jdk/jdk/rev/80e4a066342d
        > 11u backport webrev: http://cr.openjdk.java.net/~phh/8238676/webrev.11u.00/
        >
        > The first hunk of JtregNativeHotspot.gmk didn?t apply cleanly because 11u doesn?t include JDK-8179317<https://bugs.openjdk.java.net/browse/JDK-8179317>. The first hunk of jni.cpp didn?t apply cleanly because 11u doesn?t include JDK-8234739<https://bugs.openjdk.java.net/browse/JDK-8234739>.
        >
        > Successfully runs the jtreg runtime/jni tests with the two new tests included in the patch on Linux. I don?t have ready access to a Windows box, so I?d greatly appreciate it if someone could do a quick build/test on Windows for me.
        >
        > Thanks,
        > Paul
        >
        
    
    


From martijnverburg at gmail.com  Fri Mar 20 22:56:18 2020
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 20 Mar 2020 22:56:18 +0000
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAGw=733SUDHhqxRQxkp4kGFLeep5Kvp2ZrGYyBw4Qgc2zvbvwg@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <CAGw=733SUDHhqxRQxkp4kGFLeep5Kvp2ZrGYyBw4Qgc2zvbvwg@mail.gmail.com>
Message-ID: <CAP7YuASaWvO-yOOpZU1A4jtYyLs_HbQVMAdaM=bS2yhvKbLVjg@mail.gmail.com>

Adopt Binaries would be easy to produce as long as folks were happy pulling
them from a GitHub binary repo (as opposed to our main API)
Cheers,
Martijn


On Fri, 20 Mar 2020 at 16:06, Ben Evans <bevans at newrelic.com> wrote:

> Hi Denghui,
>
> This looks very interesting - thanks for your work so far.
>
> How can we get started with it? Could we follow a similar model that used
> to backport JFR (file) to OpenJDK 8 - by starting with a separate repo?
>
> Martijn - how difficult would it be to have AdoptOpenJDK build binaries
> from a separate 11u-jfr-streaming repo, if we were to do that?
>
> Cheers,
>
> Ben
>
> On Thu, Mar 19, 2020 at 7:15 AM Denghui Dong <denghui.ddh at alibaba-inc.com>
> wrote:
>
> > Hi team,
> >
> > JDK 14 is now Generally Available, as one of the features, JFR Event
> > Streaming is very attractive for us.
> >
> > With JFR Event Streaming, we can more easily implement the continuous
> > monitoring of Java application based on JFR in the container environment.
> >
> > So I would like to backport JDK-8226511(Implement JFR Event Streaming) to
> > 11u, please help us to review the patch.
> >
> > Previously, we had a discussion at
> >
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html
> ,
> > there are many companies interested in this
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> > Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> > Test (release/slow-debug on Linux): All JFR Event Streaming passed, and
> > other JFR tests have the same result with the build without this patch
> >
> > The original patch is large, and cannot be applied to 11u directly
> > All files that cannot be derectly applied are as follows:
> >     src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
> >     src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't
> exist
> > in 11u)
> >     test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java
> (dosn't
> > exist in 11u, introduced in JDK-8213914)
> >     src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
> >     src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
> >     src/jdk.jfr/share/conf/jfr/profile.jfc
> >     src/jdk.jfr/share/conf/jfr/default.jfc
> >     src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
> >     src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
> >     src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> >     src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
> >     src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
> >     src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
> >     src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
> > (ClassLoaderDataGraph_lock doesn't exist in 11u)
> >     src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
> >     src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
> >     src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
> >     src/hotspot/share/jfr/utilities/jfrTypes.hpp
> >     src/hotspot/share/jfr/support/jfrThreadLocal.cpp
> >     src/hotspot/share/jfr/metadata/metadata.xml
> >     src/hotspot/share/runtime/mutexLocker.cpp
> >   test/jdk/ProblemList.txt
> >
> > Also, we want to backport some other related issues to 11u:
> >     JDK-8233700: EventStream not closed
> >     JDK-8229209: test for cross-process JFR event streaming
> >     JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should
> clean
> > up files
> >     JDK-8234684: JFR crashes when rotating the JFR output during
> assertion
> > failure
> >     JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never
> > called
> >     JDK-8234888: EventStream::close doesn't abort streaming thread
> >     JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed
> > due to timeout at testStartTwice()
> >     JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR
> > TestCrossProcessStreaming
> >     JDK-8233111: Epoch shift synchronization point for Compiler threads
> >     JDK-8234059: Stress test fails with "Unexpected Exception in thread
> > JFR Event Stream"
> >     JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and
> > jdk.jfr.Recording::getFlushInterval
> >     JDK-8236263: Remove experimental streaming events
> > Most of them can directly apply to 11u, except 8233111, 8234059 and
> 8236263
> >
> > Cheers,
> > Denghui Dong
>

From neugens.limasoftware at gmail.com  Sat Mar 21 00:50:57 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Sat, 21 Mar 2020 01:50:57 +0100
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
Message-ID: <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>

I agree, while this is certainly an interesting feature, we should
probably let it bake a bit.

I'm particularly concerned about stability and performance here.

Cheers,
Mario

Il giorno gio 19 mar 2020 alle ore 12:24 Erik Gahlin
<erik.gahlin at oracle.com> ha scritto:

>
> Hi,
>
> JDK 14 has been out for one day and few have used it in production. The
> feature changes core aspects of the JFR implementation, such as the
> tagging mechanism and the parser. Event streaming is not something that
> can be turned on by an API call or a command line flag, it is always
> there. If there are bugs, it will likely impact ordinary use of JFR as well.
>
> Erik
>
> > Hi team,
> >
> > JDK 14 is now Generally Available, as one of the features, JFR Event Streaming is very attractive for us.
> >
> > With JFR Event Streaming, we can more easily implement the continuous monitoring of Java application based on JFR in the container environment.
> >
> > So I would like to backport JDK-8226511(Implement JFR Event Streaming) to 11u, please help us to review the patch.
> >
> > Previously, we had a discussion at https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html, there are many companies interested in this
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> > Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> > Test (release/slow-debug on Linux): All JFR Event Streaming passed, and other JFR tests have the same result with the build without this patch
> >
> > The original patch is large, and cannot be applied to 11u directly
> > All files that cannot be derectly applied are as follows:
> >      src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
> >      src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't exist in 11u)
> >      test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java (dosn't exist in 11u, introduced in JDK-8213914)
> >      src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
> >      src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
> >      src/jdk.jfr/share/conf/jfr/profile.jfc
> >      src/jdk.jfr/share/conf/jfr/default.jfc
> >      src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
> >      src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
> >      src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> >      src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
> >      src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
> >      src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
> >      src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp (ClassLoaderDataGraph_lock doesn't exist in 11u)
> >      src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
> >      src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
> >      src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
> >      src/hotspot/share/jfr/utilities/jfrTypes.hpp
> >      src/hotspot/share/jfr/support/jfrThreadLocal.cpp
> >      src/hotspot/share/jfr/metadata/metadata.xml
> >      src/hotspot/share/runtime/mutexLocker.cpp
> >    test/jdk/ProblemList.txt
> >
> > Also, we want to backport some other related issues to 11u:
> >      JDK-8233700: EventStream not closed
> >      JDK-8229209: test for cross-process JFR event streaming
> >      JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should clean up files
> >      JDK-8234684: JFR crashes when rotating the JFR output during assertion failure
> >      JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never called
> >      JDK-8234888: EventStream::close doesn't abort streaming thread
> >      JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed due to timeout at testStartTwice()
> >      JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR TestCrossProcessStreaming
> >      JDK-8233111: Epoch shift synchronization point for Compiler threads
> >      JDK-8234059: Stress test fails with "Unexpected Exception in thread JFR Event Stream"
> >      JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and jdk.jfr.Recording::getFlushInterval
> >      JDK-8236263: Remove experimental streaming events
> > Most of them can directly apply to 11u, except 8233111, 8234059 and 8236263
> >
> > Cheers,
> > Denghui Dong



--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From jianglizhou at google.com  Sat Mar 21 00:59:20 2020
From: jianglizhou at google.com (Jiangli Zhou)
Date: Fri, 20 Mar 2020 17:59:20 -0700
Subject: ping: [11u] RFR(M): 8213250: CDS archive creation aborts due to
 metaspace object allocation failure
In-Reply-To: <CALrW1jx2uMafg++F01B7TdXKeok83B_MQyV63aYpsiEp=Uo+cw@mail.gmail.com>
References: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <CALrW1jx2uMafg++F01B7TdXKeok83B_MQyV63aYpsiEp=Uo+cw@mail.gmail.com>
Message-ID: <CALrW1jwBq+uV86mgEAdSRfrStF=gduLNrm3cnn4kPBwCvy3f0g@mail.gmail.com>

On Thu, Mar 19, 2020 at 12:25 PM Jiangli Zhou <jianglizhou at google.com> wrote:
>
> Hi Goetz,
>
> The backport looks good to me. I will also run some tests on my side
> for the backport. Will report back to you.

Testing from my side looks good. Thanks!

Best regards,
Jiangli

>
> Best,
> Jiangli
>
> On Thu, Mar 19, 2020 at 6:51 AM Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com> wrote:
> >
> > Hi,
> >
> > Could I please get a review for this downport?
> >
> > Thanks!
> >   Goetz
> >
> > > -----Original Message-----
> > > From: Lindenmaier, Goetz
> > > Sent: Friday, March 13, 2020 3:21 PM
> > > To: jdk-updates-dev at openjdk.java.net
> > > Subject: [11u] RFR(M): 8213250: CDS archive creation aborts due to
> > > metaspace object allocation failure
> > >
> > > Hi
> > >
> > > I would like to downport this [1] for parity with 11.0.8-oracle.
> > >
> > > I had to resolve because in one context the InstandeKlass/Klass type differs.
> > >
> > > Further the change depends on some previous changes in jdk/jdk.
> > > I had to do the following changes in systemDictionaryShared.cpp:
> > >
> > > Because [2] "8209645: Split ClassLoaderData and ClassLoaderDataGraph into
> > > separate files"
> > > is not in 11, the include of ClassLoaderDataGraph.hpp is not needed.
> > >
> > > I had to undo the effects of [3] "8209301: JVM rename is_anonymous,
> > > host_klass to
> > > unsafe specific terminology ahead of Unsafe.defineAnonymousClass
> > > deprecation":
> > > is_unsafe_anonymous() --> is_anonymous()
> > >
> > > The new SystemDictionaryShared::finalize_verification_constraints() locks
> > > the
> > > ClassLoaderDataGraph_lock. This lock was introduced by [4] "8210155: Lock
> > > ClassLoaderDataGraph Summary: In preparation for concurrent class
> > > unloading." and
> > > is not in 11. As I understand, 11 has no concurrent class loading, so this is not
> > > needed.
> > > Removed.
> > >
> > > This webrev shows the edits I did after applying the change:
> > > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01-
> > > edits/
> > >
> > > This is the resulting webrev:
> > > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-jdk11/01/
> > >
> > > Please review.
> > >
> > > Best regards,
> > >   Goetz.
> > >
> > > [1]
> > > Original bug:
> > > https://bugs.openjdk.java.net/browse/JDK-8213250
> > > http://hg.openjdk.java.net/jdk/jdk/rev/e0fd97beab7e
> > > [2]
> > > 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate files
> > > https://bugs.openjdk.java.net/browse/JDK-8209645
> > > http://hg.openjdk.java.net/jdk/jdk/rev/db0c3952de52
> > > [3]
> > > 8209301: JVM rename is_anonymous, host_klass to unsafe specific
> > > terminology ahead
> > > of Unsafe.defineAnonymousClass deprecation
> > > https://bugs.openjdk.java.net/browse/JDK-8209301
> > > http://hg.openjdk.java.net/jdk/jdk/rev/3e5d28e6de32
> > > [4]
> > > 8210155: Lock ClassLoaderDataGraph Summary: In preparation for concurrent
> > > class unloading
> > > https://bugs.openjdk.java.net/browse/JDK-8210155
> > > http://hg.openjdk.java.net/jdk/jdk/rev/625a5bdde0c5
> > >
> > >
> >

From Junyuan.Zheng at microsoft.com  Sat Mar 21 04:56:56 2020
From: Junyuan.Zheng at microsoft.com (Junyuan Zheng)
Date: Sat, 21 Mar 2020 04:56:56 +0000
Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
 or older
In-Reply-To: <AM0PR02MB571453669CA8951741C755F38AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <MWHPR21MB083096C1F557DF9983FF34AFE3F60@MWHPR21MB0830.namprd21.prod.outlook.com>,
 <AM0PR02MB571453669CA8951741C755F38AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <MWHPR21MB083070A37BB9B00584D7E92DE3F20@MWHPR21MB0830.namprd21.prod.outlook.com>

Hi Christoph,

Thank you for reviewing this! I will check jdk14u code and create another patch.

Sincerely,

Junyuan

________________________________________
From: Langer, Christoph <christoph.langer at sap.com>
Sent: Wednesday, March 18, 2020 1:05 PM
To: Junyuan Zheng; jdk-updates-dev at openjdk.java.net
Subject: RE: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5 or older

Hi Junyuan,

I think this looks good. I can approve&sponsor this for you. I think we want to get this into jdk14u as well.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Junyuan Zheng
> Sent: Dienstag, 17. M?rz 2020 19:22
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
> or older
>
> Hi,
>
> I would like to backport JDK-8240972
> ("macOS codesign fail on macOS 10.13.5 or older") to 11u.
>
> The original patch cannot be applied to 11u directly because of the change
> JDK-8239708 (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8239708&amp;data=02%7C01%7CJunyuan.Zheng%40microsoft.com%7Cfa3c24116cbe44e9c2cd08d7cb77d3e9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637201587835476295&amp;sdata=PZPabAz5YweihzLxc4yh4%2BgtKbW3528k86BrTgevjLg%3D&amp;reserved=0).
>
> And here is the diff based on the current code:
>
> ```
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -1228,12 +1228,25 @@
> AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
>        AC_MSG_CHECKING([if codesign certificate is present])
>        $RM codesign-testfile
>        $TOUCH codesign-testfile
> -      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD \
> +          >&AS_MESSAGE_LOG_FD || CODESIGN=
>        $RM codesign-testfile
>        if test "x$CODESIGN" = x; then
>          AC_MSG_RESULT([no])
>        else
>          AC_MSG_RESULT([yes])
> +        # Verify that the codesign has --option runtime
> +        AC_MSG_CHECKING([if codesign has --option runtime])
> +        $RM codesign-testfile
> +        $TOUCH codesign-testfile
> +        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY"
> codesign-testfile \
> +            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +        $RM codesign-testfile
> +        if test "x$CODESIGN" = x; then
> +          AC_MSG_ERROR([codesign does not have --option runtime. macOS
> 10.13.6 and above is required.])
> +        else
> +          AC_MSG_RESULT([yes])
> +        fi
>        fi
>      fi
>      BASIC_REQUIRE_PROGS(SETFILE, SetFile)
> ```
>
> I also need a sponsor for this patch. Please let me know what you think.
>
> Thanks,
>
> Junyuan

From aph at redhat.com  Sat Mar 21 09:52:43 2020
From: aph at redhat.com (Andrew Haley)
Date: Sat, 21 Mar 2020 09:52:43 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
Message-ID: <df47b971-1d43-70ff-ee98-9d572ebdeda7@redhat.com>

On 3/21/20 5:22 AM, Gil Tene wrote:
> The backport there may very well end up being close to what we'd want for
> 11u, but I certainly wouldn't want to just take this bulk stuff from
> graalvm/labs-openjdk-11 and assume that is was well though through for
> handling non-Graal use modes (which are the main concern for
> OpenJDK 11u, and probably of no significant concern to the Graal project).

That's right. As discussed when we met the Graal people in Zurich last
year, it is a goal to do the work necessary to support Graal on
OpenJDK 11 rather than Labs JDK 11. That requires some changes to
JVMCI. Does it require Graal itself to be updated? Does the Graal build
use the Graal that's in the JDK for anything?

OpenJDK 11 itself must be protected, so it may be necessary to produce
a Graal fork of OpenJDK 11 if these goals conflict. This is, I
believe, the situation with Oracle: they have a separate version of
the JDK, Labs JDK 11.

I'll get some of the Red Hat people who know more about this stuff
than me to weigh in.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From denghui.ddh at alibaba-inc.com  Sat Mar 21 11:55:21 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Sat, 21 Mar 2020 19:55:21 +0800
Subject: =?UTF-8?B?UmU6IFsxMXVdIFtKRlJdIFJGUihYWEwpIDgyMjY1MTE6IEltcGxlbWVudCBKRlIgRXZlbnQg?=
 =?UTF-8?B?U3RyZWFtaW5n?=
In-Reply-To: <CAGw=733SUDHhqxRQxkp4kGFLeep5Kvp2ZrGYyBw4Qgc2zvbvwg@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>,
 <CAGw=733SUDHhqxRQxkp4kGFLeep5Kvp2ZrGYyBw4Qgc2zvbvwg@mail.gmail.com>
Message-ID: <f6bba337-ee36-414e-ba80-780611511926.denghui.ddh@alibaba-inc.com>

Hi Ben,

You can apply the patch to 11u directly.

And if you want to test JFR Streaming on 8u, I can provide
the patchset(includes some prerequisite fixes).

Thanks,
Denghui Dong

------------------------------------------------------------------
From:Ben Evans <bevans at newrelic.com>
Send Time:2020?3?21?(???) 00:06
To:???(??) <denghui.ddh at alibaba-inc.com>; Martijn Verburg <martijn.verburg at microsoft.com>
Cc:jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Subject:Re: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming

Hi Denghui,

This looks very interesting - thanks for your work so far. 

How can we get started with it? Could we follow a similar model that used to backport JFR (file) to OpenJDK 8 - by starting with a separate repo?

Martijn - how difficult would it be to have AdoptOpenJDK build binaries from a separate 11u-jfr-streaming repo, if we were to do that?

Cheers,

Ben
On Thu, Mar 19, 2020 at 7:15 AM Denghui Dong <denghui.ddh at alibaba-inc.com> wrote:
Hi team,

 JDK 14 is now Generally Available, as one of the features, JFR Event Streaming is very attractive for us.

 With JFR Event Streaming, we can more easily implement the continuous monitoring of Java application based on JFR in the container environment.

 So I would like to backport JDK-8226511(Implement JFR Event Streaming) to 11u, please help us to review the patch.

 Previously, we had a discussion at https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html, there are many companies interested in this

 Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
 Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
 Test (release/slow-debug on Linux): All JFR Event Streaming passed, and other JFR tests have the same result with the build without this patch

 The original patch is large, and cannot be applied to 11u directly
 All files that cannot be derectly applied are as follows:
     src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
     src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't exist in 11u)
     test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java (dosn't exist in 11u, introduced in JDK-8213914)
     src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
     src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
     src/jdk.jfr/share/conf/jfr/profile.jfc
     src/jdk.jfr/share/conf/jfr/default.jfc
     src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
     src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
     src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
     src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
     src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
     src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
     src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp (ClassLoaderDataGraph_lock doesn't exist in 11u)
     src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
     src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
     src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
     src/hotspot/share/jfr/utilities/jfrTypes.hpp
     src/hotspot/share/jfr/support/jfrThreadLocal.cpp
     src/hotspot/share/jfr/metadata/metadata.xml
     src/hotspot/share/runtime/mutexLocker.cpp
   test/jdk/ProblemList.txt

 Also, we want to backport some other related issues to 11u:
     JDK-8233700: EventStream not closed
     JDK-8229209: test for cross-process JFR event streaming
     JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should clean up files
     JDK-8234684: JFR crashes when rotating the JFR output during assertion failure
     JDK-8233870: JFR TestSetEndTime.java times out - onClose() is never called
     JDK-8234888: EventStream::close doesn't abort streaming thread 
     JDK-8234671: JFR api/consumer/recordingstream/TestStart.java failed due to timeout at testStartTwice()
     JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR TestCrossProcessStreaming
     JDK-8233111: Epoch shift synchronization point for Compiler threads
     JDK-8234059: Stress test fails with "Unexpected Exception in thread JFR Event Stream"
     JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and jdk.jfr.Recording::getFlushInterval
     JDK-8236263: Remove experimental streaming events
 Most of them can directly apply to 11u, except 8233111, 8234059 and 8236263

 Cheers,
 Denghui Dong

From christoph.langer at sap.com  Sun Mar 22 06:24:05 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Sun, 22 Mar 2020 06:24:05 +0000
Subject: tag jdk-14-ga in jdk14u repository
Message-ID: <AM0PR02MB5714AD7EDC33685590D6255A8AF30@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Rob,

as per [0] and with changeset [1], the jdk/jdk14 repo has been tagged "jdk-14-ga". Could you please merge this tag into jdk-updates/jdk14u as well? That would allow to build the JDK14 GA level from jdk14u by hg upping to that tag.

Thanks,
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004091.html
[1] http://hg.openjdk.java.net/jdk/jdk14/rev/6c954123ee8d


From goetz.lindenmaier at sap.com  Mon Mar 23 08:16:23 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 23 Mar 2020 08:16:23 +0000
Subject: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from "8221882:
 Use fiber-friendly java.util.concurrent.locks in JSSE"
In-Reply-To: <ce1bac3d-6451-b625-747f-3e668d0e64c1@redhat.com>
References: <AM7PR02MB60490D98905F9AFA21177E70ECFF0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <e8bb57a9-76b3-0895-89e7-d5440b1f2fb6@redhat.com>
 <AM7PR02MB6049F54BA80FD9FC0742AB59ECF70@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <ce1bac3d-6451-b625-747f-3e668d0e64c1@redhat.com>
Message-ID: <AM7PR02MB6049483E3B0EA2A40383AE30ECF00@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Martin, 

As the lock in OutputRecurd is public, I'd assumed I recursively
pull in the whole change.  But I didn't check as I did not want to 
pull in OutputRecord either.

Best regards,
  Goetz.

> -----Original Message-----
> From: Martin Balao <mbalao at redhat.com>
> Sent: Wednesday, March 18, 2020 3:15 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: 11u: RFR[M]: 8240827: Downport SSLSocketImpl.java from
> "8221882: Use fiber-friendly java.util.concurrent.locks in JSSE"
> 
> On 3/18/20 8:15 AM, Lindenmaier, Goetz wrote:
> > Taking the whole change to 11 seems too risky to me.
> 
> I didn't mean the whole patch -which I agree that seems too risky- but
> the OutputRecord part (so OutputRecord.java and SSLSocketImpl.java files
> do not need to be modified again when backporting the rest of 8221882).
> 
> Thanks,
> Martin.-


From goetz.lindenmaier at sap.com  Mon Mar 23 10:36:05 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 23 Mar 2020 10:36:05 +0000
Subject: ping: [11u] RFR(M): 8213250: CDS archive creation aborts due to
 metaspace object allocation failure
In-Reply-To: <CALrW1jwBq+uV86mgEAdSRfrStF=gduLNrm3cnn4kPBwCvy3f0g@mail.gmail.com>
References: <AM7PR02MB6049E62A18DDEAEA071A0B76ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <CALrW1jx2uMafg++F01B7TdXKeok83B_MQyV63aYpsiEp=Uo+cw@mail.gmail.com>
 <CALrW1jwBq+uV86mgEAdSRfrStF=gduLNrm3cnn4kPBwCvy3f0g@mail.gmail.com>
Message-ID: <AM7PR02MB6049987C30EC7CEE360CB7C7ECF00@AM7PR02MB6049.eurprd02.prod.outlook.com>

Thanks Jiangli!

Best regards,
  Goetz.

> -----Original Message-----
> From: Jiangli Zhou <jianglizhou at google.com>
> Sent: Saturday, March 21, 2020 1:59 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: ping: [11u] RFR(M): 8213250: CDS archive creation aborts due to
> metaspace object allocation failure
> 
> On Thu, Mar 19, 2020 at 12:25 PM Jiangli Zhou <jianglizhou at google.com>
> wrote:
> >
> > Hi Goetz,
> >
> > The backport looks good to me. I will also run some tests on my side
> > for the backport. Will report back to you.
> 
> Testing from my side looks good. Thanks!
> 
> Best regards,
> Jiangli
> 
> >
> > Best,
> > Jiangli
> >
> > On Thu, Mar 19, 2020 at 6:51 AM Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com> wrote:
> > >
> > > Hi,
> > >
> > > Could I please get a review for this downport?
> > >
> > > Thanks!
> > >   Goetz
> > >
> > > > -----Original Message-----
> > > > From: Lindenmaier, Goetz
> > > > Sent: Friday, March 13, 2020 3:21 PM
> > > > To: jdk-updates-dev at openjdk.java.net
> > > > Subject: [11u] RFR(M): 8213250: CDS archive creation aborts due to
> > > > metaspace object allocation failure
> > > >
> > > > Hi
> > > >
> > > > I would like to downport this [1] for parity with 11.0.8-oracle.
> > > >
> > > > I had to resolve because in one context the InstandeKlass/Klass type
> differs.
> > > >
> > > > Further the change depends on some previous changes in jdk/jdk.
> > > > I had to do the following changes in systemDictionaryShared.cpp:
> > > >
> > > > Because [2] "8209645: Split ClassLoaderData and ClassLoaderDataGraph
> into
> > > > separate files"
> > > > is not in 11, the include of ClassLoaderDataGraph.hpp is not needed.
> > > >
> > > > I had to undo the effects of [3] "8209301: JVM rename is_anonymous,
> > > > host_klass to
> > > > unsafe specific terminology ahead of Unsafe.defineAnonymousClass
> > > > deprecation":
> > > > is_unsafe_anonymous() --> is_anonymous()
> > > >
> > > > The new SystemDictionaryShared::finalize_verification_constraints()
> locks
> > > > the
> > > > ClassLoaderDataGraph_lock. This lock was introduced by [4] "8210155:
> Lock
> > > > ClassLoaderDataGraph Summary: In preparation for concurrent class
> > > > unloading." and
> > > > is not in 11. As I understand, 11 has no concurrent class loading, so this is
> not
> > > > needed.
> > > > Removed.
> > > >
> > > > This webrev shows the edits I did after applying the change:
> > > > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-
> jdk11/01-
> > > > edits/
> > > >
> > > > This is the resulting webrev:
> > > > http://cr.openjdk.java.net/~goetz/wr20/8213250-CDS_aborts-
> jdk11/01/
> > > >
> > > > Please review.
> > > >
> > > > Best regards,
> > > >   Goetz.
> > > >
> > > > [1]
> > > > Original bug:
> > > > https://bugs.openjdk.java.net/browse/JDK-8213250
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/e0fd97beab7e
> > > > [2]
> > > > 8209645: Split ClassLoaderData and ClassLoaderDataGraph into separate
> files
> > > > https://bugs.openjdk.java.net/browse/JDK-8209645
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/db0c3952de52
> > > > [3]
> > > > 8209301: JVM rename is_anonymous, host_klass to unsafe specific
> > > > terminology ahead
> > > > of Unsafe.defineAnonymousClass deprecation
> > > > https://bugs.openjdk.java.net/browse/JDK-8209301
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/3e5d28e6de32
> > > > [4]
> > > > 8210155: Lock ClassLoaderDataGraph Summary: In preparation for
> concurrent
> > > > class unloading
> > > > https://bugs.openjdk.java.net/browse/JDK-8210155
> > > > http://hg.openjdk.java.net/jdk/jdk/rev/625a5bdde0c5
> > > >
> > > >
> > >

From shade at redhat.com  Mon Mar 23 10:39:42 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Mar 2020 11:39:42 +0100
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <AM0PR02MB5714F1B4C8128EF5FAF5E8F08AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
 <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
 <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>
 <AM0PR02MB5714F1B4C8128EF5FAF5E8F08AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <3174b10c-aa0a-7b65-b889-717e84e71b48@redhat.com>

On 3/18/20 8:56 PM, Langer, Christoph wrote:
> I just approved the backport for 11u. Andrew, I assume you'll want to sponsor it?

I'll go talk to Andrew about this. If anything, I could sponsor it.

-- 
Thanks,
-Aleksey


From bevans at newrelic.com  Mon Mar 23 11:00:28 2020
From: bevans at newrelic.com (Ben Evans)
Date: Mon, 23 Mar 2020 12:00:28 +0100
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
Message-ID: <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>

Hi Mario,

I think we're all in agreement about stability and ensuring that there are
no performance regressions.

I was thinking that we could adopt the model that you used for the regular
JFR backport to OpenJDK 8 - starting off in a separate repo that can be
built by Adopt and consumed by enthusiasts that want to try it out. Do you
have any concerns about that? It seemed to work very well for that project
- and I would want to use the same sort of caution for Streaming-to-11.

Andrew / Christoph / Severin: What would we need to do to get a separate
repo for Ali Baba / Microsoft / New Relic / AdoptOpenJDK / other interested
parties to investigate in further?

Thanks,

Ben


On Sat, Mar 21, 2020 at 1:52 AM Mario Torre <neugens.limasoftware at gmail.com>
wrote:

> I agree, while this is certainly an interesting feature, we should
> probably let it bake a bit.
>
> I'm particularly concerned about stability and performance here.
>
> Cheers,
> Mario
>
> Il giorno gio 19 mar 2020 alle ore 12:24 Erik Gahlin
> <erik.gahlin at oracle.com> ha scritto:
>
> >
> > Hi,
> >
> > JDK 14 has been out for one day and few have used it in production. The
> > feature changes core aspects of the JFR implementation, such as the
> > tagging mechanism and the parser. Event streaming is not something that
> > can be turned on by an API call or a command line flag, it is always
> > there. If there are bugs, it will likely impact ordinary use of JFR as
> well.
> >
> > Erik
> >
> > > Hi team,
> > >
> > > JDK 14 is now Generally Available, as one of the features, JFR Event
> Streaming is very attractive for us.
> > >
> > > With JFR Event Streaming, we can more easily implement the continuous
> monitoring of Java application based on JFR in the container environment.
> > >
> > > So I would like to backport JDK-8226511(Implement JFR Event Streaming)
> to 11u, please help us to review the patch.
> > >
> > > Previously, we had a discussion at
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html,
> there are many companies interested in this
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> > > Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> > > Test (release/slow-debug on Linux): All JFR Event Streaming passed,
> and other JFR tests have the same result with the build without this patch
> > >
> > > The original patch is large, and cannot be applied to 11u directly
> > > All files that cannot be derectly applied are as follows:
> > >      src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
> > >      src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't
> exist in 11u)
> > >      test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java
> (dosn't exist in 11u, introduced in JDK-8213914)
> > >      src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
> > >      src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
> > >      src/jdk.jfr/share/conf/jfr/profile.jfc
> > >      src/jdk.jfr/share/conf/jfr/default.jfc
> > >      src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
> > >      src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
> > >      src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> > >      src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
> > >      src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
> > >      src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
> > >
> src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
> (ClassLoaderDataGraph_lock doesn't exist in 11u)
> > >      src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
> > >
> src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
> > >      src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
> > >      src/hotspot/share/jfr/utilities/jfrTypes.hpp
> > >      src/hotspot/share/jfr/support/jfrThreadLocal.cpp
> > >      src/hotspot/share/jfr/metadata/metadata.xml
> > >      src/hotspot/share/runtime/mutexLocker.cpp
> > >    test/jdk/ProblemList.txt
> > >
> > > Also, we want to backport some other related issues to 11u:
> > >      JDK-8233700: EventStream not closed
> > >      JDK-8229209: test for cross-process JFR event streaming
> > >      JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should
> clean up files
> > >      JDK-8234684: JFR crashes when rotating the JFR output during
> assertion failure
> > >      JDK-8233870: JFR TestSetEndTime.java times out - onClose() is
> never called
> > >      JDK-8234888: EventStream::close doesn't abort streaming thread
> > >      JDK-8234671: JFR api/consumer/recordingstream/TestStart.java
> failed due to timeout at testStartTwice()
> > >      JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR
> TestCrossProcessStreaming
> > >      JDK-8233111: Epoch shift synchronization point for Compiler
> threads
> > >      JDK-8234059: Stress test fails with "Unexpected Exception in
> thread JFR Event Stream"
> > >      JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and
> jdk.jfr.Recording::getFlushInterval
> > >      JDK-8236263: Remove experimental streaming events
> > > Most of them can directly apply to 11u, except 8233111, 8234059 and
> 8236263
> > >
> > > Cheers,
> > > Denghui Dong
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>

From neugens at redhat.com  Mon Mar 23 11:25:54 2020
From: neugens at redhat.com (Mario Torre)
Date: Mon, 23 Mar 2020 12:25:54 +0100
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
Message-ID: <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>

Hi Ben!

Of course I don't have concerns about people trying out things ;)
However regarding having an approach similar to JFR in 8u I'm a bit
more concerned, since the JFR patch had time to bake in and gave us a
chance to fix issues. The streaming API is rather new and changes a
lot of the internal, so we need to give it a bit of time to understand
it.

Personally, I need to study the code and see how having this
implementation may affect backporting of fixes, but my take in general
is that we had to backport JFR because this was a critical missing
feature, but backporting every new feature to 8 or 11 is not
advisable.

I know I said previously that I would have liked to see the streaming
backported, but the level of work required by the JFR backport has
made me change my mind, I think we need to give a chance to JFR in 8u
to be out in the wild for a bit before changing the implementation
again. I'm considering that even if we are talking about 11 here, the
change will most likely apply to 8u as well.

Anyway, this is just my thinking, I'm not trying to veto the change,
we should have a general agreement on what we want to do, if the
maintainers decide this is worth the effort I'll certainly try to help
like I did with the JFR backport.

Cheers,
Mario

On Mon, Mar 23, 2020 at 12:01 PM Ben Evans <bevans at newrelic.com> wrote:
>
> Hi Mario,
>
> I think we're all in agreement about stability and ensuring that there are
> no performance regressions.
>
> I was thinking that we could adopt the model that you used for the regular
> JFR backport to OpenJDK 8 - starting off in a separate repo that can be
> built by Adopt and consumed by enthusiasts that want to try it out. Do you
> have any concerns about that? It seemed to work very well for that project
> - and I would want to use the same sort of caution for Streaming-to-11.
>
> Andrew / Christoph / Severin: What would we need to do to get a separate
> repo for Ali Baba / Microsoft / New Relic / AdoptOpenJDK / other interested
> parties to investigate in further?
>
> Thanks,
>
> Ben
>
>
> On Sat, Mar 21, 2020 at 1:52 AM Mario Torre <neugens.limasoftware at gmail.com>
> wrote:
>
> > I agree, while this is certainly an interesting feature, we should
> > probably let it bake a bit.
> >
> > I'm particularly concerned about stability and performance here.
> >
> > Cheers,
> > Mario
> >
> > Il giorno gio 19 mar 2020 alle ore 12:24 Erik Gahlin
> > <erik.gahlin at oracle.com> ha scritto:
> >
> > >
> > > Hi,
> > >
> > > JDK 14 has been out for one day and few have used it in production. The
> > > feature changes core aspects of the JFR implementation, such as the
> > > tagging mechanism and the parser. Event streaming is not something that
> > > can be turned on by an API call or a command line flag, it is always
> > > there. If there are bugs, it will likely impact ordinary use of JFR as
> > well.
> > >
> > > Erik
> > >
> > > > Hi team,
> > > >
> > > > JDK 14 is now Generally Available, as one of the features, JFR Event
> > Streaming is very attractive for us.
> > > >
> > > > With JFR Event Streaming, we can more easily implement the continuous
> > monitoring of Java application based on JFR in the container environment.
> > > >
> > > > So I would like to backport JDK-8226511(Implement JFR Event Streaming)
> > to 11u, please help us to review the patch.
> > > >
> > > > Previously, we had a discussion at
> > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html,
> > there are many companies interested in this
> > > >
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> > > > Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> > > > Test (release/slow-debug on Linux): All JFR Event Streaming passed,
> > and other JFR tests have the same result with the build without this patch
> > > >
> > > > The original patch is large, and cannot be applied to 11u directly
> > > > All files that cannot be derectly applied are as follows:
> > > >      src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
> > > >      src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't
> > exist in 11u)
> > > >      test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java
> > (dosn't exist in 11u, introduced in JDK-8213914)
> > > >      src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
> > > >      src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
> > > >      src/jdk.jfr/share/conf/jfr/profile.jfc
> > > >      src/jdk.jfr/share/conf/jfr/default.jfc
> > > >      src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
> > > >      src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
> > > >      src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> > > >      src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
> > > >      src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
> > > >      src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
> > > >
> > src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
> > (ClassLoaderDataGraph_lock doesn't exist in 11u)
> > > >      src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
> > > >
> > src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
> > > >      src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
> > > >      src/hotspot/share/jfr/utilities/jfrTypes.hpp
> > > >      src/hotspot/share/jfr/support/jfrThreadLocal.cpp
> > > >      src/hotspot/share/jfr/metadata/metadata.xml
> > > >      src/hotspot/share/runtime/mutexLocker.cpp
> > > >    test/jdk/ProblemList.txt
> > > >
> > > > Also, we want to backport some other related issues to 11u:
> > > >      JDK-8233700: EventStream not closed
> > > >      JDK-8229209: test for cross-process JFR event streaming
> > > >      JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should
> > clean up files
> > > >      JDK-8234684: JFR crashes when rotating the JFR output during
> > assertion failure
> > > >      JDK-8233870: JFR TestSetEndTime.java times out - onClose() is
> > never called
> > > >      JDK-8234888: EventStream::close doesn't abort streaming thread
> > > >      JDK-8234671: JFR api/consumer/recordingstream/TestStart.java
> > failed due to timeout at testStartTwice()
> > > >      JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR
> > TestCrossProcessStreaming
> > > >      JDK-8233111: Epoch shift synchronization point for Compiler
> > threads
> > > >      JDK-8234059: Stress test fails with "Unexpected Exception in
> > thread JFR Event Stream"
> > > >      JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and
> > jdk.jfr.Recording::getFlushInterval
> > > >      JDK-8236263: Remove experimental streaming events
> > > > Most of them can directly apply to 11u, except 8233111, 8234059 and
> > 8236263
> > > >
> > > > Cheers,
> > > > Denghui Dong
> >
> >
> >
> > --
> > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> >
> > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > Proud GNU Classpath developer: http://www.classpath.org/
> > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> >
> > Please, support open standards:
> > http://endsoftpatents.org/
> >
>


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From snazy at gmx.de  Thu Mar 12 08:41:58 2020
From: snazy at gmx.de (Robert Stupp)
Date: Thu, 12 Mar 2020 09:41:58 +0100
Subject: Help requested, backport 8240629 to 11u + 14u
Message-ID: <b60a6c5bb22b973906f186bbd420230f946bf9b7.camel@gmx.de>

Hi,

backporting JDK-8240629 ("argfiles parsing broken for argfiles with
comment cross 4096 bytes chunk") to 11u + 14u is trivial. The attached
patch file applies cleanly to current jdk-updates/jdk11u + jdk-
updates/jdk14u (no changes to the patch) and tests pass locally.

I could need some help (no JBS acount) to get the patch backported to
11u + 14u.

Cheers,
Robert

References:
https://hg.openjdk.java.net/jdk/jdk/rev/79371dab85c2
https://bugs.openjdk.java.net/browse/JDK-8240629

patch file exported using 'hg export -r 58311:79371dab85c2 --git >
8240629.patch' + imported into my 11u+14u clones via qimport/qpush.



11u tests:


make run-test TEST=tier1

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL
ERROR
   jtreg:test/hotspot/jtreg:tier1                     1297  1297     0
    0
   jtreg:test/jdk:tier1                               1860  1860     0
    0
   jtreg:test/langtools:tier1                         3902  3902     0
    0
   jtreg:test/nashorn:tier1                              0     0     0
    0
   jtreg:test/jaxp:tier1                                 0     0     0
    0
==============================
TEST SUCCESS




make run-test TEST=test/jdk/tools/launcher

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL
ERROR
   jtreg:test/jdk/tools/launcher                        56    56     0
    0
==============================
TEST SUCCESS




14u tests:

make run-test TEST=tier1

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL
ERROR
   jtreg:test/hotspot/jtreg:tier1                     1471  1471     0
    0
   jtreg:test/jdk:tier1                               1899  1899     0
    0
   jtreg:test/langtools:tier1                         4020  4020     0
    0
   jtreg:test/nashorn:tier1                              0     0     0
    0
   jtreg:test/jaxp:tier1                                 0     0     0
    0
==============================
TEST SUCCESS




make run-test TEST=test/jdk/tools/launcher

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jdk/tools/launcher                        57    57     0     0
==============================
TEST SUCCESS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8240629.patch
Type: text/x-patch
Size: 3741 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jdk-updates-dev/attachments/20200312/551e772d/8240629-0001.patch>

From christoph.langer at sap.com  Fri Mar 13 15:10:36 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 13 Mar 2020 15:10:36 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>,
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
Message-ID: <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Gil,

> -----Original Message-----
> From: Gil Tene <gil at azul.com>
> Sent: Freitag, 13. M?rz 2020 15:31
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: Andrew Hughes <gnu.andrew at redhat.com>; jdk-updates-
> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
> <doug.simon at oracle.com>; Tom Rodriguez <tom.rodriguez at oracle.com>;
> Volker Simonis <volker.simonis at gmail.com>
> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
> 
> 
> 
> Sent from my iPad
> 
> > On Mar 13, 2020, at 1:04 AM, Langer, Christoph
> <christoph.langer at sap.com> wrote:
> >
> > ?Hi Andrew, all,
> >
> >> -----Original Message-----
> >> From: Andrew Hughes <gnu.andrew at redhat.com>
> >> Sent: Donnerstag, 12. M?rz 2020 19:27
> >> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> >> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
> >> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
> >> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
> >> <doug.simon at oracle.com>; Tom Rodriguez
> <tom.rodriguez at oracle.com>;
> >> Volker Simonis <volker.simonis at gmail.com>
> >> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
> >>
> >>
> >>
> >>> On 12/03/2020 12:03, Langer, Christoph wrote:
> >>> Hi all,
> >>>
> >>> as you may or may not know, the GraalVM Community Edition (CE)
> >> supports OpenJDK 11 update releases. In order to do that, there exists a
> >> clone of the OpenJDK repository in the GraalVM GitHub space [0]. This
> fork,
> >> however, contains several additional patches, obviously mainly in the area
> of
> >> JVMCI and the Graal compiler. There seems to be a certain interest of the
> >> involved parties, that is, the GraalVM community, Oracle Labs and
> probably
> >> also the OpenJDK community, to keep these repositories as close as
> possible.
> >>>
> >>> One motivation could be to allow building of GraalVM native images
> from
> >> OpenJDK distributions, such as mentioned in a GitHub issue raised against
> >> the graal project [1].
> >>>
> >>> Another motivation probably comes from the Graal community to
> reduce
> >> the maintenance effort from merging the OpenJDK changes.
> >>>
> >>> Furthermore, it has been policy in the OpenJDK 11 Updates project to try
> to
> >> follow what Oracle is doing in their JDK 11 LTS update releases. Lately,
> there
> >> obviously have been backports for JVMCI and Graal which completely
> don't
> >> match with the current state of OpenJDK 11u. When researching this I
> >> learned that the prerequisite of these kind of changes is a larger update
> of
> >> JVMCI and Graal. The basis for this change could be a commit from the
> labs-
> >> openjdk-11 Graal repository [2]. This would update JVMCI and Graal to
> the
> >> state of OpenJDK 13. More details can be taken out of the conversation of
> >> the GitHub issue [1].
> >>>
> >>> I took this change, applied it to OpenJDK 11u-dev, resolved some
> conflicts
> >> and made sure it builds on all platforms (that we support in the SAP
> team). A
> >> prerequisite would also be a backport of JDK-8208686, at least the hotspot
> >> part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are
> >> contained in [3]. With this work applied, regression testing looks quite
> >> promising. There are a few test failures in the NMT area, some crashes
> with
> >> aot and a few minor Graal related test errors, but nothing that couldn't be
> >> solved with too much of effort, I guess. But I can't make any judgement
> on
> >> the state of the Graal compiler itself, since we don't have much test
> coverage
> >> for that in our infrastructure.
> >>>
> >>> However, the main point for me is to get a discussion started. First of all
> it is
> >> about whether we want to have this kind of update at all in OpenJDK 11
> >> Updates? If so, I'd need some help by people with expertise and test
> >> infrastructure for the Graal related part. That's nothing we can cover in
> the
> >> SAP team right now. If we decide against this update, we'll have give up
> our
> >> policy about following the Oracle 11 Updates for JVMCI/Graal.
> >>>
> >>> Looking forward to get input about this.
> >>>
> >>> Thanks and best regards
> >>> Christoph
> >>>
> >>> [0] https://github.com/graalvm/labs-openjdk-11/
> >>> [1] https://github.com/oracle/graal/issues/2196
> >>> [2] https://github.com/graalvm/labs-openjdk-
> >> 11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
> >>> [3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
> >>> [4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
> >>>
> >>
> >> I'm aware of these changes for Graal and have been working on getting
> >> some of them into OpenJDK 11u.
> >>
> >> I don't think we should just apply these monolithic commits, but instead
> >> work out the relevant issues in OpenJDK 13 being backported and do it
> >> correctly. We want 11u to be as maintainable as possible.
> >
> > I've got some sympathy with that approach. We can certainly have a look to
> identify the single changes and try to apply them one by one... It'll probably
> also help to identify the sources of regressions when we run into some.
> >
> > But, the general question that needs to be answered before is: Do we
> want this to happen at all? Any opinions/thoughts?
> 
> Can you elaborate on what we believe the Oracle 11u has done so far on this
> matter?

In short, I believe Graal and JVMCI in Oracle 11u was updated to the JDK13 level. And from there on further patches have been backported.

The Graal/JVMCI update as a monolith would probably look like this: https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d.
And additional backports come on top, like most of the 23 items left in this query: https://bugs.openjdk.java.net/issues/?filter=37811 

Best regards
Christoph


From ivan.gerasimov at oracle.com  Fri Mar 20 07:19:40 2020
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 20 Mar 2020 00:19:40 -0700
Subject: [14-dev] RFR : (dc) MulticastSendReceiveTests.java failing with
 ENOMEM when joining group (OS X 10.9)
Message-ID: <3b7c4deb-223b-2134-092b-8c3df35c1423@oracle.com>

Hello!

An OOM error is intermittently observed on MacOS when joining a 
multicast group.

A workaround was implemented as part of the fix for JDK-8236925.

It is proposed to backport a portion of that fix, which helps to 
mitigate the issue on MacOS.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8044365
WEBREV: http://cr.openjdk.java.net/~igerasim/8044365/00/webrev/

Mach5 control build in progress.

-- 
With kind regards,
Ivan Gerasimov


From gil at azul.com  Fri Mar 13 14:30:36 2020
From: gil at azul.com (Gil Tene)
Date: Fri, 13 Mar 2020 14:30:36 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>,
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>



Sent from my iPad

> On Mar 13, 2020, at 1:04 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> ?Hi Andrew, all,
> 
>> -----Original Message-----
>> From: Andrew Hughes <gnu.andrew at redhat.com>
>> Sent: Donnerstag, 12. M?rz 2020 19:27
>> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
>> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
>> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
>> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
>> <doug.simon at oracle.com>; Tom Rodriguez <tom.rodriguez at oracle.com>;
>> Volker Simonis <volker.simonis at gmail.com>
>> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
>> 
>> 
>> 
>>> On 12/03/2020 12:03, Langer, Christoph wrote:
>>> Hi all,
>>> 
>>> as you may or may not know, the GraalVM Community Edition (CE)
>> supports OpenJDK 11 update releases. In order to do that, there exists a
>> clone of the OpenJDK repository in the GraalVM GitHub space [0]. This fork,
>> however, contains several additional patches, obviously mainly in the area of
>> JVMCI and the Graal compiler. There seems to be a certain interest of the
>> involved parties, that is, the GraalVM community, Oracle Labs and probably
>> also the OpenJDK community, to keep these repositories as close as possible.
>>> 
>>> One motivation could be to allow building of GraalVM native images from
>> OpenJDK distributions, such as mentioned in a GitHub issue raised against
>> the graal project [1].
>>> 
>>> Another motivation probably comes from the Graal community to reduce
>> the maintenance effort from merging the OpenJDK changes.
>>> 
>>> Furthermore, it has been policy in the OpenJDK 11 Updates project to try to
>> follow what Oracle is doing in their JDK 11 LTS update releases. Lately, there
>> obviously have been backports for JVMCI and Graal which completely don't
>> match with the current state of OpenJDK 11u. When researching this I
>> learned that the prerequisite of these kind of changes is a larger update of
>> JVMCI and Graal. The basis for this change could be a commit from the labs-
>> openjdk-11 Graal repository [2]. This would update JVMCI and Graal to the
>> state of OpenJDK 13. More details can be taken out of the conversation of
>> the GitHub issue [1].
>>> 
>>> I took this change, applied it to OpenJDK 11u-dev, resolved some conflicts
>> and made sure it builds on all platforms (that we support in the SAP team). A
>> prerequisite would also be a backport of JDK-8208686, at least the hotspot
>> part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are
>> contained in [3]. With this work applied, regression testing looks quite
>> promising. There are a few test failures in the NMT area, some crashes with
>> aot and a few minor Graal related test errors, but nothing that couldn't be
>> solved with too much of effort, I guess. But I can't make any judgement on
>> the state of the Graal compiler itself, since we don't have much test coverage
>> for that in our infrastructure.
>>> 
>>> However, the main point for me is to get a discussion started. First of all it is
>> about whether we want to have this kind of update at all in OpenJDK 11
>> Updates? If so, I'd need some help by people with expertise and test
>> infrastructure for the Graal related part. That's nothing we can cover in the
>> SAP team right now. If we decide against this update, we'll have give up our
>> policy about following the Oracle 11 Updates for JVMCI/Graal.
>>> 
>>> Looking forward to get input about this.
>>> 
>>> Thanks and best regards
>>> Christoph
>>> 
>>> [0] https://github.com/graalvm/labs-openjdk-11/
>>> [1] https://github.com/oracle/graal/issues/2196
>>> [2] https://github.com/graalvm/labs-openjdk-
>> 11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
>>> [3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
>>> [4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
>>> 
>> 
>> I'm aware of these changes for Graal and have been working on getting
>> some of them into OpenJDK 11u.
>> 
>> I don't think we should just apply these monolithic commits, but instead
>> work out the relevant issues in OpenJDK 13 being backported and do it
>> correctly. We want 11u to be as maintainable as possible.
> 
> I've got some sympathy with that approach. We can certainly have a look to identify the single changes and try to apply them one by one... It'll probably also help to identify the sources of regressions when we run into some.
> 
> But, the general question that needs to be answered before is: Do we want this to happen at all? Any opinions/thoughts?

Can you elaborate on what we believe the Oracle 11u has done so far on this matter? 

> 
> Cheers
> Christoph

From adinn at redhat.com  Mon Mar 23 12:36:17 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 23 Mar 2020 12:36:17 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
Message-ID: <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>

Hi Doug,

On 23/03/2020 10:25, Doug Simon wrote:
> The Graal sources in?graalvm/labs-openjdk-11
> <https://github.com/graalvm/labs-openjdk-11>?are not updated with those
> from?oracle/graal <https://github.com/oracle/graal>. They are mostly as
> they were when JDK 11 was released modulo changes need to adapt to the
> JVMCI updates. As you state, the primary reason for this is that the
> sources from?oracle/graal?are used?when building GraalVM on top
> of?graalvm/labs-openjdk-11. We mostly ignore the Graal sources in
> GraalVM/labs-openjdk-11.
I understand that and appreciate that any need to update the in-tree
jdk11u graal code in tandem with jdk11u hotspot changes is not for the
sake of the wider GraalVM project. It is needed to ensure that this
in-tree graal code is consistent with the hotspot code and hence
continues to allow use of the (in-tree) GraalVM compiler as a JVMCI JIT
replacement for C2 or to underpin the implementation of jaotc i.e. to
keep these two in-tree components in sync.

To address Christoph's question:

At Red Hat we are in the situation where we know that the labs  jdk11u
changes currently backported to OpenJDK jdk11u are enough to build the
(out-of-tree) Graal compiler and substratevm deliverables. In order to
allow this to work the extra build step of generating and installing
static libs must be performed. HOwever, that extra step uses build
system patches added to head and backported to jdk11u i.e. is catered
for /within/ the current release. So, in sum: as far as the mx build
step is concerned a current jdk11u build /can/ be used in place of the
Oracle labs download.

We also know that the resulting build of the compiler and substratevm
tree can be used to successfully generate native images with that same
jdk11u. That's not to say everything works but we do know that some
programs can be built and run as native images. We do not know (because
we have not tried it) how well we current jdk11u supports Truffle (or
the LLVM backend).

So, modulo further testing throwing up problems, we may perhaps be able
to leave jdk11u as is and still be able to use it to support building of
graal and native images. So, if there are pending JVMCI-related changes
to hotspot and, in consequence, to the in-tree graal code then we really
need a good reason to backport them.

Which consideration applies to the changes Christoph mentioned (they
appear to be to do with routing exceptions out of hotspot via JVMCI and
look relatively innocuous to me but don't count that as a full review
just yet). So, can you provide a reason why these are important or even
critical patches?

Are there already known issues we have not yet come across in our
testing that justify back-porting them? Alternatively, are there
upstream changes either in place or in progress in the out-of-tree graal
code base that have to depend on the level of JVMCI support these
patches provide (which seems essentially to be par with jdk13u) and
therefore imply that a backport is going to be absolutely necessary?

The mandatory follow-up question is whether these proposed changes
necessitate consequent updates to the in-tree graal code and if so which
specific ones. I'll take the whole bundle as an answer but it would be
much better to know if some of the contained changes are optional. If we
do end up backporting upstream code we would much prefer to do it patch
by patch rather than trying to push the bundled update found in the labs
jdk11u. Reducing the backport to only essential stuff would be much
preferred. We need to be sure to guarantee continuity and reliability of
function for a JVMCI-enabled  Graal JIT and Graal-based jaotc and of
course we also need to make an assessment as regards security.

Finally, I am asking that now re Chrisoph's current proposed changes.
However, as you can imagine, the same questions are rightly going to be
asked as regards future requests for changes.

regards,


Andrew Dinn
-----------


From doug.simon at oracle.com  Mon Mar 23 13:36:45 2020
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 23 Mar 2020 14:36:45 +0100
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
Message-ID: <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>



> On 23 Mar 2020, at 13:36, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi Doug,
> 
> On 23/03/2020 10:25, Doug Simon wrote:
>> The Graal sources in graalvm/labs-openjdk-11
>> <https://urldefense.com/v3/__https://github.com/graalvm/labs-openjdk-11__;!!GqivPVa7Brio!M-pcUkpK03riaDVCDWa7ewkFb-YF4FfWv5YR6E7mIAMPlQWNxJYlW2uQgdXeHWJ5$ > are not updated with those
>> from oracle/graal <https://urldefense.com/v3/__https://github.com/oracle/graal__;!!GqivPVa7Brio!M-pcUkpK03riaDVCDWa7ewkFb-YF4FfWv5YR6E7mIAMPlQWNxJYlW2uQgR5KwNjv$ >. They are mostly as
>> they were when JDK 11 was released modulo changes need to adapt to the
>> JVMCI updates. As you state, the primary reason for this is that the
>> sources from oracle/graal are used when building GraalVM on top
>> of graalvm/labs-openjdk-11. We mostly ignore the Graal sources in
>> GraalVM/labs-openjdk-11.
> I understand that and appreciate that any need to update the in-tree
> jdk11u graal code in tandem with jdk11u hotspot changes is not for the
> sake of the wider GraalVM project. It is needed to ensure that this
> in-tree graal code is consistent with the hotspot code and hence
> continues to allow use of the (in-tree) GraalVM compiler as a JVMCI JIT
> replacement for C2 or to underpin the implementation of jaotc i.e. to
> keep these two in-tree components in sync.
> 
> To address Christoph's question:
> 
> At Red Hat we are in the situation where we know that the labs  jdk11u
> changes currently backported to OpenJDK jdk11u are enough to build the
> (out-of-tree) Graal compiler and substratevm deliverables. In order to
> allow this to work the extra build step of generating and installing
> static libs must be performed. HOwever, that extra step uses build
> system patches added to head and backported to jdk11u i.e. is catered
> for /within/ the current release. So, in sum: as far as the mx build
> step is concerned a current jdk11u build /can/ be used in place of the
> Oracle labs download.
> 
> We also know that the resulting build of the compiler and substratevm
> tree can be used to successfully generate native images with that same
> jdk11u. That's not to say everything works but we do know that some
> programs can be built and run as native images. We do not know (because
> we have not tried it) how well we current jdk11u supports Truffle (or
> the LLVM backend).
> 
> So, modulo further testing throwing up problems, we may perhaps be able
> to leave jdk11u as is and still be able to use it to support building of
> graal and native images. So, if there are pending JVMCI-related changes
> to hotspot and, in consequence, to the in-tree graal code then we really
> need a good reason to backport them.
> 
> Which consideration applies to the changes Christoph mentioned (they
> appear to be to do with routing exceptions out of hotspot via JVMCI and
> look relatively innocuous to me but don't count that as a full review
> just yet). So, can you provide a reason why these are important or even
> critical patches?

Sorry, this thread is long and has mentioned a number of patches. Which ones are you referring to here?

> Are there already known issues we have not yet come across in our
> testing that justify back-porting them? Alternatively, are there
> upstream changes either in place or in progress in the out-of-tree graal
> code base that have to depend on the level of JVMCI support these
> patches provide (which seems essentially to be par with jdk13u) and
> therefore imply that a backport is going to be absolutely necessary?

I?m having trouble parsing that question. Are you asking ?is there anything in GitHub Graal that depends on the JVMCI changes in labs-openjdk-11??

> 
> The mandatory follow-up question is whether these proposed changes
> necessitate consequent updates to the in-tree graal code and if so which
> specific ones. I'll take the whole bundle as an answer but it would be
> much better to know if some of the contained changes are optional. If we
> do end up backporting upstream code we would much prefer to do it patch
> by patch rather than trying to push the bundled update found in the labs
> jdk11u. Reducing the backport to only essential stuff would be much
> preferred. We need to be sure to guarantee continuity and reliability of
> function for a JVMCI-enabled  Graal JIT and Graal-based jaotc and of
> course we also need to make an assessment as regards security.

I believe Tom has previously provided a breakdown of the patches in labs-openjdk-11. Everything in labs-openjdk-11 is essential for supporting complete GraalVM functionality as far as I understand otherwise it would not be there.

> 
> Finally, I am asking that now re Chrisoph's current proposed changes.
> However, as you can imagine, the same questions are rightly going to be
> asked as regards future requests for changes.

I think the high order point is that porting the changes in labs-openjdk-11 to jdk11u is going to be complex due the way we back-ported changes from JDK 13. With more time, we would have tried to be more principled about it but on the other hand we were keen to release GraalVM on JDK 11 given how much demand there was for it. 

It might help to have a Zoom call to discuss this further. I want Tom to be on the call so some time between 18:00 - 21:00 CET would probably work. I can do any day except Tuesday.

-Doug

From gil at azul.com  Sat Mar 21 05:22:56 2020
From: gil at azul.com (Gil Tene)
Date: Sat, 21 Mar 2020 05:22:56 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>



> On Mar 13, 2020, at 8:10 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Gil,
> 
>> -----Original Message-----
>> From: Gil Tene <gil at azul.com>
>> Sent: Freitag, 13. M?rz 2020 15:31
>> To: Langer, Christoph <christoph.langer at sap.com>
>> Cc: Andrew Hughes <gnu.andrew at redhat.com>; jdk-updates-
>> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
>> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
>> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
>> <doug.simon at oracle.com>; Tom Rodriguez <tom.rodriguez at oracle.com>;
>> Volker Simonis <volker.simonis at gmail.com>
>> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Mar 13, 2020, at 1:04 AM, Langer, Christoph
>> <christoph.langer at sap.com> wrote:
>>> 
>>> ?Hi Andrew, all,
>>> 
>>>> -----Original Message-----
>>>> From: Andrew Hughes <gnu.andrew at redhat.com>
>>>> Sent: Donnerstag, 12. M?rz 2020 19:27
>>>> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
>>>> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
>>>> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
>>>> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
>>>> <doug.simon at oracle.com>; Tom Rodriguez
>> <tom.rodriguez at oracle.com>;
>>>> Volker Simonis <volker.simonis at gmail.com>
>>>> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
>>>> 
>>>> 
>>>> 
>>>>> On 12/03/2020 12:03, Langer, Christoph wrote:
>>>>> Hi all,
>>>>> 
>>>>> as you may or may not know, the GraalVM Community Edition (CE)
>>>> supports OpenJDK 11 update releases. In order to do that, there exists a
>>>> clone of the OpenJDK repository in the GraalVM GitHub space [0]. This
>> fork,
>>>> however, contains several additional patches, obviously mainly in the area
>> of
>>>> JVMCI and the Graal compiler. There seems to be a certain interest of the
>>>> involved parties, that is, the GraalVM community, Oracle Labs and
>> probably
>>>> also the OpenJDK community, to keep these repositories as close as
>> possible.
>>>>> 
>>>>> One motivation could be to allow building of GraalVM native images
>> from
>>>> OpenJDK distributions, such as mentioned in a GitHub issue raised against
>>>> the graal project [1].
>>>>> 
>>>>> Another motivation probably comes from the Graal community to
>> reduce
>>>> the maintenance effort from merging the OpenJDK changes.
>>>>> 
>>>>> Furthermore, it has been policy in the OpenJDK 11 Updates project to try
>> to
>>>> follow what Oracle is doing in their JDK 11 LTS update releases. Lately,
>> there
>>>> obviously have been backports for JVMCI and Graal which completely
>> don't
>>>> match with the current state of OpenJDK 11u. When researching this I
>>>> learned that the prerequisite of these kind of changes is a larger update
>> of
>>>> JVMCI and Graal. The basis for this change could be a commit from the
>> labs-
>>>> openjdk-11 Graal repository [2]. This would update JVMCI and Graal to
>> the
>>>> state of OpenJDK 13. More details can be taken out of the conversation of
>>>> the GitHub issue [1].
>>>>> 
>>>>> I took this change, applied it to OpenJDK 11u-dev, resolved some
>> conflicts
>>>> and made sure it builds on all platforms (that we support in the SAP
>> team). A
>>>> prerequisite would also be a backport of JDK-8208686, at least the hotspot
>>>> part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are
>>>> contained in [3]. With this work applied, regression testing looks quite
>>>> promising. There are a few test failures in the NMT area, some crashes
>> with
>>>> aot and a few minor Graal related test errors, but nothing that couldn't be
>>>> solved with too much of effort, I guess. But I can't make any judgement
>> on
>>>> the state of the Graal compiler itself, since we don't have much test
>> coverage
>>>> for that in our infrastructure.
>>>>> 
>>>>> However, the main point for me is to get a discussion started. First of all
>> it is
>>>> about whether we want to have this kind of update at all in OpenJDK 11
>>>> Updates? If so, I'd need some help by people with expertise and test
>>>> infrastructure for the Graal related part. That's nothing we can cover in
>> the
>>>> SAP team right now. If we decide against this update, we'll have give up
>> our
>>>> policy about following the Oracle 11 Updates for JVMCI/Graal.
>>>>> 
>>>>> Looking forward to get input about this.
>>>>> 
>>>>> Thanks and best regards
>>>>> Christoph
>>>>> 
>>>>> [0] https://github.com/graalvm/labs-openjdk-11/
>>>>> [1] https://github.com/oracle/graal/issues/2196
>>>>> [2] https://github.com/graalvm/labs-openjdk-
>>>> 11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
>>>>> [3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
>>>>> [4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
>>>>> 
>>>> 
>>>> I'm aware of these changes for Graal and have been working on getting
>>>> some of them into OpenJDK 11u.
>>>> 
>>>> I don't think we should just apply these monolithic commits, but instead
>>>> work out the relevant issues in OpenJDK 13 being backported and do it
>>>> correctly. We want 11u to be as maintainable as possible.
>>> 
>>> I've got some sympathy with that approach. We can certainly have a look to
>> identify the single changes and try to apply them one by one... It'll probably
>> also help to identify the sources of regressions when we run into some.
>>> 
>>> But, the general question that needs to be answered before is: Do we
>> want this to happen at all? Any opinions/thoughts?
>> 
>> Can you elaborate on what we believe the Oracle 11u has done so far on this
>> matter?
> 
> In short, I believe Graal and JVMCI in Oracle 11u was updated to the JDK13 level. And from there on further patches have been backported.
> 
> The Graal/JVMCI update as a monolith would probably look like this: https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d.
> And additional backports come on top, like most of the 23 items left in this query: https://bugs.openjdk.java.net/issues/?filter=37811

Can someone from Oracle comment on where Graal support is moving to in
Oracle JDK 11? And/or confirm that it is being updated to be roughly in line
 with ~JDK13?

On the assumption that Oracle is updating JVMCI and Graal in Oracle JDK 11
to JDK13 levels, I think that it would be appropriate to do the same in
OpenJDK 11u. IMO it would rise the "something is missing" level that should
be addressed.

However, as there are several changes in the monolith link above that touch
central pieces of code in the JVM, and do so outside of #if INCLUDE_JVMCI
 blocks, this looks like a large piece of work that needs to be done carefully
and with lots of though when it comes to code that is not localized to jvmci and
graal modules and jvmci-specific jvm files. I assume the above links are
just a pointer to the possible scope, and not necessarily a suggestion for
what the backport will look like exactly.

The backport there may very well end up being close to what we'd want for
11u, but I certainly wouldn't want to just take this bulk stuff from
graalvm/labs-openjdk-11 and assume that is was well though through for
handling non-Graal use modes (which are the main concern for
OpenJDK 11u, and probably of no significant concern to the Graal project).

> 
> 
> Best regards
> Christoph
> 


From aph at redhat.com  Sat Mar 21 09:45:44 2020
From: aph at redhat.com (Andrew Haley)
Date: Sat, 21 Mar 2020 09:45:44 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
Message-ID: <f2ed69e3-0c8e-0ebd-21db-01d7e38ba59d@redhat.com>

On 3/21/20 5:22 AM, Gil Tene wrote:
> The backport there may very well end up being close to what we'd want for
> 11u, but I certainly wouldn't want to just take this bulk stuff from
> graalvm/labs-openjdk-11 and assume that is was well though through for
> handling non-Graal use modes (which are the main concern for
> OpenJDK 11u, and probably of no significant concern to the Graal project).

That's right. As discussed when we met the Graal people in Zurich last
year, it is a goal to do the work necessary to support Graal on
OpenJDK 11 rather than Labs JDK 11. That requires some changes to
JVMCI. Does it require Graal itself to be updated? Does the Graal build
use the Graal that's in the JDK for anything?

OpenJDK 11 itself must be protected, so it may be necessary to produce
a Graal fork of OpenJDK 11 if these goals conflict. This is, I
believe, the situation with Oracle: they have a separate version of
the JDK, Labs JDK 11.

I'll get some of the Red Hat people who know more about this stuff
than me to weigh in.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From doug.simon at oracle.com  Mon Mar 23 10:25:11 2020
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 23 Mar 2020 11:25:11 +0100
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
Message-ID: <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>

Hi,

The Graal sources in graalvm/labs-openjdk-11 <https://github.com/graalvm/labs-openjdk-11> are not updated with those from oracle/graal <https://github.com/oracle/graal>. They are mostly as they were when JDK 11 was released modulo changes need to adapt to the JVMCI updates. As you state, the primary reason for this is that the sources from oracle/graal are used when building GraalVM on top of graalvm/labs-openjdk-11. We mostly ignore the Graal sources in GraalVM/labs-openjdk-11.

-Doug

> On 21 Mar 2020, at 06:22, Gil Tene <gil at azul.com> wrote:
> 
> 
> 
>> On Mar 13, 2020, at 8:10 AM, Langer, Christoph <christoph.langer at sap.com <mailto:christoph.langer at sap.com>> wrote:
>> 
>> Hi Gil,
>> 
>>> -----Original Message-----
>>> From: Gil Tene <gil at azul.com>
>>> Sent: Freitag, 13. M?rz 2020 15:31
>>> To: Langer, Christoph <christoph.langer at sap.com>
>>> Cc: Andrew Hughes <gnu.andrew at redhat.com>; jdk-updates-
>>> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
>>> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
>>> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
>>> <doug.simon at oracle.com>; Tom Rodriguez <tom.rodriguez at oracle.com>;
>>> Volker Simonis <volker.simonis at gmail.com>
>>> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
>>> 
>>> 
>>> 
>>> Sent from my iPad
>>> 
>>>> On Mar 13, 2020, at 1:04 AM, Langer, Christoph
>>> <christoph.langer at sap.com> wrote:
>>>> 
>>>> ?Hi Andrew, all,
>>>> 
>>>>> -----Original Message-----
>>>>> From: Andrew Hughes <gnu.andrew at redhat.com>
>>>>> Sent: Donnerstag, 12. M?rz 2020 19:27
>>>>> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
>>>>> dev at openjdk.java.net; Andrew Dinn <adinn at redhat.com>; Severin
>>>>> Gehwolf <sgehwolf at redhat.com>; Andrew Haley <aph at redhat.com>;
>>>>> Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; Doug Simon
>>>>> <doug.simon at oracle.com>; Tom Rodriguez
>>> <tom.rodriguez at oracle.com>;
>>>>> Volker Simonis <volker.simonis at gmail.com>
>>>>> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 12/03/2020 12:03, Langer, Christoph wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> as you may or may not know, the GraalVM Community Edition (CE)
>>>>> supports OpenJDK 11 update releases. In order to do that, there exists a
>>>>> clone of the OpenJDK repository in the GraalVM GitHub space [0]. This
>>> fork,
>>>>> however, contains several additional patches, obviously mainly in the area
>>> of
>>>>> JVMCI and the Graal compiler. There seems to be a certain interest of the
>>>>> involved parties, that is, the GraalVM community, Oracle Labs and
>>> probably
>>>>> also the OpenJDK community, to keep these repositories as close as
>>> possible.
>>>>>> 
>>>>>> One motivation could be to allow building of GraalVM native images
>>> from
>>>>> OpenJDK distributions, such as mentioned in a GitHub issue raised against
>>>>> the graal project [1].
>>>>>> 
>>>>>> Another motivation probably comes from the Graal community to
>>> reduce
>>>>> the maintenance effort from merging the OpenJDK changes.
>>>>>> 
>>>>>> Furthermore, it has been policy in the OpenJDK 11 Updates project to try
>>> to
>>>>> follow what Oracle is doing in their JDK 11 LTS update releases. Lately,
>>> there
>>>>> obviously have been backports for JVMCI and Graal which completely
>>> don't
>>>>> match with the current state of OpenJDK 11u. When researching this I
>>>>> learned that the prerequisite of these kind of changes is a larger update
>>> of
>>>>> JVMCI and Graal. The basis for this change could be a commit from the
>>> labs-
>>>>> openjdk-11 Graal repository [2]. This would update JVMCI and Graal to
>>> the
>>>>> state of OpenJDK 13. More details can be taken out of the conversation of
>>>>> the GitHub issue [1].
>>>>>> 
>>>>>> I took this change, applied it to OpenJDK 11u-dev, resolved some
>>> conflicts
>>>>> and made sure it builds on all platforms (that we support in the SAP
>>> team). A
>>>>> prerequisite would also be a backport of JDK-8208686, at least the hotspot
>>>>> part of it, as provided in [4]. The Graal/Java parts of JDK-8208686 are
>>>>> contained in [3]. With this work applied, regression testing looks quite
>>>>> promising. There are a few test failures in the NMT area, some crashes
>>> with
>>>>> aot and a few minor Graal related test errors, but nothing that couldn't be
>>>>> solved with too much of effort, I guess. But I can't make any judgement
>>> on
>>>>> the state of the Graal compiler itself, since we don't have much test
>>> coverage
>>>>> for that in our infrastructure.
>>>>>> 
>>>>>> However, the main point for me is to get a discussion started. First of all
>>> it is
>>>>> about whether we want to have this kind of update at all in OpenJDK 11
>>>>> Updates? If so, I'd need some help by people with expertise and test
>>>>> infrastructure for the Graal related part. That's nothing we can cover in
>>> the
>>>>> SAP team right now. If we decide against this update, we'll have give up
>>> our
>>>>> policy about following the Oracle 11 Updates for JVMCI/Graal.
>>>>>> 
>>>>>> Looking forward to get input about this.
>>>>>> 
>>>>>> Thanks and best regards
>>>>>> Christoph
>>>>>> 
>>>>>> [0] https://github.com/graalvm/labs-openjdk-11/ <https://github.com/graalvm/labs-openjdk-11/>
>>>>>> [1] https://github.com/oracle/graal/issues/2196 <https://github.com/oracle/graal/issues/2196>
>>>>>> [2] https://github.com/graalvm/labs-openjdk- <https://github.com/graalvm/labs-openjdk->
>>>>> 11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
>>>>>> [3] http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/ <http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/>
>>>>>> [4] http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/ <http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/>
>>>>>> 
>>>>> 
>>>>> I'm aware of these changes for Graal and have been working on getting
>>>>> some of them into OpenJDK 11u.
>>>>> 
>>>>> I don't think we should just apply these monolithic commits, but instead
>>>>> work out the relevant issues in OpenJDK 13 being backported and do it
>>>>> correctly. We want 11u to be as maintainable as possible.
>>>> 
>>>> I've got some sympathy with that approach. We can certainly have a look to
>>> identify the single changes and try to apply them one by one... It'll probably
>>> also help to identify the sources of regressions when we run into some.
>>>> 
>>>> But, the general question that needs to be answered before is: Do we
>>> want this to happen at all? Any opinions/thoughts?
>>> 
>>> Can you elaborate on what we believe the Oracle 11u has done so far on this
>>> matter?
>> 
>> In short, I believe Graal and JVMCI in Oracle 11u was updated to the JDK13 level. And from there on further patches have been backported.
>> 
>> The Graal/JVMCI update as a monolith would probably look like this: https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d <https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d>.
>> And additional backports come on top, like most of the 23 items left in this query: https://bugs.openjdk.java.net/issues/?filter=37811 <https://bugs.openjdk.java.net/issues/?filter=37811>
> 
> Can someone from Oracle comment on where Graal support is moving to in
> Oracle JDK 11? And/or confirm that it is being updated to be roughly in line
> with ~JDK13?
> 
> On the assumption that Oracle is updating JVMCI and Graal in Oracle JDK 11
> to JDK13 levels, I think that it would be appropriate to do the same in
> OpenJDK 11u. IMO it would rise the "something is missing" level that should
> be addressed.
> 
> However, as there are several changes in the monolith link above that touch
> central pieces of code in the JVM, and do so outside of #if INCLUDE_JVMCI
> blocks, this looks like a large piece of work that needs to be done carefully
> and with lots of though when it comes to code that is not localized to jvmci and
> graal modules and jvmci-specific jvm files. I assume the above links are
> just a pointer to the possible scope, and not necessarily a suggestion for
> what the backport will look like exactly.
> 
> The backport there may very well end up being close to what we'd want for
> 11u, but I certainly wouldn't want to just take this bulk stuff from
> graalvm/labs-openjdk-11 and assume that is was well though through for
> handling non-Graal use modes (which are the main concern for
> OpenJDK 11u, and probably of no significant concern to the Graal project).
> 
>> 
>> 
>> Best regards
>> Christoph


From adinn at redhat.com  Mon Mar 23 14:29:29 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 23 Mar 2020 14:29:29 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
Message-ID: <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>

Hi Doug,

On 23/03/2020 13:36, Doug Simon wrote:
> Sorry, this thread is long and has mentioned a number of patches.
> Which ones are you referring to here?

The specific changes in question were derived from the discussion in
github/graal issue #2196. The patches are detailed in the 2 webrevs
Christoph posted:

  http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/

and

  http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/

The first webrev is the fix for JDK-8208686. The second one is
essentially the bundled update that Tom pushed to the labs version of
jkd11u after Christoph tweaked ti to make it apply and build correctly.

> I?m having trouble parsing that question. Are you asking ?is there
> anything in GitHub Graal that depends on the JVMCI changes in
> labs-openjdk-11??

I am asking two things:

1) Is there anything in the current GitHub Graal repo that critically
depends on the above changes getting into jdk11u?

2) Is there anything planned for addition to the GitHub Graal repo that
critically depends on the above changes getting into jdk11u?

In other words why do this backport instead of just use the current jdk11u?

> I believe Tom has previously provided a breakdown of the patches in
> labs-openjdk-11. Everything in labs-openjdk-11 is essential for
> supporting complete GraalVM functionality as far as I understand
> otherwise it would not be there.

First, I think all the patches mentioned in that list that involve
hotspot changes have been backported except for the ones listed above --
which is why we are currently able to build GraalVM using the latest
OpenJDK jdkd11u.

Now, I'm not suggesting that there is any /redundancy/ as regards these
remaining patches. However, what we would like to know is why we need to
backport them i.e. what problem do they resolve and what would be the
upshot if we stop further backports where we are now.

The existing jdk11u code appears to work to build Graal VM. It also
works perfectly well to build and run the in-tree Graal code. So, by
'upshot' above I mean what would it imply for the ability to continue
using jdk11u to build Graal if we don't backport the above changes? This
is one side of a benefits equation we need to assess.

> I think the high order point is that porting the changes in
> labs-openjdk-11 to jdk11u is going to be complex due the way we
> back-ported changes from JDK 13. With more time, we would have tried
> to be more principled about it but on the other hand we were keen to
> release GraalVM on JDK 11 given how much demand there was for it.

Yes, I had noticed that ;-). Also, I fully understand why a mega-patch
was chosen at the time (especially since Red Hat were responsible for a
lot of the demand you mention). I'm really trying to assess the degree
to which we can justify bringing jdk11u up to date with the jdk13u base
level.

> It might help to have a Zoom call to discuss this further. I want Tom
> to be on the call so some time between 18:00 - 21:00 CET would
> probably work. I can do any day except Tuesday.

Well, we normally try very hard to keep discussions like this in public
so that they are visible to all who might have an interest and also on
record. It's not really good open source practice to do otherwise.
However, I'd be happy to try to use the tech to help expedite resolution
of this issue -- so long as we report back ideas, suggestions and
conclusions here to all interested parties. That's also assuming that
others are happy to join in. Perhaps anyone interested in taking up your
offer could respond and then we can take arrangement of a Zoom call offline.

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 shade at redhat.com  Mon Mar 23 14:54:24 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 23 Mar 2020 15:54:24 +0100
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <3174b10c-aa0a-7b65-b889-717e84e71b48@redhat.com>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
 <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
 <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>
 <AM0PR02MB5714F1B4C8128EF5FAF5E8F08AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <3174b10c-aa0a-7b65-b889-717e84e71b48@redhat.com>
Message-ID: <0a36a0a5-96b1-4514-ad79-ee30f2b8d516@redhat.com>

On 3/23/20 11:39 AM, Aleksey Shipilev wrote:
> On 3/18/20 8:56 PM, Langer, Christoph wrote:
>> I just approved the backport for 11u. Andrew, I assume you'll want to sponsor it?
> 
> I'll go talk to Andrew about this. If anything, I could sponsor it.

Pushed to both 11u and 14u:
  https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9ac69f00f292
  https://hg.openjdk.java.net/jdk-updates/jdk14u/rev/efe766fead9d

-- 
Thanks,
-Aleksey


From christoph.langer at sap.com  Mon Mar 23 14:57:51 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 23 Mar 2020 14:57:51 +0000
Subject: new JBS filters for 11u and minor fixes to old filters
Message-ID: <AM0PR02MB5714571FDA0C6458668951918AF00@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

I've added new JBS filters for OpenJDK 11u Releases 11.0.7 and 11.0.8 and added links to them on the Wiki [0].

First of all, we currently have to defer and maybe eventually completely leave out some JVMCI related backports. You can follow the discussion and reasoning in another thread here on this list [1]. I've added filters that discard these items which should help focusing on the "real" ones.
11.0.7: https://bugs.openjdk.java.net/issues/?filter=38694
11.0.8: https://bugs.openjdk.java.net/issues/?filter=38695

Furthermore, for 11.0.8, I've created a filter that only shows net new Oracle 11.0.8 backports (leaving out items that date back to 11.0.7 or older and have not been backported in 11.0.8). I'm planning to maintain a filter for each upcoming update release as well.
11.0.8-only filter: https://bugs.openjdk.java.net/issues/?filter=38639

Furthermore, I've removed some now unnecessary parts of the queries that collect data of old releases that have been long out of the door and all backports have settled. That should hopefully improve the performance a bit and makes the query string shorter.

Best regards
Christoph

[0] https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002743.html


From christoph.langer at sap.com  Mon Mar 23 15:04:07 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 23 Mar 2020 15:04:07 +0000
Subject: If you can answer great, if not I understand
In-Reply-To: <DM6PR15MB22207F197DDA4938E311E6ADB1020@DM6PR15MB2220.namprd15.prod.outlook.com>
References: <DM6PR15MB22207F197DDA4938E311E6ADB1020@DM6PR15MB2220.namprd15.prod.outlook.com>
Message-ID: <AM0PR02MB57143FE915ADB03F3ED80C828AF00@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Jason,

the difference is that 1.8 and 11 are different releases of Java.

Both get security updates regularly. That is, 4 times a year. Next is due mid of April.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Bollinger, Jason
> Sent: Mittwoch, 5. Februar 2020 19:37
> To: jdk-updates-dev at openjdk.java.net
> Subject: If you can answer great, if not I understand
> 
> Can you tell me what the difference is between
> 
> OpenJDK JRE Version 1.8 and version 11.  I am sorry I am not a programmer.
> Do these versions get security updates often?
> 
> 
> Thanks,
> Jason
> 
> 
> The information supplied in this message may be privileged, confidential
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient of this message, the sender does not intend delivery to
> you to waive any privilege or right pertaining to this message. You have no
> right to retain, disseminate, copy or disclose the material contained herein. If
> you have received this message in error, please immediately notify the
> sender by return e-mail, and delete the errant message. Thank you.
> WRA_Disclaimer_v20070222a

From adinn at redhat.com  Mon Mar 23 16:19:06 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 23 Mar 2020 16:19:06 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
Message-ID: <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>

Hi Doug,

Ok, so let me summarize and please correct me if I misrepresent the case:

1) The first patch is critical to the ability to use jdk11u to build
GraalVM and successfully use the resulting build products.

2) The second patch is essentially an enhancement to performance of
JVMCI-based compilation on OpenJDK jdk11u. Not having it will impinge on
performance (but not change functionality) both for OpenJDK-internal use
e.g. jaotc or Graal as C2 replacement and also when using OpenJDK jdk11u
to build GraalVM.

3) You plan to continue to backport upstream changes to the the labs
jdk11u in order to be able to support ongoing development in GraalVM.

n.b. I classify the 2nd patch as only having performance implications
because, as I understand it, the point of the libgraal update is simply
to allow the GraalVM JIT to execute as precompiled native code with its
own managed memory pool rather than having to be interpreted then JIT
compile itself and employ the JVM heap for compiler data. i.e. this
change has no effect on what functionality is supported.

If that is correct then:

1) I think it would probably be wise to include the first patch into
jdk11u, modulo suitable review.

2) It doesn't sound to me like the second patch really needs to be
backported into jdk11u. jdk13+ and the jdk dev tree head already support
the the use of libgraal for those who need to use it.

3) As regards any further changes that might be needed to retain the
ability to buidl GraalVM, my view is that I don't think the jdk11u
project can or ought to offer a blank check regarding further updates to
JVMCI that imply hotspot changes (i.e. ones that will have to be met by
backporting rather than by overlaying the GraalVM code).

Of course, any further changes the GraalVM project would like to be
backported could and, I think, should still be considered on their
merits. However, in my view the project's priority has to be continuity
of operation, reliability and security. That said, it's certainly not
for me to make any final decision here. I am sure the project lead and
maintainers an, indeed, other updates project members will wish to
follow up on this point.

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

On 23/03/2020 15:03, Doug Simon wrote:
> 
> 
>> On 23 Mar 2020, at 15:29, Andrew Dinn <adinn at redhat.com> wrote:
>>
>> Hi Doug,
>>
>> On 23/03/2020 13:36, Doug Simon wrote:
>>> Sorry, this thread is long and has mentioned a number of patches.
>>> Which ones are you referring to here?
>>
>> The specific changes in question were derived from the discussion in
>> github/graal issue #2196. The patches are detailed in the 2 webrevs
>> Christoph posted:
>>
>>  http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
>>
>> and
>>
>>  http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
>>
>> The first webrev is the fix for JDK-8208686. The second one is
>> essentially the bundled update that Tom pushed to the labs version of
>> jkd11u after Christoph tweaked ti to make it apply and build correctly.
>>
>>> I?m having trouble parsing that question. Are you asking ?is there
>>> anything in GitHub Graal that depends on the JVMCI changes in
>>> labs-openjdk-11??
>>
>> I am asking two things:
>>
>> 1) Is there anything in the current GitHub Graal repo that critically
>> depends on the above changes getting into jdk11u?
> 
> JDK-8208686 fixes a JCK failure so is critical if you want to pass the JCK, especially with jaotc.
> 
> However, the general answer depends on the goal. If you want to be able to build and use libgraal with GitHub Graal + jdk11u, then the bundled update is necessary.
> 
>>
>> 2) Is there anything planned for addition to the GitHub Graal repo that
>> critically depends on the above changes getting into jdk11u?
> 
> Once again, it depends on what the goal is. Since GraalVM is built on labs-openjdk-11, the extent to which jdk11u matches open-labsjdk-11 determines the extent to which the same GraalVM can be built in jdk11u.
> 
>> In other words why do this backport instead of just use the current jdk11u?
> 
> Because jdk11u misses all the JVMCI implementation changes needed for libgraal.
> 
>>
>>> I believe Tom has previously provided a breakdown of the patches in
>>> labs-openjdk-11. Everything in labs-openjdk-11 is essential for
>>> supporting complete GraalVM functionality as far as I understand
>>> otherwise it would not be there.
>>
>> First, I think all the patches mentioned in that list that involve
>> hotspot changes have been backported except for the ones listed above --
>> which is why we are currently able to build GraalVM using the latest
>> OpenJDK jdkd11u.
> 
> Yes but it?s a GraalVM missing libgraal.
> 
>> Now, I'm not suggesting that there is any /redundancy/ as regards these
>> remaining patches. However, what we would like to know is why we need to
>> backport them i.e. what problem do they resolve and what would be the
>> upshot if we stop further backports where we are now.
>>
>> The existing jdk11u code appears to work to build Graal VM. It also
>> works perfectly well to build and run the in-tree Graal code. So, by
>> 'upshot' above I mean what would it imply for the ability to continue
>> using jdk11u to build Graal if we don't backport the above changes? This
>> is one side of a benefits equation we need to assess.
> 
> Again, libgraal is the main difference.
> 
>>> I think the high order point is that porting the changes in
>>> labs-openjdk-11 to jdk11u is going to be complex due the way we
>>> back-ported changes from JDK 13. With more time, we would have tried
>>> to be more principled about it but on the other hand we were keen to
>>> release GraalVM on JDK 11 given how much demand there was for it.
>>
>> Yes, I had noticed that ;-). Also, I fully understand why a mega-patch
>> was chosen at the time (especially since Red Hat were responsible for a
>> lot of the demand you mention). I'm really trying to assess the degree
>> to which we can justify bringing jdk11u up to date with the jdk13u base
>> level.
>>
>>> It might help to have a Zoom call to discuss this further. I want Tom
>>> to be on the call so some time between 18:00 - 21:00 CET would
>>> probably work. I can do any day except Tuesday.
>>
>> Well, we normally try very hard to keep discussions like this in public
>> so that they are visible to all who might have an interest and also on
>> record. It's not really good open source practice to do otherwise.
>> However, I'd be happy to try to use the tech to help expedite resolution
>> of this issue -- so long as we report back ideas, suggestions and
>> conclusions here to all interested parties. That's also assuming that
>> others are happy to join in. Perhaps anyone interested in taking up your
>> offer could respond and then we can take arrangement of a Zoom call offline.
> 
> FWIW, I?d be happy to record and publish a Zoom call. My only motivation for that option is that we can probably get to a resolution a lot faster. But for now, we can keep discussing on this thread.
> 
> -Doug
> 
>> 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 snazy at gmx.de  Mon Mar 23 16:53:13 2020
From: snazy at gmx.de (Robert Stupp)
Date: Mon, 23 Mar 2020 17:53:13 +0100
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <0a36a0a5-96b1-4514-ad79-ee30f2b8d516@redhat.com>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
 <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
 <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>
 <AM0PR02MB5714F1B4C8128EF5FAF5E8F08AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <3174b10c-aa0a-7b65-b889-717e84e71b48@redhat.com>
 <0a36a0a5-96b1-4514-ad79-ee30f2b8d516@redhat.com>
Message-ID: <2927d17f825e845050749427bfa17a16cb5c826d.camel@gmx.de>

On Mon, 2020-03-23 at 15:54 +0100, Aleksey Shipilev wrote:
> On 3/23/20 11:39 AM, Aleksey Shipilev wrote:
> > On 3/18/20 8:56 PM, Langer, Christoph wrote:
> > > I just approved the backport for 11u. Andrew, I assume you'll
> > > want to sponsor it?
> >
> > I'll go talk to Andrew about this. If anything, I could sponsor it.
>
> Pushed to both 11u and 14u:
>   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9ac69f00f292
>   https://hg.openjdk.java.net/jdk-updates/jdk14u/rev/efe766fead9d
>

Thank you guys!


From gnu.andrew at redhat.com  Mon Mar 23 17:07:19 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 23 Mar 2020 17:07:19 +0000
Subject: Help requested, backport 8240629 to 11u + 14u
In-Reply-To: <0a36a0a5-96b1-4514-ad79-ee30f2b8d516@redhat.com>
References: <4F02E64D-0989-44C9-A1DD-584EEC74A6B2@snazy.de>
 <be04b5a6-799f-48d5-8658-e0ba2904110f@redhat.com>
 <31601136b42ee8803abe9155601e093f8f63ff4d.camel@gmx.de>
 <AM0PR02MB5714F1B4C8128EF5FAF5E8F08AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <3174b10c-aa0a-7b65-b889-717e84e71b48@redhat.com>
 <0a36a0a5-96b1-4514-ad79-ee30f2b8d516@redhat.com>
Message-ID: <583bfa97-214b-1d2a-f767-2cf834b2cee3@redhat.com>



On 23/03/2020 14:54, Aleksey Shipilev wrote:
> On 3/23/20 11:39 AM, Aleksey Shipilev wrote:
>> On 3/18/20 8:56 PM, Langer, Christoph wrote:
>>> I just approved the backport for 11u. Andrew, I assume you'll want to sponsor it?
>>
>> I'll go talk to Andrew about this. If anything, I could sponsor it.
> 
> Pushed to both 11u and 14u:
>   https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/9ac69f00f292
>   https://hg.openjdk.java.net/jdk-updates/jdk14u/rev/efe766fead9d
> 

Thanks Aleksey.
-- 
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  Mon Mar 23 17:51:59 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 23 Mar 2020 17:51:59 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
 <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
 <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>
Message-ID: <968d9565-2baa-01d2-aa4c-48678d013835@redhat.com>

On 23/03/2020 16:56, Doug Simon wrote:
> That is a good summary. Indeed, libgraal is only a compilation time and
> resource optimization and thus not necessary for GraalVM.

Ok, glad to know I didn't misrepresent anything :-)

> Note that the JDK11 based Travis gates run on?openjdk11
> <https://github.com/oracle/graal/blob/master/.travis.yml#L17>?so we
> should recognize any regression of the GraalVM compiler there (as we
> did?recently
> <https://github.com/oracle/graal/pull/2278#issuecomment-602513391>).
> That said, also note that the Travis gate does not include any native
> image tests. That would require use of open-labsjdk-11 for access to the
> static libs.

Sure, we recognize that. You use of stockjdk11u in the gate is a great
help. As for native image, Red Hat expects to be ramping up testing on
OpenJDK jdk11u now that we are able to use it. So we should be able to
catch issues and hopefully either suggest fixes them or, at least,
report them back to you upstream in a timely fashion.

> It?s also worth pointing out that we?re also working with the HotSpot
> team at Oracle to ensure any JVMCI change we?re pushing into 11 also
> goes into JDK 15 where relevant.
Yes of course and we appreciate that effort.

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 martin.doerr at sap.com  Mon Mar 23 18:07:02 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 23 Mar 2020 18:07:02 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
Message-ID: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi,

I'd like to backport JDK-8223326 from jdk/jdk.

11u backport issue:
https://bugs.openjdk.java.net/browse/JDK-8241460

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc

11u backport webrev:
http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/

I had to integrate the change manually due to context changes. However, the new code fits to the 11u versions.

Please review.

Best regards,
Martin


From hohensee at amazon.com  Mon Mar 23 18:28:34 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 23 Mar 2020 18:28:34 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
Message-ID: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com>

The changeset references JDK-8223326, which is private. If possible, ask Oracle to make it public so we can do a normal backport rather than file an 11u-specific issue. The backport itself looks fine.

Thanks,
Paul

?On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" <jdk-updates-dev-bounces at openjdk.java.net on behalf of martin.doerr at sap.com> wrote:

    
    Hi,
    
    I'd like to backport JDK-8223326 from jdk/jdk.
    
    11u backport issue:
    https://bugs.openjdk.java.net/browse/JDK-8241460
    
    Original change:
    https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
    
    11u backport webrev:
    http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
    
    I had to integrate the change manually due to context changes. However, the new code fits to the 11u versions.
    
    Please review.
    
    Best regards,
    Martin
    
    


From martin.doerr at sap.com  Mon Mar 23 18:32:56 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 23 Mar 2020 18:32:56 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com>
References: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com>
Message-ID: <AM0PR0202MB3297BA79279B8DEE9429DDCD9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Paul,

thanks for the review.

We had already asked, but this one can't get opened up. I would have preferred a normal backport, too.

Best regards,
Martin


> -----Original Message-----
> From: Hohensee, Paul <hohensee at amazon.com>
> Sent: Montag, 23. M?rz 2020 19:29
> To: Doerr, Martin <martin.doerr at sap.com>; core-libs-
> dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> The changeset references JDK-8223326, which is private. If possible, ask
> Oracle to make it public so we can do a normal backport rather than file an
> 11u-specific issue. The backport itself looks fine.
> 
> Thanks,
> Paul
> 
> ?On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" <jdk-
> updates-dev-bounces at openjdk.java.net on behalf of
> martin.doerr at sap.com> wrote:
> 
> 
>     Hi,
> 
>     I'd like to backport JDK-8223326 from jdk/jdk.
> 
>     11u backport issue:
>     https://bugs.openjdk.java.net/browse/JDK-8241460
> 
>     Original change:
>     https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
> 
>     11u backport webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
> 
>     I had to integrate the change manually due to context changes. However,
> the new code fits to the 11u versions.
> 
>     Please review.
> 
>     Best regards,
>     Martin
> 
> 


From martin.doerr at sap.com  Mon Mar 23 19:06:54 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 23 Mar 2020 19:06:54 +0000
Subject: RFR(XS): 8241464: [11u] Backport: make rehashing be a needed
 guaranteed safepoint cleanup action
Message-ID: <AM0PR0202MB32973FC8CAAF6A88E61824039AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi,

I'd like to backport a part of JDK-8221967. I'm using a new bug because it's only a part of the original one.
Original change has the summary "Move redundant table lookup and make rehashing be a needed guaranteed safepoint cleanup action."
The first part of it doesn't apply to 11u, because the SymbolTable and StringTable parts are different in 11u and I don't see the need to change them.

The second part of it does apply and makes perfect sense. Especially if BiasedLocking is disabled (11u BiasedLocking implementation requests more safepoints making this fix less important).

Original bug:
https://bugs.openjdk.java.net/browse/JDK-8221967

Original issue:
http://hg.openjdk.java.net/jdk/jdk/rev/2523496f5107

New webrev:
http://cr.openjdk.java.net/~mdoerr/8221967_string_table_partial_backport_11u/webrev.00/

Please review.

Best regards,
Martin


From Alan.Bateman at oracle.com  Mon Mar 23 19:18:43 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2020 19:18:43 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com>

On 23/03/2020 18:07, Doerr, Martin wrote:
> Hi,
>
> I'd like to backport JDK-8223326 from jdk/jdk.
>
> 11u backport issue:
> https://bugs.openjdk.java.net/browse/JDK-8241460
>
> Original change:
> https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
>
> 11u backport webrev:
> http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
>
> I had to integrate the change manually due to context changes. However, the new code fits to the 11u versions.
>
> Please review.
>
Socket(SocketImpl) is only specified to do a permission check when the 
impl is non-null. The socket adaptor in JDK 12 and older releases 
doesn't have a dummy impl so the change should not be needed. If there 
is a security exception thrownhere then it suggests something may be 
broken elsewhere, do you have a stack trace?

-Alan

From chris.hegarty at oracle.com  Mon Mar 23 19:39:56 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 23 Mar 2020 19:39:56 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com>
Message-ID: <32493F42-5A85-40DE-A151-018C63FF753E@oracle.com>


> On 23 Mar 2020, at 19:18, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> ...
>> 
> Socket(SocketImpl) is only specified to do a permission check when the impl is non-null. The socket adaptor in JDK 12 and older releases doesn't have a dummy impl so the change should not be needed. If there is a security exception thrownhere then it suggests something may be broken elsewhere, do you have a stack trace?

I suspect that only the ServerSocketAdapter part of the change is needed, since ServerSocket(SocketImpl) does a security check regardless of the value of the given SocketImpl.

-Chris. 

From Alan.Bateman at oracle.com  Mon Mar 23 19:44:56 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2020 19:44:56 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>



On 23/03/2020 18:07, Doerr, Martin wrote:
> Hi,
>
> I'd like to backport JDK-8223326 from jdk/jdk.
>
One other thing on this. It looks like the spec changes that were part 
of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by 
mistake. Is that part of the issue that you are trying to fix?

-Alan

From Alan.Bateman at oracle.com  Mon Mar 23 19:51:34 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 Mar 2020 19:51:34 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <32493F42-5A85-40DE-A151-018C63FF753E@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com>
 <32493F42-5A85-40DE-A151-018C63FF753E@oracle.com>
Message-ID: <08eb5aec-9508-69c5-5661-c4c91fce5b78@oracle.com>



On 23/03/2020 19:39, Chris Hegarty wrote:
>
>> On 23 Mar 2020, at 19:18, Alan Bateman <Alan.Bateman at oracle.com 
>> <mailto:Alan.Bateman at oracle.com>> wrote:
>>
>>> ...
>>>
>> Socket(SocketImpl) is only specified to do a permission check when 
>> the impl is non-null. The socket adaptor in JDK 12 and older releases 
>> doesn't have a dummy impl so the change should not be needed. If 
>> there is a security exception thrownhere then it suggests something 
>> may be broken elsewhere, do you have a stack trace?
>
> I suspect that only the ServerSocketAdapter part of the change is 
> needed, since ServerSocket(SocketImpl) does a security check 
> regardless of the value of the given SocketImpl.
>
The old ServerSocketAdapter implementation pre-dates that protected 
constructor. I don't have cycles to dig into what is going on in the 
update releases but if there is a security exception bring thrown in 
either case then it suggests that something is broken elsewhere.

-Alan

From Junyuan.Zheng at microsoft.com  Mon Mar 23 20:46:37 2020
From: Junyuan.Zheng at microsoft.com (Junyuan Zheng)
Date: Mon, 23 Mar 2020 20:46:37 +0000
Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
 or older
In-Reply-To: <AM0PR02MB571453669CA8951741C755F38AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <MWHPR21MB083096C1F557DF9983FF34AFE3F60@MWHPR21MB0830.namprd21.prod.outlook.com>,
 <AM0PR02MB571453669CA8951741C755F38AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <MWHPR21MB0830EA874686A34C7C2BA31CE3F00@MWHPR21MB0830.namprd21.prod.outlook.com>

Hi Christoph,

I have generated a patch for the jdk14u. And here is the diff:

```
--- a/make/autoconf/basics.m4
+++ b/make/autoconf/basics.m4
@@ -1303,12 +1303,25 @@ AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
       AC_MSG_CHECKING([if codesign certificate is present])
       $RM codesign-testfile
       $TOUCH codesign-testfile
-      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
+      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile 2>&AS_MESSAGE_LOG_FD \
+          >&AS_MESSAGE_LOG_FD || CODESIGN=
       $RM codesign-testfile
       if test "x$CODESIGN" = x; then
         AC_MSG_RESULT([no])
       else
         AC_MSG_RESULT([yes])
+        # Verify that the codesign has --option runtime
+        AC_MSG_CHECKING([if codesign has --option runtime])
+        $RM codesign-testfile
+        $TOUCH codesign-testfile
+        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile \
+            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
+        $RM codesign-testfile
+        if test "x$CODESIGN" = x; then
+          AC_MSG_ERROR([codesign does not have --option runtime. macOS 10.13.6 and above is required.])
+        else
+          AC_MSG_RESULT([yes])
+        fi
       fi
     fi
     BASIC_REQUIRE_PROGS(SETFILE, SetFile)
```

Please let me know what you think.

Thanks!

Junyuan

________________________________________
From: Langer, Christoph <christoph.langer at sap.com>
Sent: Wednesday, March 18, 2020 1:05 PM
To: Junyuan Zheng; jdk-updates-dev at openjdk.java.net
Subject: [EXTERNAL] RE: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5 or older

Hi Junyuan,

I think this looks good. I can approve&sponsor this for you. I think we want to get this into jdk14u as well.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Junyuan Zheng
> Sent: Dienstag, 17. M?rz 2020 19:22
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
> or older
>
> Hi,
>
> I would like to backport JDK-8240972
> ("macOS codesign fail on macOS 10.13.5 or older") to 11u.
>
> The original patch cannot be applied to 11u directly because of the change
> JDK-8239708 (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8239708&amp;data=02%7C01%7CJunyuan.Zheng%40microsoft.com%7Cfa3c24116cbe44e9c2cd08d7cb77d3e9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637201587835476295&amp;sdata=PZPabAz5YweihzLxc4yh4%2BgtKbW3528k86BrTgevjLg%3D&amp;reserved=0).
>
> And here is the diff based on the current code:
>
> ```
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -1228,12 +1228,25 @@
> AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
>        AC_MSG_CHECKING([if codesign certificate is present])
>        $RM codesign-testfile
>        $TOUCH codesign-testfile
> -      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD \
> +          >&AS_MESSAGE_LOG_FD || CODESIGN=
>        $RM codesign-testfile
>        if test "x$CODESIGN" = x; then
>          AC_MSG_RESULT([no])
>        else
>          AC_MSG_RESULT([yes])
> +        # Verify that the codesign has --option runtime
> +        AC_MSG_CHECKING([if codesign has --option runtime])
> +        $RM codesign-testfile
> +        $TOUCH codesign-testfile
> +        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY"
> codesign-testfile \
> +            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +        $RM codesign-testfile
> +        if test "x$CODESIGN" = x; then
> +          AC_MSG_ERROR([codesign does not have --option runtime. macOS
> 10.13.6 and above is required.])
> +        else
> +          AC_MSG_RESULT([yes])
> +        fi
>        fi
>      fi
>      BASIC_REQUIRE_PROGS(SETFILE, SetFile)
> ```
>
> I also need a sponsor for this patch. Please let me know what you think.
>
> Thanks,
>
> Junyuan

From christoph.langer at sap.com  Tue Mar 24 06:28:22 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 06:28:22 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com>
References: <16C954D4-75BC-4296-ACAF-66ACB8B7716D@amazon.com>
Message-ID: <AM0PR02MB57143E07481BA9CE1A967B7E8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Paul,

as Martin said, the original bug could not be opened by Oracle. I, however changed the bug created by Martin to a Backport item. Doing it that way would allow a "standard" backport of such type of issues while the original item that was pushed to head can remain invisible. We proceeded like that with other bugs already and it proved to work nicely.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
> Of Hohensee, Paul
> Sent: Montag, 23. M?rz 2020 19:29
> To: Doerr, Martin <martin.doerr at sap.com>; core-libs-
> dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> The changeset references JDK-8223326, which is private. If possible, ask
> Oracle to make it public so we can do a normal backport rather than file an
> 11u-specific issue. The backport itself looks fine.
> 
> Thanks,
> Paul
> 
> ?On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" <jdk-
> updates-dev-bounces at openjdk.java.net on behalf of
> martin.doerr at sap.com> wrote:
> 
> 
>     Hi,
> 
>     I'd like to backport JDK-8223326 from jdk/jdk.
> 
>     11u backport issue:
>     https://bugs.openjdk.java.net/browse/JDK-8241460
> 
>     Original change:
>     https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
> 
>     11u backport webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
> 
>     I had to integrate the change manually due to context changes. However,
> the new code fits to the 11u versions.
> 
>     Please review.
> 
>     Best regards,
>     Martin
> 
> 


From christoph.langer at sap.com  Tue Mar 24 06:39:57 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 06:39:57 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <158204ba-d27b-8464-e1bf-edf3328c067d@oracle.com>
Message-ID: <AM0PR02MB57143AB3AA07E03D78E355BC8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Alan,

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Alan Bateman
> Sent: Montag, 23. M?rz 2020 20:19
> To: Doerr, Martin <martin.doerr at sap.com>; core-libs-
> dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> On 23/03/2020 18:07, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to backport JDK-8223326 from jdk/jdk.
> >
> > 11u backport issue:
> > https://bugs.openjdk.java.net/browse/JDK-8241460
> >
> > Original change:
> > https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
> >
> > 11u backport webrev:
> > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
> >
> > I had to integrate the change manually due to context changes. However,
> the new code fits to the 11u versions.
> >
> > Please review.
> >
> Socket(SocketImpl) is only specified to do a permission check when the
> impl is non-null. The socket adaptor in JDK 12 and older releases
> doesn't have a dummy impl so the change should not be needed. If there
> is a security exception thrownhere then it suggests something may be
> broken elsewhere, do you have a stack trace?

I think you are completely right, that change is not required for 11u as it stands.

ServerSocketAdaptor::create in 11u would never enter a path that does a permission check and for SocketAdaptor:create the Socket constructor is called with a null impl, so checkPermission(null) will immediately return null.

We also don't have an indication that something is broken. My team is just doing an exercise to go through private JBS bugs that have been resolved in jdk/jdk after JDK11 was released and tries to asses which ones should/need to go into OpenJDK 11 updates, too. That's because we wouldn't see when Oracle would backport such bugs for their Oracle 11 Updates and we fear we'd miss something important otherwise.

But I suggest to withdraw this backport of JDK-8223326 and set JDK-8241460 to "Won't Fix".

Best regards
Christoph


From christoph.langer at sap.com  Tue Mar 24 06:42:25 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 06:42:25 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
Message-ID: <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Alan,

> On 23/03/2020 18:07, Doerr, Martin wrote:
> > Hi,
> >
> > I'd like to backport JDK-8223326 from jdk/jdk.
> >
> One other thing on this. It looks like the spec changes that were part
> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
> mistake. Is that part of the issue that you are trying to fix?

I can't find/access JDK-8218573 and I also struggle to find a changelist that would resolve it (should it be a private bug). Did you misspell the number? Please help me.

Thanks
Christoph


From Alan.Bateman at oracle.com  Tue Mar 24 07:33:46 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2020 07:33:46 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
 <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>



On 24/03/2020 06:42, Langer, Christoph wrote:
> Hi Alan,
>
>> On 23/03/2020 18:07, Doerr, Martin wrote:
>>> Hi,
>>>
>>> I'd like to backport JDK-8223326 from jdk/jdk.
>>>
>> One other thing on this. It looks like the spec changes that were part
>> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
>> mistake. Is that part of the issue that you are trying to fix?
> I can't find/access JDK-8218573 and I also struggle to find a changelist that would resolve it (should it be a private bug). Did you misspell the number? Please help me.
>
JDK-8218573 was a security fix (restricted in JBS). The spec update for 
Java SE 13+ that was part of that change have found their way into the 
jdk11u-dev repo, the change for JDK 12 and older should have not 
included the spec change.

https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480

-Alan.

From Alan.Bateman at oracle.com  Tue Mar 24 07:56:27 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2020 07:56:27 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
 <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
Message-ID: <63c12a33-f9ec-90dd-bec4-ec23249a4a9c@oracle.com>

On 24/03/2020 07:33, Alan Bateman wrote:
>
> The spec update for Java SE 13+ that was part of that change have 
> found their way into the jdk11u-dev repo,
Sorry, I mean Java SE 14. It seems the spec change was accidentally 
pushed to 13.0.1 too.

-Alan


From christoph.langer at sap.com  Tue Mar 24 08:19:12 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 08:19:12 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
 <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
Message-ID: <AM0PR02MB57149294C60D12486738B9C68AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

> >> One other thing on this. It looks like the spec changes that were part
> >> of JDK-8218573 have been backported to jdk-updates/jdk11u-dev by
> >> mistake. Is that part of the issue that you are trying to fix?
> > I can't find/access JDK-8218573 and I also struggle to find a changelist that
> would resolve it (should it be a private bug). Did you misspell the number?
> Please help me.
> >
> JDK-8218573 was a security fix (restricted in JBS). The spec update for
> Java SE 13+ that was part of that change have found their way into the
> jdk11u-dev repo, the change for JDK 12 and older should have not
> included the spec change.
> 
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480

Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the only place where I was looking for JDK-8218573, so I couldn't find it.

By spec part you mean the "@throws SecurityException" sections? Do you think those should not have been part of the 11u/13u change? Should these be even rolled back?

Thanks
Christoph

From yan at azul.com  Tue Mar 24 08:48:10 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Tue, 24 Mar 2020 11:48:10 +0300
Subject: [13u] RFR: 8241489: restore missed in backports tests for 8229016,
 8239787
Message-ID: <18d03b9b-3ca1-873e-9046-9c52dfadb5a7@azul.com>

Hi,

I did a silly mistake pushing hotspot backports of 8229016, 8239787 to 13u: missed the new tests.
There's no webrev in this RFR: the tests are, for instance, in jdk14 in changesets
1d2ea8db7083
and
a3a462ce27cd
correspondingly.

Please approve a separate push.

Sorry!
--yan


From dcherepanov at azul.com  Tue Mar 24 08:53:25 2020
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Tue, 24 Mar 2020 11:53:25 +0300
Subject: [13u] RFR: 8241489: restore missed in backports tests for
 8229016, 8239787
In-Reply-To: <18d03b9b-3ca1-873e-9046-9c52dfadb5a7@azul.com>
References: <18d03b9b-3ca1-873e-9046-9c52dfadb5a7@azul.com>
Message-ID: <402d9254-e146-28fd-9db4-bc8237b020c9@azul.com>

Hi Yuri,

Would you mind including webrev into this request?

Thanks,

Dmitry

On 3/24/20 11:48 AM, Yuri Nesterenko wrote:
> Hi,
>
> I did a silly mistake pushing hotspot backports of 8229016, 8239787 to 13u: missed the new tests.
> There's no webrev in this RFR: the tests are, for instance, in jdk14 in changesets
> 1d2ea8db7083
> and
> a3a462ce27cd
> correspondingly.
>
> Please approve a separate push.
>
> Sorry!
> --yan


From yan at azul.com  Tue Mar 24 08:58:06 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Tue, 24 Mar 2020 11:58:06 +0300
Subject: [13u] RFR: 8241489: restore missed in backports tests for
 8229016, 8239787
In-Reply-To: <402d9254-e146-28fd-9db4-bc8237b020c9@azul.com>
References: <18d03b9b-3ca1-873e-9046-9c52dfadb5a7@azul.com>
 <402d9254-e146-28fd-9db4-bc8237b020c9@azul.com>
Message-ID: <17992308-b2e9-e3f2-d5c4-d0e1ab67f929@azul.com>

OK, you are right:
http://cr.openjdk.java.net/~yan/8241489/webrev.0/

Thanks,
--yan

On 24.03.2020 11:53, Dmitry Cherepanov wrote:
> Hi Yuri,
> 
> Would you mind including webrev into this request?
> 
> Thanks,
> 
> Dmitry
> 
> On 3/24/20 11:48 AM, Yuri Nesterenko wrote:
>> Hi,
>>
>> I did a silly mistake pushing hotspot backports of 8229016, 8239787 to 13u: missed the new tests.
>> There's no webrev in this RFR: the tests are, for instance, in jdk14 in changesets
>> 1d2ea8db7083
>> and
>> a3a462ce27cd
>> correspondingly.
>>
>> Please approve a separate push.
>>
>> Sorry!
>> --yan


From dcherepanov at azul.com  Tue Mar 24 09:01:08 2020
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Tue, 24 Mar 2020 12:01:08 +0300
Subject: [13u] RFR: 8241489: restore missed in backports tests for
 8229016, 8239787
In-Reply-To: <17992308-b2e9-e3f2-d5c4-d0e1ab67f929@azul.com>
References: <18d03b9b-3ca1-873e-9046-9c52dfadb5a7@azul.com>
 <402d9254-e146-28fd-9db4-bc8237b020c9@azul.com>
 <17992308-b2e9-e3f2-d5c4-d0e1ab67f929@azul.com>
Message-ID: <3862c982-1925-6500-068b-982e0b88dd5b@azul.com>

Looks good to me.

Thanks,

Dmitry

On 3/24/20 11:58 AM, Yuri Nesterenko wrote:
> OK, you are right:
> http://cr.openjdk.java.net/~yan/8241489/webrev.0/
>
> Thanks,
> --yan
>
> On 24.03.2020 11:53, Dmitry Cherepanov wrote:
>> Hi Yuri,
>>
>> Would you mind including webrev into this request?
>>
>> Thanks,
>>
>> Dmitry
>>
>> On 3/24/20 11:48 AM, Yuri Nesterenko wrote:
>>> Hi,
>>>
>>> I did a silly mistake pushing hotspot backports of 8229016, 8239787 to 13u: missed the new tests.
>>> There's no webrev in this RFR: the tests are, for instance, in jdk14 in changesets
>>> 1d2ea8db7083
>>> and
>>> a3a462ce27cd
>>> correspondingly.
>>>
>>> Please approve a separate push.
>>>
>>> Sorry!
>>> --yan


From Alan.Bateman at oracle.com  Tue Mar 24 09:53:06 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 24 Mar 2020 09:53:06 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <AM0PR02MB57149294C60D12486738B9C68AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
 <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
 <AM0PR02MB57149294C60D12486738B9C68AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com>

On 24/03/2020 08:19, Langer, Christoph wrote:
>
> Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the only place where I was looking for JDK-8218573, so I couldn't find it.
I don't have time to dig into this tangled web but it does appear that a 
backport issue was used instead of the main issue in at least one case. 
That might be part of the confusion with the JBS issues. It also appears 
that JDK-8223326 has been backported to several releases where it is not 
applicable.

>
> By spec part you mean the "@throws SecurityException" sections? Do you think those should not have been part of the 11u/13u change? Should these be even rolled back?
>
The spec changes to NetPermission and the protected Socket constructor 
should not be in the update releases. If a security fix involves a spec 
clarification then a good starting assumption is that the scope of the 
change for the update releases, if applicable, will be bit different.

-Alan.


From martin.doerr at sap.com  Tue Mar 24 10:21:30 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Mar 2020 10:21:30 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
 <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
 <AM0PR02MB57149294C60D12486738B9C68AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com>
Message-ID: <AM0PR0202MB32975F5B846538E3FB02E85F9AF10@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Thanks a lot for looking into this, Alan, Chris and Christoph!

We had also looked at 
"8217997: Better socket support": https://hg.openjdk.java.net/jdk/jdk/rev/94710bb2a5bb
which was backported as
"8218573: Better socket support": http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480
with the spec update.
It's not so easy to understand which changes need to get backportet and we should make sure we don't miss anything really important.

Thanks for shedding more light into the history.

I've closed it as "Not an Issue".

Best regards,
Martin


> -----Original Message-----
> From: Alan Bateman <Alan.Bateman at oracle.com>
> Sent: Dienstag, 24. M?rz 2020 10:53
> To: Langer, Christoph <christoph.langer at sap.com>; Doerr, Martin
> <martin.doerr at sap.com>; core-libs-dev at openjdk.java.net; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
> java.security.AccessControlException: access denied
> ("java.net.NetPermission" "setSocketImpl")
> 
> On 24/03/2020 08:19, Langer, Christoph wrote:
> >
> > Ah, I see... JDK-8218573 is JDK11u/JDK13u specific. Looks like it was derived
> from JDK-8217997 in jdk/jdk but pushed as a different bug. jdk/jdk was the
> only place where I was looking for JDK-8218573, so I couldn't find it.
> I don't have time to dig into this tangled web but it does appear that a
> backport issue was used instead of the main issue in at least one case.
> That might be part of the confusion with the JBS issues. It also appears
> that JDK-8223326 has been backported to several releases where it is not
> applicable.
> 
> >
> > By spec part you mean the "@throws SecurityException" sections? Do you
> think those should not have been part of the 11u/13u change? Should these
> be even rolled back?
> >
> The spec changes to NetPermission and the protected Socket constructor
> should not be in the update releases. If a security fix involves a spec
> clarification then a good starting assumption is that the scope of the
> change for the update releases, if applicable, will be bit different.
> 
> -Alan.


From christoph.langer at sap.com  Tue Mar 24 10:55:02 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 10:55:02 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
In-Reply-To: <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com>
References: <AM0PR0202MB32978F91C77C30CC5849A1BE9AF00@AM0PR0202MB3297.eurprd02.prod.outlook.com>
 <b58feac0-f1d6-8322-716f-47e2015d34c3@oracle.com>
 <AM0PR02MB57149CC29847CD3FB921FAE18AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <19481ca4-158e-a0bb-25d5-be14f9c36348@oracle.com>
 <AM0PR02MB57149294C60D12486738B9C68AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <5badfad0-14c8-e4a2-62ed-57f838767e3e@oracle.com>
Message-ID: <AM0PR02MB571412B88DB64D8ECCE456718AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

> > By spec part you mean the "@throws SecurityException" sections? Do you
> think those should not have been part of the 11u/13u change? Should these
> be even rolled back?
> >
> The spec changes to NetPermission and the protected Socket constructor
> should not be in the update releases. If a security fix involves a spec
> clarification then a good starting assumption is that the scope of the
> change for the update releases, if applicable, will be bit different.

Ok, makes sense. I wasn't involved in the security fix and its backport, though. But I assume should now leave the fix for JDK-8218573: "Better socket support" (http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/c7602effc480) alone now?

/Christoph


From matthias.baesken at sap.com  Tue Mar 24 11:25:37 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 24 Mar 2020 11:25:37 +0000
Subject: [11u]: RFR: 8237192: Generate stripped/public pdbs on Windows for
 jdk images
References: <AM0PR02MB5714B8BF2B2AA982B98C4B4A8AF50@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57146A549EEEDE6B45E7D9DF8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB4227A3EE573E4CE6E508EA5093F10@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello Christoph, the downport looks good to me .


And btw. , we might consider a 11u-dev  downport of   "isTargetOs" and the related "is..."  from Util.gmk   (but  with a separate change ) .

Best regards, Matthias

From: Langer, Christoph
Sent: Freitag, 20. M?rz 2020 15:50
To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
Subject: [11u]: RFR: 8237192: Generate stripped/public pdbs on Windows for jdk images

Hi,

please help to review a backport of JDK-8237192 Generate stripped/public pdbs on Windows for jdk images to OpenJDK 11.

Bug: https://bugs.openjdk.java.net/browse/JDK-8237192
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/9b999cf5e13a
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237192.11u/

Apart from resolving some copyright year changes, I had to trivially resolve some hunks in  make/common/NativeCompilation.gmk, make/launcher/Launcher-java.base.gmk and make/scripts/compare.sh. In NativeCompilation.gmk, the variable $1_SYMBOLS_DIR of the original change had to be replaced with the equivalent $1_OUTPUT_DIR. Furthermore I had to replace calls to "isTargetOs" in the makefiles with equivalent constructs since that function is not available in 11.

Thanks
Christoph


From akashche at redhat.com  Tue Mar 24 11:28:45 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 24 Mar 2020 11:28:45 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with proxy
Message-ID: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>

Hi,

Please review the backport of JDK-8183369 to 11u:

Bug: https://bugs.openjdk.java.net/browse/JDK-8183369

Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0

11u webrev: http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/

Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy 
test was adjusted because mainline changes depend on JDK-8227539 that 
was added in 14.

-- 
-Alex


From christoph.langer at sap.com  Tue Mar 24 12:14:37 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 12:14:37 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <968d9565-2baa-01d2-aa4c-48678d013835@redhat.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
 <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
 <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>
 <968d9565-2baa-01d2-aa4c-48678d013835@redhat.com>
Message-ID: <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Doug and Andrew,

thanks for bringing this discussion to the current point.

Unfortunately, I believe the latest replies from Doug didn't go to the list - but Andrew has cited them ??

So, I understand that the changes comprised by the big bulk change of labs-openjdk-11 - https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d are first and foremost necessary to enable the usage of libgraal from the oracle/graal repo in JDK11. If OpenJDK 11 Updates doesn't have the changes, libgraal can't be used with it. Correct?

I also see a second potential motivation why OpenJDK 11 updates could be interested to incorporate those kind of changes. This is to be on par with the main Oracle JDK 11 Updates release. I think I mentioned that in my initial mail but it hasn't been part of the recent discussion between the both of you, Andrew and Doug. So, while we don't exactly know what Oracle did to their JDK11 Updates codebase, the backports of subsequent changes indicate that they must have incorporated something like the big bulk change of labs-openjdk-11. That would mean their in-tree Graal code of 11u is at the newer JDK13 level and hence the AOT and C2 replacement scenarios would have received those substantial updates.

On the other hand, I think for 11u we should be cautious and err on the side of stability. That would mean we deliberately don't pull those JVMCI and Graal updates into 11u. I think that's a bit the direction this discussion was moving to.

In any case, putting the general decision aside, I also believe, that the monolith commit is not the right way to get the changes into the OpenJDK 11 Updates project. When I was trying it on JDK11u, it was more of an exploration for me. But if we're going to do the exercise of updating Graal and JVMCI in OpenJDK11u to the JDK13 level, we should probably go change by change.

To enable this, I've created a JBS filter that contains all items Tom has mentioned in his list plus several Oracle 11.0.7 and 11.0.8 backports that we had to defer and which are not yet backported into JDK11u: https://bugs.openjdk.java.net/browse/JDK-8238758?filter=38696 

The list is sorted in descending order of commit time, so I guess if we process this list bottom up, we can probably achieve the current state JDK13 like state of labs-openjdk-11. Should some item be missing in this list, please let me know and I'll add it.

Best regards
Christoph


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Dinn
> Sent: Montag, 23. M?rz 2020 18:52
> To: Doug Simon <doug.simon at oracle.com>
> Cc: Thomas Wuerthinger <thomas.wuerthinger at oracle.com>; jdk-updates-
> dev at openjdk.java.net; Tom Rodriguez <tom.rodriguez at oracle.com>
> Subject: Re: [11u] RFC: Update Graal in OpenJDK 11 Updates?
> 
> On 23/03/2020 16:56, Doug Simon wrote:
> > That is a good summary. Indeed, libgraal is only a compilation time and
> > resource optimization and thus not necessary for GraalVM.
> 
> Ok, glad to know I didn't misrepresent anything :-)
> 
> > Note that the JDK11 based Travis gates run on?openjdk11
> > <https://github.com/oracle/graal/blob/master/.travis.yml#L17>?so we
> > should recognize any regression of the GraalVM compiler there (as we
> > did?recently
> > <https://github.com/oracle/graal/pull/2278#issuecomment-602513391>).
> > That said, also note that the Travis gate does not include any native
> > image tests. That would require use of open-labsjdk-11 for access to the
> > static libs.
> 
> Sure, we recognize that. You use of stockjdk11u in the gate is a great
> help. As for native image, Red Hat expects to be ramping up testing on
> OpenJDK jdk11u now that we are able to use it. So we should be able to
> catch issues and hopefully either suggest fixes them or, at least,
> report them back to you upstream in a timely fashion.
> 
> > It?s also worth pointing out that we?re also working with the HotSpot
> > team at Oracle to ensure any JVMCI change we?re pushing into 11 also
> > goes into JDK 15 where relevant.
> Yes of course and we appreciate that effort.
> 
> 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 christoph.langer at sap.com  Tue Mar 24 12:36:50 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 12:36:50 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
References: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
Message-ID: <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Alex,

I think this looks good overall.

There's one line in test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85, where you got the indentation wrong. Please check and fix that.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Alex Kashchenko
> Sent: Dienstag, 24. M?rz 2020 12:29
> To: jdk-updates-dev at openjdk.java.net
> Cc: net-dev at openjdk.java.net
> Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
> proxy
> 
> Hi,
> 
> Please review the backport of JDK-8183369 to 11u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
> 
> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
> 
> 11u webrev:
> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
> 
> Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy
> test was adjusted because mainline changes depend on JDK-8227539 that
> was added in 14.
> 
> --
> -Alex


From christoph.langer at sap.com  Tue Mar 24 12:37:20 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 12:37:20 +0000
Subject: [11u]: RFR: 8237192: Generate stripped/public pdbs on Windows for
 jdk images
In-Reply-To: <AM0PR02MB4227A3EE573E4CE6E508EA5093F10@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714B8BF2B2AA982B98C4B4A8AF50@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57146A549EEEDE6B45E7D9DF8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB4227A3EE573E4CE6E508EA5093F10@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB571491A6384E5872C18F4EDA8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks for the review, Matthias.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Baesken, Matthias
> Sent: Dienstag, 24. M?rz 2020 12:26
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] RE: [11u]: RFR: 8237192: Generate stripped/public pdbs
> on Windows for jdk images
> 
> Hello Christoph, the downport looks good to me .
> 
> 
> And btw. , we might consider a 11u-dev  downport of   "isTargetOs" and the
> related "is..."  from Util.gmk   (but  with a separate change ) .
> 
> Best regards, Matthias
> 
> From: Langer, Christoph
> Sent: Freitag, 20. M?rz 2020 15:50
> To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-
> dev at openjdk.java.net>
> Subject: [11u]: RFR: 8237192: Generate stripped/public pdbs on Windows for
> jdk images
> 
> Hi,
> 
> please help to review a backport of JDK-8237192 Generate stripped/public
> pdbs on Windows for jdk images to OpenJDK 11.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8237192
> Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/9b999cf5e13a
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8237192.11u/
> 
> Apart from resolving some copyright year changes, I had to trivially resolve
> some hunks in  make/common/NativeCompilation.gmk,
> make/launcher/Launcher-java.base.gmk and make/scripts/compare.sh. In
> NativeCompilation.gmk, the variable $1_SYMBOLS_DIR of the original change
> had to be replaced with the equivalent $1_OUTPUT_DIR. Furthermore I had
> to replace calls to "isTargetOs" in the makefiles with equivalent constructs
> since that function is not available in 11.
> 
> Thanks
> Christoph


From sgehwolf at redhat.com  Tue Mar 24 12:49:32 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 24 Mar 2020 13:49:32 +0100
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
 <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
 <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>
 <968d9565-2baa-01d2-aa4c-48678d013835@redhat.com>
 <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <7404ab1d2037893619346323e007a50da3852b35.camel@redhat.com>

On Tue, 2020-03-24 at 12:14 +0000, Langer, Christoph wrote:
> To enable this, I've created a JBS filter that contains all items Tom
> has mentioned in his list plus several Oracle 11.0.7 and 11.0.8
> backports that we had to defer and which are not yet backported into
> JDK11u: https://bugs.openjdk.java.net/browse/JDK-8238758?filter=38696
>  

Thanks Christoph! That filter is very useful.

Cheers,
Severin


From hohensee at amazon.com  Tue Mar 24 13:36:11 2020
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 24 Mar 2020 13:36:11 +0000
Subject: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
 java.security.AccessControlException: access denied ("java.net.NetPermission"
 "setSocketImpl")
Message-ID: <7CBCC096-6FCF-4D89-A2EE-366B4B780371@amazon.com>

Thanks for the explanation of the process.

Paul

?On 3/23/20, 11:28 PM, "Langer, Christoph" <christoph.langer at sap.com> wrote:
    
    Hi Paul,
    
    as Martin said, the original bug could not be opened by Oracle. I, however changed the bug created by Martin to a Backport item. Doing it that way would allow a "standard" backport of such type of issues while the original item that was pushed to head can remain invisible. We proceeded like that with other bugs already and it proved to work nicely.
    
    Best regards
    Christoph
    
    > -----Original Message-----
    > From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> On Behalf
    > Of Hohensee, Paul
    > Sent: Montag, 23. M?rz 2020 19:29
    > To: Doerr, Martin <martin.doerr at sap.com>; core-libs-
    > dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
    > Subject: RE: [11u] RFR(S): 8223326: Regression introduced by CPU sync:
    > java.security.AccessControlException: access denied
    > ("java.net.NetPermission" "setSocketImpl")
    >
    > The changeset references JDK-8223326, which is private. If possible, ask
    > Oracle to make it public so we can do a normal backport rather than file an
    > 11u-specific issue. The backport itself looks fine.
    >
    > Thanks,
    > Paul
    >
    > On 3/23/20, 11:08 AM, "jdk-updates-dev on behalf of Doerr, Martin" <jdk-
    > updates-dev-bounces at openjdk.java.net on behalf of
    > martin.doerr at sap.com> wrote:
    >
    >
    >     Hi,
    >
    >     I'd like to backport JDK-8223326 from jdk/jdk.
    >
    >     11u backport issue:
    >     https://bugs.openjdk.java.net/browse/JDK-8241460
    >
    >     Original change:
    >     https://hg.openjdk.java.net/jdk/jdk/rev/29624901d8bc
    >
    >     11u backport webrev:
    >
    > http://cr.openjdk.java.net/~mdoerr/8223326_nio_socket_11u/webrev.00/
    >
    >     I had to integrate the change manually due to context changes. However,
    > the new code fits to the 11u versions.
    >
    >     Please review.
    >
    >     Best regards,
    >     Martin
    >
    >
    
    


From adinn at redhat.com  Tue Mar 24 14:43:30 2020
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 24 Mar 2020 14:43:30 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
 <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
 <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>
 <968d9565-2baa-01d2-aa4c-48678d013835@redhat.com>
 <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <e478ecab-d922-fdc4-48d3-102396f06cc9@redhat.com>

Hi Christoph,

On 24/03/2020 12:14, Langer, Christoph wrote:
> thanks for bringing this discussion to the current point.

> Unfortunately, I believe the latest replies from Doug didn't go to
> the list - but Andrew has cited them ??

Doug did copy his reply to the list but, of course, he is not
subscribed. His replies came direct to me of course. They may well be
waiting for a list moderator to allow them to proceed to the rest of the
list.

> So, I understand that the changes comprised by the big bulk change of
> labs-openjdk-11 -
> https://github.com/graalvm/labs-openjdk-11/commit/fbbdf5f15300716110d2ac9b9bd7f70b03b35a7d
> are first and foremost necessary to enable the usage of libgraal from
> the oracle/graal repo in JDK11. If OpenJDK 11 Updates doesn't have
> the changes, libgraal can't be used with it. Correct?

That appears to be the sum of what has changed. Of course, there is
always the possibility that some details of how that is done turn out be
important.

Indeed, Red Hat has just discovered one interesting wrinkle which might
be important:

The upstream patch that implements the bulk of the support for libgraal
(JDK-8220623) included changes to JVMCI code that resolves queries about
the structure of the underlying Hotspot code base things like listing
methods or fields of a resolved java type etc. In the jdk11u code that
is done by accessing the Java Class<?> and using java.lang.reflect APIs.
In the patch this is modified to use native calls that access the C++
types Klass, Method etc. One of the consequences of that is a difference
in how class bytecode gets loaded and resolved. The use of
java.lang.reflect require resolution of classes and so may perform
bytecode load for dependent classes earlier than happens whne querying
the C++ Klass model.

As a consequence, when running on OpenJDK jdk11u (i.e. without the
libgraal patch) the pointsto analysis traversal of the class base may
try to load bytecode for edge classes that not actually needed in the
closed world model while on the labs jdk11u the classbase query may not
need to load that bytecode. In some cases this may lead to a
ClassNotFoundException on stock jdk11u which does not happen on labs
jdk11u. Of course, this can usually be resolved by adding more jars to
the classpath.

Now I don't think that the above problem necessarily automatically
justifies backporting the libgraal patch -- note that just as regards
this specific part of the change that involves exporting to the JVCMI
module JNI access to the underlying JVM Klass model. However, it does
mean that users will encounter different behaviour on stock jdk11u even
when working with the current GraalVM code base.

> I also see a second potential motivation why OpenJDK 11 updates could
> be interested to incorporate those kind of changes. This is to be on
> par with the main Oracle JDK 11 Updates release. I think I mentioned
> that in my initial mail but it hasn't been part of the recent
> discussion between the both of you, Andrew and Doug. So, while we
> don't exactly know what Oracle did to their JDK11 Updates codebase,
> the backports of subsequent changes indicate that they must have
> incorporated something like the big bulk change of labs-openjdk-11.
> That would mean their in-tree Graal code of 11u is at the newer JDK13
> level and hence the AOT and C2 replacement scenarios would have
> received those substantial updates.

I'm not sure about this but I don't think the specific path I mention
above has been backported to Oracle's jdk11u.

> On the other hand, I think for 11u we should be cautious and err on
> the side of stability. That would mean we deliberately don't pull
> those JVMCI and Graal updates into 11u. I think that's a bit the
> direction this discussion was moving to.

Well, I think that's wise but I just wanted to note that it's about
balancing disparity in behaviors like the one described above against
the risk to non-Graal users.

> In any case, putting the general decision aside, I also believe, that
> the monolith commit is not the right way to get the changes into the
> OpenJDK 11 Updates project. When I was trying it on JDK11u, it was
> more of an exploration for me. But if we're going to do the exercise
> of updating Graal and JVMCI in OpenJDK11u to the JDK13 level, we
> should probably go change by change.

Oh we should definitely try to split out whatever we do backport from
that mega-patch so that it relates to the original upstream patches.
However, I'm not sure what it is we would actually need -- if any - from
that original set. I think we can only realistically answer that as we
progress in our tests of building Graal using the current jdk11u. If a
showstopper issue emerges we may want to consider backporting more
upstream jdk13u code but I think we need to judge every further patch on
its merits and the danger it presents to normal non-Graal uses.

> To enable this, I've created a JBS filter that contains all items Tom
> has mentioned in his list plus several Oracle 11.0.7 and 11.0.8
> backports that we had to defer and which are not yet backported into
> JDK11u: https://bugs.openjdk.java.net/browse/JDK-8238758?filter=38696

Thanks for doing that. I'll look at this and no doubt Severin also will.
We will also liaise with our Quarkus team to help pin down whether any
of these patches are really needed to fix issues with using stock jdk11u.

regards,


Andrew Dinn
-----------


From martijnverburg at gmail.com  Tue Mar 24 16:18:54 2020
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 24 Mar 2020 16:18:54 +0000
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
 <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
Message-ID: <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>

Hi all,

Could we create a project/tree/branch for this work (jdk11u-jfr-test or
some such) that a bunch of us could work on together to ensure the
stability and quality of the patch before it goes into 11u?

Cheers,
Martijn


On Mon, 23 Mar 2020 at 11:27, Mario Torre <neugens at redhat.com> wrote:

> Hi Ben!
>
> Of course I don't have concerns about people trying out things ;)
> However regarding having an approach similar to JFR in 8u I'm a bit
> more concerned, since the JFR patch had time to bake in and gave us a
> chance to fix issues. The streaming API is rather new and changes a
> lot of the internal, so we need to give it a bit of time to understand
> it.
>
> Personally, I need to study the code and see how having this
> implementation may affect backporting of fixes, but my take in general
> is that we had to backport JFR because this was a critical missing
> feature, but backporting every new feature to 8 or 11 is not
> advisable.
>
> I know I said previously that I would have liked to see the streaming
> backported, but the level of work required by the JFR backport has
> made me change my mind, I think we need to give a chance to JFR in 8u
> to be out in the wild for a bit before changing the implementation
> again. I'm considering that even if we are talking about 11 here, the
> change will most likely apply to 8u as well.
>
> Anyway, this is just my thinking, I'm not trying to veto the change,
> we should have a general agreement on what we want to do, if the
> maintainers decide this is worth the effort I'll certainly try to help
> like I did with the JFR backport.
>
> Cheers,
> Mario
>
> On Mon, Mar 23, 2020 at 12:01 PM Ben Evans <bevans at newrelic.com> wrote:
> >
> > Hi Mario,
> >
> > I think we're all in agreement about stability and ensuring that there
> are
> > no performance regressions.
> >
> > I was thinking that we could adopt the model that you used for the
> regular
> > JFR backport to OpenJDK 8 - starting off in a separate repo that can be
> > built by Adopt and consumed by enthusiasts that want to try it out. Do
> you
> > have any concerns about that? It seemed to work very well for that
> project
> > - and I would want to use the same sort of caution for Streaming-to-11.
> >
> > Andrew / Christoph / Severin: What would we need to do to get a separate
> > repo for Ali Baba / Microsoft / New Relic / AdoptOpenJDK / other
> interested
> > parties to investigate in further?
> >
> > Thanks,
> >
> > Ben
> >
> >
> > On Sat, Mar 21, 2020 at 1:52 AM Mario Torre <
> neugens.limasoftware at gmail.com>
> > wrote:
> >
> > > I agree, while this is certainly an interesting feature, we should
> > > probably let it bake a bit.
> > >
> > > I'm particularly concerned about stability and performance here.
> > >
> > > Cheers,
> > > Mario
> > >
> > > Il giorno gio 19 mar 2020 alle ore 12:24 Erik Gahlin
> > > <erik.gahlin at oracle.com> ha scritto:
> > >
> > > >
> > > > Hi,
> > > >
> > > > JDK 14 has been out for one day and few have used it in production.
> The
> > > > feature changes core aspects of the JFR implementation, such as the
> > > > tagging mechanism and the parser. Event streaming is not something
> that
> > > > can be turned on by an API call or a command line flag, it is always
> > > > there. If there are bugs, it will likely impact ordinary use of JFR
> as
> > > well.
> > > >
> > > > Erik
> > > >
> > > > > Hi team,
> > > > >
> > > > > JDK 14 is now Generally Available, as one of the features, JFR
> Event
> > > Streaming is very attractive for us.
> > > > >
> > > > > With JFR Event Streaming, we can more easily implement the
> continuous
> > > monitoring of Java application based on JFR in the container
> environment.
> > > > >
> > > > > So I would like to backport JDK-8226511(Implement JFR Event
> Streaming)
> > > to 11u, please help us to review the patch.
> > > > >
> > > > > Previously, we had a discussion at
> > >
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html
> ,
> > > there are many companies interested in this
> > > > >
> > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> > > > > Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> > > > > Test (release/slow-debug on Linux): All JFR Event Streaming passed,
> > > and other JFR tests have the same result with the build without this
> patch
> > > > >
> > > > > The original patch is large, and cannot be applied to 11u directly
> > > > > All files that cannot be derectly applied are as follows:
> > > > >      src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
> > > > >      src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp
> (dosn't
> > > exist in 11u)
> > > > >      test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java
> > > (dosn't exist in 11u, introduced in JDK-8213914)
> > > > >
> src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
> > > > >      src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
> > > > >      src/jdk.jfr/share/conf/jfr/profile.jfc
> > > > >      src/jdk.jfr/share/conf/jfr/default.jfc
> > > > >      src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
> > > > >      src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
> > > > >      src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> > > > >      src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
> > > > >      src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
> > > > >      src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
> > > > >
> > > src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
> > > (ClassLoaderDataGraph_lock doesn't exist in 11u)
> > > > >
> src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
> > > > >
> > > src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
> > > > >      src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
> > > > >      src/hotspot/share/jfr/utilities/jfrTypes.hpp
> > > > >      src/hotspot/share/jfr/support/jfrThreadLocal.cpp
> > > > >      src/hotspot/share/jfr/metadata/metadata.xml
> > > > >      src/hotspot/share/runtime/mutexLocker.cpp
> > > > >    test/jdk/ProblemList.txt
> > > > >
> > > > > Also, we want to backport some other related issues to 11u:
> > > > >      JDK-8233700: EventStream not closed
> > > > >      JDK-8229209: test for cross-process JFR event streaming
> > > > >      JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java
> should
> > > clean up files
> > > > >      JDK-8234684: JFR crashes when rotating the JFR output during
> > > assertion failure
> > > > >      JDK-8233870: JFR TestSetEndTime.java times out - onClose() is
> > > never called
> > > > >      JDK-8234888: EventStream::close doesn't abort streaming thread
> > > > >      JDK-8234671: JFR api/consumer/recordingstream/TestStart.java
> > > failed due to timeout at testStartTwice()
> > > > >      JDK-8235356: [TESTBUG] Disable 'producer is alive' check in
> JFR
> > > TestCrossProcessStreaming
> > > > >      JDK-8233111: Epoch shift synchronization point for Compiler
> > > threads
> > > > >      JDK-8234059: Stress test fails with "Unexpected Exception in
> > > thread JFR Event Stream"
> > > > >      JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and
> > > jdk.jfr.Recording::getFlushInterval
> > > > >      JDK-8236263: Remove experimental streaming events
> > > > > Most of them can directly apply to 11u, except 8233111, 8234059 and
> > > 8236263
> > > > >
> > > > > Cheers,
> > > > > Denghui Dong
> > >
> > >
> > >
> > > --
> > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> > > Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> > >
> > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> > > Proud GNU Classpath developer: http://www.classpath.org/
> > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/
> > >
> > > Please, support open standards:
> > > http://endsoftpatents.org/
> > >
> >
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>

From neugens at redhat.com  Tue Mar 24 16:30:38 2020
From: neugens at redhat.com (Mario Torre)
Date: Tue, 24 Mar 2020 17:30:38 +0100
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
 <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
 <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>
Message-ID: <CAJwKKmaoY-U8jEApyAGDDbYZ0cc8oH367qAoRJuASp3KZWt9bQ@mail.gmail.com>

On Tue, Mar 24, 2020 at 5:19 PM Martijn Verburg
<martijnverburg at gmail.com> wrote:
>
> Hi all,
>
> Could we create a project/tree/branch for this work (jdk11u-jfr-test or some such) that a bunch of us could work on together to ensure the stability and quality of the patch before it goes into 11u?

For the JFR backport we created a small team, most of us were, if not
full time, at least "stable" on the project. While anyone could join
and share some knowledge, review a patch, or contribute some work, a
stable team means we can ensure questions and reviews are done
correctly and timely (after all, this is what happens in OpenJDK as
well).

So the question here would be if there is enough of manpower to
dedicate to this project from the interested parties.

Denghui has already done the backport but my experience with JFR tells
me that work will be needed on top of this anyway.

If we have consensus that this should go into the release (from the
maintainers) and the we have a critical mass of developers that are
willing to dedicate to it, then we can request an incubator repository
like we did with the JFR backport.

In other words, we need to have some volunteers that understand this
may be a time intensive work for the next weeks or months, and that
will need to be maintained after this when it's merged.

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From akashche at redhat.com  Tue Mar 24 18:09:09 2020
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 24 Mar 2020 18:09:09 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
 <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <04315966-7931-293e-3341-f656ed3c3c37@redhat.com>

Hi Christoph,

On 03/24/2020 12:36 PM, Langer, Christoph wrote:
> Hi Alex,
> 
> I think this looks good overall.

Thanks for the review!

> 
> There's one line in test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85, where you got the indentation wrong. Please check and fix that.

Sorry for tabs on that line, not sure how they got there, updated webrev 
after :retab :

http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.01/

> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
>> Behalf Of Alex Kashchenko
>> Sent: Dienstag, 24. M?rz 2020 12:29
>> To: jdk-updates-dev at openjdk.java.net
>> Cc: net-dev at openjdk.java.net
>> Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
>> proxy
>>
>> Hi,
>>
>> Please review the backport of JDK-8183369 to 11u:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
>>
>> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
>>
>> 11u webrev:
>> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
>>
>> Patch to HttpURLConnection applies cleanly, patch to HttpURLConWithProxy
>> test was adjusted because mainline changes depend on JDK-8227539 that
>> was added in 14.
>>
>> --
>> -Alex
> 


-- 
-Alex


From aph at redhat.com  Tue Mar 24 18:55:29 2020
From: aph at redhat.com (Andrew Haley)
Date: Tue, 24 Mar 2020 18:55:29 +0000
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
 <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
 <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>
 <968d9565-2baa-01d2-aa4c-48678d013835@redhat.com>
 <AM0PR02MB5714F3EB6957B842D9F9AE578AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <2e83a478-3e6c-2cb1-7cfb-48bf932c1427@redhat.com>

On 3/24/20 12:14 PM, Langer, Christoph wrote:

> I also see a second potential motivation why OpenJDK 11 updates
> could be interested to incorporate those kind of changes. This is to
> be on par with the main Oracle JDK 11 Updates release. I think I
> mentioned that in my initial mail but it hasn't been part of the
> recent discussion between the both of you, Andrew and Doug. So,
> while we don't exactly know what Oracle did to their JDK11 Updates
> codebase, the backports of subsequent changes indicate that they
> must have incorporated something like the big bulk change of
> labs-openjdk-11. That would mean their in-tree Graal code of 11u is
> at the newer JDK13 level and hence the AOT and C2 replacement
> scenarios would have received those substantial updates.

OK, but trying to match substantial updates that we can't see seems to
me like chasing smoke: we'll never get there.

> On the other hand, I think for 11u we should be cautious and err on
> the side of stability. That would mean we deliberately don't pull
> those JVMCI and Graal updates into 11u. I think that's a bit the
> direction this discussion was moving to.

Indeed. Also, we don't want the tail to wag the dog (rather than the
dog to wag the tail.) Graal, while very promising, is only one of the
many uses for 11u, and I don't want us to get into a situation where
the needs of Graal determine the future of the project.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From christoph.langer at sap.com  Tue Mar 24 19:35:11 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 19:35:11 +0000
Subject: Last 14u commit that was merged into 14.0.1 CPU repository
Message-ID: <AM0PR02MB5714C19898DE4AF8657600B78AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Rob,

can you please let the world know, which was the latest commit from jdk-updates/jdk14u that made it into the 14.0.1 CPU repository?

Thanks
Christoph


From christoph.langer at sap.com  Tue Mar 24 19:49:48 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 19:49:48 +0000
Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection with
 proxy
In-Reply-To: <04315966-7931-293e-3341-f656ed3c3c37@redhat.com>
References: <e70275b8-7f59-b511-a01d-7b0348a01df3@redhat.com>
 <AM0PR02MB57144D9FABE397B5CFA6EB6A8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <04315966-7931-293e-3341-f656ed3c3c37@redhat.com>
Message-ID: <AM0PR02MB571406679E1135D1478F936E8AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Alex,

looks good now.

Cheers
Christoph

> -----Original Message-----
> From: Alex Kashchenko <akashche at redhat.com>
> Sent: Dienstag, 24. M?rz 2020 19:09
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: net-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection
> with proxy
> 
> Hi Christoph,
> 
> On 03/24/2020 12:36 PM, Langer, Christoph wrote:
> > Hi Alex,
> >
> > I think this looks good overall.
> 
> Thanks for the review!
> 
> >
> > There's one line in
> test/jdk/java/net/HttpURLConnection/HttpURLConWithProxy.java, line 85,
> where you got the indentation wrong. Please check and fix that.
> 
> Sorry for tabs on that line, not sure how they got there, updated webrev
> after :retab :
> 
> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.01/
> 
> >
> > Best regards
> > Christoph
> >
> >> -----Original Message-----
> >> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net>
> On
> >> Behalf Of Alex Kashchenko
> >> Sent: Dienstag, 24. M?rz 2020 12:29
> >> To: jdk-updates-dev at openjdk.java.net
> >> Cc: net-dev at openjdk.java.net
> >> Subject: [11u] RFR: 8183369: RFC unconformity of HttpURLConnection
> with
> >> proxy
> >>
> >> Hi,
> >>
> >> Please review the backport of JDK-8183369 to 11u:
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8183369
> >>
> >> Original change: https://hg.openjdk.java.net/jdk/jdk/rev/0ba758a2b6f0
> >>
> >> 11u webrev:
> >> http://cr.openjdk.java.net/~akasko/jdk11u/8183369/webrev.00/
> >>
> >> Patch to HttpURLConnection applies cleanly, patch to
> HttpURLConWithProxy
> >> test was adjusted because mainline changes depend on JDK-8227539 that
> >> was added in 14.
> >>
> >> --
> >> -Alex
> >
> 
> 
> --
> -Alex


From martin.doerr at sap.com  Tue Mar 24 20:07:05 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Mar 2020 20:07:05 +0000
Subject: [CAUTION] RFR(XS): 8241464: [11u] Backport: make rehashing be a
 needed guaranteed safepoint cleanup action
In-Reply-To: <6401890E-B4B8-406B-A33D-6FBE6216228C@sap.com>
References: <6401890E-B4B8-406B-A33D-6FBE6216228C@sap.com>
Message-ID: <AM0PR0202MB3297A3D254598B92F4ACC2179AF10@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Lutz,

> your change looks good to me.
Thanks for the review!

> Maybe you want to add a small comment like "// Heal unbalanced hash
> (done at safepoint)."
Well, it is still a clean (partial) backport, not a new change, so I don't want to introduce a diff to the jdk/jdk version.

Best regards,
Martin


> -----Original Message-----
> From: Schmidt, Lutz <lutz.schmidt at sap.com>
> Sent: Dienstag, 24. M?rz 2020 21:00
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8241464: [11u] Backport: make rehashing be
> a needed guaranteed safepoint cleanup action
> 
> Hi Martin,
> 
> your change looks good to me.
> 
> Maybe you want to add a small comment like "// Heal unbalanced hash
> (done at safepoint)."
> 
> Thanks,
> Lutz
> 
> ?On 23.03.20, 20:06, "hotspot-runtime-dev on behalf of Doerr, Martin"
> <hotspot-runtime-dev-bounces at openjdk.java.net on behalf of
> martin.doerr at sap.com> wrote:
> 
>     Hi,
> 
>     I'd like to backport a part of JDK-8221967. I'm using a new bug because it's
> only a part of the original one.
>     Original change has the summary "Move redundant table lookup and make
> rehashing be a needed guaranteed safepoint cleanup action."
>     The first part of it doesn't apply to 11u, because the SymbolTable and
> StringTable parts are different in 11u and I don't see the need to change
> them.
> 
>     The second part of it does apply and makes perfect sense. Especially if
> BiasedLocking is disabled (11u BiasedLocking implementation requests more
> safepoints making this fix less important).
> 
>     Original bug:
>     https://bugs.openjdk.java.net/browse/JDK-8221967
> 
>     Original issue:
>     http://hg.openjdk.java.net/jdk/jdk/rev/2523496f5107
> 
>     New webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8221967_string_table_partial_backport
> _11u/webrev.00/
> 
>     Please review.
> 
>     Best regards,
>     Martin
> 
> 


From christoph.langer at sap.com  Tue Mar 24 20:09:15 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 20:09:15 +0000
Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
 or older
In-Reply-To: <MWHPR21MB0830EA874686A34C7C2BA31CE3F00@MWHPR21MB0830.namprd21.prod.outlook.com>
References: <MWHPR21MB083096C1F557DF9983FF34AFE3F60@MWHPR21MB0830.namprd21.prod.outlook.com>,
 <AM0PR02MB571453669CA8951741C755F38AF70@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <MWHPR21MB0830EA874686A34C7C2BA31CE3F00@MWHPR21MB0830.namprd21.prod.outlook.com>
Message-ID: <AM0PR02MB57147E5F603B8BC56DE5DBC08AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Junyuan,

thanks for also providing the backport for 14u. It looks good to me as well.

I requested jdk11 and jdk14 backport approval on your behalf now. Will sponsor it once we get the approvals.

Best regards
Christoph

> -----Original Message-----
> From: Junyuan Zheng <Junyuan.Zheng at microsoft.com>
> Sent: Montag, 23. M?rz 2020 21:47
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] backport JDK-8240972: macOS codesign fail on macOS
> 10.13.5 or older
> 
> Hi Christoph,
> 
> I have generated a patch for the jdk14u. And here is the diff:
> 
> ```
> --- a/make/autoconf/basics.m4
> +++ b/make/autoconf/basics.m4
> @@ -1303,12 +1303,25 @@
> AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
>        AC_MSG_CHECKING([if codesign certificate is present])
>        $RM codesign-testfile
>        $TOUCH codesign-testfile
> -      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> 2>&AS_MESSAGE_LOG_FD \
> +          >&AS_MESSAGE_LOG_FD || CODESIGN=
>        $RM codesign-testfile
>        if test "x$CODESIGN" = x; then
>          AC_MSG_RESULT([no])
>        else
>          AC_MSG_RESULT([yes])
> +        # Verify that the codesign has --option runtime
> +        AC_MSG_CHECKING([if codesign has --option runtime])
> +        $RM codesign-testfile
> +        $TOUCH codesign-testfile
> +        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY"
> codesign-testfile \
> +            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> +        $RM codesign-testfile
> +        if test "x$CODESIGN" = x; then
> +          AC_MSG_ERROR([codesign does not have --option runtime. macOS
> 10.13.6 and above is required.])
> +        else
> +          AC_MSG_RESULT([yes])
> +        fi
>        fi
>      fi
>      BASIC_REQUIRE_PROGS(SETFILE, SetFile)
> ```
> 
> Please let me know what you think.
> 
> Thanks!
> 
> Junyuan
> 
> ________________________________________
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Wednesday, March 18, 2020 1:05 PM
> To: Junyuan Zheng; jdk-updates-dev at openjdk.java.net
> Subject: [EXTERNAL] RE: [11u] backport JDK-8240972: macOS codesign fail on
> macOS 10.13.5 or older
> 
> Hi Junyuan,
> 
> I think this looks good. I can approve&sponsor this for you. I think we want to
> get this into jdk14u as well.
> 
> Best regards
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Junyuan Zheng
> > Sent: Dienstag, 17. M?rz 2020 19:22
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] backport JDK-8240972: macOS codesign fail on macOS 10.13.5
> > or older
> >
> > Hi,
> >
> > I would like to backport JDK-8240972
> > ("macOS codesign fail on macOS 10.13.5 or older") to 11u.
> >
> > The original patch cannot be applied to 11u directly because of the change
> > JDK-8239708
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbug
> s.openjdk.java.net%2Fbrowse%2FJDK-
> 8239708&amp;data=02%7C01%7CJunyuan.Zheng%40microsoft.com%7Cfa3c2
> 4116cbe44e9c2cd08d7cb77d3e9%7C72f988bf86f141af91ab2d7cd011db47%7C
> 1%7C0%7C637201587835476295&amp;sdata=PZPabAz5YweihzLxc4yh4%2Bgt
> KbW3528k86BrTgevjLg%3D&amp;reserved=0).
> >
> > And here is the diff based on the current code:
> >
> > ```
> > --- a/make/autoconf/basics.m4
> > +++ b/make/autoconf/basics.m4
> > @@ -1228,12 +1228,25 @@
> > AC_DEFUN_ONCE([BASIC_SETUP_COMPLEX_TOOLS],
> >        AC_MSG_CHECKING([if codesign certificate is present])
> >        $RM codesign-testfile
> >        $TOUCH codesign-testfile
> > -      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> > 2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD || CODESIGN=
> > +      $CODESIGN -s "$MACOSX_CODESIGN_IDENTITY" codesign-testfile
> > 2>&AS_MESSAGE_LOG_FD \
> > +          >&AS_MESSAGE_LOG_FD || CODESIGN=
> >        $RM codesign-testfile
> >        if test "x$CODESIGN" = x; then
> >          AC_MSG_RESULT([no])
> >        else
> >          AC_MSG_RESULT([yes])
> > +        # Verify that the codesign has --option runtime
> > +        AC_MSG_CHECKING([if codesign has --option runtime])
> > +        $RM codesign-testfile
> > +        $TOUCH codesign-testfile
> > +        $CODESIGN --option runtime -s "$MACOSX_CODESIGN_IDENTITY"
> > codesign-testfile \
> > +            2>&AS_MESSAGE_LOG_FD >&AS_MESSAGE_LOG_FD ||
> CODESIGN=
> > +        $RM codesign-testfile
> > +        if test "x$CODESIGN" = x; then
> > +          AC_MSG_ERROR([codesign does not have --option runtime. macOS
> > 10.13.6 and above is required.])
> > +        else
> > +          AC_MSG_RESULT([yes])
> > +        fi
> >        fi
> >      fi
> >      BASIC_REQUIRE_PROGS(SETFILE, SetFile)
> > ```
> >
> > I also need a sponsor for this patch. Please let me know what you think.
> >
> > Thanks,
> >
> > Junyuan

From christoph.langer at sap.com  Tue Mar 24 20:11:26 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 24 Mar 2020 20:11:26 +0000
Subject: [CAUTION] RFR(XS): 8241464: [11u] Backport: make rehashing be a
 needed guaranteed safepoint cleanup action
In-Reply-To: <AM0PR0202MB3297A3D254598B92F4ACC2179AF10@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <6401890E-B4B8-406B-A33D-6FBE6216228C@sap.com>
 <AM0PR0202MB3297A3D254598B92F4ACC2179AF10@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57143AE9BFF4C14B7F1FD2A08AF10@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Martin,

the backport looks good to me as well.

> > Maybe you want to add a small comment like "// Heal unbalanced hash
> > (done at safepoint)."
> Well, it is still a clean (partial) backport, not a new change, so I don't want to
> introduce a diff to the jdk/jdk version.

I agree. As this is not new code, the backport should be as clean as possible.

Best regards
Christoph

> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: Schmidt, Lutz <lutz.schmidt at sap.com>
> > Sent: Dienstag, 24. M?rz 2020 21:00
> > To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> > Subject: Re: RFR(XS): 8241464: [11u] Backport: make rehashing be
> > a needed guaranteed safepoint cleanup action
> >
> > Hi Martin,
> >
> > your change looks good to me.
> >
> > Maybe you want to add a small comment like "// Heal unbalanced hash
> > (done at safepoint)."
> >
> > Thanks,
> > Lutz
> >
> > ?On 23.03.20, 20:06, "hotspot-runtime-dev on behalf of Doerr, Martin"
> > <hotspot-runtime-dev-bounces at openjdk.java.net on behalf of
> > martin.doerr at sap.com> wrote:
> >
> >     Hi,
> >
> >     I'd like to backport a part of JDK-8221967. I'm using a new bug because it's
> > only a part of the original one.
> >     Original change has the summary "Move redundant table lookup and
> make
> > rehashing be a needed guaranteed safepoint cleanup action."
> >     The first part of it doesn't apply to 11u, because the SymbolTable and
> > StringTable parts are different in 11u and I don't see the need to change
> > them.
> >
> >     The second part of it does apply and makes perfect sense. Especially if
> > BiasedLocking is disabled (11u BiasedLocking implementation requests
> more
> > safepoints making this fix less important).
> >
> >     Original bug:
> >     https://bugs.openjdk.java.net/browse/JDK-8221967
> >
> >     Original issue:
> >     http://hg.openjdk.java.net/jdk/jdk/rev/2523496f5107
> >
> >     New webrev:
> >
> >
> http://cr.openjdk.java.net/~mdoerr/8221967_string_table_partial_backport
> > _11u/webrev.00/
> >
> >     Please review.
> >
> >     Best regards,
> >     Martin
> >
> >


From martin.doerr at sap.com  Tue Mar 24 22:14:32 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 24 Mar 2020 22:14:32 +0000
Subject: RFR(XS): 8241464: [11u] Backport: make rehashing be a needed
 guaranteed safepoint cleanup action
Message-ID: <AM0PR0202MB3297871D0B59C1974D9285DB9AF10@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Thanks for the review!

Best regards,
Martin


> -----Original Message-----
> From: Langer, Christoph <christoph.langer at sap.com>
> Sent: Dienstag, 24. M?rz 2020 21:11
> To: Doerr, Martin <martin.doerr at sap.com>; Schmidt, Lutz
> <lutz.schmidt at sap.com>; jdk-updates-dev at openjdk.java.net; hotspot-
> runtime-dev at openjdk.java.net
> Subject: RE: RFR(XS): 8241464: [11u] Backport: make rehashing be
> a needed guaranteed safepoint cleanup action
> 
> Hi Martin,
> 
> the backport looks good to me as well.
> 
> > > Maybe you want to add a small comment like "// Heal unbalanced hash
> > > (done at safepoint)."
> > Well, it is still a clean (partial) backport, not a new change, so I don't want to
> > introduce a diff to the jdk/jdk version.
> 
> I agree. As this is not new code, the backport should be as clean as possible.
> 
> Best regards
> Christoph
> 
> >
> > Best regards,
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: Schmidt, Lutz <lutz.schmidt at sap.com>
> > > Sent: Dienstag, 24. M?rz 2020 21:00
> > > To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-
> > > dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> > > Subject: Re: RFR(XS): 8241464: [11u] Backport: make rehashing be
> > > a needed guaranteed safepoint cleanup action
> > >
> > > Hi Martin,
> > >
> > > your change looks good to me.
> > >
> > > Maybe you want to add a small comment like "// Heal unbalanced hash
> > > (done at safepoint)."
> > >
> > > Thanks,
> > > Lutz
> > >
> > > ?On 23.03.20, 20:06, "hotspot-runtime-dev on behalf of Doerr, Martin"
> > > <hotspot-runtime-dev-bounces at openjdk.java.net on behalf of
> > > martin.doerr at sap.com> wrote:
> > >
> > >     Hi,
> > >
> > >     I'd like to backport a part of JDK-8221967. I'm using a new bug because
> it's
> > > only a part of the original one.
> > >     Original change has the summary "Move redundant table lookup and
> > make
> > > rehashing be a needed guaranteed safepoint cleanup action."
> > >     The first part of it doesn't apply to 11u, because the SymbolTable and
> > > StringTable parts are different in 11u and I don't see the need to change
> > > them.
> > >
> > >     The second part of it does apply and makes perfect sense. Especially if
> > > BiasedLocking is disabled (11u BiasedLocking implementation requests
> > more
> > > safepoints making this fix less important).
> > >
> > >     Original bug:
> > >     https://bugs.openjdk.java.net/browse/JDK-8221967
> > >
> > >     Original issue:
> > >     http://hg.openjdk.java.net/jdk/jdk/rev/2523496f5107
> > >
> > >     New webrev:
> > >
> > >
> >
> http://cr.openjdk.java.net/~mdoerr/8221967_string_table_partial_backport
> > > _11u/webrev.00/
> > >
> > >     Please review.
> > >
> > >     Best regards,
> > >     Martin
> > >
> > >


From denghui.ddh at alibaba-inc.com  Wed Mar 25 06:05:31 2020
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Wed, 25 Mar 2020 14:05:31 +0800
Subject: =?UTF-8?B?UmU6IFsxMXVdIFtKRlJdIFJGUihYWEwpIDgyMjY1MTE6IEltcGxlbWVudCBKRlIgRXZlbnQg?=
 =?UTF-8?B?U3RyZWFtaW5n?=
In-Reply-To: <CAJwKKmaoY-U8jEApyAGDDbYZ0cc8oH367qAoRJuASp3KZWt9bQ@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
 <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
 <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>,
 <CAJwKKmaoY-U8jEApyAGDDbYZ0cc8oH367qAoRJuASp3KZWt9bQ@mail.gmail.com>
Message-ID: <4af75b06-4dd2-45b4-a395-d1f2a989cdc2.denghui.ddh@alibaba-inc.com>

Hi,

I believe there will be some volunteers, at least we(Alibaba) are willing to do it. Of course,
the premise of all this is that the maintainers agree with the work.

As Erik said, JFR Streaming has changed the internal implementation of jfr, so I think we need
to create an incubator branch and a small discussion group to trace this work, and we need some experienced people to help us. ??

Besides, JFR has just entered 8u, so I agree with Mario that it isn't appropriate time to discuss 
backporting JFR Streaming to 8u.

Thanks,
Denghui

------------------------------------------------------------------
From:Mario Torre <neugens at redhat.com>
Send Time:2020?3?25?(???) 00:31
To:Martijn Verburg <martijnverburg at gmail.com>
Cc:jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
Subject:Re: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming

On Tue, Mar 24, 2020 at 5:19 PM Martijn Verburg
<martijnverburg at gmail.com> wrote:
>
> Hi all,
>
> Could we create a project/tree/branch for this work (jdk11u-jfr-test or some such) that a bunch of us could work on together to ensure the stability and quality of the patch before it goes into 11u?

For the JFR backport we created a small team, most of us were, if not
full time, at least "stable" on the project. While anyone could join
and share some knowledge, review a patch, or contribute some work, a
stable team means we can ensure questions and reviews are done
correctly and timely (after all, this is what happens in OpenJDK as
well).

So the question here would be if there is enough of manpower to
dedicate to this project from the interested parties.

Denghui has already done the backport but my experience with JFR tells
me that work will be needed on top of this anyway.

If we have consensus that this should go into the release (from the
maintainers) and the we have a critical mass of developers that are
willing to dedicate to it, then we can request an incubator repository
like we did with the JFR backport.

In other words, we need to have some volunteers that understand this
may be a time intensive work for the next weeks or months, and that
will need to be maintained after this when it's merged.

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From goetz.lindenmaier at sap.com  Wed Mar 25 08:42:32 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 25 Mar 2020 08:42:32 +0000
Subject: [11u notice]: jdk11u closed now 
Message-ID: <AM7PR02MB6049A5CE69FE25232819D7CFECCE0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

Tag jdk-11.0.7+9 was pushed. jdk11u is closed now.
Please don't push to jdk11u anymore. The closed security
changes for 11.0.7 will be prepared on top of this tag.

Best regards,
  Goetz.

See also project plan at https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

From doug.simon at oracle.com  Mon Mar 23 16:56:59 2020
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 23 Mar 2020 17:56:59 +0100
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
 <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>
 <e04004a1-47ae-b246-5e8d-757c01c8c6ed@redhat.com>
Message-ID: <78325291-5013-4B5A-B64D-393D2018C740@oracle.com>

Andrew,

That is a good summary. Indeed, libgraal is only a compilation time and resource optimization and thus not necessary for GraalVM.

Note that the JDK11 based Travis gates run on openjdk11 <https://github.com/oracle/graal/blob/master/.travis.yml#L17> so we should recognize any regression of the GraalVM compiler there (as we did recently <https://github.com/oracle/graal/pull/2278#issuecomment-602513391>). That said, also note that the Travis gate does not include any native image tests. That would require use of open-labsjdk-11 for access to the static libs.

It?s also worth pointing out that we?re also working with the HotSpot team at Oracle to ensure any JVMCI change we?re pushing into 11 also goes into JDK 15 where relevant.

-Doug

> On 23 Mar 2020, at 17:19, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi Doug,
> 
> Ok, so let me summarize and please correct me if I misrepresent the case:
> 
> 1) The first patch is critical to the ability to use jdk11u to build
> GraalVM and successfully use the resulting build products.
> 
> 2) The second patch is essentially an enhancement to performance of
> JVMCI-based compilation on OpenJDK jdk11u. Not having it will impinge on
> performance (but not change functionality) both for OpenJDK-internal use
> e.g. jaotc or Graal as C2 replacement and also when using OpenJDK jdk11u
> to build GraalVM.
> 
> 3) You plan to continue to backport upstream changes to the the labs
> jdk11u in order to be able to support ongoing development in GraalVM.
> 
> n.b. I classify the 2nd patch as only having performance implications
> because, as I understand it, the point of the libgraal update is simply
> to allow the GraalVM JIT to execute as precompiled native code with its
> own managed memory pool rather than having to be interpreted then JIT
> compile itself and employ the JVM heap for compiler data. i.e. this
> change has no effect on what functionality is supported.
> 
> If that is correct then:
> 
> 1) I think it would probably be wise to include the first patch into
> jdk11u, modulo suitable review.
> 
> 2) It doesn't sound to me like the second patch really needs to be
> backported into jdk11u. jdk13+ and the jdk dev tree head already support
> the the use of libgraal for those who need to use it.
> 
> 3) As regards any further changes that might be needed to retain the
> ability to buidl GraalVM, my view is that I don't think the jdk11u
> project can or ought to offer a blank check regarding further updates to
> JVMCI that imply hotspot changes (i.e. ones that will have to be met by
> backporting rather than by overlaying the GraalVM code).
> 
> Of course, any further changes the GraalVM project would like to be
> backported could and, I think, should still be considered on their
> merits. However, in my view the project's priority has to be continuity
> of operation, reliability and security. That said, it's certainly not
> for me to make any final decision here. I am sure the project lead and
> maintainers an, indeed, other updates project members will wish to
> follow up on this point.
> 
> 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
> 
> On 23/03/2020 15:03, Doug Simon wrote:
>> 
>> 
>>> On 23 Mar 2020, at 15:29, Andrew Dinn <adinn at redhat.com> wrote:
>>> 
>>> Hi Doug,
>>> 
>>> On 23/03/2020 13:36, Doug Simon wrote:
>>>> Sorry, this thread is long and has mentioned a number of patches.
>>>> Which ones are you referring to here?
>>> 
>>> The specific changes in question were derived from the discussion in
>>> github/graal issue #2196. The patches are detailed in the 2 webrevs
>>> Christoph posted:
>>> 
>>> http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
>>> 
>>> and
>>> 
>>> http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
>>> 
>>> The first webrev is the fix for JDK-8208686. The second one is
>>> essentially the bundled update that Tom pushed to the labs version of
>>> jkd11u after Christoph tweaked ti to make it apply and build correctly.
>>> 
>>>> I?m having trouble parsing that question. Are you asking ?is there
>>>> anything in GitHub Graal that depends on the JVMCI changes in
>>>> labs-openjdk-11??
>>> 
>>> I am asking two things:
>>> 
>>> 1) Is there anything in the current GitHub Graal repo that critically
>>> depends on the above changes getting into jdk11u?
>> 
>> JDK-8208686 fixes a JCK failure so is critical if you want to pass the JCK, especially with jaotc.
>> 
>> However, the general answer depends on the goal. If you want to be able to build and use libgraal with GitHub Graal + jdk11u, then the bundled update is necessary.
>> 
>>> 
>>> 2) Is there anything planned for addition to the GitHub Graal repo that
>>> critically depends on the above changes getting into jdk11u?
>> 
>> Once again, it depends on what the goal is. Since GraalVM is built on labs-openjdk-11, the extent to which jdk11u matches open-labsjdk-11 determines the extent to which the same GraalVM can be built in jdk11u.
>> 
>>> In other words why do this backport instead of just use the current jdk11u?
>> 
>> Because jdk11u misses all the JVMCI implementation changes needed for libgraal.
>> 
>>> 
>>>> I believe Tom has previously provided a breakdown of the patches in
>>>> labs-openjdk-11. Everything in labs-openjdk-11 is essential for
>>>> supporting complete GraalVM functionality as far as I understand
>>>> otherwise it would not be there.
>>> 
>>> First, I think all the patches mentioned in that list that involve
>>> hotspot changes have been backported except for the ones listed above --
>>> which is why we are currently able to build GraalVM using the latest
>>> OpenJDK jdkd11u.
>> 
>> Yes but it?s a GraalVM missing libgraal.
>> 
>>> Now, I'm not suggesting that there is any /redundancy/ as regards these
>>> remaining patches. However, what we would like to know is why we need to
>>> backport them i.e. what problem do they resolve and what would be the
>>> upshot if we stop further backports where we are now.
>>> 
>>> The existing jdk11u code appears to work to build Graal VM. It also
>>> works perfectly well to build and run the in-tree Graal code. So, by
>>> 'upshot' above I mean what would it imply for the ability to continue
>>> using jdk11u to build Graal if we don't backport the above changes? This
>>> is one side of a benefits equation we need to assess.
>> 
>> Again, libgraal is the main difference.
>> 
>>>> I think the high order point is that porting the changes in
>>>> labs-openjdk-11 to jdk11u is going to be complex due the way we
>>>> back-ported changes from JDK 13. With more time, we would have tried
>>>> to be more principled about it but on the other hand we were keen to
>>>> release GraalVM on JDK 11 given how much demand there was for it.
>>> 
>>> Yes, I had noticed that ;-). Also, I fully understand why a mega-patch
>>> was chosen at the time (especially since Red Hat were responsible for a
>>> lot of the demand you mention). I'm really trying to assess the degree
>>> to which we can justify bringing jdk11u up to date with the jdk13u base
>>> level.
>>> 
>>>> It might help to have a Zoom call to discuss this further. I want Tom
>>>> to be on the call so some time between 18:00 - 21:00 CET would
>>>> probably work. I can do any day except Tuesday.
>>> 
>>> Well, we normally try very hard to keep discussions like this in public
>>> so that they are visible to all who might have an interest and also on
>>> record. It's not really good open source practice to do otherwise.
>>> However, I'd be happy to try to use the tech to help expedite resolution
>>> of this issue -- so long as we report back ideas, suggestions and
>>> conclusions here to all interested parties. That's also assuming that
>>> others are happy to join in. Perhaps anyone interested in taking up your
>>> offer could respond and then we can take arrangement of a Zoom call offline.
>> 
>> FWIW, I?d be happy to record and publish a Zoom call. My only motivation for that option is that we can probably get to a resolution a lot faster. But for now, we can keep discussing on this thread.
>> 
>> -Doug
>> 
>>> 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 doug.simon at oracle.com  Mon Mar 23 15:03:37 2020
From: doug.simon at oracle.com (Doug Simon)
Date: Mon, 23 Mar 2020 16:03:37 +0100
Subject: [11u] RFC: Update Graal in OpenJDK 11 Updates?
In-Reply-To: <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
References: <AM0PR02MB5714BB9930669BA5346B070E8AFD0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <f57776b6-1dee-8ecc-e85f-7872da7ecef3@redhat.com>
 <AM0PR02MB571403F85B00AD0599ECB1948AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <6337FD52-63B8-48A6-B704-5F029B772224@azul.com>
 <AM0PR02MB57142044725CE8696F4E43B18AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <B6FC2A83-DC40-45DE-A264-FEA1A86756C7@azul.com>
 <240FCA50-E59D-4BF4-97CA-AB3ACB007FBE@oracle.com>
 <93cf039e-60cb-78d1-9d72-5efb6d5383dd@redhat.com>
 <2A982762-1B47-4940-A354-078EADA073D5@oracle.com>
 <4d7b18fa-a3a6-314f-be32-b5bb619521fb@redhat.com>
Message-ID: <FB5E97DB-C5F0-482C-8AE7-D3618D6F8071@oracle.com>



> On 23 Mar 2020, at 15:29, Andrew Dinn <adinn at redhat.com> wrote:
> 
> Hi Doug,
> 
> On 23/03/2020 13:36, Doug Simon wrote:
>> Sorry, this thread is long and has mentioned a number of patches.
>> Which ones are you referring to here?
> 
> The specific changes in question were derived from the discussion in
> github/graal issue #2196. The patches are detailed in the 2 webrevs
> Christoph posted:
> 
>  http://cr.openjdk.java.net/~clanger/webrevs/8208686.11u/
> 
> and
> 
>  http://cr.openjdk.java.net/~clanger/webrevs/graal13.11u/
> 
> The first webrev is the fix for JDK-8208686. The second one is
> essentially the bundled update that Tom pushed to the labs version of
> jkd11u after Christoph tweaked ti to make it apply and build correctly.
> 
>> I?m having trouble parsing that question. Are you asking ?is there
>> anything in GitHub Graal that depends on the JVMCI changes in
>> labs-openjdk-11??
> 
> I am asking two things:
> 
> 1) Is there anything in the current GitHub Graal repo that critically
> depends on the above changes getting into jdk11u?

JDK-8208686 fixes a JCK failure so is critical if you want to pass the JCK, especially with jaotc.

However, the general answer depends on the goal. If you want to be able to build and use libgraal with GitHub Graal + jdk11u, then the bundled update is necessary.

> 
> 2) Is there anything planned for addition to the GitHub Graal repo that
> critically depends on the above changes getting into jdk11u?

Once again, it depends on what the goal is. Since GraalVM is built on labs-openjdk-11, the extent to which jdk11u matches open-labsjdk-11 determines the extent to which the same GraalVM can be built in jdk11u.

> In other words why do this backport instead of just use the current jdk11u?

Because jdk11u misses all the JVMCI implementation changes needed for libgraal.

> 
>> I believe Tom has previously provided a breakdown of the patches in
>> labs-openjdk-11. Everything in labs-openjdk-11 is essential for
>> supporting complete GraalVM functionality as far as I understand
>> otherwise it would not be there.
> 
> First, I think all the patches mentioned in that list that involve
> hotspot changes have been backported except for the ones listed above --
> which is why we are currently able to build GraalVM using the latest
> OpenJDK jdkd11u.

Yes but it?s a GraalVM missing libgraal.

> Now, I'm not suggesting that there is any /redundancy/ as regards these
> remaining patches. However, what we would like to know is why we need to
> backport them i.e. what problem do they resolve and what would be the
> upshot if we stop further backports where we are now.
> 
> The existing jdk11u code appears to work to build Graal VM. It also
> works perfectly well to build and run the in-tree Graal code. So, by
> 'upshot' above I mean what would it imply for the ability to continue
> using jdk11u to build Graal if we don't backport the above changes? This
> is one side of a benefits equation we need to assess.

Again, libgraal is the main difference.

>> I think the high order point is that porting the changes in
>> labs-openjdk-11 to jdk11u is going to be complex due the way we
>> back-ported changes from JDK 13. With more time, we would have tried
>> to be more principled about it but on the other hand we were keen to
>> release GraalVM on JDK 11 given how much demand there was for it.
> 
> Yes, I had noticed that ;-). Also, I fully understand why a mega-patch
> was chosen at the time (especially since Red Hat were responsible for a
> lot of the demand you mention). I'm really trying to assess the degree
> to which we can justify bringing jdk11u up to date with the jdk13u base
> level.
> 
>> It might help to have a Zoom call to discuss this further. I want Tom
>> to be on the call so some time between 18:00 - 21:00 CET would
>> probably work. I can do any day except Tuesday.
> 
> Well, we normally try very hard to keep discussions like this in public
> so that they are visible to all who might have an interest and also on
> record. It's not really good open source practice to do otherwise.
> However, I'd be happy to try to use the tech to help expedite resolution
> of this issue -- so long as we report back ideas, suggestions and
> conclusions here to all interested parties. That's also assuming that
> others are happy to join in. Perhaps anyone interested in taking up your
> offer could respond and then we can take arrangement of a Zoom call offline.

FWIW, I?d be happy to record and publish a Zoom call. My only motivation for that option is that we can probably get to a resolution a lot faster. But for now, we can keep discussing on this thread.

-Doug

> 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 lutz.schmidt at sap.com  Tue Mar 24 20:00:16 2020
From: lutz.schmidt at sap.com (Schmidt, Lutz)
Date: Tue, 24 Mar 2020 20:00:16 +0000
Subject: [CAUTION] RFR(XS): 8241464: [11u] Backport: make rehashing be a
 needed guaranteed safepoint cleanup action
Message-ID: <6401890E-B4B8-406B-A33D-6FBE6216228C@sap.com>

Hi Martin,

your change looks good to me. 

Maybe you want to add a small comment like "// Heal unbalanced hash (done at safepoint)."

Thanks,
Lutz

?On 23.03.20, 20:06, "hotspot-runtime-dev on behalf of Doerr, Martin" <hotspot-runtime-dev-bounces at openjdk.java.net on behalf of martin.doerr at sap.com> wrote:

    Hi,
    
    I'd like to backport a part of JDK-8221967. I'm using a new bug because it's only a part of the original one.
    Original change has the summary "Move redundant table lookup and make rehashing be a needed guaranteed safepoint cleanup action."
    The first part of it doesn't apply to 11u, because the SymbolTable and StringTable parts are different in 11u and I don't see the need to change them.
    
    The second part of it does apply and makes perfect sense. Especially if BiasedLocking is disabled (11u BiasedLocking implementation requests more safepoints making this fix less important).
    
    Original bug:
    https://bugs.openjdk.java.net/browse/JDK-8221967
    
    Original issue:
    http://hg.openjdk.java.net/jdk/jdk/rev/2523496f5107
    
    New webrev:
    http://cr.openjdk.java.net/~mdoerr/8221967_string_table_partial_backport_11u/webrev.00/
    
    Please review.
    
    Best regards,
    Martin
    
    


From dalibor.topic at oracle.com  Wed Mar 25 21:41:24 2020
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Wed, 25 Mar 2020 22:41:24 +0100
Subject: [11u] RFR 8235183: Remove the "HACK CODE" in comment
In-Reply-To: <7c355d05-2fce-9b2b-f996-cb88ca696941@redhat.com>
References: <AM0PR0202MB33319F6A30476435E60060489BFD0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <6de39d56-fbf5-648b-31f8-c3c5386878b6@redhat.com>
 <AM0PR02MB57149BFA9744F858486EF1A48AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <14e1958b-cf46-cc3a-3941-ab5eeadb8870@redhat.com>
 <AM0PR02MB5714C0D205C52E43213C461A8AFA0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <ec5817ce-4939-f7f1-98c1-e382b76ccc3b@redhat.com>
 <7c355d05-2fce-9b2b-f996-cb88ca696941@redhat.com>
Message-ID: <839429b8-cd07-190e-3d25-2cd6ea38f4b1@oracle.com>



On 16.03.2020 21:24, Andrew Hughes wrote:
> Much as some at Oracle may believe it to be the other way around,
> OpenJDK is the reference implementation and Oracle's tree is a fork of
> this.

Oracle's binaries of OpenJDK 11 are the reference implementation for 
Java SE 11, and can be found at https://jdk.java.net/java-se-ri/11 .

Enjoy,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>, Video: dalibor.topic at oracle.com
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From shade at redhat.com  Thu Mar 26 06:23:10 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 26 Mar 2020 07:23:10 +0100
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>

On 3/19/20 4:39 PM, Lindenmaier, Goetz wrote:
> Hi Andrew,
> 
> There are a row of changes fixing copyrights downported by Oracle to 11.0.8,
> similar to this one:
> https://bugs.openjdk.java.net/browse/JDK-8220414
> 
> See also 
> https://bugs.openjdk.java.net/issues/?filter=38639
> 
> I'd consider them pretty pointless given the rules you set.
> So should we skip them?
> If so, I would mark them all as openjdk-na. 
> (In my opinion we should downport them, but I'll follow 
> your advice.)

Not Andrew, but I believe copyright headers are important enough to consider for backports. If the
reverse was true, we would not care about rejected hunks in copyright lines during the normal backports.

-- 
Thanks,
-Aleksey


From gil at azul.com  Thu Mar 26 07:07:49 2020
From: gil at azul.com (Gil Tene)
Date: Thu, 26 Mar 2020 07:07:49 +0000
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>,
 <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
Message-ID: <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>



Sent from my iPad

On Mar 25, 2020, at 11:26 PM, Aleksey Shipilev <shade at redhat.com> wrote:

?On 3/19/20 4:39 PM, Lindenmaier, Goetz wrote:
Hi Andrew,

There are a row of changes fixing copyrights downported by Oracle to 11.0.8,
similar to this one:
https://bugs.openjdk.java.net/browse/JDK-8220414

See also
https://bugs.openjdk.java.net/issues/?filter=38639

I'd consider them pretty pointless given the rules you set.
So should we skip them?
If so, I would mark them all as openjdk-na.
(In my opinion we should downport them, but I'll follow
your advice.)

Not Andrew, but I believe copyright headers are important enough to consider for backports. If the
reverse was true, we would not care about rejected hunks in copyright lines during the normal backports.

Umm...

It literally says ?DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.?

So unless we are copying the entire file from upstream
intact (replacing the entirety of the old copyrighted file
in 11u with a new copyrighted file copied from upstream),
I don?t think anyone other than Oracle should be messing
with the existing Oracle copyright notice text in 11u code.

And if we do replace the file in its entirety (and e.g. the only
difference between the two is the copyright text) we?d likely
want the change records to indicate a removal of the old file
and an addition of a new replacement file, and not just a
change of the one or two lines of copyright text that differed
between the two.

If you can get Oracle to do the backport of the copyright
changes to 11u, that?s fine. But otherwise, I?d leave them
as they are.

I know this may seem pedantic, but copyrights and notices
matter, and they carry a lot of implications. We all depend
on the code in the updates projects not messing with them.


--
Thanks,
-Aleksey

From philip.m.jones at siemens.com  Thu Mar 26 07:29:29 2020
From: philip.m.jones at siemens.com (Jones, Philip)
Date: Thu, 26 Mar 2020 07:29:29 +0000
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>,
 <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
 <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
Message-ID: <3C3FEEEFE127B940BB0F5FADB28060418C5653A6@DEKOMMBX001.net.plm.eds.com>

As a user of OpenJDK, copyright headers are very important.

We need to go through a clearance process that scans all files for licenses etc. If a copyright header is missing or incorrect it can mean that effectively the  code becomes unusable by many.

A concrete example:

https://hg.openjdk.java.net/jdk-updates/jdk11u/file/00f8f9fcdc3a/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11.h

This file was added via https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8080462

JDK-8080462 : Update SunPKCS11 provider with PKCS11 v2.40 support

And has added files that have an unclear copyright (the copyright is a link to an unversioned online file that may change and that is still somewhat unclear)

Philip

-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of Gil Tene
Sent: 26 March 2020 07:08
To: Aleksey Shipilev <shade at redhat.com>
Cc: jdk-updates-dev at openjdk.java.net
Subject: Re: Fixes of copyright headers: Should we downport them?



Sent from my iPad

On Mar 25, 2020, at 11:26 PM, Aleksey Shipilev <shade at redhat.com> wrote:

?On 3/19/20 4:39 PM, Lindenmaier, Goetz wrote:
Hi Andrew,

There are a row of changes fixing copyrights downported by Oracle to 11.0.8, similar to this one:
https://bugs.openjdk.java.net/browse/JDK-8220414

See also
https://bugs.openjdk.java.net/issues/?filter=38639

I'd consider them pretty pointless given the rules you set.
So should we skip them?
If so, I would mark them all as openjdk-na.
(In my opinion we should downport them, but I'll follow your advice.)

Not Andrew, but I believe copyright headers are important enough to consider for backports. If the reverse was true, we would not care about rejected hunks in copyright lines during the normal backports.

Umm...

It literally says ?DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.?

So unless we are copying the entire file from upstream intact (replacing the entirety of the old copyrighted file in 11u with a new copyrighted file copied from upstream), I don?t think anyone other than Oracle should be messing with the existing Oracle copyright notice text in 11u code.

And if we do replace the file in its entirety (and e.g. the only difference between the two is the copyright text) we?d likely want the change records to indicate a removal of the old file and an addition of a new replacement file, and not just a change of the one or two lines of copyright text that differed between the two.

If you can get Oracle to do the backport of the copyright changes to 11u, that?s fine. But otherwise, I?d leave them as they are.

I know this may seem pedantic, but copyrights and notices matter, and they carry a lot of implications. We all depend on the code in the updates projects not messing with them.


--
Thanks,
-Aleksey
-----------------
Siemens Industry Software Limited is a limited company registered in England and Wales.
Registered number: 3476850.
Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD.

From rwestrel at redhat.com  Thu Mar 26 10:53:07 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 26 Mar 2020 11:53:07 +0100
Subject: [11u] RFR 8235762: JVM crash in SWPointer during C2 compilation
Message-ID: <877dz7fkvg.fsf@redhat.com>


Original bug:
https://bugs.openjdk.java.net/browse/JDK-8235762
https://hg.openjdk.java.net/jdk/jdk/rev/5aa85653a589

Original patch does not apply cleanly to 11u in
SuperWord::find_adjacent_refs(). The original change in jdk 14 partially
reverts a previous change in SuperWord::find_adjacent_refs() that's not
in jdk 11. With the patch I propose, SuperWord::find_adjacent_refs() is
mostly identical to today's code in jdk 15.

11u webrev:
  http://cr.openjdk.java.net/~roland/8235762.11u/webrev.00/

Testing: x86_64/aarch4 build, verified new test fails without the patch
and runs fine with it on aarch64, tier1 + tier2

Roland.


From rwestrel at redhat.com  Thu Mar 26 11:03:22 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 26 Mar 2020 12:03:22 +0100
Subject: 8217230: assert(t == t_no_spec) failure in
 NodeHash::check_no_speculative_types()
Message-ID: <874kubfked.fsf@redhat.com>


This is required to backport 8237086 (assert(is_MachReturn()) running
CTW with fix for JDK-8231291).

Original bug:
  https://bugs.openjdk.java.net/browse/JDK-8217230
  http://hg.openjdk.java.net/jdk/jdk12/rev/1b292ae4eb50

Original patch does not apply cleanly to 11u because context changed in
compile.hpp. Patch is otherwise identical.

11u webrev:
  http://cr.openjdk.java.net/~roland/8217230.11u/webrev.00/

Testing: x86_64 build, tier1 + tier2

Roland.


From aph at redhat.com  Thu Mar 26 11:27:46 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 26 Mar 2020 11:27:46 +0000
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <f13b6e29-753a-37cc-c47d-3c1591e55285@redhat.com>

On 3/19/20 3:39 PM, Lindenmaier, Goetz wrote:
> 
> There are a row of changes fixing copyrights downported by Oracle to 11.0.8,
> similar to this one:
> https://bugs.openjdk.java.net/browse/JDK-8220414
> 
> See also 
> https://bugs.openjdk.java.net/issues/?filter=38639
> 
> I'd consider them pretty pointless given the rules you set.
> So should we skip them?

Yes. If Oracle want us to update their copyright notices in 11u, they
can ask us nicely or they can do it themselves.

> If so, I would mark them all as openjdk-na. 
> (In my opinion we should downport them, but I'll follow 
> your advice.)

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From christoph.langer at sap.com  Thu Mar 26 14:22:37 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 26 Mar 2020 14:22:37 +0000
Subject: [11u] RFR (S): 8234146:
 compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
Message-ID: <AM0PR02MB57148EA6BEDA00998A72AE648ACF0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

please review the 11u backport of a test change for a test that can timeout under heavy system load.

Bug: https://bugs.openjdk.java.net/browse/JDK-8234146
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ecc59c31cb10
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/

The patch did not apply to 11u, but adapting was trivial. The change to the exclusion list was skipped because the test wasn't excluded in 11u. For the test itself, I had to trivially resolve the run directives because the timeout option didn't exist upstream.

Thanks
Christoph


From volker.simonis at gmail.com  Thu Mar 26 15:53:25 2020
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 26 Mar 2020 16:53:25 +0100
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
 <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
Message-ID: <CA+3eh12CPWOLf53Vp7U0uiBJKAUq3=Fz+BD-+h2_xP37DMnPRw@mail.gmail.com>

Gil Tene <gil at azul.com> schrieb am Do., 26. M?rz 2020, 08:08:

>
>
> Sent from my iPad
>
> On Mar 25, 2020, at 11:26 PM, Aleksey Shipilev <shade at redhat.com> wrote:
>
> ?On 3/19/20 4:39 PM, Lindenmaier, Goetz wrote:
> Hi Andrew,
>
> There are a row of changes fixing copyrights downported by Oracle to
> 11.0.8,
> similar to this one:
> https://bugs.openjdk.java.net/browse/JDK-8220414
>
> See also
> https://bugs.openjdk.java.net/issues/?filter=38639
>
> I'd consider them pretty pointless given the rules you set.
> So should we skip them?
> If so, I would mark them all as openjdk-na.
> (In my opinion we should downport them, but I'll follow
> your advice.)
>
> Not Andrew, but I believe copyright headers are important enough to
> consider for backports. If the
> reverse was true, we would not care about rejected hunks in copyright
> lines during the normal backports.
>
> Umm...
>
> It literally says ?DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE
> HEADER.?
>
> So unless we are copying the entire file from upstream
> intact (replacing the entirety of the old copyrighted file
> in 11u with a new copyrighted file copied from upstream),
> I don?t think anyone other than Oracle should be messing
> with the existing Oracle copyright notice text in 11u code.
>
> And if we do replace the file in its entirety (and e.g. the only
> difference between the two is the copyright text) we?d likely
> want the change records to indicate a removal of the old file
> and an addition of a new replacement file, and not just a
> change of the one or two lines of copyright text that differed
> between the two.
>
> If you can get Oracle to do the backport of the copyright
> changes to 11u, that?s fine. But otherwise, I?d leave them
> as they are.
>
> I know this may seem pedantic, but copyrights and notices
> matter, and they carry a lot of implications. We all depend
> on the code in the updates projects not messing with them.
>

Yes, I think you're opinion is overly pedantic :)

But maybe you're right. In that case however, the established rule that
every developer has to update the copyright year in every file touched by
his change has to be revised as well.

And, as already mentioned by Aleksey, it is not clear to me how to handle
arbitrary downports which among other things also change the copyright year
if you are right that only Oracle is allowed to do that.

From aph at redhat.com  Thu Mar 26 16:30:28 2020
From: aph at redhat.com (Andrew Haley)
Date: Thu, 26 Mar 2020 16:30:28 +0000
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <CA+3eh12CPWOLf53Vp7U0uiBJKAUq3=Fz+BD-+h2_xP37DMnPRw@mail.gmail.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
 <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
 <CA+3eh12CPWOLf53Vp7U0uiBJKAUq3=Fz+BD-+h2_xP37DMnPRw@mail.gmail.com>
Message-ID: <e8c1338e-8eda-6862-0c6b-3032bd7ab7bb@redhat.com>

On 3/26/20 3:53 PM, Volker Simonis wrote:
> Yes, I think you're opinion is overly pedantic :)
>
> But maybe you're right. In that case however, the established rule that
> every developer has to update the copyright year in every file touched by
> his change has to be revised as well.
>
> And, as already mentioned by Aleksey, it is not clear to me how to handle
> arbitrary downports which among other things also change the copyright year
> if you are right that only Oracle is allowed to do that.

Please let's not go down this rabbit hole. When we change stuff, we
have to update the copyright date. This is especially true when we
back-port patches from a file (c) Oracle dated, say, 2020 to one dated
2016. We must never take code which is copyright 2020, paste it into a
file dated 2016, and not update the copyright in the destination
file. It's easiest just to update the copyright on the file we're
patching to the current date.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From richard.reingruber at sap.com  Thu Mar 26 21:16:31 2020
From: richard.reingruber at sap.com (Reingruber, Richard)
Date: Thu, 26 Mar 2020 21:16:31 +0000
Subject: [11u] RFR (S): 8234146:
 compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
In-Reply-To: <AM0PR02MB57148EA6BEDA00998A72AE648ACF0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM0PR02MB57148EA6BEDA00998A72AE648ACF0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB333181E7100350262FC5B72F9BCF0@AM0PR0202MB3331.eurprd02.prod.outlook.com>

Hi Christoph,

thanks for taking care of this. The fix will help prevent timeouts in the named test. Note that this isn't a SPARC only issue. The test can misbehave on all platforms. At SAP we had timeouts on ppc, arm and x86_64 too.

  > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/

Looks good.

Thanks,
Richard. // not a Reviewer and somewhat biased as the author of the original fix ;)

-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On Behalf Of Langer, Christoph
Sent: Donnerstag, 26. M?rz 2020 15:23
To: jdk-updates-dev at openjdk.java.net
Subject: [CAUTION] [11u] RFR (S): 8234146: compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC

Hi,

please review the 11u backport of a test change for a test that can timeout under heavy system load.

Bug: https://bugs.openjdk.java.net/browse/JDK-8234146
Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ecc59c31cb10
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/

The patch did not apply to 11u, but adapting was trivial. The change to the exclusion list was skipped because the test wasn't excluded in 11u. For the test itself, I had to trivially resolve the run directives because the timeout option didn't exist upstream.

Thanks
Christoph


From martin.doerr at sap.com  Thu Mar 26 21:56:40 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 26 Mar 2020 21:56:40 +0000
Subject: [11u] RFR (S): 8234146:
 compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
In-Reply-To: <AM0PR0202MB333181E7100350262FC5B72F9BCF0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
References: <AM0PR02MB57148EA6BEDA00998A72AE648ACF0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR0202MB333181E7100350262FC5B72F9BCF0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3297545753396BCABE1752AD9ACF0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi Christoph,

looks good to me, too.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Reingruber, Richard
> Sent: Donnerstag, 26. M?rz 2020 22:17
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR (S): 8234146:
> compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
> 
> Hi Christoph,
> 
> thanks for taking care of this. The fix will help prevent timeouts in the named
> test. Note that this isn't a SPARC only issue. The test can misbehave on all
> platforms. At SAP we had timeouts on ppc, arm and x86_64 too.
> 
>   > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/
> 
> Looks good.
> 
> Thanks,
> Richard. // not a Reviewer and somewhat biased as the author of the original
> fix ;)
> 
> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Donnerstag, 26. M?rz 2020 15:23
> To: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] [11u] RFR (S): 8234146:
> compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
> 
> Hi,
> 
> please review the 11u backport of a test change for a test that can timeout
> under heavy system load.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8234146
> Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ecc59c31cb10
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/
> 
> The patch did not apply to 11u, but adapting was trivial. The change to the
> exclusion list was skipped because the test wasn't excluded in 11u. For the
> test itself, I had to trivially resolve the run directives because the timeout
> option didn't exist upstream.
> 
> Thanks
> Christoph


From goetz.lindenmaier at sap.com  Fri Mar 27 06:46:46 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 27 Mar 2020 06:46:46 +0000
Subject: [11u] RFR(S): 8236700: Upgrading JSZip from v3.1.5 to v3.2.2
Message-ID: <AM7PR02MB604992F4379ACD29940DBF0BECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi

I would like to downport this change for parity with 11.0.8-oracle.
The patch does not apply clean.

http://cr.openjdk.java.net/~goetz/wr20/8236700-upgrade_jszip-jdk11/01/

The .js files have been moved to another location in 14:
https://bugs.openjdk.java.net/browse/JDK-8221644  jquery directory should be renamed
(Later, they have been removed altogether
https://bugs.openjdk.java.net/browse/JDK-8237909  Remove zipped index files feature)

The move could be undone by simply editing the paths in the patch.
The patch then applies clean to the .js files.

A part of the license change did not apply.
The corresponding text is not in 11. It was introduced
when moving the pako license into the jszip license.
The bugs that document this are closed, but here the link 
to the changes:
  8219803: Nodeca Pako license text needs to be inserted in JSZip license text
  http://hg.openjdk.java.net/jdk/jdk/rev/5d97784f08bf
  8228492: Remove pako.md
  http://hg.openjdk.java.net/jdk/jdk/rev/5b5747ed8f34

I just dropped the sentence.

Please review.

Thanks, Goetz.

From christoph.langer at sap.com  Fri Mar 27 06:50:51 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 27 Mar 2020 06:50:51 +0000
Subject: [11u] RFR (S): 8234146:
 compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
In-Reply-To: <AM0PR0202MB3297545753396BCABE1752AD9ACF0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM0PR02MB57148EA6BEDA00998A72AE648ACF0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR0202MB333181E7100350262FC5B72F9BCF0@AM0PR0202MB3331.eurprd02.prod.outlook.com>
 <AM0PR0202MB3297545753396BCABE1752AD9ACF0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB571493FE4C0FC2BC055843E08ACC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Thanks, Richard and Martin, for the reviews.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Donnerstag, 26. M?rz 2020 22:57
> To: Reingruber, Richard <richard.reingruber at sap.com>; Langer, Christoph
> <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR (S): 8234146:
> compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
> 
> Hi Christoph,
> 
> looks good to me, too.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Reingruber, Richard
> > Sent: Donnerstag, 26. M?rz 2020 22:17
> > To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Subject: RE: [11u] RFR (S): 8234146:
> > compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
> >
> > Hi Christoph,
> >
> > thanks for taking care of this. The fix will help prevent timeouts in the
> named
> > test. Note that this isn't a SPARC only issue. The test can misbehave on all
> > platforms. At SAP we had timeouts on ppc, arm and x86_64 too.
> >
> >   > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/
> >
> > Looks good.
> >
> > Thanks,
> > Richard. // not a Reviewer and somewhat biased as the author of the
> original
> > fix ;)
> >
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Langer, Christoph
> > Sent: Donnerstag, 26. M?rz 2020 15:23
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [CAUTION] [11u] RFR (S): 8234146:
> > compiler/jsr292/ContinuousCallSiteTargetChange.java times out on SPARC
> >
> > Hi,
> >
> > please review the 11u backport of a test change for a test that can timeout
> > under heavy system load.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8234146
> > Original Change: https://hg.openjdk.java.net/jdk/jdk/rev/ecc59c31cb10
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8234146.11u/
> >
> > The patch did not apply to 11u, but adapting was trivial. The change to the
> > exclusion list was skipped because the test wasn't excluded in 11u. For the
> > test itself, I had to trivially resolve the run directives because the timeout
> > option didn't exist upstream.
> >
> > Thanks
> > Christoph


From christoph.langer at sap.com  Fri Mar 27 07:32:04 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 27 Mar 2020 07:32:04 +0000
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <e8c1338e-8eda-6862-0c6b-3032bd7ab7bb@redhat.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
 <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
 <CA+3eh12CPWOLf53Vp7U0uiBJKAUq3=Fz+BD-+h2_xP37DMnPRw@mail.gmail.com>
 <e8c1338e-8eda-6862-0c6b-3032bd7ab7bb@redhat.com>
Message-ID: <AM0PR02MB5714DF37F8D619A7B648FE768ACC0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi,

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Donnerstag, 26. M?rz 2020 17:30
> 
> On 3/26/20 3:53 PM, Volker Simonis wrote:
> > Yes, I think you're opinion is overly pedantic :)
> >
> > But maybe you're right. In that case however, the established rule that
> > every developer has to update the copyright year in every file touched by
> > his change has to be revised as well.
> >
> > And, as already mentioned by Aleksey, it is not clear to me how to handle
> > arbitrary downports which among other things also change the copyright
> year
> > if you are right that only Oracle is allowed to do that.
> 
> Please let's not go down this rabbit hole. When we change stuff, we
> have to update the copyright date. This is especially true when we
> back-port patches from a file (c) Oracle dated, say, 2020 to one dated
> 2016. We must never take code which is copyright 2020, paste it into a
> file dated 2016, and not update the copyright in the destination
> file. It's easiest just to update the copyright on the file we're
> patching to the current date.

Hm, probably you're right with that. However, actually, for process simplicity's sake, I think we're doing quite some mistakes in that sense though.

Because currently, if a backport change happens to be the one that updated a copyright year, we'll do it correctly and also increment the copyright year in the backported file. But if we're bringing down a change that has happened over the year, that is, after some other change previously had to update the copyright year, we'll miss that and have newer code than the copyright year indicates in certain files.

I guess this process is that what Oracle does and what they laid out when owning the updates project. But do we need to adjust this?



Other than that, I see no point in rejecting backports of changes like https://bugs.openjdk.java.net/browse/JDK-8220414. All the change does is correct the formatting of the license header to Oracle's standards (the comma after the second year). I don't know whether this comma is legally important or just a formatting thing but in any case, I think it corrects something which was wrong before. So we could admit it. But, of course, such backports should rather be in Oracle's interest and they only affect legal compliance and don't touch functionality at all, so if nobody in the community does backport it, it shouldn't matter either.



After all, it all comes down to a legal discussion - and so, since I'm not a lawyer and not deeply into licensing laws, everything I say in this mail is likely to be wrong ... ??


Best regards
Christoph


From goetz.lindenmaier at sap.com  Fri Mar 27 11:58:20 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 27 Mar 2020 11:58:20 +0000
Subject: [11] RFR(XS): 8231779: crash
 HeapWord*ParallelScavengeHeap::failed_mem_allocate
Message-ID: <AM7PR02MB60498654C597F3F396B1BA34ECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi,

I want to downport this for parity with 11.0.8-oracle. 

I had to do some trivial resolves due to context and Copyright:
http://cr.openjdk.java.net/~goetz/wr20/8231779-Crash_ParallelScavenge-jdk11/01/

original: 
https://bugs.openjdk.java.net/browse/JDK-8231779
https://hg.openjdk.java.net/jdk/jdk/rev/fcbd54a2c2d9

Best regards,
  Goetz.

From aph at redhat.com  Fri Mar 27 12:22:01 2020
From: aph at redhat.com (Andrew Haley)
Date: Fri, 27 Mar 2020 12:22:01 +0000
Subject: Fixes of copyright headers: Should we downport them?
In-Reply-To: <AM0PR02MB5714DF37F8D619A7B648FE768ACC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <AM7PR02MB60499E36E5A75541BE7BFBF5ECF40@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <cbaace60-91a2-bfa8-be75-cced7ea4a420@redhat.com>
 <6BD58394-B1D4-478A-AC55-608C519197AE@azul.com>
 <CA+3eh12CPWOLf53Vp7U0uiBJKAUq3=Fz+BD-+h2_xP37DMnPRw@mail.gmail.com>
 <e8c1338e-8eda-6862-0c6b-3032bd7ab7bb@redhat.com>
 <AM0PR02MB5714DF37F8D619A7B648FE768ACC0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <01d1dc3c-c642-ab4c-d21d-d32710b8ee0b@redhat.com>

Hi,

On 3/27/20 7:32 AM, Langer, Christoph wrote:
>>
>> Please let's not go down this rabbit hole. When we change stuff, we
>> have to update the copyright date. This is especially true when we
>> back-port patches from a file (c) Oracle dated, say, 2020 to one dated
>> 2016. We must never take code which is copyright 2020, paste it into a
>> file dated 2016, and not update the copyright in the destination
>> file. It's easiest just to update the copyright on the file we're
>> patching to the current date.
>
> Hm, probably you're right with that. However, actually, for process
> simplicity's sake, I think we're doing quite some mistakes in that
> sense though.
>
> Because currently, if a backport change happens to be the one that
> updated a copyright year, we'll do it correctly and also increment
> the copyright year in the backported file. But if we're bringing
> down a change that has happened over the year, that is, after some
> other change previously had to update the copyright year, we'll miss
> that and have newer code than the copyright year indicates in
> certain files.
>
> I guess this process is that what Oracle does and what they laid out
> when owning the updates project. But do we need to adjust this?

I'd just update the destination file to the current date. But please
don't go back making changes to work we've already done: it's not
hugely important, IMO.

> Other than that, I see no point in rejecting backports of changes
> like https://bugs.openjdk.java.net/browse/JDK-8220414. All the
> change does is correct the formatting of the license header to
> Oracle's standards (the comma after the second year). I don't know
> whether this comma is legally important or just a formatting thing
> but in any case, I think it corrects something which was wrong
> before. So we could admit it. But, of course, such backports should
> rather be in Oracle's interest and they only affect legal compliance
> and don't touch functionality at all, so if nobody in the community
> does backport it, it shouldn't matter either.

Exactly.

Let's remember what we're here for: our purpose is to fix significant
bugs and, occasionally, maintain compatibility. By default, we should
do nothing. If it doesn't fix a bug or enhance our users' experience
it shouldn't go in.

> After all, it all comes down to a legal discussion - and so, since
> I'm not a lawyer and not deeply into licensing laws, everything I
> say in this mail is likely to be wrong ... ??

Indeed, and arguing this stuff isn't a tremendously useful way to
spend our time.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From martin.doerr at sap.com  Fri Mar 27 12:41:58 2020
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 27 Mar 2020 12:41:58 +0000
Subject: [11] RFR(XS): 8231779: crash
 HeapWord*ParallelScavengeHeap::failed_mem_allocate
In-Reply-To: <AM7PR02MB60498654C597F3F396B1BA34ECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <AM7PR02MB60498654C597F3F396B1BA34ECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB329771C9396E85DE789CC5A59ACC0@AM0PR0202MB3297.eurprd02.prod.outlook.com>

Hi G?tz,

looks good to me.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Freitag, 27. M?rz 2020 12:58
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11] RFR(XS): 8231779: crash
> HeapWord*ParallelScavengeHeap::failed_mem_allocate
> 
> Hi,
> 
> I want to downport this for parity with 11.0.8-oracle.
> 
> I had to do some trivial resolves due to context and Copyright:
> http://cr.openjdk.java.net/~goetz/wr20/8231779-Crash_ParallelScavenge-
> jdk11/01/
> 
> original:
> https://bugs.openjdk.java.net/browse/JDK-8231779
> https://hg.openjdk.java.net/jdk/jdk/rev/fcbd54a2c2d9
> 
> Best regards,
>   Goetz.

From goetz.lindenmaier at sap.com  Fri Mar 27 13:00:17 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 27 Mar 2020 13:00:17 +0000
Subject: [11] RFR(XS): 8231779: crash
 HeapWord*ParallelScavengeHeap::failed_mem_allocate
In-Reply-To: <AM0PR0202MB329771C9396E85DE789CC5A59ACC0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
References: <AM7PR02MB60498654C597F3F396B1BA34ECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>
 <AM0PR0202MB329771C9396E85DE789CC5A59ACC0@AM0PR0202MB3297.eurprd02.prod.outlook.com>
Message-ID: <AM7PR02MB604948CA3EECDD224D15764BECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Thanks Martin!

Best regards,
  Goetz.

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Friday, March 27, 2020 1:42 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11] RFR(XS): 8231779: crash
> HeapWord*ParallelScavengeHeap::failed_mem_allocate
> 
> Hi G?tz,
> 
> looks good to me.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Freitag, 27. M?rz 2020 12:58
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11] RFR(XS): 8231779: crash
> > HeapWord*ParallelScavengeHeap::failed_mem_allocate
> >
> > Hi,
> >
> > I want to downport this for parity with 11.0.8-oracle.
> >
> > I had to do some trivial resolves due to context and Copyright:
> > http://cr.openjdk.java.net/~goetz/wr20/8231779-Crash_ParallelScavenge-
> > jdk11/01/
> >
> > original:
> > https://bugs.openjdk.java.net/browse/JDK-8231779
> > https://hg.openjdk.java.net/jdk/jdk/rev/fcbd54a2c2d9
> >
> > Best regards,
> >   Goetz.

From goetz.lindenmaier at sap.com  Fri Mar 27 15:15:17 2020
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Fri, 27 Mar 2020 15:15:17 +0000
Subject: [11u] RFR 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <877dz7fkvg.fsf@redhat.com>
References: <877dz7fkvg.fsf@redhat.com>
Message-ID: <AM7PR02MB6049841E82FE5C8C698A646DECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>

Hi Roland, 

thanks for downporting this. 

The code looks good. The code is actually the same in
find_adjacent_refs except for a difference in an unrelated
part of that larger function.

The test passes, all compiles. I also ran some smaller tests.

Looks good.

Best regards,
  Goetz.

> -----Original Message-----
> From: hotspot-compiler-dev <hotspot-compiler-dev-
> bounces at openjdk.java.net> On Behalf Of Roland Westrelin
> Sent: Thursday, March 26, 2020 11:53 AM
> To: jdk-updates-dev at openjdk.java.net; hotspot-compiler-
> dev at openjdk.java.net
> Subject: [11u] RFR 8235762: JVM crash in SWPointer during C2 compilation
> 
> 
> Original bug:
> https://bugs.openjdk.java.net/browse/JDK-8235762
> https://hg.openjdk.java.net/jdk/jdk/rev/5aa85653a589
> 
> Original patch does not apply cleanly to 11u in
> SuperWord::find_adjacent_refs(). The original change in jdk 14 partially
> reverts a previous change in SuperWord::find_adjacent_refs() that's not
> in jdk 11. With the patch I propose, SuperWord::find_adjacent_refs() is
> mostly identical to today's code in jdk 15.
> 
> 11u webrev:
>   http://cr.openjdk.java.net/~roland/8235762.11u/webrev.00/
> 
> Testing: x86_64/aarch4 build, verified new test fails without the patch
> and runs fine with it on aarch64, tier1 + tier2
> 
> Roland.


From rwestrel at redhat.com  Fri Mar 27 15:27:46 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Fri, 27 Mar 2020 16:27:46 +0100
Subject: [11u] RFR 8235762: JVM crash in SWPointer during C2 compilation
In-Reply-To: <AM7PR02MB6049841E82FE5C8C698A646DECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>
References: <877dz7fkvg.fsf@redhat.com>
 <AM7PR02MB6049841E82FE5C8C698A646DECCC0@AM7PR02MB6049.eurprd02.prod.outlook.com>
Message-ID: <87k135es25.fsf@redhat.com>


Hi Goetz,

> Looks good.

Thanks for the review!

Roland.


From martijnverburg at gmail.com  Mon Mar 30 21:00:40 2020
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 30 Mar 2020 21:00:40 +0000
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <4af75b06-4dd2-45b4-a395-d1f2a989cdc2.denghui.ddh@alibaba-inc.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
 <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
 <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>
 <CAJwKKmaoY-U8jEApyAGDDbYZ0cc8oH367qAoRJuASp3KZWt9bQ@mail.gmail.com>
 <4af75b06-4dd2-45b4-a395-d1f2a989cdc2.denghui.ddh@alibaba-inc.com>
Message-ID: <CAP7YuASJtC+-Cx5qPeF_Z+YmNeBJaJ27mkVsFbWqS4UdLNK7FQ@mail.gmail.com>

Hi All,

Microsoft will be able to commit some folks to this from mid-April onward
and will be willing to help maintain the JFR backport across 8u and 11u
alongside Alibaba and other interested folks going forward.

I'll get the engineers to jump on this list and start the learning process.

Cheers,
Martijn


On Wed, 25 Mar 2020 at 06:06, Denghui Dong <denghui.ddh at alibaba-inc.com>
wrote:

> Hi,
>
> I believe there will be some volunteers, at least we(Alibaba) are willing
> to do it. Of course,
> the premise of all this is that the maintainers agree with the work.
>
> As Erik said, JFR Streaming has changed the internal implementation of
> jfr, so I think we need
> to create an incubator branch and a small discussion group to trace this
> work, and we need some experienced people to help us. ??
>
> Besides, JFR has just entered 8u, so I agree with Mario that it isn't
> appropriate time to discuss
> backporting JFR Streaming to 8u.
>
> Thanks,
> Denghui
>
> ------------------------------------------------------------------
> From:Mario Torre <neugens at redhat.com>
> Send Time:2020?3?25?(???) 00:31
> To:Martijn Verburg <martijnverburg at gmail.com>
> Cc:jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject:Re: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
>
> On Tue, Mar 24, 2020 at 5:19 PM Martijn Verburg
> <martijnverburg at gmail.com> wrote:
> >
> > Hi all,
> >
> > Could we create a project/tree/branch for this work (jdk11u-jfr-test or
> some such) that a bunch of us could work on together to ensure the
> stability and quality of the patch before it goes into 11u?
>
> For the JFR backport we created a small team, most of us were, if not
> full time, at least "stable" on the project. While anyone could join
> and share some knowledge, review a patch, or contribute some work, a
> stable team means we can ensure questions and reviews are done
> correctly and timely (after all, this is what happens in OpenJDK as
> well).
>
> So the question here would be if there is enough of manpower to
> dedicate to this project from the interested parties.
>
> Denghui has already done the backport but my experience with JFR tells
> me that work will be needed on top of this anyway.
>
> If we have consensus that this should go into the release (from the
> maintainers) and the we have a critical mass of developers that are
> willing to dedicate to it, then we can request an incubator repository
> like we did with the JFR backport.
>
> In other words, we need to have some volunteers that understand this
> may be a time intensive work for the next weeks or months, and that
> will need to be maintained after this when it's merged.
>
> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens.limasoftware at gmail.com  Mon Mar 30 21:45:08 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Mon, 30 Mar 2020 23:45:08 +0200
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAP7YuASJtC+-Cx5qPeF_Z+YmNeBJaJ27mkVsFbWqS4UdLNK7FQ@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
 <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
 <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>
 <CAJwKKmaoY-U8jEApyAGDDbYZ0cc8oH367qAoRJuASp3KZWt9bQ@mail.gmail.com>
 <4af75b06-4dd2-45b4-a395-d1f2a989cdc2.denghui.ddh@alibaba-inc.com>
 <CAP7YuASJtC+-Cx5qPeF_Z+YmNeBJaJ27mkVsFbWqS4UdLNK7FQ@mail.gmail.com>
Message-ID: <CAGUMyaRJbRT1Z2L+EgiCVgaPccXbApXUBo0SFYj7TAw4OgnpEg@mail.gmail.com>

Hi Martijn,

Thanks, this is great news!

Cheers,
Mario

Il giorno lun 30 mar 2020 alle ore 23:01 Martijn Verburg
<martijnverburg at gmail.com> ha scritto:
>
> Hi All,
>
> Microsoft will be able to commit some folks to this from mid-April onward
> and will be willing to help maintain the JFR backport across 8u and 11u
> alongside Alibaba and other interested folks going forward.
>
> I'll get the engineers to jump on this list and start the learning process.
>
> Cheers,
> Martijn
>
>
> On Wed, 25 Mar 2020 at 06:06, Denghui Dong <denghui.ddh at alibaba-inc.com>
> wrote:
>
> > Hi,
> >
> > I believe there will be some volunteers, at least we(Alibaba) are willing
> > to do it. Of course,
> > the premise of all this is that the maintainers agree with the work.
> >
> > As Erik said, JFR Streaming has changed the internal implementation of
> > jfr, so I think we need
> > to create an incubator branch and a small discussion group to trace this
> > work, and we need some experienced people to help us.
> >
> > Besides, JFR has just entered 8u, so I agree with Mario that it isn't
> > appropriate time to discuss
> > backporting JFR Streaming to 8u.
> >
> > Thanks,
> > Denghui
> >
> > ------------------------------------------------------------------
> > From:Mario Torre <neugens at redhat.com>
> > Send Time:2020?3?25?(???) 00:31
> > To:Martijn Verburg <martijnverburg at gmail.com>
> > Cc:jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject:Re: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
> >
> > On Tue, Mar 24, 2020 at 5:19 PM Martijn Verburg
> > <martijnverburg at gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > Could we create a project/tree/branch for this work (jdk11u-jfr-test or
> > some such) that a bunch of us could work on together to ensure the
> > stability and quality of the patch before it goes into 11u?
> >
> > For the JFR backport we created a small team, most of us were, if not
> > full time, at least "stable" on the project. While anyone could join
> > and share some knowledge, review a patch, or contribute some work, a
> > stable team means we can ensure questions and reviews are done
> > correctly and timely (after all, this is what happens in OpenJDK as
> > well).
> >
> > So the question here would be if there is enough of manpower to
> > dedicate to this project from the interested parties.
> >
> > Denghui has already done the backport but my experience with JFR tells
> > me that work will be needed on top of this anyway.
> >
> > If we have consensus that this should go into the release (from the
> > maintainers) and the we have a critical mass of developers that are
> > willing to dedicate to it, then we can request an incubator repository
> > like we did with the JFR backport.
> >
> > In other words, we need to have some volunteers that understand this
> > may be a time intensive work for the next weeks or months, and that
> > will need to be maintained after this when it's merged.
> >
> > Cheers,
> > Mario
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From yan at azul.com  Tue Mar 31 08:33:57 2020
From: yan at azul.com (Yuri Nesterenko)
Date: Tue, 31 Mar 2020 11:33:57 +0300
Subject: [13u] RFR: 8241913: Bump update version for OpenJDK: jdk-13.0.4
Message-ID: <09f82ff1-4294-1c7a-4b25-0d6e7c9fa65b@azul.com>

Hi,

to start the next development period of jdk-13.0.4, we need to bump the version in jdk13u-dev
Please review:
http://cr.openjdk.java.net/~yan/8241913/webrev.0/

I'll push the change after successful request to add 13.0.4 to JBS and to hgupdater.

Release date set to July 14, see https://www.oracle.com/security-alerts/

Thanks,
--yan


From zgu at redhat.com  Tue Mar 31 16:18:46 2020
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 31 Mar 2020 12:18:46 -0400
Subject: [11u] RFR 8212986: Make Visual Studio compiler check less strict
Message-ID: <00d4768f-b5c5-ab4c-e393-197da1e9f7db@redhat.com>

Hi,

I would like to backport this small patch to 11u, so that can build JDK 
with VSC++ with different locals, other than English.

The original patch does not apply cleanly, but the conflicts are minor, 
just line shifts.

Original Bug: https://bugs.openjdk.java.net/browse/JDK-8212986
Original webrev: https://hg.openjdk.java.net/jdk/jdk/rev/885b23ef907d

11u webrev: http://cr.openjdk.java.net/~zgu/JDK-8212986_11u/webrev.00/

Test:
   Built jdk11u on Windows.

Thanks,

-Zhengyu


From christoph.langer at sap.com  Tue Mar 31 19:27:21 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 31 Mar 2020 19:27:21 +0000
Subject: [13u] RFR: 8241913: Bump update version for OpenJDK: jdk-13.0.4
In-Reply-To: <09f82ff1-4294-1c7a-4b25-0d6e7c9fa65b@azul.com>
References: <09f82ff1-4294-1c7a-4b25-0d6e7c9fa65b@azul.com>
Message-ID: <AM0PR02MB5714B876F2FDAD79899B8EED8AC80@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Yan,

looks correct to me ??

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Yuri Nesterenko
> Sent: Dienstag, 31. M?rz 2020 10:34
> To: jdk-updates-dev at openjdk.java.net
> Subject: [13u] RFR: 8241913: Bump update version for OpenJDK: jdk-13.0.4
> 
> Hi,
> 
> to start the next development period of jdk-13.0.4, we need to bump the
> version in jdk13u-dev
> Please review:
> http://cr.openjdk.java.net/~yan/8241913/webrev.0/
> 
> I'll push the change after successful request to add 13.0.4 to JBS and to
> hgupdater.
> 
> Release date set to July 14, see https://www.oracle.com/security-alerts/
> 
> Thanks,
> --yan


From bevans at newrelic.com  Tue Mar 31 21:01:30 2020
From: bevans at newrelic.com (Ben Evans)
Date: Tue, 31 Mar 2020 23:01:30 +0200
Subject: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
In-Reply-To: <CAP7YuASJtC+-Cx5qPeF_Z+YmNeBJaJ27mkVsFbWqS4UdLNK7FQ@mail.gmail.com>
References: <e1e7d325-4794-46c0-97ee-ad8213a29907.denghui.ddh@alibaba-inc.com>
 <c611ffdf-30a9-0092-e407-8982f73031e8@oracle.com>
 <CAGUMyaR7dYNnFNkkhZ7+VZuWcb_K+maOgxJtwdnfZFcYPn_mAg@mail.gmail.com>
 <CAGw=730iFqEbQNnQaCYbx8dyOeuxYXOjJqNh0e3v81epgsLo0w@mail.gmail.com>
 <CAJwKKmaAr5oF8Q9mW_mFwQsCdxcFCpjT3KmVghboZoh0y9H+2Q@mail.gmail.com>
 <CAP7YuARcvQNrTc8vp6r9TPTf1XCYMvfu_nj6k_nNzGczLj7-pg@mail.gmail.com>
 <CAJwKKmaoY-U8jEApyAGDDbYZ0cc8oH367qAoRJuASp3KZWt9bQ@mail.gmail.com>
 <4af75b06-4dd2-45b4-a395-d1f2a989cdc2.denghui.ddh@alibaba-inc.com>
 <CAP7YuASJtC+-Cx5qPeF_Z+YmNeBJaJ27mkVsFbWqS4UdLNK7FQ@mail.gmail.com>
Message-ID: <CAGw=731H+292NGgSQ1M4Je19DEfHoy0_5pnO0F92xXs1xDyieg@mail.gmail.com>

Hi everyone,

I'm still working out the final details with our execs, but I'm happy to
announce that New Relic will be committing engineering time to this project
and will be helping to incubate, test and maintain the backport.

Some other New Relic folks should be showing up on-list in the coming days.

Thanks,

Ben

On Mon, Mar 30, 2020 at 11:04 PM Martijn Verburg <martijnverburg at gmail.com>
wrote:

> Hi All,
>
> Microsoft will be able to commit some folks to this from mid-April onward
> and will be willing to help maintain the JFR backport across 8u and 11u
> alongside Alibaba and other interested folks going forward.
>
> I'll get the engineers to jump on this list and start the learning process.
>
> Cheers,
> Martijn
>
>
> On Wed, 25 Mar 2020 at 06:06, Denghui Dong <denghui.ddh at alibaba-inc.com>
> wrote:
>
> > Hi,
> >
> > I believe there will be some volunteers, at least we(Alibaba) are willing
> > to do it. Of course,
> > the premise of all this is that the maintainers agree with the work.
> >
> > As Erik said, JFR Streaming has changed the internal implementation of
> > jfr, so I think we need
> > to create an incubator branch and a small discussion group to trace this
> > work, and we need some experienced people to help us. ??
> >
> > Besides, JFR has just entered 8u, so I agree with Mario that it isn't
> > appropriate time to discuss
> > backporting JFR Streaming to 8u.
> >
> > Thanks,
> > Denghui
> >
> > ------------------------------------------------------------------
> > From:Mario Torre <neugens at redhat.com>
> > Send Time:2020?3?25?(???) 00:31
> > To:Martijn Verburg <martijnverburg at gmail.com>
> > Cc:jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject:Re: [11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
> >
> > On Tue, Mar 24, 2020 at 5:19 PM Martijn Verburg
> > <martijnverburg at gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > Could we create a project/tree/branch for this work (jdk11u-jfr-test or
> > some such) that a bunch of us could work on together to ensure the
> > stability and quality of the patch before it goes into 11u?
> >
> > For the JFR backport we created a small team, most of us were, if not
> > full time, at least "stable" on the project. While anyone could join
> > and share some knowledge, review a patch, or contribute some work, a
> > stable team means we can ensure questions and reviews are done
> > correctly and timely (after all, this is what happens in OpenJDK as
> > well).
> >
> > So the question here would be if there is enough of manpower to
> > dedicate to this project from the interested parties.
> >
> > Denghui has already done the backport but my experience with JFR tells
> > me that work will be needed on top of this anyway.
> >
> > If we have consensus that this should go into the release (from the
> > maintainers) and the we have a critical mass of developers that are
> > willing to dedicate to it, then we can request an incubator repository
> > like we did with the JFR backport.
> >
> > In other words, we need to have some volunteers that understand this
> > may be a time intensive work for the next weeks or months, and that
> > will need to be maintained after this when it's merged.
> >
> > Cheers,
> > Mario
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>