From poonam at openjdk.org  Mon Aug  1 16:38:30 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 1 Aug 2022 16:38:30 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do
Message-ID: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>

Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.

    8071507: (ref) Clear phantom reference as soft and weak references do
    8143847: Remove REF_CLEANER reference category

With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.

The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

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

Commit messages:
 - 8071507: (ref) Clear phantom reference as soft and weak references do

Changes: https://git.openjdk.org/jdk8u-dev/pull/94/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=94&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8071507
  Stats: 170 lines in 10 files changed: 105 ins; 48 del; 17 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/94/head:pull/94

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From andrew at openjdk.org  Mon Aug  1 17:45:56 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 1 Aug 2022 17:45:56 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master
Message-ID: <XfjoahIWm8GtBny89swNjAvAXNnTSJdFFYeXNp--3qk=.94d1944e-52f6-44b8-811f-1dd603a05602@github.com>

Merge 8u345 interim release back into 8u-dev

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

Commit messages:
 - Merge
 - 8290832: It is no longer possible to change "user.dir" in the JDK8
 - 8291568: Bump update version of OpenJDK: 8u345

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk8u-dev/pull/95/files
  Stats: 67 lines in 3 files changed: 0 ins; 65 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/95/head:pull/95

PR: https://git.openjdk.org/jdk8u-dev/pull/95

From duke at openjdk.org  Mon Aug  1 17:46:07 2022
From: duke at openjdk.org (Evgeny Astigeevich)
Date: Mon, 1 Aug 2022 17:46:07 GMT
Subject: [jdk8u-dev] RFR: 8274840: Update OS detection code to recognize
 Windows 11
In-Reply-To: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
References: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
Message-ID: <4Fyjibq_f_-_URtT6tZQo49k7NB6kIsLWuDymf6ouk8=.c6a04ad8-5814-46db-890a-d331207e8142@github.com>

On Fri, 29 Jul 2022 22:38:36 GMT, Rui Li <duke at openjdk.org> wrote:

> This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014
> 
> The original author is Matthias Baesken and co-authored by Arno Zeller. It was reviewed by clanger, dholmes.
> 
> The backport was clean after updating filepath.
> 
> 
> Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

Confirm it is clean.

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

Marked as reviewed by eastig at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk8u-dev/pull/93

From andrew at openjdk.org  Mon Aug  1 20:20:06 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 1 Aug 2022 20:20:06 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master [v2]
In-Reply-To: <XfjoahIWm8GtBny89swNjAvAXNnTSJdFFYeXNp--3qk=.94d1944e-52f6-44b8-811f-1dd603a05602@github.com>
References: <XfjoahIWm8GtBny89swNjAvAXNnTSJdFFYeXNp--3qk=.94d1944e-52f6-44b8-811f-1dd603a05602@github.com>
Message-ID: <eAA3ienr6aLAIVsMYrl81sY6CUfw7Eg-cen43bs8IF0=.79929684-ff5c-48b0-a6e7-cc09939b4d8e@github.com>

> Merge 8u345 interim release back into 8u-dev

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - Merge
 - Merge
 - 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
   
   Backport-of: 4140fd05a447c888856c54aee22c475173030833
 - 8194873: right ALT key hotkeys no longer work in Swing components
   8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
   
   Reviewed-by: alitvinov, yan, serb
   Backport-of: 91f281c8d713e489ddc282f935ebd879485c4b41
 - 8282538: PKCS11 tests fail on CentOS Stream 9
   
   Backport-of: d8fd22239bafecdaaedb8985ab6d709ed846e808
 - 8256722: handle VC++:1927 VS2019 in  abstract_vm_version
   
   Backport-of: 146fe86ff68095b5eb0ce1387061699738280c06
 - 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit
   
   Reviewed-by: phh
   Backport-of: b67ca938f37f952e53f73d2e0b8ebcaf96139fda
 - 8235218: Minimal VM is broken after JDK-8173361
   
   Reviewed-by: sgehwolf, andrew
   Backport-of: c10f731b11f314c97660df08c62f3c3d2f718f54
 - 8150669: C1 intrinsic for Class.isPrimitive
   
   Reviewed-by: phh
   Backport-of: 890f94d7e6be731ac2ebae2f1ad3cc20ec836115
 - 8283849: AsyncGetCallTrace may crash JVM on guarantee
   
   Reviewed-by: phh
   Backport-of: 19639855311a47ed532547743ea3873eb8b016d3
 - ... and 7 more: https://git.openjdk.org/jdk8u-dev/compare/2dadc2bf...0a71d8c0

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

Changes: https://git.openjdk.org/jdk8u-dev/pull/95/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=95&range=01
  Stats: 1948 lines in 56 files changed: 1751 ins; 80 del; 117 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/95.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/95/head:pull/95

PR: https://git.openjdk.org/jdk8u-dev/pull/95

From andrew at openjdk.org  Mon Aug  1 20:20:07 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 1 Aug 2022 20:20:07 GMT
Subject: [jdk8u-dev] Integrated: Merge jdk8u:master
In-Reply-To: <XfjoahIWm8GtBny89swNjAvAXNnTSJdFFYeXNp--3qk=.94d1944e-52f6-44b8-811f-1dd603a05602@github.com>
References: <XfjoahIWm8GtBny89swNjAvAXNnTSJdFFYeXNp--3qk=.94d1944e-52f6-44b8-811f-1dd603a05602@github.com>
Message-ID: <9BWse1K1lzpuIe0pMr17ReOkhBTB_ZylvNYEDLWYbHM=.bec395e6-60c3-4da2-b1c1-ca17b5ea9977@github.com>

On Mon, 1 Aug 2022 17:39:59 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge 8u345 interim release back into 8u-dev

This pull request has now been integrated.

Changeset: 1460bfaf
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/1460bfaf8a3be7c4772bfbb75b8a3a31560a2c2c
Stats:     67 lines in 3 files changed: 0 ins; 65 del; 2 mod

Merge

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

PR: https://git.openjdk.org/jdk8u-dev/pull/95

From gnu.andrew at redhat.com  Tue Aug  2 01:38:01 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 2 Aug 2022 02:38:01 +0100
Subject: OpenJDK 8u345 Released
Message-ID: <Yuh/+eGxetz97z4o@hex.discworld.ac.uk>

We are pleased to announce the release of OpenJDK 8u345.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u345-b01.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u345-b01.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

d3e8b554e519c53454a6c6ef1680b18d3f77ea90f3cd2c853598cb3970004ee2  openjdk8u345-b01.tar.xz
1656ceaf6811ef2693efb2152ff2c793f114e03504396977e80f809ce0405667  openjdk8u345-b01.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u345-b01.sha256

New in release OpenJDK 8u345 (2022-08-01):
===========================================
Live versions of these release notes can be found at:
  * https://bit.ly/openjdk8u345
  * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u345.txt

* Other changes
  - JDK-8290832: It is no longer possible to change "user.dir" in the JDK8
  - JDK-8291568: Bump update version of OpenJDK: 8u345

Notes on individual issues:
===========================

JDK-8290832: It is no longer possible to change "user.dir" in the JDK8
======================================================================
A change, JDK-8194154, was introduced in the 8u342 release of OpenJDK,
causing the JDK to ignore attempts to set the `user.dir` property.
While this change is suitable for a major release (it was originally
introduced in the initial release of OpenJDK 11), changing the
behaviour of such a property in an update release creates
compatibility issues in software that relies on the behaviour in prior
versions of OpenJDK 8.  As a result, we have reverted this change in
8u345.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220802/be7e0da2/signature-0001.asc>

From duke at openjdk.org  Tue Aug  2 06:22:03 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Tue, 2 Aug 2022 06:22:03 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp [v2]
In-Reply-To: <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@github.com>
References: <WCZSnJWqvZqlMsQizOTcP0iaua8g2s4Kk2Ce5mOj6a0=.0b7e5a68-af18-4784-8570-8fdbebff7bdc@github.com>
 <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@github.com>
Message-ID: <pm9iswijyCYcIJdAU9yyhNMdj5FiqQT6DaOWA6n1Ekc=.72a01f74-eec4-493a-9824-564bd504bfd1@github.com>

On Wed, 22 Jun 2022 08:54:19 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

>> Hi! Please review another backport from MSVS2019 seria. This one fixes type declarations made by globalDefinitions_VisCPP.hpp. The patch from 11u applied with the following changes:
>> 
>> - inttypes.h is included conditionally under `_MSC_VER >= 1800` because the header was introduced only in MSVS 2013 but we have to keep support of the earlier MSVS versions 
>> - the duplicates of declarations made in inttypes.h are not just removed but quoted with `_MSC_VER < 1800`
>> - common\autoconf\generated-configure.sh is regenerated to add MSVS2019 recognition (I forgot to do that in https://github.com/openjdk/jdk8u-dev/pull/33)
>> 
>> Verification: 2019 build (both 32/64) now fails with 
>> 
>> ad_x86_64_pipeline.obj : error LNK2011: precompiled object not linked in; image may not run
>> jvm.dll : fatal error LNK1120: 1 unresolved externals
>> 
>> error (to be fixed by backport of 8043492)
>> 
>> Regression: 2017/2013/2012/2010 full build - ok
>> 
>> @kimbarrett @dholmes-ora if you took a look at that it would be very much appreciated
>
> Alexey Pavlyutkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge master
>  - fixing carriage returns
>  - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f

Guys, this one stops a seria of backports required to support VS 2019/22. Could somebody to review it? Thank you

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

PR: https://git.openjdk.org/jdk8u-dev/pull/77

From iris at openjdk.org  Tue Aug  2 17:39:56 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 2 Aug 2022 17:39:56 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do
In-Reply-To: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
Message-ID: <4hHZSh2OSXHbS-5jDz6oKM06LexmIqYQvE8n59YfFmg=.df724916-8c52-4866-a6af-f4be73c3e193@github.com>

On Mon, 1 Aug 2022 16:30:17 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
> 
>     8071507: (ref) Clear phantom reference as soft and weak references do
>     8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
> 
> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

Spec changes match those expected in JSR 337 MR 4.

Thank you!

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From dholmes at openjdk.org  Wed Aug  3 02:15:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 Aug 2022 02:15:56 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do
In-Reply-To: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
Message-ID: <9PwytmFnm_-y_rex7GUBUOOqanfVeu3no4KAkHm7vEQ=.602e5714-fd73-492c-98e1-95433c76f84f@github.com>

On Mon, 1 Aug 2022 16:30:17 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
> 
>     8071507: (ref) Clear phantom reference as soft and weak references do
>     8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
> 
> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

This is an accurate backport. Thanks @poonamparhar !

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From sgehwolf at openjdk.org  Wed Aug  3 17:16:44 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 3 Aug 2022 17:16:44 GMT
Subject: [jdk8u-dev] RFR: 8290000: Bump macOS GitHub actions to macOS 11
 [v2]
In-Reply-To: <nBHuEq7bqCWwlWH-n7tn-wIbpFjtw8l41Mgl-NbVT80=.c4c286fe-3ef6-44b5-856a-0503c8f07c94@github.com>
References: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>
 <nBHuEq7bqCWwlWH-n7tn-wIbpFjtw8l41Mgl-NbVT80=.c4c286fe-3ef6-44b5-856a-0503c8f07c94@github.com>
Message-ID: <c9LRAftMBYlebllE7_fKX9wn_U7YG9nNKrom_YD-BAA=.3752c738-1309-4856-8c12-bc34531645cd@github.com>

On Thu, 21 Jul 2022 09:59:08 GMT, George Adams <duke at openjdk.org> wrote:

>> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context.
>> 
>> This PR doesn't apply cleanly because it was added to the GitHub actions rewrite in tip. As it's unlikely that I will have a backported rewrite by August 30th my preference is to backport this way round.
>
> George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Backport 4e6cd67fec3d978f4c8c1aed95a1d09b544eff68

Looks fine to me and GHA seems happy. Thumbs up!

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/87

From duke at openjdk.org  Wed Aug  3 20:58:10 2022
From: duke at openjdk.org (George Adams)
Date: Wed, 3 Aug 2022 20:58:10 GMT
Subject: [jdk8u-dev] RFR: 8290000: Bump macOS GitHub actions to macOS 11
 [v2]
In-Reply-To: <c9LRAftMBYlebllE7_fKX9wn_U7YG9nNKrom_YD-BAA=.3752c738-1309-4856-8c12-bc34531645cd@github.com>
References: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>
 <nBHuEq7bqCWwlWH-n7tn-wIbpFjtw8l41Mgl-NbVT80=.c4c286fe-3ef6-44b5-856a-0503c8f07c94@github.com>
 <c9LRAftMBYlebllE7_fKX9wn_U7YG9nNKrom_YD-BAA=.3752c738-1309-4856-8c12-bc34531645cd@github.com>
Message-ID: <ghk5Y_9IMGS65esAlqxKrMDk-PFjDOsnFba4z6fwcrM=.90637db4-03f4-4c97-958c-1fda413c36da@github.com>

On Wed, 3 Aug 2022 16:56:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Backport 4e6cd67fec3d978f4c8c1aed95a1d09b544eff68
>
> Looks fine to me and GHA seems happy. Thumbs up!

Fix request is complete. @jerboaa are you willing to sponsor the change?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/87

From mchung at openjdk.org  Wed Aug  3 23:43:03 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 3 Aug 2022 23:43:03 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do
In-Reply-To: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
Message-ID: <5kjqKwhLq5XAZGYd35UfC2N9CAyZACD1TXUoLubg_dk=.5009e3ba-d989-4bb7-9061-8dbec6c60d58@github.com>

On Mon, 1 Aug 2022 16:30:17 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
> 
>     8071507: (ref) Clear phantom reference as soft and weak references do
>     8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
> 
> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

LGTM

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From serb at openjdk.org  Thu Aug  4 00:14:59 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 4 Aug 2022 00:14:59 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
Message-ID: <xoDeT0n-xnY46A0MGTuJkEYp_XRcsKi4vpZZthKDVn8=.2e3bd5bd-5d4e-4316-a5da-f4229f02ad2b@github.com>

On Tue, 26 Jul 2022 20:31:56 GMT, Rui Li <duke at openjdk.org> wrote:

> jdk commit: https://github.com/openjdk/jdk/commit/fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f
> 
> Clean backport.

Please add a note on how it was tested.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Thu Aug  4 00:20:58 2022
From: duke at openjdk.org (Rui Li)
Date: Thu, 4 Aug 2022 00:20:58 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <xoDeT0n-xnY46A0MGTuJkEYp_XRcsKi4vpZZthKDVn8=.2e3bd5bd-5d4e-4316-a5da-f4229f02ad2b@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
 <xoDeT0n-xnY46A0MGTuJkEYp_XRcsKi4vpZZthKDVn8=.2e3bd5bd-5d4e-4316-a5da-f4229f02ad2b@github.com>
Message-ID: <5_PO2D6BPhFts9VnCWMPB6GzpuGhKnBs3BRy7XqRe9M=.aa993c52-56bc-4c7c-b269-5a39efb3b254@github.com>

On Thu, 4 Aug 2022 00:11:06 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Please add a note on how it was tested.

Updated the overview with manual test description. Also triggered a new `Pre-submit` action for the branch: https://github.com/rgithubli/jdk8u-dev/actions/workflows/submit.yml. Thanks.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Thu Aug  4 07:15:04 2022
From: duke at openjdk.org (George Adams)
Date: Thu, 4 Aug 2022 07:15:04 GMT
Subject: [jdk8u-dev] Integrated: 8290000: Bump macOS GitHub actions to macOS 11
In-Reply-To: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>
References: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>
Message-ID: <a5Pk0KBd5eN5QbZZjMN9rGt8TbiQ0vTS6VecrRNpF70=.fd3ccf8a-b716-47f0-ab63-69124619ceb1@github.com>

On Thu, 21 Jul 2022 09:45:23 GMT, George Adams <duke at openjdk.org> wrote:

> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context.
> 
> This PR doesn't apply cleanly because it was added to the GitHub actions rewrite in tip. As it's unlikely that I will have a backported rewrite by August 30th my preference is to backport this way round.

This pull request has now been integrated.

Changeset: 39fa6fb1
Author:    George Adams <georgeadams1995 at gmail.com>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/39fa6fb17215d823aacad51669750b76c987973d
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8290000: Bump macOS GitHub actions to macOS 11

Reviewed-by: sgehwolf
Backport-of: 4e6cd67fec3d978f4c8c1aed95a1d09b544eff68

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

PR: https://git.openjdk.org/jdk8u-dev/pull/87

From duke at openjdk.org  Thu Aug  4 07:39:18 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Thu, 4 Aug 2022 07:39:18 GMT
Subject: [jdk8u-dev] RFR: 8288865: [aarch64] LDR instructions must use
 legitimized addresses
In-Reply-To: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
References: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
Message-ID: <s3QYuvNw42GngLrhXxfHRxlVI7tmJDsAjU89ECf-zLQ=.6f0171a8-c80e-4312-a4f8-06f48214a6e7@github.com>

On Wed, 20 Jul 2022 09:06:28 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi! Here is a backport fixing offset large offsets on memory reading by Unsafe API for Aarch64. Except 11->8 path suffling the fix applied with the only change: only LDR-related part of the test is being backported cuz 8u-dev already has got STR-related one.
> 
> Verification (Ubuntu 18.04.6 LTS (GNU/Linux 4.9.0 aarch64)): 
> 
> hotspot/test/compiler/8235385/NonVolatileMemoryAccessWithLongOffset.java
> 
> 10 of 10 runs PASS (5 of 10 runs FAILED before the patch applied)
> 
> Regression: hotspot/test/compiler
> 
> @theRealAph could you take a look, it's almost clean except the fact that STR-related part of test already presents in 8u-dev

@jerboaa could you look at this one and approve if it's Ok? Thank you

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

PR: https://git.openjdk.org/jdk8u-dev/pull/84

From sgehwolf at openjdk.org  Thu Aug  4 09:02:06 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 Aug 2022 09:02:06 GMT
Subject: [jdk8u-dev] RFR: 8288865: [aarch64] LDR instructions must use
 legitimized addresses
In-Reply-To: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
References: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
Message-ID: <l1M5FC9PDDz1eKoYycIJmS94GnpPZScBEgZbw9ITiCM=.341db02d-3847-4211-91ee-a061e845eb4f@github.com>

On Wed, 20 Jul 2022 09:06:28 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi! Here is a backport fixing offset large offsets on memory reading by Unsafe API for Aarch64. Except 11->8 path suffling the fix applied with the only change: only LDR-related part of the test is being backported cuz 8u-dev already has got STR-related one.
> 
> Verification (Ubuntu 18.04.6 LTS (GNU/Linux 4.9.0 aarch64)): 
> 
> hotspot/test/compiler/8235385/NonVolatileMemoryAccessWithLongOffset.java
> 
> 10 of 10 runs PASS (5 of 10 runs FAILED before the patch applied)
> 
> Regression: hotspot/test/compiler
> 
> @theRealAph could you take a look, it's almost clean except the fact that STR-related part of test already presents in 8u-dev

I'll let @theRealAph approve this one.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/84

From duke at openjdk.org  Thu Aug  4 13:45:08 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Thu, 4 Aug 2022 13:45:08 GMT
Subject: [jdk8u-dev] Integrated: 8288865: [aarch64] LDR instructions must use
 legitimized addresses
In-Reply-To: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
References: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
Message-ID: <nu5gNnA6zh_ynyNNNfj09J6nk2XUqULY8VRa5PmyjqE=.fdfaab64-aa92-467c-af5b-4bbb9f25dab1@github.com>

On Wed, 20 Jul 2022 09:06:28 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi! Here is a backport fixing offset large offsets on memory reading by Unsafe API for Aarch64. Except 11->8 path suffling the fix applied with the only change: only LDR-related part of the test is being backported cuz 8u-dev already has got STR-related one.
> 
> Verification (Ubuntu 18.04.6 LTS (GNU/Linux 4.9.0 aarch64)): 
> 
> hotspot/test/compiler/8235385/NonVolatileMemoryAccessWithLongOffset.java
> 
> 10 of 10 runs PASS (5 of 10 runs FAILED before the patch applied)
> 
> Regression: hotspot/test/compiler
> 
> @theRealAph could you take a look, it's almost clean except the fact that STR-related part of test already presents in 8u-dev

This pull request has now been integrated.

Changeset: deae94f8
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/deae94f8e3805cf806967d7b320c20d87c0ffab0
Stats:     191 lines in 3 files changed: 149 ins; 2 del; 40 mod

8288865: [aarch64] LDR instructions must use legitimized addresses

Reviewed-by: adinn
Backport-of: 1f4028960a3934853104efd1d95991b137b5f520

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

PR: https://git.openjdk.org/jdk8u-dev/pull/84

From andrew at openjdk.org  Fri Aug  5 16:40:23 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 5 Aug 2022 16:40:23 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do [v2]
In-Reply-To: <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
 <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>
Message-ID: <Egr_DhUcTBqt46mr-iHq-wt4X5UviN4wASRX7T2TkJI=.e4615b9e-2645-4d1a-bf5b-af36acf4443b@github.com>

On Thu, 21 Apr 2022 16:05:25 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> These changes backport the following fixes to jdk8u-ri:
>> - 8071507: (ref) Clear phantom reference as soft and weak references do
>> - 8143847: Remove REF_CLEANER reference category
>> 
>> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected documentation in package.html

Is there a reason for backporting two changes in one PR? I see this was done in 8u42 as well. It makes it harder to review than necessary, notably where the two change the same code in `referenceProcessor.cpp`.

Also, SKARA does not appear to be picking this up as a backport, as the "Backport <commit>" style was not used (https://wiki.openjdk.org/display/SKARA/Backports). Ideally it would refer to the changeset in 8u42, [ad6cdea5ae385623afa86251a8278c9c5274f4c1](https://git.openjdk.java.net/jdk8u-ri/commit/ad6cdea5ae385623afa86251a8278c9c5274f4c1), but it may have to be one of the three original changesets from jdk

In the code itself, three files are missing copyright header changes where they are newer than the current version: `referenceProcessor.hpp`, `referenceProcessor.cpp" and `referenceType.hpp`.  8143847 bumps all of these to 2016 and this change should do the same. The other files already have a newer copyright year than in 8143847.

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

PR: https://git.openjdk.org/jdk8u-ri/pull/4

From andrew at openjdk.org  Fri Aug  5 16:41:26 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 5 Aug 2022 16:41:26 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do
In-Reply-To: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
Message-ID: <DejSWRcbfIqUuHPA7xJTvVIEg9Y-w-WEyofr4lG4GSs=.a6e201b5-3611-4a51-8df3-6aa7ae6c4ca7@github.com>

On Mon, 1 Aug 2022 16:30:17 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
> 
>     8071507: (ref) Clear phantom reference as soft and weak references do
>     8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
> 
> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

Is there a reason for backporting two changes in one PR? I see this was done in 8u42 as well. It makes it harder to review than necessary, notably where the two change the same code in `referenceProcessor.cpp`.

Also, SKARA does not appear to be picking this up as a backport, as the "Backport <commit>" style was not used (https://wiki.openjdk.org/display/SKARA/Backports). Ideally it would refer to the changeset in 8u42, [ad6cdea5ae385623afa86251a8278c9c5274f4c1](https://git.openjdk.java.net/jdk8u-ri/commit/ad6cdea5ae385623afa86251a8278c9c5274f4c1), but it may have to be one of the three original changesets from jdk

In the code itself, three files are missing copyright header changes where they are newer than the current version: `referenceProcessor.hpp`, `referenceProcessor.cpp" and `referenceType.hpp`.  8143847 bumps all of these to 2016 and this change should do the same. The other files already have a newer copyright year than in 8143847.

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

Changes requested by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From andrew at openjdk.org  Fri Aug  5 17:13:18 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 5 Aug 2022 17:13:18 GMT
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
Message-ID: <Vh1dwCS7zFJSvSc0s3hxOyHL3U31ORicMwenhN4tGCc=.cebee23e-e3f5-43d5-ac29-5829c0076c66@github.com>

On Fri, 29 Jul 2022 00:18:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

I agree this matches the version in jdk8u-ri with appropriate adjustments for newer copyright headers in 8u-dev. Changes also match the appropriate subset of [JDK-8198249](https://bugs.openjdk.org/browse/JDK-8198249) as also verified by Mandy on the original PR.

I've added `jdk8u-fix-yes` approval so this can be integrated now.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From dholmes at openjdk.org  Fri Aug  5 21:08:20 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Aug 2022 21:08:20 GMT
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <Vh1dwCS7zFJSvSc0s3hxOyHL3U31ORicMwenhN4tGCc=.cebee23e-e3f5-43d5-ac29-5829c0076c66@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <Vh1dwCS7zFJSvSc0s3hxOyHL3U31ORicMwenhN4tGCc=.cebee23e-e3f5-43d5-ac29-5829c0076c66@github.com>
Message-ID: <GWPEUJU_zkp-Vd1vS6mjXjANsLrv04IJh1WuPnNWyds=.bd29eb86-3ed5-45ec-a94e-1ef3bd28ce67@github.com>

On Fri, 5 Aug 2022 17:09:21 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
>> 
>> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
>> 
>> The changes applied "unclean" only with regard to trivial things like copyright year updates.
>> 
>> Thanks.
>
> I agree this matches the version in jdk8u-ri with appropriate adjustments for newer copyright headers in 8u-dev. Changes also match the appropriate subset of [JDK-8198249](https://bugs.openjdk.org/browse/JDK-8198249) as also verified by Mandy on the original PR.
> 
> I've added `jdk8u-fix-yes` approval so this can be integrated now.

Thank you @gnu-andrew !

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

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From dholmes at openjdk.org  Fri Aug  5 21:08:22 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 5 Aug 2022 21:08:22 GMT
Subject: [jdk8u-dev] Integrated: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
Message-ID: <XSHpRWSFk880QwsmjS7HGzifwM_A7G8wYcudfC_3qO4=.4e242382-0528-47dd-9f0f-933a3df47026@github.com>

On Fri, 29 Jul 2022 00:18:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

This pull request has now been integrated.

Changeset: b52eb70f
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/b52eb70faf9f4e2646400c9565af67e6916c5ac9
Stats:     575 lines in 25 files changed: 98 ins; 365 del; 112 mod

8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE

Reviewed-by: hseigel, iris, andrew
Backport-of: 0d4cfc090c651786535529acfe5acb0209cb1d3d

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

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From poonam at openjdk.org  Fri Aug  5 21:55:25 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Fri, 5 Aug 2022 21:55:25 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
Message-ID: <aJL_3CfQzbk-JZoUNO8zzEuLAIXvlp1iS7S3KHMW_P4=.f8986b0d-2f91-46fd-9633-40192183ee2e@github.com>

> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
> 
>     8071507: (ref) Clear phantom reference as soft and weak references do
>     8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
> 
> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/94/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/94/files/f0ee3e01..3a37a2f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=94&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=94&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/94/head:pull/94

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From mchung at openjdk.org  Fri Aug  5 22:32:23 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 5 Aug 2022 22:32:23 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <DejSWRcbfIqUuHPA7xJTvVIEg9Y-w-WEyofr4lG4GSs=.a6e201b5-3611-4a51-8df3-6aa7ae6c4ca7@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
 <DejSWRcbfIqUuHPA7xJTvVIEg9Y-w-WEyofr4lG4GSs=.a6e201b5-3611-4a51-8df3-6aa7ae6c4ca7@github.com>
Message-ID: <E8CuaZyZ0hNZ7a6norL4LtpuZWbXrzvAWTy-4nXezjI=.8af61bb3-4db4-4d9c-bcaf-2ece7708343a@github.com>

On Fri, 5 Aug 2022 16:37:50 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Is there a reason for backporting two changes in one PR? I see this was done in 8u42 as well. It makes it harder to review than necessary, notably where the two change the same code in `referenceProcessor.cpp`.

It could be done in two separate PRs.  I agree it would be easier to review if they are two separate PRs.   8143847 mainly removed the cleaner related code.  As I was familiar with the code, I didn't ask to do two separate PRs.  Will bear that in mind in the future.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From poonam at openjdk.org  Fri Aug  5 23:41:22 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Fri, 5 Aug 2022 23:41:22 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <aJL_3CfQzbk-JZoUNO8zzEuLAIXvlp1iS7S3KHMW_P4=.f8986b0d-2f91-46fd-9633-40192183ee2e@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
 <aJL_3CfQzbk-JZoUNO8zzEuLAIXvlp1iS7S3KHMW_P4=.f8986b0d-2f91-46fd-9633-40192183ee2e@github.com>
Message-ID: <_vlwGnh9CNxgPYLLdxzllpo8PZKoxLHIYJ0MtCfA-tM=.7f77208f-c1bd-41b3-9c30-72a1e5b53168@github.com>

On Fri, 5 Aug 2022 21:55:25 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
>> 
>>     8071507: (ref) Clear phantom reference as soft and weak references do
>>     8143847: Remove REF_CLEANER reference category
>> 
>> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
>> 
>> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright years

> Also, SKARA does not appear to be picking this up as a backport, as the "Backport " style was not used (https://wiki.openjdk.org/display/SKARA/Backports). Ideally it would refer to the changeset in 8u42, [ad6cdea5ae385623afa86251a8278c9c5274f4c1](https://git.openjdk.java.net/jdk8u-ri/commit/ad6cdea5ae385623afa86251a8278c9c5274f4c1), but it may have to be one of the three original changesets from jdk
> 
> In the code itself, three files are missing copyright header changes where they are newer than the current version: `referenceProcessor.hpp`, `referenceProcessor.cpp" and `referenceType.hpp`. 8143847 bumps all of these to 2016 and this change should do the same. The other files already have a newer copyright year than in 8143847.

I have updated the copyright years and also fixed the SAKARA backport part.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From duke at openjdk.org  Mon Aug  8 08:52:16 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Mon, 8 Aug 2022 08:52:16 GMT
Subject: [jdk8u-dev] RFR: 8273176: handle latest VS2019 in
 abstract_vm_version
In-Reply-To: <uIJWs-lus-eBiXhSKL3_1O9PbEGCcHW3s-PHRdc9-Oo=.4b3dd440-827b-4b2b-bdfa-519c4a251689@github.com>
References: <uIJWs-lus-eBiXhSKL3_1O9PbEGCcHW3s-PHRdc9-Oo=.4b3dd440-827b-4b2b-bdfa-519c4a251689@github.com>
Message-ID: <f3OS3D9PM1SkYjpr78G3ERDfhWpqw0aXICGiEJ15Suc=.61cd6c78-6394-44de-9cc8-36dce26ac73c@github.com>

On Mon, 11 Jul 2022 07:08:41 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi! Here is another backport from MSVS 2019 seria. This one additionally extends the list of supported VC++ compilers. The patch from 11u is applied cleanly except the path shuffling:
> 
> src/hotspot/share/runtime/abstract_vm_version.cpp -> hotspot/src/share/vm/runtime/vm_version.cpp

ping

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

PR: https://git.openjdk.org/jdk8u-dev/pull/82

From lgxbslgx at gmail.com  Mon Aug  8 20:25:25 2022
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Tue, 9 Aug 2022 04:25:25 +0800
Subject: [Proposal] Maintainer Approvals and SKARA
In-Reply-To: <YkWmI4niEzgUmOm8@hex.discworld.ac.uk>
References: <Yjt/h0zy84qfCmX6@hex.discworld.ac.uk>
 <639d9498-c764-2005-30ef-87351d639d9d@oracle.com>
 <YkWmI4niEzgUmOm8@hex.discworld.ac.uk>
Message-ID: <CAPSsVqjZW-Ftp=zWpkBb_Rar3EQrta5i==urgYn5O37vwORW2g@mail.gmail.com>

Hi all,

I re-read your comments about this enhancement recently.
And I also made a mistake when I backport a patch to
jdk11u-dev [1] although I have backported several times.
So SKARA must direct the developers accurately and help
developers complete the duplicated work to avoid the unnecessary mistakes.

Now I propose the following dev flow. Please only focus on the dev
flow instead of the code implementation here.

*- When a backport PR is created in Github.*
1. A new checkbox item `[ ] Change must be properly approved by the
maintainers`
will be added to the `Progress` part of the current PR body.
2. A comment is posted by the bot like below (the italic content) to direct
the developers:

*This is a backport pull request. Please add a comment to the main issue
[JDK-XXXX](link)*
*to state the related condition (the backport reason, the risk of the
patch, the amount of*
*work and so on). Below is an example for you:*
*```*
*Fix Request(jdk17u-dev)*
*The code applies cleanly and the test in this change fails without the
patch and succeeds after applying it.*
*The risk of this backport is low because the change is little and the
issue fixed by this change also exists in jdk xy.*
*```*
*If you don't have permission to add a comment in JBS. Please use the
command `request-approval` to provide*
*the related content, then the bot can help you add a comment by using the
content you provided. Below is an example for you:*
*```*
*/request-approval*
*Fix Request(jdk17u-dev)*
*The code applies cleanly and the test in this change fails without the
patch and succeeds after applying it.*
*The risk of this backport is low because the change is little and the
issue fixed by this change also exists in jdk xy.*
*```*
*Please note you have to contact the maintainers **directly **in the
issue [JDK-XXXX](link)*
*or by using the command **`request-approval` **repeatedly** instead of in
this pull request.*
*And you don't need to add the fix request label manually to the issue like
before,*
*now the bot can help you add the label automatically when this pull
request is ready **for maintainers to approve.*

*- When the backport PR is ready for approval *(other checks have succeeded
and other progresses have been done)
1. The bot adds a label named `jdkXXu-fix-request` to *all the issues* of
the PR
2. The bot adds a blocked label named `approval` in PR, like `csr` or other
blocked labels
These two labels are convenient for maintainers to filter the issues and
PRs which need to be handled now.

*- It is time for maintainers to approve*
The maintainers can add the label `jdkXXu-fix-yes` or `jdkXXu-fix-no` in
the issue or use the command
`/approval yes|no|y|n` in the PR to approve or object the patch. This newly
added command `approval`
can be very convenient if one backport PR has many corresponding issues.
After using this command,
the bot will add the related label to *all the issues* just like the label
`jdkXXu-fix-request` it had added.

*- Then the commit or sponsor flow will continue as usual.*
After approval, if the maintainer said 'yes', the PR will become ready to
be integrated.
If the maintainer said 'no', the PR can be closed by the bot with a comment
like
"The maintainers disapproved of this patch so this pull request will be
closed automatically".
No matter 'yes' or 'no', the label `approval` in the PR will be removed.

Above is all the dev flow. And next, I will give more information about the
new commands `*request-approval` and `approval`.*

*- "request-approval" command*
It is similar to the `summary` command which permits multiline content. And
this command can be used
multi times if the author of the PR wants to. Each time this command is
used, the bot will post the content
to a new comment in the issue. Because the author who has no permission may
want to contact/talk with the maintainers.
The related record will be recorded in the issue instead of PR which is
your intention in your previous comments.

*- "approval" command*
The command `/approval yes` or `/approval y` mean `approved`.
And the command `/approval no` or `/approval n` mean `dispproved`.
This command can be used multiple times and only the last time is valid.
Please note when the `/approval no` or `/approval n` is used, the bot will
close the PR,
and when the `/approval yes` or `/approval y` later is used, the bot will
open the PR automatically.


That is all. Thanks for reading and providing feedback.
And I will try to implement these features if I have time and hear no
objection after discussion.

[1] https://github.com/openjdk/jdk11u-dev/pull/1218#issuecomment-1184235601

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220809/21135e88/attachment.htm>

From kbarrett at openjdk.org  Tue Aug  9 03:51:27 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 9 Aug 2022 03:51:27 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <E8CuaZyZ0hNZ7a6norL4LtpuZWbXrzvAWTy-4nXezjI=.8af61bb3-4db4-4d9c-bcaf-2ece7708343a@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
 <DejSWRcbfIqUuHPA7xJTvVIEg9Y-w-WEyofr4lG4GSs=.a6e201b5-3611-4a51-8df3-6aa7ae6c4ca7@github.com>
 <E8CuaZyZ0hNZ7a6norL4LtpuZWbXrzvAWTy-4nXezjI=.8af61bb3-4db4-4d9c-bcaf-2ece7708343a@github.com>
Message-ID: <3XCTDK-qkzNxHwy4BDJ2qkAWIIdEB8ao4Q0UIssDC8E=.95752ae1-13ce-41f0-8eeb-589e1f56f44b@github.com>

On Fri, 5 Aug 2022 22:28:47 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Is there a reason for backporting two changes in one PR? I see this was done in 8u42 as well. It makes it harder to review than necessary, notably where the two change the same code in `referenceProcessor.cpp`.

There was a change before 8071507 in mainline (and backported to jdk8u) that wasn?t in the RI. That change was rendered moot (the changed code was entirely removed) by 8143847. So if we?d separated 8071507 and 8143847 in the RI we would have needed to first apply that other change to the RI (8071507 without that earlier change would have been wrong), only to have it disappear with 8143847.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From sgehwolf at redhat.com  Tue Aug  9 08:43:28 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 09 Aug 2022 10:43:28 +0200
Subject: [Proposal] Maintainer Approvals and SKARA
In-Reply-To: <CAPSsVqjZW-Ftp=zWpkBb_Rar3EQrta5i==urgYn5O37vwORW2g@mail.gmail.com>
References: <Yjt/h0zy84qfCmX6@hex.discworld.ac.uk>
 <639d9498-c764-2005-30ef-87351d639d9d@oracle.com>
 <YkWmI4niEzgUmOm8@hex.discworld.ac.uk>
 <CAPSsVqjZW-Ftp=zWpkBb_Rar3EQrta5i==urgYn5O37vwORW2g@mail.gmail.com>
Message-ID: <158074e04fcf69679b242b4e6e1f79e377447662.camel@redhat.com>

Hi,

On Tue, 2022-08-09 at 04:25 +0800, Guoxiong Li wrote:
> Hi all,
> 
> I re-read your comments about this enhancement recently.
> And I also made a mistake when I backport a patch to
> jdk11u-dev [1] although I have backported several times.
> So SKARA must direct the developers accurately and help?
> developers complete the duplicated work to avoid the unnecessary
> mistakes.
> 
> Now I propose the following dev flow. Please only focus on the dev
> flow instead of the code implementation here.
> 
> - When a backport PR is created in Github.
> 1. A new checkbox item `[ ] Change must be properly approved by the
> maintainers`?
> will be added to the `Progress` part of the current PR body.
> 2. A comment is posted by the bot like below (the italic content) to
> direct the developers:
> This is a backport pull request. Please add a comment to the main
> issue [JDK-XXXX](link)
> to state the?related condition (the backport reason, the risk of the
> patch, the amount of
> work and so on). Below is an example for you:
> ```
> Fix Request(jdk17u-dev)
> The code applies cleanly and the test in this change fails without
> the patch and succeeds after applying it.
> The risk of this backport is low because the change is little and the
> issue fixed by this change also exists in jdk xy.
> ```
> If you don't have permission to add a comment in JBS. Please use the
> command `request-approval` to provide
> the related content, then?the bot can help you add a comment by using
> the content you provided.?Below is an example for you:
> ```
> /request-approval
> Fix Request(jdk17u-dev)
> The code applies cleanly and the test in this change fails without
> the patch and succeeds after applying it.
> The risk of this backport is low because the change is little and the
> issue fixed by this change also exists in jdk xy.
> ```
> Please note you have to contact the maintainers?directly?in the
> issue?[JDK-XXXX](link)?
> or by using the command?`request-approval`?repeatedly?instead of in
> this pull request.
> And you don't need to add the fix request label manually to the issue
> like before,
> now the bot can help you add the label automatically when this pull
> request is ready?for maintainers to approve.
> 
> - When the backport PR is ready for approval (other checks have
> succeeded and other progresses have been done)
> 1. The bot adds a label named `jdkXXu-fix-request` to all the issues
> of the PR
> 2. The bot adds a blocked label named `approval` in PR, like `csr` or
> other blocked labels
> These two labels are convenient for maintainers to filter the issues
> and PRs which need to be handled now.
> 
> - It is time for maintainers to approve
> The maintainers can add the label `jdkXXu-fix-yes` or `jdkXXu-fix-no`
> in the issue or use the command?
> `/approval yes|no|y|n` in the PR to approve or object the patch. This
> newly added command `approval`?
> can be very convenient if one backport PR has many corresponding
> issues. After using this command,
> the bot will add the related label to all the issues just like the
> label `jdkXXu-fix-request`?it had added.
> 
> - Then the commit or sponsor flow will continue as usual.
> After approval, if the maintainer said 'yes', the PR will become
> ready to be integrated.
> If the maintainer said 'no', the PR can be closed?by the bot with a
> comment like
> "The maintainers disapproved of this patch so this pull request will
> be closed automatically".
> No matter 'yes' or 'no', the label `approval` in the PR will be
> removed.
> 
> Above is all the dev flow. And next, I will give more information
> about the new commands `request-approval` and `approval`.
> 
> - "request-approval" command
> It is similar to the `summary` command which permits multiline
> content. And this command can be used?
> multi times if the author of the PR wants to. Each time this command
> is used, the bot will post the content?
> to a new comment in the issue. Because the author who has no
> permission may want to contact/talk with the maintainers.
> The related record will be recorded in the issue instead of PR which
> is your intention in your previous comments.
> 
> - "approval" command
> The command `/approval yes` or `/approval y` mean `approved`.
> And the command `/approval no` or `/approval n` mean `dispproved`.
> This command can be used multiple times and only the last time is
> valid.
> Please note when the `/approval no` or `/approval n` is used, the bot
> will close the PR,
> and when the `/approval yes` or `/approval y` later is used, the bot
> will open the PR automatically.
> 
> 
> That is all. Thanks for reading and providing feedback.?
> And I will try to implement these features if I have time and hear no
> objection?after discussion.
> 

This sounds good to me. +1. Perhaps we should move this discussion and
implementation proposal to the bug tracking this issue as it is hard to
find those mailing list posts later on?
https://bugs.openjdk.org/browse/SKARA-1199

It also seems to be in-line with what Andrew Hughes suggested in [i].

Thanks,
Severin

[i] https://mail.openjdk.org/pipermail/jdk-updates-dev/2022-March/013278.html

> [1]?
> https://github.com/openjdk/jdk11u-dev/pull/1218#issuecomment-11842356
> 01
> 
> Best Regards,
> -- Guoxiong


From abakhtin at openjdk.org  Tue Aug  9 19:37:12 2022
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 9 Aug 2022 19:37:12 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u for
 Client roles
Message-ID: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>

Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
I'd like to add this functionality for parity with Oracle JavaSE8

The patch rolls back the JDK-8245476 and updates JTREG tests

All sun/security/ssl and javax/net/ssl jtreg tests are passed

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

Commit messages:
 - JDK-8245263: Enable TLSv1.3 by default on JDK 8u for Client roles

Changes: https://git.openjdk.org/jdk8u-dev/pull/96/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=96&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8245263
  Stats: 11 lines in 3 files changed: 2 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/96.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/96/head:pull/96

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From sgehwolf at openjdk.org  Wed Aug 10 08:39:50 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 10 Aug 2022 08:39:50 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
Message-ID: <nTKOOECWdHwxU8YY0kI4MCiN7T703vJWviCkNIQjZKQ=.7c6ea0b9-8cce-49cb-9ad0-3d99cc94edca@github.com>

On Tue, 9 Aug 2022 19:30:22 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
> I'd like to add this functionality for parity with Oracle JavaSE8
> 
> The patch rolls back the JDK-8245476 and updates JTREG tests
> 
> All sun/security/ssl and javax/net/ssl jtreg tests are passed

@martinuy @franferrax Could you please review this?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From andrew at openjdk.org  Thu Aug 11 03:04:38 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 11 Aug 2022 03:04:38 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <aJL_3CfQzbk-JZoUNO8zzEuLAIXvlp1iS7S3KHMW_P4=.f8986b0d-2f91-46fd-9633-40192183ee2e@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
 <aJL_3CfQzbk-JZoUNO8zzEuLAIXvlp1iS7S3KHMW_P4=.f8986b0d-2f91-46fd-9633-40192183ee2e@github.com>
Message-ID: <7LGJOcSwHOY395T53AlLrDGUtsP5H8mSyrbLNxQDOv8=.2c4555f9-c374-46cd-b46e-505b45514a9f@github.com>

On Fri, 5 Aug 2022 21:55:25 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
>> 
>>     8071507: (ref) Clear phantom reference as soft and weak references do
>>     8143847: Remove REF_CLEANER reference category
>> 
>> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
>> 
>> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright years

Marked as reviewed by andrew (Reviewer).

I've set `jdk8u-fix-yes` on the bug so this can be integrated now. Thanks again for the contribution.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From andrew at openjdk.org  Thu Aug 11 03:04:39 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 11 Aug 2022 03:04:39 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <_vlwGnh9CNxgPYLLdxzllpo8PZKoxLHIYJ0MtCfA-tM=.7f77208f-c1bd-41b3-9c30-72a1e5b53168@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
 <aJL_3CfQzbk-JZoUNO8zzEuLAIXvlp1iS7S3KHMW_P4=.f8986b0d-2f91-46fd-9633-40192183ee2e@github.com>
 <_vlwGnh9CNxgPYLLdxzllpo8PZKoxLHIYJ0MtCfA-tM=.7f77208f-c1bd-41b3-9c30-72a1e5b53168@github.com>
Message-ID: <9x6G0soywWf6RQStnM1GJkq9fd9p9JHN7_3B8-4HLX8=.4b92527d-7781-4e09-9b61-cfd5a450bfcc@github.com>

On Fri, 5 Aug 2022 23:38:25 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> > Also, SKARA does not appear to be picking this up as a backport, as the "Backport " style was not used (https://wiki.openjdk.org/display/SKARA/Backports). Ideally it would refer to the changeset in 8u42, [ad6cdea5ae385623afa86251a8278c9c5274f4c1](https://git.openjdk.java.net/jdk8u-ri/commit/ad6cdea5ae385623afa86251a8278c9c5274f4c1), but it may have to be one of the three original changesets from jdk
> > In the code itself, three files are missing copyright header changes where they are newer than the current version: `referenceProcessor.hpp`, `referenceProcessor.cpp" and `referenceType.hpp`. 8143847 bumps all of these to 2016 and this change should do the same. The other files already have a newer copyright year than in 8143847.
> 
> I have updated the copyright years and also fixed the SAKARA backport part.

Thanks. Patch looks good and seems SKARA is happier now :-)

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From andrew at openjdk.org  Thu Aug 11 03:04:40 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 11 Aug 2022 03:04:40 GMT
Subject: [jdk8u-dev] RFR: 8071507: (ref) Clear phantom reference as soft
 and weak references do [v2]
In-Reply-To: <3XCTDK-qkzNxHwy4BDJ2qkAWIIdEB8ao4Q0UIssDC8E=.95752ae1-13ce-41f0-8eeb-589e1f56f44b@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
 <DejSWRcbfIqUuHPA7xJTvVIEg9Y-w-WEyofr4lG4GSs=.a6e201b5-3611-4a51-8df3-6aa7ae6c4ca7@github.com>
 <E8CuaZyZ0hNZ7a6norL4LtpuZWbXrzvAWTy-4nXezjI=.8af61bb3-4db4-4d9c-bcaf-2ece7708343a@github.com>
 <3XCTDK-qkzNxHwy4BDJ2qkAWIIdEB8ao4Q0UIssDC8E=.95752ae1-13ce-41f0-8eeb-589e1f56f44b@github.com>
Message-ID: <Zm8vMjru3sp7HOnI3MsJ5hc7Qr8nEk_N2cKL75lEdVw=.1f134ba7-81e6-4851-b250-3de23db17a7f@github.com>

On Tue, 9 Aug 2022 03:47:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Is there a reason for backporting two changes in one PR? I see this was done in 8u42 as well. It makes it harder to review than necessary, notably where the two change the same code in `referenceProcessor.cpp`.
> 
> There was a change before 8071507 in mainline (and backported to jdk8u) that wasn?t in the RI. That change was rendered moot (the changed code was entirely removed) by 8143847. So if we?d separated 8071507 and 8143847 in the RI we would have needed to first apply that other change to the RI (8071507 without that earlier change would have been wrong), only to have it disappear with 8143847.

Thanks. Having reviewed the code, that makes sense.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From poonam at openjdk.org  Thu Aug 11 14:00:20 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Thu, 11 Aug 2022 14:00:20 GMT
Subject: [jdk8u-dev] Integrated: 8071507: (ref) Clear phantom reference as soft
 and weak references do
In-Reply-To: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
References: <l5zChzso7yelbY6nmKSc7d7OCYOQ2EVfbtHcdTBau0M=.82a251f7-bbb1-448d-b1c0-0c81d0c25609@github.com>
Message-ID: <Zw8QH9yuXDB68rWmREpfU6sJY1S5G_WeTxAO6KUaKOs=.8265df02-4816-4f3f-8ef9-bdb40b749a6f@github.com>

On Mon, 1 Aug 2022 16:30:17 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Backport of 8071507 and 8143847 from jdk8u-ri to jdk8u-dev.
> 
>     8071507: (ref) Clear phantom reference as soft and weak references do
>     8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector like soft and weak references.
> 
> The changes are clean backport apart from a little manual adjustment for the hunk at line 246 in referenceProcessor.cpp.

This pull request has now been integrated.

Changeset: 0869fc01
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/0869fc0153bde09c41ad37c3c46f715e23b41966
Stats:     173 lines in 10 files changed: 105 ins; 48 del; 20 mod

8071507: (ref) Clear phantom reference as soft and weak references do
8143847: Remove REF_CLEANER reference category

Reviewed-by: iris, dholmes, mchung, andrew
Backport-of: ad6cdea5ae385623afa86251a8278c9c5274f4c1

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

PR: https://git.openjdk.org/jdk8u-dev/pull/94

From duke at openjdk.org  Thu Aug 11 19:27:37 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 11 Aug 2022 19:27:37 GMT
Subject: [jdk8u-dev] RFR: 8183107: PKCS11 regression regarding checkKeySize
Message-ID: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>

This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly except for copyright line P11Signature.java file, which already has newer year then what is in changest (so this change is excluded).

git apply -p3 --directory=jdk/src --reject 0001-8183107-PKCS11-regression-regarding-checkKeySize.patch
Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java...
Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java...
Checking patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java...
error: while searching for:
/*
 * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it

error: patch failed: jdk/src/share/classes/sun/security/pkcs11/P11Signature.java:1
Hunk #2 succeeded at 370 (offset -24 lines).
Hunk #3 succeeded at 396 (offset -24 lines).
Checking patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java...
Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java cleanly.
Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java cleanly.
Applying patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java with 1 reject...
Rejected hunk #1.
Hunk #2 applied cleanly.
Hunk #3 applied cleanly.
Applied patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java cleanly.


Tested locally, no regressions seen in jdk_security tests.
This backport is done with intention of later also backporting JDK-8232950 [2], which depends on this one.

[1] https://bugs.openjdk.org/browse/JDK-8183107
[2] https://bugs.openjdk.org/browse/JDK-8232950

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

Commit messages:
 - Backport 67ca52873f088a08705baeef3e66319de1600576

Changes: https://git.openjdk.org/jdk8u-dev/pull/98/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=98&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8183107
  Stats: 79 lines in 4 files changed: 46 ins; 9 del; 24 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/98.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/98/head:pull/98

PR: https://git.openjdk.org/jdk8u-dev/pull/98

From poonam at openjdk.org  Thu Aug 11 19:50:34 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Thu, 11 Aug 2022 19:50:34 GMT
Subject: [jdk8u-dev] RFR: 8175797: (ref) Reference::enqueue method should clear
 the reference object before enqueuing
Message-ID: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>

These changes backport JDK-8175797 and two very closely related fixes (8178832 and 8193780) to jdk8u-dev:

    8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
    8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
    8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property

With these changes, the enqueue method clears the reference before enqueuing it to the registered queue.

It is a clean port from jdk8u-ri.

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

Commit messages:
 - 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing

Changes: https://git.openjdk.org/jdk8u-dev/pull/99/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=99&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8175797
  Stats: 61 lines in 3 files changed: 52 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/99.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/99/head:pull/99

PR: https://git.openjdk.org/jdk8u-dev/pull/99

From darcy at openjdk.org  Thu Aug 11 20:40:11 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 11 Aug 2022 20:40:11 GMT
Subject: [jdk8u-dev] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
Message-ID: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>

Same diff as used in the JDK 8u RI update.

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

Commit messages:
 - JDK-8285497: Add system property for Java SE specification maintenance version

Changes: https://git.openjdk.org/jdk8u-dev/pull/100/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285497
  Stats: 22 lines in 4 files changed: 20 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/100.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/100/head:pull/100

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From mchung at openjdk.org  Fri Aug 12 02:05:15 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 12 Aug 2022 02:05:15 GMT
Subject: [jdk8u-dev] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
References: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
Message-ID: <kuY1zSUw-W1MkeHP1UhAmqrAVqDFynIbH0c7zyYv_yE=.eee4da5f-e62a-432c-8435-168d468adad2@github.com>

On Thu, 11 Aug 2022 19:12:23 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport JDK-8175797 and two very closely related fixes (8178832 and 8193780) to jdk8u-dev:
> 
>     8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
>     8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
>     8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With these changes, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> It is a clean port from jdk8u-ri.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.org/jdk8u-dev/pull/99

From dholmes at openjdk.org  Fri Aug 12 04:16:33 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Aug 2022 04:16:33 GMT
Subject: [jdk8u-dev] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
References: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
Message-ID: <QMhqLVv8wz9A5asDlc7iJayPtuMCEoWHcsOoumnJD04=.a1e9c54b-520f-47ef-a458-ba9261d6557b@github.com>

On Thu, 11 Aug 2022 19:12:23 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport JDK-8175797 and two very closely related fixes (8178832 and 8193780) to jdk8u-dev:
> 
>     8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
>     8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
>     8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With these changes, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> It is a clean port from jdk8u-ri.

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/99

From dholmes at openjdk.org  Fri Aug 12 04:18:24 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Aug 2022 04:18:24 GMT
Subject: [jdk8u-dev] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
Message-ID: <snWESiXBdgl03bY2VPdAU_DzeEIAKQIk9CNG6dosH78=.66d749b1-abf1-4715-afc2-7761f7c83fca@github.com>

On Thu, 11 Aug 2022 20:35:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Same diff as used in the JDK 8u RI update.

Looks good. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From dingli at iscas.ac.cn  Fri Aug 12 09:59:41 2022
From: dingli at iscas.ac.cn (Dingli Zhang)
Date: Fri, 12 Aug 2022 17:59:41 +0800
Subject: Build failed with core variant in x86 
Message-ID: <D2E1C7AD-1B92-4F43-BE97-477912BBFF77@iscas.ac.cn>

Hi, I found a small problem when I built openjdk8u x86 with core variant.

Repo: https://github.com/openjdk/jdk8u.git
commit id: a18e9043fa2a0a14098e1ec25d32577aaac6c023 (tag: jdk8u342-b06)

Build commands:
```
$ bash configure \
--with-boot-jdk=/home/dingli/java-se-8u42-ri \
--with-jvm-variants=core \
--with-debug-level=release \
--with-native-debug-symbols=none \
--with-extra-cflags="-Wno-error? 
$ make JOBS=$(proc)
```

The configure command executes correctly, but the make command gives the following error:
```
## Starting hotspot
make[2]: warning: -j1 forced in submake: resetting jobserver mode.
INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
No (productcore) for x86
INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
warning: [options] bootstrap class path not set in conjunction with -source 1.7
1 warning
Generating linux_amd64_docs/jvmti.html
INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
make[3]: *** No rule to make target '/home/dingli/jdk8u/build/linux-x86_64-normal-core-release/hotspot/dist/jre/lib/amd64/libjsig.so', needed by 'generic_export'.  Stop.
make[2]: *** [Makefile:296: export_product] Error 2
make[1]: *** [HotspotWrapper.gmk:45: /home/dingli/jdk8u/build/linux-x86_64-normal-core-release/hotspot/_hotspot.timestamp] Error 2
make: *** [/home/dingli/jdk8u//make/Main.gmk:110: hotspot-only] Error 2
```

I think the problem is in `/home/dingli/jdk8u/hotspot/make/Makefile:245-257`:
```
generic_buildcore: $(HOTSPOT_SCRIPT)
ifeq ($(HS_ARCH),ppc)
  ifeq ($(ARCH_DATA_MODEL),64)
    $(MKDIR) -p $(OUTPUTDIR)
    $(CD) $(OUTPUTDIR); \
        $(MAKE) -f $(ABS_OS_MAKEFILE) \
            $(MAKE_ARGS) $(VM_TARGET)
  else
    @$(ECHO) "No ($(VM_TARGET)) for ppc ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)"
  endif
else
    @$(ECHO) "No ($(VM_TARGET)) for $(HS_ARCH)"
endif
```

The rule `generic_buildcore ` only allow ppc64 to build core variant.
I added a new conditional judgment: https://github.com/DingliZhang/jdk8u/commit/e2f9ebeba6e779fc2a06fae723d7318977097977
```
diff --git a/hotspot/make/Makefile b/hotspot/make/Makefile
index ad195763be..168f17524d 100644
--- a/hotspot/make/Makefile
+++ b/hotspot/make/Makefile
@@ -252,6 +252,11 @@ ifeq ($(HS_ARCH),ppc)
   else
        @$(ECHO) "No ($(VM_TARGET)) for ppc ARCH_DATA_MODEL=$(ARCH_DATA_MODEL)"
   endif
+else ifeq ($(HS_ARCH),x86)
+       $(MKDIR) -p $(OUTPUTDIR)
+       $(CD) $(OUTPUTDIR); \
+               $(MAKE) -f $(ABS_OS_MAKEFILE) \
+                       $(MAKE_ARGS) $(VM_TARGET)
 else
        @$(ECHO) "No ($(VM_TARGET)) for $(HS_ARCH)"
 endif
```

It works:
```
$ build/linux-x86_64-normal-core-release/jdk/bin/java -version
openjdk version "1.8.0_342-internal"
OpenJDK Runtime Environment (build 1.8.0_342-internal-dingli_2022_08_12_17_41-b00)
OpenJDK 64-Bit  VM (build 25.342-b00, interpreted mode)
```

By the way, I also tried it on aarch64 and it produces the same errors as x86 before submitting a similar patch, but there are also new errors after fixing the generic_buildcore rule (new errors can be fixed like https://gitee.com/openeuler/bishengjdk-11/commit/085a5bc8cf66d1606e40d51bb6580ed24d99eccc ), and the latest ones are currently as follows:
```
/home/parallels/jdk8u/hotspot/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp: In member function ?void StubGenerator::generate_all()?:
/home/parallels/jdk8u/hotspot/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp:4381:9: error: ?UseMultiplyToLenIntrinsic? was not declared in this scope
 4381 |     if (UseMultiplyToLenIntrinsic) {
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~
/home/parallels/jdk8u/hotspot/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp:4385:9: error: ?UseMontgomeryMultiplyIntrinsic? was not declared in this scope
 4385 |     if (UseMontgomeryMultiplyIntrinsic) {
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiling /home/parallels/jdk8u/hotspot/src/share/vm/code/stubs.cpp
Compiling /home/parallels/jdk8u/hotspot/src/share/vm/gc_implementation/g1/survRateGroup.cpp
/home/parallels/jdk8u/hotspot/src/cpu/aarch64/vm/stubGenerator_aarch64.cpp:4391:9: error: ?UseMontgomerySquareIntrinsic? was not declared in this scope
 4391 |     if (UseMontgomerySquareIntrinsic) {
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compiling /home/parallels/jdk8u/hotspot/src/share/vm/gc_implementation/shared/suspendibleThreadSet.cpp
make[6]: *** [/home/parallels/jdk8u/hotspot/make/linux/makefiles/rules.make:151: stubGenerator_aarch64.o] Error 1
make[6]: *** Waiting for unfinished jobs....
make[5]: *** [/home/parallels/jdk8u/hotspot/make/linux/makefiles/top.make:120: the_vm] Error 2
make[4]: *** [/home/parallels/jdk8u/hotspot/make/linux/Makefile:302: productcore] Error 2
make[3]: *** [Makefile:249: generic_buildcore] Error 2
make[2]: *** [Makefile:181: productcore] Error 2
make[1]: *** [HotspotWrapper.gmk:45: /home/parallels/jdk8u/build/linux-aarch64-normal-core-release/hotspot/_hotspot.timestamp] Error 2
make: *** [/home/parallels/jdk8u//make/Main.gmk:110: hotspot-only] Error 2
```

I think we can fix the problem in x86 first.

Best regards,
Dingli

From iris at openjdk.org  Fri Aug 12 17:41:32 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 12 Aug 2022 17:41:32 GMT
Subject: [jdk8u-dev] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
Message-ID: <RfJfFJPvp5-8V7rWptp5qfAXTIEJevA-BNH50VB8Asg=.eb5e5d8b-8f04-4314-a99b-25d84544d71f@github.com>

On Thu, 11 Aug 2022 20:35:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Same diff as used in the JDK 8u RI update.

Spec changes match those in JSR 337 MR 4.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From iris at openjdk.org  Fri Aug 12 21:13:32 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 12 Aug 2022 21:13:32 GMT
Subject: [jdk8u-dev] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
References: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
Message-ID: <pnFLD8QtgvzTgpMjdSdBKgtG4fFVsGB1CJNozcQOfrU=.854b2eff-3c4d-4db2-a3f8-2ace77cd76c0@github.com>

On Thu, 11 Aug 2022 19:12:23 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport JDK-8175797 and two very closely related fixes (8178832 and 8193780) to jdk8u-dev:
> 
>     8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
>     8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
>     8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With these changes, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> It is a clean port from jdk8u-ri.

Spec changes match those in JSR 337 MR 4.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u-dev/pull/99

From mchung at openjdk.org  Fri Aug 12 23:27:50 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 12 Aug 2022 23:27:50 GMT
Subject: [jdk8u-dev] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
Message-ID: <gkXhnkJ3LIhqbt5dhecVRZuUifUdwSW3HRbeworwzP0=.342bf516-e0ef-415f-8ad8-233031e41847@github.com>

On Thu, 11 Aug 2022 20:35:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Same diff as used in the JDK 8u RI update.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From christoph.langer at sap.com  Mon Aug 15 06:01:55 2022
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 15 Aug 2022 06:01:55 +0000
Subject: [Proposal] Maintainer Approvals and SKARA
In-Reply-To: <158074e04fcf69679b242b4e6e1f79e377447662.camel@redhat.com>
References: <Yjt/h0zy84qfCmX6@hex.discworld.ac.uk>
 <639d9498-c764-2005-30ef-87351d639d9d@oracle.com>
 <YkWmI4niEzgUmOm8@hex.discworld.ac.uk>
 <CAPSsVqjZW-Ftp=zWpkBb_Rar3EQrta5i==urgYn5O37vwORW2g@mail.gmail.com>
 <158074e04fcf69679b242b4e6e1f79e377447662.camel@redhat.com>
Message-ID: <DB6PR0202MB26946ADC50A34AB7EE0267F38A689@DB6PR0202MB2694.eurprd02.prod.outlook.com>

Hi Guoxiong,

+1 from me as well. Would be absolutely great if this part of the backport process could be improved soon. ?

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.org> On Behalf Of
> Severin Gehwolf
> Sent: Dienstag, 9. August 2022 10:43
> To: Guoxiong Li <lgxbslgx at gmail.com>; jdk8u-dev at openjdk.org; jdk-updates-
> dev at openjdk.org; skara-dev at openjdk.org
> Subject: Re: [Proposal] Maintainer Approvals and SKARA
> 
> Hi,
> 
> On Tue, 2022-08-09 at 04:25 +0800, Guoxiong Li wrote:
> > Hi all,
> >
> > I re-read your comments about this enhancement recently.
> > And I also made a mistake when I backport a patch to jdk11u-dev [1]
> > although I have backported several times.
> > So SKARA must direct the developers accurately and help developers
> > complete the duplicated work to avoid the unnecessary mistakes.
> >
> > Now I propose the following dev flow. Please only focus on the dev
> > flow instead of the code implementation here.
> >
> > - When a backport PR is created in Github.
> > 1. A new checkbox item `[ ] Change must be properly approved by the
> > maintainers` will be added to the `Progress` part of the current PR
> > body.
> > 2. A comment is posted by the bot like below (the italic content) to
> > direct the developers:
> > This is a backport pull request. Please add a comment to the main
> > issue [JDK-XXXX](link) to state the?related condition (the backport
> > reason, the risk of the patch, the amount of work and so on). Below is
> > an example for you:
> > ```
> > Fix Request(jdk17u-dev)
> > The code applies cleanly and the test in this change fails without the
> > patch and succeeds after applying it.
> > The risk of this backport is low because the change is little and the
> > issue fixed by this change also exists in jdk xy.
> > ```
> > If you don't have permission to add a comment in JBS. Please use the
> > command `request-approval` to provide the related content, then?the
> > bot can help you add a comment by using the content you provided.
> > Below is an example for you:
> > ```
> > /request-approval
> > Fix Request(jdk17u-dev)
> > The code applies cleanly and the test in this change fails without the
> > patch and succeeds after applying it.
> > The risk of this backport is low because the change is little and the
> > issue fixed by this change also exists in jdk xy.
> > ```
> > Please note you have to contact the maintainers?directly?in the issue
> > [JDK-XXXX](link) or by using the command?`request-approval`?repeatedly
> > instead of in this pull request.
> > And you don't need to add the fix request label manually to the issue
> > like before, now the bot can help you add the label automatically when
> > this pull request is ready?for maintainers to approve.
> >
> > - When the backport PR is ready for approval (other checks have
> > succeeded and other progresses have been done) 1. The bot adds a label
> > named `jdkXXu-fix-request` to all the issues of the PR 2. The bot adds
> > a blocked label named `approval` in PR, like `csr` or other blocked
> > labels These two labels are convenient for maintainers to filter the
> > issues and PRs which need to be handled now.
> >
> > - It is time for maintainers to approve The maintainers can add the
> > label `jdkXXu-fix-yes` or `jdkXXu-fix-no` in the issue or use the
> > command `/approval yes|no|y|n` in the PR to approve or object the
> > patch. This newly added command `approval` can be very convenient if
> > one backport PR has many corresponding issues. After using this
> > command, the bot will add the related label to all the issues just
> > like the label `jdkXXu-fix-request`?it had added.
> >
> > - Then the commit or sponsor flow will continue as usual.
> > After approval, if the maintainer said 'yes', the PR will become ready
> > to be integrated.
> > If the maintainer said 'no', the PR can be closed?by the bot with a
> > comment like "The maintainers disapproved of this patch so this pull
> > request will be closed automatically".
> > No matter 'yes' or 'no', the label `approval` in the PR will be
> > removed.
> >
> > Above is all the dev flow. And next, I will give more information
> > about the new commands `request-approval` and `approval`.
> >
> > - "request-approval" command
> > It is similar to the `summary` command which permits multiline
> > content. And this command can be used multi times if the author of the
> > PR wants to. Each time this command is used, the bot will post the
> > content to a new comment in the issue. Because the author who has no
> > permission may want to contact/talk with the maintainers.
> > The related record will be recorded in the issue instead of PR which
> > is your intention in your previous comments.
> >
> > - "approval" command
> > The command `/approval yes` or `/approval y` mean `approved`.
> > And the command `/approval no` or `/approval n` mean `dispproved`.
> > This command can be used multiple times and only the last time is
> > valid.
> > Please note when the `/approval no` or `/approval n` is used, the bot
> > will close the PR, and when the `/approval yes` or `/approval y` later
> > is used, the bot will open the PR automatically.
> >
> >
> > That is all. Thanks for reading and providing feedback. And I will try
> > to implement these features if I have time and hear no objection?after
> > discussion.
> >
> 
> This sounds good to me. +1. Perhaps we should move this discussion and
> implementation proposal to the bug tracking this issue as it is hard to find
> those mailing list posts later on?
> https://bugs.openjdk.org/browse/SKARA-1199
> 
> It also seems to be in-line with what Andrew Hughes suggested in [i].
> 
> Thanks,
> Severin
> 
> [i] https://mail.openjdk.org/pipermail/jdk-updates-dev/2022-
> March/013278.html
> 
> > [1]
> > https://github.com/openjdk/jdk11u-dev/pull/1218#issuecomment-11842356
> > 01
> >
> > Best Regards,
> > -- Guoxiong


From andrew at openjdk.org  Mon Aug 15 08:25:34 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 08:25:34 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v3]
In-Reply-To: <_Vq8b_znRuWWvaPywbYsmmXzhXtHHqoRmrnfODm-AJY=.0974576b-a169-4ed4-a483-9c56e3f1ef77@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <_Vq8b_znRuWWvaPywbYsmmXzhXtHHqoRmrnfODm-AJY=.0974576b-a169-4ed4-a483-9c56e3f1ef77@github.com>
Message-ID: <R1Ac-SQFFtoqlsNryXvaqzkpuZR8QaEEFdgNhvAqnGU=.e6ff1028-56c2-457a-bcfd-cea8e5b00384@github.com>

On Thu, 21 Jul 2022 06:46:08 GMT, Poison <duke at openjdk.org> wrote:

>> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
>> 
>> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.
>
> Poison has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d
>    
>    format code
>  - Merge branch 'openjdk:master' into backport-8214427
>  - Merge branch 'openjdk:master' into backport-8214427
>  - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d

Diff looks right now, thanks.
~~~
@@ -24,16 +15,16 @@
 +                    if (sc == rs + MAX_RESIZERS || sc == rs + 1 ||
 +                        (nt = nextTable) == null || transferIndex <= 0)
                          break;
-                     if (U.compareAndSetInt(this, SIZECTL, sc, sc + 1))
+                     if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1))
                          transfer(tab, nt);
                  }
--                else if (U.compareAndSetInt(this, SIZECTL, sc,
+-                else if (U.compareAndSwapInt(this, SIZECTL, sc,
 -                                             (rs << RESIZE_STAMP_SHIFT) + 2))
-+                else if (U.compareAndSetInt(this, SIZECTL, sc, rs + 2))
++                else if (U.compareAndSwapInt(this, SIZECTL, sc, rs + 2))
                      transfer(tab, null);
                  s = sumCount();
              }
-@@ -2358,11 +2356,11 @@ public class ConcurrentHashMap<K,V> extends AbstractMap<K,V>
+@@ -2298,11 +2296,11 @@ final Node<K,V>[] helpTransfer(Node<K,V>[] tab, Node<K,V> f) {
          Node<K,V>[] nextTab; int sc;
          if (tab != null && (f instanceof ForwardingNode) &&
              (nextTab = ((ForwardingNode<K,V>)f).nextTable) != null) {
@@ -46,5 +37,5 @@
 +                if (sc == rs + MAX_RESIZERS || sc == rs + 1 ||
 +                    transferIndex <= 0)
                      break;
-                 if (U.compareAndSetInt(this, SIZECTL, sc, sc + 1)) {
+                 if (U.compareAndSwapInt(this, SIZECTL, sc, sc + 1)) {
                      transfer(tab, nextTab);
~~~

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From andrew at openjdk.org  Mon Aug 15 08:29:27 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 08:29:27 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v3]
In-Reply-To: <_Vq8b_znRuWWvaPywbYsmmXzhXtHHqoRmrnfODm-AJY=.0974576b-a169-4ed4-a483-9c56e3f1ef77@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <_Vq8b_znRuWWvaPywbYsmmXzhXtHHqoRmrnfODm-AJY=.0974576b-a169-4ed4-a483-9c56e3f1ef77@github.com>
Message-ID: <3WrQa5MQ-3G1OQpOrrPs2gVItXS8HxE0T95OrNrXdUk=.d53f21cc-b949-490c-82e7-6d3a9407750b@github.com>

On Thu, 21 Jul 2022 06:46:08 GMT, Poison <duke at openjdk.org> wrote:

>> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
>> 
>> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.
>
> Poison has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d
>    
>    format code
>  - Merge branch 'openjdk:master' into backport-8214427
>  - Merge branch 'openjdk:master' into backport-8214427
>  - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d

I've added `jdk8u-fix-yes` to the bug so ready for integration.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From andrew at openjdk.org  Mon Aug 15 08:47:29 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 08:47:29 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
Message-ID: <zq1xf-XAbLavghhISBs6QpBuD4rSD-n05YxkPwH4Mas=.4d910d49-a03b-4148-a62f-6609084e6b4e@github.com>

On Tue, 21 Jun 2022 02:27:18 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8049228: Improve multithreaded scalability of InetAddress cache
>   
>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

Looks like a clean backport, bar the copyright header that has already been updated by later security changes.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From andrew at openjdk.org  Mon Aug 15 09:03:24 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 09:03:24 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
Message-ID: <61SFGh2sPWF6owYqUbvRYVPeO7Bier2jrzuni8PYcmY=.7be4275b-1a1a-4900-a8b3-504c5959c4f7@github.com>

On Tue, 21 Jun 2022 02:27:18 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8049228: Improve multithreaded scalability of InetAddress cache
>   
>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

I've approved this one, but as I commented on the bug, it would be nice to know the reasoning for this backport. Approvals are primarily about risk assessment in the context of the whole JDK.

In this case, it's been in later JDKs for years, and is realistically borderline between being an enhancement and a bug fix (see https://bugs.openjdk.org/browse/JDK-8171346). I think it would be preferable to deal with any issues in the new code rather than the current outdated code, which is doing its own locking that is prone to error.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From andrew at openjdk.org  Mon Aug 15 09:06:40 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 09:06:40 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
Message-ID: <bmHbW9_GRO4iqB9OyvcSrtwB5kFeDbFZ7bwO1Ix2ISk=.33163374-59bb-4186-a63d-116389e168ef@github.com>

On Tue, 21 Jun 2022 07:52:23 GMT, George Adams <duke at openjdk.org> wrote:

> Backports https://bugs.openjdk.org/browse/JDK-8251551 as it's a low-risk change and generally improves the readability/usability in GitHub.
> 
> Currently, I've just converted the README to markdown format and added a little syntax highlighting. I'm not sure if people would like me to go one step further and rip out the mercurial/nested repo references?

Still waiting on a review of my patch, sorry. It'd be good if someone could review it so we can start to move this forward.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/75

From tsteele at openjdk.org  Mon Aug 15 16:34:16 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Mon, 15 Aug 2022 16:34:16 GMT
Subject: [jdk8u-dev] RFR: 8288763: Pack200 extraction failure with invalid
 size
In-Reply-To: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
References: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
Message-ID: <bfULkWwNyhzJc-vL5m9y3QFxs6oYCeulqaamfdkqtPw=.d4fdee87-9064-41a5-b380-db4ff1361bb8@github.com>

On Wed, 20 Jul 2022 20:59:48 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> Backports this change to jdk8 to fix the pack200 compressed size issue here as well.

Hi @jerboaa, I am reaching out because I haven't received a fix-yes or a fix-no response to the backport request on JBS. Could you please take a look when you have a moment?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From poonam at openjdk.org  Mon Aug 15 16:51:30 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 15 Aug 2022 16:51:30 GMT
Subject: [jdk8u-dev] RFR: 8201793: (ref) Reference object should not support
 cloning
Message-ID: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>

This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.

With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.

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

Commit messages:
 - 8201793: (ref) Reference object should not support cloning

Changes: https://git.openjdk.org/jdk8u-dev/pull/102/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8201793
  Stats: 121 lines in 2 files changed: 121 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/102/head:pull/102

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From poonam at openjdk.org  Mon Aug 15 18:34:15 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 15 Aug 2022 18:34:15 GMT
Subject: [jdk8u-dev] RFR: 8285400: Add '@apiNote' to the APIs defined in Java
 SE 8 MR 3
Message-ID: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>

This changeset is a backport of JDK-8285400 from jdk8u-ri to jdk8u-dev. It is a clean backport other than the manual update of the copyright years.

This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :

    https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
    https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

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

Commit messages:
 - fix copyright year update
 - 8285400: Add '@apiNote' to the APIs defined in Java SE 8 MR 3

Changes: https://git.openjdk.org/jdk8u-dev/pull/103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8285400
  Stats: 42 lines in 12 files changed: 26 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/103/head:pull/103

PR: https://git.openjdk.org/jdk8u-dev/pull/103

From mbalao at openjdk.org  Mon Aug 15 19:14:22 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 15 Aug 2022 19:14:22 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
Message-ID: <nA_x_AC1wHNZc0BlUG_ZA_tgUFBSdnkx6kZkUgsYcnY=.4a49d681-51a9-42d3-a711-b0e6d25e5ae6@github.com>

On Tue, 9 Aug 2022 19:30:22 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
> I'd like to add this functionality for parity with Oracle JavaSE8
> 
> The patch rolls back the JDK-8245476 and updates JTREG tests
> 
> All sun/security/ssl and javax/net/ssl jtreg tests are passed

Hi @alexeybakhtin ,

Thanks for proposing this backport. Just for the record, the non-tests part of this change is the revert of https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ad16e2ef963c

Looks good to me overall, just a couple of minor comments related to tests:

1) During the 8u backport of several TLS 1.3 related tests, a system property had to be passed so TLS 1.3 was used by the client: -Djdk.tls.client.protocols. Can we now remove this and leave the tests aligned to newer releases? This would also be an additional check for the new defaults.

2) The test TLSClientPropertyTest.java requires some TLS 1.3 removal undoing too.

For reference, this is the changeset that introduced the TLS 1.3 tests adaptation in 8u: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ed0d638da09f

Thanks,
Martin.-

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From phh at openjdk.org  Mon Aug 15 19:27:28 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 15 Aug 2022 19:27:28 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
Message-ID: <UhXGwOpusBJqZA02h-jTxG7NpMoUUftfbMyKx36bCgI=.dbe8da8c-b3aa-4c32-af47-335bea4f585d@github.com>

On Tue, 21 Jun 2022 02:27:18 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8049228: Improve multithreaded scalability of InetAddress cache
>   
>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

@ lusou-zhangquan, I strongly suspect the copyright date conflict in InetAddressCachePolicy.java would cause a merge failure if I sponsored this. Once you fix it I'll re-review and sponsor.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From mchung at openjdk.org  Mon Aug 15 20:42:27 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 15 Aug 2022 20:42:27 GMT
Subject: [jdk8u-dev] RFR: 8201793: (ref) Reference object should not
 support cloning
In-Reply-To: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
References: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
Message-ID: <TYsNoCb_iI4RHDzwKEYCZ5wjQjf8cWtOWO5Vtb9jez4=.fe53804c-04a9-4124-af13-7a66e58c87de@github.com>

On Mon, 15 Aug 2022 16:42:06 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.
> 
> With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.

Looks good.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From abakhtin at openjdk.org  Mon Aug 15 20:45:22 2022
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 15 Aug 2022 20:45:22 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles [v2]
In-Reply-To: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
Message-ID: <nYDlHO1skwzjGaPYWUIrYw6d1GKV_kql43JkqLsYKEw=.83ddfb6a-2ce1-40ba-88f5-a47c80352824@github.com>

> Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
> I'd like to add this functionality for parity with Oracle JavaSE8
> 
> The patch rolls back the JDK-8245476 and updates JTREG tests
> 
> All sun/security/ssl and javax/net/ssl jtreg tests are passed

Alexey Bakhtin has updated the pull request incrementally with two additional commits since the last revision:

 - Update additional TLS1.3 related tests
 - Update TLS1.3 related tests

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/96/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/96/files/013a3d34..e8904524

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=96&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=96&range=00-01

  Stats: 19 lines in 12 files changed: 1 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/96.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/96/head:pull/96

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From abakhtin at openjdk.org  Mon Aug 15 20:45:22 2022
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 15 Aug 2022 20:45:22 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <nA_x_AC1wHNZc0BlUG_ZA_tgUFBSdnkx6kZkUgsYcnY=.4a49d681-51a9-42d3-a711-b0e6d25e5ae6@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
 <nA_x_AC1wHNZc0BlUG_ZA_tgUFBSdnkx6kZkUgsYcnY=.4a49d681-51a9-42d3-a711-b0e6d25e5ae6@github.com>
Message-ID: <62r-n9olZDOvu3cvKdMjfNDYSVeXJ1UsOk2MkMKlfF0=.5013649d-93fb-464a-83f5-6a0035933f15@github.com>

On Mon, 15 Aug 2022 19:10:34 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
>> I'd like to add this functionality for parity with Oracle JavaSE8
>> 
>> The patch rolls back the JDK-8245476 and updates JTREG tests
>> 
>> All sun/security/ssl and javax/net/ssl jtreg tests are passed
>
> Hi @alexeybakhtin ,
> 
> Thanks for proposing this backport. Just for the record, the non-tests part of this change is the revert of https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ad16e2ef963c
> 
> Looks good to me overall, just a couple of minor comments related to tests:
> 
> 1) During the 8u backport of several TLS 1.3 related tests, a system property had to be passed so TLS 1.3 was used by the client: -Djdk.tls.client.protocols. Can we now remove this and leave the tests aligned to newer releases? This would also be an additional check for the new defaults.
> 
> 2) The test TLSClientPropertyTest.java requires some TLS 1.3 removal undoing too.
> 
> For reference, this is the changeset that introduced the TLS 1.3 tests adaptation in 8u: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ed0d638da09f
> 
> Thanks,
> Martin.-

Hi @martinuy

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From mchung at openjdk.org  Mon Aug 15 20:47:33 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 15 Aug 2022 20:47:33 GMT
Subject: [jdk8u-dev] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
References: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
Message-ID: <ICAR0iY-LdMJyV6IbhKivsixawT8EZePnS4q5Mv6LUA=.038aa59f-e764-4954-9921-2dfb630ba982@github.com>

On Mon, 15 Aug 2022 18:18:50 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset is a backport of JDK-8285400 from jdk8u-ri to jdk8u-dev. It is a clean backport other than the manual update of the copyright years.
> 
> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

Looks good.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/103

From mbalao at openjdk.org  Mon Aug 15 22:24:28 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 15 Aug 2022 22:24:28 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <62r-n9olZDOvu3cvKdMjfNDYSVeXJ1UsOk2MkMKlfF0=.5013649d-93fb-464a-83f5-6a0035933f15@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
 <nA_x_AC1wHNZc0BlUG_ZA_tgUFBSdnkx6kZkUgsYcnY=.4a49d681-51a9-42d3-a711-b0e6d25e5ae6@github.com>
 <62r-n9olZDOvu3cvKdMjfNDYSVeXJ1UsOk2MkMKlfF0=.5013649d-93fb-464a-83f5-6a0035933f15@github.com>
Message-ID: <b9KhELRn3tJcjqdfl1WG-Wh5s9mR67RMuQYZxdXM1Pc=.8dd738ee-3113-442d-ae3f-66b70a04ba98@github.com>

On Mon, 15 Aug 2022 20:41:57 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hi @alexeybakhtin ,
>> 
>> Thanks for proposing this backport. Just for the record, the non-tests part of this change is the revert of https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ad16e2ef963c
>> 
>> Looks good to me overall, just a couple of minor comments related to tests:
>> 
>> 1) During the 8u backport of several TLS 1.3 related tests, a system property had to be passed so TLS 1.3 was used by the client: -Djdk.tls.client.protocols. Can we now remove this and leave the tests aligned to newer releases? This would also be an additional check for the new defaults.
>> 
>> 2) The test TLSClientPropertyTest.java requires some TLS 1.3 removal undoing too.
>> 
>> For reference, this is the changeset that introduced the TLS 1.3 tests adaptation in 8u: https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ed0d638da09f
>> 
>> Thanks,
>> Martin.-
>
> Hi @martinuy 
> Thank you a lot for the review and your comments
> Please find updates for the TLSv1.3 related tests. As you said most of the changes are revert of the tests adaptation  https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ed0d638da09f
> Also, I have updated tests from the https://github.com/openjdk/jdk8u-dev/commit/99f78de325c864875b348e66e1c6bc9b357e899e and https://github.com/openjdk/jdk8u-dev/commit/ce0307b965040e1e3ee7cd34c0ef7da02f344f81

Hi @alexeybakhtin ,

Changes look good. Any new test failure? (I don't think but just wanted to check)

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From duke at openjdk.org  Tue Aug 16 02:25:41 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Tue, 16 Aug 2022 02:25:41 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v4]
In-Reply-To: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
Message-ID: <Ae5D_EQRlJyBduXCdrRj0Hc_islbnyVKiPuyWHX6Y68=.322f8008-af16-4cb4-8b40-a0f764b27bc8@github.com>

> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
> 
> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:

  8049228: Update copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/70/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/70/files/08467055..68cb8d33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=70&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=70&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/70/head:pull/70

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Tue Aug 16 02:43:43 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Tue, 16 Aug 2022 02:43:43 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <61SFGh2sPWF6owYqUbvRYVPeO7Bier2jrzuni8PYcmY=.7be4275b-1a1a-4900-a8b3-504c5959c4f7@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
 <61SFGh2sPWF6owYqUbvRYVPeO7Bier2jrzuni8PYcmY=.7be4275b-1a1a-4900-a8b3-504c5959c4f7@github.com>
Message-ID: <imn2oTrG7yyORIHXdPAUYTVdAVC61SuLNYk9oDjYumI=.a1d7dafe-0ca7-4d1d-85b4-31d2821a340e@github.com>

On Mon, 15 Aug 2022 09:01:13 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> I've approved this one, but as I commented on the bug, it would be nice to know the reasoning for this backport. Approvals are primarily about risk assessment in the context of the whole JDK.
> 
> In this case, it's been in later JDKs for years, and is realistically borderline between being an enhancement and a bug fix (see https://bugs.openjdk.org/browse/JDK-8171346). I think it would be preferable to deal with any issues in the new code rather than the current outdated code, which is doing its own locking that is prone to error.

This bug is reproduced in our DNS service, which is running on jdk8 and hard to be upgraded to newer versions. So we hope to backport it and eliminate this potential risk for all jdk8 users.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Tue Aug 16 05:50:31 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Tue, 16 Aug 2022 05:50:31 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <UhXGwOpusBJqZA02h-jTxG7NpMoUUftfbMyKx36bCgI=.dbe8da8c-b3aa-4c32-af47-335bea4f585d@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
 <UhXGwOpusBJqZA02h-jTxG7NpMoUUftfbMyKx36bCgI=.dbe8da8c-b3aa-4c32-af47-335bea4f585d@github.com>
Message-ID: <bX0Y3mpPAP3U73sM56nmspH1J2VcoszEEt13COmtrHc=.5fb3b011-b3eb-4e51-b9a8-a3acb4b9de05@github.com>

On Mon, 15 Aug 2022 19:23:29 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> @ lusou-zhangquan, I strongly suspect the copyright date conflict in InetAddressCachePolicy.java would cause a merge failure if I sponsored this. Once you fix it I'll re-review and sponsor.

Copyright date has been updated in latest commit, thanks for your suggestion.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From abakhtin at openjdk.org  Tue Aug 16 07:40:34 2022
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 16 Aug 2022 07:40:34 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <b9KhELRn3tJcjqdfl1WG-Wh5s9mR67RMuQYZxdXM1Pc=.8dd738ee-3113-442d-ae3f-66b70a04ba98@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
 <nA_x_AC1wHNZc0BlUG_ZA_tgUFBSdnkx6kZkUgsYcnY=.4a49d681-51a9-42d3-a711-b0e6d25e5ae6@github.com>
 <62r-n9olZDOvu3cvKdMjfNDYSVeXJ1UsOk2MkMKlfF0=.5013649d-93fb-464a-83f5-6a0035933f15@github.com>
 <b9KhELRn3tJcjqdfl1WG-Wh5s9mR67RMuQYZxdXM1Pc=.8dd738ee-3113-442d-ae3f-66b70a04ba98@github.com>
Message-ID: <pFywkVb9ebA1wf6HKg0HyLV7YIzPuUPnemebAocSRrM=.5b37340c-368f-4eab-8924-b29da28a1572@github.com>

On Mon, 15 Aug 2022 22:22:24 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi @martinuy 
>> Thank you a lot for the review and your comments
>> Please find updates for the TLSv1.3 related tests. As you said most of the changes are revert of the tests adaptation  https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/ed0d638da09f
>> Also, I have updated tests from the https://github.com/openjdk/jdk8u-dev/commit/99f78de325c864875b348e66e1c6bc9b357e899e and https://github.com/openjdk/jdk8u-dev/commit/ce0307b965040e1e3ee7cd34c0ef7da02f344f81
>
> Hi @alexeybakhtin ,
> 
> Changes look good. Any new test failure? (I don't think but just wanted to check)

@martinuy
No new failures in sun/security/ssl javax/net/ssl tests. All tests passed except of sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java which fails on the unmodified code also.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From sgehwolf at openjdk.org  Tue Aug 16 09:26:29 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 16 Aug 2022 09:26:29 GMT
Subject: [jdk8u-dev] RFR: 8288763: Pack200 extraction failure with invalid
 size
In-Reply-To: <bfULkWwNyhzJc-vL5m9y3QFxs6oYCeulqaamfdkqtPw=.d4fdee87-9064-41a5-b380-db4ff1361bb8@github.com>
References: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
 <bfULkWwNyhzJc-vL5m9y3QFxs6oYCeulqaamfdkqtPw=.d4fdee87-9064-41a5-b380-db4ff1361bb8@github.com>
Message-ID: <LCNAOpqbE_21gcywQs_twjwdGXz5sgf6fKzwZXjUZLw=.75e0af8d-9ec6-41c4-a4d0-368c525b4af7@github.com>

On Mon, 15 Aug 2022 16:30:40 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

>> Backports this change to jdk8 to fix the pack200 compressed size issue here as well.
>
> Hi @jerboaa, I am reaching out because I haven't received a fix-yes or a fix-no response to the backport request on JBS. Could you please take a look when you have a moment?

@backwaterred OK. I've approved this on the basis that resetting the compressed size to unknown should do no harm.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From tsteele at openjdk.org  Tue Aug 16 13:24:45 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Tue, 16 Aug 2022 13:24:45 GMT
Subject: [jdk8u-dev] RFR: 8288763: Pack200 extraction failure with invalid
 size
In-Reply-To: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
References: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
Message-ID: <ZchgTtGDj7F7LMPRm-Cfs-QGPfPnW1hqkzJRO1n3xuI=.2db6d4d0-7160-481b-94da-7896aacf8275@github.com>

On Wed, 20 Jul 2022 20:59:48 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> Backports this change to jdk8 to fix the pack200 compressed size issue here as well.

Thanks all!

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From mbalao at openjdk.org  Tue Aug 16 14:00:38 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Tue, 16 Aug 2022 14:00:38 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles [v2]
In-Reply-To: <nYDlHO1skwzjGaPYWUIrYw6d1GKV_kql43JkqLsYKEw=.83ddfb6a-2ce1-40ba-88f5-a47c80352824@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
 <nYDlHO1skwzjGaPYWUIrYw6d1GKV_kql43JkqLsYKEw=.83ddfb6a-2ce1-40ba-88f5-a47c80352824@github.com>
Message-ID: <mk4qiWpqPL1i_Er7kQ4RtT9nd6JffXTMILiTVYxbtNY=.aa50af5d-340c-4136-944d-fa619f68394d@github.com>

On Mon, 15 Aug 2022 20:45:22 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
>> I'd like to add this functionality for parity with Oracle JavaSE8
>> 
>> The patch rolls back the JDK-8245476 and updates JTREG tests
>> 
>> All sun/security/ssl and javax/net/ssl jtreg tests are passed
>
> Alexey Bakhtin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update additional TLS1.3 related tests
>  - Update TLS1.3 related tests

Looks good to me.

Marked as reviewed by mbalao (Reviewer).

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

Marked as reviewed by mbalao (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From sgehwolf at openjdk.org  Tue Aug 16 14:12:20 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 16 Aug 2022 14:12:20 GMT
Subject: [jdk8u-dev] RFR: JDK-8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <pFywkVb9ebA1wf6HKg0HyLV7YIzPuUPnemebAocSRrM=.5b37340c-368f-4eab-8924-b29da28a1572@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
 <nA_x_AC1wHNZc0BlUG_ZA_tgUFBSdnkx6kZkUgsYcnY=.4a49d681-51a9-42d3-a711-b0e6d25e5ae6@github.com>
 <62r-n9olZDOvu3cvKdMjfNDYSVeXJ1UsOk2MkMKlfF0=.5013649d-93fb-464a-83f5-6a0035933f15@github.com>
 <b9KhELRn3tJcjqdfl1WG-Wh5s9mR67RMuQYZxdXM1Pc=.8dd738ee-3113-442d-ae3f-66b70a04ba98@github.com>
 <pFywkVb9ebA1wf6HKg0HyLV7YIzPuUPnemebAocSRrM=.5b37340c-368f-4eab-8924-b29da28a1572@github.com>
Message-ID: <-p5-_LWtgI-v11PXZCFiqMyo0Q4epu2A-2t_qSR00V0=.eaf17540-8026-471e-9634-d587f944fc1d@github.com>

On Tue, 16 Aug 2022 07:38:34 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Hi @alexeybakhtin ,
>> 
>> Changes look good. Any new test failure? (I don't think but just wanted to check)
>
> @martinuy
> No new failures in sun/security/ssl javax/net/ssl tests. All tests passed except of sun/security/ssl/X509TrustManagerImpl/Symantec/Distrust.java which fails on the unmodified code also.

@alexeybakhtin Please use PR title `Backport JDK-8245263` as the issue is oracle-jdk specific which doesn't have a public sha we can reference. This should be a workaround to make the skara tooling recognize this as a backport. See https://bugs.openjdk.org/browse/SKARA-1076

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From iris at openjdk.org  Tue Aug 16 16:21:24 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 16 Aug 2022 16:21:24 GMT
Subject: [jdk8u-dev] RFR: 8201793: (ref) Reference object should not
 support cloning
In-Reply-To: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
References: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
Message-ID: <rdhY4IVxofusJQshSE9o3Ue8Qs6GJLeQdZRWnrf_hXU=.e985d3c0-7778-4836-aa47-84a70279f306@github.com>

On Mon, 15 Aug 2022 16:42:06 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.
> 
> With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.

Spec changes match those in JSR 337 MR 4.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From abakhtin at openjdk.org  Tue Aug 16 18:51:21 2022
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 16 Aug 2022 18:51:21 GMT
Subject: [jdk8u-dev] Integrated: 8245263: Enable TLSv1.3 by default on JDK 8u
 for Client roles
In-Reply-To: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
References: <de9geGLnt64wwrIqortAIiiMOr8skcPTLi1wyq_uRh4=.f710ac13-9189-490a-94be-472e3ef2bed3@github.com>
Message-ID: <i87tbcgg5E3FfrJSbWZJONnnlb2plkhWbXwFqLLQxIw=.d866bc5a-6853-4bc3-b3e4-cb912893a962@github.com>

On Tue, 9 Aug 2022 19:30:22 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review a patch to enable TLSv1.3 by default on JDK 8u for Client roles
> I'd like to add this functionality for parity with Oracle JavaSE8
> 
> The patch rolls back the JDK-8245476 and updates JTREG tests
> 
> All sun/security/ssl and javax/net/ssl jtreg tests are passed

This pull request has now been integrated.

Changeset: 8e2c4984
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/8e2c498478231661a10f88854ce8afe26f0c0cd0
Stats:     30 lines in 15 files changed: 3 ins; 1 del; 26 mod

8245263: Enable TLSv1.3 by default on JDK 8u for Client roles

Reviewed-by: mbalao

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

PR: https://git.openjdk.org/jdk8u-dev/pull/96

From andrew at openjdk.org  Tue Aug 16 21:25:20 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 16 Aug 2022 21:25:20 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v4]
In-Reply-To: <Ae5D_EQRlJyBduXCdrRj0Hc_islbnyVKiPuyWHX6Y68=.322f8008-af16-4cb4-8b40-a0f764b27bc8@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <Ae5D_EQRlJyBduXCdrRj0Hc_islbnyVKiPuyWHX6Y68=.322f8008-af16-4cb4-8b40-a0f764b27bc8@github.com>
Message-ID: <dsfJinf7wFQ5VhHtNr1CvQXh0VJnGvMRC5AlI_58ygA=.28e63840-ff02-4aa7-a2ec-cefab0ca8bbe@github.com>

On Tue, 16 Aug 2022 02:25:41 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8049228: Update copyright date

Wait, what? Why are we changing the copyright dates? This is not part of the original patch. Please revert this change.

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

Changes requested by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Tue Aug 16 22:42:54 2022
From: duke at openjdk.org (Dan Lutker)
Date: Tue, 16 Aug 2022 22:42:54 GMT
Subject: [jdk8u-dev] RFR: 7131823: bug in GIFImageReader
Message-ID: <XOx4eYpylKAR5FgWiSUM7abE7kki9OLvyXuucn1i77U=.ef3c545d-2bb8-4d08-96a7-622d997794a2@github.com>

Backport of a31130fd4056907edcb420761722c629a33273eb, paths had to be updated and diff applied with offset.


patching file jdk/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
Hunk #1 succeeded at 937 (offset -16 lines).
Hunk #2 succeeded at 961 (offset -16 lines).
Hunk #3 succeeded at 984 (offset -16 lines).
patching file jdk/test/javax/imageio/plugins/gif/GIFLargeTableIndexTest.java


All imageio tests are passing including new test in the backport.

I have some tier1 errors locally that also happen without this change:

Summary: jdk_tier1
FAILED: java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectAndSummaryStatisticsTest.java
FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java
FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java
FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java
FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java
FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java

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

Commit messages:
 - Backport a31130fd4056907edcb420761722c629a33273eb

Changes: https://git.openjdk.org/jdk8u-dev/pull/104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7131823
  Stats: 175 lines in 2 files changed: 158 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/104.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/104/head:pull/104

PR: https://git.openjdk.org/jdk8u-dev/pull/104

From gnu.andrew at redhat.com  Wed Aug 17 16:14:15 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 17 Aug 2022 17:14:15 +0100
Subject: OpenJDK 8u352-b01 EA Released
Message-ID: <Yv0T17CduBjxbg+6@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u352, based on
the tag jdk8u352-b01:

https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b01-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b01-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint: CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

a55e07da8706c718a037947b955f12ac0035e8ea51a57a8e8edab66dfa3b6531  openjdk8u352-b01-ea.tar.xz
01050684b718a9726f86c0823cebd5ddba282d73015d8c8a4aa2ec9d39fcad61  openjdk8u352-b01-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u352-b01-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u352-b01:
  - JDK-8087283: Add support for the XML Signature here() function to the JDK XPath implementation
  - JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
  - JDK-8136354: [TEST_BUG] Test  java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script
  - JDK-8150669: C1 intrinsic for Class.isPrimitive
  - JDK-8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
  - JDK-8173361: various crashes in JvmtiExport::post_compiled_method_load
  - JDK-8194873: right ALT key hotkeys no longer work in Swing components
  - JDK-8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit
  - JDK-8235218: Minimal VM is broken after JDK-8173361
  - JDK-8235385: Crash on aarch64 JDK due to long offset
  - JDK-8256722: handle VC++:1927 VS2019 in  abstract_vm_version
  - JDK-8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)
  - JDK-8280963: Incorrect PrintFlags formatting on Windows
  - JDK-8282538: PKCS11 tests fail on CentOS Stream 9
  - JDK-8283849: AsyncGetCallTrace may crash JVM on guarantee
  - JDK-8287508: The tests added to jdk-8 by 8235385 are to be ported to jdk-11
  - JDK-8287521: Bump update version of OpenJDK: 8u352

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220817/4eb81051/signature.asc>

From phh at openjdk.org  Wed Aug 17 17:19:20 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 17 Aug 2022 17:19:20 GMT
Subject: [jdk8u-dev] RFR: 7131823: bug in GIFImageReader
In-Reply-To: <XOx4eYpylKAR5FgWiSUM7abE7kki9OLvyXuucn1i77U=.ef3c545d-2bb8-4d08-96a7-622d997794a2@github.com>
References: <XOx4eYpylKAR5FgWiSUM7abE7kki9OLvyXuucn1i77U=.ef3c545d-2bb8-4d08-96a7-622d997794a2@github.com>
Message-ID: <PQp8kLBaJEVhqV4PnRpm_AUANPNiTfOn5u9y4HBj8LA=.2571b4db-27f4-4c56-874f-955f1fa67c20@github.com>

On Tue, 16 Aug 2022 21:08:33 GMT, Dan Lutker <duke at openjdk.org> wrote:

> Backport of a31130fd4056907edcb420761722c629a33273eb, paths had to be updated and diff applied with offset.
> 
> 
> patching file jdk/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
> Hunk #1 succeeded at 937 (offset -16 lines).
> Hunk #2 succeeded at 961 (offset -16 lines).
> Hunk #3 succeeded at 984 (offset -16 lines).
> patching file jdk/test/javax/imageio/plugins/gif/GIFLargeTableIndexTest.java
> 
> 
> All imageio tests are passing including new test in the backport.
> 
> I have some tier1 errors locally that also happen without this change:
> 
> Summary: jdk_tier1
> FAILED: java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectAndSummaryStatisticsTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/104

From iris at openjdk.org  Wed Aug 17 17:43:44 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 17 Aug 2022 17:43:44 GMT
Subject: [jdk8u-dev] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
References: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
Message-ID: <tMfG46npvpZnenl9uFZAVC2hRm2hGEQySLliuoqyxIM=.500114b0-5740-490e-9fd1-4eea4eadb21c@github.com>

On Mon, 15 Aug 2022 18:18:50 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset is a backport of JDK-8285400 from jdk8u-ri to jdk8u-dev. It is a clean backport other than the manual update of the copyright years.
> 
> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

Matches https://github.com/openjdk/jdk8u-ri/pull/7

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u-dev/pull/103

From tsteele at openjdk.org  Wed Aug 17 19:52:27 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 17 Aug 2022 19:52:27 GMT
Subject: [jdk8u-dev] Integrated: 8288763: Pack200 extraction failure with
 invalid size
In-Reply-To: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
References: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
Message-ID: <JHVRo_vDKGJt76RQlTlerebc1OCiQApFCbnNkbog4fs=.685cd6d6-fb54-413b-b9ae-706e438851c4@github.com>

On Wed, 20 Jul 2022 20:59:48 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> Backports this change to jdk8 to fix the pack200 compressed size issue here as well.

This pull request has now been integrated.

Changeset: 645b6c81
Author:    Tyler Steele <tsteele at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/645b6c81bc9230ce5808fc4bd70240fc1311cdd4
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8288763: Pack200 extraction failure with invalid size

Reviewed-by: phh
Backport-of: 5e1ce54d6a11eac153a6e6487bc0b4ed89741b5b

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From duke at openjdk.org  Thu Aug 18 08:36:05 2022
From: duke at openjdk.org (xpbob)
Date: Thu, 18 Aug 2022 08:36:05 GMT
Subject: [jdk8u-dev] RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
Message-ID: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>

Backport a625bfdba45d49bc717bcc9be4112db93b50f50a

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

Commit messages:
 - Backport a625bfdba45d49bc717bcc9be4112db93b50f50a

Changes: https://git.openjdk.org/jdk8u-dev/pull/105/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=105&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283903
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/105.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/105/head:pull/105

PR: https://git.openjdk.org/jdk8u-dev/pull/105

From duke at openjdk.org  Thu Aug 18 16:03:00 2022
From: duke at openjdk.org (Nikita)
Date: Thu, 18 Aug 2022 16:03:00 GMT
Subject: [jdk8u-dev] RFR: 8148005: One byte may be corrupted by
 get_datetime_string()
Message-ID: <xjOEd9784MXsEfOSUJ7GYL7-SR4l79EHduKjATePqfI=.4359280b-344b-4773-b9da-70c9ab68df18@github.com>

The bug has been fixed in jdk9, but it wasn't backported to jdk8u.

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

Commit messages:
 - 8148005: One byte may be corrupted by get_datetime_string()

Changes: https://git.openjdk.org/jdk8u-dev/pull/97/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=97&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8148005
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/97.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/97/head:pull/97

PR: https://git.openjdk.org/jdk8u-dev/pull/97

From phh at openjdk.org  Thu Aug 18 19:03:04 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 18 Aug 2022 19:03:04 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
Message-ID: <xHq7e0MsU7jKPaiOFiT09r4eXk0hJxrGrn7hrMVGjPs=.72734ad1-4e15-4615-803d-aca0bd899a34@github.com>

On Fri, 24 Jun 2022 17:34:34 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`
> 
> This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 
> 
> There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.
> 
> The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From aph at redhat.com  Fri Aug 19 10:08:44 2022
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Aug 2022 11:08:44 +0100
Subject: I'm on PTO today
Message-ID: <88d112a0-5964-ed2f-1b26-5f1d922ab36c@redhat.com>

I'm on WhatsApp, etc, on +44 7776 208373.

-- 
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 Aug 19 10:18:36 2022
From: aph at redhat.com (Andrew Haley)
Date: Fri, 19 Aug 2022 11:18:36 +0100
Subject: I'm on PTO today
Message-ID: <013adbfa-cf8a-10a7-d0b1-635025c81a4e@redhat.com>

Sorry, wrong list. Damned auto-fill. :-)

-- 
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 openjdk.org  Fri Aug 19 16:21:29 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 19 Aug 2022 16:21:29 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1
Message-ID: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>

Hi,

I'd like to propose the backport of the JDK-8195607 fix to 8u because this release is affected by this issue. Given that the legacy NSS DB has been deprecated for a long time and it's increasingly replaced by SQLite DBs, the chances that JDK-8 builds hit this problem are now higher.

The 11u backport applies cleanly, once paths are fixed.

To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.

I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as wh
 en the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.

Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].

I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.

Thanks,
Martin.-

--
[1] - https://github.com/openjdk/jdk11u/blob/master/test/jdk/TEST.ROOT#L61
[2] - https://github.com/openjdk/jtreg/blob/jtreg-6.2%2B1/src/share/classes/com/sun/javatest/regtest/config/Locations.java#L174

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

Commit messages:
 - Clean the temporary nssdb directory so every test gets complete isolation (no interference from old files causing unreliability).
 - Backport b44c24d290362e4edf5b0bf18b1ecce1583daeff

Changes: https://git.openjdk.org/jdk8u-dev/pull/106/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=106&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8195607
  Stats: 57 lines in 5 files changed: 51 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/106.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/106/head:pull/106

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From mbalao at openjdk.org  Sat Aug 20 02:15:24 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Sat, 20 Aug 2022 02:15:24 GMT
Subject: [jdk8u-dev] RFR: JDK-8292688: Support Security properties in
 security.testlibrary.Proc
Message-ID: <p0-LPkxqymPm0K4Jb_dtfVBiIVloPVADUnPyiAQjD78=.84ec65d5-c44d-4f20-b7b9-27237cda0a68@github.com>

Hi,

I'd like to propose a test library enhacement as described in JDK-8292688 [1].

In addition to hook context modifications from Proc.java changes in JDK-8209901, I had to use Paths::get to obtain a Path instance from a String (Path::of is not available in 8u).

I tested these changes with my own code snippet:


public final class Main {
    private static final String CHILD_ID = "CHILD_ID";
    private static final String SEC_PROP = "SEC_PROP";
    private static final String SEC_PROP_VAL = "KNOWN_VAL!";
    public static void main(String[] args) throws Throwable {
        if (args.length > 0 && args[0].equals(CHILD_ID)) {
            String secVal = java.security.Security.getProperty(SEC_PROP);
            System.out.println("SEC_PROP: " + secVal);
            if (!secVal.equals(SEC_PROP_VAL)) {
                throw new Exception("TEST FAILED");
            }
        } else {
            Proc p = Proc.create(Main.class.getName()).args(CHILD_ID);
            p.secprop(SEC_PROP, SEC_PROP_VAL);
            p.debug(Main.class.getName());
            p.inheritIO();
            p.start().waitFor(0);
        }
    }
}


Thanks,
Martin.-

--
[1] - https://bugs.openjdk.org/browse/JDK-8292688

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

Commit messages:
 - JDK-8292688: Support Security properties in security.testlibrary.Proc

Changes: https://git.openjdk.org/jdk8u-dev/pull/107/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292688
  Stats: 27 lines in 1 file changed: 26 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/107.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/107/head:pull/107

PR: https://git.openjdk.org/jdk8u-dev/pull/107

From duke at openjdk.org  Sat Aug 20 11:34:59 2022
From: duke at openjdk.org (Poison)
Date: Sat, 20 Aug 2022 11:34:59 GMT
Subject: [jdk8u-dev] Integrated: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <h9NvdMqJNDt8eqFyzus4FE4Z4NXpuAdPf08ALa8IYRo=.3b03e99c-86a5-4d9a-a1c4-a88b5b47393a@github.com>

On Sat, 19 Mar 2022 07:57:49 GMT, Poison <duke at openjdk.org> wrote:

> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
> 
> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.

This pull request has now been integrated.

Changeset: 4cc462ab
Author:    Poison <tianshuang.me at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/4cc462abdd39f24e7f09b13f64af74bc2f1318d2
Stats:     9 lines in 1 file changed: 0 ins; 2 del; 7 mod

8214427: probable bug in logic of ConcurrentHashMap.addCount()

Reviewed-by: phh, andrew
Backport-of: 8846159987f902bb6e2b966eb4656da4b6d9469d

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From phh at openjdk.org  Sun Aug 21 17:36:26 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 21 Aug 2022 17:36:26 GMT
Subject: [jdk8u-dev] RFR: 8183107: PKCS11 regression regarding checkKeySize
In-Reply-To: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
References: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
Message-ID: <c_erIexkfjicdeBGtgn4c4hmEMjAOD5NUCFSH4x7iLY=.feaa792f-ef62-412b-b268-a8ab18e139c5@github.com>

On Thu, 11 Aug 2022 18:19:35 GMT, zzambers <duke at openjdk.org> wrote:

> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly except for copyright line P11Signature.java file, which already has newer year then what is in changest (so this change is excluded).
> 
> git apply -p3 --directory=jdk/src --reject 0001-8183107-PKCS11-regression-regarding-checkKeySize.patch
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java...
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java...
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java...
> error: while searching for:
> /*
>  * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> 
> error: patch failed: jdk/src/share/classes/sun/security/pkcs11/P11Signature.java:1
> Hunk #2 succeeded at 370 (offset -24 lines).
> Hunk #3 succeeded at 396 (offset -24 lines).
> Checking patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java...
> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java cleanly.
> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java cleanly.
> Applying patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java with 1 reject...
> Rejected hunk #1.
> Hunk #2 applied cleanly.
> Hunk #3 applied cleanly.
> Applied patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java cleanly.
> 
> 
> Tested locally, no regressions seen in jdk_security tests.
> This backport is done with intention of later also backporting JDK-8232950 [2], which depends on this one.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8183107
> [2] https://bugs.openjdk.org/browse/JDK-8232950

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/98

From phh at openjdk.org  Sun Aug 21 17:42:39 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 21 Aug 2022 17:42:39 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
Message-ID: <TRZ6CblJLZMUhu8FDRnmsngVc-kfwxhobGin39rRXAE=.19bf5cb9-416d-4a10-aea2-321d2d9702fa@github.com>

On Tue, 21 Jun 2022 07:52:23 GMT, George Adams <duke at openjdk.org> wrote:

> Backports https://bugs.openjdk.org/browse/JDK-8251551 as it's a low-risk change and generally improves the readability/usability in GitHub.
> 
> Currently, I've just converted the README to markdown format and added a little syntax highlighting. I'm not sure if people would like me to go one step further and rip out the mercurial/nested repo references?

Andrew, I reviewed https://github.com/openjdk/jdk8u-dev/pull/79.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/75

From phh at openjdk.org  Sun Aug 21 17:56:08 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 21 Aug 2022 17:56:08 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v4]
In-Reply-To: <Ae5D_EQRlJyBduXCdrRj0Hc_islbnyVKiPuyWHX6Y68=.322f8008-af16-4cb4-8b40-a0f764b27bc8@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <Ae5D_EQRlJyBduXCdrRj0Hc_islbnyVKiPuyWHX6Y68=.322f8008-af16-4cb4-8b40-a0f764b27bc8@github.com>
Message-ID: <XSSwLwZLtH0pQNNhi798S7pMcnj7plo5w78GVXxWT20=.1b0e32e5-1b81-40f8-809e-d5646d30fe28@github.com>

On Tue, 16 Aug 2022 02:25:41 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8049228: Update copyright date

That was my bad. Somehow I thought the original patch updated the copyright date. Please revert to the previous version.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From phh at openjdk.org  Sun Aug 21 18:14:28 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 21 Aug 2022 18:14:28 GMT
Subject: [jdk8u-dev] RFR: 8148005: One byte may be corrupted by
 get_datetime_string()
In-Reply-To: <xjOEd9784MXsEfOSUJ7GYL7-SR4l79EHduKjATePqfI=.4359280b-344b-4773-b9da-70c9ab68df18@github.com>
References: <xjOEd9784MXsEfOSUJ7GYL7-SR4l79EHduKjATePqfI=.4359280b-344b-4773-b9da-70c9ab68df18@github.com>
Message-ID: <HpL9uhfbFuk9XL3oVbyqRVDDdEeQvIWoE5oHWEvj-CU=.e7c57c8f-dca8-472b-9b5c-896b11ada16b@github.com>

On Thu, 11 Aug 2022 06:44:18 GMT, Nikita <duke at openjdk.org> wrote:

> The bug has been fixed in jdk9, but it wasn't backported to jdk8u.

Lgtm.

The PR doesn't have a backport label, which may cause problems. Do you need a sponsor?

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/97

From andrew at openjdk.org  Mon Aug 22 02:26:35 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 02:26:35 GMT
Subject: [jdk8u-dev] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
References: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
Message-ID: <d74IpG8cbbBdcgrjF2IGVvA74_qFYiRDnEFHrmOV-Rw=.d109ceeb-09c7-4ef4-ae88-5785ed456d4c@github.com>

On Thu, 11 Aug 2022 19:12:23 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport JDK-8175797 and two very closely related fixes (8178832 and 8193780) to jdk8u-dev:
> 
>     8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
>     8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
>     8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With these changes, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> It is a clean port from jdk8u-ri.

Makes sense to include 8178832 & 8193780 here to avoid including code only for it to be removed again by later commits.
Approved for 8u.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/99

From andrew at openjdk.org  Mon Aug 22 02:46:35 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 02:46:35 GMT
Subject: [jdk8u-dev] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
Message-ID: <f26M-oLulINsFJTSBmh1V9VO_4QgseXwHwwvEE2L3-0=.da0c0e3c-4c81-402a-be69-fe1cbaaf5ddc@github.com>

On Thu, 11 Aug 2022 20:35:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Same diff as used in the JDK 8u RI update.

Change looks good and nearly the same as that in 8u42. However, one copyright header change was missed in `System.c`, presumably due to 8189761 already having bumped it to 2019. Can we fix this please?

Also, please change the title to "Backport 31a63ba5f255e09349b3842984ac5bb3ad8e6c0b" so SKARA correctly identifies this as a backport. See https://wiki.openjdk.org/display/SKARA/Backports

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

Changes requested by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From andrew at openjdk.org  Mon Aug 22 02:49:31 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 02:49:31 GMT
Subject: [jdk8u-dev] RFR: 8201793: (ref) Reference object should not
 support cloning
In-Reply-To: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
References: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
Message-ID: <fqXkjrgrFI5pEFx4nkuJCOjLNPVdF0DnqgNS8YqOlHs=.2d4a4b8a-5d8d-4564-97da-71e32d0109c3@github.com>

On Mon, 15 Aug 2022 16:42:06 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.
> 
> With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.

Looks good. Approved.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From andrew at openjdk.org  Mon Aug 22 02:53:24 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 02:53:24 GMT
Subject: [jdk8u-dev] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
References: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
Message-ID: <yiBn0inzYe4-ozEc5S8zjLSsZNX8ayVlrCxjWCxJlo0=.67939486-e685-41f9-a34e-c95406e837d8@github.com>

On Mon, 15 Aug 2022 18:18:50 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset is a backport of JDK-8285400 from jdk8u-ri to jdk8u-dev. It is a clean backport other than the manual update of the copyright years.
> 
> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

Backport looks good.  Thanks for adjusting all those troublesome copyright headers!

I'm remember this being discussed when the MR3 changes were merged so it is good to see this update. Approved.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/103

From andrew at openjdk.org  Mon Aug 22 02:59:38 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 02:59:38 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
Message-ID: <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>

On Mon, 11 Jul 2022 12:16:34 GMT, George Adams <duke at openjdk.org> wrote:

> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

Looks good to me. Thanks for catching all the instances in the old subrepos. We should also clean up the `.jcheck` directories in those subdirectories. I doubt there is a backport for that one, so it would likely have to be an 8u bug.
Approved for 8u.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From andrew at openjdk.org  Mon Aug 22 03:15:20 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 03:15:20 GMT
Subject: [jdk8u-dev] RFR: 8183107: PKCS11 regression regarding checkKeySize
In-Reply-To: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
References: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
Message-ID: <IRNoxv32v4ytXvDInnDssiakqa_hXTrd1o3GV9rUPXI=.f3ff0a60-241b-4a63-a626-5fb9f0b3574a@github.com>

On Thu, 11 Aug 2022 18:19:35 GMT, zzambers <duke at openjdk.org> wrote:

> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly except for copyright line P11Signature.java file, which already has newer year then what is in changest (so this change is excluded).
> 
> git apply -p3 --directory=jdk/src --reject 0001-8183107-PKCS11-regression-regarding-checkKeySize.patch
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java...
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java...
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java...
> error: while searching for:
> /*
>  * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> 
> error: patch failed: jdk/src/share/classes/sun/security/pkcs11/P11Signature.java:1
> Hunk #2 succeeded at 370 (offset -24 lines).
> Hunk #3 succeeded at 396 (offset -24 lines).
> Checking patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java...
> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java cleanly.
> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java cleanly.
> Applying patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java with 1 reject...
> Rejected hunk #1.
> Hunk #2 applied cleanly.
> Hunk #3 applied cleanly.
> Applied patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java cleanly.
> 
> 
> Tested locally, no regressions seen in jdk_security tests.
> This backport is done with intention of later also backporting JDK-8232950 [2], which depends on this one.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8183107
> [2] https://bugs.openjdk.org/browse/JDK-8232950

Copyright header in `P11Signature.java` is newer due to JDK-8258833 backport, so dropping that change is fine.
Fix looks good. Approved.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/98

From andrew at openjdk.org  Mon Aug 22 03:22:30 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 03:22:30 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <xHq7e0MsU7jKPaiOFiT09r4eXk0hJxrGrn7hrMVGjPs=.72734ad1-4e15-4615-803d-aca0bd899a34@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
 <xHq7e0MsU7jKPaiOFiT09r4eXk0hJxrGrn7hrMVGjPs=.72734ad1-4e15-4615-803d-aca0bd899a34@github.com>
Message-ID: <yUlti_JFp10yKT5pzz3PyTU4wjkiGoZn9hZXJofmLiM=.87494acf-6e91-4524-93a0-b594926cfb88@github.com>

On Thu, 18 Aug 2022 18:51:41 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Lgtm.

Thanks Paul. Flagged for approval.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From duke at openjdk.org  Mon Aug 22 04:40:29 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Mon, 22 Aug 2022 04:40:29 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp [v2]
In-Reply-To: <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@github.com>
References: <WCZSnJWqvZqlMsQizOTcP0iaua8g2s4Kk2Ce5mOj6a0=.0b7e5a68-af18-4784-8570-8fdbebff7bdc@github.com>
 <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@github.com>
Message-ID: <5_npPAIkvNCvd4Lb2AGMpSPrSjNx9EuU8jFaUrO5WoE=.eba3a588-e914-4152-897c-5f5a38c05060@github.com>

On Wed, 22 Jun 2022 08:54:19 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

>> Hi! Please review another backport from MSVS2019 seria. This one fixes type declarations made by globalDefinitions_VisCPP.hpp. The patch from 11u applied with the following changes:
>> 
>> - inttypes.h is included conditionally under `_MSC_VER >= 1800` because the header was introduced only in MSVS 2013 but we have to keep support of the earlier MSVS versions 
>> - the duplicates of declarations made in inttypes.h are not just removed but quoted with `_MSC_VER < 1800`
>> - common\autoconf\generated-configure.sh is regenerated to add MSVS2019 recognition (I forgot to do that in https://github.com/openjdk/jdk8u-dev/pull/33)
>> 
>> Verification: 2019 build (both 32/64) now fails with 
>> 
>> ad_x86_64_pipeline.obj : error LNK2011: precompiled object not linked in; image may not run
>> jvm.dll : fatal error LNK1120: 1 unresolved externals
>> 
>> error (to be fixed by backport of 8043492)
>> 
>> Regression: 2017/2013/2012/2010 full build - ok
>> 
>> @kimbarrett @dholmes-ora if you took a look at that it would be very much appreciated
>
> Alexey Pavlyutkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge master
>  - fixing carriage returns
>  - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f

ping

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

PR: https://git.openjdk.org/jdk8u-dev/pull/77

From duke at openjdk.org  Mon Aug 22 07:53:10 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Mon, 22 Aug 2022 07:53:10 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
Message-ID: <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>

> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
> 
> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:

  Revert "8049228: Update copyright date"
  
  This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/70/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/70/files/68cb8d33..a7aece3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=70&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=70&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/70.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/70/head:pull/70

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Mon Aug 22 10:41:38 2022
From: duke at openjdk.org (George Adams)
Date: Mon, 22 Aug 2022 10:41:38 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
 <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>
Message-ID: <jIExREMd-uDtp_49ApPB8piLnLHMXtGUNyEsxhlizII=.89b67c2a-9a85-4168-b070-bd83cacde237@github.com>

On Mon, 22 Aug 2022 02:56:40 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change
>
> Looks good to me. Thanks for catching all the instances in the old subrepos. We should also clean up the `.jcheck` directories in those subdirectories. I doubt there is a backport for that one, so it would likely have to be an 8u bug.
> Approved for 8u.

Thanks for the review @gnu-andrew please can you sponsor this?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Mon Aug 22 10:53:31 2022
From: duke at openjdk.org (George Adams)
Date: Mon, 22 Aug 2022 10:53:31 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <_H5stR_20J6jyarLD-ImFrLYzJI1eccq0Gt0NLD1GB0=.d634d6da-dece-4526-915b-2e51dbcd8acc@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
 <_H5stR_20J6jyarLD-ImFrLYzJI1eccq0Gt0NLD1GB0=.d634d6da-dece-4526-915b-2e51dbcd8acc@github.com>
Message-ID: <iiNtNmZyb_njdoNaJZ1PijOsjRhpQ4YTjNZka7gi2Sk=.4c7012bc-2aec-4e81-89e0-318e393e8af4@github.com>

On Thu, 14 Jul 2022 18:26:49 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> That would be a backport of [JDK-8254318](https://bugs.openjdk.org/browse/JDK-8254318).

@phohensee I've covered this in https://github.com/openjdk/jdk8u-dev/pull/108

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Mon Aug 22 10:55:05 2022
From: duke at openjdk.org (George Adams)
Date: Mon, 22 Aug 2022 10:55:05 GMT
Subject: [jdk8u-dev] RFR: 8254318: Remove .hgtags
Message-ID: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>

Removes unused .hgtags files after the Git move. No code change. Low risk

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

Commit messages:
 - Backport 62a7f5d3236ab2248518a475b1d8b71cb4bf1313

Changes: https://git.openjdk.org/jdk8u-dev/pull/108/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254318
  Stats: 10233 lines in 9 files changed: 0 ins; 10233 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/108.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/108/head:pull/108

PR: https://git.openjdk.org/jdk8u-dev/pull/108

From duke at openjdk.org  Mon Aug 22 10:55:37 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 22 Aug 2022 10:55:37 GMT
Subject: [jdk8u-dev] RFR: 8183107: PKCS11 regression regarding checkKeySize
In-Reply-To: <IRNoxv32v4ytXvDInnDssiakqa_hXTrd1o3GV9rUPXI=.f3ff0a60-241b-4a63-a626-5fb9f0b3574a@github.com>
References: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
 <IRNoxv32v4ytXvDInnDssiakqa_hXTrd1o3GV9rUPXI=.f3ff0a60-241b-4a63-a626-5fb9f0b3574a@github.com>
Message-ID: <p5RxZmAbT0bjEewEE5q0Lh01-WlDZtbQ8Gm-uePNcSo=.1540fb6f-e999-45bc-9c5f-68531612b71a@github.com>

On Mon, 22 Aug 2022 03:11:52 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly except for copyright line P11Signature.java file, which already has newer year then what is in changest (so this change is excluded).
>> 
>> git apply -p3 --directory=jdk/src --reject 0001-8183107-PKCS11-regression-regarding-checkKeySize.patch
>> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java...
>> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java...
>> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java...
>> error: while searching for:
>> /*
>>  * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>> 
>> error: patch failed: jdk/src/share/classes/sun/security/pkcs11/P11Signature.java:1
>> Hunk #2 succeeded at 370 (offset -24 lines).
>> Hunk #3 succeeded at 396 (offset -24 lines).
>> Checking patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java...
>> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java cleanly.
>> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java cleanly.
>> Applying patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java with 1 reject...
>> Rejected hunk #1.
>> Hunk #2 applied cleanly.
>> Hunk #3 applied cleanly.
>> Applied patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java cleanly.
>> 
>> 
>> Tested locally, no regressions seen in jdk_security tests.
>> This backport is done with intention of later also backporting JDK-8232950 [2], which depends on this one.
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8183107
>> [2] https://bugs.openjdk.org/browse/JDK-8232950
>
> Copyright header in `P11Signature.java` is newer due to JDK-8258833 backport, so dropping that change is fine.
> Fix looks good. Approved.

@gnu-andrew @phohensee Thanks for reviews

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

PR: https://git.openjdk.org/jdk8u-dev/pull/98

From duke at openjdk.org  Mon Aug 22 12:42:57 2022
From: duke at openjdk.org (George Adams)
Date: Mon, 22 Aug 2022 12:42:57 GMT
Subject: [jdk8u-dev] Integrated: 8254178: Remove .hgignore
In-Reply-To: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
Message-ID: <Lr6Bh4kI-GWjXEylHl3sRaaH6pWaD_0u6OgpXpuJqNs=.48e619ea-86c0-47f3-84de-3b8872045b4d@github.com>

On Mon, 11 Jul 2022 12:16:34 GMT, George Adams <duke at openjdk.org> wrote:

> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

This pull request has now been integrated.

Changeset: 5323ef6c
Author:    George Adams <georgeadams1995 at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/5323ef6ca1bbf0a6e333565f97526fc5494081dc
Stats:     71 lines in 8 files changed: 0 ins; 71 del; 0 mod

8254178: Remove .hgignore

Reviewed-by: phh, andrew
Backport-of: 736e077335ec53c3804537a6abefa79087efd3ad

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From poonam at openjdk.org  Mon Aug 22 13:47:56 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 22 Aug 2022 13:47:56 GMT
Subject: [jdk8u-dev] Integrated: 8175797: (ref) Reference::enqueue method
 should clear the reference object before enqueuing
In-Reply-To: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
References: <IdKX1r3TzIuvSamSIt7tuhwYOQjoDsX16lKC4bTc5ck=.80dc9900-7715-4f05-ba07-22afd31a648b@github.com>
Message-ID: <rNokKLbMa1g-K9vWafH1c4Ual4Ev4wv2ADvpjnhC0C0=.6f2a89ec-c2c0-4d2a-a12f-c6db2c62df2e@github.com>

On Thu, 11 Aug 2022 19:12:23 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport JDK-8175797 and two very closely related fixes (8178832 and 8193780) to jdk8u-dev:
> 
>     8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
>     8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
>     8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With these changes, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> It is a clean port from jdk8u-ri.

This pull request has now been integrated.

Changeset: e633df1b
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/e633df1b629c4045e792623dbbb36b1b263f3683
Stats:     61 lines in 3 files changed: 52 ins; 3 del; 6 mod

8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
8193780: (ref) Remove the undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property

Reviewed-by: mchung, dholmes, iris, andrew
Backport-of: 330d63d2f9e18ba069e11868d4381059c66f480f

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

PR: https://git.openjdk.org/jdk8u-dev/pull/99

From andrew at openjdk.org  Mon Aug 22 14:03:39 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 14:03:39 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
 <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>
Message-ID: <xfzNAOPKjwsV1fB5OSM2-lNzCH3z3ElPdqk9NsHtcso=.554c568f-a6c1-4226-a9f9-e6919e1f0cdb@github.com>

On Mon, 22 Aug 2022 02:56:40 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change
>
> Looks good to me. Thanks for catching all the instances in the old subrepos. We should also clean up the `.jcheck` directories in those subdirectories. I doubt there is a backport for that one, so it would likely have to be an 8u bug.
> Approved for 8u.

> Thanks for the review @gnu-andrew please can you sponsor this?

I would have, but Paul beat me to it :) Sadly, you can't do the sponsorship until integrate is run.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From andrew at openjdk.org  Mon Aug 22 14:07:53 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 14:07:53 GMT
Subject: [jdk8u-dev] RFR: 8254318: Remove .hgtags
In-Reply-To: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>
References: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>
Message-ID: <dyTzKIe9AaWN1P9oYqwuHWSjeArVpt-_3MKvxT8hWhU=.2cdcc943-dd5a-414d-9451-6a3d0f269ae8@github.com>

On Mon, 22 Aug 2022 10:47:11 GMT, George Adams <duke at openjdk.org> wrote:

> Removes unused .hgtags files after the Git move. No code change. Low risk

Looks good to me. Are you able to add `jdk8u-fix-request` now? I see an authorship status: https://openjdk.org/census#gdams If not, i can do so (and approve at the same time)

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/108

From duke at openjdk.org  Mon Aug 22 14:07:53 2022
From: duke at openjdk.org (George Adams)
Date: Mon, 22 Aug 2022 14:07:53 GMT
Subject: [jdk8u-dev] RFR: 8254318: Remove .hgtags
In-Reply-To: <dyTzKIe9AaWN1P9oYqwuHWSjeArVpt-_3MKvxT8hWhU=.2cdcc943-dd5a-414d-9451-6a3d0f269ae8@github.com>
References: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>
 <dyTzKIe9AaWN1P9oYqwuHWSjeArVpt-_3MKvxT8hWhU=.2cdcc943-dd5a-414d-9451-6a3d0f269ae8@github.com>
Message-ID: <o9QgVk_5_v9oS3bSrJOlgdkCcSEEqLhwDSqwToreowU=.fa74a902-0707-4a1c-86fa-f3dc7916596a@github.com>

On Mon, 22 Aug 2022 14:02:45 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Looks good to me. Are you able to add jdk8u-fix-request now? I see an authorship status: https://openjdk.org/census#gdams If not, i can do so (and approve at the same time)

@gnu-andrew added the fix request

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

PR: https://git.openjdk.org/jdk8u-dev/pull/108

From duke at openjdk.org  Mon Aug 22 16:14:39 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 22 Aug 2022 16:14:39 GMT
Subject: [jdk8u-dev] Integrated: 8183107: PKCS11 regression regarding
 checkKeySize
In-Reply-To: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
References: <djlRrXWZfnE51PFuNVqY7zFmc0uOXne_B4Bu3AjaxMg=.baa66865-218e-4680-832a-812ba177bfeb@github.com>
Message-ID: <fprtV-hltBbYaYwrADGQjD7966Ij6Uy2A3LlmW1_gyQ=.0c92e403-e653-431e-b6fa-d3bcf99bcdc8@github.com>

On Thu, 11 Aug 2022 18:19:35 GMT, zzambers <duke at openjdk.org> wrote:

> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly except for copyright line P11Signature.java file, which already has newer year then what is in changest (so this change is excluded).
> 
> git apply -p3 --directory=jdk/src --reject 0001-8183107-PKCS11-regression-regarding-checkKeySize.patch
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java...
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java...
> Checking patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java...
> error: while searching for:
> /*
>  * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> 
> error: patch failed: jdk/src/share/classes/sun/security/pkcs11/P11Signature.java:1
> Hunk #2 succeeded at 370 (offset -24 lines).
> Hunk #3 succeeded at 396 (offset -24 lines).
> Checking patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java...
> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyGenerator.java cleanly.
> Applied patch jdk/src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java cleanly.
> Applying patch jdk/src/share/classes/sun/security/pkcs11/P11Signature.java with 1 reject...
> Rejected hunk #1.
> Hunk #2 applied cleanly.
> Hunk #3 applied cleanly.
> Applied patch jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM_INFO.java cleanly.
> 
> 
> Tested locally, no regressions seen in jdk_security tests.
> This backport is done with intention of later also backporting JDK-8232950 [2], which depends on this one.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8183107
> [2] https://bugs.openjdk.org/browse/JDK-8232950

This pull request has now been integrated.

Changeset: 1b52b014
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/1b52b014b6150efd480810d6561414c782c1f8c7
Stats:     79 lines in 4 files changed: 46 ins; 9 del; 24 mod

8183107: PKCS11 regression regarding checkKeySize

Changed key size check in PKCS11 provider to only enforce positive return values

Reviewed-by: phh, andrew
Backport-of: 67ca52873f088a08705baeef3e66319de1600576

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

PR: https://git.openjdk.org/jdk8u-dev/pull/98

From poonam at openjdk.org  Mon Aug 22 17:25:50 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 22 Aug 2022 17:25:50 GMT
Subject: [jdk8u-dev] RFR: 8201793: (ref) Reference object should not
 support cloning [v2]
In-Reply-To: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
References: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
Message-ID: <3UuJy5x8USxASC_pE1CHxqztckRgW8ymUHBAyduted0=.d04e93c9-2295-4a8b-85ab-46ca27e4442e@github.com>

> This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.
> 
> With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.

Poonam Bajaj has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - resolved conflicts
 - 8201793: (ref) Reference object should not support cloning

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

Changes: https://git.openjdk.org/jdk8u-dev/pull/102/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=102&range=01
  Stats: 121 lines in 2 files changed: 121 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/102.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/102/head:pull/102

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From poonam at openjdk.org  Mon Aug 22 18:48:49 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 22 Aug 2022 18:48:49 GMT
Subject: [jdk8u-dev] RFR: 8201793: (ref) Reference object should not
 support cloning [v2]
In-Reply-To: <3UuJy5x8USxASC_pE1CHxqztckRgW8ymUHBAyduted0=.d04e93c9-2295-4a8b-85ab-46ca27e4442e@github.com>
References: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
 <3UuJy5x8USxASC_pE1CHxqztckRgW8ymUHBAyduted0=.d04e93c9-2295-4a8b-85ab-46ca27e4442e@github.com>
Message-ID: <W45Ep9s2FcM8OTDybUDpKrbF4aUfEvC2tQQgagaPbMs=.54018961-1491-43b7-af59-a435faf80def@github.com>

On Mon, 22 Aug 2022 17:25:50 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.
>> 
>> With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.
>
> Poonam Bajaj has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - resolved conflicts
>  - 8201793: (ref) Reference object should not support cloning

\integrate

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

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From duke at openjdk.org  Mon Aug 22 19:14:07 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 22 Aug 2022 19:14:07 GMT
Subject: [jdk8u-dev] RFR: 8232950: SUNPKCS11 Provider incorrectly check key
 length for PSS Signatures.
Message-ID: <qI0L-K1aLjAjRfiPNmQY2CBwAXNmNw6_Wtxotj4o7Yc=.b8f4e3b7-a33c-4f98-829e-5b72fe30e3dc@github.com>

This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly.

git apply -p3 --dir=jdk/src 0001-8232950-SUNPKCS11-Provider-incorrectly-check-key-len.patch

Tested locally, no regressions in jdk_security tests.

[1] https://bugs.openjdk.org/browse/JDK-8232950

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

Commit messages:
 - Backport f14e3a60b26f0488da26abf3ae6c0521d5f616e5

Changes: https://git.openjdk.org/jdk8u-dev/pull/109/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8232950
  Stats: 10 lines in 1 file changed: 3 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/109.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/109/head:pull/109

PR: https://git.openjdk.org/jdk8u-dev/pull/109

From andrew at openjdk.org  Mon Aug 22 19:32:38 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 19:32:38 GMT
Subject: [jdk8u-dev] RFR: 8254318: Remove .hgtags
In-Reply-To: <o9QgVk_5_v9oS3bSrJOlgdkCcSEEqLhwDSqwToreowU=.fa74a902-0707-4a1c-86fa-f3dc7916596a@github.com>
References: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>
 <dyTzKIe9AaWN1P9oYqwuHWSjeArVpt-_3MKvxT8hWhU=.2cdcc943-dd5a-414d-9451-6a3d0f269ae8@github.com>
 <o9QgVk_5_v9oS3bSrJOlgdkCcSEEqLhwDSqwToreowU=.fa74a902-0707-4a1c-86fa-f3dc7916596a@github.com>
Message-ID: <3K7-z7vwHqVRXRjLEIk7NaQXVLPhV6_6mO1PJlSrBmk=.4bd1e06d-782f-4409-93a2-44e13609edb9@github.com>

On Mon, 22 Aug 2022 14:05:26 GMT, George Adams <duke at openjdk.org> wrote:

> > Looks good to me. Are you able to add jdk8u-fix-request now? I see an authorship status: https://openjdk.org/census#gdams If not, i can do so (and approve at the same time)
> 
> @gnu-andrew added the fix request

Approved.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/108

From andrew at openjdk.org  Mon Aug 22 19:38:31 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 19:38:31 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
Message-ID: <3Lk76753rBcAXymE6aDWF3vZ6Zt3O469P1JRehNcGNk=.e9f8a5c3-2059-49ea-b193-1b2022a3e90b@github.com>

On Mon, 22 Aug 2022 07:53:10 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8049228: Update copyright date"
>   
>   This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.

Ok, let's try again :)

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From andrew at openjdk.org  Mon Aug 22 19:38:33 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 19:38:33 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v4]
In-Reply-To: <XSSwLwZLtH0pQNNhi798S7pMcnj7plo5w78GVXxWT20=.1b0e32e5-1b81-40f8-809e-d5646d30fe28@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <Ae5D_EQRlJyBduXCdrRj0Hc_islbnyVKiPuyWHX6Y68=.322f8008-af16-4cb4-8b40-a0f764b27bc8@github.com>
 <XSSwLwZLtH0pQNNhi798S7pMcnj7plo5w78GVXxWT20=.1b0e32e5-1b81-40f8-809e-d5646d30fe28@github.com>
Message-ID: <dTlLmXoIMcByqQb0vROn1-zG4SN21AEyxG3ZPnIeAtQ=.49691ae6-4c0e-41e9-8094-9fc6fc6668f9@github.com>

On Sun, 21 Aug 2022 17:52:54 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> That was my bad. Somehow I thought the original patch updated the copyright date. Please revert to the previous version.

No worries. I just couldn't work out the issue you were referring to and indeed there is no 2022 bump in the original patch.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From poonam at openjdk.org  Mon Aug 22 19:57:54 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 22 Aug 2022 19:57:54 GMT
Subject: [jdk8u-dev] Integrated: 8201793: (ref) Reference object should not
 support cloning
In-Reply-To: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
References: <WOEFc0zwHtUboZOm23VDMBOtUSAaCannPO06kbOSatg=.d224dc62-39bd-491d-b711-d6b5dc8e26bf@github.com>
Message-ID: <KnH0SthKtnnmoYPPK4O_KsoEl-a1zv6EftRJpgJMzcg=.f59e60ae-01b6-40a2-8ad5-bcae4eca421b@github.com>

On Mon, 15 Aug 2022 16:42:06 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This is a clean backport of JDK-8201793 from jdk8u-ri to jdk8u-dev.
> 
> With this change, java.lang.ref.Reference::clone method always throws CloneNotSupportedException.

This pull request has now been integrated.

Changeset: 3a5b2cdc
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/3a5b2cdc101f501fb7681d6c1ce20f68db08f004
Stats:     121 lines in 2 files changed: 121 ins; 0 del; 0 mod

8201793: (ref) Reference object should not support cloning

Reviewed-by: mchung, iris, andrew
Backport-of: 58ec25de2f383144417eb000efacecb78b30395c

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

PR: https://git.openjdk.org/jdk8u-dev/pull/102

From andrew at openjdk.org  Mon Aug 22 20:01:37 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 22 Aug 2022 20:01:37 GMT
Subject: [jdk8u-dev] RFR: 8232950: SUNPKCS11 Provider incorrectly check key
 length for PSS Signatures.
In-Reply-To: <qI0L-K1aLjAjRfiPNmQY2CBwAXNmNw6_Wtxotj4o7Yc=.b8f4e3b7-a33c-4f98-829e-5b72fe30e3dc@github.com>
References: <qI0L-K1aLjAjRfiPNmQY2CBwAXNmNw6_Wtxotj4o7Yc=.b8f4e3b7-a33c-4f98-829e-5b72fe30e3dc@github.com>
Message-ID: <C3G1474NTITKNYB53wEtwVVD62jOsRyHJSUbTPo-ztI=.1ca97435-d8fe-485c-a55c-d61a12ab3f52@github.com>

On Mon, 22 Aug 2022 19:06:23 GMT, zzambers <duke at openjdk.org> wrote:

> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly.
> 
> git apply -p3 --dir=jdk/src 0001-8232950-SUNPKCS11-Provider-incorrectly-check-key-len.patch
> 
> Tested locally, no regressions in jdk_security tests.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8232950

Looks fine, clean backport.

Approved for 8u

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/109

From poonam at openjdk.org  Mon Aug 22 20:10:46 2022
From: poonam at openjdk.org (Poonam Bajaj)
Date: Mon, 22 Aug 2022 20:10:46 GMT
Subject: [jdk8u-dev] Integrated: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
References: <Is7Rj1IbuTfb4IU5rWhP0REPXR_KcAZmbEZt33Ol3Qo=.d8094c20-09db-48ea-b7e6-7101a86ee555@github.com>
Message-ID: <uD8tMLwFr7BaQrAGqoHFAUvbvoIaulcGy9B4g-3WMd0=.c31f2e52-d42e-4d52-acd1-603970c58d29@github.com>

On Mon, 15 Aug 2022 18:18:50 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset is a backport of JDK-8285400 from jdk8u-ri to jdk8u-dev. It is a clean backport other than the manual update of the copyright years.
> 
> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>     https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

This pull request has now been integrated.

Changeset: 8ad9018e
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/8ad9018e42916b683e163c1c7629a9ba9962aed4
Stats:     42 lines in 12 files changed: 26 ins; 2 del; 14 mod

8285400: Add '@apiNote' to the APIs defined in Java SE 8 MR 3

Reviewed-by: mchung, iris, andrew
Backport-of: 3740d05c063e1f80a0808a969a2cc136cafa48cb

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

PR: https://git.openjdk.org/jdk8u-dev/pull/103

From darcy at openjdk.org  Mon Aug 22 20:15:48 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Aug 2022 20:15:48 GMT
Subject: [jdk8u-dev] RFR: JDK-8285497: Add system property for Java SE
 specification maintenance version [v2]
In-Reply-To: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
Message-ID: <glDR8CDHfpCJjTmlMp6k92SGOtK6xa4oQcypTJxRrdw=.e3ff4595-2263-45b6-8329-e93d0b4acf9e@github.com>

> Same diff as used in the JDK 8u RI update.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8285497
 - Update copyright per code review comment.
 - JDK-8285497: Add system property for Java SE specification maintenance version

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/100/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/100/files/cb3240d5..c73443cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=100&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=100&range=00-01

  Stats: 372 lines in 34 files changed: 223 ins; 85 del; 64 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/100.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/100/head:pull/100

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From darcy at openjdk.org  Mon Aug 22 20:39:31 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 Aug 2022 20:39:31 GMT
Subject: [jdk8u-dev] RFR: 8285497: Add system property for Java SE
 specification maintenance version [v2]
In-Reply-To: <f26M-oLulINsFJTSBmh1V9VO_4QgseXwHwwvEE2L3-0=.da0c0e3c-4c81-402a-be69-fe1cbaaf5ddc@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
 <f26M-oLulINsFJTSBmh1V9VO_4QgseXwHwwvEE2L3-0=.da0c0e3c-4c81-402a-be69-fe1cbaaf5ddc@github.com>
Message-ID: <7b6YchfMPDm_2wVRVxvogOjI-4ysUyaedFX9ZOthkTY=.8646becc-5542-430f-98e7-26d5b64841ff@github.com>

On Mon, 22 Aug 2022 02:42:33 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Change looks good and nearly the same as that in 8u42. However, one copyright header change was missed in `System.c`, presumably due to 8189761 already having bumped it to 2019. Can we fix this please?
> 
> Also, please change the title to "Backport 31a63ba5f255e09349b3842984ac5bb3ad8e6c0b" so SKARA correctly identifies this as a backport. 

I've done as you've requested.

> See https://wiki.openjdk.org/display/SKARA/Backports

Yes, I am familiar with the basic operation of Skara. I don't see anything on the referenced page that requires use of a Skara Backport PR when doing a backport. The impetus for adding the backport feature to Skara, a feature enabled several months after JDK mainline switched to Skara, was to reduce the overhead of the common case of backport a fix to an earlier release where few to no changes are needed.

Before sending out this PR, I looked for, but did not find, documentation for what procedures 8u wanted to use for a situation like this.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From t.glaser at tarent.de  Tue Aug 23 00:55:14 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Tue, 23 Aug 2022 02:55:14 +0200 (CEST)
Subject: GCC 12 suitability?
Message-ID: <41cf7626-ab74-a15-d955-7be24272ce30@tarent.de>

Hi,

I vaguely recalling something about issues with GCC 12.
Now both Debian and *buntu are switching to it; can I
build jdk8u with it?

Thanks,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From duke at openjdk.org  Tue Aug 23 07:36:48 2022
From: duke at openjdk.org (George Adams)
Date: Tue, 23 Aug 2022 07:36:48 GMT
Subject: [jdk8u-dev] RFR: 8292762: Remove .jcheck directories from jdk8u
 subcomponents
Message-ID: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>

After the consolidation of jdk8u into a single mono-style repo there is no longer a need to have the .jcheck directories in each of the subcomponent directories. These can now be removed.

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

Commit messages:
 - 8292762 Remove .jcheck directories from jdk8u subcomponents

Changes: https://git.openjdk.org/jdk8u-dev/pull/110/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292762
  Stats: 14 lines in 7 files changed: 0 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/110.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/110/head:pull/110

PR: https://git.openjdk.org/jdk8u-dev/pull/110

From duke at openjdk.org  Tue Aug 23 07:44:50 2022
From: duke at openjdk.org (George Adams)
Date: Tue, 23 Aug 2022 07:44:50 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
 <ztxnRyDMpdPfothnVICCPYbY-cfBBXo12NqK8u6i3sY=.d9547f96-696f-4d38-9cf2-26ddefee4c68@github.com>
Message-ID: <U-bRDPqqd72QejO4VpzFa3tlbt4Qq3WlgWMBL6dzfZ4=.43a557f2-3887-4efe-b6c1-1f94a1ff0f06@github.com>

On Mon, 22 Aug 2022 02:56:40 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> We should also clean up the .jcheck directories in those subdirectories. I doubt there is a backport for that one, so it would likely have to be an 8u bug.

@gnu-andrew please see https://github.com/openjdk/jdk8u-dev/pull/110 (and [JDK-8292762](https://bugs.openjdk.org/browse/JDK-8292762))

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Tue Aug 23 11:42:31 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 23 Aug 2022 11:42:31 GMT
Subject: [jdk8u-dev] RFR: 8232950: SUNPKCS11 Provider incorrectly check key
 length for PSS Signatures.
In-Reply-To: <C3G1474NTITKNYB53wEtwVVD62jOsRyHJSUbTPo-ztI=.1ca97435-d8fe-485c-a55c-d61a12ab3f52@github.com>
References: <qI0L-K1aLjAjRfiPNmQY2CBwAXNmNw6_Wtxotj4o7Yc=.b8f4e3b7-a33c-4f98-829e-5b72fe30e3dc@github.com>
 <C3G1474NTITKNYB53wEtwVVD62jOsRyHJSUbTPo-ztI=.1ca97435-d8fe-485c-a55c-d61a12ab3f52@github.com>
Message-ID: <xxiPl4yFVn0ewLIr1KiRtOZNlOoi5XDXEs_J8d0W17I=.f73a3ce0-5c0b-4deb-8a9d-b4fe7a33a529@github.com>

On Mon, 22 Aug 2022 19:59:19 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly.
>> 
>> git apply -p3 --dir=jdk/src 0001-8232950-SUNPKCS11-Provider-incorrectly-check-key-len.patch
>> 
>> Tested locally, no regressions in jdk_security tests.
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8232950
>
> Approved for 8u

@gnu-andrew thanks

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

PR: https://git.openjdk.org/jdk8u-dev/pull/109

From phh at openjdk.org  Tue Aug 23 13:46:40 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 23 Aug 2022 13:46:40 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
Message-ID: <_EZ7ekyP-1TPeqyU2ABcaG38QKUuMmxETn2uX8vlKT8=.33d3e180-112b-49e0-aa19-bd8816a4bd7e@github.com>

On Mon, 22 Aug 2022 07:53:10 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8049228: Update copyright date"
>   
>   This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.

Just need an integrate comment. :)

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Tue Aug 23 15:15:19 2022
From: duke at openjdk.org (zzambers)
Date: Tue, 23 Aug 2022 15:15:19 GMT
Subject: [jdk8u-dev] RFR: 8039955: [TESTBUG] jdk/lambda/LambdaTranslationTest1
 - java.lang.AssertionError: expected [d:1234.000000] but found
 [d:1234, 000000]
Message-ID: <ehWCRWRqslE-H-HTVP3Pt2-1LfoXxu5c7Ijlvam4m5A=.17699524-f6b1-4187-b5f1-0588418ea263@github.com>

This is backport of JDK-8039955 [1]. 

Two tests from jdk_tier1 are sensitive to locale of test machine (expect "." as decimal separator), which causes failures when running on some locales, such as czech (which uses "," as decimal separator ). This backport fixes this issue.

Patch with changes applies cleanly:

git apply 0001-8039955-TESTBUG-jdk-lambda-LambdaTranslationTest1-ja.patch


Tested locally using czech locale, 2 tests in jdk_tier1 get fixed, no regressions.

[1] https://bugs.openjdk.org/browse/JDK-8039955

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

Commit messages:
 - Backport 3555038f51fbf7f908b7346a8329f4da44a7cde5

Changes: https://git.openjdk.org/jdk8u-dev/pull/112/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=112&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8039955
  Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/112.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/112/head:pull/112

PR: https://git.openjdk.org/jdk8u-dev/pull/112

From ebaron at openjdk.org  Tue Aug 23 16:11:31 2022
From: ebaron at openjdk.org (Elliott Baron)
Date: Tue, 23 Aug 2022 16:11:31 GMT
Subject: [jdk8u-dev] RFR: 8035467: Xerces Update: Move to Xalan based DOM
 L3 serializer. Deprecate Xerces' native serializer.
In-Reply-To: <Lx7dn5rK4UFSvKjhh9iv8DbQDcGnxGZ3Ct28bAcVl_k=.851d6cbb-526f-4635-9564-ef7722d31e3c@github.com>
References: <Lx7dn5rK4UFSvKjhh9iv8DbQDcGnxGZ3Ct28bAcVl_k=.851d6cbb-526f-4635-9564-ef7722d31e3c@github.com>
Message-ID: <lurGSXcJIN11ztzOHS3RX8ylfch0lhImm8-nm59x4rw=.98314198-5910-4860-a41b-55183f14fed3@github.com>

On Fri, 22 Jul 2022 22:13:07 GMT, Elliott Baron <ebaron at openjdk.org> wrote:

> This backport is part of the effort to update Xerces in 8u to 2.12 ([JDK-8238164](https://bugs.openjdk.org/browse/JDK-8238164).
> 
> The JDK 9 commit does not apply cleanly, but only required cosmetic changes. These are due to differences in some copyright headers, and not having a `@version` Javadoc tag in the 8u version of these files.
> 
> I am concerned over deprecating the Xerces serializer. As noted in [JDK-8219692](https://bugs.openjdk.org/browse/JDK-8219692), there are behavioural changes caused by this new serializer.

(Ping to keep PR open)

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

PR: https://git.openjdk.org/jdk8u-dev/pull/89

From sgehwolf at openjdk.org  Tue Aug 23 16:33:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Aug 2022 16:33:39 GMT
Subject: [jdk8u-dev] RFR: JDK-8292688: Support Security properties in
 security.testlibrary.Proc
In-Reply-To: <p0-LPkxqymPm0K4Jb_dtfVBiIVloPVADUnPyiAQjD78=.84ec65d5-c44d-4f20-b7b9-27237cda0a68@github.com>
References: <p0-LPkxqymPm0K4Jb_dtfVBiIVloPVADUnPyiAQjD78=.84ec65d5-c44d-4f20-b7b9-27237cda0a68@github.com>
Message-ID: <5WlJqFm2Vy9HbwtM52AtrKyNj9X0nfMbTAtHhEf6rTU=.f5c91bd9-2f93-4f77-bbbe-2dcad010f1c3@github.com>

On Sat, 20 Aug 2022 02:10:51 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> I'd like to propose a test library enhacement as described in JDK-8292688 [1].
> 
> In addition to hook context modifications from Proc.java changes in JDK-8209901, I had to use Paths::get to obtain a Path instance from a String (Path::of is not available in 8u).
> 
> I tested these changes with my own code snippet:
> 
> 
> public final class Main {
>     private static final String CHILD_ID = "CHILD_ID";
>     private static final String SEC_PROP = "SEC_PROP";
>     private static final String SEC_PROP_VAL = "KNOWN_VAL!";
>     public static void main(String[] args) throws Throwable {
>         if (args.length > 0 && args[0].equals(CHILD_ID)) {
>             String secVal = java.security.Security.getProperty(SEC_PROP);
>             System.out.println("SEC_PROP: " + secVal);
>             if (!secVal.equals(SEC_PROP_VAL)) {
>                 throw new Exception("TEST FAILED");
>             }
>         } else {
>             Proc p = Proc.create(Main.class.getName()).args(CHILD_ID);
>             p.secprop(SEC_PROP, SEC_PROP_VAL);
>             p.debug(Main.class.getName());
>             p.inheritIO();
>             p.start().waitFor(0);
>         }
>     }
> }
> 
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.org/browse/JDK-8292688

Looks fine to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/107

From sgehwolf at openjdk.org  Tue Aug 23 18:32:20 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 Aug 2022 18:32:20 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1
In-Reply-To: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
Message-ID: <eV0MkvSJITpAY1oYNhKW0C0cctrHhTBAhJzj4x1h8rU=.11683e51-abe4-46a2-86e8-343868886cee@github.com>

On Fri, 19 Aug 2022 02:50:19 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> The 11u backport applies cleanly, once paths are fixed.

Yes, that seems to be the case if https://github.com/openjdk/jdk8u-dev/pull/106/commits/73173863ab9da7ee2ec080401180475bf7ee22e1 is to be looked at on its own.
 
> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.

OK.

> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as 
 when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
> 
> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
> 
> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.

This seems strange, wouldn't a jtreg version `> 4.2 b08` not run into this problem? I.e. if I run with jtreg 5 (oldest version I have here), I wouldn't see this issue? If so I'm not sure this is worth adding https://github.com/openjdk/jdk8u-dev/pull/106/commits/22c1df05d2ab51a400ebdc69566e84fdaf32efec to this backport. It's not in head either. So at the very least this should be an 8u-only bug. But if that's only happening with jtreg 4, I'd say this is not worth fixing at all (or perhaps add jtreg 5 as a minimal version. Everyone should be on newer versions these days anyway.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From duke at openjdk.org  Tue Aug 23 22:10:34 2022
From: duke at openjdk.org (Bernd)
Date: Tue, 23 Aug 2022 22:10:34 GMT
Subject: [jdk8u-dev] RFR: 8035467: Xerces Update: Move to Xalan based DOM
 L3 serializer. Deprecate Xerces' native serializer.
In-Reply-To: <Lx7dn5rK4UFSvKjhh9iv8DbQDcGnxGZ3Ct28bAcVl_k=.851d6cbb-526f-4635-9564-ef7722d31e3c@github.com>
References: <Lx7dn5rK4UFSvKjhh9iv8DbQDcGnxGZ3Ct28bAcVl_k=.851d6cbb-526f-4635-9564-ef7722d31e3c@github.com>
Message-ID: <mhOLu9-cugqJ0c5xViPCvSfpyhb25K2aLP5eBKvA4GU=.4df317c4-aeb1-4416-a0c7-1d59302f5f48@github.com>

On Fri, 22 Jul 2022 22:13:07 GMT, Elliott Baron <ebaron at openjdk.org> wrote:

> This backport is part of the effort to update Xerces in 8u to 2.12 ([JDK-8238164](https://bugs.openjdk.org/browse/JDK-8238164).
> 
> The JDK 9 commit does not apply cleanly, but only required cosmetic changes. These are due to differences in some copyright headers, and not having a `@version` Javadoc tag in the 8u version of these files.
> 
> I am concerned over deprecating the Xerces serializer. As noted in [JDK-8219692](https://bugs.openjdk.org/browse/JDK-8219692), there are behavioural changes caused by this new serializer.

There are no additional tests needed?
BTW if the existing Testcases do not detect changed behavior then it?s either uncritical (or the tests are incomplete?)
I know with a backport there is not much room to make changes but should this really go into the Update tree with no additional testd, not even for the new api or the actual factories (to make sure the fallback is not used)

jaxp/src/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java line 389:

> 387:          */
> 388:         public LSSerializer createLSSerializer() {
> 389:             try {

Is there any advantage to loading this dynamically? The old implementation with a static constructor looks easier to follow. Since both are always in the same module also the fallback could be removed.

jaxp/src/com/sun/org/apache/xml/internal/serialize/OutputFormat.java line 64:

> 62:  * @see LineSeparator
> 63:  *
> 64:  * @deprecated As of JDK 1.9, Xerces 2.9.0, Xerces DOM L3 Serializer implementation

That could be missleading, is it deprecated since java 9 or is it replaced since java 8u?

jaxp/src/com/sun/org/apache/xml/internal/serializer/Encodings.java line 161:

> 159:      * @return boolean - true if the encoding was recognized else false
> 160:      */
> 161:     public static boolean isRecognizedEncoding(String encoding)

Is there a testcard for this new API?

jaxp/src/com/sun/org/apache/xml/internal/serializer/ToStream.java line 542:

> 540:                     setIndentAmount(Integer.parseInt(val));
> 541:                 } else if (OutputKeys.INDENT.equals(name)) {
> 542:                     boolean b = val.endsWith("yes") ? true : false;

EndsWith is not very idiomatic for a boolean, maybe that requires an explaining comment?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/89

From duke at openjdk.org  Wed Aug 24 04:01:32 2022
From: duke at openjdk.org (duke)
Date: Wed, 24 Aug 2022 04:01:32 GMT
Subject: [jdk8u-dev] Withdrawn: 8286582: Build fails on macos aarch64 when
 using --with-zlib=bundled
In-Reply-To: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
References: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
Message-ID: <lXeOBynmhzZo2T3Uhc9X6_sqoEFcLSj2s5yTNfQ8EjI=.9bf6e6ff-44a1-40fa-ad61-b3f2eed01c72@github.com>

On Mon, 27 Jun 2022 00:33:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [50d47de8](https://github.com/openjdk/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Jaikiran Pai on 12 May 2022 and was reviewed by Magnus Ihse Bursie and Lance Andersen.
> 
> The patch for JDK8 is slightly different:
>  * The main code patch is moved from the `make/autoconf/lib-bundled.m4` to the `jdk/make/lib/CoreLibraries.gmk` the same place where `":= -lz"` option is set.
>  * All disabled warnings are removed from the patch, seems we do not have such DISABLED_WARNINGS_XX in JDK8

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/80

From duke at openjdk.org  Wed Aug 24 08:04:51 2022
From: duke at openjdk.org (George Adams)
Date: Wed, 24 Aug 2022 08:04:51 GMT
Subject: [jdk8u-dev] Integrated: 8254318: Remove .hgtags
In-Reply-To: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>
References: <cqwUCGASASOVwWJ5u-lM12WxIN9Kv1uE3ho7us1VwYU=.06d0d9d3-66e8-4f62-913b-d26ac8f4316b@github.com>
Message-ID: <sKhj_zY8uWWTKHSxnr7Hd4K4cXzhay-Ii1zL8iYPBTE=.a04b1786-c0f5-467b-96e9-62998a9d8a1a@github.com>

On Mon, 22 Aug 2022 10:47:11 GMT, George Adams <duke at openjdk.org> wrote:

> Removes unused .hgtags files after the Git move. No code change. Low risk

This pull request has now been integrated.

Changeset: a4d49735
Author:    George Adams <georgeadams1995 at gmail.com>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/a4d497350218b38070164a71acc7502110567547
Stats:     10233 lines in 9 files changed: 0 ins; 10233 del; 0 mod

8254318: Remove .hgtags

Reviewed-by: andrew
Backport-of: 62a7f5d3236ab2248518a475b1d8b71cb4bf1313

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

PR: https://git.openjdk.org/jdk8u-dev/pull/108

From plenty.su at gmail.com  Wed Aug 24 09:52:52 2022
From: plenty.su at gmail.com (Plenty Su)
Date: Wed, 24 Aug 2022 18:52:52 +0900
Subject: Might be a ContainerSupport issue on macOS Docker Engine
Message-ID: <CALqsiWUwQj14Ff-R__-VL=8mDHowegsCJrf4tDMfizug_6fbOw@mail.gmail.com>

Hi,

I am trying the ContainerSupport feature.
https://bugs.openjdk.org/browse/JDK-8196595

This is my sample code
```
package com.example;

import com.sun.management.OperatingSystemMXBean;
import java.lang.management.ManagementFactory;
import java.util.concurrent.TimeUnit;

public class App {
  public static void main(String[] args) {
    OperatingSystemMXBean bean =
        (OperatingSystemMXBean)
ManagementFactory.getOperatingSystemMXBean();
    while (true) {
      System.out.println("processors: " + bean.getAvailableProcessors());
      System.out.println("memory: " + bean.getTotalPhysicalMemorySize());
      try {
        TimeUnit.SECONDS.sleep(5);
      } catch (Exception e) {
      }
    }
  }
}
```

I compiled this sample code with OpenJDK 8 without JVM argument
`-XX:+UseContainerSupport`,
and I dockerize it based on openjdk:8u342
```
FROM openjdk:8u342
COPY ./app/build/install/app /app
CMD [ "/app/bin/app" ]
```

Then, I ran this built image on Linux Docker Engine with the following
command
```
docker run --rm -it --cpus 1 -m 1G {image}
```

I got the output as I expected.
```
processors: 1
memory: 1073741824
```

However, when I tried to run the same built image on macOS Docker Engine
(Intel Chip) with the same image and command,
the output was my macOS Docker Engine's host information
```
processors: 4
memory: 6233055232
```
(My macOS Docker Engine has set resources limit to 4CPU and 6GB Memory)


I checked the cgroup files in the container. For example,
```
# cat /sys/fs/cgroup/memory.max
1073741824
```

It seems that macOS Docker Engine did set cgroup properly.

I also tried building the same application based on openjdk:17-alpine
(without re-compiling the code with JDK 17, only changing the base image)
```
FROM openjdk:17-alpine
COPY ./app/build/install/app /app
CMD [ "/app/bin/app" ]
```

and I tested the image with the same command on macOS.
It displayed the expected result.
```
> docker run --rm -it --cpus 1 -m 1G {image}
processors: 1
memory: 1073741824
```

I wonder if someone encounters the same case?

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220824/890440f7/attachment-0001.htm>

From sgehwolf at redhat.com  Wed Aug 24 11:53:09 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 24 Aug 2022 13:53:09 +0200
Subject: Might be a ContainerSupport issue on macOS Docker Engine
In-Reply-To: <CALqsiWUwQj14Ff-R__-VL=8mDHowegsCJrf4tDMfizug_6fbOw@mail.gmail.com>
References: <CALqsiWUwQj14Ff-R__-VL=8mDHowegsCJrf4tDMfizug_6fbOw@mail.gmail.com>
Message-ID: <6ed7cabede35b93a5a9467b763b8a7692db06441.camel@redhat.com>

Hi,

The code in JDK 17 and JDK 8 isn't 100% aligned. So it's hard to say.
Please check which cgroups version is in use. Best to try with JDK 17
using '-XshowSettings:system' switch when spawning the app. That should
give some clues.

For example the output here looks like this (note the 'Provider:'
section):

Operating System Metrics:
    Provider: cgroupv1
    Effective CPU Count: 8
    CPU Period: 100000us
    CPU Quota: -1
    CPU Shares: -1
    List of Processors, 8 total: 
    0 1 2 3 4 5 6 7 
    List of Effective Processors, 8 total: 
    0 1 2 3 4 5 6 7 
    List of Memory Nodes, 1 total: 
    0 
    List of Available Memory Nodes, 1 total: 
    0 
    Memory Limit: Unlimited
    Memory Soft Limit: Unlimited
    Memory & Swap Limit: Unlimited
    Maximum Processes Limit: Unlimited

openjdk version "17.0.4" 2022-07-19
OpenJDK Runtime Environment (Red_Hat-17.0.4.0.8-1.fc36) (build 17.0.4+8)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.4.0.8-1.fc36) (build 17.0.4+8, mixed mode, sharing)

I'd expect for the affected system to be a cgroups v2 system, which
isn't supported in JDK 8u (yet). See:
https://bugs.openjdk.org/browse/JDK-8230305


On Wed, 2022-08-24 at 18:52 +0900, Plenty Su wrote:
> 
> I checked the cgroup files in the container. For example, 
> ```
> # cat /sys/fs/cgroup/memory.max
> 1073741824
> ```

memory.max is a cgroups v2 interface file. That suggests whatever macOS
Docker Engine does, it uses some Linux with cgv2 underneath.

HTH.

Thanks,
Severin


From duke at openjdk.org  Wed Aug 24 12:22:44 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Wed, 24 Aug 2022 12:22:44 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
Message-ID: <STxrYFv7Yyqn2Pfsq4Au-vHwPe2KAo1AWhQ-7GCIGzo=.affb3b49-3a2c-4fd4-a81c-cc9bab51dec1@github.com>

On Mon, 22 Aug 2022 07:53:10 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8049228: Update copyright date"
>   
>   This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.

> /summary 8049228: Improve multithreaded scalability of InetAddress cache 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
> 
> Reviewed-by: phh, andrew

I intended to update summary of this PR with this `summary` command before integrate, but it looks like not working as expected. And now jcheck failed with this error message:

Exception occurred during jcheck - the operation will be retried

Incorrectly formatted commit message: 8049228: Improve multithreaded scalability of InetAddress cache
7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate

8049228: Improve multithreaded scalability of InetAddress cache
7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate

Reviewed-by: phh, andrew

Reviewed-by: phh, Andrew

Is this my operation fault or jcheck bug? Could anybody help to solve this problem. Thanks a lot.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From sgehwolf at openjdk.org  Wed Aug 24 12:22:45 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 24 Aug 2022 12:22:45 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <STxrYFv7Yyqn2Pfsq4Au-vHwPe2KAo1AWhQ-7GCIGzo=.affb3b49-3a2c-4fd4-a81c-cc9bab51dec1@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
 <STxrYFv7Yyqn2Pfsq4Au-vHwPe2KAo1AWhQ-7GCIGzo=.affb3b49-3a2c-4fd4-a81c-cc9bab51dec1@github.com>
Message-ID: <r4jMv4Zx9hW3JU4VkR-rLwM0ZnbfLB_sPDDzKIbWcTU=.90b472cc-91db-4d6b-9428-b29d789644f5@github.com>

On Wed, 24 Aug 2022 02:37:23 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

> > /summary 8049228: Improve multithreaded scalability of InetAddress cache 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
> > Reviewed-by: phh, andrew
> 
> I intended to update summary of this PR with this `summary` command before integrate, but it looks like not working as expected. And now jcheck failed with this error message:
> 
> ```
> Exception occurred during jcheck - the operation will be retried
> 
> Incorrectly formatted commit message: 8049228: Improve multithreaded scalability of InetAddress cache
> 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
> 
> 8049228: Improve multithreaded scalability of InetAddress cache
> 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
> 
> Reviewed-by: phh, andrew
> 
> Reviewed-by: phh, Andrew
> ```
> 
> Is this my operation fault or jcheck bug? Could anybody help to solve this problem. Thanks a lot.

Don't set the commit message like that using `/summary`. What you want is `/issue add`. `Reviewed-by` fields are set by the bots based on the approving reviewers, so it's no surprise it didn't like that. That being said, for all intents an purposes what the bot suggested in https://github.com/openjdk/jdk8u-dev/pull/70#issuecomment-1188121988 pretty much matches what you want, no? What is it that you want to achieve exactly?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From sgehwolf at openjdk.org  Wed Aug 24 12:29:42 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 24 Aug 2022 12:29:42 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <STxrYFv7Yyqn2Pfsq4Au-vHwPe2KAo1AWhQ-7GCIGzo=.affb3b49-3a2c-4fd4-a81c-cc9bab51dec1@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
 <STxrYFv7Yyqn2Pfsq4Au-vHwPe2KAo1AWhQ-7GCIGzo=.affb3b49-3a2c-4fd4-a81c-cc9bab51dec1@github.com>
Message-ID: <A6pKVHyJ7J7ueoOGxqnTxVA1fGOwwg7VuE5biWKrLgc=.c4889cec-2072-49d0-bead-79799acfb737@github.com>

On Wed, 24 Aug 2022 02:37:23 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "8049228: Update copyright date"
>>   
>>   This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.
>
>> /summary 8049228: Improve multithreaded scalability of InetAddress cache 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
>> 
>> Reviewed-by: phh, andrew
> 
> I intended to update summary of this PR with this `summary` command before integrate, but it looks like not working as expected. And now jcheck failed with this error message:
> 
> Exception occurred during jcheck - the operation will be retried
> 
> Incorrectly formatted commit message: 8049228: Improve multithreaded scalability of InetAddress cache
> 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
> 
> 8049228: Improve multithreaded scalability of InetAddress cache
> 7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate
> 
> Reviewed-by: phh, andrew
> 
> Reviewed-by: phh, Andrew
> 
> Is this my operation fault or jcheck bug? Could anybody help to solve this problem. Thanks a lot.

@lusou-zhangquan It looks like that has broken the bots. Best to file a SKARA issue here: https://bugs.openjdk.org/browse/SKARA if you can't create issues, I can help with that.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Wed Aug 24 17:37:42 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 24 Aug 2022 17:37:42 GMT
Subject: [jdk8u-dev] Integrated: 8039955: [TESTBUG]
 jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError: expected
 [d:1234.000000] but found [d:1234,000000]
In-Reply-To: <ehWCRWRqslE-H-HTVP3Pt2-1LfoXxu5c7Ijlvam4m5A=.17699524-f6b1-4187-b5f1-0588418ea263@github.com>
References: <ehWCRWRqslE-H-HTVP3Pt2-1LfoXxu5c7Ijlvam4m5A=.17699524-f6b1-4187-b5f1-0588418ea263@github.com>
Message-ID: <Iivca9NXFvSimyZxtGICp7POYpt0IgKBpCFp5tcwU4Q=.e07b9df1-f016-4da0-8e55-8e49e02e6830@github.com>

On Tue, 23 Aug 2022 15:07:14 GMT, zzambers <duke at openjdk.org> wrote:

> This is backport of JDK-8039955 [1]. 
> 
> Two tests from jdk_tier1 are sensitive to locale of test machine (expect "." as decimal separator), which causes failures when running on some locales, such as czech (which uses "," as decimal separator ). This backport fixes this issue.
> 
> Patch with changes applies cleanly:
> 
> git apply 0001-8039955-TESTBUG-jdk-lambda-LambdaTranslationTest1-ja.patch
> 
> 
> Tested locally using czech locale, 2 tests in jdk_tier1 get fixed, no regressions.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8039955

This pull request has now been integrated.

Changeset: 41c7d2d7
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/41c7d2d74d328f1b75a8271fbdc834679edbbae6
Stats:     10 lines in 2 files changed: 4 ins; 0 del; 6 mod

8039955: [TESTBUG] jdk/lambda/LambdaTranslationTest1 - java.lang.AssertionError: expected [d:1234.000000] but found [d:1234,000000]

Backport-of: 3555038f51fbf7f908b7346a8329f4da44a7cde5

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

PR: https://git.openjdk.org/jdk8u-dev/pull/112

From duke at openjdk.org  Wed Aug 24 17:48:37 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 24 Aug 2022 17:48:37 GMT
Subject: [jdk8u-dev] Integrated: 8232950: SUNPKCS11 Provider incorrectly check
 key length for PSS Signatures.
In-Reply-To: <qI0L-K1aLjAjRfiPNmQY2CBwAXNmNw6_Wtxotj4o7Yc=.b8f4e3b7-a33c-4f98-829e-5b72fe30e3dc@github.com>
References: <qI0L-K1aLjAjRfiPNmQY2CBwAXNmNw6_Wtxotj4o7Yc=.b8f4e3b7-a33c-4f98-829e-5b72fe30e3dc@github.com>
Message-ID: <y6BjkTa6l8aBoNuwdUR_B-QWGZ90Jl8fPYPPYF5fYEA=.45ded42d-e49b-4124-9797-737c861c373a@github.com>

On Mon, 22 Aug 2022 19:06:23 GMT, zzambers <duke at openjdk.org> wrote:

> This is backport of JDK-8183107 [1]. When dealt with different paths on jdk8, patch extracted from jdk project applied cleanly.
> 
> git apply -p3 --dir=jdk/src 0001-8232950-SUNPKCS11-Provider-incorrectly-check-key-len.patch
> 
> Tested locally, no regressions in jdk_security tests.
> 
> [1] https://bugs.openjdk.org/browse/JDK-8232950

This pull request has now been integrated.

Changeset: e3251a22
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/e3251a2293f2eeb286e3075269b1d132acae22bf
Stats:     10 lines in 1 file changed: 3 ins; 3 del; 4 mod

8232950: SUNPKCS11 Provider incorrectly check key length for PSS Signatures.

Fixed to treat the queried key size values as bits instead of bytes

Reviewed-by: andrew
Backport-of: f14e3a60b26f0488da26abf3ae6c0521d5f616e5

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

PR: https://git.openjdk.org/jdk8u-dev/pull/109

From andrew at openjdk.org  Wed Aug 24 17:53:50 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 24 Aug 2022 17:53:50 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
Message-ID: <0XTN798ArDsioZxmsnlmSmCJlKlV5sC0wdiyfhawZy4=.80a14adf-88bb-4e95-b2df-3e767dc82170@github.com>

On Mon, 22 Aug 2022 07:53:10 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8049228: Update copyright date"
>   
>   This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.

It's probably simpler to just open a fresh PR.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From andrew at openjdk.org  Wed Aug 24 18:23:48 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 24 Aug 2022 18:23:48 GMT
Subject: [jdk8u-dev] RFR: 8285497: Add system property for Java SE
 specification maintenance version [v2]
In-Reply-To: <glDR8CDHfpCJjTmlMp6k92SGOtK6xa4oQcypTJxRrdw=.e3ff4595-2263-45b6-8329-e93d0b4acf9e@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
 <glDR8CDHfpCJjTmlMp6k92SGOtK6xa4oQcypTJxRrdw=.e3ff4595-2263-45b6-8329-e93d0b4acf9e@github.com>
Message-ID: <C_0Efu_Rv-gMi6fRRUygqRDBhrZgOFmSOMDXD6Bdg8c=.517a3708-9709-480b-bfc1-edb558ed8c8b@github.com>

On Mon, 22 Aug 2022 20:15:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Same diff as used in the JDK 8u RI update.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8285497
>  - Update copyright per code review comment.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

Updated patch looks good

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From andrew at openjdk.org  Wed Aug 24 18:28:40 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 24 Aug 2022 18:28:40 GMT
Subject: [jdk8u-dev] RFR: 8285497: Add system property for Java SE
 specification maintenance version [v2]
In-Reply-To: <7b6YchfMPDm_2wVRVxvogOjI-4ysUyaedFX9ZOthkTY=.8646becc-5542-430f-98e7-26d5b64841ff@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
 <f26M-oLulINsFJTSBmh1V9VO_4QgseXwHwwvEE2L3-0=.da0c0e3c-4c81-402a-be69-fe1cbaaf5ddc@github.com>
 <7b6YchfMPDm_2wVRVxvogOjI-4ysUyaedFX9ZOthkTY=.8646becc-5542-430f-98e7-26d5b64841ff@github.com>
Message-ID: <a7OBQ-N2TF1Q0JGiclDMmT2qwFK9SIaDLo2WlAXWTjc=.9cb39f66-ad0f-4c47-8c64-f1c86f2f70e8@github.com>

On Mon, 22 Aug 2022 20:35:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Change looks good and nearly the same as that in 8u42. However, one copyright header change was missed in `System.c`, presumably due to 8189761 already having bumped it to 2019. Can we fix this please?
> > Also, please change the title to "Backport 31a63ba5f255e09349b3842984ac5bb3ad8e6c0b" so SKARA correctly identifies this as a backport.
> 
> I've done as you've requested.
> 
> > See https://wiki.openjdk.org/display/SKARA/Backports
> 
> Yes, I am familiar with the basic operation of Skara. I don't see anything on the referenced page that requires use of a Skara Backport PR when doing a backport. The impetus for adding the backport feature to Skara, a feature enabled several months after JDK mainline switched to Skara, was to reduce the overhead of the common case of backport a fix to an earlier release where few to no changes are needed.
> 
> Before sending out this PR, I looked for, but did not find, documentation for what procedures 8u wanted to use for a situation like this.

Thanks for the feedback. I can improve the documentation on the 8u wiki to make this clearer. If Skara doesn't recognise the issue as a backport, it doesn't seem to like the referenced bug. Prior to you updating the title, it was issuing a warning that the bug was not open (as we'd expect), so I'm not sure it would correctly resolve it with a backport issue when pushed. Using the `"Backport <x>"` nomenclature just seems to make things work well in all cases.

Thanks for making the changes. I've approved this for 8u now so it's good to integrate.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From andrew at openjdk.org  Wed Aug 24 18:28:41 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 24 Aug 2022 18:28:41 GMT
Subject: [jdk8u-dev] RFR: 8285497: Add system property for Java SE
 specification maintenance version [v2]
In-Reply-To: <glDR8CDHfpCJjTmlMp6k92SGOtK6xa4oQcypTJxRrdw=.e3ff4595-2263-45b6-8329-e93d0b4acf9e@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
 <glDR8CDHfpCJjTmlMp6k92SGOtK6xa4oQcypTJxRrdw=.e3ff4595-2263-45b6-8329-e93d0b4acf9e@github.com>
Message-ID: <v0Fs8ZzztE0KfpFbN_T3tsZHATAc5_XHGk0c4OQc9zs=.fb4fd53c-6bee-4949-b3db-52a38d318c48@github.com>

On Mon, 22 Aug 2022 20:15:48 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Same diff as used in the JDK 8u RI update.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8285497
>  - Update copyright per code review comment.
>  - JDK-8285497: Add system property for Java SE specification maintenance version

Also, it's not necessary for this PR, but you might want to enable GitHub Actions on your 8u fork for any future PRs.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From darcy at openjdk.org  Wed Aug 24 19:39:41 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Aug 2022 19:39:41 GMT
Subject: [jdk8u-dev] Integrated: 8285497: Add system property for Java SE
 specification maintenance version
In-Reply-To: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
Message-ID: <W2JET1LJ3MhScS30BI4ZTpti38kXashBeYUO1rmFLbU=.95993b61-2c05-4f0c-8497-b8dbe59d361a@github.com>

On Thu, 11 Aug 2022 20:35:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Same diff as used in the JDK 8u RI update.

This pull request has now been integrated.

Changeset: d0ad2422
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/d0ad2422d172bc436dad619adf78ce51285c2388
Stats:     23 lines in 4 files changed: 20 ins; 0 del; 3 mod

8285497: Add system property for Java SE specification maintenance version

Reviewed-by: dholmes, iris, mchung, andrew
Backport-of: 31a63ba5f255e09349b3842984ac5bb3ad8e6c0b

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

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From darcy at openjdk.org  Wed Aug 24 21:46:27 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 Aug 2022 21:46:27 GMT
Subject: [jdk8u-dev] RFR: 8285497: Add system property for Java SE
 specification maintenance version [v2]
In-Reply-To: <a7OBQ-N2TF1Q0JGiclDMmT2qwFK9SIaDLo2WlAXWTjc=.9cb39f66-ad0f-4c47-8c64-f1c86f2f70e8@github.com>
References: <R2KesUYbHmvg9-3hlUm_zSntktWb4twYpn4HKVPD-NM=.5d02acb8-8822-4900-b612-ffc50810acaf@github.com>
 <f26M-oLulINsFJTSBmh1V9VO_4QgseXwHwwvEE2L3-0=.da0c0e3c-4c81-402a-be69-fe1cbaaf5ddc@github.com>
 <7b6YchfMPDm_2wVRVxvogOjI-4ysUyaedFX9ZOthkTY=.8646becc-5542-430f-98e7-26d5b64841ff@github.com>
 <a7OBQ-N2TF1Q0JGiclDMmT2qwFK9SIaDLo2WlAXWTjc=.9cb39f66-ad0f-4c47-8c64-f1c86f2f70e8@github.com>
Message-ID: <W9k7T_djaNy1k8C6l1aWHNpfJVRper3xjlat8RBENfk=.3dae6504-13f7-432a-abdd-89cf1a8e6132@github.com>

On Wed, 24 Aug 2022 18:23:33 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> > > Change looks good and nearly the same as that in 8u42. However, one copyright header change was missed in `System.c`, presumably due to 8189761 already having bumped it to 2019. Can we fix this please?
> > > Also, please change the title to "Backport 31a63ba5f255e09349b3842984ac5bb3ad8e6c0b" so SKARA correctly identifies this as a backport.
> > 
> > 
> > I've done as you've requested.
> > > See https://wiki.openjdk.org/display/SKARA/Backports
> > 
> > 
> > Yes, I am familiar with the basic operation of Skara. I don't see anything on the referenced page that requires use of a Skara Backport PR when doing a backport. The impetus for adding the backport feature to Skara, a feature enabled several months after JDK mainline switched to Skara, was to reduce the overhead of the common case of backport a fix to an earlier release where few to no changes are needed.
> > Before sending out this PR, I looked for, but did not find, documentation for what procedures 8u wanted to use for a situation like this.
> 
> Thanks for the feedback. I can improve the documentation on the 8u wiki to make this  #clearer. If Skara doesn't recognise the issue as a backport, it doesn't seem to like the referenced bug. Prior to you updating the title, it was issuing a warning that the bug was not open (as we'd expect), so I'm not sure it would correctly resolve it with a backport issue when pushed. Using the `"Backport <x>"` nomenclature just seems to make things work well in all cases.

I also noticed the previous message about "bug not being open" before the PR was changed to a backport. I assume that is a opportunity-for-improvement for the bots to say "we noticed we'll need to create a new backport record if this gets pushed," which the bots should certainly be able to do.

My general advice on using JBS includes "don't create a backport record before it is needed." I didn't try to create an 8-pool record to see if it would making the warning go away since I assumed the right thing would happen on the push with respect to JBS.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/100

From duke at openjdk.org  Thu Aug 25 02:34:44 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Thu, 25 Aug 2022 02:34:44 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v5]
In-Reply-To: <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <gVCeg_AkR0KSoW_YlAfPM_TYK7OFb1YIvAQBzKbOoQ4=.e9d3eacd-c1d5-4136-9d91-f071b4d183d4@github.com>
Message-ID: <XsrCYNQNILYMe_VKtjrdmCi1d4SgwPouxz33TW9JOFY=.91378b5e-f937-4902-8d3c-04030e851b87@github.com>

On Mon, 22 Aug 2022 07:53:10 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "8049228: Update copyright date"
>   
>   This reverts commit 68cb8d33f1172e6d50c28ef054d0a9b061770412.

Close this PR and open a fresh one because of broken bots.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Thu Aug 25 02:34:45 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Thu, 25 Aug 2022 02:34:45 GMT
Subject: [jdk8u-dev] Withdrawn: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
Message-ID: <_H0dTe-t4CgLxnjDGyM6Ffp5EvVpzq_68GLCFSxc1f4=.27163cc4-b7d8-4be6-857e-2d8bf5fa288f@github.com>

On Wed, 1 Jun 2022 03:41:58 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
> 
> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Thu Aug 25 02:40:29 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Thu, 25 Aug 2022 02:40:29 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache
Message-ID: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>

Refresh https://github.com/openjdk/jdk8u-dev/pull/70

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

Commit messages:
 - 8049228: Improve multithreaded scalability of InetAddress cache

Changes: https://git.openjdk.org/jdk8u-dev/pull/113/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8049228
  Stats: 484 lines in 2 files changed: 133 ins; 235 del; 116 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/113.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/113/head:pull/113

PR: https://git.openjdk.org/jdk8u-dev/pull/113

From duke at openjdk.org  Thu Aug 25 07:55:06 2022
From: duke at openjdk.org (psoujany)
Date: Thu, 25 Aug 2022 07:55:06 GMT
Subject: [jdk8u-dev] RFR: 8209052: Low contrast in
 docs/api/constant-values.html
Message-ID: <yztAKtjMJ_YAgyt7quuYRCdTunoOWTBYhJKtxHKlRWo=.35a740b2-2470-4c22-94e9-87ebaa4f8639@github.com>

Backport e2eab3c1b7d55860e705ae6f924a2a3976f76f48 to JDK8.
Openjdk bug: https://bugs.openjdk.org/browse/JDK-8209052

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

Commit messages:
 - Backport e2eab3c1b7d55860e705ae6f924a2a3976f76f48

Changes: https://git.openjdk.org/jdk8u-dev/pull/114/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=114&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8209052
  Stats: 428 lines in 1 file changed: 350 ins; 14 del; 64 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/114.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/114/head:pull/114

PR: https://git.openjdk.org/jdk8u-dev/pull/114

From plenty.su at gmail.com  Thu Aug 25 09:22:17 2022
From: plenty.su at gmail.com (Plenty Su)
Date: Thu, 25 Aug 2022 18:22:17 +0900
Subject: Might be a ContainerSupport issue on macOS Docker Engine
In-Reply-To: <6ed7cabede35b93a5a9467b763b8a7692db06441.camel@redhat.com>
References: <CALqsiWUwQj14Ff-R__-VL=8mDHowegsCJrf4tDMfizug_6fbOw@mail.gmail.com>
 <6ed7cabede35b93a5a9467b763b8a7692db06441.camel@redhat.com>
Message-ID: <CALqsiWWErKu2yGS_g73zr=0ayziqdDr2XiMFsQRK1MNy8-BYpw@mail.gmail.com>

Hi Severin,

Thank you for the answer.

I tested the command that you advised on macOS Docker Engine.
```
> docker run --rm -it --cpus 1 -m 1G {image based on OpenJDK 17} java
-XshowSettings:system -version
Operating System Metrics:
    Provider: cgroupv2
    Effective CPU Count: 1
    CPU Period: 100000us
    CPU Quota: 100000us
    CPU Shares: -1
    List of Processors: N/A
    List of Effective Processors, 4 total:
    0 1 2 3
    List of Memory Nodes: N/A
    List of Available Memory Nodes, 1 total:
    0
    Memory Limit: 1.00G
    Memory Soft Limit: 0.00K
    Memory & Swap Limit: 2.00G

openjdk version "17-ea" 2021-09-14
OpenJDK Runtime Environment (build 17-ea+14)
OpenJDK 64-Bit Server VM (build 17-ea+14, mixed mode, sharing)
```

As you guessed, macOS Docker Engine does use cgroups v2 to limit the
container's resources.
Then, I think I should just use OpenJDK 17 as the runtime solution.

Thank you for your help!


On Wed, Aug 24, 2022 at 8:53 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> Hi,
>
> The code in JDK 17 and JDK 8 isn't 100% aligned. So it's hard to say.
> Please check which cgroups version is in use. Best to try with JDK 17
> using '-XshowSettings:system' switch when spawning the app. That should
> give some clues.
>
> For example the output here looks like this (note the 'Provider:'
> section):
>
> Operating System Metrics:
>     Provider: cgroupv1
>     Effective CPU Count: 8
>     CPU Period: 100000us
>     CPU Quota: -1
>     CPU Shares: -1
>     List of Processors, 8 total:
>     0 1 2 3 4 5 6 7
>     List of Effective Processors, 8 total:
>     0 1 2 3 4 5 6 7
>     List of Memory Nodes, 1 total:
>     0
>     List of Available Memory Nodes, 1 total:
>     0
>     Memory Limit: Unlimited
>     Memory Soft Limit: Unlimited
>     Memory & Swap Limit: Unlimited
>     Maximum Processes Limit: Unlimited
>
> openjdk version "17.0.4" 2022-07-19
> OpenJDK Runtime Environment (Red_Hat-17.0.4.0.8-1.fc36) (build 17.0.4+8)
> OpenJDK 64-Bit Server VM (Red_Hat-17.0.4.0.8-1.fc36) (build 17.0.4+8,
> mixed mode, sharing)
>
> I'd expect for the affected system to be a cgroups v2 system, which
> isn't supported in JDK 8u (yet). See:
> https://bugs.openjdk.org/browse/JDK-8230305
>
>
> On Wed, 2022-08-24 at 18:52 +0900, Plenty Su wrote:
> >
> > I checked the cgroup files in the container. For example,
> > ```
> > # cat /sys/fs/cgroup/memory.max
> > 1073741824
> > ```
>
> memory.max is a cgroups v2 interface file. That suggests whatever macOS
> Docker Engine does, it uses some Linux with cgv2 underneath.
>
> HTH.
>
> Thanks,
> Severin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220825/fdf73c23/attachment.htm>

From andrew at openjdk.org  Thu Aug 25 16:23:46 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 25 Aug 2022 16:23:46 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>
References: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>
Message-ID: <YHclkPunXbxV3AxIZXl3odl6zLNAiAe0gdJEAfFNbRg=.e5821305-af3b-4259-bf82-67a2b25b1ede@github.com>

On Thu, 25 Aug 2022 02:31:45 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

> Refresh https://github.com/openjdk/jdk8u-dev/pull/70

Patch is identical to the one I reviewed for #70 
Bug is already approved so let's just do /integrate and get this in :-)

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/113

From phh at openjdk.org  Thu Aug 25 18:43:00 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 25 Aug 2022 18:43:00 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>
References: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>
Message-ID: <FFOjzTt37Xwj2ncUnAIAdXft2r6Th_0CjKPytRJw-xA=.43202382-93b2-4efe-be2e-d63ee2b91487@github.com>

On Thu, 25 Aug 2022 02:31:45 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

> Refresh https://github.com/openjdk/jdk8u-dev/pull/70

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/113

From mbalao at openjdk.org  Fri Aug 26 01:48:15 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 Aug 2022 01:48:15 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1
In-Reply-To: <eV0MkvSJITpAY1oYNhKW0C0cctrHhTBAhJzj4x1h8rU=.11683e51-abe4-46a2-86e8-343868886cee@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
 <eV0MkvSJITpAY1oYNhKW0C0cctrHhTBAhJzj4x1h8rU=.11683e51-abe4-46a2-86e8-343868886cee@github.com>
Message-ID: <Oro9oUztPKIHKaHBw3rfnvQexMNGCXsbHM2EQf5xSa4=.6c76b398-1c60-4a43-87fa-93abfd05a5c9@github.com>

On Tue, 23 Aug 2022 18:28:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hi,
>> 
>> I'd like to propose the backport of the JDK-8195607 fix to 8u because this release is affected by this issue. Given that the legacy NSS DB has been deprecated for a long time and it's increasingly replaced by SQLite DBs, the chances that JDK-8 builds hit this problem are now higher.
>> 
>> The 11u backport applies cleanly, once paths are fixed.
>> 
>> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.
>> 
>> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as
  when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
>> 
>> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
>> 
>> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://github.com/openjdk/jdk11u/blob/master/test/jdk/TEST.ROOT#L61
>> [2] - https://github.com/openjdk/jtreg/blob/jtreg-6.2%2B1/src/share/classes/com/sun/javatest/regtest/config/Locations.java#L174
>
>> The 11u backport applies cleanly, once paths are fixed.
> 
> Yes, that seems to be the case if https://github.com/openjdk/jdk8u-dev/pull/106/commits/73173863ab9da7ee2ec080401180475bf7ee22e1 is to be looked at on its own.
>  
>> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.
> 
> OK.
> 
>> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as
  when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
>> 
>> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
>> 
>> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.
> 
> This seems strange, wouldn't a jtreg version `> 4.2 b08` not run into this problem? I.e. if I run with jtreg 5 (oldest version I have here), I wouldn't see this issue? If so I'm not sure this is worth adding https://github.com/openjdk/jdk8u-dev/pull/106/commits/22c1df05d2ab51a400ebdc69566e84fdaf32efec to this backport. It's not in head either. So at the very least this should be an 8u-only bug. But if that's only happening with jtreg 4, I'd say this is not worth fixing at all (or perhaps add jtreg 5 as a minimal version. Everyone should be on newer versions these days anyway.

Hi @jerboaa ,

Thanks for your review.

Let me clarify the jtreg issue. It's not that the test fails because it's run with an old jtreg. In fact, I'm running with jtreg 5 and it's failing. The problem is that the TEST.ROOT in JDK-8 does not set a "minimum jtreg required" (probably because it's a newer feature than JDK-8). In these cases, jtreg takes a conservative approach and does not split the text execution into different directories. Setting a "minimum jtreg required" in JDK-8 would be a high risk as we don't know the impact of other tests in newer or older jtreg releases. Having this test broken would be a regression. I hope we can have this fix, or you might come up with a different one. Let me know if that helps for a better understanding.

Martin.-

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

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From aph at openjdk.org  Fri Aug 26 08:47:18 2022
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 26 Aug 2022 08:47:18 GMT
Subject: [jdk8u-dev] Withdrawn: 8285802: AArch64: Consistently handle offsets
 in MacroAssembler as 64-bit quantities
In-Reply-To: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
References: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>
Message-ID: <rwVh7w1JVPtfWS3jv_8gt5rMmaO2OJli9eJuWBoZpMY=.14458792-412e-4b4f-8c26-ace51749a7f3@github.com>

On Fri, 29 Apr 2022 17:40:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This is a backport of [8285802](https://github.com/openjdk/jdk/commit/df4d5cf5f53c1451487e6301d31c196fac029f7a) from the openjdk/jdk repository. It's almost clean, but upstream mainline has a few
> cleanups of integer type handling, so there is some additional backporting risk.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/50

From sgehwolf at openjdk.org  Fri Aug 26 09:07:58 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 26 Aug 2022 09:07:58 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1
In-Reply-To: <Oro9oUztPKIHKaHBw3rfnvQexMNGCXsbHM2EQf5xSa4=.6c76b398-1c60-4a43-87fa-93abfd05a5c9@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
 <eV0MkvSJITpAY1oYNhKW0C0cctrHhTBAhJzj4x1h8rU=.11683e51-abe4-46a2-86e8-343868886cee@github.com>
 <Oro9oUztPKIHKaHBw3rfnvQexMNGCXsbHM2EQf5xSa4=.6c76b398-1c60-4a43-87fa-93abfd05a5c9@github.com>
Message-ID: <Lr6a-mD67L3tEvN_YrnOzIjMe1GEGH1yDbxeSipsI8o=.d50f714f-04b9-4c79-abfb-57481985e353@github.com>

On Fri, 26 Aug 2022 01:44:14 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Let me clarify the jtreg issue. It's not that the test fails because it's run with an old jtreg. In fact, I'm running with jtreg 5 and it's failing. The problem is that the TEST.ROOT in JDK-8 does not set a "minimum jtreg required" (probably because it's a newer feature than JDK-8). In these cases, jtreg takes a conservative approach and does not split the text execution into different directories. Setting a "minimum jtreg required" in JDK-8 would be a high risk as we don't know the impact of other tests in newer or older jtreg releases. Having this test broken would be a regression. I hope we can have this fix, or you might come up with a different one. Let me know if that helps for a better understanding.

Thanks for the clarification. I'm fine with your approach, but https://github.com/openjdk/jdk8u-dev/commit/22c1df05d2ab51a400ebdc69566e84fdaf32efec should go in as a separate 8u-specific patch. Or we could take this as an opportunity to require jtreg 5+ (which should be fine IMHO, I don't agree it's a high risk change). Either way this should be a separate discussion with a separate bug.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From duke at openjdk.org  Fri Aug 26 12:30:08 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Fri, 26 Aug 2022 12:30:08 GMT
Subject: [jdk8u-dev] Integrated: 8049228: Improve multithreaded scalability of
 InetAddress cache
In-Reply-To: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>
References: <PpWIPk_uCUSIG_yK6JGYRCJBBkhMI3F78GirhoQfjRY=.f75e9770-a2b3-4c50-83ca-f211fa2919e7@github.com>
Message-ID: <x0HH5nEcq6nL9Fp1UTBV3N2u2fS0vZNr2oUHlEhBJvo=.46b6a8d9-d12b-45ac-b64a-866711b3b13f@github.com>

On Thu, 25 Aug 2022 02:31:45 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

> Refresh https://github.com/openjdk/jdk8u-dev/pull/70

This pull request has now been integrated.

Changeset: 22230588
Author:    Peter Levart <plevart at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/222305888bda3f0e225839d832cdf8983996a229
Stats:     484 lines in 2 files changed: 133 ins; 235 del; 116 mod

8049228: Improve multithreaded scalability of InetAddress cache
7186258: InetAddress$Cache should replace currentTimeMillis with nanoTime for more precise and accurate

Reviewed-by: andrew, phh
Backport-of: 250fbb065a789a303d692d698c9b69117bf6cd2c

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

PR: https://git.openjdk.org/jdk8u-dev/pull/113

From andrew at openjdk.org  Fri Aug 26 14:22:49 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 14:22:49 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size
 computations [v2]
In-Reply-To: <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
 <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@github.com>
Message-ID: <-_Iw8FSvNI5iWfFmDbwic6D-mZnXSZyCi2C9avbz0-I=.6bd88279-eb57-4bf4-a422-57a94959ff63@github.com>

On Thu, 30 Jun 2022 03:34:39 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix minimum stack size computations on AArch64.
>> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
>> Following test case worked correctly after patch.
>> Before patch:
>> $ java TLSStackOverflow
>> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
>> After patch:
>> $ java TLSStackOverflow
>> got expected stackoverflow, passed
>> 
>> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
>> $ cat TLSStackOverflow.java
>> 
>> import javax.net.ServerSocketFactory;
>> import javax.net.SocketFactory;
>> import javax.net.ssl.*;
>> import java.io.*;
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.net.Socket;
>> import java.security.KeyStore;
>> import java.security.KeyStoreException;
>> import java.security.NoSuchAlgorithmException;
>> import java.security.SecureRandom;
>> import java.security.cert.CertificateException;
>> import java.security.cert.X509Certificate;
>> 
>> public class TLSStackOverflow
>> {
>> 
>>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>>     private static final char[] passphrase = "changeit".toCharArray();
>>     private static final int port = 8447;
>> 
>>     private static KeyStore pfx = null;
>> 
>>     public static void doWrite(OutputStream out) throws Exception {
>>         out.write("hello".getBytes(), 0, 3);
>>         out.flush();
>>         doWrite(out);
>>     }
>> 
>>     public TLSStackOverflow()
>>     {}
>> 
>>     public static void main(String[] args) throws Exception
>>     {
>>         new Thread(() -> {
>>             try {
>>                 pfx = KeyStore.getInstance("PKCS12");
>>                 pfx.load(new FileInputStream(keystore), passphrase);
>>                 SSLContext ctx = SSLContext.getInstance("TLS");
>>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>>                 kmf.init(pfx, passphrase);
>>                 KeyManager[] kms = kmf.getKeyManagers();
>>                 ctx.init(kms, null, null);
>>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>>                 while (true)
>>                 {
>>                     Socket socket = null;
>>                     try
>>                     {
>>                         socket = serversocket.accept();
>> 
>>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>> 
>>                         byte[] buf = new byte[8192];
>>                         int len = in.read(buf);
>>                     }
>>                     catch (Exception e)
>>                     {
>>                         e.printStackTrace();
>>                     }
>>                     finally
>>                     {
>> //                        try
>> //                        {
>> //                            socket.close();
>> //                        }
>> //                        catch (Exception e) {
>> //                            e.printStackTrace();
>> //                        }
>>                     }
>>                 }
>>             } catch (Exception e) {
>>                 e.printStackTrace();
>>             }
>>         }).start();
>> 
>>         Thread.sleep(2000);
>> 
>>         new Thread(() -> {
>>             SSLSocket socket = null;
>>             try {
>>                 pfx = KeyStore.getInstance("PKCS12");
>>                 pfx.load(new FileInputStream(keystore), passphrase);
>>                 SSLContext ctx = SSLContext.getInstance("TLS");
>>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>>                 kmf.init(pfx, passphrase);
>>                 TrustAllManager[] trust = { new TrustAllManager() };
>>                 ctx.init(null, trust, null);
>>                 SocketFactory fact = ctx.getSocketFactory();
>>                 socket = (SSLSocket) fact.createSocket();
>>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>>                 socket.setTcpNoDelay(true);
>>                 socket.startHandshake();
>> 
>>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>> 
>>                 String s = "GET " + " HTTP/1.1\r\n";
>>                 s+= "Accept: */*\r\n";
>>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>>                 s+= "Connection: Close\r\n";
>>                 s+= "\r\n";
>>                 try {
>>                     doWrite(out);
>>                 } catch (StackOverflowError e) {
>>                     System.out.println("got expected stackoverflow, passed");
>>                     System.exit(0);
>>                 }
>> 
>>                 byte[] buf = new byte[8192];
>>                 int len = in.read(buf);
>>                 if (len == -1)
>>                 {
>>                     System.out.println("eof");
>>                     return;
>>                 }
>>                 System.out.println(new String(buf, 0, len));
>>             }
>>             catch (Exception e)
>>             {
>>                 e.printStackTrace();
>>             }
>>             finally
>>             {
>>                 try
>>                 {
>>                     socket.close();
>>                 }
>>                 catch (Exception e)
>>                 {}
>>             }
>> 
>>         }).start();
>> 
>>     }
>> 
>> }
>> 
>> 
>> class TrustAllManager implements X509TrustManager
>> {
>>     private X509Certificate[] issuers;
>> 
>>     public TrustAllManager()
>>     {
>>         this.issuers = new X509Certificate[0];
>>     }
>> 
>>     public X509Certificate[] getAcceptedIssuers()
>>     {
>>         return issuers ;
>>     }
>> 
>>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>>     {}
>> 
>>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>>     {}
>> }
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8173339
>  - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

I've approved this based on Andrew's review. Please reopen and integrate. Thanks.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/66

From andrew at openjdk.org  Fri Aug 26 14:23:19 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 14:23:19 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v2]
In-Reply-To: <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
 <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
Message-ID: <sRTo13m-Rj4XBAabM2hgPudv-9_fJVC-olY_hN_m3jk=.debb1641-93db-4cd5-a1d5-ce38c747a409@github.com>

On Thu, 30 Jun 2022 03:36:49 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix tests for OS with 64K page size.
>> Patch does not apply cleanly: 
>> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
>> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
>> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
>> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
>> 
>> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
>> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
>> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
>> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
>> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
>> and passes with the patch on Aarch64 with 64K page size.
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
>> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
>> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
>> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
>> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
>> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
>> [7] https://bugs.openjdk.java.net/browse/JDK-8173339
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch '8173339' into 8067941
>  - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

SKARA seems to be confused by the closure of #66 due to timeout, not integration. Please re-open that one so we can correctly integrate it as a dependency for this one.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From andrew at openjdk.org  Fri Aug 26 14:31:02 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 14:31:02 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size
 computations [v2]
In-Reply-To: <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
 <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@github.com>
Message-ID: <FerFXU1pL-fRZ2a1xS1WhP2vdwLIuyWVhlBF163oEmc=.6319c0b2-e4ee-43b2-bfe9-4c70317e312f@github.com>

On Thu, 30 Jun 2022 03:34:39 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix minimum stack size computations on AArch64.
>> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
>> Following test case worked correctly after patch.
>> Before patch:
>> $ java TLSStackOverflow
>> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
>> After patch:
>> $ java TLSStackOverflow
>> got expected stackoverflow, passed
>> 
>> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
>> $ cat TLSStackOverflow.java
>> 
>> import javax.net.ServerSocketFactory;
>> import javax.net.SocketFactory;
>> import javax.net.ssl.*;
>> import java.io.*;
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.net.Socket;
>> import java.security.KeyStore;
>> import java.security.KeyStoreException;
>> import java.security.NoSuchAlgorithmException;
>> import java.security.SecureRandom;
>> import java.security.cert.CertificateException;
>> import java.security.cert.X509Certificate;
>> 
>> public class TLSStackOverflow
>> {
>> 
>>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>>     private static final char[] passphrase = "changeit".toCharArray();
>>     private static final int port = 8447;
>> 
>>     private static KeyStore pfx = null;
>> 
>>     public static void doWrite(OutputStream out) throws Exception {
>>         out.write("hello".getBytes(), 0, 3);
>>         out.flush();
>>         doWrite(out);
>>     }
>> 
>>     public TLSStackOverflow()
>>     {}
>> 
>>     public static void main(String[] args) throws Exception
>>     {
>>         new Thread(() -> {
>>             try {
>>                 pfx = KeyStore.getInstance("PKCS12");
>>                 pfx.load(new FileInputStream(keystore), passphrase);
>>                 SSLContext ctx = SSLContext.getInstance("TLS");
>>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>>                 kmf.init(pfx, passphrase);
>>                 KeyManager[] kms = kmf.getKeyManagers();
>>                 ctx.init(kms, null, null);
>>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>>                 while (true)
>>                 {
>>                     Socket socket = null;
>>                     try
>>                     {
>>                         socket = serversocket.accept();
>> 
>>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>> 
>>                         byte[] buf = new byte[8192];
>>                         int len = in.read(buf);
>>                     }
>>                     catch (Exception e)
>>                     {
>>                         e.printStackTrace();
>>                     }
>>                     finally
>>                     {
>> //                        try
>> //                        {
>> //                            socket.close();
>> //                        }
>> //                        catch (Exception e) {
>> //                            e.printStackTrace();
>> //                        }
>>                     }
>>                 }
>>             } catch (Exception e) {
>>                 e.printStackTrace();
>>             }
>>         }).start();
>> 
>>         Thread.sleep(2000);
>> 
>>         new Thread(() -> {
>>             SSLSocket socket = null;
>>             try {
>>                 pfx = KeyStore.getInstance("PKCS12");
>>                 pfx.load(new FileInputStream(keystore), passphrase);
>>                 SSLContext ctx = SSLContext.getInstance("TLS");
>>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>>                 kmf.init(pfx, passphrase);
>>                 TrustAllManager[] trust = { new TrustAllManager() };
>>                 ctx.init(null, trust, null);
>>                 SocketFactory fact = ctx.getSocketFactory();
>>                 socket = (SSLSocket) fact.createSocket();
>>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>>                 socket.setTcpNoDelay(true);
>>                 socket.startHandshake();
>> 
>>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>> 
>>                 String s = "GET " + " HTTP/1.1\r\n";
>>                 s+= "Accept: */*\r\n";
>>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>>                 s+= "Connection: Close\r\n";
>>                 s+= "\r\n";
>>                 try {
>>                     doWrite(out);
>>                 } catch (StackOverflowError e) {
>>                     System.out.println("got expected stackoverflow, passed");
>>                     System.exit(0);
>>                 }
>> 
>>                 byte[] buf = new byte[8192];
>>                 int len = in.read(buf);
>>                 if (len == -1)
>>                 {
>>                     System.out.println("eof");
>>                     return;
>>                 }
>>                 System.out.println(new String(buf, 0, len));
>>             }
>>             catch (Exception e)
>>             {
>>                 e.printStackTrace();
>>             }
>>             finally
>>             {
>>                 try
>>                 {
>>                     socket.close();
>>                 }
>>                 catch (Exception e)
>>                 {}
>>             }
>> 
>>         }).start();
>> 
>>     }
>> 
>> }
>> 
>> 
>> class TrustAllManager implements X509TrustManager
>> {
>>     private X509Certificate[] issuers;
>> 
>>     public TrustAllManager()
>>     {
>>         this.issuers = new X509Certificate[0];
>>     }
>> 
>>     public X509Certificate[] getAcceptedIssuers()
>>     {
>>         return issuers ;
>>     }
>> 
>>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>>     {}
>> 
>>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>>     {}
>> }
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8173339
>  - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

Thanks for the quick turn-around!

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

PR: https://git.openjdk.org/jdk8u-dev/pull/66

From dongbohe at openjdk.org  Fri Aug 26 14:31:03 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Fri, 26 Aug 2022 14:31:03 GMT
Subject: [jdk8u-dev] Integrated: 8173339: AArch64: Fix minimum stack size
 computations
In-Reply-To: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
Message-ID: <oskMw8qSM263iQqU0OisN5_Sl8062wdTDoBfixfN-a8=.1a792338-7bda-48d2-9b8b-f71dbb7240a4@github.com>

On Mon, 30 May 2022 03:22:04 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix minimum stack size computations on AArch64.
> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
> 
> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
> Following test case worked correctly after patch.
> Before patch:
> $ java TLSStackOverflow
> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
> After patch:
> $ java TLSStackOverflow
> got expected stackoverflow, passed
> 
> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
> $ cat TLSStackOverflow.java
> 
> import javax.net.ServerSocketFactory;
> import javax.net.SocketFactory;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.net.Socket;
> import java.security.KeyStore;
> import java.security.KeyStoreException;
> import java.security.NoSuchAlgorithmException;
> import java.security.SecureRandom;
> import java.security.cert.CertificateException;
> import java.security.cert.X509Certificate;
> 
> public class TLSStackOverflow
> {
> 
>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>     private static final char[] passphrase = "changeit".toCharArray();
>     private static final int port = 8447;
> 
>     private static KeyStore pfx = null;
> 
>     public static void doWrite(OutputStream out) throws Exception {
>         out.write("hello".getBytes(), 0, 3);
>         out.flush();
>         doWrite(out);
>     }
> 
>     public TLSStackOverflow()
>     {}
> 
>     public static void main(String[] args) throws Exception
>     {
>         new Thread(() -> {
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 KeyManager[] kms = kmf.getKeyManagers();
>                 ctx.init(kms, null, null);
>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>                 while (true)
>                 {
>                     Socket socket = null;
>                     try
>                     {
>                         socket = serversocket.accept();
> 
>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                         byte[] buf = new byte[8192];
>                         int len = in.read(buf);
>                     }
>                     catch (Exception e)
>                     {
>                         e.printStackTrace();
>                     }
>                     finally
>                     {
> //                        try
> //                        {
> //                            socket.close();
> //                        }
> //                        catch (Exception e) {
> //                            e.printStackTrace();
> //                        }
>                     }
>                 }
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }).start();
> 
>         Thread.sleep(2000);
> 
>         new Thread(() -> {
>             SSLSocket socket = null;
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 TrustAllManager[] trust = { new TrustAllManager() };
>                 ctx.init(null, trust, null);
>                 SocketFactory fact = ctx.getSocketFactory();
>                 socket = (SSLSocket) fact.createSocket();
>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>                 socket.setTcpNoDelay(true);
>                 socket.startHandshake();
> 
>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                 String s = "GET " + " HTTP/1.1\r\n";
>                 s+= "Accept: */*\r\n";
>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>                 s+= "Connection: Close\r\n";
>                 s+= "\r\n";
>                 try {
>                     doWrite(out);
>                 } catch (StackOverflowError e) {
>                     System.out.println("got expected stackoverflow, passed");
>                     System.exit(0);
>                 }
> 
>                 byte[] buf = new byte[8192];
>                 int len = in.read(buf);
>                 if (len == -1)
>                 {
>                     System.out.println("eof");
>                     return;
>                 }
>                 System.out.println(new String(buf, 0, len));
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>             finally
>             {
>                 try
>                 {
>                     socket.close();
>                 }
>                 catch (Exception e)
>                 {}
>             }
> 
>         }).start();
> 
>     }
> 
> }
> 
> 
> class TrustAllManager implements X509TrustManager
> {
>     private X509Certificate[] issuers;
> 
>     public TrustAllManager()
>     {
>         this.issuers = new X509Certificate[0];
>     }
> 
>     public X509Certificate[] getAcceptedIssuers()
>     {
>         return issuers ;
>     }
> 
>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>     {}
> 
>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>     {}
> }

This pull request has now been integrated.

Changeset: de32daa3
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/de32daa3efba67db204e86c8ed4380603432b3c6
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8173339: AArch64: Fix minimum stack size computations

Reviewed-by: aph
Backport-of: 540ec375c30e973ceb1a944d5cc60cc8532e88ec

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

PR: https://git.openjdk.org/jdk8u-dev/pull/66

From dongbohe at openjdk.org  Fri Aug 26 14:34:09 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Fri, 26 Aug 2022 14:34:09 GMT
Subject: [jdk8u-dev] RFR: 8173339: AArch64: Fix minimum stack size
 computations [v2]
In-Reply-To: <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
 <4W0R9iGGasm7Hh6CiOuLR7wV6nVQstafZzabvhThm-s=.74ddc7a6-3d2e-4e57-8d37-82d150a8ece4@github.com>
Message-ID: <uilpH4hRKHOvDD6VNZz9A_oa7wpEetsH3D139r4Aqpk=.e45164c9-227f-41db-a7b7-49f62524b1f9@github.com>

On Thu, 30 Jun 2022 03:34:39 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix minimum stack size computations on AArch64.
>> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
>> Following test case worked correctly after patch.
>> Before patch:
>> $ java TLSStackOverflow
>> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
>> After patch:
>> $ java TLSStackOverflow
>> got expected stackoverflow, passed
>> 
>> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
>> $ cat TLSStackOverflow.java
>> 
>> import javax.net.ServerSocketFactory;
>> import javax.net.SocketFactory;
>> import javax.net.ssl.*;
>> import java.io.*;
>> import java.net.InetAddress;
>> import java.net.InetSocketAddress;
>> import java.net.Socket;
>> import java.security.KeyStore;
>> import java.security.KeyStoreException;
>> import java.security.NoSuchAlgorithmException;
>> import java.security.SecureRandom;
>> import java.security.cert.CertificateException;
>> import java.security.cert.X509Certificate;
>> 
>> public class TLSStackOverflow
>> {
>> 
>>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>>     private static final char[] passphrase = "changeit".toCharArray();
>>     private static final int port = 8447;
>> 
>>     private static KeyStore pfx = null;
>> 
>>     public static void doWrite(OutputStream out) throws Exception {
>>         out.write("hello".getBytes(), 0, 3);
>>         out.flush();
>>         doWrite(out);
>>     }
>> 
>>     public TLSStackOverflow()
>>     {}
>> 
>>     public static void main(String[] args) throws Exception
>>     {
>>         new Thread(() -> {
>>             try {
>>                 pfx = KeyStore.getInstance("PKCS12");
>>                 pfx.load(new FileInputStream(keystore), passphrase);
>>                 SSLContext ctx = SSLContext.getInstance("TLS");
>>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>>                 kmf.init(pfx, passphrase);
>>                 KeyManager[] kms = kmf.getKeyManagers();
>>                 ctx.init(kms, null, null);
>>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>>                 while (true)
>>                 {
>>                     Socket socket = null;
>>                     try
>>                     {
>>                         socket = serversocket.accept();
>> 
>>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>> 
>>                         byte[] buf = new byte[8192];
>>                         int len = in.read(buf);
>>                     }
>>                     catch (Exception e)
>>                     {
>>                         e.printStackTrace();
>>                     }
>>                     finally
>>                     {
>> //                        try
>> //                        {
>> //                            socket.close();
>> //                        }
>> //                        catch (Exception e) {
>> //                            e.printStackTrace();
>> //                        }
>>                     }
>>                 }
>>             } catch (Exception e) {
>>                 e.printStackTrace();
>>             }
>>         }).start();
>> 
>>         Thread.sleep(2000);
>> 
>>         new Thread(() -> {
>>             SSLSocket socket = null;
>>             try {
>>                 pfx = KeyStore.getInstance("PKCS12");
>>                 pfx.load(new FileInputStream(keystore), passphrase);
>>                 SSLContext ctx = SSLContext.getInstance("TLS");
>>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>>                 kmf.init(pfx, passphrase);
>>                 TrustAllManager[] trust = { new TrustAllManager() };
>>                 ctx.init(null, trust, null);
>>                 SocketFactory fact = ctx.getSocketFactory();
>>                 socket = (SSLSocket) fact.createSocket();
>>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>>                 socket.setTcpNoDelay(true);
>>                 socket.startHandshake();
>> 
>>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
>> 
>>                 String s = "GET " + " HTTP/1.1\r\n";
>>                 s+= "Accept: */*\r\n";
>>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>>                 s+= "Connection: Close\r\n";
>>                 s+= "\r\n";
>>                 try {
>>                     doWrite(out);
>>                 } catch (StackOverflowError e) {
>>                     System.out.println("got expected stackoverflow, passed");
>>                     System.exit(0);
>>                 }
>> 
>>                 byte[] buf = new byte[8192];
>>                 int len = in.read(buf);
>>                 if (len == -1)
>>                 {
>>                     System.out.println("eof");
>>                     return;
>>                 }
>>                 System.out.println(new String(buf, 0, len));
>>             }
>>             catch (Exception e)
>>             {
>>                 e.printStackTrace();
>>             }
>>             finally
>>             {
>>                 try
>>                 {
>>                     socket.close();
>>                 }
>>                 catch (Exception e)
>>                 {}
>>             }
>> 
>>         }).start();
>> 
>>     }
>> 
>> }
>> 
>> 
>> class TrustAllManager implements X509TrustManager
>> {
>>     private X509Certificate[] issuers;
>> 
>>     public TrustAllManager()
>>     {
>>         this.issuers = new X509Certificate[0];
>>     }
>> 
>>     public X509Certificate[] getAcceptedIssuers()
>>     {
>>         return issuers ;
>>     }
>> 
>>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>>     {}
>> 
>>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>>     {}
>> }
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8173339
>  - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

I should do it, thanks for the sponsor.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/66

From andrew at openjdk.org  Fri Aug 26 15:11:58 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 15:11:58 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v2]
In-Reply-To: <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
 <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
Message-ID: <GNyjIyD03y4T0Q1_b-nK-9TdyH2EVRr3QKzs8vkwAl8=.9452cc93-7a9f-40da-ab51-7b6ca6d234f0@github.com>

On Thu, 30 Jun 2022 03:36:49 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix tests for OS with 64K page size.
>> Patch does not apply cleanly: 
>> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
>> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
>> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
>> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
>> 
>> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
>> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
>> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
>> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
>> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
>> and passes with the patch on Aarch64 with 64K page size.
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
>> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
>> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
>> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
>> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
>> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
>> [7] https://bugs.openjdk.java.net/browse/JDK-8173339
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch '8173339' into 8067941
>  - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

Filed https://bugs.openjdk.org/browse/SKARA-1568 for the issue with SKARA treating a timed-out PR as an integrated PR

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

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From andrew at openjdk.org  Fri Aug 26 15:23:08 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 15:23:08 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v2]
In-Reply-To: <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
 <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
Message-ID: <u5lyOT98zHv3G0U6TmsQ_4-3v6QXMj04GRcJWUm0Uas=.f0420116-2f39-48ab-b524-7624545c9dc0@github.com>

On Thu, 30 Jun 2022 03:36:49 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix tests for OS with 64K page size.
>> Patch does not apply cleanly: 
>> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
>> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
>> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
>> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
>> 
>> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
>> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
>> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
>> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
>> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
>> and passes with the patch on Aarch64 with 64K page size.
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
>> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
>> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
>> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
>> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
>> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
>> [7] https://bugs.openjdk.java.net/browse/JDK-8173339
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch '8173339' into 8067941
>  - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

Changes make sense to me, given the bump to AArch64 stack sizes in JDK-8173339

I assume this doesn't affect other architectures, as we don't have JDK-8159335 which bumped the stack sizes on ppc64?

8u now:
~~~
$ grep -r 'StackShadowPages' hotspot/|grep pd_global
hotspot/src/cpu/aarch64/vm/globals_aarch64.hpp:define_pd_global(intx, StackShadowPages, 20 DEBUG_ONLY(+5));
hotspot/src/cpu/sparc/vm/globals_sparc.hpp:define_pd_global(intx, StackShadowPages, 10 DEBUG_ONLY(+1));
hotspot/src/cpu/sparc/vm/globals_sparc.hpp:define_pd_global(intx, StackShadowPages, 3 DEBUG_ONLY(+1));
hotspot/src/cpu/x86/vm/globals_x86.hpp:define_pd_global(intx, StackShadowPages, NOT_WIN64(20) WIN64_ONLY(6) DEBUG_ONLY(+2));
hotspot/src/cpu/x86/vm/globals_x86.hpp:define_pd_global(intx, StackShadowPages, 4 DEBUG_ONLY(+5));
hotspot/src/cpu/zero/vm/globals_zero.hpp:define_pd_global(intx,  StackShadowPages,     5 LP64_ONLY(+1) DEBUG_ONLY(+3));
hotspot/src/os_cpu/aix_ppc/vm/globals_aix_ppc.hpp:define_pd_global(intx, StackShadowPages,         6 DEBUG_ONLY(+2));
hotspot/src/os_cpu/linux_ppc/vm/globals_linux_ppc.hpp:define_pd_global(intx, StackShadowPages,         6 DEBUG_ONLY(+2));
~~~

11u now:
~~~
$ grep -r 'define DEFAULT_STACK_SHADOW_PAGES' ../jdk11u-dev/src/hotspot
../jdk11u-dev/src/hotspot/cpu/x86/globals_x86.hpp:#define DEFAULT_STACK_SHADOW_PAGES (NOT_WIN64(20) WIN64_ONLY(7) DEBUG_ONLY(+2))
../jdk11u-dev/src/hotspot/cpu/x86/globals_x86.hpp:#define DEFAULT_STACK_SHADOW_PAGES (4 DEBUG_ONLY(+5))
../jdk11u-dev/src/hotspot/cpu/aarch64/globals_aarch64.hpp:#define DEFAULT_STACK_SHADOW_PAGES (20 DEBUG_ONLY(+5))
../jdk11u-dev/src/hotspot/cpu/arm/globals_arm.hpp:#define DEFAULT_STACK_SHADOW_PAGES (5 DEBUG_ONLY(+1))
../jdk11u-dev/src/hotspot/cpu/ppc/globals_ppc.hpp:#define DEFAULT_STACK_SHADOW_PAGES (20 DEBUG_ONLY(+2))
../jdk11u-dev/src/hotspot/cpu/s390/globals_s390.hpp:#define DEFAULT_STACK_SHADOW_PAGES   (20 DEBUG_ONLY(+4))
../jdk11u-dev/src/hotspot/cpu/sparc/globals_sparc.hpp:#define DEFAULT_STACK_SHADOW_PAGES (20 DEBUG_ONLY(+2))
../jdk11u-dev/src/hotspot/cpu/zero/globals_zero.hpp:#define DEFAULT_STACK_SHADOW_PAGES (5 LP64_ONLY(+1) DEBUG_ONLY(+3))
~~~

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From andrew at openjdk.org  Fri Aug 26 15:27:08 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 15:27:08 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
Message-ID: <bi7_NmYqIcs8J38mG_oSLz_nbHYqrbK2s2dLneFpNcU=.72debb48-bd3f-4669-a3af-c83b5dad3e3d@github.com>

On Fri, 24 Jun 2022 17:34:34 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`
> 
> This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 
> 
> There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.
> 
> The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.

I see `jdk8u-fix-yes` now

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From andrew at openjdk.org  Fri Aug 26 15:27:09 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 26 Aug 2022 15:27:09 GMT
Subject: [jdk8u-dev] Integrated: 8139668: Generate README-build.html from
 markdown
In-Reply-To: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
Message-ID: <VMjsrrX6tyhE_b8Zc1Kz_hJwLg8at1RrAG_g8ST_5eE=.cae9ec35-5266-44ea-889d-6c7af2daf8ea@github.com>

On Fri, 24 Jun 2022 17:34:34 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`
> 
> This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 
> 
> There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.
> 
> The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.

This pull request has now been integrated.

Changeset: d102764b
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/d102764ba4675280113f2dd96908ed13ee5a37a8
Stats:     4159 lines in 3 files changed: 1667 ins; 1445 del; 1047 mod

8139668: Generate README-build.html from markdown

Reviewed-by: phh
Backport-of: 17c896827dbf1a54ab6539cc2b506f973dbde246

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From duke at openjdk.org  Fri Aug 26 17:45:09 2022
From: duke at openjdk.org (Dan Lutker)
Date: Fri, 26 Aug 2022 17:45:09 GMT
Subject: [jdk8u-dev] Integrated: 7131823: bug in GIFImageReader
In-Reply-To: <XOx4eYpylKAR5FgWiSUM7abE7kki9OLvyXuucn1i77U=.ef3c545d-2bb8-4d08-96a7-622d997794a2@github.com>
References: <XOx4eYpylKAR5FgWiSUM7abE7kki9OLvyXuucn1i77U=.ef3c545d-2bb8-4d08-96a7-622d997794a2@github.com>
Message-ID: <zK6MHObUDaOhfuwNTlg97mD0yoNNbU23fwvDVunhOjU=.f40ffa8f-07cd-4247-8444-a1e77b5f6598@github.com>

On Tue, 16 Aug 2022 21:08:33 GMT, Dan Lutker <duke at openjdk.org> wrote:

> Backport of a31130fd4056907edcb420761722c629a33273eb, paths had to be updated and diff applied with offset.
> 
> 
> patching file jdk/src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java
> Hunk #1 succeeded at 937 (offset -16 lines).
> Hunk #2 succeeded at 961 (offset -16 lines).
> Hunk #3 succeeded at 984 (offset -16 lines).
> patching file jdk/test/javax/imageio/plugins/gif/GIFLargeTableIndexTest.java
> 
> 
> All imageio tests are passing including new test in the backport.
> 
> I have some tier1 errors locally that also happen without this change:
> 
> Summary: jdk_tier1
> FAILED: java/util/stream/test/org/openjdk/tests/java/lang/invoke/MHProxiesTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/CollectAndSummaryStatisticsTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/FindFirstOpTest.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/IntPrimitiveOpsTests.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/LongPrimitiveOpsTests.java
> FAILED: java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java

This pull request has now been integrated.

Changeset: 026a6c58
Author:    Dan Lutker <lutkerd at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/026a6c58afe2ff4ec851c5ea4905c68c87b4d7c0
Stats:     175 lines in 2 files changed: 158 ins; 4 del; 13 mod

7131823: bug in GIFImageReader

Reviewed-by: phh
Backport-of: a31130fd4056907edcb420761722c629a33273eb

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

PR: https://git.openjdk.org/jdk8u-dev/pull/104

From phh at openjdk.org  Fri Aug 26 18:12:18 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Aug 2022 18:12:18 GMT
Subject: [jdk8u-dev] RFR: 8292762: Remove .jcheck directories from jdk8u
 subcomponents
In-Reply-To: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
References: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
Message-ID: <TYxxoc2yzcf83lNTGKUZJv4Lo7cRKquL4txkLRQB8ak=.34d48a92-5ce2-4bc6-8f1a-a869e3de96a6@github.com>

On Tue, 23 Aug 2022 07:29:37 GMT, George Adams <duke at openjdk.org> wrote:

> After the consolidation of jdk8u into a single mono-style repo there is no longer a need to have the .jcheck configuration files in each of the subcomponent directories. These can now be removed.

Missed the root directory .jcheck.

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

Changes requested by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/110

From mbalao at openjdk.org  Fri Aug 26 21:47:10 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 Aug 2022 21:47:10 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1 [v2]
In-Reply-To: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
Message-ID: <-E8Ved1JdypO-Nydc8u5XfbzNk3ACZHMUscRd5lpazg=.38c33ba8-9e2f-4ef0-ac72-78b291f9afe5@github.com>

> Hi,
> 
> I'd like to propose the backport of the JDK-8195607 fix to 8u because this release is affected by this issue. Given that the legacy NSS DB has been deprecated for a long time and it's increasingly replaced by SQLite DBs, the chances that JDK-8 builds hit this problem are now higher.
> 
> The 11u backport applies cleanly, once paths are fixed.
> 
> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.
> 
> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as 
 when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
> 
> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
> 
> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://github.com/openjdk/jdk11u/blob/master/test/jdk/TEST.ROOT#L61
> [2] - https://github.com/openjdk/jtreg/blob/jtreg-6.2%2B1/src/share/classes/com/sun/javatest/regtest/config/Locations.java#L174

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Clean the temporary nssdb directory so every test gets complete isolation (no interference from old files causing unreliability)." as required in the PR review.
  
  This reverts commit 22c1df05d2ab51a400ebdc69566e84fdaf32efec.

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/106/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/106/files/22c1df05..551163b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=106&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=106&range=00-01

  Stats: 27 lines in 1 file changed: 0 ins; 25 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/106.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/106/head:pull/106

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From mbalao at openjdk.org  Fri Aug 26 21:53:13 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 Aug 2022 21:53:13 GMT
Subject: [jdk8u-dev] Integrated: JDK-8292688: Support Security properties in
 security.testlibrary.Proc
In-Reply-To: <p0-LPkxqymPm0K4Jb_dtfVBiIVloPVADUnPyiAQjD78=.84ec65d5-c44d-4f20-b7b9-27237cda0a68@github.com>
References: <p0-LPkxqymPm0K4Jb_dtfVBiIVloPVADUnPyiAQjD78=.84ec65d5-c44d-4f20-b7b9-27237cda0a68@github.com>
Message-ID: <ObNxikAYGv4kAbVEXsvARh7BzWcdTA5w7r1OmSmFZs4=.24ef445e-98ad-4b89-abb5-f31d76df44c4@github.com>

On Sat, 20 Aug 2022 02:10:51 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hi,
> 
> I'd like to propose a test library enhacement as described in JDK-8292688 [1].
> 
> In addition to hook context modifications from Proc.java changes in JDK-8209901, I had to use Paths::get to obtain a Path instance from a String (Path::of is not available in 8u).
> 
> I tested these changes with my own code snippet:
> 
> 
> public final class Main {
>     private static final String CHILD_ID = "CHILD_ID";
>     private static final String SEC_PROP = "SEC_PROP";
>     private static final String SEC_PROP_VAL = "KNOWN_VAL!";
>     public static void main(String[] args) throws Throwable {
>         if (args.length > 0 && args[0].equals(CHILD_ID)) {
>             String secVal = java.security.Security.getProperty(SEC_PROP);
>             System.out.println("SEC_PROP: " + secVal);
>             if (!secVal.equals(SEC_PROP_VAL)) {
>                 throw new Exception("TEST FAILED");
>             }
>         } else {
>             Proc p = Proc.create(Main.class.getName()).args(CHILD_ID);
>             p.secprop(SEC_PROP, SEC_PROP_VAL);
>             p.debug(Main.class.getName());
>             p.inheritIO();
>             p.start().waitFor(0);
>         }
>     }
> }
> 
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.org/browse/JDK-8292688

This pull request has now been integrated.

Changeset: 0d5ea9d2
Author:    Martin Balao <mbalao at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/0d5ea9d29e97f1e4adcc1e1d36bc109fc5cee506
Stats:     27 lines in 1 file changed: 26 ins; 0 del; 1 mod

8292688: Support Security properties in security.testlibrary.Proc

Reviewed-by: sgehwolf

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

PR: https://git.openjdk.org/jdk8u-dev/pull/107

From mbalao at openjdk.org  Fri Aug 26 22:16:06 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 Aug 2022 22:16:06 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1
In-Reply-To: <Lr6a-mD67L3tEvN_YrnOzIjMe1GEGH1yDbxeSipsI8o=.d50f714f-04b9-4c79-abfb-57481985e353@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
 <eV0MkvSJITpAY1oYNhKW0C0cctrHhTBAhJzj4x1h8rU=.11683e51-abe4-46a2-86e8-343868886cee@github.com>
 <Oro9oUztPKIHKaHBw3rfnvQexMNGCXsbHM2EQf5xSa4=.6c76b398-1c60-4a43-87fa-93abfd05a5c9@github.com>
 <Lr6a-mD67L3tEvN_YrnOzIjMe1GEGH1yDbxeSipsI8o=.d50f714f-04b9-4c79-abfb-57481985e353@github.com>
Message-ID: <wnGQuNdF1CnUIsCyK7VvaF4QXtl1W67xFE5tYDkKImY=.0b677e02-ba4c-45c4-818d-350973907a89@github.com>

On Fri, 26 Aug 2022 09:05:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Hi @jerboaa ,
>> 
>> Thanks for your review.
>> 
>> Let me clarify the jtreg issue. It's not that the test fails because it's run with an old jtreg. In fact, I'm running with jtreg 5 and it's failing. The problem is that the TEST.ROOT in JDK-8 does not set a "minimum jtreg required" (probably because it's a newer feature than JDK-8). In these cases, jtreg takes a conservative approach and does not split the text execution into different directories. Setting a "minimum jtreg required" in JDK-8 would be a high risk as we don't know the impact of other tests in newer or older jtreg releases. Having this test broken would be a regression. I hope we can have this fix, or you might come up with a different one. Let me know if that helps for a better understanding.
>> 
>> Martin.-
>
>> Let me clarify the jtreg issue. It's not that the test fails because it's run with an old jtreg. In fact, I'm running with jtreg 5 and it's failing. The problem is that the TEST.ROOT in JDK-8 does not set a "minimum jtreg required" (probably because it's a newer feature than JDK-8). In these cases, jtreg takes a conservative approach and does not split the text execution into different directories. Setting a "minimum jtreg required" in JDK-8 would be a high risk as we don't know the impact of other tests in newer or older jtreg releases. Having this test broken would be a regression. I hope we can have this fix, or you might come up with a different one. Let me know if that helps for a better understanding.
> 
> Thanks for the clarification. I'm fine with your approach, but https://github.com/openjdk/jdk8u-dev/commit/22c1df05d2ab51a400ebdc69566e84fdaf32efec should go in as a separate 8u-specific patch. Or we could take this as an opportunity to require jtreg 5+ (which should be fine IMHO, I don't agree it's a high risk change). Either way this should be a separate discussion with a separate bug.

Hi @jerboaa ,

Thanks for your comment.

I've committed a revert for https://github.com/openjdk/jdk8u-dev/commit/22c1df05d2ab51a400ebdc69566e84fdaf32efec and opened a new ticket for it: https://bugs.openjdk.org/browse/JDK-8292998

I'll not propose this backport to 8u until I have JDK-8292998 integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From mbalao at openjdk.org  Fri Aug 26 22:32:11 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Fri, 26 Aug 2022 22:32:11 GMT
Subject: [jdk8u-dev] RFR: JDK-8292998: Clean Secmod temporary NSS DB directory
 before test execution
Message-ID: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>

Hello,

I'd like to propose this fix as described in https://bugs.openjdk.org/browse/JDK-8292998

The temporary directory used by Secmod tests to copy NSS DB files is deleted (which includes all its files and, potentially, subdirectories) and created empty again before running the test. I decided to implement the recursive delete function here for 3 reasons: 1) it's a short and simple function,  2) convenience (we don't have to link every current Secmod test to a test library) and 3) increase chances of backporting future Secmod tests cleanly. Contrary to the approach of setting a minimum jtreg version required, the scope of this change are Secmod tests only and the risk should be minimal.

Thanks,
Martin.-

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

Commit messages:
 - JDK-8292998: Clean Secmod temporary NSS DB directory before test execution.

Changes: https://git.openjdk.org/jdk8u-dev/pull/115/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=115&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292998
  Stats: 27 lines in 1 file changed: 25 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/115.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/115/head:pull/115

PR: https://git.openjdk.org/jdk8u-dev/pull/115

From duke at openjdk.org  Sat Aug 27 09:33:17 2022
From: duke at openjdk.org (George Adams)
Date: Sat, 27 Aug 2022 09:33:17 GMT
Subject: [jdk8u-dev] RFR: 8292762: Remove .jcheck directories from jdk8u
 subcomponents
In-Reply-To: <TYxxoc2yzcf83lNTGKUZJv4Lo7cRKquL4txkLRQB8ak=.34d48a92-5ce2-4bc6-8f1a-a869e3de96a6@github.com>
References: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
 <TYxxoc2yzcf83lNTGKUZJv4Lo7cRKquL4txkLRQB8ak=.34d48a92-5ce2-4bc6-8f1a-a869e3de96a6@github.com>
Message-ID: <c9L2KDIoqmIES1kmEBgF0B71njIAhM3zi2XdD__5Pq4=.eb547d77-aaa0-43ef-9f22-ba1f36b9d7ca@github.com>

On Fri, 26 Aug 2022 18:10:16 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> After the consolidation of jdk8u into a single mono-style repo there is no longer a need to have the .jcheck configuration files in each of the subcomponent directories. These can now be removed.
>
> Missed the root directory .jcheck.

@phohensee don?t we need that one? I thought that was used by the skara tooling? It exists in all the other repos

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

PR: https://git.openjdk.org/jdk8u-dev/pull/110

From duke at openjdk.org  Sat Aug 27 09:37:21 2022
From: duke at openjdk.org (George Adams)
Date: Sat, 27 Aug 2022 09:37:21 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <bi7_NmYqIcs8J38mG_oSLz_nbHYqrbK2s2dLneFpNcU=.72debb48-bd3f-4669-a3af-c83b5dad3e3d@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
 <bi7_NmYqIcs8J38mG_oSLz_nbHYqrbK2s2dLneFpNcU=.72debb48-bd3f-4669-a3af-c83b5dad3e3d@github.com>
Message-ID: <-nShdCiKQ7Snjp1mpsh1_tf8SUwovOL_ar549uP0-_c=.83fa60a1-9d50-427a-8999-800a0ab81ac3@github.com>

On Fri, 26 Aug 2022 15:21:40 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`
>> 
>> This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 
>> 
>> There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.
>> 
>> The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.
>
> I see `jdk8u-fix-yes` now

@gnu-andrew is the plan to backport JDK-8176509 next?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From phh at openjdk.org  Sun Aug 28 12:21:20 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Sun, 28 Aug 2022 12:21:20 GMT
Subject: [jdk8u-dev] RFR: 8292762: Remove .jcheck directories from jdk8u
 subcomponents
In-Reply-To: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
References: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
Message-ID: <PkCwLQU6ie6mOYd8gJnr0Cgb84sY1Z5BGufwclXpqxY=.e5fea992-fae0-4d45-a953-2b4a46ebbbb1@github.com>

On Tue, 23 Aug 2022 07:29:37 GMT, George Adams <duke at openjdk.org> wrote:

> After the consolidation of jdk8u into a single mono-style repo there is no longer a need to have the .jcheck configuration files in each of the subcomponent directories. These can now be removed.

You're correct. Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/110

From dongbohe at openjdk.org  Mon Aug 29 01:06:07 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Mon, 29 Aug 2022 01:06:07 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v2]
In-Reply-To: <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
 <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
Message-ID: <Xtcs5G9ViB_nLe28uOrcpxCLmHY0KeefWovp2p-dNDg=.d55c41b7-fc44-40c9-ba0d-ba5274bc5d83@github.com>

On Thu, 30 Jun 2022 03:36:49 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix tests for OS with 64K page size.
>> Patch does not apply cleanly: 
>> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
>> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
>> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
>> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
>> 
>> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
>> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
>> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
>> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
>> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
>> and passes with the patch on Aarch64 with 64K page size.
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
>> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
>> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
>> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
>> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
>> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
>> [7] https://bugs.openjdk.java.net/browse/JDK-8173339
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch '8173339' into 8067941
>  - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

Yes, theoretically this does not affect other architectures.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From dongbohe at openjdk.org  Mon Aug 29 01:27:17 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Mon, 29 Aug 2022 01:27:17 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v2]
In-Reply-To: <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
 <DyH4_P-dmo6FUt0AYeUf8LO2JffKZNfWpIyvFA-3GAo=.46812e0b-74a9-4af0-8e2c-88cd3fbf6d0f@github.com>
Message-ID: <DBPWd3Gwv3ZopDTmMT2yQui8ansdOGU8E66ua5SpEaA=.d102b6b7-e22f-433a-8e2b-72538dcaed11@github.com>

On Thu, 30 Jun 2022 03:36:49 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix tests for OS with 64K page size.
>> Patch does not apply cleanly: 
>> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
>> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
>> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
>> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
>> 
>> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
>> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
>> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
>> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
>> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
>> and passes with the patch on Aarch64 with 64K page size.
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
>> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
>> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
>> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
>> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
>> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
>> [7] https://bugs.openjdk.java.net/browse/JDK-8173339
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch '8173339' into 8067941
>  - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682

But we need to explain the impact of [JDK-8173339](https://bugs.openjdk.org/browse/JDK-8173339) in the jdk8u release. The minimum value of xss on Aarch64 is changed from 164k to 228k on 4k page size(328k->456k on 64k page size). If the user-specified xss is smaller than the current minimum value, the value of xss needs to be adjusted to be larger than the minimum required value to prevent JVM startup failure.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From dongbohe at openjdk.org  Mon Aug 29 01:47:58 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Mon, 29 Aug 2022 01:47:58 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v3]
In-Reply-To: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
Message-ID: <nggfE7d--DEIWJI7LZAkprPKATPhftsDKwWJrRf6M34=.32255896-0f06-41f2-82b7-2a5c3556c887@github.com>

> Hi,
> 
> I would like to backport this patch to fix tests for OS with 64K page size.
> Patch does not apply cleanly: 
> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
> 
> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
> 
> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
> and passes with the patch on Aarch64 with 64K page size.
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
> [7] https://bugs.openjdk.java.net/browse/JDK-8173339

Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8067941
 - Merge branch '8173339' into 8067941
 - Merge branch 'master' into 8173339
 - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682
 - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/71/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/71/files/565302ee..5261d713

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=71&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=71&range=01-02

  Stats: 18157 lines in 168 files changed: 3923 ins; 12614 del; 1620 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/71.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/71/head:pull/71

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From sgehwolf at openjdk.org  Mon Aug 29 10:57:16 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 29 Aug 2022 10:57:16 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1 [v2]
In-Reply-To: <-E8Ved1JdypO-Nydc8u5XfbzNk3ACZHMUscRd5lpazg=.38c33ba8-9e2f-4ef0-ac72-78b291f9afe5@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
 <-E8Ved1JdypO-Nydc8u5XfbzNk3ACZHMUscRd5lpazg=.38c33ba8-9e2f-4ef0-ac72-78b291f9afe5@github.com>
Message-ID: <Cs9v--JJq79po2CvH1scQI7VbcKnM3dXjHa2dpVESVM=.f9c722f8-9b06-4ca8-935f-da71d0e7cbc8@github.com>

On Fri, 26 Aug 2022 21:47:10 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi,
>> 
>> I'd like to propose the backport of the JDK-8195607 fix to 8u because this release is affected by this issue. Given that the legacy NSS DB has been deprecated for a long time and it's increasingly replaced by SQLite DBs, the chances that JDK-8 builds hit this problem are now higher.
>> 
>> The 11u backport applies cleanly, once paths are fixed.
>> 
>> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.
>> 
>> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as
  when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
>> 
>> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
>> 
>> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://github.com/openjdk/jdk11u/blob/master/test/jdk/TEST.ROOT#L61
>> [2] - https://github.com/openjdk/jtreg/blob/jtreg-6.2%2B1/src/share/classes/com/sun/javatest/regtest/config/Locations.java#L174
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Clean the temporary nssdb directory so every test gets complete isolation (no interference from old files causing unreliability)." as required in the PR review.
>   
>   This reverts commit 22c1df05d2ab51a400ebdc69566e84fdaf32efec.

Looks like a clean backport to me now.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From sgehwolf at openjdk.org  Mon Aug 29 16:20:25 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 29 Aug 2022 16:20:25 GMT
Subject: [jdk8u-dev] RFR: JDK-8292998: Clean Secmod temporary NSS DB
 directory before test execution
In-Reply-To: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
References: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
Message-ID: <OfF2WhIICNskK7l8Agsq3YRCWnNy83yHdyv55pPouOo=.d24298a8-dd6f-47a3-9feb-154801cac2ad@github.com>

On Fri, 26 Aug 2022 22:26:06 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hello,
> 
> I'd like to propose this fix as described in https://bugs.openjdk.org/browse/JDK-8292998
> 
> The temporary directory used by Secmod tests to copy NSS DB files is deleted (which includes all its files and, potentially, subdirectories) and created empty again before running the test. I decided to implement the recursive delete function here for 3 reasons: 1) it's a short and simple function,  2) convenience (we don't have to link every current Secmod test to a test library) and 3) increase chances of backporting future Secmod tests cleanly. Contrary to the approach of setting a minimum jtreg version required, the scope of this change are Secmod tests only and the risk should be minimal.
> 
> Thanks,
> Martin.-

This looks OK to me. Given that this change makes test runs not leak files from one test to another this is good! Later JDK versions are doing the same, but with a different means. Thumbs up.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/115

From duke at openjdk.org  Mon Aug 29 18:10:59 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 29 Aug 2022 18:10:59 GMT
Subject: [jdk8u-dev] RFR: JDK-8292998: Clean Secmod temporary NSS DB
 directory before test execution
In-Reply-To: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
References: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
Message-ID: <TSHA8fOxe0Zcfv0rmXIn_ZUzwVU3kmB8AeSQHruB-9w=.17e63dea-7fd0-447a-ad9c-63bce2379c04@github.com>

On Fri, 26 Aug 2022 22:26:06 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hello,
> 
> I'd like to propose this fix as described in https://bugs.openjdk.org/browse/JDK-8292998
> 
> The temporary directory used by Secmod tests to copy NSS DB files is deleted (which includes all its files and, potentially, subdirectories) and created empty again before running the test. I decided to implement the recursive delete function here for 3 reasons: 1) it's a short and simple function,  2) convenience (we don't have to link every current Secmod test to a test library) and 3) increase chances of backporting future Secmod tests cleanly. Contrary to the approach of setting a minimum jtreg version required, the scope of this change are Secmod tests only and the risk should be minimal.
> 
> Thanks,
> Martin.-

I wonder why "DBDIR" is created inside of "test.classes" dir. Apart from not being cleaned up this also seems like potential source of problems when tests are run concurrently. Couldn't "DBDIR" just be placed in "scratch" [1] directory? Or is there something I am missing here?

[1] https://openjdk.org/jtreg/faq.html#scratch-directory

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

PR: https://git.openjdk.org/jdk8u-dev/pull/115

From duke at openjdk.org  Mon Aug 29 18:12:05 2022
From: duke at openjdk.org (Stephanie Crater)
Date: Mon, 29 Aug 2022 18:12:05 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <5_PO2D6BPhFts9VnCWMPB6GzpuGhKnBs3BRy7XqRe9M=.aa993c52-56bc-4c7c-b269-5a39efb3b254@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
 <xoDeT0n-xnY46A0MGTuJkEYp_XRcsKi4vpZZthKDVn8=.2e3bd5bd-5d4e-4316-a5da-f4229f02ad2b@github.com>
 <5_PO2D6BPhFts9VnCWMPB6GzpuGhKnBs3BRy7XqRe9M=.aa993c52-56bc-4c7c-b269-5a39efb3b254@github.com>
Message-ID: <Zfe2IzsgeTSf-MGX3SyW7eKklha-3H70Jqd3wnWbYbg=.773ae6e0-cb4f-4df9-a136-886ba95dba45@github.com>

On Thu, 4 Aug 2022 00:17:09 GMT, Rui Li <duke at openjdk.org> wrote:

>> Please add a note on how it was tested.
>
>> Please add a note on how it was tested.
> 
> Updated the overview with manual test description. Also triggered a new `Pre-submit` action for the branch: https://github.com/rgithubli/jdk8u-dev/actions/workflows/submit.yml. Thanks.

@rgithubli are you still planning to integrate this PR and dependent PR https://github.com/openjdk/jdk8u-dev/pull/93? Can we get a fix-yes tag?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Mon Aug 29 18:17:05 2022
From: duke at openjdk.org (Rui Li)
Date: Mon, 29 Aug 2022 18:17:05 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <Zfe2IzsgeTSf-MGX3SyW7eKklha-3H70Jqd3wnWbYbg=.773ae6e0-cb4f-4df9-a136-886ba95dba45@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
 <xoDeT0n-xnY46A0MGTuJkEYp_XRcsKi4vpZZthKDVn8=.2e3bd5bd-5d4e-4316-a5da-f4229f02ad2b@github.com>
 <5_PO2D6BPhFts9VnCWMPB6GzpuGhKnBs3BRy7XqRe9M=.aa993c52-56bc-4c7c-b269-5a39efb3b254@github.com>
 <Zfe2IzsgeTSf-MGX3SyW7eKklha-3H70Jqd3wnWbYbg=.773ae6e0-cb4f-4df9-a136-886ba95dba45@github.com>
Message-ID: <o5YDx3SWeU54rMLQuyCVk5wy1Ofmot6tvX-yJf8qqdc=.d148626e-b71e-4303-b5c4-c5e21e2c0822@github.com>

On Mon, 29 Aug 2022 18:08:13 GMT, Stephanie Crater <duke at openjdk.org> wrote:

>>> Please add a note on how it was tested.
>> 
>> Updated the overview with manual test description. Also triggered a new `Pre-submit` action for the branch: https://github.com/rgithubli/jdk8u-dev/actions/workflows/submit.yml. Thanks.
>
> @rgithubli are you still planning to integrate this PR and dependent PR https://github.com/openjdk/jdk8u-dev/pull/93? Can we get a fix-yes tag?

@calderast Yes I do plan to integrate. We're still waiting for maintainers to review and mark both JBS issues ([JDK-8071530](https://bugs.openjdk.org/browse/JDK-8071530), [JDK-8274840](https://bugs.openjdk.org/browse/JDK-8274840)) to `jdk8u-fix-request`. Any chance you know how to accelerate?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Mon Aug 29 18:27:52 2022
From: duke at openjdk.org (Stephanie Crater)
Date: Mon, 29 Aug 2022 18:27:52 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
Message-ID: <ltSuglnc4Tk00IhgCzfOypKNmY4C6ruMRSU7e0KeJ9M=.b37a882a-4154-4679-afd4-badcb3896586@github.com>

On Tue, 26 Jul 2022 20:31:56 GMT, Rui Li <duke at openjdk.org> wrote:

> jdk commit: https://github.com/openjdk/jdk/commit/fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f
> 
> Clean backport.
> 
> Testing:
> - Tested with this change applied: https://github.com/openjdk/jdk8u-dev/pull/93. This backport is a prerequisite of https://github.com/openjdk/jdk8u-dev/pull/93. 
> - Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

jdk8u maintainer @theRealAph, could you please review for a fix-yes? Thanks!

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From phh at openjdk.org  Mon Aug 29 19:05:07 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 29 Aug 2022 19:05:07 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
Message-ID: <MQQn8qCM1xO2Ce0KwltjRyAOd0g1ksaJB6OaWsrdRQc=.709ecf35-74ac-4f65-8195-a8368f83f6d8@github.com>

On Tue, 26 Jul 2022 20:31:56 GMT, Rui Li <duke at openjdk.org> wrote:

> jdk commit: https://github.com/openjdk/jdk/commit/fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f
> 
> Clean backport.
> 
> Testing:
> - Tested with this change applied: https://github.com/openjdk/jdk8u-dev/pull/93. This backport is a prerequisite of https://github.com/openjdk/jdk8u-dev/pull/93. 
> - Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

I tagged [JDK-8071530](https://bugs.openjdk.org/browse/JDK-8071530) almost a month ago.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From mbalao at openjdk.org  Mon Aug 29 21:02:56 2022
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 29 Aug 2022 21:02:56 GMT
Subject: [jdk8u-dev] RFR: JDK-8292998: Clean Secmod temporary NSS DB
 directory before test execution
In-Reply-To: <TSHA8fOxe0Zcfv0rmXIn_ZUzwVU3kmB8AeSQHruB-9w=.17e63dea-7fd0-447a-ad9c-63bce2379c04@github.com>
References: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
 <TSHA8fOxe0Zcfv0rmXIn_ZUzwVU3kmB8AeSQHruB-9w=.17e63dea-7fd0-447a-ad9c-63bce2379c04@github.com>
Message-ID: <JslugH8p-rjR6TQVDtFvx29109vvHxxtyor0ELviGaI=.99ffc9a9-9d86-4fb5-9bb3-b7cd4d49552c@github.com>

On Mon, 29 Aug 2022 18:06:20 GMT, zzambers <duke at openjdk.org> wrote:

>> Hello,
>> 
>> I'd like to propose this fix as described in https://bugs.openjdk.org/browse/JDK-8292998
>> 
>> The temporary directory used by Secmod tests to copy NSS DB files is deleted (which includes all its files and, potentially, subdirectories) and created empty again before running the test. I decided to implement the recursive delete function here for 3 reasons: 1) it's a short and simple function,  2) convenience (we don't have to link every current Secmod test to a test library) and 3) increase chances of backporting future Secmod tests cleanly. Contrary to the approach of setting a minimum jtreg version required, the scope of this change are Secmod tests only and the risk should be minimal.
>> 
>> Thanks,
>> Martin.-
>
> I wonder why "DBDIR" is created inside of "test.classes" dir. Apart from not being cleaned up this also seems like potential source of problems when tests are run concurrently. Couldn't "DBDIR" just be placed in "scratch" [1] directory? Or is there something I am missing here?
> 
> [1] https://openjdk.org/jtreg/faq.html#scratch-directory

Hi @zzambers ,

It's a good point. I think that Secmod tests are not and have never been ready to run in parallel, at least not in 8u. As an example, they copy entire files to the same location without any file system synchronization scheme, which can potentially lead to inconsistencies. What we have fixed here is the sequential run of these tests, which was working before JDK-8195607.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/115

From sgehwolf at openjdk.org  Tue Aug 30 08:50:13 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Aug 2022 08:50:13 GMT
Subject: [jdk8u-dev] RFR: 8274840: Update OS detection code to recognize
 Windows 11
In-Reply-To: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
References: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
Message-ID: <W-8y2f4XGNzdKZcMNg7p3njCbQkpXDqevZwlMOiyrZ4=.017c580f-67f4-412f-b9e7-41ff531531c9@github.com>

On Fri, 29 Jul 2022 22:38:36 GMT, Rui Li <duke at openjdk.org> wrote:

> This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014
> 
> The original author is Matthias Baesken and co-authored by Arno Zeller. It was reviewed by clanger, dholmes.
> 
> The backport was clean after updating filepath.
> 
> 
> Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

Don't close this yet, bot.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/93

From sgehwolf at openjdk.org  Tue Aug 30 08:50:14 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Aug 2022 08:50:14 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <MQQn8qCM1xO2Ce0KwltjRyAOd0g1ksaJB6OaWsrdRQc=.709ecf35-74ac-4f65-8195-a8368f83f6d8@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
 <MQQn8qCM1xO2Ce0KwltjRyAOd0g1ksaJB6OaWsrdRQc=.709ecf35-74ac-4f65-8195-a8368f83f6d8@github.com>
Message-ID: <RZB5wYBrDrQB_S7GtjQbGCKApjNpNTIKuPYsVhMmh4E=.e9c3dcd9-e017-4676-9616-508d4c9f4a0f@github.com>

On Mon, 29 Aug 2022 19:02:04 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> I tagged [JDK-8071530](https://bugs.openjdk.org/browse/JDK-8071530) and [JDK-8274840](https://bugs.openjdk.org/browse/JDK-8274840) almost a month ago.

Sorry, I've approved them both now.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Tue Aug 30 08:54:17 2022
From: duke at openjdk.org (Rui Li)
Date: Tue, 30 Aug 2022 08:54:17 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <MQQn8qCM1xO2Ce0KwltjRyAOd0g1ksaJB6OaWsrdRQc=.709ecf35-74ac-4f65-8195-a8368f83f6d8@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
 <MQQn8qCM1xO2Ce0KwltjRyAOd0g1ksaJB6OaWsrdRQc=.709ecf35-74ac-4f65-8195-a8368f83f6d8@github.com>
Message-ID: <b_xSw6Y1ZHLaZlKM6wGfSt4CGRWJ5M5aZiIfm9tqp0o=.778069c8-90e6-4b0c-9b28-6ab747370670@github.com>

On Mon, 29 Aug 2022 19:02:04 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> jdk commit: https://github.com/openjdk/jdk/commit/fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f
>> 
>> Clean backport.
>> 
>> Testing:
>> - Tested with this change applied: https://github.com/openjdk/jdk8u-dev/pull/93. This backport is a prerequisite of https://github.com/openjdk/jdk8u-dev/pull/93. 
>> - Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`
>
> I tagged [JDK-8071530](https://bugs.openjdk.org/browse/JDK-8071530) and [JDK-8274840](https://bugs.openjdk.org/browse/JDK-8274840) almost a month ago.

@phohensee Yeah sorry. I meant `fix-yes` tag rather than `fix-request`. Fixed the comment. Thanks for helping out for the tagging!

@jerboaa Thanks!

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Tue Aug 30 09:16:20 2022
From: duke at openjdk.org (Rui Li)
Date: Tue, 30 Aug 2022 09:16:20 GMT
Subject: [jdk8u-dev] Integrated: 8071530: Update OS detection code to reflect
 Windows 10 version change
In-Reply-To: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
References: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>
Message-ID: <mXzmvaS78Bg4aUdk0_BJ68t-ign9vfnpZsh6OaTUEbk=.d164c24f-ee95-4457-87ae-619fe44fa9a6@github.com>

On Tue, 26 Jul 2022 20:31:56 GMT, Rui Li <duke at openjdk.org> wrote:

> jdk commit: https://github.com/openjdk/jdk/commit/fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f
> 
> Clean backport.
> 
> Testing:
> - Tested with this change applied: https://github.com/openjdk/jdk8u-dev/pull/93. This backport is a prerequisite of https://github.com/openjdk/jdk8u-dev/pull/93. 
> - Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

This pull request has now been integrated.

Changeset: 266918d1
Author:    Rui Li <ruiamzn at amazon.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/266918d1d384f0fa002c6f5f508b84835fe57c13
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8071530: Update OS detection code to reflect Windows 10 version change

Backport-of: fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Tue Aug 30 09:20:27 2022
From: duke at openjdk.org (Rui Li)
Date: Tue, 30 Aug 2022 09:20:27 GMT
Subject: [jdk8u-dev] RFR: 8274840: Update OS detection code to recognize
 Windows 11 [v2]
In-Reply-To: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
References: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
Message-ID: <RjG866GTzCLf9AtqJwEeBCiDsNzsUxmKUW2dyxfO1mk=.867f9ac8-89a8-4307-bbc9-70e401ce3415@github.com>

> This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014
> 
> The original author is Matthias Baesken and co-authored by Arno Zeller. It was reviewed by clanger, dholmes.
> 
> The backport was clean after updating filepath.
> 
> 
> Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

Rui Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/93/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/93/files/c6a6e603..c6a6e603

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=93&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=93&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/93.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/93/head:pull/93

PR: https://git.openjdk.org/jdk8u-dev/pull/93

From sgehwolf at openjdk.org  Tue Aug 30 10:15:11 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Aug 2022 10:15:11 GMT
Subject: [jdk8u-dev] RFR: 8274840: Update OS detection code to recognize
 Windows 11 [v2]
In-Reply-To: <RjG866GTzCLf9AtqJwEeBCiDsNzsUxmKUW2dyxfO1mk=.867f9ac8-89a8-4307-bbc9-70e401ce3415@github.com>
References: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
 <RjG866GTzCLf9AtqJwEeBCiDsNzsUxmKUW2dyxfO1mk=.867f9ac8-89a8-4307-bbc9-70e401ce3415@github.com>
Message-ID: <LIYN3Qz1cUnNZ4oi6UCQ6oSYbhrcoLn2n0PRwP6SpGA=.cf8a50d4-0f9e-4684-a206-0e2585150c76@github.com>

On Tue, 30 Aug 2022 09:20:27 GMT, Rui Li <duke at openjdk.org> wrote:

>> This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014
>> 
>> The original author is Matthias Baesken and co-authored by Arno Zeller. It was reviewed by clanger, dholmes.
>> 
>> The backport was clean after updating filepath.
>> 
>> 
>> Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`
>
> Rui Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

@rgithubli I think we need to do the `/integrate` and `/sponsor` handshake again. It wasn't labelled `ready` when you initially issued `/integrate`...

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

PR: https://git.openjdk.org/jdk8u-dev/pull/93

From duke at openjdk.org  Tue Aug 30 17:38:28 2022
From: duke at openjdk.org (Rui Li)
Date: Tue, 30 Aug 2022 17:38:28 GMT
Subject: [jdk8u-dev] Integrated: 8274840: Update OS detection code to recognize
 Windows 11
In-Reply-To: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
References: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>
Message-ID: <Z76vhG42bmCN11vVXmtvyaPLk7-YLk-lVyRLHdmE8cc=.9bd8f0d8-1d51-4d4f-aac7-3688f777590a@github.com>

On Fri, 29 Jul 2022 22:38:36 GMT, Rui Li <duke at openjdk.org> wrote:

> This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014
> 
> The original author is Matthias Baesken and co-authored by Arno Zeller. It was reviewed by clanger, dholmes.
> 
> The backport was clean after updating filepath.
> 
> 
> Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

This pull request has now been integrated.

Changeset: bd946fa7
Author:    Rui Li <ruiamzn at amazon.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/bd946fa751cc3b979bb9906941b4570d1750471f
Stats:     15 lines in 2 files changed: 13 ins; 0 del; 2 mod

8274840: Update OS detection code to recognize Windows 11

Reviewed-by: phh
Backport-of: 97ea9dd2f24f9f1fb9b9345a4202a825ee28e014

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

PR: https://git.openjdk.org/jdk8u-dev/pull/93

From sgehwolf at openjdk.org  Tue Aug 30 17:44:26 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Aug 2022 17:44:26 GMT
Subject: [jdk8u-dev] RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
References: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
Message-ID: <QwOwvMMdVx9PAVr4J7V58Un3kDrhvoLbzW4N6pPh8wk=.c89b6aa1-c0fc-4658-be81-9d590190f22a@github.com>

On Thu, 18 Aug 2022 08:28:37 GMT, xpbob <duke at openjdk.org> wrote:

> Backport a625bfdba45d49bc717bcc9be4112db93b50f50a

Only copyright header and path changes. Marking as clean.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/105

From sgehwolf at openjdk.org  Tue Aug 30 18:10:16 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 30 Aug 2022 18:10:16 GMT
Subject: [jdk8u-dev] RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
References: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
Message-ID: <yM3JmG_1P0lVyy8KwRulAGb7O4od5xWmFTf5H5Q3MQo=.9afbea36-79c8-4143-b938-398d03e624ed@github.com>

On Mon, 27 Jun 2022 00:33:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [50d47de8](https://github.com/openjdk/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Jaikiran Pai on 12 May 2022 and was reviewed by Magnus Ihse Bursie and Lance Andersen.
> 
> The patch for JDK8 is slightly different:
>  * The main code patch is moved from the `make/autoconf/lib-bundled.m4` to the `jdk/make/lib/CoreLibraries.gmk` the same place where `":= -lz"` option is set.
>  * All disabled warnings are removed from the patch, seems we do not have such DISABLED_WARNINGS_XX in JDK8

@mrserb This is not being recognized as a backport. Please fix that.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/80

From duke at openjdk.org  Tue Aug 30 19:06:07 2022
From: duke at openjdk.org (George Adams)
Date: Tue, 30 Aug 2022 19:06:07 GMT
Subject: [jdk8u-dev] Integrated: 8292762: Remove .jcheck directories from jdk8u
 subcomponents
In-Reply-To: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
References: <cKdc3DpFNYCWi5Fbc-wb1A_5FxI9gQCMENsDLnpsLVM=.b4513984-3b4a-44f0-9bb3-190baf796bc9@github.com>
Message-ID: <A1JB6xtpWL_h6uE31ysSX0MxYC4fGmWNS57Ejf9miqs=.c25d489c-3eb5-42f8-a00b-af3c482d9a5f@github.com>

On Tue, 23 Aug 2022 07:29:37 GMT, George Adams <duke at openjdk.org> wrote:

> After the consolidation of jdk8u into a single mono-style repo there is no longer a need to have the .jcheck configuration files in each of the subcomponent directories. These can now be removed.

This pull request has now been integrated.

Changeset: 2be37c31
Author:    George Adams <georgeadams1995 at gmail.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/2be37c31bbd26e0aa8d1e7d3cc3bf333b64eeaa0
Stats:     14 lines in 7 files changed: 0 ins; 14 del; 0 mod

8292762: Remove .jcheck directories from jdk8u subcomponents

Reviewed-by: phh

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

PR: https://git.openjdk.org/jdk8u-dev/pull/110

From gnu.andrew at redhat.com  Wed Aug 31 01:39:55 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 31 Aug 2022 02:39:55 +0100
Subject: [RAMPDOWN] 8u352 now in Rampdown Stage
Message-ID: <Yw6763zjUkRDuhVe@hex.discworld.ac.uk>

8u352 is now in rampdown for release in October.

jdk8u-dev is CLOSED for commits until further notice, while the branch
is prepared for the 8u362 release cycle.

For critical fixes (i.e. regressions or urgent fixes) for 8u352,
please file a PR against https://github.com/openjdk/jdk8u and use
jdk8u-critical-request to obtain approval to push.

Note that JDK-8292688 [0] pushed on Friday is the last commit of 8u352
pre-rampdown and will be part of 8u352-b05 once promoted. Those
changes already pushed this week will be moved to 8u362, as per the
schedule on the OpenJDK 8u wiki [1].

[0] https://github.com/openjdk/jdk8u-dev/commit/0d5ea9d29e97f1e4adcc1e1d36bc109fc5cee506
[1] https://wiki.openjdk.org/display/jdk8u/Main

Thanks, 
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220831/418f082b/signature.asc>

From duke at openjdk.org  Wed Aug 31 01:55:25 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 31 Aug 2022 01:55:25 GMT
Subject: [jdk8u-dev] RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <QwOwvMMdVx9PAVr4J7V58Un3kDrhvoLbzW4N6pPh8wk=.c89b6aa1-c0fc-4658-be81-9d590190f22a@github.com>
References: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
 <QwOwvMMdVx9PAVr4J7V58Un3kDrhvoLbzW4N6pPh8wk=.c89b6aa1-c0fc-4658-be81-9d590190f22a@github.com>
Message-ID: <DWhSLPlPYrzI_8PVag74hpr9LkmHHg5Z4Aa6vZmCOdM=.572e2c7f-9296-40f1-b81d-21cb7362d806@github.com>

On Tue, 30 Aug 2022 17:41:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Backport a625bfdba45d49bc717bcc9be4112db93b50f50a
>
> Only copyright header and path changes. Marking as clean.

@jerboaa 
Thanks for review

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

PR: https://git.openjdk.org/jdk8u-dev/pull/105

From andrew at openjdk.org  Wed Aug 31 02:08:21 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:08:21 GMT
Subject: [jdk8u-dev] RFR: 8286582: Build fails on macos aarch64 when using
 --with-zlib=bundled
In-Reply-To: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
References: <ImYzQRJ5mteFVjl4P0piwd0_GTLWZBNXegC-CM9YPGw=.476a9301-d6fe-4821-ae6a-144a00a2015a@github.com>
Message-ID: <NGSt1UuLknuvsyHQKlMaybN_3ROiyfZT23rMLQuDkR4=.9572b254-09bc-43ce-b4eb-3e39f6b4604d@github.com>

On Mon, 27 Jun 2022 00:33:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [50d47de8](https://github.com/openjdk/jdk/commit/50d47de8358e2f22bf3a4a165d660c25ef6eacbc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Jaikiran Pai on 12 May 2022 and was reviewed by Magnus Ihse Bursie and Lance Andersen.
> 
> The patch for JDK8 is slightly different:
>  * The main code patch is moved from the `make/autoconf/lib-bundled.m4` to the `jdk/make/lib/CoreLibraries.gmk` the same place where `":= -lz"` option is set.
>  * All disabled warnings are removed from the patch, seems we do not have such DISABLED_WARNINGS_XX in JDK8

Change itself looks ok, but title needs to be changed to "Backport 8363d9db801314f13e708db62993da5b73634f69" for the backport to be correctly identified.

Please reopen and fix this.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/80

From duke at openjdk.org  Wed Aug 31 02:13:12 2022
From: duke at openjdk.org (xpbob)
Date: Wed, 31 Aug 2022 02:13:12 GMT
Subject: [jdk8u-dev] RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
References: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
Message-ID: <mwjE8lzTvlGxmL6JwRluNQWKg97lB-vLbBSaVs5XQN0=.d1083d62-d8a2-4069-9627-92efd581fa2f@github.com>

On Thu, 18 Aug 2022 08:28:37 GMT, xpbob <duke at openjdk.org> wrote:

> Backport a625bfdba45d49bc717bcc9be4112db93b50f50a

This bug has been flagged jdk8u-fix-yes

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

PR: https://git.openjdk.org/jdk8u-dev/pull/105

From andrew at openjdk.org  Wed Aug 31 02:19:21 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:19:21 GMT
Subject: [jdk8u-dev] RFR: 8283903: GetContainerCpuLoad does not return the
 correct result in share mode
In-Reply-To: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
References: <fS44Y-s_cA22S-q9rju9vl2raNUVbEG6vLk7XXpzRrI=.70c13735-0187-44de-bb8d-e7424d738f70@github.com>
Message-ID: <6Ft4iD3eYtWvgP1_fvsy1qvWg7ERLTBeoEIiHobhbYE=.e349a550-a06a-4b9b-9645-c0af24db717e@github.com>

On Thu, 18 Aug 2022 08:28:37 GMT, xpbob <duke at openjdk.org> wrote:

> Backport a625bfdba45d49bc717bcc9be4112db93b50f50a

Backport looks good.
8u is currently closed for rampdown. Please wait for it to re-open before integrating this patch.

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

Changes requested by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/105

From andrew at openjdk.org  Wed Aug 31 02:26:18 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:26:18 GMT
Subject: [jdk8u-dev] RFR: 8288928: Incorrect GPL header in pnglibconf.h
 (backport of JDK-8185041)
In-Reply-To: <D065rv5snIRUcBwqsgwlMn7e46MI1rP2BA_f80wBhmo=.3c96e402-5f11-4403-a792-d65497ad2b66@github.com>
References: <D065rv5snIRUcBwqsgwlMn7e46MI1rP2BA_f80wBhmo=.3c96e402-5f11-4403-a792-d65497ad2b66@github.com>
Message-ID: <lxUGf8IUXrA--nAFudKcVYG2W4LN18iXj7zg_yZNIFw=.0ed304aa-04ca-4194-b764-8abe27b3b061@github.com>

On Tue, 28 Jun 2022 05:53:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [70762d39](https://github.com/openjdk/jdk/commit/70762d397267f85ce81727ec0c89c9448967798e) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 7 Oct 2019 and was reviewed by Phil Race.
> Thanks!
> 
> Backport is clean, but I have to create a new JBS issue, the initial one is closed.

Backport looks good
8u-dev is currently closed for rampdown so please wait until it reopens before integrating.

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

Changes requested by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/81

From andrew at openjdk.org  Wed Aug 31 02:31:27 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:31:27 GMT
Subject: [jdk8u-dev] RFR: 8273176: handle latest VS2019 in
 abstract_vm_version
In-Reply-To: <uIJWs-lus-eBiXhSKL3_1O9PbEGCcHW3s-PHRdc9-Oo=.4b3dd440-827b-4b2b-bdfa-519c4a251689@github.com>
References: <uIJWs-lus-eBiXhSKL3_1O9PbEGCcHW3s-PHRdc9-Oo=.4b3dd440-827b-4b2b-bdfa-519c4a251689@github.com>
Message-ID: <nqxqQ_TmGxgEvxx608AE-ZFXsNG6GQkVU3CmTQ1oNqY=.6e1a71fe-d3fc-4dca-b0a4-7288dc44ef58@github.com>

On Mon, 11 Jul 2022 07:08:41 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi! Here is another backport from MSVS 2019 seria. This one additionally extends the list of supported VC++ compilers. The patch from 11u is applied cleanly except the path shuffling:
> 
> src/hotspot/share/runtime/abstract_vm_version.cpp -> hotspot/src/share/vm/runtime/vm_version.cpp

Clean backport.

8u-dev is currently closed for rampdown.
Please do not integrate this PR until it is reopened.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/82

From andrew at openjdk.org  Wed Aug 31 02:34:20 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:34:20 GMT
Subject: [jdk8u-dev] RFR: 8067941: [TESTBUG] Fix tests for OS with 64K page
 size. [v3]
In-Reply-To: <nggfE7d--DEIWJI7LZAkprPKATPhftsDKwWJrRf6M34=.32255896-0f06-41f2-82b7-2a5c3556c887@github.com>
References: <sP-nq_dvWqFlmEvEzQsV0h-_AbmVByPemxiZF0rI7YQ=.c96bd048-b98a-4a52-8155-cbd1daace5ac@github.com>
 <nggfE7d--DEIWJI7LZAkprPKATPhftsDKwWJrRf6M34=.32255896-0f06-41f2-82b7-2a5c3556c887@github.com>
Message-ID: <H-NQZmqFmDbsD9IbIrEM9y5IZTkCZrFcwBm4iRdAdOo=.e9f5a03a-fcc8-4d31-b310-dbefbc884507@github.com>

On Mon, 29 Aug 2022 01:47:58 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this patch to fix tests for OS with 64K page size.
>> Patch does not apply cleanly: 
>> JDK-8062854[1] move StackOverflowBug.java and Test8009761.java to corresponding subfolders.
>> Test8009761.java context is different because JDK-8021775[2] and JDK-8011397[3] doesn't in jdk8u.
>> Change to TestGCLogMessages.java is excluded because it was added in JDK-8027962[4].
>> Chnage to WBStackSize.java is excluded because JDK-8032970[5] does not exist in 8.
>> 
>> I changed Xss in StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java, 
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java and TestStackBangRbp.java from
>> 392k to 512k according to JDK-8159335[6], because JDK-8173339[7] changed StackShadowPages to 20, xss needs at least 456k.
>> 
>> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 64k page size.
>> Checked that StackOverflowBug.java, Test8009761.java, TestRecursiveReplacedException.java,
>> StackOverflowGuardPagesOff.java, TestStackBangMonitorOwned.java, TestStackBangRbp.java,
>> TestHumongousAllocInitialMark.java, TestCMSHeapSizeFlags.java, TestG1HeapSizeFlags.java,
>> TestParallelHeapSizeFlags.java, TestSerialHeapSizeFlags.java fails without the patch
>> and passes with the patch on Aarch64 with 64K page size.
>> 
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8062854
>> [2] https://bugs.openjdk.java.net/browse/JDK-8021775
>> [3] https://bugs.openjdk.java.net/browse/JDK-8011397
>> [4] https://bugs.openjdk.java.net/browse/JDK-8027962
>> [5] https://bugs.openjdk.java.net/browse/JDK-8032970
>> [6] https://bugs.openjdk.java.net/browse/JDK-8159335
>> [7] https://bugs.openjdk.java.net/browse/JDK-8173339
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into 8067941
>  - Merge branch '8173339' into 8067941
>  - Merge branch 'master' into 8173339
>  - Backport 8e2df5f543522866e7c27ff95ea6fb6458393682
>  - Backport 540ec375c30e973ceb1a944d5cc60cc8532e88ec

8u-dev is currently closed for rampdown.
I'll sponsor this once it reopens.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/71

From andrew at openjdk.org  Wed Aug 31 02:49:25 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:49:25 GMT
Subject: [jdk8u-dev] RFR: JDK-8292998: Clean Secmod temporary NSS DB
 directory before test execution
In-Reply-To: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
References: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
Message-ID: <2n7U7moz4EtrszEPXvQC6YqHGPf356smrh2d1a_63bE=.44e5e62f-6642-40d2-b460-dde4e17cf372@github.com>

On Fri, 26 Aug 2022 22:26:06 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> Hello,
> 
> I'd like to propose this fix as described in https://bugs.openjdk.org/browse/JDK-8292998
> 
> The temporary directory used by Secmod tests to copy NSS DB files is deleted (which includes all its files and, potentially, subdirectories) and created empty again before running the test. I decided to implement the recursive delete function here for 3 reasons: 1) it's a short and simple function,  2) convenience (we don't have to link every current Secmod test to a test library) and 3) increase chances of backporting future Secmod tests cleanly. Contrary to the approach of setting a minimum jtreg version required, the scope of this change are Secmod tests only and the risk should be minimal.
> 
> Thanks,
> Martin.-

Changes requested by andrew (Reviewer).

jdk/test/sun/security/pkcs11/SecmodTest.java line 99:

> 97:     }
> 98: 
> 99:     private static void deleteDir(final Path directory) throws IOException {

Can we not use `FileUtils.deleteFileTreeWithRetry(Path)` here? That seems to be the same thing, but with better error handling.

See `jdk/test/lib/jdk/test/lib/util/FileUtils.java`

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

PR: https://git.openjdk.org/jdk8u-dev/pull/115

From andrew at openjdk.org  Wed Aug 31 02:55:11 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 02:55:11 GMT
Subject: [jdk8u-dev] RFR: 8195607:
 sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with
 "NSS initialization failed" on NSS 3.34.1 [v2]
In-Reply-To: <-E8Ved1JdypO-Nydc8u5XfbzNk3ACZHMUscRd5lpazg=.38c33ba8-9e2f-4ef0-ac72-78b291f9afe5@github.com>
References: <zsfOrxcsdx8afupxdmTy06kxVxeYRTOJs2Oyw4RTyrA=.e590c9a2-f2b6-460e-836a-daf10745bff3@github.com>
 <-E8Ved1JdypO-Nydc8u5XfbzNk3ACZHMUscRd5lpazg=.38c33ba8-9e2f-4ef0-ac72-78b291f9afe5@github.com>
Message-ID: <u1J0Xl2CsJsSnd_cn4T2n9lnE3VpQqi9PRQo_bWPJ-w=.5805990d-4356-4364-964b-2140aa9d84bc@github.com>

On Fri, 26 Aug 2022 21:47:10 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> Hi,
>> 
>> I'd like to propose the backport of the JDK-8195607 fix to 8u because this release is affected by this issue. Given that the legacy NSS DB has been deprecated for a long time and it's increasingly replaced by SQLite DBs, the chances that JDK-8 builds hit this problem are now higher.
>> 
>> The 11u backport applies cleanly, once paths are fixed.
>> 
>> To minimize risks, I manually debugged the OpenJDK code that connected to an NSS DB using the sql: prefix and everything was as expected.
>> 
>> I also run all the tests under the jdk/sun/security/pkcs11 category and noticed no-regressions strictly related to this fix. The test 'jdk/sun/security/pkcs11/Secmod/TrustAnchors.java' requires a special note, though. This test passes if run standalone but fails when run as part of a group. The reason is because when run as part of a group, other tests copy the file 'pkcs11.txt' to the temporary nssdb directory which is shared between all of them. This DB does not register the trust anchors module called 'Builtin Roots Module', which was available in the old secmod.db and is required by the test (which expects to see a Secmod$Module of TRUSTANCHOR type). While the test leaves the sun.security.pkcs11.SecmodTest::useSqlite field set to false and tries to access the legacy DB (also contained in the shared temporary nssdb directory), NSS realizes that there is a new SQLite DB in the same directory and reads the configuration from pkcs11.txt. Otherwise, if pkcs11.txt does not exist (as
  when the test is run standalone), it creates one with the information in secmod.db and it registers the 'Builtin Roots Module' module. All these findings have been verified with the 'modutil -list' command. While the issue is unrelated to what JDK-8195607 fixes, it has been uncovered by the existence of the pkcs11.txt file introduced with this change.
>> 
>> Why newer releases are not affected? Because jtreg runs tests (including TrustAnchors.java) in separated directories, so they don't share the nssdb temporary directory. In newer releases, TEST.ROOT has a requiredVersion attribute [1] indicating to jtreg that this can be done [2].
>> 
>> I've analyzed several ways to fix this issue but the one that I'd like to propose is to clean up the temporary nssdb directory for every test and avoid conflicts, giving every test the isolation that jtreg does when it sets test.classes uniquely per test in newer JDK releases.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://github.com/openjdk/jdk11u/blob/master/test/jdk/TEST.ROOT#L61
>> [2] - https://github.com/openjdk/jtreg/blob/jtreg-6.2%2B1/src/share/classes/com/sun/javatest/regtest/config/Locations.java#L174
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Clean the temporary nssdb directory so every test gets complete isolation (no interference from old files causing unreliability)." as required in the PR review.
>   
>   This reverts commit 22c1df05d2ab51a400ebdc69566e84fdaf32efec.

Backport looks clean.
8u-dev is currently closed for rampdown. Please wait for it to reopen before integrating.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/106

From duke at openjdk.org  Wed Aug 31 11:25:20 2022
From: duke at openjdk.org (zzambers)
Date: Wed, 31 Aug 2022 11:25:20 GMT
Subject: [jdk8u-dev] RFR: JDK-8292998: Clean Secmod temporary NSS DB
 directory before test execution
In-Reply-To: <JslugH8p-rjR6TQVDtFvx29109vvHxxtyor0ELviGaI=.99ffc9a9-9d86-4fb5-9bb3-b7cd4d49552c@github.com>
References: <piR9O4mG4K0YMl1iwnQVSjl9yswmeISoUJfH0Ba-1Pw=.473c9e1c-8345-493b-b233-2bda5e9a91fd@github.com>
 <TSHA8fOxe0Zcfv0rmXIn_ZUzwVU3kmB8AeSQHruB-9w=.17e63dea-7fd0-447a-ad9c-63bce2379c04@github.com>
 <JslugH8p-rjR6TQVDtFvx29109vvHxxtyor0ELviGaI=.99ffc9a9-9d86-4fb5-9bb3-b7cd4d49552c@github.com>
Message-ID: <n50gsbEcOSJcdBeCg9jFG1ixX_81Qm14xdVQACfWH8M=.8a258f00-4371-479b-81d1-09e0f226479f@github.com>

On Mon, 29 Aug 2022 20:59:32 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> I wonder why "DBDIR" is created inside of "test.classes" dir. Apart from not being cleaned up this also seems like potential source of problems when tests are run concurrently. Couldn't "DBDIR" just be placed in "scratch" [1] directory? Or is there something I am missing here?
>> 
>> [1] https://openjdk.org/jtreg/faq.html#scratch-directory
>
> Hi @zzambers ,
> 
> It's a good point. I think that Secmod tests are not and have never been ready to run in parallel, at least not in 8u. As an example, they copy entire files to the same location without any file system synchronization scheme, which can potentially lead to inconsistencies. What we have fixed here is the sequential run of these tests, which was working before JDK-8195607.

@martinuy I was just thinking if just turning this line
`DBDIR = System.getProperty("test.classes", ".") + SEP + "tmpdb";`
into
`DBDIR = "." + SEP + "tmpdb";`
instead of doing manual cleanup wouldn't be simpler and more robust solution (using "scratch" dir). But I have not actually tested that...

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

PR: https://git.openjdk.org/jdk8u-dev/pull/115

From andrew at openjdk.org  Wed Aug 31 17:26:52 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 17:26:52 GMT
Subject: [jdk8u-dev] RFR: 8293181: Bump update version of OpenJDK: 8u362
Message-ID: <4AR6PF5KhUl6xGfHA0rvFcXi3VEKB6nCw8ASINM_TX8=.47f3983a-d92a-4929-9fca-0656ab7fc154@github.com>

Rampdown for 8u352 has begun. 8u-dev needs to transition to 8u362.

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

Commit messages:
 - 8293181: Bump update version of OpenJDK: 8u362

Changes: https://git.openjdk.org/jdk8u-dev/pull/116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293181
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/116.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/116/head:pull/116

PR: https://git.openjdk.org/jdk8u-dev/pull/116

From sgehwolf at openjdk.org  Wed Aug 31 17:29:29 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 31 Aug 2022 17:29:29 GMT
Subject: [jdk8u-dev] RFR: 8293181: Bump update version of OpenJDK: 8u362
In-Reply-To: <4AR6PF5KhUl6xGfHA0rvFcXi3VEKB6nCw8ASINM_TX8=.47f3983a-d92a-4929-9fca-0656ab7fc154@github.com>
References: <4AR6PF5KhUl6xGfHA0rvFcXi3VEKB6nCw8ASINM_TX8=.47f3983a-d92a-4929-9fca-0656ab7fc154@github.com>
Message-ID: <uIdaN8yXAmkfDnYvcV8zMkftnb5ezKBMiZ9G-RFLA64=.418ed051-d3e6-4513-8806-b4e3a43b043d@github.com>

On Wed, 31 Aug 2022 17:19:52 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Rampdown for 8u352 has begun. 8u-dev needs to transition to 8u362.

LGTM

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/116

From andrew at openjdk.org  Wed Aug 31 17:46:34 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 17:46:34 GMT
Subject: [jdk8u-dev] RFR: 8293181: Bump update version of OpenJDK: 8u362
In-Reply-To: <uIdaN8yXAmkfDnYvcV8zMkftnb5ezKBMiZ9G-RFLA64=.418ed051-d3e6-4513-8806-b4e3a43b043d@github.com>
References: <4AR6PF5KhUl6xGfHA0rvFcXi3VEKB6nCw8ASINM_TX8=.47f3983a-d92a-4929-9fca-0656ab7fc154@github.com>
 <uIdaN8yXAmkfDnYvcV8zMkftnb5ezKBMiZ9G-RFLA64=.418ed051-d3e6-4513-8806-b4e3a43b043d@github.com>
Message-ID: <hXcwHOj4oJPzTC71yy2wsv5Fn65ne35FbiphDpL9Frc=.374cf0ef-3834-4cf5-b76b-178a01f92b6d@github.com>

On Wed, 31 Aug 2022 17:27:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Rampdown for 8u352 has begun. 8u-dev needs to transition to 8u362.
>
> LGTM

Thanks @jerboaa for the quick review and approval.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/116

From andrew at openjdk.org  Wed Aug 31 17:46:34 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 31 Aug 2022 17:46:34 GMT
Subject: [jdk8u-dev] Integrated: 8293181: Bump update version of OpenJDK: 8u362
In-Reply-To: <4AR6PF5KhUl6xGfHA0rvFcXi3VEKB6nCw8ASINM_TX8=.47f3983a-d92a-4929-9fca-0656ab7fc154@github.com>
References: <4AR6PF5KhUl6xGfHA0rvFcXi3VEKB6nCw8ASINM_TX8=.47f3983a-d92a-4929-9fca-0656ab7fc154@github.com>
Message-ID: <nBmR4e26hLnpzn5hfio4hIUW_Qpls0selnn-2EoVGwM=.a0231b33-8b74-48c7-9363-36b73e64c647@github.com>

On Wed, 31 Aug 2022 17:19:52 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Rampdown for 8u352 has begun. 8u-dev needs to transition to 8u362.

This pull request has now been integrated.

Changeset: daccfee6
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/daccfee68e4a18461ab79bb18930d8ad8044b2cb
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8293181: Bump update version of OpenJDK: 8u362

Reviewed-by: sgehwolf

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

PR: https://git.openjdk.org/jdk8u-dev/pull/116