From yan at openjdk.java.net  Mon Feb  1 06:58:45 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 1 Feb 2021 06:58:45 GMT
Subject: [jdk13u-dev] Integrated: 8249215: JFrame::setVisible crashed with
 -Dfile.encoding=UTF-8 on Japanese Windows.
In-Reply-To: <DBjHauWEGYl104m3wVQaxzvQxoj5hO7bZ6lV-SQgtR0=.24f71917-bef7-4cad-b985-0b3c2a3aecb6@github.com>
References: <DBjHauWEGYl104m3wVQaxzvQxoj5hO7bZ6lV-SQgtR0=.24f71917-bef7-4cad-b985-0b3c2a3aecb6@github.com>
Message-ID: <VxIcKjrEspauyqh6bXJm56wZcQQXiywWB8bfMamod_o=.fc4a05ba-7a7d-487a-9cd6-76261d7c2b49@github.com>

On Fri, 29 Jan 2021 14:54:07 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I'd like to port the issue to  13u. The patch  goes without adjustments, problem is reproduced (and was reproduced first in 13).

This pull request has now been integrated.

Changeset: 7a3ce726
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/7a3ce726
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8 on Japanese Windows.

Backport-of: e15e30fef22ddffcaef9449648ae93b407a7b598

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/100

From omikhaltcova at openjdk.java.net  Mon Feb  1 07:08:49 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Mon, 1 Feb 2021 07:08:49 GMT
Subject: [jdk13u-dev] Integrated: 8243389: enhance os::pd_print_cpu_info on
 linux
In-Reply-To: <S_PKbPeU1q2nMsn_MfEaD2kbxFPsK2JG8Oq-PGoSFnk=.4afedd6c-37c8-4269-835d-00de4f1c8c43@github.com>
References: <S_PKbPeU1q2nMsn_MfEaD2kbxFPsK2JG8Oq-PGoSFnk=.4afedd6c-37c8-4269-835d-00de4f1c8c43@github.com>
Message-ID: <pRtyweZjbg5U7qsHTPoBwxb9uTZZYn3zQqALXGq7n6Y=.52dac0ce-2897-463d-a047-b81ed03fbf94@github.com>

On Fri, 29 Jan 2021 16:38:16 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8243389 to jdk13u for parity with jdk11u.
> The original patch applied cleanly.

This pull request has now been integrated.

Changeset: 01fffd0c
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/01fffd0c
Stats:     56 lines in 1 file changed: 56 ins; 0 del; 0 mod

8243389: enhance os::pd_print_cpu_info on linux

Backport-of: 60e2afe2d340beb2899c1b298c002fae360be49a

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/101

From thartmann at openjdk.java.net  Mon Feb  1 15:01:11 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:01:11 GMT
Subject: [jdk16u] RFR: 8258946: Fix optimization-unstable code involving
 signed integer overflow
Message-ID: <xl5HOFF8PJRySO8TxY-lvPxm7VVH9zUniy8df3BPCYQ=.e94b13c9-271a-4fc4-89b6-3d9a8f973da2@github.com>

Backport of [JDK-8258946](https://bugs.openjdk.java.net/browse/JDK-8258946). Applies cleanly.

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

Commit messages:
 - 8258946: Fix optimization-unstable code involving signed integer overflow

Changes: https://git.openjdk.java.net/jdk16u/pull/9/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=9&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258946
  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/9/head:pull/9

PR: https://git.openjdk.java.net/jdk16u/pull/9

From thartmann at openjdk.java.net  Mon Feb  1 15:10:56 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:10:56 GMT
Subject: [jdk16u] RFR: 8258243: C2: assert failed ("Bad derived pointer") with
 -XX:+VerifyRegisterAllocator
Message-ID: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>

Backport of [JDK-8258243](https://bugs.openjdk.java.net/browse/JDK-8258243). Applies cleanly.

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

Commit messages:
 - 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator

Changes: https://git.openjdk.java.net/jdk16u/pull/10/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=10&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258243
  Stats: 43 lines in 2 files changed: 40 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/10/head:pull/10

PR: https://git.openjdk.java.net/jdk16u/pull/10

From thartmann at openjdk.java.net  Mon Feb  1 15:10:02 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:10:02 GMT
Subject: [jdk16u] RFR: 8259576: Misplaced curly brace in
 Matcher::find_shared_post_visit
Message-ID: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>

Backport of [JDK-8259576](https://bugs.openjdk.java.net/browse/JDK-8259576). Applies cleanly.

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

Commit messages:
 - 8259576: Misplaced curly brace in Matcher::find_shared_post_visit

Changes: https://git.openjdk.java.net/jdk16u/pull/11/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=11&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259576
  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/11.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/11/head:pull/11

PR: https://git.openjdk.java.net/jdk16u/pull/11

From thartmann at openjdk.java.net  Mon Feb  1 15:11:58 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:11:58 GMT
Subject: [jdk16u] RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use
 condition is incorrect
Message-ID: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>

Backport of [JDK-8259619](https://bugs.openjdk.java.net/browse/JDK-8259619). Applies cleanly.

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

Commit messages:
 - 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect

Changes: https://git.openjdk.java.net/jdk16u/pull/12/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=12&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259619
  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/12.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/12/head:pull/12

PR: https://git.openjdk.java.net/jdk16u/pull/12

From thartmann at openjdk.java.net  Mon Feb  1 15:14:52 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:14:52 GMT
Subject: [jdk16u] RFR: 8259773: Incorrect encoding of AVX-512 kmovq instruction
Message-ID: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>

Backport of [JDK-8259773](https://bugs.openjdk.java.net/browse/JDK-8259773). Applies cleanly.

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

Commit messages:
 - 8259773: Incorrect encoding of AVX-512 kmovq instruction

Changes: https://git.openjdk.java.net/jdk16u/pull/13/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=13&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259773
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/13.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/13/head:pull/13

PR: https://git.openjdk.java.net/jdk16u/pull/13

From thartmann at openjdk.java.net  Mon Feb  1 15:18:53 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:18:53 GMT
Subject: [jdk16u] RFR: 8259777: Incorrect predication condition generated by
 ADLC
Message-ID: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>

Backport of [JDK-8259777](https://bugs.openjdk.java.net/browse/JDK-8259777). Applies cleanly.

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

Commit messages:
 - 8259777: Incorrect predication condition generated by ADLC

Changes: https://git.openjdk.java.net/jdk16u/pull/14/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=14&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259777
  Stats: 26 lines in 2 files changed: 15 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/14.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/14/head:pull/14

PR: https://git.openjdk.java.net/jdk16u/pull/14

From thartmann at openjdk.java.net  Mon Feb  1 15:24:01 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:24:01 GMT
Subject: [jdk16u] RFR: 8260338: Some fields in HaltNode is not cloned
Message-ID: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>

Backport of [JDK-8260338](https://bugs.openjdk.java.net/browse/JDK-8260338). Applies cleanly.

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

Commit messages:
 - 8260338: Some fields in HaltNode is not cloned

Changes: https://git.openjdk.java.net/jdk16u/pull/15/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=15&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260338
  Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/15/head:pull/15

PR: https://git.openjdk.java.net/jdk16u/pull/15

From vlivanov at openjdk.java.net  Mon Feb  1 15:29:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:29:42 GMT
Subject: [jdk16u] RFR: 8259773: Incorrect encoding of AVX-512 kmovq
 instruction
In-Reply-To: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
References: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
Message-ID: <vQT35jfDF7Q_eUCd8ZJJ9h6ZeXKDX7eqDWrXunsywv4=.92ef5c3f-9a55-4970-b598-972c957247b0@github.com>

On Mon, 1 Feb 2021 15:09:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259773](https://bugs.openjdk.java.net/browse/JDK-8259773). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/13

From vlivanov at openjdk.java.net  Mon Feb  1 15:29:43 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:29:43 GMT
Subject: [jdk16u] RFR: 8259777: Incorrect predication condition generated
 by ADLC
In-Reply-To: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
References: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
Message-ID: <SfNqW7Hm5tvwSykT5nwEoyCxy5oa7gqd5yuqAUkdRmI=.c3abc303-79fc-4470-8cc9-3bf6719b822f@github.com>

On Mon, 1 Feb 2021 15:13:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259777](https://bugs.openjdk.java.net/browse/JDK-8259777). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/14

From vlivanov at openjdk.java.net  Mon Feb  1 15:30:49 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:30:49 GMT
Subject: [jdk16u] RFR: 8259576: Misplaced curly brace in
 Matcher::find_shared_post_visit
In-Reply-To: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
References: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
Message-ID: <-v4q2eeQZJcJZGBGnOFX1RYZVx_su1CZuWEgAsXu3vY=.91c3a4d4-0e82-41c7-9c91-a7b8d1c4f264@github.com>

On Mon, 1 Feb 2021 15:01:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259576](https://bugs.openjdk.java.net/browse/JDK-8259576). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/11

From vlivanov at openjdk.java.net  Mon Feb  1 15:30:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:30:42 GMT
Subject: [jdk16u] RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use
 condition is incorrect
In-Reply-To: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
References: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
Message-ID: <VhkqmEKTZEl1MfoxOmutZZfQUGSOfQRoXXeqOQ1x-1Q=.cc61aa1f-097c-41c4-8649-bbc3def33a5a@github.com>

On Mon, 1 Feb 2021 15:04:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259619](https://bugs.openjdk.java.net/browse/JDK-8259619). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/12

From vlivanov at openjdk.java.net  Mon Feb  1 15:30:47 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:30:47 GMT
Subject: [jdk16u] RFR: 8258243: C2: assert failed ("Bad derived pointer")
 with -XX:+VerifyRegisterAllocator
In-Reply-To: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
References: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
Message-ID: <ZNprq8ygY6XQZo2v9Ydv5fR2GoQNDFBOpD6ZjhH7F80=.f3845d2c-fb5a-4d36-8b89-d45bf0e89d67@github.com>

On Mon, 1 Feb 2021 14:58:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8258243](https://bugs.openjdk.java.net/browse/JDK-8258243). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/10

From thartmann at openjdk.java.net  Mon Feb  1 15:33:49 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:33:49 GMT
Subject: [jdk16u] RFR: 8259339: AllocateUninitializedArray C2 intrinsic fails
 with void.class input
Message-ID: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>

Backport of [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339). Applies cleanly.

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

Commit messages:
 - 8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input

Changes: https://git.openjdk.java.net/jdk16u/pull/16/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=16&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259339
  Stats: 20 lines in 2 files changed: 16 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/16/head:pull/16

PR: https://git.openjdk.java.net/jdk16u/pull/16

From vlivanov at openjdk.java.net  Mon Feb  1 15:34:40 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:34:40 GMT
Subject: [jdk16u] RFR: 8260338: Some fields in HaltNode is not cloned
In-Reply-To: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
References: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
Message-ID: <BEkrDi4DbVSgIsUBMdBxyAK5wQ67dbndCG3gqjYcE5o=.44cdbae7-478a-46b1-b1ae-6b434575dfb7@github.com>

On Mon, 1 Feb 2021 15:19:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8260338](https://bugs.openjdk.java.net/browse/JDK-8260338). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/15

From vlivanov at openjdk.java.net  Mon Feb  1 15:37:46 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 1 Feb 2021 15:37:46 GMT
Subject: [jdk16u] RFR: 8259339: AllocateUninitializedArray C2 intrinsic
 fails with void.class input
In-Reply-To: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
References: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
Message-ID: <g1JPaw0bDdAEkf1d7-OmtSxdrpqAYix-15lut1N007U=.d0ee2037-3ab8-4188-a2cf-9a48e521f2c7@github.com>

On Mon, 1 Feb 2021 15:23:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339). Applies cleanly.

Marked as reviewed by vlivanov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/16

From thartmann at openjdk.java.net  Mon Feb  1 15:41:06 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 1 Feb 2021 15:41:06 GMT
Subject: [jdk16u] RFR: 8259049: Uninitialized variable after JDK-8257513
Message-ID: <ynl8pfCGDJkrHkKZe-hyvFNJD4gEtjP2m2FzVlMWBcs=.1704e7d1-9056-495c-af60-bfd2cd5f273b@github.com>

Backport of [JDK-8257513](https://bugs.openjdk.java.net/browse/JDK-8257513). Applies cleanly.

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

Commit messages:
 - 8257513: C2: assert((constant_addr - _masm.code()->consts()->start()) == con.offset())

Changes: https://git.openjdk.java.net/jdk16u/pull/17/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=17&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259049
  Stats: 91 lines in 4 files changed: 82 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/17/head:pull/17

PR: https://git.openjdk.java.net/jdk16u/pull/17

From kvn at openjdk.java.net  Mon Feb  1 15:45:47 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 15:45:47 GMT
Subject: [jdk16u] RFR: 8259339: AllocateUninitializedArray C2 intrinsic
 fails with void.class input
In-Reply-To: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
References: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
Message-ID: <tyiORaVu1XyokTJ10bSgpS7YxznD8v31NfFejAlYS4g=.a0c584be-a266-4a78-b465-b370436cc40e@github.com>

On Mon, 1 Feb 2021 15:23:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/16

From kvn at openjdk.java.net  Mon Feb  1 15:48:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 15:48:43 GMT
Subject: [jdk16u] RFR: 8259049: Uninitialized variable after JDK-8257513
In-Reply-To: <ynl8pfCGDJkrHkKZe-hyvFNJD4gEtjP2m2FzVlMWBcs=.1704e7d1-9056-495c-af60-bfd2cd5f273b@github.com>
References: <ynl8pfCGDJkrHkKZe-hyvFNJD4gEtjP2m2FzVlMWBcs=.1704e7d1-9056-495c-af60-bfd2cd5f273b@github.com>
Message-ID: <h6lqjxrlPPDBvrpkz1FPLdl6Hxtyusi0qDfD6Tfw7Qs=.d969144b-c493-4f71-baf4-c03a5faee7a2@github.com>

On Mon, 1 Feb 2021 15:31:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8257513](https://bugs.openjdk.java.net/browse/JDK-8257513). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/17

From kvn at openjdk.java.net  Mon Feb  1 16:00:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:00:42 GMT
Subject: [jdk16u] RFR: 8258946: Fix optimization-unstable code involving
 signed integer overflow
In-Reply-To: <xl5HOFF8PJRySO8TxY-lvPxm7VVH9zUniy8df3BPCYQ=.e94b13c9-271a-4fc4-89b6-3d9a8f973da2@github.com>
References: <xl5HOFF8PJRySO8TxY-lvPxm7VVH9zUniy8df3BPCYQ=.e94b13c9-271a-4fc4-89b6-3d9a8f973da2@github.com>
Message-ID: <LX8BFiRRWcvnjfzmL9Jl7qduUF8VTP5UrKcRRhQUiU0=.99fca85b-948f-4cf4-84b4-6726862f8faa@github.com>

On Mon, 1 Feb 2021 14:55:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8258946](https://bugs.openjdk.java.net/browse/JDK-8258946). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/9

From kvn at openjdk.java.net  Mon Feb  1 16:01:49 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:01:49 GMT
Subject: [jdk16u] RFR: 8259576: Misplaced curly brace in
 Matcher::find_shared_post_visit
In-Reply-To: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
References: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
Message-ID: <PWe0c6fuKnDN-Nl09eeN-TCSK_fsVoHjjCo_tpQb6Ok=.13c4f2ae-a592-46a4-a31c-2994fdd7ccac@github.com>

On Mon, 1 Feb 2021 15:01:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259576](https://bugs.openjdk.java.net/browse/JDK-8259576). Applies cleanly.

Trivilal.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/11

From kvn at openjdk.java.net  Mon Feb  1 16:02:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:02:46 GMT
Subject: [jdk16u] RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use
 condition is incorrect
In-Reply-To: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
References: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
Message-ID: <kcCbTzXqoCWMm1ZxCDJHGcDufC_1h1BCOhDg1kD_5FA=.08017543-2a64-421f-ac12-fd456fa0cabd@github.com>

On Mon, 1 Feb 2021 15:04:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259619](https://bugs.openjdk.java.net/browse/JDK-8259619). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/12

From kvn at openjdk.java.net  Mon Feb  1 16:02:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:02:48 GMT
Subject: [jdk16u] RFR: 8258243: C2: assert failed ("Bad derived pointer")
 with -XX:+VerifyRegisterAllocator
In-Reply-To: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
References: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
Message-ID: <MD6IuYgkROxkwfXPpnjh7bnho_ZkHETzVA39DCSRjeY=.b8dbc53e-adea-4042-9cd7-d1719293996a@github.com>

On Mon, 1 Feb 2021 14:58:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8258243](https://bugs.openjdk.java.net/browse/JDK-8258243). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/10

From kvn at openjdk.java.net  Mon Feb  1 16:03:42 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:03:42 GMT
Subject: [jdk16u] RFR: 8259777: Incorrect predication condition generated
 by ADLC
In-Reply-To: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
References: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
Message-ID: <8FE0W1b0qEGMGNMbkPHHvXLr-9yAaN_H7vPYTwCSv9A=.842a4b03-e8bb-475c-80cd-8b8d6755b096@github.com>

On Mon, 1 Feb 2021 15:13:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259777](https://bugs.openjdk.java.net/browse/JDK-8259777). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/14

From kvn at openjdk.java.net  Mon Feb  1 16:03:44 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:03:44 GMT
Subject: [jdk16u] RFR: 8259773: Incorrect encoding of AVX-512 kmovq
 instruction
In-Reply-To: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
References: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
Message-ID: <7TUqwMZ_XYWBYGJt_hRGdXLWq86MPiwxXhj9mL2ELYM=.d2370ff0-fb69-4121-aa59-e2e1442a5c26@github.com>

On Mon, 1 Feb 2021 15:09:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259773](https://bugs.openjdk.java.net/browse/JDK-8259773). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/13

From kvn at openjdk.java.net  Mon Feb  1 16:04:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 1 Feb 2021 16:04:43 GMT
Subject: [jdk16u] RFR: 8260338: Some fields in HaltNode is not cloned
In-Reply-To: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
References: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
Message-ID: <Ye8pDxojMMpYV8bYULHEQrgYFIMFlgZce_vvq_r-5JA=.ca992abb-222c-49b4-b556-dd75bd126ecb@github.com>

On Mon, 1 Feb 2021 15:19:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8260338](https://bugs.openjdk.java.net/browse/JDK-8260338). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/15

From github.com+75672469+larry-n at openjdk.java.net  Mon Feb  1 16:20:04 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Mon, 1 Feb 2021 16:20:04 GMT
Subject: [jdk13u-dev] RFR: 8238710: LingeredApp doesn't log stdout/stderr if
 exits with non-zero code
Message-ID: <ubbFfEb3v7BA1lnpMaiPZffnmqGkUgFxV_R29Hqqg2w=.c54abb99-daa3-4f8a-ad33-2640fb607884@github.com>

Backport fix for bug JDK-8238710. Tested with tier1 and tier2.

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

Commit messages:
 - Backport bcb804f07f290e70fe0e2a243f98aec7a3ec0497

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/102/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=102&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8238710
  Stats: 12 lines in 1 file changed: 5 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/102.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/102/head:pull/102

PR: https://git.openjdk.java.net/jdk13u-dev/pull/102

From sgehwolf at redhat.com  Mon Feb  1 16:21:18 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 01 Feb 2021 17:21:18 +0100
Subject: [11u] RFR: 8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports
 false positive
Message-ID: <e55ecefa13647391860ebc8ffc60ffc1a04b677b.camel@redhat.com>

Hi,

Please review this 11u backport of JDK-8260378. This would be a follow-
up fix test-fix for JDK-8258836 which applies cleanly. The only
difference to the JDK head fix is the omission of the ProblemList-
zgc.txt hunk as the test for JDK-8258836 was never problem-listed in
JDK 11u. The intention would be to push JDK-8258836 and JDK-8260378
together (if approved, of course).

Bug: https://bugs.openjdk.java.net/browse/JDK-8260378
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8260378/jdk11/02/webrev/
Original change: https://github.com/openjdk/jdk/commit/af8a08f5

Thoughts?

Thanks,
Severin


From github.com+75672469+larry-n at openjdk.java.net  Mon Feb  1 16:28:57 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Mon, 1 Feb 2021 16:28:57 GMT
Subject: [jdk13u-dev] RFR: 8241478:
 vmTestbase/gc/gctests/Steal/steal001/steal001.java fails with OOME
Message-ID: <UIiJE3Y4c4l2QPLtlkL5zqp4eyHgVU5qHNQjYnR48Oc=.c501cc4c-637b-4118-ac63-9c652c115ea5@github.com>

Backport fix for bug JDK-8241478, tested with tier1 and tier2

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

Commit messages:
 - Backport 931af1260cbe4bd8667555fc9a5e823d68f85716

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/103/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=103&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241478
  Stats: 279 lines in 4 files changed: 0 ins; 279 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/103.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/103/head:pull/103

PR: https://git.openjdk.java.net/jdk13u-dev/pull/103

From github.com+75672469+larry-n at openjdk.java.net  Mon Feb  1 16:35:55 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Mon, 1 Feb 2021 16:35:55 GMT
Subject: [jdk13u-dev] RFR: 8234541: C1 emits an empty message when it inlines
 successfully
Message-ID: <hwDT1Qzce8EFVPwI1PVz4AnL_PmrDr1S9vWACWz9E2o=.c66c99bb-2cae-494f-b4dc-fa406effb9e1@github.com>

Backport fix for bug JDK-8234541. Tested with tier1 and tier2

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

Commit messages:
 - Backport 4e64af81a2ea66313d03b720004667bc7975f6e4

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/104/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=104&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234541
  Stats: 11 lines in 2 files changed: 1 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/104/head:pull/104

PR: https://git.openjdk.java.net/jdk13u-dev/pull/104

From thartmann at openjdk.java.net  Tue Feb  2 06:52:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:52:48 GMT
Subject: [jdk16u] RFR: 8258946: Fix optimization-unstable code involving
 signed integer overflow
In-Reply-To: <LX8BFiRRWcvnjfzmL9Jl7qduUF8VTP5UrKcRRhQUiU0=.99fca85b-948f-4cf4-84b4-6726862f8faa@github.com>
References: <xl5HOFF8PJRySO8TxY-lvPxm7VVH9zUniy8df3BPCYQ=.e94b13c9-271a-4fc4-89b6-3d9a8f973da2@github.com>
 <LX8BFiRRWcvnjfzmL9Jl7qduUF8VTP5UrKcRRhQUiU0=.99fca85b-948f-4cf4-84b4-6726862f8faa@github.com>
Message-ID: <lgXQB2sjconSdqsEG6h0uxMx3X4GZdVdjAN_PuZM6Bk=.4e84b2b5-6198-4d26-b63f-0df1eb7dd56d@github.com>

On Mon, 1 Feb 2021 15:58:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8258946](https://bugs.openjdk.java.net/browse/JDK-8258946). Applies cleanly.
>
> Good.

Thanks for the review, Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/9

From thartmann at openjdk.java.net  Tue Feb  2 06:52:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:52:48 GMT
Subject: [jdk16u] Integrated: 8258946: Fix optimization-unstable code
 involving signed integer overflow
In-Reply-To: <xl5HOFF8PJRySO8TxY-lvPxm7VVH9zUniy8df3BPCYQ=.e94b13c9-271a-4fc4-89b6-3d9a8f973da2@github.com>
References: <xl5HOFF8PJRySO8TxY-lvPxm7VVH9zUniy8df3BPCYQ=.e94b13c9-271a-4fc4-89b6-3d9a8f973da2@github.com>
Message-ID: <Qik-2GrEsgIQ3nzUwho3xHemwOO6VbzotlkXU8F2gVs=.27378086-178c-4e77-9c73-7f525108cc57@github.com>

On Mon, 1 Feb 2021 14:55:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8258946](https://bugs.openjdk.java.net/browse/JDK-8258946). Applies cleanly.

This pull request has now been integrated.

Changeset: 62e53c8d
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/62e53c8d
Stats:     10 lines in 3 files changed: 0 ins; 0 del; 10 mod

8258946: Fix optimization-unstable code involving signed integer overflow

Reviewed-by: kvn
Backport-of: dd8996c5f5784b18a01a86354e3ccaae1f86adae

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

PR: https://git.openjdk.java.net/jdk16u/pull/9

From thartmann at openjdk.java.net  Tue Feb  2 06:53:44 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:53:44 GMT
Subject: [jdk16u] RFR: 8258243: C2: assert failed ("Bad derived pointer")
 with -XX:+VerifyRegisterAllocator
In-Reply-To: <MD6IuYgkROxkwfXPpnjh7bnho_ZkHETzVA39DCSRjeY=.b8dbc53e-adea-4042-9cd7-d1719293996a@github.com>
References: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
 <MD6IuYgkROxkwfXPpnjh7bnho_ZkHETzVA39DCSRjeY=.b8dbc53e-adea-4042-9cd7-d1719293996a@github.com>
Message-ID: <8BGLOwVSb91mMPYbKBmbYxrnhu8sZk0PcxmPGPSyil0=.7d7c5822-5c98-4e1d-9399-c4deade302c0@github.com>

On Mon, 1 Feb 2021 15:59:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8258243](https://bugs.openjdk.java.net/browse/JDK-8258243). Applies cleanly.
>
> Good.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/10

From thartmann at openjdk.java.net  Tue Feb  2 06:53:49 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:53:49 GMT
Subject: [jdk16u] RFR: 8259576: Misplaced curly brace in
 Matcher::find_shared_post_visit
In-Reply-To: <PWe0c6fuKnDN-Nl09eeN-TCSK_fsVoHjjCo_tpQb6Ok=.13c4f2ae-a592-46a4-a31c-2994fdd7ccac@github.com>
References: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
 <PWe0c6fuKnDN-Nl09eeN-TCSK_fsVoHjjCo_tpQb6Ok=.13c4f2ae-a592-46a4-a31c-2994fdd7ccac@github.com>
Message-ID: <hqFPUKw3r1txuydbmSlm7OkK_iUQOxhXasy9u4kNiBc=.8e813e7e-f681-4c31-af2e-ca1c3e4e7ba8@github.com>

On Mon, 1 Feb 2021 15:59:07 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259576](https://bugs.openjdk.java.net/browse/JDK-8259576). Applies cleanly.
>
> Trivilal.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/11

From thartmann at openjdk.java.net  Tue Feb  2 06:53:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:53:46 GMT
Subject: [jdk16u] Integrated: 8258243: C2: assert failed ("Bad derived
 pointer") with -XX:+VerifyRegisterAllocator
In-Reply-To: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
References: <0H6sOQXxBtoPj7T7wTgM73PCoGVeXAfV4ftYqA893Q0=.1bad944f-f27a-4e24-98e8-da86bf2b0dc0@github.com>
Message-ID: <9xJzmKs31wiNgb7E8GbhRK7e1VIF_HlZAcE-OXhe0lg=.f8779daa-18be-4847-b96b-ff55d7e917ef@github.com>

On Mon, 1 Feb 2021 14:58:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8258243](https://bugs.openjdk.java.net/browse/JDK-8258243). Applies cleanly.

This pull request has now been integrated.

Changeset: 19b86c4b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/19b86c4b
Stats:     43 lines in 2 files changed: 40 ins; 0 del; 3 mod

8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator

Reviewed-by: vlivanov, kvn
Backport-of: a3561ae8a435dba7d4127090b4a447f8216b01e9

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

PR: https://git.openjdk.java.net/jdk16u/pull/10

From thartmann at openjdk.java.net  Tue Feb  2 06:53:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:53:50 GMT
Subject: [jdk16u] Integrated: 8259576: Misplaced curly brace in
 Matcher::find_shared_post_visit
In-Reply-To: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
References: <jDkoOCsDU18CiTn-KnJlV0Vk28L34b8TaInA4164a80=.5253090f-39fd-433e-8260-573a7e024f2e@github.com>
Message-ID: <hAkTgkt2IT0frxSmghfumEKxlfcnaEZAzZzFH1cg4f4=.6eeacbad-ae9f-4255-bcc6-50de57f4c238@github.com>

On Mon, 1 Feb 2021 15:01:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259576](https://bugs.openjdk.java.net/browse/JDK-8259576). Applies cleanly.

This pull request has now been integrated.

Changeset: f8af3b55
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/f8af3b55
Stats:     2 lines in 1 file changed: 1 ins; 1 del; 0 mod

8259576: Misplaced curly brace in Matcher::find_shared_post_visit

Reviewed-by: vlivanov, kvn
Backport-of: 4697cfa4b01792c04becba3632833559e4b755b7

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

PR: https://git.openjdk.java.net/jdk16u/pull/11

From thartmann at openjdk.java.net  Tue Feb  2 06:54:43 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:54:43 GMT
Subject: [jdk16u] RFR: 8259777: Incorrect predication condition generated
 by ADLC
In-Reply-To: <8FE0W1b0qEGMGNMbkPHHvXLr-9yAaN_H7vPYTwCSv9A=.842a4b03-e8bb-475c-80cd-8b8d6755b096@github.com>
References: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
 <8FE0W1b0qEGMGNMbkPHHvXLr-9yAaN_H7vPYTwCSv9A=.842a4b03-e8bb-475c-80cd-8b8d6755b096@github.com>
Message-ID: <PSoLZl2Cg0gwEeTnquOnBDhBejkVHe9anowScn0NFkc=.6a6183a0-9255-4be4-b2c3-5569b4c5a439@github.com>

On Mon, 1 Feb 2021 16:01:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259777](https://bugs.openjdk.java.net/browse/JDK-8259777). Applies cleanly.
>
> Good.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/14

From thartmann at openjdk.java.net  Tue Feb  2 06:54:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:54:45 GMT
Subject: [jdk16u] Integrated: 8259777: Incorrect predication condition
 generated by ADLC
In-Reply-To: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
References: <UDw6S1umAoajaDFIm3UGKa60DpyHUrO8EY8dn3UdgV0=.07f2ee05-7e46-43fa-988e-2b34f2bf374b@github.com>
Message-ID: <rqQ0qlu_UDtLen-kI-ZXxEc274Hna_VjMQKWLUySCH8=.da4a83f5-a078-4fc7-9725-531e2ce0b3d0@github.com>

On Mon, 1 Feb 2021 15:13:38 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259777](https://bugs.openjdk.java.net/browse/JDK-8259777). Applies cleanly.

This pull request has now been integrated.

Changeset: cddbb158
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/cddbb158
Stats:     26 lines in 2 files changed: 15 ins; 0 del; 11 mod

8259777: Incorrect predication condition generated by ADLC

Reviewed-by: vlivanov, kvn
Backport-of: bcf20a0dcc752707881d3b4da25712d3ef4e93ff

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

PR: https://git.openjdk.java.net/jdk16u/pull/14

From thartmann at openjdk.java.net  Tue Feb  2 06:55:44 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:55:44 GMT
Subject: [jdk16u] RFR: 8259773: Incorrect encoding of AVX-512 kmovq
 instruction
In-Reply-To: <7TUqwMZ_XYWBYGJt_hRGdXLWq86MPiwxXhj9mL2ELYM=.d2370ff0-fb69-4121-aa59-e2e1442a5c26@github.com>
References: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
 <7TUqwMZ_XYWBYGJt_hRGdXLWq86MPiwxXhj9mL2ELYM=.d2370ff0-fb69-4121-aa59-e2e1442a5c26@github.com>
Message-ID: <W5ggDxT0HA1UMcOGKQVok4WrA2WVWVeg-uhWY3WPWfY=.8ee218b3-2609-4c59-817b-05bc429cb2b5@github.com>

On Mon, 1 Feb 2021 16:00:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259773](https://bugs.openjdk.java.net/browse/JDK-8259773). Applies cleanly.
>
> Good.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/13

From thartmann at openjdk.java.net  Tue Feb  2 06:55:44 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:55:44 GMT
Subject: [jdk16u] RFR: 8260338: Some fields in HaltNode is not cloned
In-Reply-To: <Ye8pDxojMMpYV8bYULHEQrgYFIMFlgZce_vvq_r-5JA=.ca992abb-222c-49b4-b556-dd75bd126ecb@github.com>
References: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
 <Ye8pDxojMMpYV8bYULHEQrgYFIMFlgZce_vvq_r-5JA=.ca992abb-222c-49b4-b556-dd75bd126ecb@github.com>
Message-ID: <aSVRQC7iBp497edB-wq0ePdTENLvKKv_K_wkUnqYyB0=.9fa70544-6538-4c49-86a3-daec50c447f3@github.com>

On Mon, 1 Feb 2021 16:01:53 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8260338](https://bugs.openjdk.java.net/browse/JDK-8260338). Applies cleanly.
>
> Good.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/15

From thartmann at openjdk.java.net  Tue Feb  2 06:55:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:55:45 GMT
Subject: [jdk16u] RFR: 8259619: C1: 3-arg StubAssembler::call_RT stack-use
 condition is incorrect
In-Reply-To: <kcCbTzXqoCWMm1ZxCDJHGcDufC_1h1BCOhDg1kD_5FA=.08017543-2a64-421f-ac12-fd456fa0cabd@github.com>
References: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
 <kcCbTzXqoCWMm1ZxCDJHGcDufC_1h1BCOhDg1kD_5FA=.08017543-2a64-421f-ac12-fd456fa0cabd@github.com>
Message-ID: <7zkGyNhgI16lQXvO8UBrRc9B2I1PF4f0UTPsfHVLX20=.45de8615-3f43-4a50-bb73-0385b222b274@github.com>

On Mon, 1 Feb 2021 16:00:10 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259619](https://bugs.openjdk.java.net/browse/JDK-8259619). Applies cleanly.
>
> Good.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/12

From thartmann at openjdk.java.net  Tue Feb  2 06:55:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:55:46 GMT
Subject: [jdk16u] Integrated: 8260338: Some fields in HaltNode is not cloned
In-Reply-To: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
References: <Fv568fqbC-6Lmst-hD3y1QD1J1YpiJj7CL_pXDg1F0Q=.e0b66fd2-3a31-4e52-a107-95c21e1235e2@github.com>
Message-ID: <VvFmL86t0xohX8qieRgNYhIL2AF3EtAOuQUw7UYrVvk=.7dae5b58-13d6-4729-9c00-1aee8d0936b5@github.com>

On Mon, 1 Feb 2021 15:19:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8260338](https://bugs.openjdk.java.net/browse/JDK-8260338). Applies cleanly.

This pull request has now been integrated.

Changeset: 9d4171ff
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/9d4171ff
Stats:     5 lines in 2 files changed: 3 ins; 0 del; 2 mod

8260338: Some fields in HaltNode is not cloned

Reviewed-by: vlivanov, kvn
Backport-of: 09489e28bd2a5c5d09e5a651c6889fc1179629e5

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

PR: https://git.openjdk.java.net/jdk16u/pull/15

From thartmann at openjdk.java.net  Tue Feb  2 06:55:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:55:45 GMT
Subject: [jdk16u] Integrated: 8259773: Incorrect encoding of AVX-512 kmovq
 instruction
In-Reply-To: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
References: <SD_MgFFsLvyg91qQIcyYV8pbP7aV5wZN2u-z4rpxmbI=.e08a9981-3e14-4689-bccd-967dc49e5c9a@github.com>
Message-ID: <B2-sS487CVoPkzXeoRrzDQ0eFpG5O7CHiu6bPkZFZxg=.5de69ec2-7833-4e3e-b48b-648b38eb8f9d@github.com>

On Mon, 1 Feb 2021 15:09:25 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259773](https://bugs.openjdk.java.net/browse/JDK-8259773). Applies cleanly.

This pull request has now been integrated.

Changeset: 625a3846
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/625a3846
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8259773: Incorrect encoding of AVX-512 kmovq instruction

Reviewed-by: vlivanov, kvn
Backport-of: ff3e6e46cd2b830e8656934d68e14f89b9095cda

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

PR: https://git.openjdk.java.net/jdk16u/pull/13

From thartmann at openjdk.java.net  Tue Feb  2 06:55:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:55:47 GMT
Subject: [jdk16u] Integrated: 8259619: C1: 3-arg StubAssembler::call_RT
 stack-use condition is incorrect
In-Reply-To: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
References: <AjQ11aUJCEHMLK5hkNVndUyJwT0cAchzEXjvmvbduvU=.03a2b144-bc28-4581-bba9-67d4da118eef@github.com>
Message-ID: <1I3qDsrs0F9_px9fkAo6h1y4qqKeG01j7zaFdbPCJVI=.177a9bd2-2129-498d-b25a-e19b14326fc8@github.com>

On Mon, 1 Feb 2021 15:04:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259619](https://bugs.openjdk.java.net/browse/JDK-8259619). Applies cleanly.

This pull request has now been integrated.

Changeset: 58ff0df2
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/58ff0df2
Stats:     4 lines in 2 files changed: 0 ins; 0 del; 4 mod

8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect

Reviewed-by: vlivanov, kvn
Backport-of: ce9451208772534efd532a6bc44c226a419f570d

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

PR: https://git.openjdk.java.net/jdk16u/pull/12

From thartmann at openjdk.java.net  Tue Feb  2 06:56:51 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:56:51 GMT
Subject: [jdk16u] RFR: 8257513: C2: assert((constant_addr -
 _masm.code()->consts()->start()) == con.offset())
In-Reply-To: <h6lqjxrlPPDBvrpkz1FPLdl6Hxtyusi0qDfD6Tfw7Qs=.d969144b-c493-4f71-baf4-c03a5faee7a2@github.com>
References: <ynl8pfCGDJkrHkKZe-hyvFNJD4gEtjP2m2FzVlMWBcs=.1704e7d1-9056-495c-af60-bfd2cd5f273b@github.com>
 <h6lqjxrlPPDBvrpkz1FPLdl6Hxtyusi0qDfD6Tfw7Qs=.d969144b-c493-4f71-baf4-c03a5faee7a2@github.com>
Message-ID: <L-bqUheQNfbaxNsHw7lDULPNPdDPpd8x6UAxtAU70Jk=.d4edd0ad-1832-4c35-b54d-58c955539c23@github.com>

On Mon, 1 Feb 2021 15:45:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8257513](https://bugs.openjdk.java.net/browse/JDK-8257513). Applies cleanly.
>
> Good.

Thanks for the review, Vladimir. I've accidentally linked the wrong JBS issue (JDK-8259049 instead of JDK-8257513). Updating.

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

PR: https://git.openjdk.java.net/jdk16u/pull/17

From thartmann at openjdk.java.net  Tue Feb  2 06:57:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:57:47 GMT
Subject: [jdk16u] RFR: 8259339: AllocateUninitializedArray C2 intrinsic
 fails with void.class input
In-Reply-To: <tyiORaVu1XyokTJ10bSgpS7YxznD8v31NfFejAlYS4g=.a0c584be-a266-4a78-b465-b370436cc40e@github.com>
References: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
 <tyiORaVu1XyokTJ10bSgpS7YxznD8v31NfFejAlYS4g=.a0c584be-a266-4a78-b465-b370436cc40e@github.com>
Message-ID: <O_Of_YhXPtbadu8PLapRvgkoY0Al61y_E1cXbyqvI28=.8bb5905a-d099-47eb-8b7e-dc0ae9397dc4@github.com>

On Mon, 1 Feb 2021 15:43:06 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339). Applies cleanly.
>
> Good.

Thanks for the reviews, Vladimir and Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/16

From thartmann at openjdk.java.net  Tue Feb  2 06:57:48 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 06:57:48 GMT
Subject: [jdk16u] Integrated: 8259339: AllocateUninitializedArray C2 intrinsic
 fails with void.class input
In-Reply-To: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
References: <q6fkOBpiIxkcSRm-iCLDuBwgZyPPTdDQ53rh9wEVSLM=.8857b3bd-388c-4406-95e1-3533289f626a@github.com>
Message-ID: <5Fvn2vA0b4EOVRaikjAgj8TCrDuE7gZblo9iUtO7eTc=.e158ad2f-0877-4e15-9af3-b5ecc8f41b1e@github.com>

On Mon, 1 Feb 2021 15:23:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259339](https://bugs.openjdk.java.net/browse/JDK-8259339). Applies cleanly.

This pull request has now been integrated.

Changeset: 5c948e71
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/5c948e71
Stats:     20 lines in 2 files changed: 16 ins; 0 del; 4 mod

8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input

Reviewed-by: vlivanov, kvn
Backport-of: 0e6de4eb5759ec4c6d8583bd77c3c96b9f34be01

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

PR: https://git.openjdk.java.net/jdk16u/pull/16

From thartmann at openjdk.java.net  Tue Feb  2 07:00:50 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:00:50 GMT
Subject: [jdk16u] Integrated: 8257513: C2: assert((constant_addr -
 _masm.code()->consts()->start()) == con.offset())
In-Reply-To: <ynl8pfCGDJkrHkKZe-hyvFNJD4gEtjP2m2FzVlMWBcs=.1704e7d1-9056-495c-af60-bfd2cd5f273b@github.com>
References: <ynl8pfCGDJkrHkKZe-hyvFNJD4gEtjP2m2FzVlMWBcs=.1704e7d1-9056-495c-af60-bfd2cd5f273b@github.com>
Message-ID: <VU5W12_bQAQBFo-RJ5h0LjOuHAFyh1yx_O8gtrufnfM=.c1687bee-aeba-4536-a251-ff7b417598c2@github.com>

On Mon, 1 Feb 2021 15:31:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8257513](https://bugs.openjdk.java.net/browse/JDK-8257513). Applies cleanly.

This pull request has now been integrated.

Changeset: 96f427f5
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/96f427f5
Stats:     91 lines in 4 files changed: 82 ins; 0 del; 9 mod

8257513: C2: assert((constant_addr - _masm.code()->consts()->start()) == con.offset())

Reviewed-by: kvn
Backport-of: 9f1516492c20f52f249d7389f4058d8978faed9f

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

PR: https://git.openjdk.java.net/jdk16u/pull/17

From thartmann at openjdk.java.net  Tue Feb  2 07:29:55 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:29:55 GMT
Subject: [jdk16u] RFR: 8259049: Uninitialized variable after JDK-8257513
Message-ID: <iLLG6A0qLJ6_14LkIwPkNzhtX6xlcgOv19gA8eWhpkk=.447a7c2f-d774-4fd9-85ed-74cee275dbf4@github.com>

Backport of [JDK-8259049](https://bugs.openjdk.java.net/browse/JDK-8259049). Applies cleanly.

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

Commit messages:
 - 8259049: Uninitialized variable after JDK-8257513

Changes: https://git.openjdk.java.net/jdk16u/pull/18/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=18&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259049
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/18.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/18/head:pull/18

PR: https://git.openjdk.java.net/jdk16u/pull/18

From thartmann at openjdk.java.net  Tue Feb  2 07:39:05 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:39:05 GMT
Subject: [jdk16u] RFR: 8259706: C2 compilation fails with assert(vtable_index
 == Method::invalid_vtable_index) failed: correct sentinel value
Message-ID: <hr7VqIa4p7hSF-Ip34FDTijSowuclD4GJ0n3cMuyZHg=.3748fce2-5ab4-4986-95c2-7a024561f919@github.com>

Backport of [JDK-8259706](https://bugs.openjdk.java.net/browse/JDK-8259706). Applies cleanly.

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

Commit messages:
 - 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value

Changes: https://git.openjdk.java.net/jdk16u/pull/19/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=19&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259706
  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/19.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/19/head:pull/19

PR: https://git.openjdk.java.net/jdk16u/pull/19

From kvn at openjdk.java.net  Tue Feb  2 07:42:43 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 2 Feb 2021 07:42:43 GMT
Subject: [jdk16u] RFR: 8259049: Uninitialized variable after JDK-8257513
In-Reply-To: <iLLG6A0qLJ6_14LkIwPkNzhtX6xlcgOv19gA8eWhpkk=.447a7c2f-d774-4fd9-85ed-74cee275dbf4@github.com>
References: <iLLG6A0qLJ6_14LkIwPkNzhtX6xlcgOv19gA8eWhpkk=.447a7c2f-d774-4fd9-85ed-74cee275dbf4@github.com>
Message-ID: <9dJ5JpONDYG3OzF0FNJkaoqPRhaI0FbJ5Zcn0dbN6R0=.431b4bcc-46bb-4b58-a1c4-6c5beca11ac6@github.com>

On Tue, 2 Feb 2021 07:25:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259049](https://bugs.openjdk.java.net/browse/JDK-8259049). Applies cleanly.

Trivial.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/18

From kvn at openjdk.java.net  Tue Feb  2 07:44:48 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 2 Feb 2021 07:44:48 GMT
Subject: [jdk16u] RFR: 8259706: C2 compilation fails with
 assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel
 value
In-Reply-To: <hr7VqIa4p7hSF-Ip34FDTijSowuclD4GJ0n3cMuyZHg=.3748fce2-5ab4-4986-95c2-7a024561f919@github.com>
References: <hr7VqIa4p7hSF-Ip34FDTijSowuclD4GJ0n3cMuyZHg=.3748fce2-5ab4-4986-95c2-7a024561f919@github.com>
Message-ID: <QKhkL0xJ30TEz_1NgLY4A04BOVquLhKShxRhagpm0tI=.9ec7e2be-ac26-48f3-8efb-527a6fa863be@github.com>

On Tue, 2 Feb 2021 07:33:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259706](https://bugs.openjdk.java.net/browse/JDK-8259706). Applies cleanly.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/19

From thartmann at openjdk.java.net  Tue Feb  2 07:47:45 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:47:45 GMT
Subject: [jdk16u] RFR: 8259706: C2 compilation fails with
 assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel
 value
In-Reply-To: <QKhkL0xJ30TEz_1NgLY4A04BOVquLhKShxRhagpm0tI=.9ec7e2be-ac26-48f3-8efb-527a6fa863be@github.com>
References: <hr7VqIa4p7hSF-Ip34FDTijSowuclD4GJ0n3cMuyZHg=.3748fce2-5ab4-4986-95c2-7a024561f919@github.com>
 <QKhkL0xJ30TEz_1NgLY4A04BOVquLhKShxRhagpm0tI=.9ec7e2be-ac26-48f3-8efb-527a6fa863be@github.com>
Message-ID: <1H6-6jcJIRjarFYZRjh-7RXS9ZJU9yLU4WtvR2ZV-kA=.728e72a7-0a1c-4be7-a3c0-ed5a23f3d4a1@github.com>

On Tue, 2 Feb 2021 07:41:31 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259706](https://bugs.openjdk.java.net/browse/JDK-8259706). Applies cleanly.
>
> Good.

Thanks Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/19

From thartmann at openjdk.java.net  Tue Feb  2 07:47:46 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:47:46 GMT
Subject: [jdk16u] RFR: 8259049: Uninitialized variable after JDK-8257513
In-Reply-To: <9dJ5JpONDYG3OzF0FNJkaoqPRhaI0FbJ5Zcn0dbN6R0=.431b4bcc-46bb-4b58-a1c4-6c5beca11ac6@github.com>
References: <iLLG6A0qLJ6_14LkIwPkNzhtX6xlcgOv19gA8eWhpkk=.447a7c2f-d774-4fd9-85ed-74cee275dbf4@github.com>
 <9dJ5JpONDYG3OzF0FNJkaoqPRhaI0FbJ5Zcn0dbN6R0=.431b4bcc-46bb-4b58-a1c4-6c5beca11ac6@github.com>
Message-ID: <xagbf8M3lNxOQr0Y-R4uJzGQGp7PQKpqJaE5bDOG6uI=.92a944b6-4fa6-48a1-9379-05b2fd92b40c@github.com>

On Tue, 2 Feb 2021 07:39:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Backport of [JDK-8259049](https://bugs.openjdk.java.net/browse/JDK-8259049). Applies cleanly.
>
> Trivial.

Thanks Vladimir!

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

PR: https://git.openjdk.java.net/jdk16u/pull/18

From thartmann at openjdk.java.net  Tue Feb  2 07:47:47 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 07:47:47 GMT
Subject: [jdk16u] Integrated: 8259049: Uninitialized variable after JDK-8257513
In-Reply-To: <iLLG6A0qLJ6_14LkIwPkNzhtX6xlcgOv19gA8eWhpkk=.447a7c2f-d774-4fd9-85ed-74cee275dbf4@github.com>
References: <iLLG6A0qLJ6_14LkIwPkNzhtX6xlcgOv19gA8eWhpkk=.447a7c2f-d774-4fd9-85ed-74cee275dbf4@github.com>
Message-ID: <Oikob8Ngd1Ol9U_ZQHJkvGPlWctrQ2peKf0OUZ-J7TY=.74f6fb08-3b7b-43ad-957d-3c7776203700@github.com>

On Tue, 2 Feb 2021 07:25:00 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259049](https://bugs.openjdk.java.net/browse/JDK-8259049). Applies cleanly.

This pull request has now been integrated.

Changeset: c059d743
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/c059d743
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8259049: Uninitialized variable after JDK-8257513

Reviewed-by: kvn
Backport-of: 9f1516492c20f52f249d7389f4058d8978faed9f

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

PR: https://git.openjdk.java.net/jdk16u/pull/18

From thartmann at openjdk.java.net  Tue Feb  2 09:22:43 2021
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 2 Feb 2021 09:22:43 GMT
Subject: [jdk16u] Integrated: 8259706: C2 compilation fails with
 assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel
 value
In-Reply-To: <hr7VqIa4p7hSF-Ip34FDTijSowuclD4GJ0n3cMuyZHg=.3748fce2-5ab4-4986-95c2-7a024561f919@github.com>
References: <hr7VqIa4p7hSF-Ip34FDTijSowuclD4GJ0n3cMuyZHg=.3748fce2-5ab4-4986-95c2-7a024561f919@github.com>
Message-ID: <CACCNatau1GLLdB0iKQBVUUxyF0E0LU2qxfCmzWddZc=.145f1ac1-f045-4a26-b8e7-441eb594c77a@github.com>

On Tue, 2 Feb 2021 07:33:05 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Backport of [JDK-8259706](https://bugs.openjdk.java.net/browse/JDK-8259706). Applies cleanly.

This pull request has now been integrated.

Changeset: 684f6c38
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/684f6c38
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value

Reviewed-by: kvn
Backport-of: 8b8b1f9a37d8606848e40aede006db8129cdac39

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

PR: https://git.openjdk.java.net/jdk16u/pull/19

From evergizova at openjdk.java.net  Tue Feb  2 10:21:46 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Tue, 2 Feb 2021 10:21:46 GMT
Subject: [jdk13u-dev] Integrated: 8236772: Fix build for windows 32-bit after
 8212160 and 8234331.
In-Reply-To: <DXIexkzGNOsH-8cezoQExuyqH8L0Clf_Qr0bbJEx-4A=.db6bfe45-a2c3-4d25-8f73-f55eb35a8c4c@github.com>
References: <DXIexkzGNOsH-8cezoQExuyqH8L0Clf_Qr0bbJEx-4A=.db6bfe45-a2c3-4d25-8f73-f55eb35a8c4c@github.com>
Message-ID: <7b2AKPa9nAUco3LTMpiS8anJAfYeS-gZk4ovdv-OohU=.85a5275b-9707-4e76-a6bf-32247dd0335c@github.com>

On Fri, 29 Jan 2021 12:35:11 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport 8236772 to 13u as follow-up fix for JDK-8212160 that is already included to 13u.
> The original patch contains two independent follow-up fixes for JDK-8212160 and JDK-8234331.
> JDK-8234331 is not planned to be included to 13u, so only the part related to JDK-8212160 is backported.
> libCompiledZombie test library is built successfully for Windows 32-bit after applying the patch.

This pull request has now been integrated.

Changeset: 186e8b29
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/186e8b29
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8236772: Fix build for windows 32-bit after 8212160 and 8234331.

Reviewed-by: yan
Backport-of: d6a2a079d16feead9ec5b897d098f659271dbc64

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/99

From yan at azul.com  Tue Feb  2 15:55:54 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Tue, 2 Feb 2021 18:55:54 +0300
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
Message-ID: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>

I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer

In the last year Ekaterina did some 84 commits [1] to the various OpenJDK projects.
To jdk13u only she backported 48 fixes (that, including this year's activity).
In plans is even more active participation in OpenJDK, and making her a Committer
would help us all by avoiding the need for someone else to push her fixes.

Votes are due by 16h00 UTC on the 16th of Feb, 2021.

Only current OpenJDK Updates Committers (and above)  [2] are eligible
to vote on this nomination. Votes must be cast in the open by replying
to this mailing list.

For Three-Vote Consensus voting instructions, see [3].

[0] https://openjdk.java.net/census#evergizova
[1] https://github.com/kvergizova
[2] https://openjdk.java.net/census#jdk-updates
[3] http://openjdk.java.net/projects/#committer-vote

Thank you,
 --yan


From dalibor.topic at oracle.com  Tue Feb  2 16:48:10 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Tue, 2 Feb 2021 17:48:10 +0100
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <6ae34e36-fa94-c271-dacc-856a5a625ae2@oracle.com>

Vote: Yes.

On 02.02.2021 16:55, Yuri Nesterenko wrote:
> I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer
>
> In the last year Ekaterina did some 84 commits [1] to the various OpenJDK projects.
> To jdk13u only she backported 48 fixes (that, including this year's activity).
> In plans is even more active participation in OpenJDK, and making her a Committer
> would help us all by avoiding the need for someone else to push her fixes.
>
> Votes are due by 16h00 UTC on the 16th of Feb, 2021.
>
> Only current OpenJDK Updates Committers (and above)  [2] are eligible
> to vote on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#evergizova
> [1] https://github.com/kvergizova
> [2] https://openjdk.java.net/census#jdk-updates
> [3] http://openjdk.java.net/projects/#committer-vote
>
> Thank you,
>   --yan
>
-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961 
<tel:+491737185961>, Video: dalibor.topic at oracle.com 
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From vladimir.kozlov at oracle.com  Tue Feb  2 17:26:31 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 2 Feb 2021 09:26:31 -0800
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <2daa849d-9a56-0650-e0f9-8f10e804c8b1@oracle.com>

Vote: yes

Thanks,
Vladimir K

On 2/2/21 7:55 AM, Yuri Nesterenko wrote:
> I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer
> 
> In the last year Ekaterina did some 84 commits [1] to the various OpenJDK projects.
> To jdk13u only she backported 48 fixes (that, including this year's activity).
> In plans is even more active participation in OpenJDK, and making her a Committer
> would help us all by avoiding the need for someone else to push her fixes.
> 
> Votes are due by 16h00 UTC on the 16th of Feb, 2021.
> 
> Only current OpenJDK Updates Committers (and above)  [2] are eligible
> to vote on this nomination. Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [3].
> 
> [0] https://openjdk.java.net/census#evergizova
> [1] https://github.com/kvergizova
> [2] https://openjdk.java.net/census#jdk-updates
> [3] http://openjdk.java.net/projects/#committer-vote
> 
> Thank you,
>   --yan
> 

From serguei.spitsyn at oracle.com  Tue Feb  2 17:44:01 2021
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 2 Feb 2021 17:44:01 +0000
Subject: New OpenJDK Updates Committer: Ekaterina Vergizova
Message-ID: <39DBD6BF-F7B8-4784-A84D-D81AD26EB7F9@oracle.com>

Vote: yes 


From martin.doerr at sap.com  Tue Feb  2 20:28:18 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 2 Feb 2021 20:28:18 +0000
Subject: [11u] RFR: 8244683: A TSA server used by tests
Message-ID: <AM4PR02MB3057F599C7D20D24E3B238889AB59@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

JDK-8244683 is backported to 11.0.11-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

TimestampCheck.java:
- The parts which get removed contain minor differences (see [1])
- Resolution: Take new version.

TsaHandler.java and TsaSigner.java:
- New code contains usages of KnownOIDs which don't exist in 11u.
- Resolution: Translate them (see [2])

TsaSigner.java:
- New code uses ObjectIdentifier.of
- Resolution: Change back to "new ObjectIdentifier" according to [1]
- Uses HexPrinter (for debug code) which doesn't exist in 11u.
- Resolution: Use HexDumpEncoder instead: System.out.println(new HexDumpEncoder().encode(bytes));

An additional testfix is needed:
https://bugs.openjdk.java.net/browse/JDK-8246709
which applies cleanly except that it needs an import change (see [3]).
That change is not included in the webrev. I just want to push 11u backport of 8244683 together with 8246709 (including [3]) together.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8244683

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/56bda3e6d148

11u backport:
http://cr.openjdk.java.net/~mdoerr/8244683_TSA_11u/webrev.00/

Please review.

Best regards,
Martin


[1] diff JDK11u:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java JDK16:TimestampCheck_before_8244683.java
65a66
>  *          8242151
137c138
<             ObjectIdentifier policyId = new ObjectIdentifier(defaultPolicyId);
---
>             ObjectIdentifier policyId = ObjectIdentifier.of(defaultPolicyId);
161c162
<                 policyId = new ObjectIdentifier(defaultPolicyId);
---
>                 policyId = ObjectIdentifier.of(defaultPolicyId);
233c234
<             ContentInfo contentInfo = new ContentInfo(new ObjectIdentifier(
---
>             ContentInfo contentInfo = new ContentInfo(ObjectIdentifier.of(

[2] KnownOIDs Translation:
https://github.com/openjdk/jdk/commit/080b3b83ebffe5149fbc9ac48e921fb51e9c3c63#diff-e6d5bd6b166be4737084473fcf55b0f101a710263c899c19b0df2a702c89a30e

[3] diff JDK16:TSA_testfix_orig.patch resolved_JDK11u:8246709_TSA.patch
<  import jdk.test.lib.process.OutputAnalyzer;
---
>  import jdk.testlibrary.OutputAnalyzer;


From martin.doerr at sap.com  Tue Feb  2 20:35:27 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 2 Feb 2021 20:35:27 +0000
Subject: [11u] RFR: 8247691: [aarch64] Incorrect handling of VM exceptions
 in C1 deopt stub/traps
In-Reply-To: <8e911df9-426d-d3dd-b500-c2a9108caa1b@redhat.com>
References: <AM4PR02MB3057E0F28320A6558C3D81279AA20@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR02MB3057FC293ED98B88977EB0779AA10@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <8e911df9-426d-d3dd-b500-c2a9108caa1b@redhat.com>
Message-ID: <AM4PR02MB3057F50F96D42703FC85020D9AB59@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Andrew,

did you see my reproduction hints in the comments in the issue?
https://bugs.openjdk.java.net/browse/JDK-8247691

We can't take it as it is. Would it make sense to use JRT_ENTRY_NO_ASYNC?

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Donnerstag, 21. Januar 2021 14:15
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR: 8247691: [aarch64] Incorrect handling of VM
> exceptions in C1 deopt stub/traps
> 
> On 21/01/2021 10:26, Doerr, Martin wrote:
> > This change doesn't seem to be ready for backport, yet.
> > I've added a comment to the bug.
> 
> Thanks. If you can get me a reproducer I'll fix it.
> 
> --
> 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 david.holmes at oracle.com  Tue Feb  2 21:17:01 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 3 Feb 2021 07:17:01 +1000
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <ae0cace2-ad98-b2b2-584d-c7b257a7ae92@oracle.com>

Vote: yes

David

On 3/02/2021 1:55 am, Yuri Nesterenko wrote:
> I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer
> 
> In the last year Ekaterina did some 84 commits [1] to the various OpenJDK projects.
> To jdk13u only she backported 48 fixes (that, including this year's activity).
> In plans is even more active participation in OpenJDK, and making her a Committer
> would help us all by avoiding the need for someone else to push her fixes.
> 
> Votes are due by 16h00 UTC on the 16th of Feb, 2021.
> 
> Only current OpenJDK Updates Committers (and above)  [2] are eligible
> to vote on this nomination. Votes must be cast in the open by replying
> to this mailing list.
> 
> For Three-Vote Consensus voting instructions, see [3].
> 
> [0] https://openjdk.java.net/census#evergizova
> [1] https://github.com/kvergizova
> [2] https://openjdk.java.net/census#jdk-updates
> [3] http://openjdk.java.net/projects/#committer-vote
> 
> Thank you,
>   --yan
> 

From harold.seigel at oracle.com  Tue Feb  2 21:27:49 2021
From: harold.seigel at oracle.com (Harold Seigel)
Date: Tue, 2 Feb 2021 16:27:49 -0500
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <7b9bd378-d684-312b-a553-797e88a869f6@oracle.com>

Vote: Yes

Harold

On 2/2/2021 10:55 AM, Yuri Nesterenko wrote:
> I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer
>
> In the last year Ekaterina did some 84 commits [1] to the various OpenJDK projects.
> To jdk13u only she backported 48 fixes (that, including this year's activity).
> In plans is even more active participation in OpenJDK, and making her a Committer
> would help us all by avoiding the need for someone else to push her fixes.
>
> Votes are due by 16h00 UTC on the 16th of Feb, 2021.
>
> Only current OpenJDK Updates Committers (and above)  [2] are eligible
> to vote on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#evergizova
> [1] https://github.com/kvergizova
> [2] https://openjdk.java.net/census#jdk-updates
> [3] http://openjdk.java.net/projects/#committer-vote
>
> Thank you,
>   --yan
>

From Divino.Cesar at microsoft.com  Wed Feb  3 01:43:42 2021
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Wed, 3 Feb 2021 01:43:42 +0000
Subject: [11u] RFR (XS): Add compiler/c2/Test8004741.java to Problem list
In-Reply-To: <BY5PR21MB1473ED305AFCF8B2DA5199959AA19@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB1473ED305AFCF8B2DA5199959AA19@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <BY5PR21MB14738E5BB27592F5730438059AB49@BY5PR21MB1473.namprd21.prod.outlook.com>

Gentle ping. Can someone PTAL?
________________________________
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas <Divino.Cesar at microsoft.com>
Sent: January 21, 2021 3:15 PM
To: jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Subject: [11u] RFR (XS): Add compiler/c2/Test8004741.java to Problem list

Related to this issue: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8235801&amp;data=04%7C01%7Cdivino.cesar%40microsoft.com%7Cc209173a22344265160808d8be628179%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637468677578394639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=0fOEOavyZuWEFd4zrFTxqwtZtpwPAb7%2B0JfabGH5Le4%3D&amp;reserved=0
Backport of this patch: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8238930&amp;data=04%7C01%7Cdivino.cesar%40microsoft.com%7Cc209173a22344265160808d8be628179%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637468677578394639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7MNLk2qk0rG9yePfz2xUOSu42anFRduW0GyQih39ykY%3D&amp;reserved=0

Can you please review the trivial patch below to add test compiler/c2/Test8004741.java to hotspot/ProblemList.txt ?


Thank you,
Cesar

# HG changeset patch
# User Cesar Soares <disoares at microsoft.com>
# Date 1611269569 28800
#      Thu Jan 21 14:52:49 2021 -0800
# Node ID 74768c3b73150616747eee1359311777c8455748
# Parent  e0184b812b08b03168f43a1aad81cf857cebc577
problem list compiler/c2/Test8004741.java

diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt
--- a/test/hotspot/jtreg/ProblemList.txt
+++ b/test/hotspot/jtreg/ProblemList.txt
@@ -52,6 +52,7 @@
 compiler/types/correctness/OffTest.java 8066173 generic-all

 compiler/c2/Test6852078.java 8194310 generic-all
+compiler/c2/Test8004741.java 8235801 generic-all

 applications/ctw/modules/java_desktop.java 8189604 windows-all
 applications/ctw/modules/java_desktop_2.java 8189604,8204842 generic-all


From evergizova at openjdk.java.net  Wed Feb  3 07:04:49 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Wed, 3 Feb 2021 07:04:49 GMT
Subject: [jdk13u-dev] RFR: 8239497: SEGV in EdgeUtils::field_name_symbol(Edge
 const&)
Message-ID: <IEuzjmhvYS_A5Np-69RZTeNkF5N5ePNZCEETZMDifnA=.678e0750-d633-4b73-a633-2c33a9c8b24c@github.com>

I'd like to backport 8239497 to 13u for parity with 11u.
The patch doesn't apply cleanly due to context differences in jfr/leakprofiler/chains/edge.cpp and jfr/leakprofiler/chains/edgeUtils.cpp (JDK-8235174 is not in 13u), reapplied manually.
Tested with tier1 and jdk/jfr tests.

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

Commit messages:
 - Backport f2fb5c54ae1c5ca8ed8dfb136b1f967877cc362e

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/105/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=105&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8239497
  Stats: 108 lines in 6 files changed: 23 ins; 47 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/105.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/105/head:pull/105

PR: https://git.openjdk.java.net/jdk13u-dev/pull/105

From hedongbo at huawei.com  Wed Feb  3 09:16:23 2021
From: hedongbo at huawei.com (hedongbo)
Date: Wed, 3 Feb 2021 09:16:23 +0000
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel
Message-ID: <8FC616E5EC1A774287430B1CC2696FE304710E65@dggeml513-mbx.china.huawei.com>

Hi,



Please review the backport of JDK-8246707 to 11u:



Bug: https://bugs.openjdk.java.net/browse/JDK-8246707

Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c8c6030e4d1f

11u webrev: http://cr.openjdk.java.net/~dongbohe/8246707/webrev.00/



This patch doesn't apply cleanly but is fairly trivial. The reason is that the latest jdk8u-dev has no ` blockingRead ` and `blockingWriteFully` function, because they were added in jdk13 through JDK-8222774.




Tested with tier1, tier2. No regression in tests.






Thanks,
dongbohe


From shade at redhat.com  Wed Feb  3 09:43:49 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Feb 2021 10:43:49 +0100
Subject: [11u] RFR (S) 8251944: Add Shenandoah test config to
 compiler/gcbarriers/UnsafeIntrinsicsTest.java
Message-ID: <74f58d15-fdd7-6830-8a66-f3e24c5bdd8a@redhat.com>

Original test improvement:
   https://bugs.openjdk.java.net/browse/JDK-8251944
   https://git.openjdk.java.net/jdk/commit/db6f3930

It does not apply cleanly to 11u, because test still has @requires !graal and ZGC is not yet 
production-ready and needs UnlockExperimentalVMOptions. Otherwise the patch is the same:
   https://cr.openjdk.java.net/~shade/8251944/webrev.11u.01/

Testing: affected test

-- 
Thanks,
-Aleksey


From shade at redhat.com  Wed Feb  3 09:46:00 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Feb 2021 10:46:00 +0100
Subject: [11u] RFR: 8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports
 false positive
In-Reply-To: <e55ecefa13647391860ebc8ffc60ffc1a04b677b.camel@redhat.com>
References: <e55ecefa13647391860ebc8ffc60ffc1a04b677b.camel@redhat.com>
Message-ID: <0af0e5f9-55f5-481d-8461-2c128da5660e@redhat.com>

On 2/1/21 5:21 PM, Severin Gehwolf wrote:
> Hi,
> 
> Please review this 11u backport of JDK-8260378. This would be a follow-
> up fix test-fix for JDK-8258836 which applies cleanly. The only
> difference to the JDK head fix is the omission of the ProblemList-
> zgc.txt hunk as the test for JDK-8258836 was never problem-listed in
> JDK 11u. The intention would be to push JDK-8258836 and JDK-8260378
> together (if approved, of course).
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8260378
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8260378/jdk11/02/webrev/
> Original change: https://github.com/openjdk/jdk/commit/af8a08f5
> 
> Thoughts?

Looks fine to me.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Wed Feb  3 09:57:21 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 03 Feb 2021 10:57:21 +0100
Subject: [11u] RFR: 8260378: [TESTBUG] DcmdMBeanTestCheckJni.java
 reports false positive
In-Reply-To: <0af0e5f9-55f5-481d-8461-2c128da5660e@redhat.com>
References: <e55ecefa13647391860ebc8ffc60ffc1a04b677b.camel@redhat.com>
 <0af0e5f9-55f5-481d-8461-2c128da5660e@redhat.com>
Message-ID: <64ef44cdaf5f6a6fdda18da481224e903139c12e.camel@redhat.com>

On Wed, 2021-02-03 at 10:46 +0100, Aleksey Shipilev wrote:
> Looks fine to me.

Thanks for the review, Aleksey!

Cheers,
Severin


From daniel.fuchs at oracle.com  Wed Feb  3 10:05:26 2021
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 3 Feb 2021 10:05:26 +0000
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <ce07c3f6-f4c7-a266-659e-0488dbd68987@oracle.com>

Vote: yes

best regards,

-- daniel

On 02/02/2021 15:55, Yuri Nesterenko wrote:
> I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer


From shade at redhat.com  Wed Feb  3 10:59:17 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 3 Feb 2021 11:59:17 +0100
Subject: [11u] RFR (S) 8235324: Dying objects are published from users of
 CollectedHeap::object_iterate
Message-ID: <b26834b7-66ab-e5d6-22ad-720b172a0142@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8235324
   https://hg.openjdk.java.net/jdk/jdk/rev/35d8d9b65744

The patch applies almost cleanly to 11u. The only conflict I have to resolve is in zBarrier.hpp, 
where context is different. The patch itself is simple: keep-alive things that we touch with 
object_iterate, in case we load them with non-keepalive barriers.

11u variant:
   https://cr.openjdk.java.net/~shade/8235324/webrev.11u.01/

It requires two follow ups that unbreak Shenandoah, to be backported at the same time
  8237369: Shenandoah: failed vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java test
  8237392: Shenandoah: Remove unreliable assertion

Testing: tier{1,2,3} with {G1, Shenandoah, ZGC, Parallel}; vmTestbase_nsk_jvmti with {G1, 
Shenandoah, ZGC, Parallel}

-- 
Thanks,
-Aleksey


From stefan.karlsson at oracle.com  Wed Feb  3 12:05:52 2021
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 3 Feb 2021 13:05:52 +0100
Subject: [11u] RFR (S) 8235324: Dying objects are published from users of
 CollectedHeap::object_iterate
In-Reply-To: <b26834b7-66ab-e5d6-22ad-720b172a0142@redhat.com>
References: <b26834b7-66ab-e5d6-22ad-720b172a0142@redhat.com>
Message-ID: <78c644bc-7bba-cd42-dae5-a511332a023e@oracle.com>

Looks good.

Thanks,
StefanK

On 2021-02-03 11:59, Aleksey Shipilev wrote:
> Original bug:
> ? https://bugs.openjdk.java.net/browse/JDK-8235324
> ? https://hg.openjdk.java.net/jdk/jdk/rev/35d8d9b65744
>
> The patch applies almost cleanly to 11u. The only conflict I have to 
> resolve is in zBarrier.hpp, where context is different. The patch 
> itself is simple: keep-alive things that we touch with object_iterate, 
> in case we load them with non-keepalive barriers.
>
> 11u variant:
> ? https://cr.openjdk.java.net/~shade/8235324/webrev.11u.01/
>
> It requires two follow ups that unbreak Shenandoah, to be backported 
> at the same time
> ?8237369: Shenandoah: failed 
> vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java test
> ?8237392: Shenandoah: Remove unreliable assertion
>
> Testing: tier{1,2,3} with {G1, Shenandoah, ZGC, Parallel}; 
> vmTestbase_nsk_jvmti with {G1, Shenandoah, ZGC, Parallel}
>


From lois.foltan at oracle.com  Wed Feb  3 15:04:19 2021
From: lois.foltan at oracle.com (Lois Foltan)
Date: Wed, 3 Feb 2021 10:04:19 -0500
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <bc755de7-f47c-350a-3a8b-17042a15ac80@oracle.com>

Vote: yes

Lois

On 2/2/2021 10:55 AM, Yuri Nesterenko wrote:
> I hereby nominate Ekaterina Vergizova (evergizova) [0] to OpenJDK Updates Committer
>
> In the last year Ekaterina did some 84 commits [1] to the various OpenJDK projects.
> To jdk13u only she backported 48 fixes (that, including this year's activity).
> In plans is even more active participation in OpenJDK, and making her a Committer
> would help us all by avoiding the need for someone else to push her fixes.
>
> Votes are due by 16h00 UTC on the 16th of Feb, 2021.
>
> Only current OpenJDK Updates Committers (and above)  [2] are eligible
> to vote on this nomination. Votes must be cast in the open by replying
> to this mailing list.
>
> For Three-Vote Consensus voting instructions, see [3].
>
> [0] https://openjdk.java.net/census#evergizova
> [1] https://github.com/kvergizova
> [2] https://openjdk.java.net/census#jdk-updates
> [3] http://openjdk.java.net/projects/#committer-vote
>
> Thank you,
>   --yan
>


From github.com+75672469+larry-n at openjdk.java.net  Wed Feb  3 15:12:52 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Wed, 3 Feb 2021 15:12:52 GMT
Subject: [jdk13u-dev] Integrated: 8234541: C1 emits an empty message when it
 inlines successfully
In-Reply-To: <hwDT1Qzce8EFVPwI1PVz4AnL_PmrDr1S9vWACWz9E2o=.c66c99bb-2cae-494f-b4dc-fa406effb9e1@github.com>
References: <hwDT1Qzce8EFVPwI1PVz4AnL_PmrDr1S9vWACWz9E2o=.c66c99bb-2cae-494f-b4dc-fa406effb9e1@github.com>
Message-ID: <Hzicz44_Tz64THTqE761ygEZdujTT6G8Oima2OdvBCU=.518b98f7-9b1c-404c-afdf-8f3cd77aac54@github.com>

On Mon, 1 Feb 2021 16:30:18 GMT, Larry-N <github.com+75672469+Larry-N at openjdk.org> wrote:

> Backport fix for bug JDK-8234541. Tested with tier1 and tier2

This pull request has now been integrated.

Changeset: a34f6992
Author:    Ilarion Nakonechnyy <Ilarion at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/a34f6992
Stats:     11 lines in 2 files changed: 1 ins; 6 del; 4 mod

8234541: C1 emits an empty message when it inlines successfully

Use "inline" as the message when successfull

Backport-of: 4e64af81a2ea66313d03b720004667bc7975f6e4

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/104

From github.com+75672469+larry-n at openjdk.java.net  Wed Feb  3 15:17:45 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Wed, 3 Feb 2021 15:17:45 GMT
Subject: [jdk13u-dev] Integrated: 8241478:
 vmTestbase/gc/gctests/Steal/steal001/steal001.java fails with OOME
In-Reply-To: <UIiJE3Y4c4l2QPLtlkL5zqp4eyHgVU5qHNQjYnR48Oc=.c501cc4c-637b-4118-ac63-9c652c115ea5@github.com>
References: <UIiJE3Y4c4l2QPLtlkL5zqp4eyHgVU5qHNQjYnR48Oc=.c501cc4c-637b-4118-ac63-9c652c115ea5@github.com>
Message-ID: <M9LjWfI8mOY_ZMeDztyFXA7XRqwe4zSmlvizGEn4_ac=.4836910b-167c-4405-9772-e11d087057dd@github.com>

On Mon, 1 Feb 2021 16:23:23 GMT, Larry-N <github.com+75672469+Larry-N at openjdk.org> wrote:

> Backport fix for bug JDK-8241478, tested with tier1 and tier2

This pull request has now been integrated.

Changeset: 6778089e
Author:    Ilarion Nakonechnyy <Ilarion at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/6778089e
Stats:     279 lines in 4 files changed: 0 ins; 279 del; 0 mod

8241478: vmTestbase/gc/gctests/Steal/steal001/steal001.java fails with OOME

Backport-of: 931af1260cbe4bd8667555fc9a5e823d68f85716

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/103

From github.com+75672469+larry-n at openjdk.java.net  Wed Feb  3 15:24:54 2021
From: github.com+75672469+larry-n at openjdk.java.net (Larry-N)
Date: Wed, 3 Feb 2021 15:24:54 GMT
Subject: [jdk13u-dev] Integrated: 8238710: LingeredApp doesn't log
 stdout/stderr if exits with non-zero code
In-Reply-To: <ubbFfEb3v7BA1lnpMaiPZffnmqGkUgFxV_R29Hqqg2w=.c54abb99-daa3-4f8a-ad33-2640fb607884@github.com>
References: <ubbFfEb3v7BA1lnpMaiPZffnmqGkUgFxV_R29Hqqg2w=.c54abb99-daa3-4f8a-ad33-2640fb607884@github.com>
Message-ID: <cHw3sDR0twomiIt02vOAkuRnpnau_dAtDITd5SA22hc=.a992e366-7cfe-4d46-b3f5-9ed4d9541274@github.com>

On Mon, 1 Feb 2021 16:13:03 GMT, Larry-N <github.com+75672469+Larry-N at openjdk.org> wrote:

> Backport fix for bug JDK-8238710. Tested with tier1 and tier2.

This pull request has now been integrated.

Changeset: e2fbd269
Author:    Ilarion Nakonechnyy <Ilarion at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/e2fbd269
Stats:     12 lines in 1 file changed: 5 ins; 1 del; 6 mod

8238710: LingeredApp doesn't log stdout/stderr if exits with non-zero code

Backport-of: bcb804f07f290e70fe0e2a243f98aec7a3ec0497

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/102

From rob.mckenna at oracle.com  Wed Feb  3 16:44:57 2021
From: rob.mckenna at oracle.com (Robert Mckenna)
Date: Wed, 3 Feb 2021 16:44:57 +0000
Subject: [15u-communication] CFV: 15u lead maintainer nomination for Yuri
 Nesterenko
Message-ID: <BN6PR1001MB20996680E653120B8D302D2E93B49@BN6PR1001MB2099.namprd10.prod.outlook.com>

As the Project Lead, I would like to ask for your vote for the
nomination [0] of Yuri Nesterenko as future lead maintainer.

Votes are due by the 10th of February.

Only current JDK Updates Committers [1] are eligible to vote
on this nomination.  Votes must be cast in the open by replying
"Vote: yes" to this mail.

For Lazy Consensus voting instructions, see [2].

  -Rob

[0] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004686.html
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/bylaws#lazy-consensus

From vkempik at azul.com  Wed Feb  3 17:07:35 2021
From: vkempik at azul.com (Vladimir Kempik)
Date: Wed, 3 Feb 2021 17:07:35 +0000
Subject: CFV: New OpenJDK Updates Committer: Ekaterina Vergizova 
Message-ID: <7EB4EAEB-AF84-47E2-A9F5-8F4EE4217021@azul.com>

Vote: yes

From vkempik at azul.com  Wed Feb  3 17:10:16 2021
From: vkempik at azul.com (Vladimir Kempik)
Date: Wed, 3 Feb 2021 17:10:16 +0000
Subject: [15u-communication] CFV: 15u lead maintainer nomination for Yuri
 Nesterenko 
Message-ID: <ECC3E2DB-ED42-4F6C-B158-8AC2907B2691@azul.com>

Vote: yes

From serguei.spitsyn at oracle.com  Wed Feb  3 17:29:50 2021
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Wed, 3 Feb 2021 17:29:50 +0000
Subject: [15u-communication] CFV: 15u lead maintainer nomination for Yuri
 Nesterenko
In-Reply-To: <BN6PR1001MB20996680E653120B8D302D2E93B49@BN6PR1001MB2099.namprd10.prod.outlook.com>
References: <BN6PR1001MB20996680E653120B8D302D2E93B49@BN6PR1001MB2099.namprd10.prod.outlook.com>
Message-ID: <DF34D38F-A8F6-4CA9-B3D9-BA53C9382E2F@oracle.com>

Vote: yes


From rhalade at openjdk.java.net  Wed Feb  3 22:44:11 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Wed, 3 Feb 2021 22:44:11 GMT
Subject: [jdk16u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore
Message-ID: <ug_t8pKYNdzFxkij7E16vFMYUS8KGeeIROC9GjoMX4c=.49eabcfb-1de2-4915-9c18-fda87d1840e0@github.com>

Backport is not clean as fix for JDK-8251989 is not in JDK 16. This fix updated VerifyCACerts.java test code.

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

Commit messages:
 - 8256421: Add 2 HARICA roots to cacerts truststore

Changes: https://git.openjdk.java.net/jdk16u/pull/20/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=20&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256421
  Stats: 394 lines in 4 files changed: 390 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/20.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/20/head:pull/20

PR: https://git.openjdk.java.net/jdk16u/pull/20

From rhalade at openjdk.java.net  Thu Feb  4 01:09:57 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 4 Feb 2021 01:09:57 GMT
Subject: [jdk16u] RFR: 8260864: ProblemList two security/krb5 tests on Linux
Message-ID: <UVpwWenLtzR2s56w2E8cthE-nndSYRYvwz42hvJbJ8E=.4115bd2f-cd0c-4365-8bc5-931d2710b130@github.com>

Reviewed-by: dholmes

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

Commit messages:
 - 8260864: ProblemList two security/krb5 tests on Linux

Changes: https://git.openjdk.java.net/jdk16u/pull/21/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=21&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260864
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/21.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/21/head:pull/21

PR: https://git.openjdk.java.net/jdk16u/pull/21

From mikael at openjdk.java.net  Thu Feb  4 01:39:46 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 4 Feb 2021 01:39:46 GMT
Subject: [jdk16u] RFR: 8260864: ProblemList two security/krb5 tests on
 Linux
In-Reply-To: <UVpwWenLtzR2s56w2E8cthE-nndSYRYvwz42hvJbJ8E=.4115bd2f-cd0c-4365-8bc5-931d2710b130@github.com>
References: <UVpwWenLtzR2s56w2E8cthE-nndSYRYvwz42hvJbJ8E=.4115bd2f-cd0c-4365-8bc5-931d2710b130@github.com>
Message-ID: <wsvMFPNduuMaFj45waf65Xh8QzHx0ecZbNbARspJqYM=.aab2f8de-5827-4fa3-93bf-61300ef96683@github.com>

On Thu, 4 Feb 2021 01:04:31 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Reviewed-by: dholmes

Marked as reviewed by mikael (Committer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/21

From jhuttana at redhat.com  Thu Feb  4 01:48:25 2021
From: jhuttana at redhat.com (Jayashree Huttanagoudar)
Date: Thu, 4 Feb 2021 07:18:25 +0530
Subject: [11u] RFR: 8261089: [TESTBUG] native library of test
 TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x
Message-ID: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>

Hi,

Could you please review this build fix for test-image on gcc 4.4.x
systems.  JDK-8258077 is included with 11.0.11+1 and has an initial
declaration in the for loop. The fix is minor and makes the build proceed
further.This breaks our vanilla OpenJDK 11 builds. This isn't really
suitable for jdk/jdk as   it's moved on to later toolchains. There is no
point in fixing this for later JDKs as those aren't going to be buildable
with those old compilers.

Bug: https://bugs.openjdk.java.net/browse/JDK-8261089

Proposed Fix:
diff --git
a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
index 28afd30..08da0c2 100644
---
a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
+++
b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
@@ -35,7 +35,8 @@ Java_TestCheckedReleaseCriticalArray_modifyArray(JNIEnv
*env,
   if (isCopy == JNI_FALSE) {
     jint len = (*env)->GetArrayLength(env, iarr);
     // make arbitrary changes to the array
-    for (int i = 0; i < len; i++) {
+    int i;
+    for (i = 0; i < len; i++) {
       arr[i] *= 2;
     }
     // write-back using JNI_COMMIT to test for memory leak

Testing: Build of test-image target progress with this fix.

Thoughts?

Thanks and Regards,
Jaya

From david.holmes at oracle.com  Thu Feb  4 05:14:20 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 4 Feb 2021 15:14:20 +1000
Subject: [15u-communication] CFV: 15u lead maintainer nomination for Yuri
 Nesterenko
In-Reply-To: <BN6PR1001MB20996680E653120B8D302D2E93B49@BN6PR1001MB2099.namprd10.prod.outlook.com>
References: <BN6PR1001MB20996680E653120B8D302D2E93B49@BN6PR1001MB2099.namprd10.prod.outlook.com>
Message-ID: <3b00b880-e67a-e22b-d051-e38fcce066aa@oracle.com>

Vote: yes

David

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

From omikhaltcova at openjdk.java.net  Thu Feb  4 08:09:03 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Thu, 4 Feb 2021 08:09:03 GMT
Subject: [jdk13u-dev] RFR: 8241458: [JVMCI] add mark value to expose
 CodeOffsets::Frame_Complete
Message-ID: <N-cGOfh45rrVjIZB8wleKwnhqSV4TX23ShM29SPIm0Y=.ef8a02ae-9777-42f3-848b-05a1ad4c2028@github.com>

I'd like to backport JDK-8241458 to jdk13u for parity with jdk11u.
The original patch applied cleanly.
All regular tests passed.

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

Commit messages:
 - Backport d74351824302657450b0f7c7b7a2af57ff7c1251

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/106/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=106&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241458
  Stats: 30 lines in 3 files changed: 6 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/106/head:pull/106

PR: https://git.openjdk.java.net/jdk13u-dev/pull/106

From shade at redhat.com  Thu Feb  4 08:21:39 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 09:21:39 +0100
Subject: [11u] RFR (XS) 8253353: Crash in C2: guarantee(n != NULL) failed: No
 Node
Message-ID: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>

Original bugfix:
   https://bugs.openjdk.java.net/browse/JDK-8253353
   https://git.openjdk.java.net/jdk16/commit/1926765f

This fixes the regression introduced by:
   https://bugs.openjdk.java.net/browse/JDK-8240576

...which was already backported to 11.0.8.

The patch is simple, but it fails to apply cleanly, because one of the asserts in loopnode.cpp 
cannot be placed automatically. I placed near "loop->_nest++" in 11u code.

11u variant:
   https://cr.openjdk.java.net/~shade/8253353/webrev.11u.01

Testing: tier{1,2,3}; new test fails without the patch, passes with it

-- 
Thanks,
-Aleksey


From vladimir.kozlov at oracle.com  Thu Feb  4 08:52:13 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 4 Feb 2021 00:52:13 -0800
Subject: [11u] RFR (XS) 8253353: Crash in C2: guarantee(n != NULL) failed:
 No Node
In-Reply-To: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>
References: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>
Message-ID: <0948b803-3551-f66a-2cd6-40407b472119@oracle.com>

Looks good.
It will match our backport exactly if you remove empty line after first assert().

Thanks,
Vladimir K

On 2/4/21 12:21 AM, Aleksey Shipilev wrote:
> Original bugfix:
>  ? https://bugs.openjdk.java.net/browse/JDK-8253353
>  ? https://git.openjdk.java.net/jdk16/commit/1926765f
> 
> This fixes the regression introduced by:
>  ? https://bugs.openjdk.java.net/browse/JDK-8240576
> 
> ...which was already backported to 11.0.8.
> 
> The patch is simple, but it fails to apply cleanly, because one of the asserts in loopnode.cpp cannot be placed 
> automatically. I placed near "loop->_nest++" in 11u code.
> 
> 11u variant:
>  ? https://cr.openjdk.java.net/~shade/8253353/webrev.11u.01
> 
> Testing: tier{1,2,3}; new test fails without the patch, passes with it
> 

From shade at redhat.com  Thu Feb  4 08:54:25 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 09:54:25 +0100
Subject: [11u] RFR (S) 8235324: Dying objects are published from users of
 CollectedHeap::object_iterate
In-Reply-To: <78c644bc-7bba-cd42-dae5-a511332a023e@oracle.com>
References: <b26834b7-66ab-e5d6-22ad-720b172a0142@redhat.com>
 <78c644bc-7bba-cd42-dae5-a511332a023e@oracle.com>
Message-ID: <dc403d4f-a63a-82fb-f10f-fe851034486f@redhat.com>

On 2/3/21 1:05 PM, Stefan Karlsson wrote:
> Looks good.

Thanks, tagged for 11u maintainers approval.

-- 
-Aleksey


From shade at redhat.com  Thu Feb  4 09:10:58 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 10:10:58 +0100
Subject: [11u] RFR (S) 8079353: [TESTBUG]
 runtime/CompressedOops/UseCompressedOops.java failed on Windows when getting
 disjoint instead of zero based coops
Message-ID: <5a87edc5-1486-b62b-106a-9f83dc5dd2d8@redhat.com>

Original testbug:
   https://bugs.openjdk.java.net/browse/JDK-8079353
   https://hg.openjdk.java.net/jdk/jdk/rev/622c26f0673f

This follows the other stabilizing fixes in the same test (i.e. JDK-8086003). The patch does not 
apply to 11u due to missing problemlist addition. I ignored that hunk.

11u variant:
   https://cr.openjdk.java.net/~shade/8079353/webrev.11u.01

Testing: affected test on Linux x86_64 (still runs)

-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Feb  4 09:29:15 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 10:29:15 +0100
Subject: [11u] RFR (S) 8079353: [TESTBUG]
 runtime/CompressedOops/UseCompressedOops.java failed on Windows when getting
 disjoint instead of zero based coops
In-Reply-To: <5a87edc5-1486-b62b-106a-9f83dc5dd2d8@redhat.com>
References: <5a87edc5-1486-b62b-106a-9f83dc5dd2d8@redhat.com>
Message-ID: <6890f76e-20e9-71b7-142a-fdb1551b4ecb@redhat.com>

On 2/4/21 10:10 AM, Aleksey Shipilev wrote:
> Original testbug:
>     https://bugs.openjdk.java.net/browse/JDK-8079353
>     https://hg.openjdk.java.net/jdk/jdk/rev/622c26f0673f
> 
> This follows the other stabilizing fixes in the same test (i.e. JDK-8086003). The patch does not
> apply to 11u due to missing problemlist addition. I ignored that hunk.
> 
> 11u variant:
>     https://cr.openjdk.java.net/~shade/8079353/webrev.11u.01

Hold on, sorry. There *is* the ProblemList hunk in 11u, because the history is all messed up. This 
is on hold until we figure out if the test is stable enough to be enabled in 11u.

-- 
Thanks,
-Aleksey


From omikhaltcova at openjdk.java.net  Thu Feb  4 09:32:46 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Thu, 4 Feb 2021 09:32:46 GMT
Subject: [jdk13u-dev] Integrated: 8241458: [JVMCI] add mark value to expose
 CodeOffsets::Frame_Complete
In-Reply-To: <N-cGOfh45rrVjIZB8wleKwnhqSV4TX23ShM29SPIm0Y=.ef8a02ae-9777-42f3-848b-05a1ad4c2028@github.com>
References: <N-cGOfh45rrVjIZB8wleKwnhqSV4TX23ShM29SPIm0Y=.ef8a02ae-9777-42f3-848b-05a1ad4c2028@github.com>
Message-ID: <NW9F-3QDlrifgG6cWCAIOhqRaVdhw_jHAkY0gV_Ci_o=.62dab0e7-d0fa-4ba9-b71f-8cc40371921b@github.com>

On Wed, 3 Feb 2021 17:02:33 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8241458 to jdk13u for parity with jdk11u.
> The original patch applied cleanly.
> All regular tests passed.

This pull request has now been integrated.

Changeset: 72e40e9b
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/72e40e9b
Stats:     30 lines in 3 files changed: 6 ins; 0 del; 24 mod

8241458: [JVMCI] add mark value to expose CodeOffsets::Frame_Complete

Backport-of: d74351824302657450b0f7c7b7a2af57ff7c1251

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/106

From shade at redhat.com  Thu Feb  4 09:43:13 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 10:43:13 +0100
Subject: [11u] RFR (S) 8259849: Shenandoah: Rename store-val to IU-barrier
Message-ID: <bf672900-bfc7-3e7d-5650-4a5432193185@redhat.com>

Original cleanup:
   https://bugs.openjdk.java.net/browse/JDK-8259849
   https://git.openjdk.java.net/jdk/commit/e60c9926

I had to basically redo most of the patch, because the context is different in many places. But the 
change is mechanical search-and-replace.

11u variant:
   https://cr.openjdk.java.net/~shade/8259849/webrev.11u.01/

Testing: hotspot_gc_shenandoah on Linux x86_64, x86_32, AArch64; also tier{1,2,3} with Shenandoah

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Thu Feb  4 09:55:01 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 4 Feb 2021 10:55:01 +0100
Subject: [11u] RFR (S) 8259849: Shenandoah: Rename store-val to IU-barrier
In-Reply-To: <bf672900-bfc7-3e7d-5650-4a5432193185@redhat.com>
References: <bf672900-bfc7-3e7d-5650-4a5432193185@redhat.com>
Message-ID: <931cbe5b-9ecd-b12d-3753-22e6fb149091@redhat.com>

Looks good to me! Thank you!

> Original cleanup:
>  ? https://bugs.openjdk.java.net/browse/JDK-8259849
>  ? https://git.openjdk.java.net/jdk/commit/e60c9926
> 
> I had to basically redo most of the patch, because the context is 
> different in many places. But the change is mechanical search-and-replace.
> 
> 11u variant:
>  ? https://cr.openjdk.java.net/~shade/8259849/webrev.11u.01/
> 
> Testing: hotspot_gc_shenandoah on Linux x86_64, x86_32, AArch64; also 
> tier{1,2,3} with Shenandoah
> 


From shade at redhat.com  Thu Feb  4 12:31:01 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 13:31:01 +0100
Subject: [11u] RFR (S) 8251944: Add Shenandoah test config to
 compiler/gcbarriers/UnsafeIntrinsicsTest.java
In-Reply-To: <74f58d15-fdd7-6830-8a66-f3e24c5bdd8a@redhat.com>
References: <74f58d15-fdd7-6830-8a66-f3e24c5bdd8a@redhat.com>
Message-ID: <49b570e1-c001-5420-05bd-0214a976128a@redhat.com>

CC'ing shenandoah-dev at .

On 2/3/21 10:43 AM, Aleksey Shipilev wrote:
> Original test improvement:
>     https://bugs.openjdk.java.net/browse/JDK-8251944
>     https://git.openjdk.java.net/jdk/commit/db6f3930
> 
> It does not apply cleanly to 11u, because test still has @requires !graal and ZGC is not yet
> production-ready and needs UnlockExperimentalVMOptions. Otherwise the patch is the same:
>     https://cr.openjdk.java.net/~shade/8251944/webrev.11u.01/
> 
> Testing: affected test
> 


-- 
Thanks,
-Aleksey


From shade at redhat.com  Thu Feb  4 12:49:33 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 13:49:33 +0100
Subject: [11u] RFR (S) 8259849: Shenandoah: Rename store-val to IU-barrier
In-Reply-To: <931cbe5b-9ecd-b12d-3753-22e6fb149091@redhat.com>
References: <bf672900-bfc7-3e7d-5650-4a5432193185@redhat.com>
 <931cbe5b-9ecd-b12d-3753-22e6fb149091@redhat.com>
Message-ID: <b7a0f586-b1e6-a449-1f74-9bcf4dcc36b6@redhat.com>

On 2/4/21 10:55 AM, Roman Kennke wrote:
> Looks good to me! Thank you!

Thanks, tagged for approval.

-- 
-Aleksey


From hohensee at amazon.com  Thu Feb  4 15:51:45 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 4 Feb 2021 15:51:45 +0000
Subject: [11u] RFR (XS): 8223504: improve performance of forall loops by
 better inlining of "iterator()" methods.
Message-ID: <6B7B8AA7-4826-43D3-A323-71DDD3218906@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Dmitry Chuyko <dmitry.chuyko at bell-sw.com>
Date: Thursday, January 28, 2021 at 3:23 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: [11u] RFR (XS): 8223504: improve performance of forall loops by better inlining of "iterator()" methods.

Hello,

Original RFE: https://bugs.openjdk.java.net/browse/JDK-8223504

Original patch mostly applies cleanly except do_klass() addition in
systemDictionary.hpp which was mechanically reproduced with an extra
parameter.

11u webrev: http://cr.openjdk.java.net/~dchuyko/8223504/webrev.11u.00/

Testing: tier1, tier2.

--
Thanks,
-Dmitry



From yan at openjdk.java.net  Thu Feb  4 16:03:54 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 4 Feb 2021 16:03:54 GMT
Subject: [jdk13u-dev] RFR: 8239497: SEGV in
 EdgeUtils::field_name_symbol(Edge const&)
In-Reply-To: <IEuzjmhvYS_A5Np-69RZTeNkF5N5ePNZCEETZMDifnA=.678e0750-d633-4b73-a633-2c33a9c8b24c@github.com>
References: <IEuzjmhvYS_A5Np-69RZTeNkF5N5ePNZCEETZMDifnA=.678e0750-d633-4b73-a633-2c33a9c8b24c@github.com>
Message-ID: <dUtD38Dt0jfDkXYzLSnTfcbkcIOPs758eBHZz3PTUR4=.6040f94b-a8b4-4209-8079-4227f2a7e2f9@github.com>

On Wed, 3 Feb 2021 06:59:35 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport 8239497 to 13u for parity with 11u.
> The patch doesn't apply cleanly due to context differences in jfr/leakprofiler/chains/edge.cpp and jfr/leakprofiler/chains/edgeUtils.cpp (JDK-8235174 is not in 13u), reapplied manually.
> Tested with tier1 and jdk/jfr tests.

Marked as reviewed by yan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/105

From christoph.langer at sap.com  Thu Feb  4 17:03:56 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 4 Feb 2021 17:03:56 +0000
Subject: FW: [11u] RFR (XS): 8261020: Wrong format parameter in
 create_emergency_chunk_path
In-Reply-To: <bd3f9475-c88a-4ad7-89e5-9f4e1291590c.denghui.ddh@alibaba-inc.com>
References: <dea05f16-c164-4b21-8d46-cd7ed1c7045c.denghui.ddh@alibaba-inc.com>
 <bd3f9475-c88a-4ad7-89e5-9f4e1291590c.denghui.ddh@alibaba-inc.com>
Message-ID: <AM4PR02MB3138656DD98C6F06D1DA16C18AB39@AM4PR02MB3138.eurprd02.prod.outlook.com>

Forwarding for Denghui as he seems to have issues with this mailing list?

------------------------------------------------------------------
From:???(??) <mailto:denghui.ddh at alibaba-inc.com>
Send Time:2021?2?3?(???) 16:22
To:jdk-updates-dev at openjdk.java.net <mailto:jdk-updates-dev at openjdk.java.net>
Subject:[11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path

Hi team,
Could?I?have?a?review?of?this?small?fix?

In create_emergency_chunk_path,?the?call?to?jio_snprintf?used?a?wrong?format?parameter?"repository_path_len".

This?bug?was?introduced?in?8217362(Emergency?dump?does?not?work?when?disk=false?is?set)?and?fixed?in?8226511(Implement?JFR?Event?Streaming),
It?is?currently?unacceptable?to?fully?backport?8226511?to?11u,?so I filed a?new?issue?to?fix?this?problem.

JBS:?https://bugs.openjdk.java.net/browse/JDK-8261020
webrev:?http://cr.openjdk.java.net/~ddong/8261020/webrev.00/

Thanks,
Denghui?Dong


From rkennke at redhat.com  Thu Feb  4 17:21:59 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 4 Feb 2021 18:21:59 +0100
Subject: [11u] RFR (S) 8251944: Add Shenandoah test config to
 compiler/gcbarriers/UnsafeIntrinsicsTest.java
In-Reply-To: <49b570e1-c001-5420-05bd-0214a976128a@redhat.com>
References: <74f58d15-fdd7-6830-8a66-f3e24c5bdd8a@redhat.com>
 <49b570e1-c001-5420-05bd-0214a976128a@redhat.com>
Message-ID: <d0256f1e-7a44-2b17-8135-8b127a0ddaea@redhat.com>

Looks good to me! Thanks!

Roman


> CC'ing shenandoah-dev at .
> 
> On 2/3/21 10:43 AM, Aleksey Shipilev wrote:
>> Original test improvement:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8251944
>> ??? https://git.openjdk.java.net/jdk/commit/db6f3930
>>
>> It does not apply cleanly to 11u, because test still has @requires 
>> !graal and ZGC is not yet
>> production-ready and needs UnlockExperimentalVMOptions. Otherwise the 
>> patch is the same:
>> ??? https://cr.openjdk.java.net/~shade/8251944/webrev.11u.01/
>>
>> Testing: affected test
>>
> 
> 


From shade at redhat.com  Thu Feb  4 17:37:19 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 4 Feb 2021 18:37:19 +0100
Subject: [11u] RFR (S) 8251944: Add Shenandoah test config to
 compiler/gcbarriers/UnsafeIntrinsicsTest.java
In-Reply-To: <d0256f1e-7a44-2b17-8135-8b127a0ddaea@redhat.com>
References: <74f58d15-fdd7-6830-8a66-f3e24c5bdd8a@redhat.com>
 <49b570e1-c001-5420-05bd-0214a976128a@redhat.com>
 <d0256f1e-7a44-2b17-8135-8b127a0ddaea@redhat.com>
Message-ID: <18799efb-419c-ed38-3dfb-5c41856ad9a6@redhat.com>

On 2/4/21 6:21 PM, Roman Kennke wrote:
> Looks good to me! Thanks!

Thanks, tagged for approval.


-- 
Thanks,
-Aleksey


From rhalade at openjdk.java.net  Thu Feb  4 17:38:46 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 4 Feb 2021 17:38:46 GMT
Subject: [jdk16u] Integrated: 8260864: ProblemList two security/krb5 tests on
 Linux
In-Reply-To: <UVpwWenLtzR2s56w2E8cthE-nndSYRYvwz42hvJbJ8E=.4115bd2f-cd0c-4365-8bc5-931d2710b130@github.com>
References: <UVpwWenLtzR2s56w2E8cthE-nndSYRYvwz42hvJbJ8E=.4115bd2f-cd0c-4365-8bc5-931d2710b130@github.com>
Message-ID: <HON-2OcZZ3XEWei2FGxYyZNrSawK0ch2IbDCg2v8SFg=.f321759e-2c9b-4260-a707-d6ccf207629a@github.com>

On Thu, 4 Feb 2021 01:04:31 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Reviewed-by: dholmes

This pull request has now been integrated.

Changeset: f48451c7
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/f48451c7
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8260864: ProblemList two security/krb5 tests on Linux

Reviewed-by: mikael
Backport-of: a6d950587bc68f81495660f59169b7f1970076e7

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

PR: https://git.openjdk.java.net/jdk16u/pull/21

From mullan at openjdk.java.net  Thu Feb  4 19:15:46 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 4 Feb 2021 19:15:46 GMT
Subject: [jdk16u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore
In-Reply-To: <ug_t8pKYNdzFxkij7E16vFMYUS8KGeeIROC9GjoMX4c=.49eabcfb-1de2-4915-9c18-fda87d1840e0@github.com>
References: <ug_t8pKYNdzFxkij7E16vFMYUS8KGeeIROC9GjoMX4c=.49eabcfb-1de2-4915-9c18-fda87d1840e0@github.com>
Message-ID: <Fl3O0fcDRSF4jy8yOYcgnjk1fndmToawfJtRPNjHSW0=.cc536369-7340-4dd7-ba35-31f2ddad7ed5@github.com>

On Wed, 3 Feb 2021 22:39:21 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Backport is not clean as fix for JDK-8251989 is not in JDK 16. This fix updated VerifyCACerts.java test code.

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/20

From rhalade at openjdk.java.net  Thu Feb  4 19:15:47 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Thu, 4 Feb 2021 19:15:47 GMT
Subject: [jdk16u] Integrated: 8256421: Add 2 HARICA roots to cacerts truststore
In-Reply-To: <ug_t8pKYNdzFxkij7E16vFMYUS8KGeeIROC9GjoMX4c=.49eabcfb-1de2-4915-9c18-fda87d1840e0@github.com>
References: <ug_t8pKYNdzFxkij7E16vFMYUS8KGeeIROC9GjoMX4c=.49eabcfb-1de2-4915-9c18-fda87d1840e0@github.com>
Message-ID: <GhzfjKIzWSDMF_9UdB0KBRhEA1B_I7upur1JwTSgp4o=.aee7c3d7-e92a-4a86-8154-c45534f954b2@github.com>

On Wed, 3 Feb 2021 22:39:21 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

> Backport is not clean as fix for JDK-8251989 is not in JDK 16. This fix updated VerifyCACerts.java test code.

This pull request has now been integrated.

Changeset: 4ccaf6b8
Author:    Rajan Halade <rhalade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/4ccaf6b8
Stats:     394 lines in 4 files changed: 390 ins; 0 del; 4 mod

8256421: Add 2 HARICA roots to cacerts truststore

Reviewed-by: mullan
Backport-of: 69189f8820fa5e016f8dc651b6dcb77b4dd1bbdd

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

PR: https://git.openjdk.java.net/jdk16u/pull/20

From ramanand.patil at in.ibm.com  Fri Feb  5 04:56:33 2021
From: ramanand.patil at in.ibm.com (Ramanand Patil)
Date: Fri, 5 Feb 2021 04:56:33 +0000
Subject: [11u] RFR: JDK-8247753: UIManager.getSytemLookAndFeelClassName()
 returns wrong value on Fedora 32
Message-ID: <OF69AE76A8.0527445A-ON00258673.001B269E-00258673.001B26A5@notes.na.collabserv.com>

Hi all,
Please review the JDK11u backport of JDK-8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
Bug Link: https://bugs.openjdk.java.net/browse/JDK-8247753
Webrev: http://cr.openjdk.java.net/~rpatil/8247753/webrev.00/
JDK-16 Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/97a5fd3612ef
The patch was not applied cleanly from JDK16 to JDK11u as the check for the environmental variables "GNOME_DESKTOP_SESSION_ID" and "XDG_CURRENT_DESKTOP" is done in native code (unix/native/libjava/java_props_md.c) in jdk11u.
The test case is taken from the latest jdk repo by ignoring the changes done to the test via "JDK-8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports".
Testing is mainly done on Ubuntu(18.04) and Fedora(version 32 and 33) and is a pass.

Note:
- I am actually resending this mail as it was not delivered earlier.
- Copyright year will be updated before push or if there are any other revisions to the patch.

Regards,
Ramanand.


From abrygin at azul.com  Fri Feb  5 08:01:18 2021
From: abrygin at azul.com (Andrew Brygin)
Date: Fri, 5 Feb 2021 11:01:18 +0300
Subject: [15u-communication] CFV: 15u lead maintainer nomination for Yuri
 Nesterenko
Message-ID: <1325a6eb-a35b-a894-5a50-a31c0cdd03fa@azul.com>

Vote: yes

Thanks,
Andrew


From christoph.langer at sap.com  Fri Feb  5 08:03:05 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 5 Feb 2021 08:03:05 +0000
Subject: jdk-updates-dev mailing list does not work - mails don't get forwarded
Message-ID: <AM4PR02MB3138F8735CB6023139FB56598AB29@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

it seems to me as if the jdk-updates-dev mailing list has problems since Monday or so. Several people report that mails send to the list don't get forwarded to the list subscribers any more. All folks with sap.com addresses are affected and I also know of gmail.com accounts. Don't know about others. One can see the mails arrive at the list and they show up in the archives [0], though.

It also seems that it is a problem specific to the jdk-updates-dev mailing list since the other OpenJDK mailing lists I'm subscribed to still work.

Can you please have a look asap, as this is blocking work on the OpenJDK update releases?

Thanks a lot!
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/thread.html


From yan at azul.com  Fri Feb  5 08:21:26 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Fri, 5 Feb 2021 11:21:26 +0300
Subject: jdk-updates-dev mailing list does not work - mails don't get
 forwarded
Message-ID: <3ca8a911-e97f-1d18-40af-99ed8e6af04a@azul.com>

The same with azul.com addresses.
I've written to ops at ojn about that yesterday, waiting...

--yan

(Christoph's message  copied from archive web page)


Hi,

it seems to me as if the jdk-updates-dev mailing list has problems since Monday or so. Several people
report that mails send to the list don't get forwarded to the list subscribers any more. All folks
with sap.com addresses are affected and I also know of gmail.com accounts. Don't know about others.
One can see the mails arrive at the list and they show up in the archives [0], though.

It also seems that it is a problem specific to the jdk-updates-dev mailing list since the other
OpenJDK mailing lists I'm subscribed to still work.

Can you please have a look asap, as this is blocking work on the OpenJDK update releases?

Thanks a lot!
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/thread.html


From omikhaltcova at openjdk.java.net  Fri Feb  5 08:31:59 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 5 Feb 2021 08:31:59 GMT
Subject: [jdk13u-dev] RFR: 8234058:
 runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass
 base: 0x0000000000000000' missing from stdout/stderr
Message-ID: <XJPPehRvpZMpvWcA64iTbUqR0ai0Ek82qT-q1O08nps=.b610303f-d2be-44f0-8b7d-624e703f4802@github.com>

I'd like to backport JDK-8234058 to jdk13u for parity with jdk11u.
The original patch applied cleanly.
Tested via jtreg with the tests in /runtime/CompressedOops.

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

Commit messages:
 - Backport 1c5322b998012a4ca0e7d3583eddee9fa0880346

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/107

From dcherepanov at azul.com  Fri Feb  5 08:38:43 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Fri, 5 Feb 2021 11:38:43 +0300
Subject: [15u-communication] CFV: 15u lead maintainer nomination for Yuri
 Nesterenko
Message-ID: <7b4dcb3d-85ca-d03b-f86c-67b23e5fa97e@azul.com>

Vote: yes


From yan at openjdk.java.net  Fri Feb  5 09:48:53 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 5 Feb 2021 09:48:53 GMT
Subject: [jdk13u-dev] RFR: 8221823: Requested JDialog width is ignored
Message-ID: <C7Ke4TNKyLbeje6TsNwK32Gix7HOSmcc-zEfe9Bto9M=.bc0db799-d0ae-4cf5-ba00-abd5e59c60c4@github.com>

This should be a "clean"  backport of a fix made in 15 and existing in 11. Need to test it using our internal machinery...

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

Commit messages:
 - Backport 8d2aa62bd94ffe63175dd91ba6442eaf08c6ba69

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/108/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=108&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8221823
  Stats: 171 lines in 9 files changed: 146 ins; 6 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/108.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/108/head:pull/108

PR: https://git.openjdk.java.net/jdk13u-dev/pull/108

From evergizova at openjdk.java.net  Fri Feb  5 09:57:46 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 5 Feb 2021 09:57:46 GMT
Subject: [jdk13u-dev] Integrated: 8239497: SEGV in
 EdgeUtils::field_name_symbol(Edge const&)
In-Reply-To: <IEuzjmhvYS_A5Np-69RZTeNkF5N5ePNZCEETZMDifnA=.678e0750-d633-4b73-a633-2c33a9c8b24c@github.com>
References: <IEuzjmhvYS_A5Np-69RZTeNkF5N5ePNZCEETZMDifnA=.678e0750-d633-4b73-a633-2c33a9c8b24c@github.com>
Message-ID: <bRnaCsxNnNLsnB4tRVClzr8h9McNdObqFZ4RHqHlQ-Q=.0d9998b4-34ca-4b93-8732-cc203a38cdf0@github.com>

On Wed, 3 Feb 2021 06:59:35 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport 8239497 to 13u for parity with 11u.
> The patch doesn't apply cleanly due to context differences in jfr/leakprofiler/chains/edge.cpp and jfr/leakprofiler/chains/edgeUtils.cpp (JDK-8235174 is not in 13u), reapplied manually.
> Tested with tier1 and jdk/jfr tests.

This pull request has now been integrated.

Changeset: 43ed0018
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/43ed0018
Stats:     108 lines in 6 files changed: 23 ins; 47 del; 38 mod

8239497: SEGV in EdgeUtils::field_name_symbol(Edge const&)

Reviewed-by: yan
Backport-of: f2fb5c54ae1c5ca8ed8dfb136b1f967877cc362e

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/105

From omikhaltcova at openjdk.java.net  Fri Feb  5 10:03:42 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 5 Feb 2021 10:03:42 GMT
Subject: [jdk13u-dev] Integrated: 8234058:
 runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass
 base: 0x0000000000000000' missing from stdout/stderr
In-Reply-To: <XJPPehRvpZMpvWcA64iTbUqR0ai0Ek82qT-q1O08nps=.b610303f-d2be-44f0-8b7d-624e703f4802@github.com>
References: <XJPPehRvpZMpvWcA64iTbUqR0ai0Ek82qT-q1O08nps=.b610303f-d2be-44f0-8b7d-624e703f4802@github.com>
Message-ID: <ReDr7gm9xKbs0NwzHzp-F8mkoOqeohqpE8parMRGU7I=.126d2a85-4bff-4832-a4b1-2c095cd2f198@github.com>

On Fri, 5 Feb 2021 08:25:38 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8234058 to jdk13u for parity with jdk11u.
> The original patch applied cleanly.
> Tested via jtreg with the tests in /runtime/CompressedOops.

This pull request has now been integrated.

Changeset: c06b62e6
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/c06b62e6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8234058: runtime/CompressedOops/CompressedClassPointers.java fails with 'Narrow klass base: 0x0000000000000000' missing from stdout/stderr

Don't run test on Windows because ASLR can cause unexpected memory addresses

Backport-of: 1c5322b998012a4ca0e7d3583eddee9fa0880346

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/107

From evergizova at openjdk.java.net  Fri Feb  5 14:01:54 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 5 Feb 2021 14:01:54 GMT
Subject: [jdk13u-dev] RFR: 8216324: GetClassMethods is confused by the
 presence of default methods in super interfaces
Message-ID: <EUNtRY2a1GrNCSFEe-ZrgPC27RHifchiswNB1ybL-QY=.e3fc4276-cd55-4211-b516-16585caa2b2b@github.com>

I'd like to backport 8216324 to 13u for parity with 11u.
The patch applies cleanly.
Tested with tier1 and other jvmti tests; new test fails without the patch, passes with it.

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

Commit messages:
 - Backport 277ec3d26080275e3c14b7e3f40c15e5cdfa3821

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/109/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=109&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8216324
  Stats: 261 lines in 5 files changed: 214 ins; 8 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/109.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/109/head:pull/109

PR: https://git.openjdk.java.net/jdk13u-dev/pull/109

From rob.mckenna at oracle.com  Fri Feb  5 15:06:47 2021
From: rob.mckenna at oracle.com (Robert Mckenna)
Date: Fri, 5 Feb 2021 15:06:47 +0000
Subject: jdk-updates-dev mailing list does not work - mails don't get
 forwarded
In-Reply-To: <AM4PR02MB3138F8735CB6023139FB56598AB29@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138F8735CB6023139FB56598AB29@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <BN6PR1001MB2099EF2FD772A35F0EE73D3993B29@BN6PR1001MB2099.namprd10.prod.outlook.com>

I'm not sure what could be causing this but I've mailed ops to see if they can figure it out.

    -Rob

________________________________________
From: Langer, Christoph <christoph.langer at sap.com>
Sent: Friday 5 February 2021 08:03
To: jdk-updates-dev at openjdk.java.net; ops at openjdk.java.net; Robert Mckenna; Tim Bell
Cc: Doerr, Martin; Lindenmaier, Goetz; Reingruber, Richard; Baesken, Matthias
Subject: [External] : jdk-updates-dev mailing list does not work - mails don't get forwarded

Hi,

it seems to me as if the jdk-updates-dev mailing list has problems since Monday or so. Several people report that mails send to the list don?t get forwarded to the list subscribers any more. All folks with sap.com addresses are affected and I also know of gmail.com accounts. Don?t know about others. One can see the mails arrive at the list and they show up in the archives [0], though.

It also seems that it is a problem specific to the jdk-updates-dev mailing list since the other OpenJDK mailing lists I?m subscribed to still work.

Can you please have a look asap, as this is blocking work on the OpenJDK update releases?

Thanks a lot!
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/thread.html


From evergizova at openjdk.java.net  Fri Feb  5 15:30:54 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 5 Feb 2021 15:30:54 GMT
Subject: [jdk13u-dev] Integrated: 8216324: GetClassMethods is confused by the
 presence of default methods in super interfaces
In-Reply-To: <EUNtRY2a1GrNCSFEe-ZrgPC27RHifchiswNB1ybL-QY=.e3fc4276-cd55-4211-b516-16585caa2b2b@github.com>
References: <EUNtRY2a1GrNCSFEe-ZrgPC27RHifchiswNB1ybL-QY=.e3fc4276-cd55-4211-b516-16585caa2b2b@github.com>
Message-ID: <0JXLl5v3Hy-dzeYCua587-EJzVxrFoEE0whxVJFhQak=.975a0a79-fba8-4a42-b1f4-f9c76b9f1df2@github.com>

On Fri, 5 Feb 2021 13:57:01 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport 8216324 to 13u for parity with 11u.
> The patch applies cleanly.
> Tested with tier1 and other jvmti tests; new test fails without the patch, passes with it.

This pull request has now been integrated.

Changeset: 051ffceb
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/051ffceb
Stats:     261 lines in 5 files changed: 214 ins; 8 del; 39 mod

8216324: GetClassMethods is confused by the presence of default methods in super interfaces

Backport-of: 277ec3d26080275e3c14b7e3f40c15e5cdfa3821

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/109

From yan at openjdk.java.net  Fri Feb  5 15:43:48 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 5 Feb 2021 15:43:48 GMT
Subject: [jdk13u-dev] Integrated: 8221823: Requested JDialog width is ignored
In-Reply-To: <C7Ke4TNKyLbeje6TsNwK32Gix7HOSmcc-zEfe9Bto9M=.bc0db799-d0ae-4cf5-ba00-abd5e59c60c4@github.com>
References: <C7Ke4TNKyLbeje6TsNwK32Gix7HOSmcc-zEfe9Bto9M=.bc0db799-d0ae-4cf5-ba00-abd5e59c60c4@github.com>
Message-ID: <jlCUIumlS_lClw-a32PPE9jqtMs7DOPhYJl_ErwcZCc=.7ee01d5f-fbf5-44d3-a8d0-5c8f10be50d7@github.com>

On Fri, 5 Feb 2021 09:43:40 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> This should be a "clean"  backport of a fix made in 15 and existing in 11. Need to test it using our internal machinery... Success.

This pull request has now been integrated.

Changeset: b6077e71
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/b6077e71
Stats:     171 lines in 9 files changed: 146 ins; 6 del; 19 mod

8221823: Requested JDialog width is ignored

Backport-of: 8d2aa62bd94ffe63175dd91ba6442eaf08c6ba69

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/108

From qingfeng.yy at alibaba-inc.com  Sun Feb  7 08:54:52 2021
From: qingfeng.yy at alibaba-inc.com (Yang Yi)
Date: Sun, 07 Feb 2021 16:54:52 +0800
Subject: =?UTF-8?B?WzExdV0gUkZSOiBCYWNrcG9ydCBvZiA4MjE2MDQxOiBbRXZlbnQgUmVxdWVzdF0gLSBEZW9w?=
 =?UTF-8?B?dGltaXphdGlvbg==?=
Message-ID: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>

Hi,

Please can I request a review of this webrev for the backport of
https://bugs.openjdk.java.net/browse/JDK-8216041 ?

Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-8216041/webrev.00/

This patch doesn't apply cleanly but is fairly trivial. The signature of 
method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)` is
not different comparing to upstream and jdk11u. Simply adjusting the 
argument position and adding extra parameters can solve this problem.

Best,Yang Yi

From yan at openjdk.java.net  Mon Feb  8 08:34:09 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 8 Feb 2021 08:34:09 GMT
Subject: [jdk13u-dev] RFR: 8243925: Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
Message-ID: <tm-CtgGylhe9ZMtkYvykZe-ebEO1yxMZyWlUbHXtJaY=.9431a317-7d21-4cff-8019-30e3395a631d@github.com>

I'd like to port it to jdk13u in a series of HiDPI fixes for windows. Applies clean.
I'll update this request and push after the test run completion.

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

Commit messages:
 - Backport 9c415c4d524336157ccaeb780b18d133b19aa527

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/110/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=110&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243925
  Stats: 123 lines in 3 files changed: 116 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/110.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/110/head:pull/110

PR: https://git.openjdk.java.net/jdk13u-dev/pull/110

From christoph.langer at sap.com  Mon Feb  8 10:08:45 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 8 Feb 2021 10:08:45 +0000
Subject: Heads up: jdk-updates-dev mailing list problems (resolved)
Message-ID: <AM4PR02MB3138490D14DE7F66E6C97DBA8A8F9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi all,

for those who haven't been aware: Last week jdk-updates-dev had some issues and mails were not relayed to subscribers for some time.

While it seems the issue is resolved now, I suggest that people re-send mails (e.g. RFRs) once again if there's doubt that those mails have reached the desired audience.

Best regards
Christoph


From shade at redhat.com  Mon Feb  8 10:33:10 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 8 Feb 2021 11:33:10 +0100
Subject: [11u] RFR (XS) 8253353: Crash in C2: guarantee(n != NULL) failed:
 No Node
In-Reply-To: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>
References: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>
Message-ID: <d4bfeb7e-0ac2-61b7-4d84-1d1b14b89089@redhat.com>

On 2/4/21 9:21 AM, Aleksey Shipilev wrote:
> Original bugfix:
>     https://bugs.openjdk.java.net/browse/JDK-8253353
>     https://git.openjdk.java.net/jdk16/commit/1926765f
> 
> This fixes the regression introduced by:
>     https://bugs.openjdk.java.net/browse/JDK-8240576
> 
> ...which was already backported to 11.0.8.
> 
> The patch is simple, but it fails to apply cleanly, because one of the asserts in loopnode.cpp
> cannot be placed automatically. I placed near "loop->_nest++" in 11u code.
> 
> 11u variant:
>     https://cr.openjdk.java.net/~shade/8253353/webrev.11u.01
> 
> Testing: tier{1,2,3}; new test fails without the patch, passes with it

I see Vladimir's review here (but not in my mail, because jdk-updates-dev mailing list is 
temporarily broken):
   https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004864.html

Vladimir says:
  > It will match our backport exactly if you remove empty line after first assert().

...and I would prefer to keep it with the original empty line in the code.

-- 
Thanks,
-Aleksey


From sgehwolf at redhat.com  Mon Feb  8 11:05:12 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 08 Feb 2021 12:05:12 +0100
Subject: Heads up: jdk-updates-dev mailing list problems (resolved)
In-Reply-To: <AM4PR02MB3138490D14DE7F66E6C97DBA8A8F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138490D14DE7F66E6C97DBA8A8F9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <bc539110e09a084032fe035a85dec656f0d802ac.camel@redhat.com>

On Mon, 2021-02-08 at 10:08 +0000, Langer, Christoph wrote:
> Hi all,
> 
> for those who haven't been aware: Last week jdk-updates-dev had some
> issues and mails were not relayed to subscribers for some time.
> 
> While it seems the issue is resolved now, I suggest that people re-
> send mails (e.g. RFRs) once again if there's doubt that those mails
> have reached the desired audience.

Thanks, Christoph! This info is much appreciated. I (for one) hadn't
noticed... :-/

Cheers,
Severin


From jhuttana at redhat.com  Mon Feb  8 11:18:40 2021
From: jhuttana at redhat.com (Jayashree Huttanagoudar)
Date: Mon, 8 Feb 2021 16:48:40 +0530
Subject: [11u] RFR: 8261089: [TESTBUG] native library of test
 TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x
In-Reply-To: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>
References: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>
Message-ID: <CAJ8kv5NNdRqh_va2Nnt81+G7Yf6x52mht357HOCg_M8D5upQcg@mail.gmail.com>

Hi All,

I am reposting this due to relay problems.

Thanks and Regards,
Jaya

On Thu, Feb 4, 2021 at 7:18 AM Jayashree Huttanagoudar <jhuttana at redhat.com>
wrote:

> Hi,
>
> Could you please review this build fix for test-image on gcc 4.4.x
> systems.  JDK-8258077 is included with 11.0.11+1 and has an initial
> declaration in the for loop. The fix is minor and makes the build proceed
> further.This breaks our vanilla OpenJDK 11 builds. This isn't really
> suitable for jdk/jdk as   it's moved on to later toolchains. There is no
> point in fixing this for later JDKs as those aren't going to be buildable
> with those old compilers.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8261089
>
> Proposed Fix:
> diff --git
> a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> index 28afd30..08da0c2 100644
> ---
> a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> +++
> b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> @@ -35,7 +35,8 @@ Java_TestCheckedReleaseCriticalArray_modifyArray(JNIEnv
> *env,
>    if (isCopy == JNI_FALSE) {
>      jint len = (*env)->GetArrayLength(env, iarr);
>      // make arbitrary changes to the array
> -    for (int i = 0; i < len; i++) {
> +    int i;
> +    for (i = 0; i < len; i++) {
>        arr[i] *= 2;
>      }
>      // write-back using JNI_COMMIT to test for memory leak
>
> Testing: Build of test-image target progress with this fix.
>
> Thoughts?
>
> Thanks and Regards,
> Jaya
>

From yan at openjdk.java.net  Mon Feb  8 12:28:53 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 8 Feb 2021 12:28:53 GMT
Subject: [jdk13u-dev] Withdrawn: 8243925: Toolkit#getScreenInsets() returns
 wrong value on HiDPI screens (Windows)
In-Reply-To: <tm-CtgGylhe9ZMtkYvykZe-ebEO1yxMZyWlUbHXtJaY=.9431a317-7d21-4cff-8019-30e3395a631d@github.com>
References: <tm-CtgGylhe9ZMtkYvykZe-ebEO1yxMZyWlUbHXtJaY=.9431a317-7d21-4cff-8019-30e3395a631d@github.com>
Message-ID: <a2z8p_BWNCDGlu4lje7gqhfQBJppk74NDfLoh7IZ-D8=.8db90203-11b0-4ed0-ba5a-ef604636cabd@github.com>

On Mon, 8 Feb 2021 08:29:15 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I'd like to port it to jdk13u in a series of HiDPI fixes for windows. Applies clean.
> I'll update this request and push after the test run completion.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/110

From sgehwolf at redhat.com  Mon Feb  8 12:40:42 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 08 Feb 2021 13:40:42 +0100
Subject: [11u] RFR: 8261089: [TESTBUG] native library of test
 TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x
In-Reply-To: <CAJ8kv5NNdRqh_va2Nnt81+G7Yf6x52mht357HOCg_M8D5upQcg@mail.gmail.com>
References: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>
 <CAJ8kv5NNdRqh_va2Nnt81+G7Yf6x52mht357HOCg_M8D5upQcg@mail.gmail.com>
Message-ID: <4ebf4aad92d9c2362be4ed9d43248efc8611e09d.camel@redhat.com>

On Mon, 2021-02-08 at 16:48 +0530, Jayashree Huttanagoudar wrote:
> 
> On Thu, Feb 4, 2021 at 7:18 AM Jayashree Huttanagoudar <jhuttana at redhat.com>
> wrote:
> 
> > Hi,
> > 
> > Could you please review this build fix for test-image on gcc 4.4.x
> > systems.? JDK-8258077 is included with 11.0.11+1 and has an initial
> > declaration in the for loop. The fix is minor and makes the build proceed
> > further.This breaks our vanilla OpenJDK 11 builds. This isn't really
> > suitable for jdk/jdk as?? it's moved on to later toolchains. There is no
> > point in fixing this for later JDKs as those aren't going to be buildable
> > with those old compilers.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8261089
> > 
> > Proposed Fix:
> > diff --git
> > a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > index 28afd30..08da0c2 100644
> > ---
> > a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > +++
> > b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > @@ -35,7 +35,8 @@ Java_TestCheckedReleaseCriticalArray_modifyArray(JNIEnv
> > *env,
> > ?? if (isCopy == JNI_FALSE) {
> > ???? jint len = (*env)->GetArrayLength(env, iarr);
> > ???? // make arbitrary changes to the array
> > -??? for (int i = 0; i < len; i++) {
> > +??? int i;
> > +??? for (i = 0; i < len; i++) {
> > ?????? arr[i] *= 2;
> > ???? }
> > ???? // write-back using JNI_COMMIT to test for memory leak
> > 
> > Testing: Build of test-image target progress with this fix.
> > 
> > Thoughts?

Looks fine to me and it fixes early access builds. I can sponsor the
fix for you!

Thanks,
Severin


From jhuttana at redhat.com  Mon Feb  8 12:46:05 2021
From: jhuttana at redhat.com (Jayashree Huttanagoudar)
Date: Mon, 8 Feb 2021 18:16:05 +0530
Subject: [11u] RFR: 8261089: [TESTBUG] native library of test
 TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x
In-Reply-To: <4ebf4aad92d9c2362be4ed9d43248efc8611e09d.camel@redhat.com>
References: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>
 <CAJ8kv5NNdRqh_va2Nnt81+G7Yf6x52mht357HOCg_M8D5upQcg@mail.gmail.com>
 <4ebf4aad92d9c2362be4ed9d43248efc8611e09d.camel@redhat.com>
Message-ID: <CAJ8kv5O_zhP677R0nJSC5o=NJn1-7QEdS=k_6E1Ry02u+xa3cg@mail.gmail.com>

Hi Severin,

On Mon, Feb 8, 2021 at 6:10 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> On Mon, 2021-02-08 at 16:48 +0530, Jayashree Huttanagoudar wrote:
> >
> > On Thu, Feb 4, 2021 at 7:18 AM Jayashree Huttanagoudar <
> jhuttana at redhat.com>
> > wrote:
> >
> > > Hi,
> > >
> > > Could you please review this build fix for test-image on gcc 4.4.x
> > > systems.  JDK-8258077 is included with 11.0.11+1 and has an initial
> > > declaration in the for loop. The fix is minor and makes the build
> proceed
> > > further.This breaks our vanilla OpenJDK 11 builds. This isn't really
> > > suitable for jdk/jdk as   it's moved on to later toolchains. There is
> no
> > > point in fixing this for later JDKs as those aren't going to be
> buildable
> > > with those old compilers.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8261089
> > >
> > > Proposed Fix:
> > > diff --git
> > >
> a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > >
> b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > > index 28afd30..08da0c2 100644
> > > ---
> > >
> a/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > > +++
> > >
> b/test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c
> > > @@ -35,7 +35,8 @@
> Java_TestCheckedReleaseCriticalArray_modifyArray(JNIEnv
> > > *env,
> > >    if (isCopy == JNI_FALSE) {
> > >      jint len = (*env)->GetArrayLength(env, iarr);
> > >      // make arbitrary changes to the array
> > > -    for (int i = 0; i < len; i++) {
> > > +    int i;
> > > +    for (i = 0; i < len; i++) {
> > >        arr[i] *= 2;
> > >      }
> > >      // write-back using JNI_COMMIT to test for memory leak
> > >
> > > Testing: Build of test-image target progress with this fix.
> > >
> > > Thoughts?
>
> Looks fine to me and it fixes early access builds. I can sponsor the
> fix for you!
>

Thank you so much!!

Regards,
Jaya


> Thanks,
> Severin
>
>

From yan at openjdk.java.net  Mon Feb  8 12:47:57 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 8 Feb 2021 12:47:57 GMT
Subject: [jdk13u-dev] RFR: 8243925: Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
Message-ID: <mMM6eQ6YDy010k21WBxm2JfauSRxPEUodLlO8racbrQ=.e165234b-3953-4bfa-9974-bd4d77bd7be5@github.com>

Second attempt to backport this issue. After creating a PR, doing testing, I realized that newly introduced test change required some modifications. It has a preview feature in terms of 13 totally unrelated to the original issue. 
Unfortunately, I could not find an easy way to amend a backport commit (routine described for a regular PR seems not working here). So I had to close PR,  discard a branch and start anew.

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

Commit messages:
 - Backport 9c415c4d524336157ccaeb780b18d133b19aa527

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/111/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=111&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243925
  Stats: 123 lines in 3 files changed: 116 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/111.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/111/head:pull/111

PR: https://git.openjdk.java.net/jdk13u-dev/pull/111

From yan at openjdk.java.net  Mon Feb  8 13:09:43 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 8 Feb 2021 13:09:43 GMT
Subject: [jdk13u-dev] Withdrawn: 8243925: Toolkit#getScreenInsets() returns
 wrong value on HiDPI screens (Windows)
In-Reply-To: <mMM6eQ6YDy010k21WBxm2JfauSRxPEUodLlO8racbrQ=.e165234b-3953-4bfa-9974-bd4d77bd7be5@github.com>
References: <mMM6eQ6YDy010k21WBxm2JfauSRxPEUodLlO8racbrQ=.e165234b-3953-4bfa-9974-bd4d77bd7be5@github.com>
Message-ID: <oV55HFI3PpAN3JmMam1caD8BqPHeg1y2AoKGvZZO2Hc=.a5f782c6-8cf4-477c-8e7d-7121b4b153c6@github.com>

On Mon, 8 Feb 2021 12:42:38 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> Second attempt to backport this issue. After creating a PR, doing testing, I realized that newly introduced test change required some modifications. It has a preview feature in terms of 13 totally unrelated to the original issue. 
> Unfortunately, I could not find an easy way to amend a backport commit (routine described for a regular PR seems not working here). So I had to close PR,  discard a branch and start anew.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/111

From goetz.lindenmaier at sap.com  Mon Feb  8 13:18:17 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 8 Feb 2021 13:18:17 +0000
Subject: [11u] RFR: 8244683: A TSA server used by tests
In-Reply-To: <AM4PR02MB3057F599C7D20D24E3B238889AB59@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB3057F599C7D20D24E3B238889AB59@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB34430B25D5273D58D2613AD9EC8F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi Martin,

Thanks for downporting this.
Nice documentation of the changes! Looks good.

Best regards,
  Goetz.

From: Doerr, Martin <martin.doerr at sap.com>
Sent: Tuesday, February 2, 2021 9:28 PM
To: security-dev <security-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: [11u] RFR: 8244683: A TSA server used by tests

Hi,

JDK-8244683 is backported to 11.0.11-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

TimestampCheck.java:
- The parts which get removed contain minor differences (see [1])
- Resolution: Take new version.

TsaHandler.java and TsaSigner.java:
- New code contains usages of KnownOIDs which don't exist in 11u.
- Resolution: Translate them (see [2])

TsaSigner.java:
- New code uses ObjectIdentifier.of
- Resolution: Change back to "new ObjectIdentifier" according to [1]
- Uses HexPrinter (for debug code) which doesn't exist in 11u.
- Resolution: Use HexDumpEncoder instead: System.out.println(new HexDumpEncoder().encode(bytes));

An additional testfix is needed:
https://bugs.openjdk.java.net/browse/JDK-8246709
which applies cleanly except that it needs an import change (see [3]).
That change is not included in the webrev. I just want to push 11u backport of 8244683 together with 8246709 (including [3]) together.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8244683

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/56bda3e6d148

11u backport:
http://cr.openjdk.java.net/~mdoerr/8244683_TSA_11u/webrev.00/

Please review.

Best regards,
Martin


[1] diff JDK11u:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java JDK16:TimestampCheck_before_8244683.java
65a66
>  *          8242151
137c138
<             ObjectIdentifier policyId = new ObjectIdentifier(defaultPolicyId);
---
>             ObjectIdentifier policyId = ObjectIdentifier.of(defaultPolicyId);
161c162
<                 policyId = new ObjectIdentifier(defaultPolicyId);
---
>                 policyId = ObjectIdentifier.of(defaultPolicyId);
233c234
<             ContentInfo contentInfo = new ContentInfo(new ObjectIdentifier(
---
>             ContentInfo contentInfo = new ContentInfo(ObjectIdentifier.of(

[2] KnownOIDs Translation:
https://github.com/openjdk/jdk/commit/080b3b83ebffe5149fbc9ac48e921fb51e9c3c63#diff-e6d5bd6b166be4737084473fcf55b0f101a710263c899c19b0df2a702c89a30e

[3] diff JDK16:TSA_testfix_orig.patch resolved_JDK11u:8246709_TSA.patch
<  import jdk.test.lib.process.OutputAnalyzer;
---
>  import jdk.testlibrary.OutputAnalyzer;


From yan at openjdk.java.net  Mon Feb  8 13:19:07 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 8 Feb 2021 13:19:07 GMT
Subject: [jdk13u-dev] RFR: 8243925: Toolkit#getScreenInsets() returns wrong
 value on HiDPI screens (Windows)
Message-ID: <BM6JErJ7SCESYXCdk_Xn1N4xLGHzanOR_LHfNaPmV3I=.c590ca00-aaa1-43cb-a4bb-0ec68b4e2ad0@github.com>

Ahem, third attempt to backport this issue. After creating a PR, doing testing, I realized that newly introduced test change required some modifications. It has a preview feature in terms of 13 totally unrelated to the original issue. 
Unfortunately, I could not find an easy way to amend a backport commit (routine described for a regular PR seems not working here). So I had to close PR,  discard a branch and start anew.

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

Commit messages:
 - Backport 9c415c4d524336157ccaeb780b18d133b19aa527

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/112/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=112&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243925
  Stats: 134 lines in 3 files changed: 121 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/112.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/112/head:pull/112

PR: https://git.openjdk.java.net/jdk13u-dev/pull/112

From martin.doerr at sap.com  Mon Feb  8 13:28:24 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 8 Feb 2021 13:28:24 +0000
Subject: [11u] RFR: 8244683: A TSA server used by tests
In-Reply-To: <AM0PR0202MB34430B25D5273D58D2613AD9EC8F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM4PR02MB3057F599C7D20D24E3B238889AB59@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM0PR0202MB34430B25D5273D58D2613AD9EC8F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB305763F47A21D9AD427CD1839A8F9@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi G?tz,

thanks for the review!

Best regards,
Martin


From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Sent: Montag, 8. Februar 2021 14:18
To: Doerr, Martin <martin.doerr at sap.com>; security-dev <security-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>
Subject: RE: [11u] RFR: 8244683: A TSA server used by tests

Hi Martin,

Thanks for downporting this.
Nice documentation of the changes! Looks good.

Best regards,
  Goetz.

From: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Sent: Tuesday, February 2, 2021 9:28 PM
To: security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: [11u] RFR: 8244683: A TSA server used by tests

Hi,

JDK-8244683 is backported to 11.0.11-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

TimestampCheck.java:
- The parts which get removed contain minor differences (see [1])
- Resolution: Take new version.

TsaHandler.java and TsaSigner.java:
- New code contains usages of KnownOIDs which don't exist in 11u.
- Resolution: Translate them (see [2])

TsaSigner.java:
- New code uses ObjectIdentifier.of
- Resolution: Change back to "new ObjectIdentifier" according to [1]
- Uses HexPrinter (for debug code) which doesn't exist in 11u.
- Resolution: Use HexDumpEncoder instead: System.out.println(new HexDumpEncoder().encode(bytes));

An additional testfix is needed:
https://bugs.openjdk.java.net/browse/JDK-8246709
which applies cleanly except that it needs an import change (see [3]).
That change is not included in the webrev. I just want to push 11u backport of 8244683 together with 8246709 (including [3]) together.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8244683

Original change:
https://hg.openjdk.java.net/jdk/jdk/rev/56bda3e6d148

11u backport:
http://cr.openjdk.java.net/~mdoerr/8244683_TSA_11u/webrev.00/

Please review.

Best regards,
Martin


[1] diff JDK11u:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java JDK16:TimestampCheck_before_8244683.java
65a66
>  *          8242151
137c138
<             ObjectIdentifier policyId = new ObjectIdentifier(defaultPolicyId);
---
>             ObjectIdentifier policyId = ObjectIdentifier.of(defaultPolicyId);
161c162
<                 policyId = new ObjectIdentifier(defaultPolicyId);
---
>                 policyId = ObjectIdentifier.of(defaultPolicyId);
233c234
<             ContentInfo contentInfo = new ContentInfo(new ObjectIdentifier(
---
>             ContentInfo contentInfo = new ContentInfo(ObjectIdentifier.of(

[2] KnownOIDs Translation:
https://github.com/openjdk/jdk/commit/080b3b83ebffe5149fbc9ac48e921fb51e9c3c63#diff-e6d5bd6b166be4737084473fcf55b0f101a710263c899c19b0df2a702c89a30e

[3] diff JDK16:TSA_testfix_orig.patch resolved_JDK11u:8246709_TSA.patch
<  import jdk.test.lib.process.OutputAnalyzer;
---
>  import jdk.testlibrary.OutputAnalyzer;


From christoph.langer at sap.com  Mon Feb  8 13:40:47 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 8 Feb 2021 13:40:47 +0000
Subject: [11u] RFR (XS) 8253353: Crash in C2: guarantee(n != NULL) failed:
 No Node
In-Reply-To: <d4bfeb7e-0ac2-61b7-4d84-1d1b14b89089@redhat.com>
References: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>
 <d4bfeb7e-0ac2-61b7-4d84-1d1b14b89089@redhat.com>
Message-ID: <AM4PR02MB3138B149B633792A7293955F8A8F9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Aleksey,

looks fine, approved.

Best regards
Christoph


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Aleksey Shipilev
> Sent: Montag, 8. Februar 2021 11:33
> To: jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u] RFR (XS) 8253353: Crash in C2: guarantee(n != NULL) failed:
> No Node
> 
> On 2/4/21 9:21 AM, Aleksey Shipilev wrote:
> > Original bugfix:
> >     https://bugs.openjdk.java.net/browse/JDK-8253353
> >     https://git.openjdk.java.net/jdk16/commit/1926765f
> >
> > This fixes the regression introduced by:
> >     https://bugs.openjdk.java.net/browse/JDK-8240576
> >
> > ...which was already backported to 11.0.8.
> >
> > The patch is simple, but it fails to apply cleanly, because one of the asserts
> in loopnode.cpp
> > cannot be placed automatically. I placed near "loop->_nest++" in 11u code.
> >
> > 11u variant:
> >     https://cr.openjdk.java.net/~shade/8253353/webrev.11u.01
> >
> > Testing: tier{1,2,3}; new test fails without the patch, passes with it
> 
> I see Vladimir's review here (but not in my mail, because jdk-updates-dev
> mailing list is
> temporarily broken):
>    https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-
> February/004864.html
> 
> Vladimir says:
>   > It will match our backport exactly if you remove empty line after first
> assert().
> 
> ...and I would prefer to keep it with the original empty line in the code.
> 
> --
> Thanks,
> -Aleksey


From denghui.ddh at alibaba-inc.com  Mon Feb  8 14:12:35 2021
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Mon, 08 Feb 2021 22:12:35 +0800
Subject: =?UTF-8?B?WzExdV0gUkZSIChYUyk6IDgyNjEwMjA6IFdyb25nIGZvcm1hdCBwYXJhbWV0ZXIgaW4gY3Jl?=
 =?UTF-8?B?YXRlX2VtZXJnZW5jeV9jaHVua19wYXRo?=
Message-ID: <46969ae4-8bb6-47b6-8339-42d261c3b400.denghui.ddh@alibaba-inc.com>

Hi team,

This email was not sent successfully due to a problem with the mailing list last week, so I resend this email. Thanks to Christoph for his help:)

Could I have a review of this small fix?

In create_emergency_chunk_path, the call to jio_snprintf used a wrong format parameter "repository_path_len".

This bug was introduced in 8217362(Emergency dump does not work when disk=false is set) and fixed in 8226511(Implement JFR Event Streaming),
It is currently unacceptable to fully backport 8226511 to 11u, so I filed a new issue to fix this problem.

JBS: https://bugs.openjdk.java.net/browse/JDK-8261020
webrev: http://cr.openjdk.java.net/~ddong/8261020/webrev.00/

Thanks,
Denghui Dong

From sgehwolf at redhat.com  Mon Feb  8 14:18:16 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 08 Feb 2021 15:18:16 +0100
Subject: [11u] RFR: 8261089: [TESTBUG] native library of test
 TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x
In-Reply-To: <CAJ8kv5O_zhP677R0nJSC5o=NJn1-7QEdS=k_6E1Ry02u+xa3cg@mail.gmail.com>
References: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>
 <CAJ8kv5NNdRqh_va2Nnt81+G7Yf6x52mht357HOCg_M8D5upQcg@mail.gmail.com>
 <4ebf4aad92d9c2362be4ed9d43248efc8611e09d.camel@redhat.com>
 <CAJ8kv5O_zhP677R0nJSC5o=NJn1-7QEdS=k_6E1Ry02u+xa3cg@mail.gmail.com>
Message-ID: <255443701491ed17ab4d185094e575889bcf8281.camel@redhat.com>

On Mon, 2021-02-08 at 18:16 +0530, Jayashree Huttanagoudar wrote:
> > 
> > Looks fine to me and it fixes early access builds. I can sponsor
> > the fix for you!
> 
> Thank you so much!!

Pushed:
https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7b7a18a77d1b

Thanks,
Severin


From bae at openjdk.java.net  Mon Feb  8 14:30:54 2021
From: bae at openjdk.java.net (Andrew Brygin)
Date: Mon, 8 Feb 2021 14:30:54 GMT
Subject: [jdk13u-dev] RFR: 8243925: Toolkit#getScreenInsets() returns
 wrong value on HiDPI screens (Windows)
In-Reply-To: <BM6JErJ7SCESYXCdk_Xn1N4xLGHzanOR_LHfNaPmV3I=.c590ca00-aaa1-43cb-a4bb-0ec68b4e2ad0@github.com>
References: <BM6JErJ7SCESYXCdk_Xn1N4xLGHzanOR_LHfNaPmV3I=.c590ca00-aaa1-43cb-a4bb-0ec68b4e2ad0@github.com>
Message-ID: <ZzkVVvllPz7IYQUQhhZyIm4N_Q4WRlWUC0AsRpomdgE=.63f3dbcd-9a6a-4aab-a4ce-e41502421eb1@github.com>

On Mon, 8 Feb 2021 13:13:43 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> Ahem, third attempt to backport this issue. After creating a PR, doing testing, I realized that newly introduced test change required some modifications. It has a preview feature in terms of 13 totally unrelated to the original issue. 
> Unfortunately, I could not find an easy way to amend a backport commit (routine described for a regular PR seems not working here). So I had to close PR,  discard a branch and start anew.

Proposed change looks fine to me.

Thanks,
Andrew

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

Marked as reviewed by bae (Reviewer).

PR: https://git.openjdk.java.net/jdk13u-dev/pull/112

From yan at openjdk.java.net  Mon Feb  8 14:38:47 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Mon, 8 Feb 2021 14:38:47 GMT
Subject: [jdk13u-dev] Integrated: 8243925: Toolkit#getScreenInsets() returns
 wrong value on HiDPI screens (Windows)
In-Reply-To: <BM6JErJ7SCESYXCdk_Xn1N4xLGHzanOR_LHfNaPmV3I=.c590ca00-aaa1-43cb-a4bb-0ec68b4e2ad0@github.com>
References: <BM6JErJ7SCESYXCdk_Xn1N4xLGHzanOR_LHfNaPmV3I=.c590ca00-aaa1-43cb-a4bb-0ec68b4e2ad0@github.com>
Message-ID: <6NAGX7qMTSFtcOlo012ynJCNJJEPHRXC5QIclw9C5vg=.9b273fcf-d712-4761-b0c6-c041bbc65087@github.com>

On Mon, 8 Feb 2021 13:13:43 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> Ahem, third attempt to backport this issue. After creating a PR, doing testing, I realized that newly introduced test change required some modifications. It has a preview feature in terms of 13 totally unrelated to the original issue. 
> Unfortunately, I could not find an easy way to amend a backport commit (routine described for a regular PR seems not working here). So I had to close PR,  discard a branch and start anew.

This pull request has now been integrated.

Changeset: f7aa8b5f
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/f7aa8b5f
Stats:     134 lines in 3 files changed: 121 ins; 0 del; 13 mod

8243925: Toolkit#getScreenInsets() returns wrong value on HiDPI screens (Windows)

Reviewed-by: bae
Backport-of: 9c415c4d524336157ccaeb780b18d133b19aa527

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/112

From jhuttana at redhat.com  Mon Feb  8 14:45:57 2021
From: jhuttana at redhat.com (Jayashree Huttanagoudar)
Date: Mon, 8 Feb 2021 20:15:57 +0530
Subject: [11u] RFR: 8261089: [TESTBUG] native library of test
 TestCheckedReleaseCriticalArray.java fails to compile with gcc 4.x
In-Reply-To: <255443701491ed17ab4d185094e575889bcf8281.camel@redhat.com>
References: <CAJ8kv5NDak6SMxGwa-K4BSBUhsG9d6QKstvwFiL6o_1ABrs_HA@mail.gmail.com>
 <CAJ8kv5NNdRqh_va2Nnt81+G7Yf6x52mht357HOCg_M8D5upQcg@mail.gmail.com>
 <4ebf4aad92d9c2362be4ed9d43248efc8611e09d.camel@redhat.com>
 <CAJ8kv5O_zhP677R0nJSC5o=NJn1-7QEdS=k_6E1Ry02u+xa3cg@mail.gmail.com>
 <255443701491ed17ab4d185094e575889bcf8281.camel@redhat.com>
Message-ID: <CAJ8kv5N6oN8dLW30YoiFKTZMpnivUNqEeKEYapH6rzKsk9JtKw@mail.gmail.com>

Hi Severin,


On Mon, Feb 8, 2021 at 7:48 PM Severin Gehwolf <sgehwolf at redhat.com> wrote:

> On Mon, 2021-02-08 at 18:16 +0530, Jayashree Huttanagoudar wrote:
> > >
> > > Looks fine to me and it fixes early access builds. I can sponsor
> > > the fix for you!
> >
> > Thank you so much!!
>
> Pushed:
> https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/7b7a18a77d1b


Thank you!

Regards,
Jaya

>
>
> Thanks,
> Severin
>
>

From christoph.langer at sap.com  Mon Feb  8 14:47:34 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 8 Feb 2021 14:47:34 +0000
Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object
 in java.lang.Thread
In-Reply-To: <CEF4B512-D6AB-4247-B1C5-93682817401F@amazon.com>
References: <CEF4B512-D6AB-4247-B1C5-93682817401F@amazon.com>
Message-ID: <AM4PR02MB313853757A92A27BF1ABC12A8A8F9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

hearing no objections for a decent period of time, I have approved this now. ??

Best regards
Christoph

> -----Original Message-----
> From: Hohensee, Paul <hohensee at amazon.com>
> Sent: Donnerstag, 21. Januar 2021 00:43
> To: Langer, Christoph <christoph.langer at sap.com>; Andrew Haley
> <aph at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> object in java.lang.Thread
> 
> Ping. :)
> 
> ?-----Original Message-----
> From: "Langer, Christoph" <christoph.langer at sap.com>
> Date: Monday, January 18, 2021 at 7:23 AM
> To: Andrew Haley <aph at redhat.com>
> Cc: "Hohensee, Paul" <hohensee at amazon.com>, "jdk-updates-
> dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> object in java.lang.Thread
> 
> Hi Andrew,
> 
> with all evaluation and discussion of this item, I would be ready to approve it.
> Or would you object?
> 
> Cheers
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Hohensee, Paul
> > Sent: Freitag, 15. Januar 2021 20:58
> > To: Andrew Haley <aph at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> > Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> > object in java.lang.Thread
> >
> > As Richard noted, it's a useful cleanup and "reduces footprint without
> > performance cost."
> >
> > Amazon has a number of small performance/footprint backports we've
> been
> > running internally in 11.0.9 for the last 3 months that we?d like to upstream.
> > This is one of them.
> >
> > Thanks,
> > Paul
> >
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on
> > behalf of Andrew Haley <aph at redhat.com>
> > Date: Thursday, January 14, 2021 at 2:51 AM
> > To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-
> > dev at openjdk.java.net>
> > Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> > object in java.lang.Thread
> >
> > Can someone please explain why this P4 Enhancement is proposed for
> > backporting?
> >
> > --
> > 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 kravikumar at openjdk.java.net  Mon Feb  8 15:10:58 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 8 Feb 2021 15:10:58 GMT
Subject: [jdk16u] RFR: 8260356: (tz) Upgrade time-zone data to tzdata2021a
Message-ID: <6RoIX6rKMLi0QR9TawxFfX8pJKqf5QqTpPJn7vPb_Ec=.da614938-9b83-465a-b520-9fab3ed7beef@github.com>

tzdata2021a integration to jdk16u.

Passed regression and applies clean

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

Commit messages:
 - Backport d9aefa36ac1d4b711a3082e3ce6c442d4cb8e718

Changes: https://git.openjdk.java.net/jdk16u/pull/22/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=22&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260356
  Stats: 12 lines in 3 files changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/22.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/22/head:pull/22

PR: https://git.openjdk.java.net/jdk16u/pull/22

From kravikumar at openjdk.java.net  Mon Feb  8 16:52:48 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 8 Feb 2021 16:52:48 GMT
Subject: [jdk16u] Integrated: 8260356: (tz) Upgrade time-zone data to
 tzdata2021a
In-Reply-To: <6RoIX6rKMLi0QR9TawxFfX8pJKqf5QqTpPJn7vPb_Ec=.da614938-9b83-465a-b520-9fab3ed7beef@github.com>
References: <6RoIX6rKMLi0QR9TawxFfX8pJKqf5QqTpPJn7vPb_Ec=.da614938-9b83-465a-b520-9fab3ed7beef@github.com>
Message-ID: <2Bazl0oYlVaXRtgVTriSrTPaBc5s65a84h0YN5ZjJFg=.12ad6c8f-631b-48ac-82f2-31c2db6d9438@github.com>

On Mon, 8 Feb 2021 15:04:12 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> tzdata2021a integration to jdk16u.
> 
> Passed regression and applies clean

This pull request has now been integrated.

Changeset: 78cf59ba
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/78cf59ba
Stats:     12 lines in 3 files changed: 6 ins; 0 del; 6 mod

8260356: (tz) Upgrade time-zone data to tzdata2021a

Backport-of: d9aefa36ac1d4b711a3082e3ce6c442d4cb8e718

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

PR: https://git.openjdk.java.net/jdk16u/pull/22

From evergizova at openjdk.java.net  Mon Feb  8 17:00:15 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Mon, 8 Feb 2021 17:00:15 GMT
Subject: [jdk13u-dev] RFR: 8196969: JTreg Failure:
 serviceability/sa/ClhsdbJstack.java causes NPE
Message-ID: <UftTzg9WM7RUUda37wESinicr8QKHpt9-8rluaJEvb4=.96ab63a0-fada-4d75-9a30-476fcdd73770@github.com>

I'd like to backport 8196969 to 13u for parity with 11u.
The patch applies cleanly.
Tested with tier1; new test fails without the patch, passes with it.

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

Commit messages:
 - Backport c4f5c4fe9ba9c7ee9f46da309d8bff4ecf771f49

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/113/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=113&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8196969
  Stats: 181 lines in 3 files changed: 180 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/113.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/113/head:pull/113

PR: https://git.openjdk.java.net/jdk13u-dev/pull/113

From vladimir.kozlov at oracle.com  Mon Feb  8 17:03:01 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 8 Feb 2021 09:03:01 -0800
Subject: [11u] RFR (XS) 8253353: Crash in C2: guarantee(n != NULL) failed:
 No Node
In-Reply-To: <d4bfeb7e-0ac2-61b7-4d84-1d1b14b89089@redhat.com>
References: <29228a56-dea3-5bc9-125d-1b34b6ca64c2@redhat.com>
 <d4bfeb7e-0ac2-61b7-4d84-1d1b14b89089@redhat.com>
Message-ID: <6cda5af3-d3a3-9d15-19e3-360c3a67c5f6@oracle.com>

I am fine with keeping empty line.

Thanks,
Vladimir K

On 2/8/21 2:33 AM, Aleksey Shipilev wrote:
> On 2/4/21 9:21 AM, Aleksey Shipilev wrote:
>> Original bugfix:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8253353
>> ??? https://git.openjdk.java.net/jdk16/commit/1926765f
>>
>> This fixes the regression introduced by:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8240576
>>
>> ...which was already backported to 11.0.8.
>>
>> The patch is simple, but it fails to apply cleanly, because one of the asserts in loopnode.cpp
>> cannot be placed automatically. I placed near "loop->_nest++" in 11u code.
>>
>> 11u variant:
>> ??? https://cr.openjdk.java.net/~shade/8253353/webrev.11u.01
>>
>> Testing: tier{1,2,3}; new test fails without the patch, passes with it
> 
> I see Vladimir's review here (but not in my mail, because jdk-updates-dev mailing list is temporarily broken):
>  ? https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004864.html
> 
> Vladimir says:
>  ?> It will match our backport exactly if you remove empty line after first assert().
> 
> ...and I would prefer to keep it with the original empty line in the code.
> 

From shade at openjdk.java.net  Mon Feb  8 18:33:58 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 8 Feb 2021 18:33:58 GMT
Subject: [jdk16u] RFR: 8261310: PPC64 Zero build fails with
 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has
 incomplete type and cannot be defined
Message-ID: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>

Note this is **not** a backport, but 16u-specific change.

$ CONF=linux-ppc64-zero-fastdebug make hotspot


 1799 | struct FunctionDescriptor functionDescriptor;
      | ^~~~~~~~~~~~~~~~~~

`FunctionDescriptor` is from `src/hotspot/cpu/ppc/assembler_ppc.hpp`, and obviously not available for Zero.

The affected code was removed by JDK-8252148 in 17, so this issue affects versions below it.
While not exactly the regression for 16, it would be nice to have this fixed for 16 and lower, to get clean builds on all platform configurations, including JDK 16 GA.

The fix is trivial:

diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp
index 9b0dc413bcd..476fdc48e43 100644
--- a/src/hotspot/share/utilities/vmError.cpp
+++ b/src/hotspot/share/utilities/vmError.cpp
@@ -1795,7 +1795,7 @@ void VMError::controlled_crash(int how) {
   char * const dataPtr = NULL; // bad data pointer
   const void (*funcPtr)(void); // bad function pointer
 
-#if defined(PPC64) && !defined(ABI_ELFv2)
+#if defined(PPC64) && !defined(ABI_ELFv2) && !defined(ZERO)
   struct FunctionDescriptor functionDescriptor;
 
   functionDescriptor.set_entry((address) 0xF);

Additional testing:
 - [x] Linux Zero PPC64 fastdebug build

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

Commit messages:
 - 8261310: PPC64 Zero build fails with 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has incomplete type and cannot be defined

Changes: https://git.openjdk.java.net/jdk16u/pull/23/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=23&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261310
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/23.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/23/head:pull/23

PR: https://git.openjdk.java.net/jdk16u/pull/23

From stuefe at openjdk.java.net  Mon Feb  8 18:46:53 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 8 Feb 2021 18:46:53 GMT
Subject: [jdk16u] RFR: 8261310: PPC64 Zero build fails with
 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has
 incomplete type and cannot be defined
In-Reply-To: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>
References: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>
Message-ID: <vwS_EU36GF08AatAGkmIuUc_lsNNey0KWtl46CJ-b8I=.9cc70ee9-1f30-4441-990a-45c25b334c2f@github.com>

On Mon, 8 Feb 2021 18:30:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Note this is **not** a backport, but 16u-specific change.
> 
> $ CONF=linux-ppc64-zero-fastdebug make hotspot
> 
> 
>  1799 | struct FunctionDescriptor functionDescriptor;
>       | ^~~~~~~~~~~~~~~~~~
> 
> `FunctionDescriptor` is from `src/hotspot/cpu/ppc/assembler_ppc.hpp`, and obviously not available for Zero.
> 
> The affected code was removed by JDK-8252148 in 17, so this issue affects versions below it.
> While not exactly the regression for 16, it would be nice to have this fixed for 16 and lower, to get clean builds on all platform configurations, including JDK 16 GA.
> 
> The fix is trivial:
> 
> diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp
> index 9b0dc413bcd..476fdc48e43 100644
> --- a/src/hotspot/share/utilities/vmError.cpp
> +++ b/src/hotspot/share/utilities/vmError.cpp
> @@ -1795,7 +1795,7 @@ void VMError::controlled_crash(int how) {
>    char * const dataPtr = NULL; // bad data pointer
>    const void (*funcPtr)(void); // bad function pointer
>  
> -#if defined(PPC64) && !defined(ABI_ELFv2)
> +#if defined(PPC64) && !defined(ABI_ELFv2) && !defined(ZERO)
>    struct FunctionDescriptor functionDescriptor;
>  
>    functionDescriptor.set_entry((address) 0xF);
> 
> Additional testing:
>  - [x] Linux Zero PPC64 fastdebug build

Still good and trivial.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk16u/pull/23

From iklam at openjdk.java.net  Mon Feb  8 20:51:48 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 8 Feb 2021 20:51:48 GMT
Subject: [jdk16u] RFR: 8261310: PPC64 Zero build fails with
 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has
 incomplete type and cannot be defined
In-Reply-To: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>
References: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>
Message-ID: <WGBHkvDWfZOFlUlq2unzafPzoUfT5kPyNCK8ISIyWQs=.efd7717a-e216-401d-b904-5d37c14d36f1@github.com>

On Mon, 8 Feb 2021 18:30:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Note this is **not** a backport, but 16u-specific change.
> 
> $ CONF=linux-ppc64-zero-fastdebug make hotspot
> 
> 
>  1799 | struct FunctionDescriptor functionDescriptor;
>       | ^~~~~~~~~~~~~~~~~~
> 
> `FunctionDescriptor` is from `src/hotspot/cpu/ppc/assembler_ppc.hpp`, and obviously not available for Zero.
> 
> The affected code was removed by JDK-8252148 in 17, so this issue affects versions below it.
> While not exactly the regression for 16, it would be nice to have this fixed for 16 and lower, to get clean builds on all platform configurations, including JDK 16 GA.
> 
> The fix is trivial:
> 
> diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp
> index 9b0dc413bcd..476fdc48e43 100644
> --- a/src/hotspot/share/utilities/vmError.cpp
> +++ b/src/hotspot/share/utilities/vmError.cpp
> @@ -1795,7 +1795,7 @@ void VMError::controlled_crash(int how) {
>    char * const dataPtr = NULL; // bad data pointer
>    const void (*funcPtr)(void); // bad function pointer
>  
> -#if defined(PPC64) && !defined(ABI_ELFv2)
> +#if defined(PPC64) && !defined(ABI_ELFv2) && !defined(ZERO)
>    struct FunctionDescriptor functionDescriptor;
>  
>    functionDescriptor.set_entry((address) 0xF);
> 
> Additional testing:
>  - [x] Linux Zero PPC64 fastdebug build

Marked as reviewed by iklam (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/23

From hohensee at amazon.com  Mon Feb  8 21:34:33 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 8 Feb 2021 21:34:33 +0000
Subject: [11u] RFR: 8222518: Remove unnecessary caching of Parker object
 in java.lang.Thread
Message-ID: <C30A86E5-736F-45DF-A870-7F78320B1FC3@amazon.com>

Thanks, Christoph. Pushed.

?-----Original Message-----
From: "Langer, Christoph" <christoph.langer at sap.com>
Date: Monday, February 8, 2021 at 6:48 AM
To: "Hohensee, Paul" <hohensee at amazon.com>, Andrew Haley <aph at redhat.com>
Cc: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker object in java.lang.Thread

Hi,

hearing no objections for a decent period of time, I have approved this now. ??

Best regards
Christoph

> -----Original Message-----
> From: Hohensee, Paul <hohensee at amazon.com>
> Sent: Donnerstag, 21. Januar 2021 00:43
> To: Langer, Christoph <christoph.langer at sap.com>; Andrew Haley
> <aph at redhat.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> object in java.lang.Thread
>
> Ping. :)
>
> -----Original Message-----
> From: "Langer, Christoph" <christoph.langer at sap.com>
> Date: Monday, January 18, 2021 at 7:23 AM
> To: Andrew Haley <aph at redhat.com>
> Cc: "Hohensee, Paul" <hohensee at amazon.com>, "jdk-updates-
> dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> object in java.lang.Thread
>
> Hi Andrew,
>
> with all evaluation and discussion of this item, I would be ready to approve it.
> Or would you object?
>
> Cheers
> Christoph
>
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Hohensee, Paul
> > Sent: Freitag, 15. Januar 2021 20:58
> > To: Andrew Haley <aph at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> > Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> > object in java.lang.Thread
> >
> > As Richard noted, it's a useful cleanup and "reduces footprint without
> > performance cost."
> >
> > Amazon has a number of small performance/footprint backports we've
> been
> > running internally in 11.0.9 for the last 3 months that we?d like to upstream.
> > This is one of them.
> >
> > Thanks,
> > Paul
> >
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on
> > behalf of Andrew Haley <aph at redhat.com>
> > Date: Thursday, January 14, 2021 at 2:51 AM
> > To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-
> > dev at openjdk.java.net>
> > Subject: RE: [11u] RFR: 8222518: Remove unnecessary caching of Parker
> > object in java.lang.Thread
> >
> > Can someone please explain why this P4 Enhancement is proposed for
> > backporting?
> >
> > --
> > 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 hedongbo at huawei.com  Tue Feb  9 01:17:35 2021
From: hedongbo at huawei.com (hedongbo)
Date: Tue, 9 Feb 2021 01:17:35 +0000
Subject: FW: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel
Message-ID: <8FC616E5EC1A774287430B1CC2696FE3047397A8@dggeml533-mbs.china.huawei.com>

Ping?

From: hedongbo
Sent: Wednesday, February 3, 2021 5:16 PM
To: jdk-updates-dev at openjdk.java.net
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel


Hi,



Please review the backport of JDK-8246707 to 11u:



Bug: https://bugs.openjdk.java.net/browse/JDK-8246707

Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c8c6030e4d1f

11u webrev: http://cr.openjdk.java.net/~dongbohe/8246707/webrev.00/



This patch doesn't apply cleanly but is fairly trivial. The reason is that the latest jdk8u-dev has no ` blockingRead ` and `blockingWriteFully` function, because they were added in jdk13 through JDK-8222774.




Tested with tier1, tier2. No regression in tests.






Thanks,
dongbohe


From yan at openjdk.java.net  Tue Feb  9 09:12:42 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Tue, 9 Feb 2021 09:12:42 GMT
Subject: [jdk13u-dev] RFR: 8259048: (tz) Upgrade time-zone data to tzdata2020f
Message-ID: <pnAFeJJEV6spiL3lzCHRGGffY3jk9CoShALOnl89njE=.a1c8bbf3-b7b0-4142-8537-8c37c83604b4@github.com>

This tzdata change should be backported here, too. The patch contains changes for 2020e as well. Applies without modifications, all relevant regtests do pass.

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

Commit messages:
 - Backport fe84ecd52b929759c3f355afc20c5356829351d5

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/114/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=114&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259048
  Stats: 729 lines in 10 files changed: 578 ins; 19 del; 132 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/114.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/114/head:pull/114

PR: https://git.openjdk.java.net/jdk13u-dev/pull/114

From yan at openjdk.java.net  Tue Feb  9 09:18:33 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Tue, 9 Feb 2021 09:18:33 GMT
Subject: [jdk13u-dev] Integrated: 8259048: (tz) Upgrade time-zone data to
 tzdata2020f
In-Reply-To: <pnAFeJJEV6spiL3lzCHRGGffY3jk9CoShALOnl89njE=.a1c8bbf3-b7b0-4142-8537-8c37c83604b4@github.com>
References: <pnAFeJJEV6spiL3lzCHRGGffY3jk9CoShALOnl89njE=.a1c8bbf3-b7b0-4142-8537-8c37c83604b4@github.com>
Message-ID: <iEdYba1uRh1SMUlWZ0zbg7RHVGyWW6BmvoZtFDhNZ54=.3aa8b2f4-54ac-4e2b-857e-bf3867968e00@github.com>

On Tue, 9 Feb 2021 09:08:08 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> This tzdata change should be backported here, too. The patch contains changes for 2020e as well. Applies without modifications, all relevant regtests do pass.

This pull request has now been integrated.

Changeset: bb3bbd0d
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/bb3bbd0d
Stats:     729 lines in 10 files changed: 578 ins; 19 del; 132 mod

8259048: (tz) Upgrade time-zone data to tzdata2020f

Backport-of: fe84ecd52b929759c3f355afc20c5356829351d5

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/114

From evergizova at openjdk.java.net  Tue Feb  9 10:56:33 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Tue, 9 Feb 2021 10:56:33 GMT
Subject: [jdk13u-dev] Integrated: 8196969: JTreg Failure:
 serviceability/sa/ClhsdbJstack.java causes NPE
In-Reply-To: <UftTzg9WM7RUUda37wESinicr8QKHpt9-8rluaJEvb4=.96ab63a0-fada-4d75-9a30-476fcdd73770@github.com>
References: <UftTzg9WM7RUUda37wESinicr8QKHpt9-8rluaJEvb4=.96ab63a0-fada-4d75-9a30-476fcdd73770@github.com>
Message-ID: <jhMRbcGn_m0i_6ksblAhjiVrMY2qT-mc7fIcKmy1T1I=.33528c72-f014-4a5d-b976-1a739625c1b0@github.com>

On Mon, 8 Feb 2021 16:51:23 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport 8196969 to 13u for parity with 11u.
> The patch applies cleanly.
> Tested with tier1; new test fails without the patch, passes with it.

This pull request has now been integrated.

Changeset: 962ff982
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/962ff982
Stats:     181 lines in 3 files changed: 180 ins; 0 del; 1 mod

8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE

Account for serialized null scopes in NMethod

Backport-of: c4f5c4fe9ba9c7ee9f46da309d8bff4ecf771f49

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/113

From kravikumar at openjdk.java.net  Wed Feb 10 10:42:52 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Wed, 10 Feb 2021 10:42:52 GMT
Subject: [jdk16u] RFR: 8249867: xml declaration is not followed by a newline
Message-ID: <v4ZB0i-45pc9WBoh4x1ZDiMCvSTyqzeVFAV-_p3dDks=.ba6e0847-c8ad-43a5-8b5b-2fafb5ef9599@github.com>

Backport JDK-8249867 to 16u. Fix verified

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

Commit messages:
 - Backport 69ee314b63a9f260e3dcbe9ccd67ddc4faec3ba0

Changes: https://git.openjdk.java.net/jdk16u/pull/24/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=24&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249867
  Stats: 479 lines in 5 files changed: 428 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/24.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/24/head:pull/24

PR: https://git.openjdk.java.net/jdk16u/pull/24

From evergizova at openjdk.java.net  Wed Feb 10 12:43:51 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Wed, 10 Feb 2021 12:43:51 GMT
Subject: [jdk13u-dev] RFR: 8234662: Sweeper should keep current nmethod alive
 before yielding for ICStub refills
Message-ID: <F2uRwLmw6UW1HoZOd95YoO6E4NQzjq3lbuf-ycxj73Y=.b76feb6b-fee0-4352-aabf-22c4a5a8f504@github.com>

I'd like to backport JDK-8234662 to 13u as a prerequisite for JDK-8235829.
JDK-8234662 adds a piece of code to CompiledMethod::cleanup_inline_caches() that is extracted to separate method (CompiledMethod::run_nmethod_entry_barrier()) and widely used in JDK-8235829.
The patch doesn't apply cleanly due to minor context difference in barrierSetNMethod.hpp (JDK-8230765 is not in 13u), reapplied manually.
Tested with tier1.

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

Commit messages:
 - Backport 22ea33cf7a8d964fedb93e479ad22dc49cb897bf

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/115/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=115&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234662
  Stats: 15 lines in 2 files changed: 14 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/115/head:pull/115

PR: https://git.openjdk.java.net/jdk13u-dev/pull/115

From yan at openjdk.java.net  Wed Feb 10 14:42:43 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Wed, 10 Feb 2021 14:42:43 GMT
Subject: [jdk13u-dev] RFR: 8234662: Sweeper should keep current nmethod
 alive before yielding for ICStub refills
In-Reply-To: <F2uRwLmw6UW1HoZOd95YoO6E4NQzjq3lbuf-ycxj73Y=.b76feb6b-fee0-4352-aabf-22c4a5a8f504@github.com>
References: <F2uRwLmw6UW1HoZOd95YoO6E4NQzjq3lbuf-ycxj73Y=.b76feb6b-fee0-4352-aabf-22c4a5a8f504@github.com>
Message-ID: <RfwCxnwnTXkYjBKBnzpx8Op4rNDQCp5-IzQxoHLP0sU=.be8e1099-a167-4a73-8b51-cbcf855cc670@github.com>

On Wed, 10 Feb 2021 12:38:37 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8234662 to 13u as a prerequisite for JDK-8235829.
> JDK-8234662 adds a piece of code to CompiledMethod::cleanup_inline_caches() that is extracted to separate method (CompiledMethod::run_nmethod_entry_barrier()) and widely used in JDK-8235829.
> The patch doesn't apply cleanly due to minor context difference in barrierSetNMethod.hpp (JDK-8230765 is not in 13u), reapplied manually.
> Tested with tier1.

Marked as reviewed by yan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/115

From yan at openjdk.java.net  Wed Feb 10 15:24:46 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Wed, 10 Feb 2021 15:24:46 GMT
Subject: [jdk13u-dev] Integrated: 8249176: jdk jtreg test
 security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java
 fails
Message-ID: <mhCX0IlzpqFQvM8rvqNWe-PXTVgxGDhqYxShHj3ASXs=.6b66ed36-0364-4678-a87a-bb3fdf413f87@github.com>

I'd like to port this test-only fix to 13u, too. Patch applies clean. Test fails before the fix, pass after.

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

Commit messages:
 - Backport 24578630cf55d5ebc2990924ddc93769fa8c60c8

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/116/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=116&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249176
  Stats: 140 lines in 1 file changed: 11 ins; 1 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/116.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/116/head:pull/116

PR: https://git.openjdk.java.net/jdk13u-dev/pull/116

From yan at openjdk.java.net  Wed Feb 10 15:24:46 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Wed, 10 Feb 2021 15:24:46 GMT
Subject: [jdk13u-dev] Integrated: 8249176: jdk jtreg test
 security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java
 fails
In-Reply-To: <mhCX0IlzpqFQvM8rvqNWe-PXTVgxGDhqYxShHj3ASXs=.6b66ed36-0364-4678-a87a-bb3fdf413f87@github.com>
References: <mhCX0IlzpqFQvM8rvqNWe-PXTVgxGDhqYxShHj3ASXs=.6b66ed36-0364-4678-a87a-bb3fdf413f87@github.com>
Message-ID: <0cxBXRdBa-YVs04eIxqHhE3k2Jf1vVkW0AC9VnRA8ZQ=.04705527-4f0c-4d60-adc7-d6d0ef67925b@github.com>

On Wed, 10 Feb 2021 15:18:08 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I'd like to port this test-only fix to 13u, too. Patch applies clean. Test fails before the fix, pass after.

This pull request has now been integrated.

Changeset: a42820a1
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/a42820a1
Stats:     140 lines in 1 file changed: 11 ins; 1 del; 128 mod

8249176: jdk jtreg test security/infra/java/security/cert/CertPathValidator/certification/GlobalSignR6CA.java fails

Backport-of: 24578630cf55d5ebc2990924ddc93769fa8c60c8

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/116

From evergizova at openjdk.java.net  Wed Feb 10 15:29:37 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Wed, 10 Feb 2021 15:29:37 GMT
Subject: [jdk13u-dev] Integrated: 8234662: Sweeper should keep current nmethod
 alive before yielding for ICStub refills
In-Reply-To: <F2uRwLmw6UW1HoZOd95YoO6E4NQzjq3lbuf-ycxj73Y=.b76feb6b-fee0-4352-aabf-22c4a5a8f504@github.com>
References: <F2uRwLmw6UW1HoZOd95YoO6E4NQzjq3lbuf-ycxj73Y=.b76feb6b-fee0-4352-aabf-22c4a5a8f504@github.com>
Message-ID: <brBLpuNp6Js12WgmaysbOBrcm5CTYlzoRzMyyAU-GUc=.32659a36-fef7-4af1-ba0c-75d9b8c4971d@github.com>

On Wed, 10 Feb 2021 12:38:37 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8234662 to 13u as a prerequisite for JDK-8235829.
> JDK-8234662 adds a piece of code to CompiledMethod::cleanup_inline_caches() that is extracted to separate method (CompiledMethod::run_nmethod_entry_barrier()) and widely used in JDK-8235829.
> The patch doesn't apply cleanly due to minor context difference in barrierSetNMethod.hpp (JDK-8230765 is not in 13u), reapplied manually.
> Tested with tier1.

This pull request has now been integrated.

Changeset: 9bf30f78
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/9bf30f78
Stats:     15 lines in 2 files changed: 14 ins; 1 del; 0 mod

8234662: Sweeper should keep current nmethod alive before yielding for ICStub refills

Reviewed-by: yan
Backport-of: 22ea33cf7a8d964fedb93e479ad22dc49cb897bf

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/115

From evergizova at openjdk.java.net  Wed Feb 10 16:19:50 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Wed, 10 Feb 2021 16:19:50 GMT
Subject: [jdk13u-dev] RFR: 8241319: WB_GetCodeBlob doesn't have ResourceMark
Message-ID: <r1iQbvnxG-u0ggxGHDeKLbLy9vF5tBb67i6dFLTgKAM=.23d9dbe5-55dc-4740-ac24-6011792588ac@github.com>

I'd like to backport JDK-8241319 to 13u for parity with 11u.
The patch applies cleanly.
Tested with tier1.

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

Commit messages:
 - Backport f778ad2f4b014c4ff9bdffe43e8bf4014582db8c

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/117

From christoph.langer at sap.com  Wed Feb 10 16:39:24 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 10 Feb 2021 16:39:24 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13
 cycle
Message-ID: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,



after most of the OpenJDK projects, including OpenJDK updates 13u and 16u, have already moved to git, we'd like to propose the transitioning of 11u to git as well. The topic has been brought up in a few discussions already, e.g. [0].



Our proposal would be to move the JDK 11 updates project to Github/Skara with the 11.0.13 development cycle. The git switch of jdk11u-dev should happen on June 2, 2021, which is when 11.0.13 development starts. With the first promotion of 11.0.13 to the jdk11u stabilization repository on August 3, 2021, we would then also switch the jdk11u repository to git.



This means that On June 2, 2021, the jdk11u-dev mercurial repository [1] would be made read-only and changes for 11.0.13 ought to be pushed to the jdk11u-dev github repo [2]. On August 3, 2021, the jdk11u mercurial repo [3] would be set read-only and the equivalent git repo [4] will be opened for pushes. After the moves, the mercurial repositories will contain 11.0.12 and be updated no further.



This is why we think the project should move to git:

* Git/Github is used by the OpenJDK project in head and the higher update releases. JDK11u will certainly benefit if it uses the same processes

* The tooling and infrastructure (Skara) is the maintained set of tooling

* The Git/Skara processes have the potential to simplify the backporting processes and could improve the productivity in the JDK 11 updates project

* Git is probably the most prevalent SCM for downstream consumers which means that the downstream processes to consume the git repositories should largely be available by now or can be made available until the time of the switch without extraordinary cost



At the time of the 11.0.13 cycle, the backport tooling should have reached a convenient state of maturity, suitable for the 11u project.



Looking forward to your thoughts and arguments...



Best regards,

Christoph and Goetz



[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004450.html

[1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev<http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/>

[2] https://github.com/openjdk/jdk11u-dev

[3] http://hg.openjdk.java.net/jdk-updates/jdk11u

[4] https://github.com/openjdk/jdk11u


From evergizova at openjdk.java.net  Wed Feb 10 17:30:45 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Wed, 10 Feb 2021 17:30:45 GMT
Subject: [jdk13u-dev] RFR: 8235829: graal crashes with Zombie.java test
Message-ID: <EHXiCmfqYq8pZjRygz_n3m8ANsHuJaiZw56BqozvfRE=.a3013bf6-49e3-4513-a219-91895d75872e@github.com>

I'd like to backport JDK-8235829 to 13u for parity with 11u.
The patch doesn't apply cleanly due to minor context difference in management.cpp (JDK-8170299 is not in 13u), reapplied manually.
Tested with tier1.

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

Commit messages:
 - Backport eb6beeac946ba2070c3549fecb2c8aa5bb56f8f3

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/118/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=118&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235829
  Stats: 108 lines in 12 files changed: 75 ins; 17 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/118.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/118/head:pull/118

PR: https://git.openjdk.java.net/jdk13u-dev/pull/118

From kravikumar at openjdk.java.net  Wed Feb 10 17:53:42 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Wed, 10 Feb 2021 17:53:42 GMT
Subject: [jdk16u] Integrated: 8249867: xml declaration is not followed by a
 newline
In-Reply-To: <v4ZB0i-45pc9WBoh4x1ZDiMCvSTyqzeVFAV-_p3dDks=.ba6e0847-c8ad-43a5-8b5b-2fafb5ef9599@github.com>
References: <v4ZB0i-45pc9WBoh4x1ZDiMCvSTyqzeVFAV-_p3dDks=.ba6e0847-c8ad-43a5-8b5b-2fafb5ef9599@github.com>
Message-ID: <ufU1Hn-Kru74SVVP3ZQQOxDZYK5dCdyvrMYyTV7mpPg=.f9a7964c-f111-4270-bbfd-3b1cf9de7381@github.com>

On Wed, 10 Feb 2021 10:35:35 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Backport JDK-8249867 to 16u. Fix verified

This pull request has now been integrated.

Changeset: 6c6c6e67
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/6c6c6e67
Stats:     479 lines in 5 files changed: 428 ins; 2 del; 49 mod

8249867: xml declaration is not followed by a newline

Backport-of: 69ee314b63a9f260e3dcbe9ccd67ddc4faec3ba0

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

PR: https://git.openjdk.java.net/jdk16u/pull/24

From gouessej at orange.fr  Wed Feb 10 18:08:57 2021
From: gouessej at orange.fr (gouessej at orange.fr)
Date: Wed, 10 Feb 2021 19:08:57 +0100 (CET)
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <1095011848.6506.1612980538145.JavaMail.www@wwinf1h06>

Hello

?

Sorry, maybe it's a bit late or silly but will it still be possible to get the source code of OpenJDK >= 11.0.13 and to contribute without using Github? Git != Github. I have nothing against Git, I understand the advantages of the transition but Github is owned by Microsoft, I hope that the mercurial repositories will be kept on the long term and I hope that a Github account won't become mandatory to contribute. I'm worried about the important concentration of open source projects in a single platform controlled by a single company (and as charity begins at home, I have no Github account).

?

Best regards.

?

> Message du 10/02/21 17:40
> De : "Langer, Christoph" 
> A : "jdk-updates-dev at openjdk.java.net" 
> Copie ? : "Lindenmaier, Goetz" , "Andrew Haley" , "Severin Gehwolf" 
> Objet : [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle
> 
> Hi,
> 
> 
> 
> after most of the OpenJDK projects, including OpenJDK updates 13u and 16u, have already moved to git, we'd like to propose the transitioning of 11u to git as well. The topic has been brought up in a few discussions already, e.g. [0].
> 
> 
> 
> Our proposal would be to move the JDK 11 updates project to Github/Skara with the 11.0.13 development cycle. The git switch of jdk11u-dev should happen on June 2, 2021, which is when 11.0.13 development starts. With the first promotion of 11.0.13 to the jdk11u stabilization repository on August 3, 2021, we would then also switch the jdk11u repository to git.
> 
> 
> 
> This means that On June 2, 2021, the jdk11u-dev mercurial repository [1] would be made read-only and changes for 11.0.13 ought to be pushed to the jdk11u-dev github repo [2]. On August 3, 2021, the jdk11u mercurial repo [3] would be set read-only and the equivalent git repo [4] will be opened for pushes. After the moves, the mercurial repositories will contain 11.0.12 and be updated no further.
> 
> 
> 
> This is why we think the project should move to git:
> 
> * Git/Github is used by the OpenJDK project in head and the higher update releases. JDK11u will certainly benefit if it uses the same processes
> 
> * The tooling and infrastructure (Skara) is the maintained set of tooling
> 
> * The Git/Skara processes have the potential to simplify the backporting processes and could improve the productivity in the JDK 11 updates project
> 
> * Git is probably the most prevalent SCM for downstream consumers which means that the downstream processes to consume the git repositories should largely be available by now or can be made available until the time of the switch without extraordinary cost
> 
> 
> 
> At the time of the 11.0.13 cycle, the backport tooling should have reached a convenient state of maturity, suitable for the 11u project.
> 
> 
> 
> Looking forward to your thoughts and arguments...
> 
> 
> 
> Best regards,
> 
> Christoph and Goetz
> 
> 
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004450.html
> 
> [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev
> 
> [2] https://github.com/openjdk/jdk11u-dev
> 
> [3] http://hg.openjdk.java.net/jdk-updates/jdk11u
> 
> [4] https://github.com/openjdk/jdk11u
> 
>

From yan at openjdk.java.net  Thu Feb 11 12:15:57 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 11 Feb 2021 12:15:57 GMT
Subject: [jdk13u-dev] RFR: 8249251: [dark_mode ubuntu 20.04] The selected menu
 is not highlighted in GTKLookAndFeel
Message-ID: <B1KQD0OdKsFutBwdi9minIbJAz1wyGxyUEQG3sSI4yA=.7382cbec-f418-41e2-b22b-8629d8e2c754@github.com>

Tried with different WMs. The fix seems working well with SwingSet2; automatic swing tests don't show any regression.

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

Commit messages:
 - Backport be2a92d8c7365c7aa79a43b53139e2f57fb15390

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=119&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249251
  Stats: 303 lines in 2 files changed: 225 ins; 75 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/119/head:pull/119

PR: https://git.openjdk.java.net/jdk13u-dev/pull/119

From yan at openjdk.java.net  Thu Feb 11 12:18:44 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 11 Feb 2021 12:18:44 GMT
Subject: [jdk13u-dev] Integrated: 8249251: [dark_mode ubuntu 20.04] The
 selected menu is not highlighted in GTKLookAndFeel
In-Reply-To: <B1KQD0OdKsFutBwdi9minIbJAz1wyGxyUEQG3sSI4yA=.7382cbec-f418-41e2-b22b-8629d8e2c754@github.com>
References: <B1KQD0OdKsFutBwdi9minIbJAz1wyGxyUEQG3sSI4yA=.7382cbec-f418-41e2-b22b-8629d8e2c754@github.com>
Message-ID: <c2RCRZXZ5x0azQEeOgVK6aHZSZKTAQCkO83AJQOLtKo=.69696101-a3fe-481d-a27e-43d82e7536a3@github.com>

On Thu, 11 Feb 2021 12:11:14 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> Tried with different WMs. The fix seems working well with SwingSet2; automatic swing tests don't show any regression.

This pull request has now been integrated.

Changeset: 9b4784d1
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/9b4784d1
Stats:     303 lines in 2 files changed: 225 ins; 75 del; 3 mod

8249251: [dark_mode ubuntu 20.04]  The selected menu is not highlighted in GTKLookAndFeel

Backport-of: be2a92d8c7365c7aa79a43b53139e2f57fb15390

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/119

From yan at openjdk.java.net  Thu Feb 11 12:21:46 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 11 Feb 2021 12:21:46 GMT
Subject: [jdk13u-dev] RFR: 8235829: graal crashes with Zombie.java test
In-Reply-To: <EHXiCmfqYq8pZjRygz_n3m8ANsHuJaiZw56BqozvfRE=.a3013bf6-49e3-4513-a219-91895d75872e@github.com>
References: <EHXiCmfqYq8pZjRygz_n3m8ANsHuJaiZw56BqozvfRE=.a3013bf6-49e3-4513-a219-91895d75872e@github.com>
Message-ID: <O1WgVp8jp5Vod1ElSNK51s81yyPBkBYzoGmJuo2mYzY=.bc9a523b-aa54-4aa9-ad32-220b8abcb65b@github.com>

On Wed, 10 Feb 2021 17:25:35 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8235829 to 13u for parity with 11u.
> The patch doesn't apply cleanly due to minor context difference in management.cpp (JDK-8170299 is not in 13u), reapplied manually.
> Tested with tier1.

Marked as reviewed by yan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/118

From evergizova at openjdk.java.net  Thu Feb 11 12:39:45 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Thu, 11 Feb 2021 12:39:45 GMT
Subject: [jdk13u-dev] Integrated: 8235829: graal crashes with Zombie.java test
In-Reply-To: <EHXiCmfqYq8pZjRygz_n3m8ANsHuJaiZw56BqozvfRE=.a3013bf6-49e3-4513-a219-91895d75872e@github.com>
References: <EHXiCmfqYq8pZjRygz_n3m8ANsHuJaiZw56BqozvfRE=.a3013bf6-49e3-4513-a219-91895d75872e@github.com>
Message-ID: <k3scZnQB-Ag7yzFA0tc7-JE7OV0KQWH53FvSPcwDuxE=.31bd1470-e93d-4045-b75e-99d3b28474fa@github.com>

On Wed, 10 Feb 2021 17:25:35 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8235829 to 13u for parity with 11u.
> The patch doesn't apply cleanly due to minor context difference in management.cpp (JDK-8170299 is not in 13u), reapplied manually.
> Tested with tier1.

This pull request has now been integrated.

Changeset: b5216aaf
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/b5216aaf
Stats:     108 lines in 12 files changed: 75 ins; 17 del; 16 mod

8235829: graal crashes with Zombie.java test

Start ServiceThread before compiler threads, and run nmethod barriers for zgc before adding to the service thread queues, or posting events from the java thread.

Reviewed-by: yan
Backport-of: eb6beeac946ba2070c3549fecb2c8aa5bb56f8f3

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/118

From evergizova at openjdk.java.net  Thu Feb 11 12:52:43 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Thu, 11 Feb 2021 12:52:43 GMT
Subject: [jdk13u-dev] Integrated: 8241319: WB_GetCodeBlob doesn't have
 ResourceMark
In-Reply-To: <r1iQbvnxG-u0ggxGHDeKLbLy9vF5tBb67i6dFLTgKAM=.23d9dbe5-55dc-4740-ac24-6011792588ac@github.com>
References: <r1iQbvnxG-u0ggxGHDeKLbLy9vF5tBb67i6dFLTgKAM=.23d9dbe5-55dc-4740-ac24-6011792588ac@github.com>
Message-ID: <NpJeW5RZeGEVJxyNHlaNVwrupgxF1fBUBkyTXM_nf_o=.6b8991d2-e301-4450-8c12-43ec67666990@github.com>

On Wed, 10 Feb 2021 16:14:11 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8241319 to 13u for parity with 11u.
> The patch applies cleanly.
> Tested with tier1.

This pull request has now been integrated.

Changeset: 9f7f443f
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/9f7f443f
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8241319: WB_GetCodeBlob doesn't have ResourceMark

Backport-of: f778ad2f4b014c4ff9bdffe43e8bf4014582db8c

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/117

From Pengfei.Li at arm.com  Thu Feb 11 13:09:29 2021
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Thu, 11 Feb 2021 13:09:29 +0000
Subject: [11u] RFR(S): 8261022: Fix incorrect result of Math.abs() with char
 type
In-Reply-To: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>
References: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>
Message-ID: <PR3PR08MB5850DFB4DCEF1B2A1AEDBB56968C9@PR3PR08MB5850.eurprd08.prod.outlook.com>

Resend

> Hi,
> 
> I'd like to backport JDK-8261022 to jdk11u.
> 
> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8261022
> Modified webrev: http://cr.openjdk.java.net/~pli/rfr/8261022/backport11u/
> 
> This issue causes vectorized abs generate incorrect result when the argument
> has char type. Root cause is that the vector abs operation is not specially
> handled in computing vector element types after we enabled that in JDK-
> 8222074 in jdk13. As JDK-8222074 was backported to jdk11u, jdk11u is also
> affected.
> 
> The patch to fix this is in jdk17 now. The fix does not apply to jdk11u cleanly,
> as VectorNode::is_shift_opcode() is not defined in jdk11u. I have modified
> the patch a little bit to fit this difference.
> 
> Tested jtreg hotspot::tier1 and the newly added jtreg case. No failure after
> the modified patch.
> 
> --
> Thanks,
> Pengfei


From aph at redhat.com  Thu Feb 11 13:41:13 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Feb 2021 13:41:13 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <1095011848.6506.1612980538145.JavaMail.www@wwinf1h06>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <1095011848.6506.1612980538145.JavaMail.www@wwinf1h06>
Message-ID: <040be5f2-d850-1a72-92ef-075d4b66a135@redhat.com>

On 10/02/2021 18:08, gouessej at orange.fr wrote:

> Sorry, maybe it's a bit late or silly but will it still be possible
> to get the source code of OpenJDK >= 11.0.13 and to contribute
> without using Github? Git != Github. I have nothing against Git, I
> understand the advantages of the transition but Github is owned by
> Microsoft,

I imagine that people will mirror OpenJDK @ Github.

> I hope that the mercurial repositories will be kept on the long term

I don't think that will happen.

> and I hope that a Github account won't become mandatory to
> contribute. I'm worried about the important concentration of open
> source projects in a single platform controlled by a single company
> (and as charity begins at home, I have no Github account).

I understand, but the Github workflow is so much better than we had
with Mercurial that it's unlikely anyone will want to return or to
maintain it. Apart from anything else, we're using Github services for
patch review, which work very well. Mercurial simply couldn't scale to
meet our needs.

-- 
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  Thu Feb 11 13:46:53 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Feb 2021 13:46:53 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>

[Add: jdk8u-dev]

On 10/02/2021 16:39, Langer, Christoph wrote:
> This is why we think the project should move to git:

I have no objection to this, but it's important to reach consensus,
which ISO defines as

  General agreement, characterized by the absence of sustained opposition
  to substantial issues by any important part of the concerned interests
  and by a process that involves seeking to take into account the views
  of all parties concerned and to reconcile any conflicting arguments
  Consensus need not imply unanimity.

It's also important not to consider 11 in isolation: while we do not
need to move 8 and 11 simultaneously, I very much do not want to see
them use different workflows for a long period.

-- 
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 omikhaltcova at openjdk.java.net  Thu Feb 11 14:39:53 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Thu, 11 Feb 2021 14:39:53 GMT
Subject: [jdk13u-dev] RFR: 8242283: Can't start JVM when java home path
 includes non-ASCII character
Message-ID: <eb9OrDCNd-ezGn3KE86cuvH2u2sM-kUUnYiqvI0Y3l4=.34473383-a5b6-4115-9029-783eed6a57ac@github.com>

I'd like to backport JDK-8242283 to jdk13u for parity with jdk11u.
It's a partial fix related only to HotSpot. The scope of fixes is the same as for jdk11u. The reasons is the same. 
The original (partial) patch applied cleanly.

Tested manually. This patch is applied after JDK-8240197 and it fixes the following scenario for example:
    System locale: Chinese (Simplified, China) 
    Current format: English (United States) 
    Active code page: 936 
Before the patch:

    $ ./java -version
    Error occurred during initialization of VM
    Failed setting boot class path.
After the patch:

    $ java -version
    openjdk version "11.0.9" 2020-10-20 LTS
    OpenJDK Runtime Environment Zulu11.43+21-CA (build 11.0.9+11-LTS)
    OpenJDK 64-Bit Server VM Zulu11.43+21-CA (build 11.0.9+11-LTS, mixed mode)

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

Commit messages:
 - Backport d34f732b9958149df51a64b15e8af6210f451362

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/120

From yan at openjdk.java.net  Thu Feb 11 15:07:46 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 11 Feb 2021 15:07:46 GMT
Subject: [jdk13u-dev] RFR: 8242283: Can't start JVM when java home path
 includes non-ASCII character
In-Reply-To: <eb9OrDCNd-ezGn3KE86cuvH2u2sM-kUUnYiqvI0Y3l4=.34473383-a5b6-4115-9029-783eed6a57ac@github.com>
References: <eb9OrDCNd-ezGn3KE86cuvH2u2sM-kUUnYiqvI0Y3l4=.34473383-a5b6-4115-9029-783eed6a57ac@github.com>
Message-ID: <XuabnUdG0IVTC1gIFdg9r5ZRv4ll7ISslkrTrhbqufY=.fad6369c-2e4d-46cd-8dfa-a256ea804edd@github.com>

On Thu, 11 Feb 2021 14:34:27 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8242283 to jdk13u for parity with jdk11u.
> It's a partial fix related only to HotSpot. The scope of fixes is the same as for jdk11u. The reasons is the same. 
> The original (partial) patch applied cleanly.
> 
> Tested manually. This patch is applied after JDK-8240197 and it fixes the following scenario for example:
>     System locale: Chinese (Simplified, China) 
>     Current format: English (United States) 
>     Active code page: 936 
>     
> Before the patch:
> 
>     $ ./java -version
>     Error occurred during initialization of VM
>     Failed setting boot class path.
>     
> After the patch:
> 
>     $ ./java -version
>     openjdk version "13.0.7-internal" 2021-04-20
>     OpenJDK Runtime Environment (build 13.0.7-internal+0-adhoc.omikhaltsova.jdk13u-dev-fork)
>     OpenJDK 64-Bit Server VM (build 13.0.7-internal+0-adhoc.omikhaltsova.jdk13u-dev-fork, mixed mode, sharing)

I think next time it would be better to, well, not duplicate a rationale to make a fix partial etc. but add at least a short explanation and maybe some link here, too. In this case, a reviewer would have to make less steps.

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

Marked as reviewed by yan (Reviewer).

PR: https://git.openjdk.java.net/jdk13u-dev/pull/120

From evergizova at openjdk.java.net  Thu Feb 11 15:09:49 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Thu, 11 Feb 2021 15:09:49 GMT
Subject: [jdk13u-dev] RFR: 8227275: Within native OOM error handling,
 assertions may hang the process
Message-ID: <Y5Z_ajEzM9HqT6QfTwVvWqOOXZMzQcXclN-TpAyOrFA=.39c7d92c-7517-4dea-bd03-e4cec77bc7e0@github.com>

I'd like to backport JDK-8227275 to 13u for parity with 11u.
The patch applies cleanly.
Tested with tier1.

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

Commit messages:
 - Backport ac0e72332e7863f65ce9fbd8bfb77181bcaf786d

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/121/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=121&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8227275
  Stats: 40 lines in 10 files changed: 25 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/121.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/121/head:pull/121

PR: https://git.openjdk.java.net/jdk13u-dev/pull/121

From hohensee at amazon.com  Thu Feb 11 15:44:08 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 11 Feb 2021 15:44:08 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
Message-ID: <78128678-B9E9-49D6-A5AF-E8884E8BB6DD@amazon.com>

I very much favor this proposal. I've watched JDK tip development productivity go up significantly since the Github transition and had only a few personal teething problems with the new process. And, Amazon hosts its Corretto distributions on Github, so moving 11u to git will simplify our lives a bit. :)

Thanks,
Paul

?-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of "Langer, Christoph" <christoph.langer at sap.com>
Date: Wednesday, February 10, 2021 at 8:40 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Cc: "Lindenmaier, Goetz" <goetz.lindenmaier at sap.com>, Andrew Haley <aph at redhat.com>, Severin Gehwolf <sgehwolf at redhat.com>
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle

Hi,



after most of the OpenJDK projects, including OpenJDK updates 13u and 16u, have already moved to git, we'd like to propose the transitioning of 11u to git as well. The topic has been brought up in a few discussions already, e.g. [0].



Our proposal would be to move the JDK 11 updates project to Github/Skara with the 11.0.13 development cycle. The git switch of jdk11u-dev should happen on June 2, 2021, which is when 11.0.13 development starts. With the first promotion of 11.0.13 to the jdk11u stabilization repository on August 3, 2021, we would then also switch the jdk11u repository to git.



This means that On June 2, 2021, the jdk11u-dev mercurial repository [1] would be made read-only and changes for 11.0.13 ought to be pushed to the jdk11u-dev github repo [2]. On August 3, 2021, the jdk11u mercurial repo [3] would be set read-only and the equivalent git repo [4] will be opened for pushes. After the moves, the mercurial repositories will contain 11.0.12 and be updated no further.



This is why we think the project should move to git:

* Git/Github is used by the OpenJDK project in head and the higher update releases. JDK11u will certainly benefit if it uses the same processes

* The tooling and infrastructure (Skara) is the maintained set of tooling

* The Git/Skara processes have the potential to simplify the backporting processes and could improve the productivity in the JDK 11 updates project

* Git is probably the most prevalent SCM for downstream consumers which means that the downstream processes to consume the git repositories should largely be available by now or can be made available until the time of the switch without extraordinary cost



At the time of the 11.0.13 cycle, the backport tooling should have reached a convenient state of maturity, suitable for the 11u project.



Looking forward to your thoughts and arguments...



Best regards,

Christoph and Goetz



[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004450.html

[1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev<http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/>

[2] https://github.com/openjdk/jdk11u-dev

[3] http://hg.openjdk.java.net/jdk-updates/jdk11u

[4] https://github.com/openjdk/jdk11u



From evergizova at openjdk.java.net  Thu Feb 11 16:09:44 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Thu, 11 Feb 2021 16:09:44 GMT
Subject: [jdk13u-dev] Integrated: 8227275: Within native OOM error handling,
 assertions may hang the process
In-Reply-To: <Y5Z_ajEzM9HqT6QfTwVvWqOOXZMzQcXclN-TpAyOrFA=.39c7d92c-7517-4dea-bd03-e4cec77bc7e0@github.com>
References: <Y5Z_ajEzM9HqT6QfTwVvWqOOXZMzQcXclN-TpAyOrFA=.39c7d92c-7517-4dea-bd03-e4cec77bc7e0@github.com>
Message-ID: <pCR8ZGx2ExD14_7eYHB23DVVKm5LyGwi132AFeKDs9o=.62060c98-2d54-4532-a3bf-427838693ae6@github.com>

On Thu, 11 Feb 2021 15:05:01 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8227275 to 13u for parity with 11u.
> The patch applies cleanly.
> Tested with tier1.

This pull request has now been integrated.

Changeset: 86ccee1a
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/86ccee1a
Stats:     40 lines in 10 files changed: 25 ins; 0 del; 15 mod

8227275: Within native OOM error handling, assertions may hang the process

Backport-of: ac0e72332e7863f65ce9fbd8bfb77181bcaf786d

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/121

From adinn at redhat.com  Thu Feb 11 16:46:51 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 11 Feb 2021 16:46:51 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
Message-ID: <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>

On 11/02/2021 13:46, Andrew Haley wrote:

> It's also important not to consider 11 in isolation: while we do not
> need to move 8 and 11 simultaneously, I very much do not want to see
> them use different workflows for a long period.
I'm also ok with switching jdk11u.

I'm not sure jdk8u will be quite so easy to switch as it is made up of 
multiple hg repos. We can just clone these hg repos into their own 
separate github repos. However, I'm not sure if the Skara tooling will 
'just work' when we try to relate multiple change sets committed to 
these independent repos to common JIRAs.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From aph at redhat.com  Thu Feb 11 17:20:19 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Feb 2021 17:20:19 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
Message-ID: <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>

On 11/02/2021 16:46, Andrew Dinn wrote:
> On 11/02/2021 13:46, Andrew Haley wrote:
> 
>> It's also important not to consider 11 in isolation: while we do not
>> need to move 8 and 11 simultaneously, I very much do not want to see
>> them use different workflows for a long period.
> I'm also ok with switching jdk11u.
> 
> I'm not sure jdk8u will be quite so easy to switch as it is made up of 
> multiple hg repos. We can just clone these hg repos into their own 
> separate github repos. However, I'm not sure if the Skara tooling will 
> 'just work' when we try to relate multiple change sets committed to 
> these independent repos to common JIRAs.

We can take input from the Skara folk about that. As I understand
it, there are already people who have built a monorepo from JDK 8.

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


From sgehwolf at redhat.com  Thu Feb 11 17:36:58 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 11 Feb 2021 18:36:58 +0100
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <9081060d9eecfe52e24955848fdc0b0b63665da0.camel@redhat.com>

On Wed, 2021-02-10 at 16:39 +0000, Langer, Christoph wrote:
> Hi,
> ?
> after most of the OpenJDK projects, including OpenJDK updates 13u and
> 16u, have already moved to git, we?d like to propose the
> transitioning of 11u to git as well. The topic has been brought up in
> a few discussions already, e.g. [0].
> ?
> Our proposal would be to move the JDK 11 updates project to
> Github/Skara with the 11.0.13 development cycle. The git switch of
> jdk11u-dev should happen on June 2, 2021, which is when 11.0.13
> development starts. With the first promotion of 11.0.13 to the jdk11u
> stabilization repository on August 3, 2021, we would then also switch
> the jdk11u repository to git.
> ?
> This means that On June 2, 2021, the jdk11u-dev mercurial repository
> [1] would be made read-only and changes for 11.0.13 ought to be
> pushed to the jdk11u-dev github repo [2]. On August 3, 2021, the
> jdk11u mercurial repo [3] would be set read-only and the equivalent
> git repo [4] will be opened for pushes. After the moves, the
> mercurial repositories will contain 11.0.12 and be updated no
> further.
> ?
> This is why we think the project should move to git:
> * Git/Github is used by the OpenJDK project in head and the higher
> update releases. JDK11u will certainly benefit if it uses the same
> processes
> * The tooling and infrastructure (Skara) is the maintained set of
> tooling
> * The Git/Skara processes have the potential to simplify the
> backporting processes and could improve the productivity in the JDK
> 11 updates project
> * Git is probably the most prevalent SCM for downstream consumers
> which means that the downstream processes to consume the git
> repositories should largely be available by now or can be made
> available until the time of the switch without extraordinary cost
> ?
> At the time of the 11.0.13 cycle, the backport tooling should have
> reached a convenient state of maturity, suitable for the 11u project.
> ?
> Looking forward to your thoughts and arguments?

I support this proposal, though, I don't have strong feelings either
way :)

Thanks,
Severin


> Best regards,
> Christoph and Goetz
> ?
> [0] 
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-December/004450.html
> [1] http://hg.openjdk.java.net/jdk-updates/jdk11u-dev 
> [2] https://github.com/openjdk/jdk11u-dev
> [3] http://hg.openjdk.java.net/jdk-updates/jdk11u
> [4] https://github.com/openjdk/jdk11u
> ?



From sgehwolf at redhat.com  Thu Feb 11 18:02:33 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 11 Feb 2021 19:02:33 +0100
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
Message-ID: <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>

On Thu, 2021-02-11 at 17:20 +0000, Andrew Haley wrote:
> On 11/02/2021 16:46, Andrew Dinn wrote:
> > On 11/02/2021 13:46, Andrew Haley wrote:
> > 
> > > It's also important not to consider 11 in isolation: while we do not
> > > need to move 8 and 11 simultaneously, I very much do not want to see
> > > them use different workflows for a long period.
> > I'm also ok with switching jdk11u.
> > 
> > I'm not sure jdk8u will be quite so easy to switch as it is made up of 
> > multiple hg repos. We can just clone these hg repos into their own 
> > separate github repos. However, I'm not sure if the Skara tooling will 
> > 'just work' when we try to relate multiple change sets committed to 
> > these independent repos to common JIRAs.
> 
> We can take input from the Skara folk about that. As I understand
> it, there are already people who have built a monorepo from JDK 8.

Does Skara help for getting a forest into mono-repo shape? For mainline
JDK it was JEP 296 which did it[0]. My understanding is that having a
mono-repo is a requirement for a move to git (using skara tooling). If
that's true, we'd have to be doing something similar for JDK 8u first.
Failing that, we'd have to do a different approach for moving JDK 8u.

Also, do we know how well other efforts of getting the mercurial forest
into a single git tree fares in terms of preserving history?

So while moving JDK 11u over seems doable (already a mono-repo; there
is already a git mirror under the openjdk Github namespace[1]), getting
JDK 8u done seems significanly different and more risky.

With that in mind, should a potential move of 11u to git be (time)
dependent on a move of jdk8u to git? I'm not sure...

Thanks,
Severin

[0] https://openjdk.java.net/jeps/296
[1] https://github.com/openjdk/jdk11u
    https://github.com/openjdk/jdk11u-dev


From vladimir.kozlov at oracle.com  Thu Feb 11 18:18:11 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Feb 2021 10:18:11 -0800
Subject: [11u] RFR(S): 8261022: Fix incorrect result of Math.abs() with
 char type
In-Reply-To: <PR3PR08MB5850DFB4DCEF1B2A1AEDBB56968C9@PR3PR08MB5850.eurprd08.prod.outlook.com>
References: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>
 <PR3PR08MB5850DFB4DCEF1B2A1AEDBB56968C9@PR3PR08MB5850.eurprd08.prod.outlook.com>
Message-ID: <6e591fa9-27ba-4b69-8576-2540b5824471@oracle.com>

Backport patch looks good.

Thanks,
Vladimir K

On 2/11/21 5:09 AM, Pengfei Li wrote:
> Resend
> 
>> Hi,
>>
>> I'd like to backport JDK-8261022 to jdk11u.
>>
>> Original JBS: https://bugs.openjdk.java.net/browse/JDK-8261022
>> Modified webrev: http://cr.openjdk.java.net/~pli/rfr/8261022/backport11u/
>>
>> This issue causes vectorized abs generate incorrect result when the argument
>> has char type. Root cause is that the vector abs operation is not specially
>> handled in computing vector element types after we enabled that in JDK-
>> 8222074 in jdk13. As JDK-8222074 was backported to jdk11u, jdk11u is also
>> affected.
>>
>> The patch to fix this is in jdk17 now. The fix does not apply to jdk11u cleanly,
>> as VectorNode::is_shift_opcode() is not defined in jdk11u. I have modified
>> the patch a little bit to fit this difference.
>>
>> Tested jtreg hotspot::tier1 and the newly added jtreg case. No failure after
>> the modified patch.
>>
>> --
>> Thanks,
>> Pengfei
> 

From prr at openjdk.java.net  Thu Feb 11 20:12:54 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 11 Feb 2021 20:12:54 GMT
Subject: [jdk16u] Integrated: 8260380: Upgrade to LittleCMS 2.12
Message-ID: <5p65g7FM1G7W7TvRD6KPTqbFtNMrSRh_8Njwrwlm-cQ=.bc6b4a54-e3ce-42dd-b54a-ce9935e80b39@github.com>

8260380: Upgrade to LittleCMS 2.12.
Reviewed-by: jdv, serb

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

Commit messages:
 - 8260380: Upgrade to LittleCMS 2.12

Changes: https://git.openjdk.java.net/jdk16u/pull/25/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=25&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260380
  Stats: 717 lines in 20 files changed: 249 ins; 286 del; 182 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk16u/pull/25

From prr at openjdk.java.net  Thu Feb 11 20:12:54 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 11 Feb 2021 20:12:54 GMT
Subject: [jdk16u] Integrated: 8260380: Upgrade to LittleCMS 2.12
In-Reply-To: <5p65g7FM1G7W7TvRD6KPTqbFtNMrSRh_8Njwrwlm-cQ=.bc6b4a54-e3ce-42dd-b54a-ce9935e80b39@github.com>
References: <5p65g7FM1G7W7TvRD6KPTqbFtNMrSRh_8Njwrwlm-cQ=.bc6b4a54-e3ce-42dd-b54a-ce9935e80b39@github.com>
Message-ID: <R2AlVKU6yImEOMdTuthcqhtd0BfB1FC8VZzo23GA0j4=.aeffe4cc-baf7-4def-9d4b-6b5c993a6427@github.com>

On Thu, 11 Feb 2021 20:06:42 GMT, Phil Race <prr at openjdk.org> wrote:

> 8260380: Upgrade to LittleCMS 2.12.
> Reviewed-by: jdv, serb

This pull request has now been integrated.

Changeset: 988dfa8c
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/988dfa8c
Stats:     717 lines in 20 files changed: 249 ins; 286 del; 182 mod

8260380: Upgrade to LittleCMS 2.12

Backport-of: 4caeb39f01b13b5472d8dacb268262fd418fd0c4

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

PR: https://git.openjdk.java.net/jdk16u/pull/25

From goetz.lindenmaier at sap.com  Thu Feb 11 20:47:33 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 11 Feb 2021 20:47:33 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
Message-ID: <AM0PR0202MB344339CEE8E7D957B5AC3D01EC8C9@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

> So while moving JDK 11u over seems doable (already a mono-repo; there
> is already a git mirror under the openjdk Github namespace[1]), getting
> JDK 8u done seems significanly different and more risky.
> 
> With that in mind, should a potential move of 11u to git be (time)
> dependent on a move of jdk8u to git? I'm not sure...

I think so too.  I don't see strong arguments to tie the two 
together.  Especially I see no argument that holds for
tying  8 to 11 that does not hold as well to tie 11 to {17, 15, 13}.
As 13 and 15 already are on git, 11 should follow.  And 17u 
will be started in the time frame where we would transition 11u 
to git (probably in July).

Best regards,
  Goetz.


> 
> Thanks,
> Severin
> 
> [0] https://openjdk.java.net/jeps/296
> [1] https://github.com/openjdk/jdk11u
>     https://github.com/openjdk/jdk11u-dev


From gnu.andrew at redhat.com  Fri Feb 12 07:15:59 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 12 Feb 2021 07:15:59 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
Message-ID: <20210212071559.GC340416@rincewind>

On 13:46 Thu 11 Feb     , Andrew Haley wrote:
> [Add: jdk8u-dev]
> 
> On 10/02/2021 16:39, Langer, Christoph wrote:
> > This is why we think the project should move to git:
> 
> I have no objection to this, but it's important to reach consensus,
> which ISO defines as
> 
>   General agreement, characterized by the absence of sustained opposition
>   to substantial issues by any important part of the concerned interests
>   and by a process that involves seeking to take into account the views
>   of all parties concerned and to reconcile any conflicting arguments
>   Consensus need not imply unanimity.
> 
> It's also important not to consider 11 in isolation: while we do not
> need to move 8 and 11 simultaneously, I very much do not want to see
> them use different workflows for a long period.
> 
> -- 
> 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
> 

I have still not seen any answer to my question of how a bulk update is
pushed for the CPU.

My own attempts to backport to jdk13u suggest the tooling still needs
work on this, or at least better documentation. [0]

OpenJDK 16, the first release to use git during development, has not
even been released yet. Why the rush?

I don't see any reason at all to start altering 8u at such a late
stage in its development.  All risk and no gain.

[0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241
-- 
Andrew :)

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

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

From christoph.langer at sap.com  Fri Feb 12 08:38:01 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 12 Feb 2021 08:38:01 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <20210212071559.GC340416@rincewind>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
Message-ID: <AM4PR02MB3138ACF737D31A99F0E0A3D68A8B9@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Andrew,

you have valid concerns which I hope we can get sorted out until the proposed 11u switch. Let me answer in detail:

> I have still not seen any answer to my question of how a bulk update is
> pushed for the CPU.

I think generally this is kind of answered. For the 11u <-> 11u-dev merges we can use a facility called "Merge PR", something like people used to merge jdk16 back into jdk [0].
Although I've not yet done it myself and will need to talk to Skara folks to get it explained better, I think this is what we can use.

For working on the CPU I hope to be able to use "git bundle" to distribute the state of work on vuln-dev (Similar to what we do with hg bundle now) and eventually push the release via a Merge PR. I will explore this in detail in the next weeks and see if it's bound to work. In case I don't see it working, I'd consider it a showstopper. So I'll update you on this soon, in time before the advised github switch.

> My own attempts to backport to jdk13u suggest the tooling still needs
> work on this, or at least better documentation. [0]

I think you have a point here. As far as I know the "git backport" command does not exist yet and also the process to backport a change by commenting "/backport" on the original change in the jdk repository is not activated yet. I've brought this up to the skara team and they said that they hope to be able to enable it soon [1]. At the moment a backport would work like documented in the manual steps of this link [2] - which is not too convenient. I'll approach Skara folks again about that.

> OpenJDK 16, the first release to use git during development, has not
> even been released yet. Why the rush?

Well, I would not consider it to be in a rush, given the proposal of switching in about 4 months from now. But overall, to align processes, to me it seems favorable to go to git with 11u and we should not overly delay it. At that time JDK16 and its first update release 16.0.1 will have been delivered out of git (as well as a few jdk13u update releases).

> I don't see any reason at all to start altering 8u at such a late
> stage in its development.  All risk and no gain.

That's a different discussion which I won't take part in as I'm not involved so much in 8u. The only point I have on that is that there's no reason to couple the decisions for 8 and 11, as was stated by Severin and Goetz already.

Best regards
Christoph

[0] https://github.com/openjdk/jdk/pull/2392
[1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-January/004051.html
[2] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI


From yan at openjdk.java.net  Fri Feb 12 09:16:57 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 12 Feb 2021 09:16:57 GMT
Subject: [jdk13u-dev] Integrated: 8243321: Add Entrust root CA - G4 to Oracle
 Root CA program
Message-ID: <lQkQ4afppRwdzs-6zwKwmiqG9jv_3jOohcJxZeyLGng=.82611fd8-db87-45e0-8d99-31c1be65ab98@github.com>

The fix makes 13u closer to LTS releases and 15u, cacerts-wide. Applies clean. Tests run OK (well, for test/jdk/sun/security/lib/cacerts/VerifyCACerts.java to fully pass at this moment we need to exclude 5 1024-bit certificates). 
The follow-up will be 8243320.

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

Commit messages:
 - Backport 6e323383307da768f9b91906f07d3221580ac180

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/122/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=122&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243321
  Stats: 217 lines in 3 files changed: 198 ins; 3 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/122.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/122/head:pull/122

PR: https://git.openjdk.java.net/jdk13u-dev/pull/122

From yan at openjdk.java.net  Fri Feb 12 09:16:58 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 12 Feb 2021 09:16:58 GMT
Subject: [jdk13u-dev] Integrated: 8243321: Add Entrust root CA - G4 to Oracle
 Root CA program
In-Reply-To: <lQkQ4afppRwdzs-6zwKwmiqG9jv_3jOohcJxZeyLGng=.82611fd8-db87-45e0-8d99-31c1be65ab98@github.com>
References: <lQkQ4afppRwdzs-6zwKwmiqG9jv_3jOohcJxZeyLGng=.82611fd8-db87-45e0-8d99-31c1be65ab98@github.com>
Message-ID: <4Qfq6LxDsdLSfGmdEV3vZnxrMN0xJpInKh-UXlcwX0s=.e5d1ba04-9ffa-4dca-aea9-0237365a7b67@github.com>

On Fri, 12 Feb 2021 09:08:41 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> The fix makes 13u closer to LTS releases and 15u, cacerts-wide. Applies clean. Tests run OK (well, for test/jdk/sun/security/lib/cacerts/VerifyCACerts.java to fully pass at this moment we need to exclude 5 1024-bit certificates). 
> The follow-up will be 8243320.

This pull request has now been integrated.

Changeset: c36fb9aa
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/c36fb9aa
Stats:     217 lines in 3 files changed: 198 ins; 3 del; 16 mod

8243321: Add Entrust root CA - G4 to Oracle Root CA program

Backport-of: 6e323383307da768f9b91906f07d3221580ac180

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/122

From aph at redhat.com  Fri Feb 12 09:45:24 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 12 Feb 2021 09:45:24 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
Message-ID: <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>

On 11/02/2021 18:02, Severin Gehwolf wrote:
> On Thu, 2021-02-11 at 17:20 +0000, Andrew Haley wrote:
>> On 11/02/2021 16:46, Andrew Dinn wrote:
>>> On 11/02/2021 13:46, Andrew Haley wrote:
>>>
>>>> It's also important not to consider 11 in isolation: while we do not
>>>> need to move 8 and 11 simultaneously, I very much do not want to see
>>>> them use different workflows for a long period.
>>> I'm also ok with switching jdk11u.
>>>
>>> I'm not sure jdk8u will be quite so easy to switch as it is made up of
>>> multiple hg repos. We can just clone these hg repos into their own
>>> separate github repos. However, I'm not sure if the Skara tool:
ing will
>>> 'just work' when we try to relate multiple change sets committed to
>>> these independent repos to common JIRAs.
>>
>> We can take input from the Skara folk about that. As I understand
>> it, there are already people who have built a monorepo from JDK 8.
>
> Does Skara help for getting a forest into mono-repo shape? For mainline
> JDK it was JEP 296 which did it[0]. My understanding is that having a
> mono-repo is a requirement for a move to git (using skara tooling). If
> that's true, we'd have to be doing something similar for JDK 8u first.
> Failing that, we'd have to do a different approach for moving JDK 8u.

What problems do you forsee? Nothing would be moved or altered, except
perhaps to delete get_source.sh, but even that isn't essential.

Have a look at https://github.com/AdoptOpenJDK/openjdk-jdk8u.

> Also, do we know how well other efforts of getting the mercurial forest
> into a single git tree fares in terms of preserving history?

IMO that one isn't a show stopper, given that the old Hg stuff still
exists.

> So while moving JDK 11u over seems doable (already a mono-repo; there
> is already a git mirror under the openjdk Github namespace[1]), getting
> JDK 8u done seems significanly different and more risky.
>
> With that in mind, should a potential move of 11u to git be (time)
> dependent on a move of jdk8u to git? I'm not sure...
Certainly not.

I do not propose to make 11 wait for 8; but neither do I want 8 to
languish in a dusty corner.

Mind you, there would be one advantage: the more difficult it is
to contribute to 8u, the less churn there would be. Hmm, (half
joking) maybe we should leave 8 on Hg to stop people from
changing it.

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


From yan at openjdk.java.net  Fri Feb 12 09:53:59 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 12 Feb 2021 09:53:59 GMT
Subject: [jdk13u-dev] RFR: 8243320: Add SSL root certificates to Oracle Root
 CA program
Message-ID: <Dkelmu5-3TMemhtS86lAEBgUYFRQ_UP0GJ_ZXFo3AHI=.69e43edd-0713-4fd1-accd-bd1b088502e6@github.com>

Porting this fix would make 13u closer to LTS releases and 15. Applies clean, tests run OK.

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

Commit messages:
 - Backport 1e535dfa53db807ef7b624fea93614530f35d443

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/123/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=123&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243320
  Stats: 603 lines in 5 files changed: 600 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/123.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/123/head:pull/123

PR: https://git.openjdk.java.net/jdk13u-dev/pull/123

From yan at openjdk.java.net  Fri Feb 12 09:58:46 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 12 Feb 2021 09:58:46 GMT
Subject: [jdk13u-dev] Integrated: 8243320: Add SSL root certificates to Oracle
 Root CA program
In-Reply-To: <Dkelmu5-3TMemhtS86lAEBgUYFRQ_UP0GJ_ZXFo3AHI=.69e43edd-0713-4fd1-accd-bd1b088502e6@github.com>
References: <Dkelmu5-3TMemhtS86lAEBgUYFRQ_UP0GJ_ZXFo3AHI=.69e43edd-0713-4fd1-accd-bd1b088502e6@github.com>
Message-ID: <flOzvJOrokBn_5kiMkxX7pIPY6qmU314ACSBnBGNz_Q=.bd19f258-c4c7-4e48-932b-940544ad5f9e@github.com>

On Fri, 12 Feb 2021 09:47:46 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> Porting this fix would make 13u closer to LTS releases and 15. Applies clean, tests run OK.

This pull request has now been integrated.

Changeset: 4273ff4a
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/4273ff4a
Stats:     603 lines in 5 files changed: 600 ins; 0 del; 3 mod

8243320: Add SSL root certificates to Oracle Root CA program

Backport-of: 1e535dfa53db807ef7b624fea93614530f35d443

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/123

From evergizova at openjdk.java.net  Fri Feb 12 10:03:58 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 12 Feb 2021 10:03:58 GMT
Subject: [jdk13u-dev] RFR: 8229815: Upgrade Jline to 3.12.1
Message-ID: <novC_7XSgYDO6nO3Aj8Py26bX-teDlTpRlVNsjD4qu8=.1396b934-5023-4dd9-ae24-ca8a1fa53aaa@github.com>

I'd like to backport JDK-8229815 to 13u for parity with 11u.
The patch applies cleanly.
Tested with tier1 and jshell tier2 tests.

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

Commit messages:
 - Backport a9952bb5d9fe2fbf12d4ba43608dfc830180ec86

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/124/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=124&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8229815
  Stats: 1501 lines in 103 files changed: 880 ins; 147 del; 474 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/124.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/124/head:pull/124

PR: https://git.openjdk.java.net/jdk13u-dev/pull/124

From doko at ubuntu.com  Fri Feb 12 11:27:45 2021
From: doko at ubuntu.com (Matthias Klose)
Date: Fri, 12 Feb 2021 12:27:45 +0100
Subject: status of jdk-17 as an LTS release?
Message-ID: <3196107d-e6fd-84e9-2146-65e6d9106cb0@ubuntu.com>

I'm trying to find some information about the LTS status of the upcoming jdk-17
release.  The only document I am aware of are slides from Marc Reinhold from a
talk given at FOSDEM, and mentioning of the LTS status for jdk-17 at one of the
jdk developer meetings following the FOSDEMs in 2019 and 2020.

Bootstrapping 16 or 17 from 11 is a bit tedious, therefore I did propose to also
include 16 or 17 into the upcoming Debian release.  17 would be a better choice
if it's an LTS release.

Thanks, Matthias

From evergizova at openjdk.java.net  Fri Feb 12 11:42:43 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 12 Feb 2021 11:42:43 GMT
Subject: [jdk13u-dev] Integrated: 8229815: Upgrade Jline to 3.12.1
In-Reply-To: <novC_7XSgYDO6nO3Aj8Py26bX-teDlTpRlVNsjD4qu8=.1396b934-5023-4dd9-ae24-ca8a1fa53aaa@github.com>
References: <novC_7XSgYDO6nO3Aj8Py26bX-teDlTpRlVNsjD4qu8=.1396b934-5023-4dd9-ae24-ca8a1fa53aaa@github.com>
Message-ID: <FbDFgMhCfMGGt6enfeH2X6f8Y_Ogvs1gJr0JJ60vHgI=.24ee2b6c-7afe-4eda-a328-3a932ed0156c@github.com>

On Fri, 12 Feb 2021 09:57:37 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8229815 to 13u for parity with 11u.
> The patch applies cleanly.
> Tested with tier1 and jshell tier2 tests.

This pull request has now been integrated.

Changeset: 85191334
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/85191334
Stats:     1501 lines in 103 files changed: 880 ins; 147 del; 474 mod

8229815: Upgrade Jline to 3.12.1

Backport-of: a9952bb5d9fe2fbf12d4ba43608dfc830180ec86

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/124

From evergizova at openjdk.java.net  Fri Feb 12 12:58:05 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 12 Feb 2021 12:58:05 GMT
Subject: [jdk13u-dev] RFR: 8241598: Upgrade JLine to 3.14.0
Message-ID: <uHHOqN5sMiJd_AdjCQJZqKKT-c8i07RAvmbm9YkJ-JE=.363cd12d-6213-4421-a184-92d858803dd1@github.com>

I'd like to backport JDK-8241598 to 13u for parity with 11u.
The patch applies cleanly.
Follow-up fix JDK-8242030 is planned to be backported as well.
Tested (after applying JDK-8242030) with tier1 and jshell tier2 tests.

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

Commit messages:
 - Backport f1ef83b02e40882bad9dc0c0daac071896099529

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/125/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=125&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241598
  Stats: 1431 lines in 40 files changed: 1194 ins; 88 del; 149 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/125.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/125/head:pull/125

PR: https://git.openjdk.java.net/jdk13u-dev/pull/125

From omikhaltcova at openjdk.java.net  Fri Feb 12 14:24:43 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 12 Feb 2021 14:24:43 GMT
Subject: [jdk13u-dev] Integrated: 8242283: Can't start JVM when java home path
 includes non-ASCII character
In-Reply-To: <eb9OrDCNd-ezGn3KE86cuvH2u2sM-kUUnYiqvI0Y3l4=.34473383-a5b6-4115-9029-783eed6a57ac@github.com>
References: <eb9OrDCNd-ezGn3KE86cuvH2u2sM-kUUnYiqvI0Y3l4=.34473383-a5b6-4115-9029-783eed6a57ac@github.com>
Message-ID: <ZuiRgEeSsjcWkrPwmYNmcWnrQcL3SBmAvv8awJCiFIo=.80fbecac-40fb-412c-8b07-de3a82b054b3@github.com>

On Thu, 11 Feb 2021 14:34:27 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8242283 to jdk13u for parity with jdk11u.
> It's a partial fix related only to HotSpot. The scope of fixes is the same as for jdk11u. The reasons is the same. 
> The original (partial) patch applied cleanly.
> 
> Tested manually. This patch is applied after JDK-8240197 and it fixes the following scenario for example:
>     System locale: Chinese (Simplified, China) 
>     Current format: English (United States) 
>     Active code page: 936 
>     
> Before the patch:
> 
>     $ ./java -version
>     Error occurred during initialization of VM
>     Failed setting boot class path.
>     
> After the patch:
> 
>     $ ./java -version
>     openjdk version "13.0.7-internal" 2021-04-20
>     OpenJDK Runtime Environment (build 13.0.7-internal+0-adhoc.omikhaltsova.jdk13u-dev-fork)
>     OpenJDK 64-Bit Server VM (build 13.0.7-internal+0-adhoc.omikhaltsova.jdk13u-dev-fork, mixed mode, sharing)

This pull request has now been integrated.

Changeset: c229f3c9
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/c229f3c9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8242283: Can't start JVM when java home path includes non-ASCII character

Reviewed-by: yan
Backport-of: d34f732b9958149df51a64b15e8af6210f451362

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/120

From sgehwolf at redhat.com  Fri Feb 12 16:37:49 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 12 Feb 2021 17:37:49 +0100
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
Message-ID: <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>

On Fri, 2021-02-12 at 09:45 +0000, Andrew Haley wrote:
> On 11/02/2021 18:02, Severin Gehwolf wrote:
> > Does Skara help for getting a forest into mono-repo shape? For mainline
> > JDK it was JEP 296 which did it[0]. My understanding is that having a
> > mono-repo is a requirement for a move to git (using skara tooling). If
> > that's true, we'd have to be doing something similar for JDK 8u first.
> > Failing that, we'd have to do a different approach for moving JDK 8u.
> 
> What problems do you forsee? Nothing would be moved or altered, except
> perhaps to delete get_source.sh, but even that isn't essential.
> 
> Have a look at https://github.com/AdoptOpenJDK/openjdk-jdk8u.

Good question. My worry is that we get some detail wrong and discover
it after the switch, when it's too late to change. Some food for
thought:

- Timestamps should match (they don't seem to match the original
  commits in the above repo)
- What are the requirements to get a verified tree up in the openjdk
  namespace? Does it need to pass jcheck for every commit? Do we
  need to relax jcheck/verification for the initial population of the
  repository?
- No extra tags (there seem to be some extra tags in the repo above).
- Is there proper tag-for-tag alignment? Checking out jdk8u282-b08 from
  HG should produce the same sources than checking out jdk8u282-b08
  from monorepo/git.
- What updates would be required for JBS integration? Is that taken
  care of by Skara?

Most of these things seem to be solved with the JEP 296 scripts. The
rest would be solved by skara tooling once there is a monorepo (I
think). At least that's my understanding.

> > Also, do we know how well other efforts of getting the mercurial forest
> > into a single git tree fares in terms of preserving history?
> 
> IMO that one isn't a show stopper, given that the old Hg stuff still
> exists.

Well, to clarify, there is no way we are going to be able to preserve
commit hashes in this conversion. But we at least need accurate enough
history which matches the HG forest history with expected differences
(like cross repo changes for the same bug having multiple commits). The
requirement for me would be that the history goes all the way back to
its inception and would be self-sufficient (no extra HG clone needed).

> 
Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
more thought than 11u.

My preference would be to do it in steps:
1.) HG forest -> monorepo conversion (using JEP 296 scripts)
2.) HG -> git conversion using Skara tooling (should take care of
    proper metadata, etc.)

Thanks,
Severin


From evergizova at openjdk.java.net  Fri Feb 12 17:09:40 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 12 Feb 2021 17:09:40 GMT
Subject: [jdk13u-dev] Integrated: 8241598: Upgrade JLine to 3.14.0
In-Reply-To: <uHHOqN5sMiJd_AdjCQJZqKKT-c8i07RAvmbm9YkJ-JE=.363cd12d-6213-4421-a184-92d858803dd1@github.com>
References: <uHHOqN5sMiJd_AdjCQJZqKKT-c8i07RAvmbm9YkJ-JE=.363cd12d-6213-4421-a184-92d858803dd1@github.com>
Message-ID: <_lTQkg3rg8Kgoth_ngDIkibMuAYHu2chRSB8jC1gefI=.f355362e-4c19-4c11-871b-41c08f07be7c@github.com>

On Fri, 12 Feb 2021 12:48:19 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8241598 to 13u for parity with 11u.
> The patch applies cleanly.
> Follow-up fix JDK-8242030 is planned to be backported as well.
> Tested (after applying JDK-8242030) with tier1 and jshell tier2 tests.

This pull request has now been integrated.

Changeset: 7d292c8c
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/7d292c8c
Stats:     1431 lines in 40 files changed: 1194 ins; 88 del; 149 mod

8241598: Upgrade JLine to 3.14.0

Upgrading to JLine 3.14.0

Backport-of: f1ef83b02e40882bad9dc0c0daac071896099529

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/125

From evergizova at openjdk.java.net  Fri Feb 12 17:32:01 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 12 Feb 2021 17:32:01 GMT
Subject: [jdk13u-dev] RFR: 8242030: Wrong package declarations in jline
 classes after JDK-8241598
Message-ID: <f_nAOHnVu9Yw-OABbfDXI-ia7P4Tompg_G1YqHZfIr4=.4cd8a3e5-7330-4cd3-85f7-13aa62aa3b73@github.com>

I'd like to backport JDK-8242030 to 13u as follow-up fix for JDK-8241598 that is already included to 13u.
The patch applies cleanly.
Tested with tier1 and jshell tier2 tests.

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

Commit messages:
 - Backport 746d28d110c8b63007491560d6f5ba3a337ed9dd

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=126&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8242030
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/126/head:pull/126

PR: https://git.openjdk.java.net/jdk13u-dev/pull/126

From adinn at redhat.com  Fri Feb 12 17:39:39 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Fri, 12 Feb 2021 17:39:39 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
Message-ID: <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>

On 12/02/2021 16:37, Severin Gehwolf wrote:
> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
> more thought than 11u.

That's what I was thinking.

> My preference would be to do it in steps:
> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
> 2.) HG -> git conversion using Skara tooling (should take care of
>      proper metadata, etc.)
Yes, I think this is the right way to go about it. If nothing else 
because the tools for the second step assumed that the first one had 
happened.

The really tricky differences I see happen at step 1 (although they 
might have a knock-on effect at step 2)

   JEP 296 had to relocate all the java code into modules
   JEP 296 did not have to retain (and therefore relocate) all of the 
java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)

I don't suppose these differences would be impossible to sort out but I 
think they would require some effort.

regards,


Andrew Dinn
-----------


From aph at redhat.com  Fri Feb 12 18:52:06 2021
From: aph at redhat.com (Andrew Haley)
Date: Fri, 12 Feb 2021 18:52:06 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <20210212071559.GC340416@rincewind>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
Message-ID: <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com>

On 12/02/2021 07:15, Andrew Hughes wrote:
> even been released yet. Why the rush?
> 
> I don't see any reason at all to start altering 8u at such a late
> stage in its development.  All risk and no gain.
> 
> [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241

We've always been a bit short of boots on the ground, and being
stuck on an obsolete VCS will only isolate 8u even more. Maybe this
is an optimist-versus-pessimist thing, but 8u may be about halfway
through its lifetime! <ducks>

-- 
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 dalibor.topic at oracle.com  Fri Feb 12 20:05:57 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 12 Feb 2021 21:05:57 +0100
Subject: status of jdk-17 as an LTS release?
In-Reply-To: <3196107d-e6fd-84e9-2146-65e6d9106cb0@ubuntu.com>
References: <3196107d-e6fd-84e9-2146-65e6d9106cb0@ubuntu.com>
Message-ID: <4c08e9e4-4feb-273a-5bca-eb5d610c10c1@oracle.com>

Hi Matthias,

Planning for JDK 17 has just started a few weeks ago on 
https://openjdk.java.net/projects/jdk/17/

I assume that many distributors of OpenJDK builds expect JDK 17 to 
become an LTS release for them, but I wouldn't expect to see it on 
official support roadmaps until it's (close to being) released.

cheers,

dalibor topic

On 12.02.2021 12:27, Matthias Klose wrote:
> I'm trying to find some information about the LTS status of the upcoming jdk-17
> release.  The only document I am aware of are slides from Marc Reinhold from a
> talk given at FOSDEM, and mentioning of the LTS status for jdk-17 at one of the
> jdk developer meetings following the FOSDEMs in 2019 and 2020.
>
> Bootstrapping 16 or 17 from 11 is a bit tedious, therefore I did propose to also
> include 16 or 17 into the upcoming Debian release.  17 would be a better choice
> if it's an LTS release.
>
> Thanks, Matthias
-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961 
<tel:+491737185961>, Video: dalibor.topic at oracle.com 
<sip:dalibor.topic at oracle.com>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From volker.simonis at gmail.com  Fri Feb 12 21:33:47 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 12 Feb 2021 22:33:47 +0100
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
Message-ID: <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>

On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
>
> On 12/02/2021 16:37, Severin Gehwolf wrote:
> > Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
> > more thought than 11u.
>
> That's what I was thinking.
>
> > My preference would be to do it in steps:
> > 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
> > 2.) HG -> git conversion using Skara tooling (should take care of
> >      proper metadata, etc.)
> Yes, I think this is the right way to go about it. If nothing else
> because the tools for the second step assumed that the first one had
> happened.
>
> The really tricky differences I see happen at step 1 (although they
> might have a knock-on effect at step 2)
>

I think converting 8u to a Git mono-repo might not be as complicated
and risky as it seems. We have to remember that most of the work has
already been done by JEP 296 in jdk10. That process already converted
all the old history and as nobody seems to have been complaining about
it in jdk10 and later, that conversion must have been fine. I.e. The
jdk 10 repository naturally contains the sources of jdk8 from which is
was initially forked (I think at jdk8-b120).

So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:

hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120

This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
we only have to use the JEP 296 scripts or something equivalent (I
hope that the Oracle build group can assist or at least give some good
advice here :)

>From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
with the above command, it looks like the "JEP 296" script worked as
follows:
- let's assume were at a changeset which merges all the subrepos at a
specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
every jdk8-bXX tag corresponds to a weekly version).
- sequentially transplant all the changes from a single subrepo up
until the next tag "jdk8-bXX+1" into the new repo
- do this sequentially for all the other sub-repositories
- create a merge change in the new mono-repo which merges all the
newly transplanted changes and tag it with "jdk8-bXX+1"
- verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
bit-wise equal to the sources of the jdk8u forest when every single
repo is synced to the same tag.
- repeat the procedure for all the other jdk8-bXX tags

We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
the described procedure for all the additional changes between
jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
Needless to say that the Corretto team is fully supporting the
transition of jdk8u from a Mercurial forest to a Git mono-repo and
will be happy to get involved into the process :)

Best regards,
Volker

>    JEP 296 had to relocate all the java code into modules
>    JEP 296 did not have to retain (and therefore relocate) all of the
> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
>
> I don't suppose these differences would be impossible to sort out but I
> think they would require some effort.
>
> regards,
>
>
> Andrew Dinn
> -----------
>

From attila at openjdk.java.net  Sat Feb 13 12:58:00 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 13 Feb 2021 12:58:00 GMT
Subject: [jdk16u] RFR: 8198540: Dynalink leaks memory when generating type
 converters
Message-ID: <sq9Px4tLmHwN8SehS1NgPBCE69CHpw-ga2CNVxw97NU=.bd018510-28e3-44ee-9a51-37c2c429019e@github.com>

8198540: Dynalink leaks memory when generating type converters
Reviewed-by: plevart, hannesw

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

Commit messages:
 - 8198540: Dynalink leaks memory when generating type converters

Changes: https://git.openjdk.java.net/jdk16u/pull/26/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=26&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198540
  Stats: 772 lines in 5 files changed: 538 ins; 220 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/26.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/26/head:pull/26

PR: https://git.openjdk.java.net/jdk16u/pull/26

From attila at openjdk.java.net  Sat Feb 13 14:19:47 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 13 Feb 2021 14:19:47 GMT
Subject: [jdk16u] Integrated: 8198540: Dynalink leaks memory when generating
 type converters
In-Reply-To: <sq9Px4tLmHwN8SehS1NgPBCE69CHpw-ga2CNVxw97NU=.bd018510-28e3-44ee-9a51-37c2c429019e@github.com>
References: <sq9Px4tLmHwN8SehS1NgPBCE69CHpw-ga2CNVxw97NU=.bd018510-28e3-44ee-9a51-37c2c429019e@github.com>
Message-ID: <jlVOMsWzVQscNGGBQNsoZ3VRR1jWraR35-UqXVxQWWE=.1157de74-27aa-4fc8-a40c-3e22a62bdd1f@github.com>

On Sat, 13 Feb 2021 12:51:53 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> 8198540: Dynalink leaks memory when generating type converters
> Reviewed-by: plevart, hannesw

This pull request has now been integrated.

Changeset: b6db9a50
Author:    Attila Szegedi <attila at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/b6db9a50
Stats:     772 lines in 5 files changed: 538 ins; 220 del; 14 mod

8198540: Dynalink leaks memory when generating type converters

Backport-of: 8f4c15f6417e471b372f74460fa94b9d84c4811d

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

PR: https://git.openjdk.java.net/jdk16u/pull/26

From attila at openjdk.java.net  Sat Feb 13 17:51:58 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 13 Feb 2021 17:51:58 GMT
Subject: [jdk13u-dev] RFR: 8198540: Dynalink leaks memory when generating type
 converters
Message-ID: <_Z_ZptjCVPeGWZiroRUtGHybFKT2KvHOnTQ-Y-PXG7A=.d539c7b2-6654-4922-812e-1e9a735b0db0@github.com>

I would like to backport JDK-8198540 to 13u.

The patch doesn't apply cleanly due to minor context differences, namely that [JDK-8251538](https://github.com/openjdk/jdk/commit/4b1b547020effb72ba9ef92807fec39a0db99973) is not in 13u. This was a purely code refactoring task, which among other things refactored some anonymous inner classes in `TypeConverterFactory.java` and `ClassMap.java` to lambdas. All the lines that failed to apply cleanly were deletes, so after this change these differences no longer even exist.

Additionally, 13u did not have running of tests in `test/jdk/jdk/dynalink` enabled as part of the `jdk_other` test group, so a relevant single line of [JDK-8252124](https://github.com/openjdk/jdk/commit/97f8261e4190b8edf83c1d8f11ea57f6c8338284#diff-687d4f32a29eeafbc88c0807e48388ea3e3b16dee622db0fef1473cb387f22ac) was also added to `test/jdk/TEST.groups` to enable the two tests that are part of this change to run.

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

Commit messages:
 - 8198540: Dynalink leaks memory when generating type converters

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=127&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198540
  Stats: 781 lines in 6 files changed: 539 ins; 228 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/127/head:pull/127

PR: https://git.openjdk.java.net/jdk13u-dev/pull/127

From szegedia at gmail.com  Sat Feb 13 21:57:01 2021
From: szegedia at gmail.com (Attila Szegedi)
Date: Sat, 13 Feb 2021 22:57:01 +0100
Subject: [jdk11u-dev] RFR: 8198540: Dynalink leaks memory when generating type
 converters
Message-ID: <2A5A51D0-A44E-4267-AE09-DD3FBD2C5219@gmail.com>

I would like to backport JDK-8198540 to 11u.

What follows is very similar to my earlier message today for backporting the same issue to 13u; the 13u and 11u changesets are virtually identical (except for a 4-line offset in applying the one line in TEST.groups file.)

The patch doesn't apply cleanly due to minor context differences, namely that [JDK-8251538](https://github.com/openjdk/jdk/commit/4b1b547020effb72ba9ef92807fec39a0db99973 <https://github.com/openjdk/jdk/commit/4b1b547020effb72ba9ef92807fec39a0db99973>) is not in 11u. This was a purely code refactoring task, which among other things refactored some anonymous inner classes in `TypeConverterFactory.java` and `ClassMap.java` to lambdas. All the lines that failed to apply cleanly were deletes, so after this change these differences no longer even exist.

Additionally, 11u did not have running of tests in `test/jdk/jdk/dynalink` enabled as part of the `jdk_other` test group, so a relevant single line of [JDK-8252124](https://github.com/openjdk/jdk/commit/97f8261e4190b8edf83c1d8f11ea57f6c8338284#diff-687d4f32a29eeafbc88c0807e48388ea3e3b16dee622db0fef1473cb387f22ac <https://github.com/openjdk/jdk/commit/97f8261e4190b8edf83c1d8f11ea57f6c8338284#diff-687d4f32a29eeafbc88c0807e48388ea3e3b16dee622db0fef1473cb387f22ac>) was also added to `test/jdk/TEST.groups` to enable the two tests that are part of this change to run.

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

Commit messages:
- 8198540: Dynalink leaks memory when generating type converters

Webrev: http://cr.openjdk.java.net/~attila/8198540/webrev.jdk11u-dev/index.html <https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=127&range=00>
 Issue: https://bugs.openjdk.java.net/browse/JDK-8198540 <https://bugs.openjdk.java.net/browse/JDK-8198540>


From tvoniadka at openjdk.java.net  Mon Feb 15 07:22:51 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Mon, 15 Feb 2021 07:22:51 GMT
Subject: [jdk16u] RFR: 8259628:
 jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails
 intermittently
Message-ID: <wsKMibdiNKzYBVKZ3KmNfwUF-AZtos0fGhJkWjWz5aU=.63ea8660-9f0b-465a-955a-1364a3bf5520@github.com>

This is a direct backport of

8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently

The patch applies clean, and the test passes on all platforms.

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

Commit messages:
 - Backport 13ca433ff66e202710735134e072178557114ad4

Changes: https://git.openjdk.java.net/jdk16u/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=27&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259628
  Stats: 9 lines in 1 file changed: 4 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/27/head:pull/27

PR: https://git.openjdk.java.net/jdk16u/pull/27

From tvoniadka at openjdk.java.net  Mon Feb 15 08:58:44 2021
From: tvoniadka at openjdk.java.net (Thejasvi Voniadka)
Date: Mon, 15 Feb 2021 08:58:44 GMT
Subject: [jdk16u] Integrated: 8259628:
 jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails
 intermittently
In-Reply-To: <wsKMibdiNKzYBVKZ3KmNfwUF-AZtos0fGhJkWjWz5aU=.63ea8660-9f0b-465a-955a-1364a3bf5520@github.com>
References: <wsKMibdiNKzYBVKZ3KmNfwUF-AZtos0fGhJkWjWz5aU=.63ea8660-9f0b-465a-955a-1364a3bf5520@github.com>
Message-ID: <oVGMuPWsj8Wyz1PXC77HStHOayHSRdARwQLV69c1BTY=.0bfab691-c210-4eb0-ba30-796abcab2c42@github.com>

On Mon, 15 Feb 2021 07:15:25 GMT, Thejasvi Voniadka <tvoniadka at openjdk.org> wrote:

> This is a direct backport of
> 
> 8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently
> 
> The patch applies clean, and the test passes on all platforms.

This pull request has now been integrated.

Changeset: c82a994a
Author:    Thejasvi Voniadka <tvoniadka at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/c82a994a
Stats:     9 lines in 1 file changed: 4 ins; 3 del; 2 mod

8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently

Backport-of: 13ca433ff66e202710735134e072178557114ad4

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

PR: https://git.openjdk.java.net/jdk16u/pull/27

From shade at redhat.com  Mon Feb 15 11:20:44 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 12:20:44 +0100
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
Message-ID: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>

Hi,

I have a process question about 16u (and maybe Skara).

Look here:
   JDK 17:     https://bugs.openjdk.java.net/browse/JDK-8198540
   JDK 16.0.1: https://bugs.openjdk.java.net/browse/JDK-8261691

This is backport PR:
   https://github.com/openjdk/jdk16u/pull/26

I see no mention of any of jdk16u-fix-* tags on the original issue. Is this is process bug, i.e. 
Skara allowing integration without maintainer approval? Or have I missed some announcement that 
maintainer's approval is not required for 16u anymore?

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Feb 15 11:30:24 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 12:30:24 +0100
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
Message-ID: <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>

On 2/15/21 12:20 PM, Aleksey Shipilev wrote:
> I have a process question about 16u (and maybe Skara).
> 
> Look here:
>     JDK 17:     https://bugs.openjdk.java.net/browse/JDK-8198540
>     JDK 16.0.1: https://bugs.openjdk.java.net/browse/JDK-8261691
> 
> This is backport PR:
>     https://github.com/openjdk/jdk16u/pull/26
> 
> I see no mention of any of jdk16u-fix-* tags on the original issue. Is this is process bug, i.e.
> Skara allowing integration without maintainer approval? Or have I missed some announcement that
> maintainer's approval is not required for 16u anymore?

I went through all closed JDK 16u PRs, and it looks like only 3 issues have slipped without the 
explicit 16u maintainer approval. I think this is a process bug then, and Skara bots should not 
really allow to integrate without the maintainer approval.

*) Have no jdk16u-fix-* tags at all:
   8260380: Upgrade to LittleCMS 2.12
   8198540: Dynalink leaks memory when generating type converters

*) Have jdk16u-fix-request, but NOT jdk16u-fix-yes:
   8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently

*) Have both jdk16u-fix-request AND jdk16u-fix-yes:
   8249867: xml declaration is not followed by a newline
   8260356: (tz) Upgrade time-zone data to tzdata2021a
   8260864: ProblemList two security/krb5 tests on Linux
   8256421: Add 2 HARICA roots to cacerts truststore
   8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed
   8259049: Uninitialized variable after JDK-8257513
   8257513: C2: assert((constant_addr - _masm.code()->consts()->start()) == con.offset())
   8260338: Some fields in HaltNode is not cloned
   8259777: Incorrect predication condition generated by ADLC
   8259773: Incorrect encoding of AVX-512 kmovq instruction
   8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect
   8259576: Misplaced curly brace in Matcher::find_shared_post_visit
   8260010: UTF8ZipCoder not thread-safe since JDK-8243469
   8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator
   8258946: Fix optimization-unstable code involving signed integer overflow
   8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined
   7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection
   8258909: update jdk16u jcheck conf
   8253368: TLS connection always receives close_notify exception
   8258471: "search codecache" clhsdb command does not work
   8226810: Failed to launch JVM because of NullPointerException occured on System.props
   8259048: (tz) Upgrade time-zone data to tzdata2020f


-- 
Thanks,
-Aleksey


From yan at azul.com  Mon Feb 15 12:30:12 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Mon, 15 Feb 2021 15:30:12 +0300
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
Message-ID: <5b0ca5d6-3e64-a658-653d-53c295d9b690@azul.com>

Hi Aleksey,

Skara as of now does not read these labels, and as all the discussions are mostly in PRs,
it's all too easy for everybody to ignore it.

--yan

On 15.02.2021 14:30, Aleksey Shipilev wrote:
> On 2/15/21 12:20 PM, Aleksey Shipilev wrote:
>> I have a process question about 16u (and maybe Skara).
>>
>> Look here:
>> ??? JDK 17:???? https://bugs.openjdk.java.net/browse/JDK-8198540
>> ??? JDK 16.0.1: https://bugs.openjdk.java.net/browse/JDK-8261691
>>
>> This is backport PR:
>> ??? https://github.com/openjdk/jdk16u/pull/26
>>
>> I see no mention of any of jdk16u-fix-* tags on the original issue. Is this is process bug, i.e.
>> Skara allowing integration without maintainer approval? Or have I missed some announcement that
>> maintainer's approval is not required for 16u anymore?
> 
> I went through all closed JDK 16u PRs, and it looks like only 3 issues have slipped without the
> explicit 16u maintainer approval. I think this is a process bug then, and Skara bots should not really
> allow to integrate without the maintainer approval.
> 
> *) Have no jdk16u-fix-* tags at all:
> ? 8260380: Upgrade to LittleCMS 2.12
> ? 8198540: Dynalink leaks memory when generating type converters
> 
> *) Have jdk16u-fix-request, but NOT jdk16u-fix-yes:
> ? 8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently
> 
> *) Have both jdk16u-fix-request AND jdk16u-fix-yes:
> ? 8249867: xml declaration is not followed by a newline
> ? 8260356: (tz) Upgrade time-zone data to tzdata2021a
> ? 8260864: ProblemList two security/krb5 tests on Linux
> ? 8256421: Add 2 HARICA roots to cacerts truststore
> ? 8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed
> ? 8259049: Uninitialized variable after JDK-8257513
> ? 8257513: C2: assert((constant_addr - _masm.code()->consts()->start()) == con.offset())
> ? 8260338: Some fields in HaltNode is not cloned
> ? 8259777: Incorrect predication condition generated by ADLC
> ? 8259773: Incorrect encoding of AVX-512 kmovq instruction
> ? 8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect
> ? 8259576: Misplaced curly brace in Matcher::find_shared_post_visit
> ? 8260010: UTF8ZipCoder not thread-safe since JDK-8243469
> ? 8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator
> ? 8258946: Fix optimization-unstable code involving signed integer overflow
> ? 8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined
> ? 7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection
> ? 8258909: update jdk16u jcheck conf
> ? 8253368: TLS connection always receives close_notify exception
> ? 8258471: "search codecache" clhsdb command does not work
> ? 8226810: Failed to launch JVM because of NullPointerException occured on System.props
> ? 8259048: (tz) Upgrade time-zone data to tzdata2020f
> 
> 


From szegedia at gmail.com  Mon Feb 15 13:26:32 2021
From: szegedia at gmail.com (Attila Szegedi)
Date: Mon, 15 Feb 2021 14:26:32 +0100
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
Message-ID: <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>

Ouch, that was me.

This weekend I submitted backport requests for my issue 8198540 for all of 16u, 13u, and 11u and of course, I wanted to make sure I do it right. It was a while since I last submitted a backport request, and never did it in Skara, and I didn?t want to be a burden to have people explain it all to me, so I started with picking an existing issue and meticulously checking how did they do it there, both on the PR and in Jira. And I picked the most recent integrated one in 16u, 8260380 to emulate? which is also on the shame list :-(

So that?s how I ended up with no tags and also integrated it, since that?s what I saw was done with 8260380. (I did a local build and run the tests, FWIW.)

None of this is a justification for what happened, just an explanation how I got to screw up the process. 

I profoundly apologize about it. I?ll strive to do better. I?m fine with my changes being reverted, adding the request tag, and resubmitting if that?s the reasonable way forward. Alternatively, if it gets approved after the fact, I?ll graciously accept that too while acknowledging that this isn?t the right way to go about it. I just added the 16u request tag to the issue in JBS.

FWIW, for 13u and 11u I managed to find better linked descriptions of the process (specifically, the 11u page is very detailed) and my submissions for these two have the requisite request tags and I?m waiting for approval on those.

Attila.

> On 2021. Feb 15., at 12:30, Aleksey Shipilev <shade at redhat.com> wrote:
> 
> On 2/15/21 12:20 PM, Aleksey Shipilev wrote:
>> I have a process question about 16u (and maybe Skara).
>> Look here:
>>    JDK 17:     https://bugs.openjdk.java.net/browse/JDK-8198540
>>    JDK 16.0.1: https://bugs.openjdk.java.net/browse/JDK-8261691
>> This is backport PR:
>>    https://github.com/openjdk/jdk16u/pull/26
>> I see no mention of any of jdk16u-fix-* tags on the original issue. Is this is process bug, i.e.
>> Skara allowing integration without maintainer approval? Or have I missed some announcement that
>> maintainer's approval is not required for 16u anymore?
> 
> I went through all closed JDK 16u PRs, and it looks like only 3 issues have slipped without the explicit 16u maintainer approval. I think this is a process bug then, and Skara bots should not really allow to integrate without the maintainer approval.
> 
> *) Have no jdk16u-fix-* tags at all:
>  8260380: Upgrade to LittleCMS 2.12
>  8198540: Dynalink leaks memory when generating type converters
> 
> *) Have jdk16u-fix-request, but NOT jdk16u-fix-yes:
>  8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently
> 
> *) Have both jdk16u-fix-request AND jdk16u-fix-yes:
>  8249867: xml declaration is not followed by a newline
>  8260356: (tz) Upgrade time-zone data to tzdata2021a
>  8260864: ProblemList two security/krb5 tests on Linux
>  8256421: Add 2 HARICA roots to cacerts truststore
>  8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed
>  8259049: Uninitialized variable after JDK-8257513
>  8257513: C2: assert((constant_addr - _masm.code()->consts()->start()) == con.offset())
>  8260338: Some fields in HaltNode is not cloned
>  8259777: Incorrect predication condition generated by ADLC
>  8259773: Incorrect encoding of AVX-512 kmovq instruction
>  8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect
>  8259576: Misplaced curly brace in Matcher::find_shared_post_visit
>  8260010: UTF8ZipCoder not thread-safe since JDK-8243469
>  8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator
>  8258946: Fix optimization-unstable code involving signed integer overflow
>  8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined
>  7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection
>  8258909: update jdk16u jcheck conf
>  8253368: TLS connection always receives close_notify exception
>  8258471: "search codecache" clhsdb command does not work
>  8226810: Failed to launch JVM because of NullPointerException occured on System.props
>  8259048: (tz) Upgrade time-zone data to tzdata2020f
> 
> 
> -- 
> Thanks,
> -Aleksey
> 


From shade at redhat.com  Mon Feb 15 13:32:57 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 14:32:57 +0100
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
 <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
Message-ID: <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>

Hi Attila,

On 2/15/21 2:26 PM, Attila Szegedi wrote:
> None of this is a justification for what happened, just an explanation how I got to screw up the process.

That is not your fault.

Really, that's a process bug: the bots should not have allowed to integrate without the approval. To 
me, the existence of such easy opportunity to miss the crucial step looks like a dealbreaker for 
adopting Skara for 11u and 8u projects.

> I profoundly apologize about it. I?ll strive to do better. I?m fine with my changes being
> reverted, adding the request tag, and resubmitting if that?s the reasonable way forward.
> Alternatively, if it gets approved after the fact, I?ll graciously accept that too while
> acknowledging that this isn?t the right way to go about it. I just added the 16u request tag to
> the issue in JBS.

No problem here. Retroactive approvals happen from time to time. My concern was not with the quality 
of the backport, but with the fact that 16u maintainers did not acknowledge it, while they should 
actually be in full control about what is going in.

-- 
Thanks,
-Aleksey


From goetz.lindenmaier at sap.com  Mon Feb 15 13:47:39 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 15 Feb 2021 13:47:39 +0000
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
 <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
 <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>
Message-ID: <VI1PR0202MB3454DDBCBE08EE63E964BF5DEC889@VI1PR0202MB3454.eurprd02.prod.outlook.com>

Hi Aleksey, 

> Really, that's a process bug: the bots should not have allowed to integrate
> without the approval. To
> me, the existence of such easy opportunity to miss the crucial step looks like
> a dealbreaker for
> adopting Skara for 11u and 8u projects.

As I understand, this is on purpose.  They did not want to change
the process when going from mercurial to git.  And in mercurial, 
there is also no automatic check for the tags.  We had the case
that people pushed to 11u without tags.

For me, this is a reason to go to git:  once there, and everybody 
got accommodated to the new infrastructure, we could start 
agreeing on such new, additional checks for 11u.  
I would appreciate this particular check.

Best regards,
  Goetz.



 

From denghui.ddh at alibaba-inc.com  Mon Feb 15 14:21:49 2021
From: denghui.ddh at alibaba-inc.com (Denghui Dong)
Date: Mon, 15 Feb 2021 22:21:49 +0800
Subject: =?UTF-8?B?WzExdV0gUkZSIChYUyk6IDgyNjEwMjA6IFdyb25nIGZvcm1hdCBwYXJhbWV0ZXIgaW4gY3Jl?=
 =?UTF-8?B?YXRlX2VtZXJnZW5jeV9jaHVua19wYXRo?=
Message-ID: <f8f484ff-1882-47b2-894e-20efa6c68aa5.denghui.ddh@alibaba-inc.com>

Gentle ping.

Denghui Dong


------------------------------------------------------------------
From:???(??) <denghui.ddh at alibaba-inc.com>
Send Time:2021?2?8?(???) 22:12
To:jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Subject:[11u] RFR (XS): 8261020: Wrong format parameter in create_emergency_chunk_path

Hi team,

This email was not sent successfully due to a problem with the mailing list last week, so I resend this email. Thanks to Christoph for his help:)

Could I have a review of this small fix?

In create_emergency_chunk_path, the call to jio_snprintf used a wrong format parameter "repository_path_len".

This bug was introduced in 8217362(Emergency dump does not work when disk=false is set) and fixed in 8226511(Implement JFR Event Streaming),
It is currently unacceptable to fully backport 8226511 to 11u, so I filed a new issue to fix this problem.

JBS: https://bugs.openjdk.java.net/browse/JDK-8261020
webrev: http://cr.openjdk.java.net/~ddong/8261020/webrev.00/

Thanks,
Denghui Dong


From kevin.rushforth at oracle.com  Mon Feb 15 17:32:03 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Mon, 15 Feb 2021 09:32:03 -0800
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
 <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
 <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>
Message-ID: <c5f4325e-8323-7c04-d438-cad89d42b3d5@oracle.com>

With so many different processes and subtle rules for different projects 
at different points in time, it seems unwise for Skara to start down the 
slippery slope of looking at JBS labels (and maybe bug priority and 
issuetype (bug vs RFE)?) to decide whether it is OK to integrate a 
particular bug fix to a particular repo at a particular point in time.

FWIW, calling the absence of this level of checking a "dealbreaker" 
seems like hyperbole when you don't have any such checks today in hg.

Perhaps Rob McKenna can chime in.

-- Kevin


On 2/15/2021 5:32 AM, Aleksey Shipilev wrote:
> Hi Attila,
>
> On 2/15/21 2:26 PM, Attila Szegedi wrote:
>> None of this is a justification for what happened, just an 
>> explanation how I got to screw up the process.
>
> That is not your fault.
>
> Really, that's a process bug: the bots should not have allowed to 
> integrate without the approval. To me, the existence of such easy 
> opportunity to miss the crucial step looks like a dealbreaker for 
> adopting Skara for 11u and 8u projects.
>
>> I profoundly apologize about it. I?ll strive to do better. I?m fine 
>> with my changes being
>> reverted, adding the request tag, and resubmitting if that?s the 
>> reasonable way forward.
>> Alternatively, if it gets approved after the fact, I?ll graciously 
>> accept that too while
>> acknowledging that this isn?t the right way to go about it. I just 
>> added the 16u request tag to
>> the issue in JBS.
>
> No problem here. Retroactive approvals happen from time to time. My 
> concern was not with the quality of the backport, but with the fact 
> that 16u maintainers did not acknowledge it, while they should 
> actually be in full control about what is going in.
>


From shade at redhat.com  Mon Feb 15 18:15:33 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 19:15:33 +0100
Subject: [11u] RFR (XS) 8261251: Shenandoah: Use object size for full GC
 humongous compaction
Message-ID: <62f8d040-f3b6-bf3b-2a43-564bb809cb77@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8261251
   https://git.openjdk.java.net/jdk/commit/deb0544f

The patch does not apply cleanly to 11u, because of the shenandoahMarkCompact -> shenandoahFullGC 
rename. I applied the same patch to the new file without problems.

11u variant:

diff -r a4e1ec47729f src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Thu Jan 28 09:50:21 2021 +0000
+++ b/src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Mon Feb 15 10:50:03 2021 +0100
@@ -905,7 +905,7 @@

        Copy::aligned_conjoint_words(heap->get_region(old_start)->bottom(),
                                     heap->get_region(new_start)->bottom(),
-                                   ShenandoahHeapRegion::region_size_words()*num_regions);
+                                   words_size);

        oop new_obj = oop(heap->get_region(new_start)->bottom());
        new_obj->init_mark_raw();

Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah

-- 
Thanks,
-Aleksey


From shade at openjdk.java.net  Mon Feb 15 18:19:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 18:19:45 GMT
Subject: [jdk16u] Integrated: 8261310: PPC64 Zero build fails with
 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has
 incomplete type and cannot be defined
In-Reply-To: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>
References: <tLaYQTLRuWujYSRrv7pHc2ak7XQv_gaJL8NU8edxlKk=.85021470-98b8-4fee-8e8d-70fd0a818d45@github.com>
Message-ID: <nmnz_cOJJLXePnCXT60ZVV-Lz3AvQj0coPQMruhQuWo=.0ae33633-1334-4714-8a17-11f91b960340@github.com>

On Mon, 8 Feb 2021 18:30:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Note this is **not** a backport, but 16u-specific change.
> 
> $ CONF=linux-ppc64-zero-fastdebug make hotspot
> 
> 
>  1799 | struct FunctionDescriptor functionDescriptor;
>       | ^~~~~~~~~~~~~~~~~~
> 
> `FunctionDescriptor` is from `src/hotspot/cpu/ppc/assembler_ppc.hpp`, and obviously not available for Zero.
> 
> The affected code was removed by JDK-8252148 in 17, so this issue affects versions below it.
> While not exactly the regression for 16, it would be nice to have this fixed for 16 and lower, to get clean builds on all platform configurations, including JDK 16 GA.
> 
> The fix is trivial:
> 
> diff --git a/src/hotspot/share/utilities/vmError.cpp b/src/hotspot/share/utilities/vmError.cpp
> index 9b0dc413bcd..476fdc48e43 100644
> --- a/src/hotspot/share/utilities/vmError.cpp
> +++ b/src/hotspot/share/utilities/vmError.cpp
> @@ -1795,7 +1795,7 @@ void VMError::controlled_crash(int how) {
>    char * const dataPtr = NULL; // bad data pointer
>    const void (*funcPtr)(void); // bad function pointer
>  
> -#if defined(PPC64) && !defined(ABI_ELFv2)
> +#if defined(PPC64) && !defined(ABI_ELFv2) && !defined(ZERO)
>    struct FunctionDescriptor functionDescriptor;
>  
>    functionDescriptor.set_entry((address) 0xF);
> 
> Additional testing:
>  - [x] Linux Zero PPC64 fastdebug build

This pull request has now been integrated.

Changeset: cc3417dc
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/cc3417dc
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8261310: PPC64 Zero build fails with 'VMError::controlled_crash(int)::FunctionDescriptor functionDescriptor' has incomplete type and cannot be defined

Reviewed-by: stuefe, iklam

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

PR: https://git.openjdk.java.net/jdk16u/pull/23

From shade at redhat.com  Mon Feb 15 18:41:40 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 19:41:40 +0100
Subject: [11u] RFR (S) 8260704: ParallelGC: oldgen expansion needs
 release-store for _end
Message-ID: <38523647-9a8d-7d22-ee95-6a6a2d892ca0@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8260704
   https://git.openjdk.java.net/jdk16/commit/afd5eefd

While the patch is simple, 11u does not have Atomic methods we need -- those were moved from 
OrderAccess to Atomic in JDK 14 with JDK-8234562. So, 11u patch uses OrderAccess.

11u variant:
   https://cr.openjdk.java.net/~shade/8260704/webrev.11u.02/

Testing: tier{1,2} with Parallel

-- 
Thanks,
-Aleksey


From shade at redhat.com  Mon Feb 15 18:46:13 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 19:46:13 +0100
Subject: [11u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still
 fails "assert(covered_region.contains(new_memregion)) failed: new region is
 not in covered_region"
Message-ID: <83009f52-4329-eb9b-d158-3a051584beff@redhat.com>

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8259271
   https://github.com/openjdk/jdk16/commit/685c03dc

Like with JDK-8260704 backport, we do not have Atomic methods yet, those were moved from
OrderAccess to Atomic in JDK 14 with JDK-8234562. So, 11u patch uses OrderAccess. This backport 
would land after JDK-8260704, so no additional #include is needed.

11u variant:

diff -r 48895ff9213d src/hotspot/share/gc/parallel/mutableSpace.cpp
--- a/src/hotspot/share/gc/parallel/mutableSpace.cpp    Mon Feb 15 18:17:01 2021 +0000
+++ b/src/hotspot/share/gc/parallel/mutableSpace.cpp    Mon Feb 15 19:46:06 2021 +0100
@@ -193,11 +193,15 @@
  }

  // This version is lock-free.
  HeapWord* MutableSpace::cas_allocate(size_t size) {
    do {
-    HeapWord* obj = top();
+    // Read top before end, else the range check may pass when it shouldn't.
+    // If end is read first, other threads may advance end and top such that
+    // current top > old end and current top + size > current end.  Then
+    // pointer_delta underflows, allowing installation of top > current end.
+    HeapWord* obj = OrderAccess::load_acquire(top_addr());
      if (pointer_delta(end(), obj) >= size) {
        HeapWord* new_top = obj + size;
        HeapWord* result = Atomic::cmpxchg(new_top, top_addr(), obj);
        // result can be one of two:
        //  the old top value: the exchange succeeded


Testing: tier{1,2} with Parallel

-- 
Thanks,
-Aleksey


From rob.mckenna at oracle.com  Mon Feb 15 18:52:44 2021
From: rob.mckenna at oracle.com (Robert Mckenna)
Date: Mon, 15 Feb 2021 18:52:44 +0000
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <c5f4325e-8323-7c04-d438-cad89d42b3d5@oracle.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
 <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
 <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>,
 <c5f4325e-8323-7c04-d438-cad89d42b3d5@oracle.com>
Message-ID: <8CE4D50C-D64F-451F-AFF7-0B431629C512@oracle.com>

Sorry folks, I?m actually ooto atm so I haven?t been paying as much attention as I should be. (I have a cron job that should be warning me about things like this but I hadn?t enabled it since we added branch support to a library we use, I need to get that back up and running.)

Certainly at some point deploying a check via skara bot would be helpful. It will need some discussion first however and we certainly don?t want to make changes like that for the first skara-based update.

I will contact the fix authors if there are problems with retroactive approval.

    -Rob

> On 15 Feb 2021, at 17:32, Kevin Rushforth <Kevin.Rushforth at oracle.com> wrote:
> 
> ?With so many different processes and subtle rules for different projects at different points in time, it seems unwise for Skara to start down the slippery slope of looking at JBS labels (and maybe bug priority and issuetype (bug vs RFE)?) to decide whether it is OK to integrate a particular bug fix to a particular repo at a particular point in time.
> 
> FWIW, calling the absence of this level of checking a "dealbreaker" seems like hyperbole when you don't have any such checks today in hg.
> 
> Perhaps Rob McKenna can chime in.
> 
> -- Kevin
> 
> 
>> On 2/15/2021 5:32 AM, Aleksey Shipilev wrote:
>> Hi Attila,
>> 
>>> On 2/15/21 2:26 PM, Attila Szegedi wrote:
>>> None of this is a justification for what happened, just an explanation how I got to screw up the process.
>> 
>> That is not your fault.
>> 
>> Really, that's a process bug: the bots should not have allowed to integrate without the approval. To me, the existence of such easy opportunity to miss the crucial step looks like a dealbreaker for adopting Skara for 11u and 8u projects.
>> 
>>> I profoundly apologize about it. I?ll strive to do better. I?m fine with my changes being
>>> reverted, adding the request tag, and resubmitting if that?s the reasonable way forward.
>>> Alternatively, if it gets approved after the fact, I?ll graciously accept that too while
>>> acknowledging that this isn?t the right way to go about it. I just added the 16u request tag to
>>> the issue in JBS.
>> 
>> No problem here. Retroactive approvals happen from time to time. My concern was not with the quality of the backport, but with the fact that 16u maintainers did not acknowledge it, while they should actually be in full control about what is going in.
>> 
> 

From shade at redhat.com  Mon Feb 15 18:59:07 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Mon, 15 Feb 2021 19:59:07 +0100
Subject: [11u] RFR (S) 8260497: Shenandoah: Improve SATB flushing
Message-ID: <0bcbdd56-00cd-e107-58ae-d0268ceba529@redhat.com>

Original RFE:
   https://bugs.openjdk.java.net/browse/JDK-8260497
   https://git.openjdk.java.net/jdk/commit/316d52c1

There are distinct changes from master version.

First, SATBMarkQueue and PtrQueue are still closely coupled together. Because of this, we cannot 
drop "virtual" from should_enqueue_buffer, and therefore cannot remove 
ShenandoahSATBMarkQueue::should_enqueue_buffer completely.

Second, there is no SATBMarkQueueSet::flush_queue(SATBMarkQueue&), and so we have to go to 
SATBMarkQueue::flush directly. This also simplifies ShenandoahFlushSATBHandshakeClosure.

I have observed reduced final-mark times with this patch.

11u variant:
   https://cr.openjdk.java.net/~shade/8260497/webrev.11u.01/

Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah


-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Mon Feb 15 20:03:08 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 15 Feb 2021 21:03:08 +0100
Subject: [11u] RFR (XS) 8261251: Shenandoah: Use object size for full GC
 humongous compaction
In-Reply-To: <62f8d040-f3b6-bf3b-2a43-564bb809cb77@redhat.com>
References: <62f8d040-f3b6-bf3b-2a43-564bb809cb77@redhat.com>
Message-ID: <48e62f36-1b02-2b29-99de-36543624579d@redhat.com>

Good! Thanks,
Roman

> Original bug:
>  ? https://bugs.openjdk.java.net/browse/JDK-8261251
>  ? https://git.openjdk.java.net/jdk/commit/deb0544f
> 
> The patch does not apply cleanly to 11u, because of the 
> shenandoahMarkCompact -> shenandoahFullGC rename. I applied the same 
> patch to the new file without problems.
> 
> 11u variant:
> 
> diff -r a4e1ec47729f 
> src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
> --- a/src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Thu Jan 
> 28 09:50:21 2021 +0000
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Mon Feb 
> 15 10:50:03 2021 +0100
> @@ -905,7 +905,7 @@
> 
>  ?????? Copy::aligned_conjoint_words(heap->get_region(old_start)->bottom(),
>  ??????????????????????????????????? heap->get_region(new_start)->bottom(),
> -                                   
> ShenandoahHeapRegion::region_size_words()*num_regions);
> +?????????????????????????????????? words_size);
> 
>  ?????? oop new_obj = oop(heap->get_region(new_start)->bottom());
>  ?????? new_obj->init_mark_raw();
> 
> Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah
> 


From rkennke at redhat.com  Mon Feb 15 20:04:39 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Mon, 15 Feb 2021 21:04:39 +0100
Subject: [11u] RFR (S) 8260497: Shenandoah: Improve SATB flushing
In-Reply-To: <0bcbdd56-00cd-e107-58ae-d0268ceba529@redhat.com>
References: <0bcbdd56-00cd-e107-58ae-d0268ceba529@redhat.com>
Message-ID: <9d0ddff1-b4c5-4948-e864-ada6e23cd3c8@redhat.com>

Looks good, thank you!

Roman


> Original RFE:
>  ? https://bugs.openjdk.java.net/browse/JDK-8260497
>  ? https://git.openjdk.java.net/jdk/commit/316d52c1
> 
> There are distinct changes from master version.
> 
> First, SATBMarkQueue and PtrQueue are still closely coupled together. 
> Because of this, we cannot drop "virtual" from should_enqueue_buffer, 
> and therefore cannot remove 
> ShenandoahSATBMarkQueue::should_enqueue_buffer completely.
> 
> Second, there is no SATBMarkQueueSet::flush_queue(SATBMarkQueue&), and 
> so we have to go to SATBMarkQueue::flush directly. This also simplifies 
> ShenandoahFlushSATBHandshakeClosure.
> 
> I have observed reduced final-mark times with this patch.
> 
> 11u variant:
>  ? https://cr.openjdk.java.net/~shade/8260497/webrev.11u.01/
> 
> Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah
> 
> 


From christoph.langer at sap.com  Mon Feb 15 22:54:56 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 15 Feb 2021 22:54:56 +0000
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <8CE4D50C-D64F-451F-AFF7-0B431629C512@oracle.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
 <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
 <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>,
 <c5f4325e-8323-7c04-d438-cad89d42b3d5@oracle.com>
 <8CE4D50C-D64F-451F-AFF7-0B431629C512@oracle.com>
Message-ID: <AM4PR02MB3138620979B8A0C8BB0211058A889@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

I personally  think that maintainer approvals, checked by "the system" would be a desirable feature for the future.

It doesn't necessarily have to be reading labels from JBS - it could also be entering an approval command in a PR or the like. (Similar to /sponsor for people who aren't committer in a project). This can be discussed in more detail once we get there.

But for the moment I agree to focus on moving the processes to GitHub/Skara and make sure we fix bugs and get things smooth without transforming the process beyond the minimum that's necessary to adopt Skara. So the jdk*u-fix protocol is what should be followed for the time being.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Robert Mckenna
> Sent: Montag, 15. Februar 2021 19:53
> To: Kevin Rushforth <kevin.rushforth at oracle.com>
> Cc: Aleksey Shipilev <shade at redhat.com>; Attila Szegedi
> <szegedia at gmail.com>; jdk-updates-dev at openjdk.java.net
> Subject: Re: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
> 
> Sorry folks, I?m actually ooto atm so I haven?t been paying as much attention
> as I should be. (I have a cron job that should be warning me about things like
> this but I hadn?t enabled it since we added branch support to a library we
> use, I need to get that back up and running.)
> 
> Certainly at some point deploying a check via skara bot would be helpful. It
> will need some discussion first however and we certainly don?t want to make
> changes like that for the first skara-based update.
> 
> I will contact the fix authors if there are problems with retroactive approval.
> 
>     -Rob
> 
> > On 15 Feb 2021, at 17:32, Kevin Rushforth <Kevin.Rushforth at oracle.com>
> wrote:
> >
> > ?With so many different processes and subtle rules for different projects at
> different points in time, it seems unwise for Skara to start down the slippery
> slope of looking at JBS labels (and maybe bug priority and issuetype (bug vs
> RFE)?) to decide whether it is OK to integrate a particular bug fix to a
> particular repo at a particular point in time.
> >
> > FWIW, calling the absence of this level of checking a "dealbreaker" seems
> like hyperbole when you don't have any such checks today in hg.
> >
> > Perhaps Rob McKenna can chime in.
> >
> > -- Kevin
> >
> >
> >> On 2/15/2021 5:32 AM, Aleksey Shipilev wrote:
> >> Hi Attila,
> >>
> >>> On 2/15/21 2:26 PM, Attila Szegedi wrote:
> >>> None of this is a justification for what happened, just an explanation
> how I got to screw up the process.
> >>
> >> That is not your fault.
> >>
> >> Really, that's a process bug: the bots should not have allowed to integrate
> without the approval. To me, the existence of such easy opportunity to miss
> the crucial step looks like a dealbreaker for adopting Skara for 11u and 8u
> projects.
> >>
> >>> I profoundly apologize about it. I?ll strive to do better. I?m fine with my
> changes being
> >>> reverted, adding the request tag, and resubmitting if that?s the
> reasonable way forward.
> >>> Alternatively, if it gets approved after the fact, I?ll graciously accept that
> too while
> >>> acknowledging that this isn?t the right way to go about it. I just added the
> 16u request tag to
> >>> the issue in JBS.
> >>
> >> No problem here. Retroactive approvals happen from time to time. My
> concern was not with the quality of the backport, but with the fact that 16u
> maintainers did not acknowledge it, while they should actually be in full
> control about what is going in.
> >>
> >

From hohensee at amazon.com  Tue Feb 16 01:12:46 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 16 Feb 2021 01:12:46 +0000
Subject: ReE: [11u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still
 fails "assert(covered_region.contains(new_memregion)) failed: new
 region is not in covered_region"
Message-ID: <C9AA569F-EE5F-4151-B9BA-42FF3CA8F1A3@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, February 15, 2021 at 10:47 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: [11u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8259271
   https://github.com/openjdk/jdk16/commit/685c03dc

Like with JDK-8260704 backport, we do not have Atomic methods yet, those were moved from
OrderAccess to Atomic in JDK 14 with JDK-8234562. So, 11u patch uses OrderAccess. This backport
would land after JDK-8260704, so no additional #include is needed.

11u variant:

diff -r 48895ff9213d src/hotspot/share/gc/parallel/mutableSpace.cpp
--- a/src/hotspot/share/gc/parallel/mutableSpace.cpp    Mon Feb 15 18:17:01 2021 +0000
+++ b/src/hotspot/share/gc/parallel/mutableSpace.cpp    Mon Feb 15 19:46:06 2021 +0100
@@ -193,11 +193,15 @@
  }

  // This version is lock-free.
  HeapWord* MutableSpace::cas_allocate(size_t size) {
    do {
-    HeapWord* obj = top();
+    // Read top before end, else the range check may pass when it shouldn't.
+    // If end is read first, other threads may advance end and top such that
+    // current top > old end and current top + size > current end.  Then
+    // pointer_delta underflows, allowing installation of top > current end.
+    HeapWord* obj = OrderAccess::load_acquire(top_addr());
      if (pointer_delta(end(), obj) >= size) {
        HeapWord* new_top = obj + size;
        HeapWord* result = Atomic::cmpxchg(new_top, top_addr(), obj);
        // result can be one of two:
        //  the old top value: the exchange succeeded


Testing: tier{1,2} with Parallel

--
Thanks,
-Aleksey



From hohensee at amazon.com  Tue Feb 16 01:12:42 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 16 Feb 2021 01:12:42 +0000
Subject: [11u] RFR (S) 8260704: ParallelGC: oldgen expansion needs
 release-store for _end
Message-ID: <C554D488-EEDC-407B-87E6-EC1A53C1C44D@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
Date: Monday, February 15, 2021 at 10:42 AM
To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
Subject: [11u] RFR (S) 8260704: ParallelGC: oldgen expansion needs release-store for _end

Original bug:
   https://bugs.openjdk.java.net/browse/JDK-8260704
   https://git.openjdk.java.net/jdk16/commit/afd5eefd

While the patch is simple, 11u does not have Atomic methods we need -- those were moved from
OrderAccess to Atomic in JDK 14 with JDK-8234562. So, 11u patch uses OrderAccess.

11u variant:
   https://cr.openjdk.java.net/~shade/8260704/webrev.11u.02/

Testing: tier{1,2} with Parallel

--
Thanks,
-Aleksey



From shade at redhat.com  Tue Feb 16 07:35:41 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 08:35:41 +0100
Subject: [11u] RFR (S) 8260704: ParallelGC: oldgen expansion needs
 release-store for _end
In-Reply-To: <C554D488-EEDC-407B-87E6-EC1A53C1C44D@amazon.com>
References: <C554D488-EEDC-407B-87E6-EC1A53C1C44D@amazon.com>
Message-ID: <79c98f92-8569-99c7-c4cf-2c71dfdf2dc8@redhat.com>

Thanks, tagged.

On 2/16/21 2:12 AM, Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
> Date: Monday, February 15, 2021 at 10:42 AM
> To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Subject: [11u] RFR (S) 8260704: ParallelGC: oldgen expansion needs release-store for _end
> 
> Original bug:
>     https://bugs.openjdk.java.net/browse/JDK-8260704
>     https://git.openjdk.java.net/jdk16/commit/afd5eefd
> 
> While the patch is simple, 11u does not have Atomic methods we need -- those were moved from
> OrderAccess to Atomic in JDK 14 with JDK-8234562. So, 11u patch uses OrderAccess.
> 
> 11u variant:
>     https://cr.openjdk.java.net/~shade/8260704/webrev.11u.02/
> 
> Testing: tier{1,2} with Parallel
> 
> --
> Thanks,
> -Aleksey
> 
> 


-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Feb 16 07:35:48 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 08:35:48 +0100
Subject: ReE: [11u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java
 still fails "assert(covered_region.contains(new_memregion)) failed: new
 region is not in covered_region"
In-Reply-To: <C9AA569F-EE5F-4151-B9BA-42FF3CA8F1A3@amazon.com>
References: <C9AA569F-EE5F-4151-B9BA-42FF3CA8F1A3@amazon.com>
Message-ID: <88081764-4c4b-a090-e0aa-875071d62452@redhat.com>

Thanks, tagged.

On 2/16/21 2:12 AM, Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Aleksey Shipilev <shade at redhat.com>
> Date: Monday, February 15, 2021 at 10:47 AM
> To: "jdk-updates-dev at openjdk.java.net" <jdk-updates-dev at openjdk.java.net>
> Subject: [11u] RFR (XS) 8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"
> 
> Original bug:
>     https://bugs.openjdk.java.net/browse/JDK-8259271
>     https://github.com/openjdk/jdk16/commit/685c03dc
> 
> Like with JDK-8260704 backport, we do not have Atomic methods yet, those were moved from
> OrderAccess to Atomic in JDK 14 with JDK-8234562. So, 11u patch uses OrderAccess. This backport
> would land after JDK-8260704, so no additional #include is needed.
> 
> 11u variant:
> 
> diff -r 48895ff9213d src/hotspot/share/gc/parallel/mutableSpace.cpp
> --- a/src/hotspot/share/gc/parallel/mutableSpace.cpp    Mon Feb 15 18:17:01 2021 +0000
> +++ b/src/hotspot/share/gc/parallel/mutableSpace.cpp    Mon Feb 15 19:46:06 2021 +0100
> @@ -193,11 +193,15 @@
>    }
> 
>    // This version is lock-free.
>    HeapWord* MutableSpace::cas_allocate(size_t size) {
>      do {
> -    HeapWord* obj = top();
> +    // Read top before end, else the range check may pass when it shouldn't.
> +    // If end is read first, other threads may advance end and top such that
> +    // current top > old end and current top + size > current end.  Then
> +    // pointer_delta underflows, allowing installation of top > current end.
> +    HeapWord* obj = OrderAccess::load_acquire(top_addr());
>        if (pointer_delta(end(), obj) >= size) {
>          HeapWord* new_top = obj + size;
>          HeapWord* result = Atomic::cmpxchg(new_top, top_addr(), obj);
>          // result can be one of two:
>          //  the old top value: the exchange succeeded
> 
> 
> Testing: tier{1,2} with Parallel
> 
> --
> Thanks,
> -Aleksey
> 
> 


-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Feb 16 07:36:07 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 08:36:07 +0100
Subject: [11u] RFR (S) 8260497: Shenandoah: Improve SATB flushing
In-Reply-To: <9d0ddff1-b4c5-4948-e864-ada6e23cd3c8@redhat.com>
References: <0bcbdd56-00cd-e107-58ae-d0268ceba529@redhat.com>
 <9d0ddff1-b4c5-4948-e864-ada6e23cd3c8@redhat.com>
Message-ID: <a40b5773-386e-fbff-9d68-0b7bc4ef1bf3@redhat.com>

Thanks, tagged.

On 2/15/21 9:04 PM, Roman Kennke wrote:
> Looks good, thank you!
> 
> Roman
> 
> 
>> Original RFE:
>>   ? https://bugs.openjdk.java.net/browse/JDK-8260497
>>   ? https://git.openjdk.java.net/jdk/commit/316d52c1
>>
>> There are distinct changes from master version.
>>
>> First, SATBMarkQueue and PtrQueue are still closely coupled together.
>> Because of this, we cannot drop "virtual" from should_enqueue_buffer,
>> and therefore cannot remove
>> ShenandoahSATBMarkQueue::should_enqueue_buffer completely.
>>
>> Second, there is no SATBMarkQueueSet::flush_queue(SATBMarkQueue&), and
>> so we have to go to SATBMarkQueue::flush directly. This also simplifies
>> ShenandoahFlushSATBHandshakeClosure.
>>
>> I have observed reduced final-mark times with this patch.
>>
>> 11u variant:
>>   ? https://cr.openjdk.java.net/~shade/8260497/webrev.11u.01/
>>
>> Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah
>>
>>
> 


-- 
Thanks,
-Aleksey


From shade at redhat.com  Tue Feb 16 07:36:17 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 16 Feb 2021 08:36:17 +0100
Subject: [11u] RFR (XS) 8261251: Shenandoah: Use object size for full GC
 humongous compaction
In-Reply-To: <48e62f36-1b02-2b29-99de-36543624579d@redhat.com>
References: <62f8d040-f3b6-bf3b-2a43-564bb809cb77@redhat.com>
 <48e62f36-1b02-2b29-99de-36543624579d@redhat.com>
Message-ID: <2635b2ec-0dd5-7ea6-82d0-55b06edcdcd8@redhat.com>

Thanks, tagged.

On 2/15/21 9:03 PM, Roman Kennke wrote:
> Good! Thanks,
> Roman
> 
>> Original bug:
>>   ? https://bugs.openjdk.java.net/browse/JDK-8261251
>>   ? https://git.openjdk.java.net/jdk/commit/deb0544f
>>
>> The patch does not apply cleanly to 11u, because of the
>> shenandoahMarkCompact -> shenandoahFullGC rename. I applied the same
>> patch to the new file without problems.
>>
>> 11u variant:
>>
>> diff -r a4e1ec47729f
>> src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Thu Jan
>> 28 09:50:21 2021 +0000
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp Mon Feb
>> 15 10:50:03 2021 +0100
>> @@ -905,7 +905,7 @@
>>
>>   ?????? Copy::aligned_conjoint_words(heap->get_region(old_start)->bottom(),
>>   ??????????????????????????????????? heap->get_region(new_start)->bottom(),
>> -
>> ShenandoahHeapRegion::region_size_words()*num_regions);
>> +?????????????????????????????????? words_size);
>>
>>   ?????? oop new_obj = oop(heap->get_region(new_start)->bottom());
>>   ?????? new_obj->init_mark_raw();
>>
>> Testing: hotspot_gc_shenandoah; tier{1,2} with Shenandoah
>>
> 


-- 
Thanks,
-Aleksey


From dmarkov at openjdk.java.net  Tue Feb 16 11:35:06 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 16 Feb 2021 11:35:06 GMT
Subject: [jdk16u] Integrated: 8261231: Windows IME was disabled after DnD
 operation
Message-ID: <CoQWVj-1dI2ftvtFjuROMN_rNADNCtwDFYV2cr_LPO0=.1907921f-5e7f-402b-8cfb-a55d378d3b5d@github.com>

8261231: Windows IME was disabled after DnD operation

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

Commit messages:
 - 8261231: Windows IME was disabled after DnD operation

Changes: https://git.openjdk.java.net/jdk16u/pull/28/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=28&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261231
  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/28/head:pull/28

PR: https://git.openjdk.java.net/jdk16u/pull/28

From dmarkov at openjdk.java.net  Tue Feb 16 11:35:07 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Tue, 16 Feb 2021 11:35:07 GMT
Subject: [jdk16u] Integrated: 8261231: Windows IME was disabled after DnD
 operation
In-Reply-To: <CoQWVj-1dI2ftvtFjuROMN_rNADNCtwDFYV2cr_LPO0=.1907921f-5e7f-402b-8cfb-a55d378d3b5d@github.com>
References: <CoQWVj-1dI2ftvtFjuROMN_rNADNCtwDFYV2cr_LPO0=.1907921f-5e7f-402b-8cfb-a55d378d3b5d@github.com>
Message-ID: <VYCGLfbgaMpntO43ip0AbBCR_Eyl2K9eFmM4bgzedqw=.3c349ed7-2dcd-448c-92d2-d924f0614b5f@github.com>

On Tue, 16 Feb 2021 10:32:55 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> 8261231: Windows IME was disabled after DnD operation

This pull request has now been integrated.

Changeset: ac08d3f0
Author:    Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/ac08d3f0
Stats:     5 lines in 1 file changed: 3 ins; 1 del; 1 mod

8261231: Windows IME was disabled after DnD operation

Backport-of: d6d5d9bf2f1a3343af6cf30a9d06a1f1b5f764ad

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

PR: https://git.openjdk.java.net/jdk16u/pull/28

From sean.coffey at oracle.com  Tue Feb 16 14:59:25 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 16 Feb 2021 14:59:25 +0000
Subject: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
In-Reply-To: <AM4PR02MB3138620979B8A0C8BB0211058A889@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <ef4baf4b-c64e-38f3-6b67-605c739271c4@redhat.com>
 <526f9826-a7b2-2b36-0131-fb263f45e5d0@redhat.com>
 <788823F9-149D-49CE-AD2C-A257B66E4653@gmail.com>
 <40e9f4fc-8b58-ba02-d28d-6631162ae575@redhat.com>
 <c5f4325e-8323-7c04-d438-cad89d42b3d5@oracle.com>
 <8CE4D50C-D64F-451F-AFF7-0B431629C512@oracle.com>
 <AM4PR02MB3138620979B8A0C8BB0211058A889@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <0c33c25e-a5c4-2e20-5041-bddf167d4dac@oracle.com>

With or without Skara, any contributor to the JDK Updates Project should 
be aware of the basic processes associated with the Project. The process 
for pushing code is documented at 
https://openjdk.java.net/projects/jdk-updates/approval.html - If it's 
not clear, it can be corrected on that end also.

regards,
Sean.

On 15/02/2021 22:54, Langer, Christoph wrote:
> Hi,
>
> I personally  think that maintainer approvals, checked by "the system" would be a desirable feature for the future.
>
> It doesn't necessarily have to be reading labels from JBS - it could also be entering an approval command in a PR or the like. (Similar to /sponsor for people who aren't committer in a project). This can be discussed in more detail once we get there.
>
> But for the moment I agree to focus on moving the processes to GitHub/Skara and make sure we fix bugs and get things smooth without transforming the process beyond the minimum that's necessary to adopt Skara. So the jdk*u-fix protocol is what should be followed for the time being.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
>> Behalf Of Robert Mckenna
>> Sent: Montag, 15. Februar 2021 19:53
>> To: Kevin Rushforth <kevin.rushforth at oracle.com>
>> Cc: Aleksey Shipilev <shade at redhat.com>; Attila Szegedi
>> <szegedia at gmail.com>; jdk-updates-dev at openjdk.java.net
>> Subject: Re: [jdk16u] Are we ignoring jdk16u-fix-* protocol?
>>
>> Sorry folks, I?m actually ooto atm so I haven?t been paying as much attention
>> as I should be. (I have a cron job that should be warning me about things like
>> this but I hadn?t enabled it since we added branch support to a library we
>> use, I need to get that back up and running.)
>>
>> Certainly at some point deploying a check via skara bot would be helpful. It
>> will need some discussion first however and we certainly don?t want to make
>> changes like that for the first skara-based update.
>>
>> I will contact the fix authors if there are problems with retroactive approval.
>>
>>      -Rob
>>
>>> On 15 Feb 2021, at 17:32, Kevin Rushforth <Kevin.Rushforth at oracle.com>
>> wrote:
>>> ?With so many different processes and subtle rules for different projects at
>> different points in time, it seems unwise for Skara to start down the slippery
>> slope of looking at JBS labels (and maybe bug priority and issuetype (bug vs
>> RFE)?) to decide whether it is OK to integrate a particular bug fix to a
>> particular repo at a particular point in time.
>>> FWIW, calling the absence of this level of checking a "dealbreaker" seems
>> like hyperbole when you don't have any such checks today in hg.
>>> Perhaps Rob McKenna can chime in.
>>>
>>> -- Kevin
>>>
>>>
>>>> On 2/15/2021 5:32 AM, Aleksey Shipilev wrote:
>>>> Hi Attila,
>>>>
>>>>> On 2/15/21 2:26 PM, Attila Szegedi wrote:
>>>>> None of this is a justification for what happened, just an explanation
>> how I got to screw up the process.
>>>> That is not your fault.
>>>>
>>>> Really, that's a process bug: the bots should not have allowed to integrate
>> without the approval. To me, the existence of such easy opportunity to miss
>> the crucial step looks like a dealbreaker for adopting Skara for 11u and 8u
>> projects.
>>>>> I profoundly apologize about it. I?ll strive to do better. I?m fine with my
>> changes being
>>>>> reverted, adding the request tag, and resubmitting if that?s the
>> reasonable way forward.
>>>>> Alternatively, if it gets approved after the fact, I?ll graciously accept that
>> too while
>>>>> acknowledging that this isn?t the right way to go about it. I just added the
>> 16u request tag to
>>>>> the issue in JBS.
>>>> No problem here. Retroactive approvals happen from time to time. My
>> concern was not with the quality of the backport, but with the fact that 16u
>> maintainers did not acknowledge it, while they should actually be in full
>> control about what is going in.

From christoph.langer at sap.com  Tue Feb 16 16:25:00 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 16 Feb 2021 16:25:00 +0000
Subject: RFR 8258945: test/jdk/tools/jlink/JLinkReproducibleTest.java
 fails randomly when cds is disabled
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE3046B6227@dggeml533-mbs.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE3046AC833@dggeml533-mbs.china.huawei.com>
 <AM4PR02MB3138CB562899BECFC74C3B158AA80@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <8FC616E5EC1A774287430B1CC2696FE3046B6227@dggeml533-mbs.china.huawei.com>
Message-ID: <AM4PR02MB31384B28C38A36DC3C92FB848A879@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi hedongbo,

I went again through this topic and I don't see any other fix at the moment than to exclude this test in 11u. It would need JEP 341 to be backported which is probably out of scope.

I'll file an exclusion.

Best regards
Christoph

> -----Original Message-----
> From: hedongbo <hedongbo at huawei.com>
> Sent: Dienstag, 19. Januar 2021 08:04
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: RE: RFR 8258945: test/jdk/tools/jlink/JLinkReproducibleTest.java
> fails randomly when cds is disabled
> 
> Thanks Christoph!
> 
> Glad to hear the news and look forward to you can post a PR ASAP.
> 
> 
> Thanks,
> dongbohe
> 
> -----Original Message-----
> From: Langer, Christoph [mailto:christoph.langer at sap.com]
> Sent: Friday, January 15, 2021 1:15 AM
> To: hedongbo <hedongbo at huawei.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: RFR 8258945: test/jdk/tools/jlink/JLinkReproducibleTest.java
> fails randomly when cds is disabled
> 
> Hi dongbohe,
> 
> we also see this issue in our nightly testing and are interested in fixing this.
> 
> However, backporting https://bugs.openjdk.java.net/browse/JDK-8202951
> doesn't seem appropriate for backporting to 11u to me. Don't know if other
> people would have a different opinion - if so, please chime in.
> 
> We should find a different solution, maybe we can exclude the test from
> running when CDS is disabled by some jtreg directive?
> 
> Thanks
> Christoph
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of hedongbo
> > Sent: Donnerstag, 14. Januar 2021 02:54
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: RFR 8258945: test/jdk/tools/jlink/JLinkReproducibleTest.java
> > fails randomly when cds is disabled
> >
> > Hi,
> > Can someone help me look at this problem?
> >
> > BugID: http://bugs.openjdk.java.net/browse/JDK-8258945
> >
> > As analyzed in JDK-8258945, this is caused by the fact that the object
> > hashcode of enum may be different in different JVMs. It is not a good
> > idea to modify the calculation of the hashcode of the
> > ModuleDescriptor, and it is also difficult.  Therefore, I think we can
> > backport JDK-
> > 8202951<https://bugs.openjdk.java.net/browse/JDK-8202951> to jdk11 to
> workarounds.
> >
> > Any suggestions? If backport is needed, I will start this work.
> >
> >
> >
> > Thanks,
> > dongbohe

From erik.joelsson at oracle.com  Tue Feb 16 19:30:41 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 16 Feb 2021 11:30:41 -0800
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
Message-ID: <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>

Hello,

As you may have seen, Erik Duveblad just posted about our prototype 
conversions on skara-dev [1]. These are based on the same kind of 
forest->mono repo conversion, followed by hg->git conversion that 
mainline went through.

I have been working for a while now on adapting the scripts from JEP 296 
to work for the old update releases. This has required more work than I 
first anticipated as the problem now requires a more generalized 
solution, but I believe I now have something that works reasonably well. 
If you are curious on the details, please continue reading.

Volker's description of the processes is pretty accurate on a high 
level. The main difference in 8u compared to a main release is that the 
tags are not sequential in history. This means that we can't transplant 
(or splice as it's called in Mercurial terms) changes as freely on top 
of each tagged change. In the original JDK 10 consolidation, we had a 
handful of changes that weren't linear (around the transition between 
JDK 9 and 10), and I handled them differently (basically just merging 
them together to recreate the point in history, but not splicing 
anything on top afterwards). Since they were only a handful, I could 
just list them out explicitly in the script. For 8u, a majority of the 
tags are non linear, so a big problem was creating an algorithm that 
would automatically figure out a reasonable line of tags in sequence 
that I could use to splice changes on top of.

Another big problem is that there are often tags merged together in 
different order in different repos. When this happens, the script needs 
to figure out the best order to do the conversion. I have tried to 
automate this process as much as possible. The ordering is sensitive 
when some of the tags are used to splice changes on top of them. There 
are also cases of tags missing completely.

In the end, the state of the mono repo at each tag is verified to be 
exactly the same as the forest of repos at each tag. The state of 
changes between tags is however less predictable in 8u compared to 
mainline due to the large amount of non linear tags.

For the extra curious, here is what the current algorithm for choosing 
the "splice tags" looks like:

1. Start with the first tag

2. Continue with each consecutive build for current release until a gap 
in build numbers is detected (we typically have update release builds 
 >b30 that probably aren't that interesting)

3. Find the next release in order and then find the first tag in that 
release that is also a descendant of the previous splice tag in every repo.

4. Repeat from 2 until all tags have been considered.

/Erik

[1] 
https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html

On 2021-02-12 13:33, Volker Simonis wrote:
> On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
>> On 12/02/2021 16:37, Severin Gehwolf wrote:
>>> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
>>> more thought than 11u.
>> That's what I was thinking.
>>
>>> My preference would be to do it in steps:
>>> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
>>> 2.) HG -> git conversion using Skara tooling (should take care of
>>>       proper metadata, etc.)
>> Yes, I think this is the right way to go about it. If nothing else
>> because the tools for the second step assumed that the first one had
>> happened.
>>
>> The really tricky differences I see happen at step 1 (although they
>> might have a knock-on effect at step 2)
>>
> I think converting 8u to a Git mono-repo might not be as complicated
> and risky as it seems. We have to remember that most of the work has
> already been done by JEP 296 in jdk10. That process already converted
> all the old history and as nobody seems to have been complaining about
> it in jdk10 and later, that conversion must have been fine. I.e. The
> jdk 10 repository naturally contains the sources of jdk8 from which is
> was initially forked (I think at jdk8-b120).
>
> So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:
>
> hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120
>
> This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
> we only have to use the JEP 296 scripts or something equivalent (I
> hope that the Oracle build group can assist or at least give some good
> advice here :)
>
>  From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
> with the above command, it looks like the "JEP 296" script worked as
> follows:
> - let's assume were at a changeset which merges all the subrepos at a
> specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
> every jdk8-bXX tag corresponds to a weekly version).
> - sequentially transplant all the changes from a single subrepo up
> until the next tag "jdk8-bXX+1" into the new repo
> - do this sequentially for all the other sub-repositories
> - create a merge change in the new mono-repo which merges all the
> newly transplanted changes and tag it with "jdk8-bXX+1"
> - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
> bit-wise equal to the sources of the jdk8u forest when every single
> repo is synced to the same tag.
> - repeat the procedure for all the other jdk8-bXX tags
>
> We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
> the described procedure for all the additional changes between
> jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
> Needless to say that the Corretto team is fully supporting the
> transition of jdk8u from a Mercurial forest to a Git mono-repo and
> will be happy to get involved into the process :)
>
> Best regards,
> Volker
>
>>     JEP 296 had to relocate all the java code into modules
>>     JEP 296 did not have to retain (and therefore relocate) all of the
>> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
>>
>> I don't suppose these differences would be impossible to sort out but I
>> think they would require some effort.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>

From rkennke at redhat.com  Tue Feb 16 20:26:48 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Tue, 16 Feb 2021 21:26:48 +0100
Subject: RFR(11u): 8257621: JFR StringPool misses cached items across
 consecutive recordings
Message-ID: <d8e9deb8-7f13-e52b-56e5-48dce4e4f1a0@redhat.com>

Can I please get a review of the following backport:

Original issue:
https://bugs.openjdk.java.net/browse/JDK-8257621

The original fix:
https://github.com/openjdk/jdk16/commit/7aac4dc1

JDK11u webrev:
http://cr.openjdk.java.net/~rkennke/JDK-8257621-jdk11/webrev.00/

None of the code that has been changed to use jfrSignal in jdk16 seems 
to exist in jdk11, so I left those parts out. I am not totally sure if 
JfrStringPool::add() is correct.

I successfully ran JFR tests, including TestReEnableName.java.

Thanks,
Roman


From yan at azul.com  Wed Feb 17 07:05:25 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Wed, 17 Feb 2021 10:05:25 +0300
Subject: Result: New OpenJDK Updates Committer: Ekaterina Vergizova
In-Reply-To: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
References: <c6b5e225-8978-388a-56da-7784f61b21c8@azul.com>
Message-ID: <f3ce9413-4e98-8d48-1547-61826656a1b6@azul.com>

Voting for Ekaterina Vergizova (evergizova) [0] is now closed.

Yes: 8
Veto: 0
Abstain: 0


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

Thank you!
--yan

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004832.html
[1] http://openjdk.java.net/bylaws#three-vote-consensus


From thomas.stuefe at gmail.com  Wed Feb 17 07:43:33 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 17 Feb 2021 08:43:33 +0100
Subject: How speedy are patches to be downported to 11?
Message-ID: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>

Hi,

what is the general policy of downporting changes from 17 to 11? I see
sometimes changes downported rather quickly which could have done with a
little more baking time. Especially since 17 is not even released yet.

Are there guidelines to follow? I did not find anything in the Wiki. Eg
minimum time to let a patch stew in the head release?

Related to that, how are possible compatibility issues to be handled? Eg. a
patch fixing the output of a command may be correct but may still throw off
parsers.

I suspect the answer will be "its up to you", and depends
on patch complexity and bug severity. But I still am curious how you handle
this in practice.

Thanks!

Thomas

From shade at redhat.com  Wed Feb 17 08:19:59 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 17 Feb 2021 09:19:59 +0100
Subject: How speedy are patches to be downported to 11?
In-Reply-To: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
References: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
Message-ID: <06f9d923-ecaa-42fe-3f40-b195b36cec95@redhat.com>

On 2/17/21 8:43 AM, Thomas St?fe wrote:
> Related to that, how are possible compatibility issues to be handled? Eg. a
> patch fixing the output of a command may be correct but may still throw off
> parsers.

Judgement call. We generally try to avoid introducing non-bug differences in update releases. But 
that is not a firm rule, AFAIU.

> I suspect the answer will be "its up to you", and depends
> on patch complexity and bug severity. But I still am curious how you handle
> this in practice.

My personal guideline is like this:
  - obvious build fixes are proposed right away (because they unbreak stuff);
  - testbug fixes are proposed right away (because they do not affect product quality);
  - simple fixes are proposed after a few nightly cycles (the follow-up bugs are usually filed 
within days from the initial integration into master);
  - complex fixes are proposed after at least 10 days (same reason, but give more time to catch bugs)
  - very complex fixes are proposed after about a month of stewing, and then only in the initial 
months of the update release (and they generally try to match the Oracle's version)

jdk-backports-monitor, for example, has the automatic cooldown set for 10 days:
   https://builds.shipilev.net/backports-monitor/label-actionable-redhat-interest.txt

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

JDK-8260934: java/lang/StringBuilder/HugeCapacity.java fails without Compact Strings

   Original Bug:
       URL: https://bugs.openjdk.java.net/browse/JDK-8260934
       Reporter: Aleksey Shipilev
       Assignee: Aleksey Shipilev
       Priority: P4
       Components: core-libs/java.lang

   Original Fix:
          17: JDK-8260934, https://git.openjdk.java.net/jdk/commit/ad54d8dd, shade, 7 day(s) ago

   Backports and Forwardports:
          16: WAITING for patch to bake a little: 3 days more
          11: WAITING for patch to bake a little: 3 days more
           8: Not affected

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

-- 
Thanks,
-Aleksey


From thomas.stuefe at gmail.com  Wed Feb 17 08:52:20 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 17 Feb 2021 09:52:20 +0100
Subject: How speedy are patches to be downported to 11?
In-Reply-To: <06f9d923-ecaa-42fe-3f40-b195b36cec95@redhat.com>
References: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
 <06f9d923-ecaa-42fe-3f40-b195b36cec95@redhat.com>
Message-ID: <CAA-vtUw0nGtVSq+EcwjeBSenJA__0Tmx0NaHurB+QDK=ba63Tw@mail.gmail.com>

Thank you Aleksey, this sounds quite reasonable.

On Wed, Feb 17, 2021 at 9:20 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 2/17/21 8:43 AM, Thomas St?fe wrote:
> > Related to that, how are possible compatibility issues to be handled?
> Eg. a
> > patch fixing the output of a command may be correct but may still throw
> off
> > parsers.
>
> Judgement call. We generally try to avoid introducing non-bug differences
> in update releases. But
> that is not a firm rule, AFAIU.
>
> > I suspect the answer will be "its up to you", and depends
> > on patch complexity and bug severity. But I still am curious how you
> handle
> > this in practice.
>
> My personal guideline is like this:
>   - obvious build fixes are proposed right away (because they unbreak
> stuff);
>   - testbug fixes are proposed right away (because they do not affect
> product quality);
>   - simple fixes are proposed after a few nightly cycles (the follow-up
> bugs are usually filed
> within days from the initial integration into master);
>   - complex fixes are proposed after at least 10 days (same reason, but
> give more time to catch bugs)
>   - very complex fixes are proposed after about a month of stewing, and
> then only in the initial
> months of the update release (and they generally try to match the Oracle's
> version)
>
> jdk-backports-monitor, for example, has the automatic cooldown set for 10
> days:
>
> https://builds.shipilev.net/backports-monitor/label-actionable-redhat-interest.txt
>
> ------------------------------------
>
> JDK-8260934: java/lang/StringBuilder/HugeCapacity.java fails without
> Compact Strings
>
>    Original Bug:
>        URL: https://bugs.openjdk.java.net/browse/JDK-8260934
>        Reporter: Aleksey Shipilev
>        Assignee: Aleksey Shipilev
>        Priority: P4
>        Components: core-libs/java.lang
>
>    Original Fix:
>           17: JDK-8260934,
> https://git.openjdk.java.net/jdk/commit/ad54d8dd, shade, 7 day(s) ago
>
>    Backports and Forwardports:
>           16: WAITING for patch to bake a little: 3 days more
>           11: WAITING for patch to bake a little: 3 days more
>            8: Not affected
>
> ------------------------------------
>
> --
> Thanks,
> -Aleksey
>
>

From aph at redhat.com  Wed Feb 17 09:29:12 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Feb 2021 09:29:12 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
Message-ID: <232e541b-b61f-c83a-f334-a77f9e671c77@redhat.com>

On 16/02/2021 19:30, erik.joelsson at oracle.com wrote:
> In the end, the state of the mono repo at each tag is verified to be 
> exactly the same as the forest of repos at each tag. The state of 
> changes between tags is however less predictable in 8u compared to 
> mainline due to the large amount of non linear tags.

OK, thanks. That was a very useful explanation of what we need
to know.

-- 
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  Wed Feb 17 09:30:12 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 17 Feb 2021 09:30:12 +0000
Subject: How speedy are patches to be downported to 11?
In-Reply-To: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
References: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
Message-ID: <7bc67a72-d738-0fcd-bd2e-9f9ded0f2de2@redhat.com>

On 17/02/2021 07:43, Thomas St?fe wrote:
> what is the general policy of downporting changes from 17 to 11? I see
> sometimes changes downported rather quickly which could have done with a
> little more baking time. Especially since 17 is not even released yet.
> 
> Are there guidelines to follow? I did not find anything in the Wiki. Eg
> minimum time to let a patch stew in the head release?
> 
> Related to that, how are possible compatibility issues to be handled? Eg. a
> patch fixing the output of a command may be correct but may still throw off
> parsers.
> 
> I suspect the answer will be "its up to you", and depends
> on patch complexity and bug severity. But I still am curious how you handle
> this in practice.

It completely depends on severity and urgency, and to some extent on
the age of the release. As JDK 11 gets older, we should be increasingly
reluctant to patch it: users have a reasonable assumption that a
release becomes increasingly stable over time.

It's always better to allow a patch to bake in head for some time, but
often there's no good reason to delay. In addition to what Aleksey said,
some complex and intrusive patches need a whole release cycle, more
than six months.

-- 
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 chris.hegarty at oracle.com  Wed Feb 17 09:58:42 2021
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 17 Feb 2021 09:58:42 +0000
Subject: How speedy are patches to be downported to 11?
In-Reply-To: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
References: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
Message-ID: <17663948-2866-47BE-A18D-5FB25B55413C@oracle.com>

Thomas,

> On 17 Feb 2021, at 07:43, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> Hi,
> 
> what is the general policy of downporting changes from 17 to 11?

I know this is not what you asked ;-), but ...  At a minimum, when considering backporting to the previous LTS, it would be good to also consider porting to the latest shipping (or soon to be shipping) non-LTS release, .e.g in this case 16u. It?s desirable that there be a reasonable verification and migration path from prior releases to an update of the-latest-major-release.

-Chris.

From kravikumar at openjdk.java.net  Wed Feb 17 10:01:18 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Wed, 17 Feb 2021 10:01:18 GMT
Subject: [jdk16u] RFR: 8261209: isStandalone property: remove dependency on
 pretty-print
Message-ID: <EAZw-Kr3cKFhsYwD2zT01J8fN8wB4Z5eGFFRt3ruLOc=.eb3d5613-bc5c-4a36-afe5-5e153600b80b@github.com>

Backport JDK-8261209 to 16u repo. Patch applies clean and passed regression

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

Commit messages:
 - Backport 7c565f8b377bc4b61fa907b68d8c23d489df1cdc

Changes: https://git.openjdk.java.net/jdk16u/pull/29/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=29&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261209
  Stats: 36 lines in 3 files changed: 18 ins; 2 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/29/head:pull/29

PR: https://git.openjdk.java.net/jdk16u/pull/29

From thomas.stuefe at gmail.com  Wed Feb 17 10:28:16 2021
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 17 Feb 2021 11:28:16 +0100
Subject: How speedy are patches to be downported to 11?
In-Reply-To: <17663948-2866-47BE-A18D-5FB25B55413C@oracle.com>
References: <CAA-vtUx9p9nMQZr=vu4pZjHioLk30koqDZ8B45u64jkgNrV27w@mail.gmail.com>
 <17663948-2866-47BE-A18D-5FB25B55413C@oracle.com>
Message-ID: <CAA-vtUwsCEgdj7x4W5zJbCiOGNk8qqtwNvQObD5Obkzdfbu+3Q@mail.gmail.com>

On Wed, Feb 17, 2021 at 10:58 AM Chris Hegarty <chris.hegarty at oracle.com>
wrote:

> Thomas,
>
> > On 17 Feb 2021, at 07:43, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> >
> > Hi,
> >
> > what is the general policy of downporting changes from 17 to 11?
>
> I know this is not what you asked ;-), but ...  At a minimum, when
> considering backporting to the previous LTS, it would be good to also
> consider porting to the latest shipping (or soon to be shipping) non-LTS
> release, .e.g in this case 16u. It?s desirable that there be a reasonable
> verification and migration path from prior releases to an update of
> the-latest-major-release.
>
>
Yes, that makes sense.

Thanks, Thomas



> -Chris.

From kravikumar at openjdk.java.net  Wed Feb 17 11:21:44 2021
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Wed, 17 Feb 2021 11:21:44 GMT
Subject: [jdk16u] Integrated: 8261209: isStandalone property: remove
 dependency on pretty-print
In-Reply-To: <EAZw-Kr3cKFhsYwD2zT01J8fN8wB4Z5eGFFRt3ruLOc=.eb3d5613-bc5c-4a36-afe5-5e153600b80b@github.com>
References: <EAZw-Kr3cKFhsYwD2zT01J8fN8wB4Z5eGFFRt3ruLOc=.eb3d5613-bc5c-4a36-afe5-5e153600b80b@github.com>
Message-ID: <4kcL31cXatonWG8lAiwuNnoXkOGxdlIL2vNRx3XKEO8=.647b87ec-ecae-492b-a615-25d6c46d8fef@github.com>

On Wed, 17 Feb 2021 09:56:14 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Backport JDK-8261209 to 16u repo. Patch applies clean and passed regression

This pull request has now been integrated.

Changeset: 7f9d72bc
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/7f9d72bc
Stats:     36 lines in 3 files changed: 18 ins; 2 del; 16 mod

8261209: isStandalone property: remove dependency on pretty-print

Backport-of: 7c565f8b377bc4b61fa907b68d8c23d489df1cdc

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

PR: https://git.openjdk.java.net/jdk16u/pull/29

From volker.simonis at gmail.com  Wed Feb 17 13:54:07 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 17 Feb 2021 14:54:07 +0100
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
Message-ID: <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>

Hi Erik^2 :)

thank you so much for the detailed description. I'm especially excited
that you've already published fully consolidated mono-repos for jdk 6
to 9. That's really very much appreciated!

Now that the heavy lifting has been done, I hope we can seriously
consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what
blockers are you still seeing? Is there anything the community can
help with to speedup the migration?

Thank you and best regards,
Volker

On Tue, Feb 16, 2021 at 8:31 PM <erik.joelsson at oracle.com> wrote:
>
> Hello,
>
> As you may have seen, Erik Duveblad just posted about our prototype
> conversions on skara-dev [1]. These are based on the same kind of
> forest->mono repo conversion, followed by hg->git conversion that
> mainline went through.
>
> I have been working for a while now on adapting the scripts from JEP 296
> to work for the old update releases. This has required more work than I
> first anticipated as the problem now requires a more generalized
> solution, but I believe I now have something that works reasonably well.
> If you are curious on the details, please continue reading.
>
> Volker's description of the processes is pretty accurate on a high
> level. The main difference in 8u compared to a main release is that the
> tags are not sequential in history. This means that we can't transplant
> (or splice as it's called in Mercurial terms) changes as freely on top
> of each tagged change. In the original JDK 10 consolidation, we had a
> handful of changes that weren't linear (around the transition between
> JDK 9 and 10), and I handled them differently (basically just merging
> them together to recreate the point in history, but not splicing
> anything on top afterwards). Since they were only a handful, I could
> just list them out explicitly in the script. For 8u, a majority of the
> tags are non linear, so a big problem was creating an algorithm that
> would automatically figure out a reasonable line of tags in sequence
> that I could use to splice changes on top of.
>
> Another big problem is that there are often tags merged together in
> different order in different repos. When this happens, the script needs
> to figure out the best order to do the conversion. I have tried to
> automate this process as much as possible. The ordering is sensitive
> when some of the tags are used to splice changes on top of them. There
> are also cases of tags missing completely.
>
> In the end, the state of the mono repo at each tag is verified to be
> exactly the same as the forest of repos at each tag. The state of
> changes between tags is however less predictable in 8u compared to
> mainline due to the large amount of non linear tags.
>
> For the extra curious, here is what the current algorithm for choosing
> the "splice tags" looks like:
>
> 1. Start with the first tag
>
> 2. Continue with each consecutive build for current release until a gap
> in build numbers is detected (we typically have update release builds
>  >b30 that probably aren't that interesting)
>
> 3. Find the next release in order and then find the first tag in that
> release that is also a descendant of the previous splice tag in every repo.
>
> 4. Repeat from 2 until all tags have been considered.
>
> /Erik
>
> [1]
> https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html
>
> On 2021-02-12 13:33, Volker Simonis wrote:
> > On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
> >> On 12/02/2021 16:37, Severin Gehwolf wrote:
> >>> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
> >>> more thought than 11u.
> >> That's what I was thinking.
> >>
> >>> My preference would be to do it in steps:
> >>> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
> >>> 2.) HG -> git conversion using Skara tooling (should take care of
> >>>       proper metadata, etc.)
> >> Yes, I think this is the right way to go about it. If nothing else
> >> because the tools for the second step assumed that the first one had
> >> happened.
> >>
> >> The really tricky differences I see happen at step 1 (although they
> >> might have a knock-on effect at step 2)
> >>
> > I think converting 8u to a Git mono-repo might not be as complicated
> > and risky as it seems. We have to remember that most of the work has
> > already been done by JEP 296 in jdk10. That process already converted
> > all the old history and as nobody seems to have been complaining about
> > it in jdk10 and later, that conversion must have been fine. I.e. The
> > jdk 10 repository naturally contains the sources of jdk8 from which is
> > was initially forked (I think at jdk8-b120).
> >
> > So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:
> >
> > hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120
> >
> > This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
> > we only have to use the JEP 296 scripts or something equivalent (I
> > hope that the Oracle build group can assist or at least give some good
> > advice here :)
> >
> >  From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
> > with the above command, it looks like the "JEP 296" script worked as
> > follows:
> > - let's assume were at a changeset which merges all the subrepos at a
> > specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
> > every jdk8-bXX tag corresponds to a weekly version).
> > - sequentially transplant all the changes from a single subrepo up
> > until the next tag "jdk8-bXX+1" into the new repo
> > - do this sequentially for all the other sub-repositories
> > - create a merge change in the new mono-repo which merges all the
> > newly transplanted changes and tag it with "jdk8-bXX+1"
> > - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
> > bit-wise equal to the sources of the jdk8u forest when every single
> > repo is synced to the same tag.
> > - repeat the procedure for all the other jdk8-bXX tags
> >
> > We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
> > the described procedure for all the additional changes between
> > jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
> > Needless to say that the Corretto team is fully supporting the
> > transition of jdk8u from a Mercurial forest to a Git mono-repo and
> > will be happy to get involved into the process :)
> >
> > Best regards,
> > Volker
> >
> >>     JEP 296 had to relocate all the java code into modules
> >>     JEP 296 did not have to retain (and therefore relocate) all of the
> >> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
> >>
> >> I don't suppose these differences would be impossible to sort out but I
> >> think they would require some effort.
> >>
> >> regards,
> >>
> >>
> >> Andrew Dinn
> >> -----------
> >>

From goetz.lindenmaier at sap.com  Wed Feb 17 15:19:12 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 17 Feb 2021 15:19:12 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
 <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
Message-ID: <AM0PR0202MB3443C5E5EB1C035EAEBA63B6EC869@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

I think it is about time to start a thread of its own to discuss this for 8.
What do you think?

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of Volker
> Simonis
> Sent: Wednesday, February 17, 2021 2:54 PM
> To: Erik Joelsson <erik.joelsson at oracle.com>; Erik Helin
> <erik.helin at oracle.com>
> Cc: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>; jdk8u-dev <jdk8u-
> dev at openjdk.java.net>
> Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> 11.0.13 cycle
> 
> Hi Erik^2 :)
> 
> thank you so much for the detailed description. I'm especially excited
> that you've already published fully consolidated mono-repos for jdk 6
> to 9. That's really very much appreciated!
> 
> Now that the heavy lifting has been done, I hope we can seriously
> consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what
> blockers are you still seeing? Is there anything the community can
> help with to speedup the migration?
> 
> Thank you and best regards,
> Volker
> 
> On Tue, Feb 16, 2021 at 8:31 PM <erik.joelsson at oracle.com> wrote:
> >
> > Hello,
> >
> > As you may have seen, Erik Duveblad just posted about our prototype
> > conversions on skara-dev [1]. These are based on the same kind of
> > forest->mono repo conversion, followed by hg->git conversion that
> > mainline went through.
> >
> > I have been working for a while now on adapting the scripts from JEP 296
> > to work for the old update releases. This has required more work than I
> > first anticipated as the problem now requires a more generalized
> > solution, but I believe I now have something that works reasonably well.
> > If you are curious on the details, please continue reading.
> >
> > Volker's description of the processes is pretty accurate on a high
> > level. The main difference in 8u compared to a main release is that the
> > tags are not sequential in history. This means that we can't transplant
> > (or splice as it's called in Mercurial terms) changes as freely on top
> > of each tagged change. In the original JDK 10 consolidation, we had a
> > handful of changes that weren't linear (around the transition between
> > JDK 9 and 10), and I handled them differently (basically just merging
> > them together to recreate the point in history, but not splicing
> > anything on top afterwards). Since they were only a handful, I could
> > just list them out explicitly in the script. For 8u, a majority of the
> > tags are non linear, so a big problem was creating an algorithm that
> > would automatically figure out a reasonable line of tags in sequence
> > that I could use to splice changes on top of.
> >
> > Another big problem is that there are often tags merged together in
> > different order in different repos. When this happens, the script needs
> > to figure out the best order to do the conversion. I have tried to
> > automate this process as much as possible. The ordering is sensitive
> > when some of the tags are used to splice changes on top of them. There
> > are also cases of tags missing completely.
> >
> > In the end, the state of the mono repo at each tag is verified to be
> > exactly the same as the forest of repos at each tag. The state of
> > changes between tags is however less predictable in 8u compared to
> > mainline due to the large amount of non linear tags.
> >
> > For the extra curious, here is what the current algorithm for choosing
> > the "splice tags" looks like:
> >
> > 1. Start with the first tag
> >
> > 2. Continue with each consecutive build for current release until a gap
> > in build numbers is detected (we typically have update release builds
> >  >b30 that probably aren't that interesting)
> >
> > 3. Find the next release in order and then find the first tag in that
> > release that is also a descendant of the previous splice tag in every repo.
> >
> > 4. Repeat from 2 until all tags have been considered.
> >
> > /Erik
> >
> > [1]
> > https://mail.openjdk.java.net/pipermail/skara-dev/2021-
> February/004228.html
> >
> > On 2021-02-12 13:33, Volker Simonis wrote:
> > > On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
> > >> On 12/02/2021 16:37, Severin Gehwolf wrote:
> > >>> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
> > >>> more thought than 11u.
> > >> That's what I was thinking.
> > >>
> > >>> My preference would be to do it in steps:
> > >>> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
> > >>> 2.) HG -> git conversion using Skara tooling (should take care of
> > >>>       proper metadata, etc.)
> > >> Yes, I think this is the right way to go about it. If nothing else
> > >> because the tools for the second step assumed that the first one had
> > >> happened.
> > >>
> > >> The really tricky differences I see happen at step 1 (although they
> > >> might have a knock-on effect at step 2)
> > >>
> > > I think converting 8u to a Git mono-repo might not be as complicated
> > > and risky as it seems. We have to remember that most of the work has
> > > already been done by JEP 296 in jdk10. That process already converted
> > > all the old history and as nobody seems to have been complaining about
> > > it in jdk10 and later, that conversion must have been fine. I.e. The
> > > jdk 10 repository naturally contains the sources of jdk8 from which is
> > > was initially forked (I think at jdk8-b120).
> > >
> > > So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:
> > >
> > > hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120
> > >
> > > This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
> > > we only have to use the JEP 296 scripts or something equivalent (I
> > > hope that the Oracle build group can assist or at least give some good
> > > advice here :)
> > >
> > >  From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
> > > with the above command, it looks like the "JEP 296" script worked as
> > > follows:
> > > - let's assume were at a changeset which merges all the subrepos at a
> > > specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
> > > every jdk8-bXX tag corresponds to a weekly version).
> > > - sequentially transplant all the changes from a single subrepo up
> > > until the next tag "jdk8-bXX+1" into the new repo
> > > - do this sequentially for all the other sub-repositories
> > > - create a merge change in the new mono-repo which merges all the
> > > newly transplanted changes and tag it with "jdk8-bXX+1"
> > > - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
> > > bit-wise equal to the sources of the jdk8u forest when every single
> > > repo is synced to the same tag.
> > > - repeat the procedure for all the other jdk8-bXX tags
> > >
> > > We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
> > > the described procedure for all the additional changes between
> > > jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
> > > Needless to say that the Corretto team is fully supporting the
> > > transition of jdk8u from a Mercurial forest to a Git mono-repo and
> > > will be happy to get involved into the process :)
> > >
> > > Best regards,
> > > Volker
> > >
> > >>     JEP 296 had to relocate all the java code into modules
> > >>     JEP 296 did not have to retain (and therefore relocate) all of the
> > >> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
> > >>
> > >> I don't suppose these differences would be impossible to sort out but I
> > >> think they would require some effort.
> > >>
> > >> regards,
> > >>
> > >>
> > >> Andrew Dinn
> > >> -----------
> > >>

From vkempik at azul.com  Wed Feb 17 16:18:49 2021
From: vkempik at azul.com (Vladimir Kempik)
Date: Wed, 17 Feb 2021 16:18:49 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
 <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
Message-ID: <15fb175913bd4861a788ce1586111fa5@azul.com>

Hello

We have observed one issue on jdk13u-dev after switching to skara: doing clean backport becomes a lot more complicated than with hg, as result it slowed our backporting pace.

Regards, Vladimir.

Volker Simonis <volker.simonis at gmail.com> 17 ??????? 2021 ?. 16:54:46 ???????:

Hi Erik^2 :)

thank you so much for the detailed description. I'm especially excited
that you've already published fully consolidated mono-repos for jdk 6
to 9. That's really very much appreciated!

Now that the heavy lifting has been done, I hope we can seriously
consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what
blockers are you still seeing? Is there anything the community can
help with to speedup the migration?

Thank you and best regards,
Volker

On Tue, Feb 16, 2021 at 8:31 PM <erik.joelsson at oracle.com> wrote:

Hello,

As you may have seen, Erik Duveblad just posted about our prototype
conversions on skara-dev [1]. These are based on the same kind of
forest->mono repo conversion, followed by hg->git conversion that
mainline went through.

I have been working for a while now on adapting the scripts from JEP 296
to work for the old update releases. This has required more work than I
first anticipated as the problem now requires a more generalized
solution, but I believe I now have something that works reasonably well.
If you are curious on the details, please continue reading.

Volker's description of the processes is pretty accurate on a high
level. The main difference in 8u compared to a main release is that the
tags are not sequential in history. This means that we can't transplant
(or splice as it's called in Mercurial terms) changes as freely on top
of each tagged change. In the original JDK 10 consolidation, we had a
handful of changes that weren't linear (around the transition between
JDK 9 and 10), and I handled them differently (basically just merging
them together to recreate the point in history, but not splicing
anything on top afterwards). Since they were only a handful, I could
just list them out explicitly in the script. For 8u, a majority of the
tags are non linear, so a big problem was creating an algorithm that
would automatically figure out a reasonable line of tags in sequence
that I could use to splice changes on top of.

Another big problem is that there are often tags merged together in
different order in different repos. When this happens, the script needs
to figure out the best order to do the conversion. I have tried to
automate this process as much as possible. The ordering is sensitive
when some of the tags are used to splice changes on top of them. There
are also cases of tags missing completely.

In the end, the state of the mono repo at each tag is verified to be
exactly the same as the forest of repos at each tag. The state of
changes between tags is however less predictable in 8u compared to
mainline due to the large amount of non linear tags.

For the extra curious, here is what the current algorithm for choosing
the "splice tags" looks like:

1. Start with the first tag

2. Continue with each consecutive build for current release until a gap
in build numbers is detected (we typically have update release builds
b30 that probably aren't that interesting)

3. Find the next release in order and then find the first tag in that
release that is also a descendant of the previous splice tag in every repo.

4. Repeat from 2 until all tags have been considered.

/Erik

[1]
https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html

On 2021-02-12 13:33, Volker Simonis wrote:
On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
On 12/02/2021 16:37, Severin Gehwolf wrote:
Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
more thought than 11u.
That's what I was thinking.

My preference would be to do it in steps:
1.) HG forest -> monorepo conversion (using JEP 296 scripts)
2.) HG -> git conversion using Skara tooling (should take care of
  proper metadata, etc.)
Yes, I think this is the right way to go about it. If nothing else
because the tools for the second step assumed that the first one had
happened.

The really tricky differences I see happen at step 1 (although they
might have a knock-on effect at step 2)

I think converting 8u to a Git mono-repo might not be as complicated
and risky as it seems. We have to remember that most of the work has
already been done by JEP 296 in jdk10. That process already converted
all the old history and as nobody seems to have been complaining about
it in jdk10 and later, that conversion must have been fine. I.e. The
jdk 10 repository naturally contains the sources of jdk8 from which is
was initially forked (I think at jdk8-b120).

So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:

hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120

This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
we only have to use the JEP 296 scripts or something equivalent (I
hope that the Oracle build group can assist or at least give some good
advice here :)

>From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
with the above command, it looks like the "JEP 296" script worked as
follows:
- let's assume were at a changeset which merges all the subrepos at a
specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
every jdk8-bXX tag corresponds to a weekly version).
- sequentially transplant all the changes from a single subrepo up
until the next tag "jdk8-bXX+1" into the new repo
- do this sequentially for all the other sub-repositories
- create a merge change in the new mono-repo which merges all the
newly transplanted changes and tag it with "jdk8-bXX+1"
- verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
bit-wise equal to the sources of the jdk8u forest when every single
repo is synced to the same tag.
- repeat the procedure for all the other jdk8-bXX tags

We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
the described procedure for all the additional changes between
jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
Needless to say that the Corretto team is fully supporting the
transition of jdk8u from a Mercurial forest to a Git mono-repo and
will be happy to get involved into the process :)

Best regards,
Volker

JEP 296 had to relocate all the java code into modules
JEP 296 did not have to retain (and therefore relocate) all of the
java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)

I don't suppose these differences would be impossible to sort out but I
think they would require some effort.

regards,


Andrew Dinn
-----------



From alvdavi at amazon.com  Wed Feb 17 17:07:41 2021
From: alvdavi at amazon.com (Alvarez, David)
Date: Wed, 17 Feb 2021 17:07:41 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <15fb175913bd4861a788ce1586111fa5@azul.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
 <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>,
 <15fb175913bd4861a788ce1586111fa5@azul.com>
Message-ID: <290418C3-C152-4678-A02D-B2965D573887@amazon.com>

Hi,

I?m intrigued about the clean back port issue. Would you mind providing more detail on why is that so?

Thanks,

David

> On Feb 17, 2021, at 08:19, Vladimir Kempik <vkempik at azul.com> wrote:
> 
> ?CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hello
> 
> We have observed one issue on jdk13u-dev after switching to skara: doing clean backport becomes a lot more complicated than with hg, as result it slowed our backporting pace.
> 
> Regards, Vladimir.
> 
> Volker Simonis <volker.simonis at gmail.com> 17 ??????? 2021 ?. 16:54:46 ???????:
> 
> Hi Erik^2 :)
> 
> thank you so much for the detailed description. I'm especially excited
> that you've already published fully consolidated mono-repos for jdk 6
> to 9. That's really very much appreciated!
> 
> Now that the heavy lifting has been done, I hope we can seriously
> consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what
> blockers are you still seeing? Is there anything the community can
> help with to speedup the migration?
> 
> Thank you and best regards,
> Volker
> 
> On Tue, Feb 16, 2021 at 8:31 PM <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> As you may have seen, Erik Duveblad just posted about our prototype
> conversions on skara-dev [1]. These are based on the same kind of
> forest->mono repo conversion, followed by hg->git conversion that
> mainline went through.
> 
> I have been working for a while now on adapting the scripts from JEP 296
> to work for the old update releases. This has required more work than I
> first anticipated as the problem now requires a more generalized
> solution, but I believe I now have something that works reasonably well.
> If you are curious on the details, please continue reading.
> 
> Volker's description of the processes is pretty accurate on a high
> level. The main difference in 8u compared to a main release is that the
> tags are not sequential in history. This means that we can't transplant
> (or splice as it's called in Mercurial terms) changes as freely on top
> of each tagged change. In the original JDK 10 consolidation, we had a
> handful of changes that weren't linear (around the transition between
> JDK 9 and 10), and I handled them differently (basically just merging
> them together to recreate the point in history, but not splicing
> anything on top afterwards). Since they were only a handful, I could
> just list them out explicitly in the script. For 8u, a majority of the
> tags are non linear, so a big problem was creating an algorithm that
> would automatically figure out a reasonable line of tags in sequence
> that I could use to splice changes on top of.
> 
> Another big problem is that there are often tags merged together in
> different order in different repos. When this happens, the script needs
> to figure out the best order to do the conversion. I have tried to
> automate this process as much as possible. The ordering is sensitive
> when some of the tags are used to splice changes on top of them. There
> are also cases of tags missing completely.
> 
> In the end, the state of the mono repo at each tag is verified to be
> exactly the same as the forest of repos at each tag. The state of
> changes between tags is however less predictable in 8u compared to
> mainline due to the large amount of non linear tags.
> 
> For the extra curious, here is what the current algorithm for choosing
> the "splice tags" looks like:
> 
> 1. Start with the first tag
> 
> 2. Continue with each consecutive build for current release until a gap
> in build numbers is detected (we typically have update release builds
> b30 that probably aren't that interesting)
> 
> 3. Find the next release in order and then find the first tag in that
> release that is also a descendant of the previous splice tag in every repo.
> 
> 4. Repeat from 2 until all tags have been considered.
> 
> /Erik
> 
> [1]
> https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html
> 
> On 2021-02-12 13:33, Volker Simonis wrote:
> On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
> On 12/02/2021 16:37, Severin Gehwolf wrote:
> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
> more thought than 11u.
> That's what I was thinking.
> 
> My preference would be to do it in steps:
> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
> 2.) HG -> git conversion using Skara tooling (should take care of
>  proper metadata, etc.)
> Yes, I think this is the right way to go about it. If nothing else
> because the tools for the second step assumed that the first one had
> happened.
> 
> The really tricky differences I see happen at step 1 (although they
> might have a knock-on effect at step 2)
> 
> I think converting 8u to a Git mono-repo might not be as complicated
> and risky as it seems. We have to remember that most of the work has
> already been done by JEP 296 in jdk10. That process already converted
> all the old history and as nobody seems to have been complaining about
> it in jdk10 and later, that conversion must have been fine. I.e. The
> jdk 10 repository naturally contains the sources of jdk8 from which is
> was initially forked (I think at jdk8-b120).
> 
> So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:
> 
> hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120
> 
> This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
> we only have to use the JEP 296 scripts or something equivalent (I
> hope that the Oracle build group can assist or at least give some good
> advice here :)
> 
> From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
> with the above command, it looks like the "JEP 296" script worked as
> follows:
> - let's assume were at a changeset which merges all the subrepos at a
> specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
> every jdk8-bXX tag corresponds to a weekly version).
> - sequentially transplant all the changes from a single subrepo up
> until the next tag "jdk8-bXX+1" into the new repo
> - do this sequentially for all the other sub-repositories
> - create a merge change in the new mono-repo which merges all the
> newly transplanted changes and tag it with "jdk8-bXX+1"
> - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
> bit-wise equal to the sources of the jdk8u forest when every single
> repo is synced to the same tag.
> - repeat the procedure for all the other jdk8-bXX tags
> 
> We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
> the described procedure for all the additional changes between
> jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
> Needless to say that the Corretto team is fully supporting the
> transition of jdk8u from a Mercurial forest to a Git mono-repo and
> will be happy to get involved into the process :)
> 
> Best regards,
> Volker
> 
> JEP 296 had to relocate all the java code into modules
> JEP 296 did not have to retain (and therefore relocate) all of the
> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
> 
> I don't suppose these differences would be impossible to sort out but I
> think they would require some effort.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 
> 

From vkempik at azul.com  Wed Feb 17 17:32:05 2021
From: vkempik at azul.com (Vladimir Kempik)
Date: Wed, 17 Feb 2021 17:32:05 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <15fb175913bd4861a788ce1586111fa5@azul.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
 <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
 <15fb175913bd4861a788ce1586111fa5@azul.com>
Message-ID: <F9E0F090-EEDC-4660-A516-956011291C64@azul.com>

Hello
so the old process, with hg:
if backport applies cleanly - do request to backport via jbs, once approved - push it to the repo, preserving original patch metadata (author, etc)

new process with skara:
if backport appliess cleanly - create pull request, if bot decides its clean - can be integrated without review, then get approval via jbs, then integrate
if backport does not apply cleanly - create pull request, wait for it to be reviewed, then get approval via jbs, then integrate

issue1: it?s bot who decides if this a clean backport or not, almost clean == not clean
issue2 ( small one): clean backport is pushed under the name of backporter, not original author
when we only started with skara on jdk13u-dev, clean backports mechanics wasn?t existing yet, so every backport had to be reviewed, slowing us, now it?s a bit easier.

Skara is generally good for backports now. You may want to try to backport something into jdk13u-dev to test it yourself before you switch jdk11u-dev to git.

Regards, Vladimir.

> 17 ????. 2021 ?., ? 19:18, Vladimir Kempik <vkempik at azul.com> ???????(?):
> 
> Hello
> 
> We have observed one issue on jdk13u-dev after switching to skara: doing clean backport becomes a lot more complicated than with hg, as result it slowed our backporting pace.
> 
> Regards, Vladimir.
> 
> Volker Simonis <volker.simonis at gmail.com> 17 ??????? 2021 ?. 16:54:46 ???????:
> 
> Hi Erik^2 :)
> 
> thank you so much for the detailed description. I'm especially excited
> that you've already published fully consolidated mono-repos for jdk 6
> to 9. That's really very much appreciated!
> 
> Now that the heavy lifting has been done, I hope we can seriously
> consider migrating 8u to Git as well. @OpenJDK8u-Maintainers - what
> blockers are you still seeing? Is there anything the community can
> help with to speedup the migration?
> 
> Thank you and best regards,
> Volker
> 
> On Tue, Feb 16, 2021 at 8:31 PM <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> As you may have seen, Erik Duveblad just posted about our prototype
> conversions on skara-dev [1]. These are based on the same kind of
> forest->mono repo conversion, followed by hg->git conversion that
> mainline went through.
> 
> I have been working for a while now on adapting the scripts from JEP 296
> to work for the old update releases. This has required more work than I
> first anticipated as the problem now requires a more generalized
> solution, but I believe I now have something that works reasonably well.
> If you are curious on the details, please continue reading.
> 
> Volker's description of the processes is pretty accurate on a high
> level. The main difference in 8u compared to a main release is that the
> tags are not sequential in history. This means that we can't transplant
> (or splice as it's called in Mercurial terms) changes as freely on top
> of each tagged change. In the original JDK 10 consolidation, we had a
> handful of changes that weren't linear (around the transition between
> JDK 9 and 10), and I handled them differently (basically just merging
> them together to recreate the point in history, but not splicing
> anything on top afterwards). Since they were only a handful, I could
> just list them out explicitly in the script. For 8u, a majority of the
> tags are non linear, so a big problem was creating an algorithm that
> would automatically figure out a reasonable line of tags in sequence
> that I could use to splice changes on top of.
> 
> Another big problem is that there are often tags merged together in
> different order in different repos. When this happens, the script needs
> to figure out the best order to do the conversion. I have tried to
> automate this process as much as possible. The ordering is sensitive
> when some of the tags are used to splice changes on top of them. There
> are also cases of tags missing completely.
> 
> In the end, the state of the mono repo at each tag is verified to be
> exactly the same as the forest of repos at each tag. The state of
> changes between tags is however less predictable in 8u compared to
> mainline due to the large amount of non linear tags.
> 
> For the extra curious, here is what the current algorithm for choosing
> the "splice tags" looks like:
> 
> 1. Start with the first tag
> 
> 2. Continue with each consecutive build for current release until a gap
> in build numbers is detected (we typically have update release builds
> b30 that probably aren't that interesting)
> 
> 3. Find the next release in order and then find the first tag in that
> release that is also a descendant of the previous splice tag in every repo.
> 
> 4. Repeat from 2 until all tags have been considered.
> 
> /Erik
> 
> [1]
> https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html
> 
> On 2021-02-12 13:33, Volker Simonis wrote:
> On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
> On 12/02/2021 16:37, Severin Gehwolf wrote:
> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
> more thought than 11u.
> That's what I was thinking.
> 
> My preference would be to do it in steps:
> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
> 2.) HG -> git conversion using Skara tooling (should take care of
>  proper metadata, etc.)
> Yes, I think this is the right way to go about it. If nothing else
> because the tools for the second step assumed that the first one had
> happened.
> 
> The really tricky differences I see happen at step 1 (although they
> might have a knock-on effect at step 2)
> 
> I think converting 8u to a Git mono-repo might not be as complicated
> and risky as it seems. We have to remember that most of the work has
> already been done by JEP 296 in jdk10. That process already converted
> all the old history and as nobody seems to have been complaining about
> it in jdk10 and later, that conversion must have been fine. I.e. The
> jdk 10 repository naturally contains the sources of jdk8 from which is
> was initially forked (I think at jdk8-b120).
> 
> So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:
> 
> hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120
> 
> This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
> we only have to use the JEP 296 scripts or something equivalent (I
> hope that the Oracle build group can assist or at least give some good
> advice here :)
> 
> From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
> with the above command, it looks like the "JEP 296" script worked as
> follows:
> - let's assume were at a changeset which merges all the subrepos at a
> specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
> every jdk8-bXX tag corresponds to a weekly version).
> - sequentially transplant all the changes from a single subrepo up
> until the next tag "jdk8-bXX+1" into the new repo
> - do this sequentially for all the other sub-repositories
> - create a merge change in the new mono-repo which merges all the
> newly transplanted changes and tag it with "jdk8-bXX+1"
> - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
> bit-wise equal to the sources of the jdk8u forest when every single
> repo is synced to the same tag.
> - repeat the procedure for all the other jdk8-bXX tags
> 
> We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
> the described procedure for all the additional changes between
> jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
> Needless to say that the Corretto team is fully supporting the
> transition of jdk8u from a Mercurial forest to a Git mono-repo and
> will be happy to get involved into the process :)
> 
> Best regards,
> Volker
> 
> JEP 296 had to relocate all the java code into modules
> JEP 296 did not have to retain (and therefore relocate) all of the
> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
> 
> I don't suppose these differences would be impossible to sort out but I
> think they would require some effort.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 


From christoph.langer at sap.com  Wed Feb 17 18:58:56 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 Feb 2021 18:58:56 +0000
Subject: [11u] RFR (XS): 8261753: Test java/lang/System/OsVersionTest.java
 still failing on BigSur patch versions after JDK-8253702
Message-ID: <AM4PR02MB3138C9B7759134E725D5674C8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

please review the backport of this test fix. I requested backport of JDK-8253702 already which applies clean. However, when building on Mac with Xcode <12 and running on MacOS versions that have a patch version number (>0), OsVersionTest is still bound to fail.

I had to do a minor context adaption in the test imports.

Bug: https://bugs.openjdk.java.net/browse/JDK-8261753
Original Change: https://git.openjdk.java.net/jdk/commit/8ba390d1
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8261753.11u/

Thanks
Christoph


From christoph.langer at sap.com  Wed Feb 17 19:09:41 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 Feb 2021 19:09:41 +0000
Subject: [11u] RFR (XS): 8261829: Exclude
 tools/jlink/JLinkReproducibleTest.java in 11u
Message-ID: <AM4PR02MB3138F6F40C1E920A27A3EA598A869@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

please review this test exclusion for 11u.

The backport of JDK-8214230 [0] has introduced JLinkReproducibleTest which unfortunately fails randomly in 11u due to the absence of JEP 341: Default CDS Archives [1]. This was analyzed in bug report JDK-8258945 [2]. Since I assume we don't want to backport default CDS archives to 11u, we should find another solution to fix this test (if possible). For the time being the test should be excluded.

Bug: https://bugs.openjdk.java.net/browse/JDK-8261829
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8261829.11u/

Thanks
Christoph

[0] https://bugs.openjdk.java.net/browse/JDK-8214230
[1] https://bugs.openjdk.java.net/browse/JDK-8204247
[2] https://bugs.openjdk.java.net/browse/JDK-8258945


From christoph.langer at sap.com  Wed Feb 17 21:26:01 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 Feb 2021 21:26:01 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <F9E0F090-EEDC-4660-A516-956011291C64@azul.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
 <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
 <15fb175913bd4861a788ce1586111fa5@azul.com>
 <F9E0F090-EEDC-4660-A516-956011291C64@azul.com>
Message-ID: <AM4PR02MB313894F2D5DABE2506DE2BAC8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Vladimir,

> so the old process, with hg:
> if backport applies cleanly - do request to backport via jbs, once approved -
> push it to the repo, preserving original patch metadata (author, etc)
> 
> new process with skara:
> if backport appliess cleanly - create pull request, if bot decides its clean - can
> be integrated without review, then get approval via jbs, then integrate
> if backport does not apply cleanly - create pull request, wait for it to be
> reviewed, then get approval via jbs, then integrate
> 
> issue1: it?s bot who decides if this a clean backport or not, almost clean ==
> not clean

When we had a call with the Skara team, we talked about this point. For the case when the bot doesn't identify a backport as clean but we'd usually argue that it's a clean backport since e.g. only copyright headers changed or similar, we asked for a command to override the bot's decision. E.g. comment the PR with "/clean" or something like that. I don't know how the status of this development item is, though.

Anyway, even if such a "/clean" command isn't available, I'd rather think this wouldn't mean a big slowdown. You'd just have to find some reviewer to approve the PR.

> issue2 ( small one): clean backport is pushed under the name of backporter,
> not original author

This is a change of paradigm with the Skara tooling. A backport is now always attributed to the backporter which is something that several people involved in JDK updates backporting were asking for. So I wouldn't consider that as an issue, rather an improvement.

> when we only started with skara on jdk13u-dev, clean backports mechanics
> wasn?t existing yet, so every backport had to be reviewed, slowing us, now
> it?s a bit easier.
> 
> Skara is generally good for backports now. You may want to try to backport
> something into jdk13u-dev to test it yourself before you switch jdk11u-dev
> to git.

Thanks for your insights!

Cheers
Christoph

From christoph.langer at sap.com  Wed Feb 17 21:46:40 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 Feb 2021 21:46:40 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
Message-ID: <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi all,

collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ??

If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle.

I'll seek to get answers to some open questions:
- How do Merge PRs work?
- Will "git bundle" work for the CPU process?
- What about "git backport" and the "/backport" command in github?
- What's the status of "clean" backports?

This is what I have in my mind currently, please help me to add to the list in case I've forgot or overlooked something important.

If nobody stops me and I get these questions answered in a satisfactorily fashion, I will send around a final announcement about the switch in due course.

Sounds ok? (No response means yes ??)

Best regards
Christoph

PS: I suggest to start another thread for the 8u git discussions on jdk8u-dev...


> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Donnerstag, 11. Februar 2021 14:47
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Severin Gehwolf
> <sgehwolf at redhat.com>
> Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> 11.0.13 cycle
> 
> [Add: jdk8u-dev]
> 
> On 10/02/2021 16:39, Langer, Christoph wrote:
> > This is why we think the project should move to git:
> 
> I have no objection to this, but it's important to reach consensus,
> which ISO defines as
> 
>   General agreement, characterized by the absence of sustained opposition
>   to substantial issues by any important part of the concerned interests
>   and by a process that involves seeking to take into account the views
>   of all parties concerned and to reconcile any conflicting arguments
>   Consensus need not imply unanimity.
> 
> It's also important not to consider 11 in isolation: while we do not
> need to move 8 and 11 simultaneously, I very much do not want to see
> them use different workflows for a long period.
> 
> --
> 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 gouessej at orange.fr  Wed Feb 17 22:26:32 2021
From: gouessej at orange.fr (gouessej at orange.fr)
Date: Wed, 17 Feb 2021 23:26:32 +0100 (CET)
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <1364782376.9573.1613600792503.JavaMail.www@wwinf1f23>

Hello

?

No, it's not ok. I'd add "How to contribute without using a Github account?".

?

?

> Message du 17/02/21 22:47
> De : "Langer, Christoph" 
> A : "Andrew Haley" , "jdk-updates-dev at openjdk.java.net" 
> Copie ? : "jdk8u-dev at openjdk.java.net" , "Lindenmaier,
Goetz" , "Severin Gehwolf" 
> Objet : RE: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle
> 
> Hi all,
> 
> collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ??
> 
> If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle.
> 
> I'll seek to get answers to some open questions:
> - How do Merge PRs work?
> - Will "git bundle" work for the CPU process?
> - What about "git backport" and the "/backport" command in github?
> - What's the status of "clean" backports?
> 
> This is what I have in my mind currently, please help me to add to the list in case I've forgot or overlooked something important.
> 
> If nobody stops me and I get these questions answered in a satisfactorily fashion, I will send around a final announcement about the switch in due course.
> 
> Sounds ok? (No response means yes ??)
> 
> Best regards
> Christoph
> 
> PS: I suggest to start another thread for the 8u git discussions on jdk8u-dev...
> 
> 
> > -----Original Message-----
> > From: Andrew Haley 
> > Sent: Donnerstag, 11. Februar 2021 14:47
> > To: Langer, Christoph ; jdk-updates-
> > dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
> > Cc: Lindenmaier, Goetz ; Severin Gehwolf
> > 
> > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> > 11.0.13 cycle
> > 
> > [Add: jdk8u-dev]
> > 
> > On 10/02/2021 16:39, Langer, Christoph wrote:
> > > This is why we think the project should move to git:
> > 
> > I have no objection to this, but it's important to reach consensus,
> > which ISO defines as
> > 
> > General agreement, characterized by the absence of sustained opposition
> > to substantial issues by any important part of the concerned interests
> > and by a process that involves seeking to take into account the views
> > of all parties concerned and to reconcile any conflicting arguments
> > Consensus need not imply unanimity.
> > 
> > It's also important not to consider 11 in isolation: while we do not
> > need to move 8 and 11 simultaneously, I very much do not want to see
> > them use different workflows for a long period.
> > 
> > --
> > Andrew Haley (he/him)
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. 
> > https://keybase.io/andrewhaley
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
>

From christoph.langer at sap.com  Wed Feb 17 23:14:48 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 17 Feb 2021 23:14:48 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <1364782376.9573.1613600792503.JavaMail.www@wwinf1f23>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <1364782376.9573.1613600792503.JavaMail.www@wwinf1f23>
Message-ID: <AM4PR02MB31380340E12F2E1D1F5CF0C98A869@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

I?m sorry but this objection/question isn?t valid for this thread.

For a general discussion on whether OpenJDK development should be possible without GitHub Lock-In, you could start a discussion on the discuss or jdk-dev mailing lists at a general project level. But the update releases will have to follow the mainline infrastructure.

Cheers
Christoph


From: gouessej at orange.fr <gouessej at orange.fr>
Sent: Mittwoch, 17. Februar 2021 23:27
To: Langer, Christoph <christoph.langer at sap.com>; Andrew Haley <aph at redhat.com>; jdk-updates-dev at openjdk.java.net
Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Severin Gehwolf <sgehwolf at redhat.com>
Subject: RE: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle


Hello



No, it's not ok. I'd add "How to contribute without using a Github account?".




> Message du 17/02/21 22:47
> De : "Langer, Christoph" <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
> A : "Andrew Haley" <aph at redhat.com<mailto:aph at redhat.com>>, "jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>" <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>
> Copie ? : "jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>" <jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>>, "Lindenmaier,
Goetz" <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>, "Severin Gehwolf" <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>
> Objet : RE: [11u] Proposal: Switch jdk11u development to Git/Skara with 11.0.13 cycle
>
> Hi all,
>
> collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ??
>
> If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle.
>
> I'll seek to get answers to some open questions:
> - How do Merge PRs work?
> - Will "git bundle" work for the CPU process?
> - What about "git backport" and the "/backport" command in github?
> - What's the status of "clean" backports?
>
> This is what I have in my mind currently, please help me to add to the list in case I've forgot or overlooked something important.
>
> If nobody stops me and I get these questions answered in a satisfactorily fashion, I will send around a final announcement about the switch in due course.
>
> Sounds ok? (No response means yes ??)
>
> Best regards
> Christoph
>
> PS: I suggest to start another thread for the 8u git discussions on jdk8u-dev...
>
>
> > -----Original Message-----
> > From: Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>
> > Sent: Donnerstag, 11. Februar 2021 14:47
> > To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; jdk-updates-
> > dev at openjdk.java.net<mailto:dev at openjdk.java.net>; jdk8u-dev at openjdk.java.net<mailto:jdk8u-dev at openjdk.java.net>
> > Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>; Severin Gehwolf
> > <sgehwolf at redhat.com<mailto:sgehwolf at redhat.com>>
> > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> > 11.0.13 cycle
> >
> > [Add: jdk8u-dev]
> >
> > On 10/02/2021 16:39, Langer, Christoph wrote:
> > > This is why we think the project should move to git:
> >
> > I have no objection to this, but it's important to reach consensus,
> > which ISO defines as
> >
> > General agreement, characterized by the absence of sustained opposition
> > to substantial issues by any important part of the concerned interests
> > and by a process that involves seeking to take into account the views
> > of all parties concerned and to reconcile any conflicting arguments
> > Consensus need not imply unanimity.
> >
> > It's also important not to consider 11 in isolation: while we do not
> > need to move 8 and 11 simultaneously, I very much do not want to see
> > them use different workflows for a long period.
> >
> > --
> > 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 erikj at openjdk.java.net  Wed Feb 17 23:42:58 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 17 Feb 2021 23:42:58 GMT
Subject: [jdk16u] RFR: 8261261: The version extra fields needs to be
 overridable in jib-profiles.js
Message-ID: <IM7Q_Hf88jNqE51FvsS0Q9NrT-kC5T5mVRt5gWpohTg=.044b4fc4-08c1-49c7-98ef-2ed18b566c5c@github.com>

8261261: The version extra fields needs to be overridable in jib-profiles.js

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

Commit messages:
 - Applying patch from mainline

Changes: https://git.openjdk.java.net/jdk16u/pull/30/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=30&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261261
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/30/head:pull/30

PR: https://git.openjdk.java.net/jdk16u/pull/30

From mikael at openjdk.java.net  Thu Feb 18 00:51:42 2021
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 18 Feb 2021 00:51:42 GMT
Subject: [jdk16u] RFR: 8261261: The version extra fields needs to be
 overridable in jib-profiles.js
In-Reply-To: <IM7Q_Hf88jNqE51FvsS0Q9NrT-kC5T5mVRt5gWpohTg=.044b4fc4-08c1-49c7-98ef-2ed18b566c5c@github.com>
References: <IM7Q_Hf88jNqE51FvsS0Q9NrT-kC5T5mVRt5gWpohTg=.044b4fc4-08c1-49c7-98ef-2ed18b566c5c@github.com>
Message-ID: <dtx-tb2gfFeT3_Q8LCh4qYfj-55Ji6J5tiRFtplinVM=.349840ba-c5aa-4ea3-bdeb-beb19d724669@github.com>

On Wed, 17 Feb 2021 23:38:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> 8261261: The version extra fields needs to be overridable in jib-profiles.js

Marked as reviewed by mikael (Committer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/30

From qingfeng.yy at alibaba-inc.com  Thu Feb 18 05:27:27 2021
From: qingfeng.yy at alibaba-inc.com (Yang Yi)
Date: Thu, 18 Feb 2021 13:27:27 +0800
Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUjogQmFja3BvcnQgb2YgODIxNjA0MTogW0V2ZW50IFJlcXVlc3RdIC0g?=
 =?UTF-8?B?RGVvcHRpbWl6YXRpb24=?=
In-Reply-To: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
Message-ID: <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>

Gentle Ping :-)
 ------------------Original Mail ------------------
Sender:Yang Yi <qingfeng.yy at alibaba-inc.com>
Send Date:Sun Feb 7 16:54:52 2021
Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>
Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi,

Please can I request a review of this webrev for the backport of
https://bugs.openjdk.java.net/browse/JDK-8216041 ?

Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-8216041/webrev.00/

This patch doesn't apply cleanly but is fairly trivial. The signature of 
method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)` is
not different comparing to upstream and jdk11u. Simply adjusting the 
argument position and adding extra parameters can solve this problem.

Best,Yang Yi

From dmitry.chuyko at bell-sw.com  Thu Feb 18 08:26:39 2021
From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko)
Date: Thu, 18 Feb 2021 11:26:39 +0300
Subject: [11u] RFR (S) 8214922: Aarch64: Add vectorization support for
 fmin/fmax
Message-ID: <9d0af7aa-b4df-2774-f099-cc55de1890e0@bell-sw.com>

Hello,

Original RFE: https://bugs.openjdk.java.net/browse/JDK-8214922

Original patch applies almost cleanly except 2 added lines in 
src/hotspot/share/opto/vectornode.cpp because of missing part of context 
(JDK-8214751 not ported), they are added manually.

11u webrev: http://cr.openjdk.java.net/~dchuyko/8214922/webrev.11u.00/

Testing: tier1, tier2, TestFpMinMaxIntrinsics.

--
Thanks,
-Dmitry


From martin.doerr at sap.com  Thu Feb 18 10:06:52 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 18 Feb 2021 10:06:52 +0000
Subject: [11u] RFR (XS): 8261829: Exclude
 tools/jlink/JLinkReproducibleTest.java in 11u
In-Reply-To: <AM4PR02MB3138F6F40C1E920A27A3EA598A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138F6F40C1E920A27A3EA598A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB30571F4C544A95A78019D4819A859@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Christoph,

I think this makes sense. Looks good.

Thanks and best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Mittwoch, 17. Februar 2021 20:10
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR (XS): 8261829: Exclude
> tools/jlink/JLinkReproducibleTest.java in 11u
> 
> Hi,
> 
> please review this test exclusion for 11u.
> 
> The backport of JDK-8214230 [0] has introduced JLinkReproducibleTest which
> unfortunately fails randomly in 11u due to the absence of JEP 341: Default
> CDS Archives [1]. This was analyzed in bug report JDK-8258945 [2]. Since I
> assume we don't want to backport default CDS archives to 11u, we should
> find another solution to fix this test (if possible). For the time being the test
> should be excluded.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8261829
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8261829.11u/
> 
> Thanks
> Christoph
> 
> [0] https://bugs.openjdk.java.net/browse/JDK-8214230
> [1] https://bugs.openjdk.java.net/browse/JDK-8204247
> [2] https://bugs.openjdk.java.net/browse/JDK-8258945


From martin.doerr at sap.com  Thu Feb 18 10:15:08 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 18 Feb 2021 10:15:08 +0000
Subject: [11u] RFR (XS): 8261753: Test java/lang/System/OsVersionTest.java
 still failing on BigSur patch versions after JDK-8253702
In-Reply-To: <AM4PR02MB3138C9B7759134E725D5674C8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138C9B7759134E725D5674C8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057AC769A35164BEA10700B9A859@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Christoph,

backport looks good.
Note that the Copyright shouldn't have the 2nd comma, but I guess we don't need to fix that during backports.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Langer, Christoph
> Sent: Mittwoch, 17. Februar 2021 19:59
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR (XS): 8261753: Test
> java/lang/System/OsVersionTest.java still failing on BigSur patch versions
> after JDK-8253702
> 
> Hi,
> 
> please review the backport of this test fix. I requested backport of JDK-
> 8253702 already which applies clean. However, when building on Mac with
> Xcode <12 and running on MacOS versions that have a patch version number
> (>0), OsVersionTest is still bound to fail.
> 
> I had to do a minor context adaption in the test imports.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8261753
> Original Change: https://git.openjdk.java.net/jdk/commit/8ba390d1
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8261753.11u/
> 
> Thanks
> Christoph


From christoph.langer at sap.com  Thu Feb 18 10:24:39 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 18 Feb 2021 10:24:39 +0000
Subject: [11u] RFR (XS): 8261829: Exclude
 tools/jlink/JLinkReproducibleTest.java in 11u
In-Reply-To: <AM4PR02MB30571F4C544A95A78019D4819A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138F6F40C1E920A27A3EA598A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB30571F4C544A95A78019D4819A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB31385A3564A86398C0191AE38A859@AM4PR02MB3138.eurprd02.prod.outlook.com>

Thanks, Martin!

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Donnerstag, 18. Februar 2021 11:07
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR (XS): 8261829: Exclude
> tools/jlink/JLinkReproducibleTest.java in 11u
> 
> Hi Christoph,
> 
> I think this makes sense. Looks good.
> 
> Thanks and best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Langer, Christoph
> > Sent: Mittwoch, 17. Februar 2021 20:10
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR (XS): 8261829: Exclude
> > tools/jlink/JLinkReproducibleTest.java in 11u
> >
> > Hi,
> >
> > please review this test exclusion for 11u.
> >
> > The backport of JDK-8214230 [0] has introduced JLinkReproducibleTest
> which
> > unfortunately fails randomly in 11u due to the absence of JEP 341: Default
> > CDS Archives [1]. This was analyzed in bug report JDK-8258945 [2]. Since I
> > assume we don't want to backport default CDS archives to 11u, we should
> > find another solution to fix this test (if possible). For the time being the test
> > should be excluded.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8261829
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8261829.11u/
> >
> > Thanks
> > Christoph
> >
> > [0] https://bugs.openjdk.java.net/browse/JDK-8214230
> > [1] https://bugs.openjdk.java.net/browse/JDK-8204247
> > [2] https://bugs.openjdk.java.net/browse/JDK-8258945


From christoph.langer at sap.com  Thu Feb 18 10:26:33 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 18 Feb 2021 10:26:33 +0000
Subject: [11u] RFR (XS): 8261753: Test java/lang/System/OsVersionTest.java
 still failing on BigSur patch versions after JDK-8253702
In-Reply-To: <AM4PR02MB3057AC769A35164BEA10700B9A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB3138C9B7759134E725D5674C8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <AM4PR02MB3057AC769A35164BEA10700B9A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138AC66FCB8E5BB500752498A859@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Martin,

thanks for the review and the hint regarding copyright. I forgot that the SAP copyright line differs in format to the Oracle copyright. I'll fix that in a separate change (and backport accordingly).

Cheers
Christoph

> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Donnerstag, 18. Februar 2021 11:15
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: RE: [11u] RFR (XS): 8261753: Test
> java/lang/System/OsVersionTest.java still failing on BigSur patch versions
> after JDK-8253702
> 
> Hi Christoph,
> 
> backport looks good.
> Note that the Copyright shouldn't have the 2nd comma, but I guess we don't
> need to fix that during backports.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Langer, Christoph
> > Sent: Mittwoch, 17. Februar 2021 19:59
> > To: jdk-updates-dev at openjdk.java.net
> > Subject: [11u] RFR (XS): 8261753: Test
> > java/lang/System/OsVersionTest.java still failing on BigSur patch versions
> > after JDK-8253702
> >
> > Hi,
> >
> > please review the backport of this test fix. I requested backport of JDK-
> > 8253702 already which applies clean. However, when building on Mac with
> > Xcode <12 and running on MacOS versions that have a patch version
> number
> > (>0), OsVersionTest is still bound to fail.
> >
> > I had to do a minor context adaption in the test imports.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8261753
> > Original Change: https://git.openjdk.java.net/jdk/commit/8ba390d1
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8261753.11u/
> >
> > Thanks
> > Christoph


From martin.doerr at sap.com  Thu Feb 18 11:11:19 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 18 Feb 2021 11:11:19 +0000
Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore
Message-ID: <AM4PR02MB30573DF6D46B67BFD89710459A859@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

JDK-8256421 is backported to 11.0.11-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

I'm using the jdk16u backport. See "Fix Request (jdk16u)" comment.

VerifyCACerts.java:
I had to change the COUNT manually:
-    private static final int COUNT = 95;
+    private static final int COUNT = 97;
And I've computed the new CHECKSUM which gets verified by the test:
shasum -a 256 jdk/lib/security/cacerts | sed -e 's/../&:/g' | tr '[:lower:]' '[:upper:]' | cut -c1-95
9F:6B:41:1D:05:AF:E3:C5:4F:E8:39:89:50:79:60:B1:F6:A4:02:40:0C:28:8D:73:78:08:E5:61:7C:17:EA:59

Bug:
https://bugs.openjdk.java.net/browse/JDK-8256421

Original change (from 16u):
https://github.com/openjdk/jdk16u/commit/4ccaf6b8

11u backport:
http://cr.openjdk.java.net/~mdoerr/8256421_HARICA_cacerts_11u/webrev.00/

Please review.

Best regards,
Martin


From christoph.langer at sap.com  Thu Feb 18 13:11:15 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 18 Feb 2021 13:11:15 +0000
Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore
In-Reply-To: <AM4PR02MB30573DF6D46B67BFD89710459A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB30573DF6D46B67BFD89710459A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138471FC7CEC8797D86C6618A859@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Martin,

this backport looks good to me.

Best regards
Christoph

From: Doerr, Martin <martin.doerr at sap.com>
Sent: Donnerstag, 18. Februar 2021 12:11
To: security-dev <security-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Langer, Christoph <christoph.langer at sap.com>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore

Hi,

JDK-8256421 is backported to 11.0.11-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

I'm using the jdk16u backport. See "Fix Request (jdk16u)" comment.

VerifyCACerts.java:
I had to change the COUNT manually:
-    private static final int COUNT = 95;
+    private static final int COUNT = 97;
And I've computed the new CHECKSUM which gets verified by the test:
shasum -a 256 jdk/lib/security/cacerts | sed -e 's/../&:/g' | tr '[:lower:]' '[:upper:]' | cut -c1-95
9F:6B:41:1D:05:AF:E3:C5:4F:E8:39:89:50:79:60:B1:F6:A4:02:40:0C:28:8D:73:78:08:E5:61:7C:17:EA:59

Bug:
https://bugs.openjdk.java.net/browse/JDK-8256421

Original change (from 16u):
https://github.com/openjdk/jdk16u/commit/4ccaf6b8

11u backport:
http://cr.openjdk.java.net/~mdoerr/8256421_HARICA_cacerts_11u/webrev.00/

Please review.

Best regards,
Martin


From martin.doerr at sap.com  Thu Feb 18 13:47:12 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Thu, 18 Feb 2021 13:47:12 +0000
Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore
In-Reply-To: <AM4PR02MB3138471FC7CEC8797D86C6618A859@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB30573DF6D46B67BFD89710459A859@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM4PR02MB3138471FC7CEC8797D86C6618A859@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057AEB3DC324CF8AC0CCF1B9A859@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi Christoph,

thanks for the review and the approval!

Best regards,
Martin


From: Langer, Christoph <christoph.langer at sap.com>
Sent: Donnerstag, 18. Februar 2021 14:11
To: Doerr, Martin <martin.doerr at sap.com>; security-dev <security-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
Subject: RE: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore

Hi Martin,

this backport looks good to me.

Best regards
Christoph

From: Doerr, Martin <martin.doerr at sap.com<mailto:martin.doerr at sap.com>>
Sent: Donnerstag, 18. Februar 2021 12:11
To: security-dev <security-dev at openjdk.java.net<mailto:security-dev at openjdk.java.net>>; jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
Cc: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Lindenmaier, Goetz <goetz.lindenmaier at sap.com<mailto:goetz.lindenmaier at sap.com>>
Subject: [11u] RFR: 8256421: Add 2 HARICA roots to cacerts truststore

Hi,

JDK-8256421 is backported to 11.0.11-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

I'm using the jdk16u backport. See "Fix Request (jdk16u)" comment.

VerifyCACerts.java:
I had to change the COUNT manually:
-    private static final int COUNT = 95;
+    private static final int COUNT = 97;
And I've computed the new CHECKSUM which gets verified by the test:
shasum -a 256 jdk/lib/security/cacerts | sed -e 's/../&:/g' | tr '[:lower:]' '[:upper:]' | cut -c1-95
9F:6B:41:1D:05:AF:E3:C5:4F:E8:39:89:50:79:60:B1:F6:A4:02:40:0C:28:8D:73:78:08:E5:61:7C:17:EA:59

Bug:
https://bugs.openjdk.java.net/browse/JDK-8256421

Original change (from 16u):
https://github.com/openjdk/jdk16u/commit/4ccaf6b8

11u backport:
http://cr.openjdk.java.net/~mdoerr/8256421_HARICA_cacerts_11u/webrev.00/

Please review.

Best regards,
Martin


From gnu.andrew at redhat.com  Fri Feb 19 05:18:41 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 19 Feb 2021 05:18:41 +0000
Subject: [11u] Make use of DEFAULT_PROMOTED_VERSION_PRE
Message-ID: <20210219051841.GB781755@rincewind>

It seems that the addition of DEFAULT_PROMOTED_VERSION_PRE
was backported to 11u for 11.0.7:

https://bugs.openjdk.java.net/browse/JDK-8223464
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002302.html

However, the value does not seem to have been updated since.

Should this not be set to the empty string when the jdk11
tree is tagged with a *-ga release?

This is what was done recently for the RC of OpenJDK 16:

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

Thanks,
-- 
Andrew :)

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

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

From hedongbo at huawei.com  Fri Feb 19 07:56:57 2021
From: hedongbo at huawei.com (hedongbo)
Date: Fri, 19 Feb 2021 07:56:57 +0000
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel
Message-ID: <8FC616E5EC1A774287430B1CC2696FE30476B3DC@dggeml513-mbs.china.huawei.com>

Gentle Ping :-)

From: hedongbo
Sent: Tuesday, February 9, 2021 9:18 AM
To: jdk-updates-dev at openjdk.java.net
Subject: FW: [11u] RFR:8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel

Ping?

From: hedongbo
Sent: Wednesday, February 3, 2021 5:16 PM
To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel


Hi,



Please review the backport of JDK-8246707 to 11u:



Bug: https://bugs.openjdk.java.net/browse/JDK-8246707

Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c8c6030e4d1f

11u webrev: http://cr.openjdk.java.net/~dongbohe/8246707/webrev.00/



This patch doesn't apply cleanly but is fairly trivial. The reason is that the latest jdk11u-dev has no ` blockingRead ` and `blockingWriteFully` function, because they were added in jdk13 through JDK-8222774.




Tested with tier1, tier2. No regression in tests.






Thanks,
dongbohe


From yan at openjdk.java.net  Fri Feb 19 08:48:59 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Fri, 19 Feb 2021 08:48:59 GMT
Subject: [jdk13u-dev] RFR: 8242030: Wrong package declarations in jline
 classes after JDK-8241598
In-Reply-To: <f_nAOHnVu9Yw-OABbfDXI-ia7P4Tompg_G1YqHZfIr4=.4cd8a3e5-7330-4cd3-85f7-13aa62aa3b73@github.com>
References: <f_nAOHnVu9Yw-OABbfDXI-ia7P4Tompg_G1YqHZfIr4=.4cd8a3e5-7330-4cd3-85f7-13aa62aa3b73@github.com>
Message-ID: <yjkELn6mm_F-vjmSRM2aaL4HlZhWDK0wLfwQEL_on84=.63f484db-a6ed-4354-a97b-1b7f781cc030@github.com>

On Fri, 12 Feb 2021 17:26:51 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8242030 to 13u as follow-up fix for JDK-8241598 that is already included to 13u.
> The patch applies cleanly.
> Tested with tier1 and jshell tier2 tests.

Katya is Committer now; let see if the census is reread on every occasion... (otherwise the new status would work for the new PRs)

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/126

From evergizova at openjdk.java.net  Fri Feb 19 08:56:44 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Fri, 19 Feb 2021 08:56:44 GMT
Subject: [jdk13u-dev] Integrated: 8242030: Wrong package declarations in jline
 classes after JDK-8241598
In-Reply-To: <f_nAOHnVu9Yw-OABbfDXI-ia7P4Tompg_G1YqHZfIr4=.4cd8a3e5-7330-4cd3-85f7-13aa62aa3b73@github.com>
References: <f_nAOHnVu9Yw-OABbfDXI-ia7P4Tompg_G1YqHZfIr4=.4cd8a3e5-7330-4cd3-85f7-13aa62aa3b73@github.com>
Message-ID: <NA_ZoaNOz9O_nQ2l3IoC3duio9Di1yNjmNHUGDu6MR0=.7ec2d7ee-43e3-4713-a60a-9818bdad3847@github.com>

On Fri, 12 Feb 2021 17:26:51 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8242030 to 13u as follow-up fix for JDK-8241598 that is already included to 13u.
> The patch applies cleanly.
> Tested with tier1 and jshell tier2 tests.

This pull request has now been integrated.

Changeset: f9a04a4d
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/f9a04a4d
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8242030: Wrong package declarations in jline classes after JDK-8241598

Backport-of: 746d28d110c8b63007491560d6f5ba3a337ed9dd

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/126

From cgo at openjdk.java.net  Fri Feb 19 09:42:02 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 19 Feb 2021 09:42:02 GMT
Subject: [jdk16u] RFR: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails
 if ergonomics detect too small InitialHeapSize
Message-ID: <NHZ7ok6oMCJmcsUGcI1vcAJxk-hcVmvEJJHICSvFHmc=.082eb9da-4e52-479f-8409-67dbcbfa4a7c@github.com>

Patch applies cleanly and fixes the test in 16u. Risk should be minimal, as only a test case is changed. Without this backport, we are not able to run the hotspot tier1 JTreg test suite for aarch32 on memory constrained devices.

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

Commit messages:
 - Clean backport of JDK-8261758.

Changes: https://git.openjdk.java.net/jdk16u/pull/31/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=31&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261758
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/31/head:pull/31

PR: https://git.openjdk.java.net/jdk16u/pull/31

From sgehwolf at redhat.com  Fri Feb 19 09:43:10 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 19 Feb 2021 10:43:10 +0100
Subject: [11u] Make use of DEFAULT_PROMOTED_VERSION_PRE
In-Reply-To: <20210219051841.GB781755@rincewind>
References: <20210219051841.GB781755@rincewind>
Message-ID: <e66ea35261d4f7a17c695f5bf7526a63e6fcb551.camel@redhat.com>

Hi,

On Fri, 2021-02-19 at 05:18 +0000, Andrew Hughes wrote:
> It seems that the addition of DEFAULT_PROMOTED_VERSION_PRE
> was backported to 11u for 11.0.7:
> 
> https://bugs.openjdk.java.net/browse/JDK-8223464
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002302.html
> 
> However, the value does not seem to have been updated since.
> 
> Should this not be set to the empty string when the jdk11
> tree is tagged with a *-ga release?

Yeah it could. But is it worth doing? Even if it was done it would have
no effect on the build downstream consumers do, unless they
specifically take that value and pass it to configure.

So I'm somewhat on the fence about this as it would be yet annother
change which would needed to be done as part of the CPU patching (and
reverted once the next dev-cycle starts). A lot of churn for little
gain.

It feels like it's not really worth doing. YMMV.

Thanks,
Severin

> This is what was done recently for the RC of OpenJDK 16:
> 
> https://bugs.openjdk.java.net/browse/JDK-8259794
> 
> Thanks,


From cgo at openjdk.java.net  Fri Feb 19 09:46:44 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 19 Feb 2021 09:46:44 GMT
Subject: [jdk16u] RFR: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java
 fails if ergonomics detect too small InitialHeapSize
In-Reply-To: <NHZ7ok6oMCJmcsUGcI1vcAJxk-hcVmvEJJHICSvFHmc=.082eb9da-4e52-479f-8409-67dbcbfa4a7c@github.com>
References: <NHZ7ok6oMCJmcsUGcI1vcAJxk-hcVmvEJJHICSvFHmc=.082eb9da-4e52-479f-8409-67dbcbfa4a7c@github.com>
Message-ID: <3_EBmr32iflO-BrM9Py_J9CXVKwUuCmxEoB0wpXUAeQ=.200f992e-c865-441e-9eda-d86109c9ef6f@github.com>

On Fri, 19 Feb 2021 09:37:42 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Patch applies cleanly and fixes the test in 16u. Risk should be minimal, as only a test case is changed. Without this backport, we are not able to run the hotspot tier1 JTreg test suite for aarch32 on memory constrained devices.

Sorry, I created a normal pull request instead of a backport pull request, closing this one.

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

PR: https://git.openjdk.java.net/jdk16u/pull/31

From cgo at openjdk.java.net  Fri Feb 19 09:46:44 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 19 Feb 2021 09:46:44 GMT
Subject: [jdk16u] Withdrawn: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java
 fails if ergonomics detect too small InitialHeapSize
In-Reply-To: <NHZ7ok6oMCJmcsUGcI1vcAJxk-hcVmvEJJHICSvFHmc=.082eb9da-4e52-479f-8409-67dbcbfa4a7c@github.com>
References: <NHZ7ok6oMCJmcsUGcI1vcAJxk-hcVmvEJJHICSvFHmc=.082eb9da-4e52-479f-8409-67dbcbfa4a7c@github.com>
Message-ID: <qN7ULHN6CpeKe5oPtMTfSKN2kzpIG2Q95bdphy6rUCE=.e0f04b29-617a-47c2-830a-65c55627b415@github.com>

On Fri, 19 Feb 2021 09:37:42 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Patch applies cleanly and fixes the test in 16u. Risk should be minimal, as only a test case is changed. Without this backport, we are not able to run the hotspot tier1 JTreg test suite for aarch32 on memory constrained devices.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk16u/pull/31

From cgo at openjdk.java.net  Fri Feb 19 09:53:06 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 19 Feb 2021 09:53:06 GMT
Subject: [jdk16u] RFR: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails
 if ergonomics detect too small InitialHeapSize
Message-ID: <aLStUULoyMCKqYH6qjmSG7m0b6Mm9G3qJnVTMbYzf18=.4a633e4e-2640-453a-84b4-9e858b83df87@github.com>

8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize

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

Commit messages:
 - Clean backport of JDK-8261758.

Changes: https://git.openjdk.java.net/jdk16u/pull/32/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=32&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261758
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/32/head:pull/32

PR: https://git.openjdk.java.net/jdk16u/pull/32

From cgo at openjdk.java.net  Fri Feb 19 09:56:58 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 19 Feb 2021 09:56:58 GMT
Subject: [jdk16u] RFR: 8261752: Multiple GC test are missing memory
 requirements
Message-ID: <mS4O_srLH8jDiGbmDhtyEUiy0ZiB9m0qaVe84re1JlI=.57bf7183-81ca-4b1f-8b3c-4e1f7df92e74@github.com>

8261752: Multiple GC test are missing memory requirements

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

Commit messages:
 - Clean backport of JDK-8261752.

Changes: https://git.openjdk.java.net/jdk16u/pull/33/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=33&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261752
  Stats: 7 lines in 7 files changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/33/head:pull/33

PR: https://git.openjdk.java.net/jdk16u/pull/33

From cgo at openjdk.java.net  Fri Feb 19 11:24:45 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Fri, 19 Feb 2021 11:24:45 GMT
Subject: [jdk16u] RFR: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java
 fails if ergonomics detect too small InitialHeapSize
In-Reply-To: <aLStUULoyMCKqYH6qjmSG7m0b6Mm9G3qJnVTMbYzf18=.4a633e4e-2640-453a-84b4-9e858b83df87@github.com>
References: <aLStUULoyMCKqYH6qjmSG7m0b6Mm9G3qJnVTMbYzf18=.4a633e4e-2640-453a-84b4-9e858b83df87@github.com>
Message-ID: <GMtJHRkFj0GJQ31-m5HIy7lyEGEzuUQOVzHytiifsEY=.107d2988-3c2b-488d-8cc6-49683de1fa16@github.com>

On Fri, 19 Feb 2021 09:46:23 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize

Am I actually supposed to open the pull request on the jdk16u repository, or on [jdk16](https://github.com/openjdk/jdk16)?

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

PR: https://git.openjdk.java.net/jdk16u/pull/32

From clanger at openjdk.java.net  Fri Feb 19 12:34:08 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 19 Feb 2021 12:34:08 GMT
Subject: [jdk16u] Integrated: 8261022: Fix incorrect result of Math.abs() with
 char type
Message-ID: <kKqYg9Ckpe69vZa9iTOql4elWJEHdY_s38LK722MWlw=.c0966d85-733b-4d70-babf-180d0d3cbe66@github.com>

Backport JDK-8261022

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

Commit messages:
 - Backport 7a2db858e0e81f2ba17c3554386bb6a833318b3d

Changes: https://git.openjdk.java.net/jdk16u/pull/34/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=34&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261022
  Stats: 77 lines in 2 files changed: 66 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/34.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/34/head:pull/34

PR: https://git.openjdk.java.net/jdk16u/pull/34

From clanger at openjdk.java.net  Fri Feb 19 12:34:10 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 19 Feb 2021 12:34:10 GMT
Subject: [jdk16u] Integrated: 8261022: Fix incorrect result of Math.abs() with
 char type
In-Reply-To: <kKqYg9Ckpe69vZa9iTOql4elWJEHdY_s38LK722MWlw=.c0966d85-733b-4d70-babf-180d0d3cbe66@github.com>
References: <kKqYg9Ckpe69vZa9iTOql4elWJEHdY_s38LK722MWlw=.c0966d85-733b-4d70-babf-180d0d3cbe66@github.com>
Message-ID: <9UgytxzByNWpZiQCTmzCr6Raafl3ZYbscoklsPivmj8=.50e111bc-dced-452a-b657-65b28a7881b8@github.com>

On Fri, 19 Feb 2021 12:27:12 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Backport JDK-8261022

This pull request has now been integrated.

Changeset: 9d0adb8b
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/9d0adb8b
Stats:     77 lines in 2 files changed: 66 ins; 1 del; 10 mod

8261022: Fix incorrect result of Math.abs() with char type

Backport-of: 7a2db858e0e81f2ba17c3554386bb6a833318b3d

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

PR: https://git.openjdk.java.net/jdk16u/pull/34

From christoph.langer at sap.com  Fri Feb 19 12:55:34 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 19 Feb 2021 12:55:34 +0000
Subject: [11u] Make use of DEFAULT_PROMOTED_VERSION_PRE
In-Reply-To: <e66ea35261d4f7a17c695f5bf7526a63e6fcb551.camel@redhat.com>
References: <20210219051841.GB781755@rincewind>
 <e66ea35261d4f7a17c695f5bf7526a63e6fcb551.camel@redhat.com>
Message-ID: <AM4PR02MB3138E21EDFB95030396690F18A849@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi,

it looks like "DEFAULT_PROMOTED_VERSION_PRE=ea" is used in head openjdk/jdk and in the beginning when a release is branched into a separate repository. At the point when the branch is marked as release candidate, it's set to an empty value. For update releases it always empty as well (compare with jdk15u, jdk16u...). So no flipping upon ga tags.

To match this pattern in 11u, we should have "DEFAULT_PROMOTED_VERSION_PRE=". OTOH, I don't think this change will have a lot of effect to downstream consumers as they would set the version_pre value via configure anyway. But I'd welcome if we would align this. Would you mind to do this, Andrew?

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Severin Gehwolf
> Sent: Freitag, 19. Februar 2021 10:43
> To: Andrew Hughes <gnu.andrew at redhat.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] Make use of DEFAULT_PROMOTED_VERSION_PRE
> 
> Hi,
> 
> On Fri, 2021-02-19 at 05:18 +0000, Andrew Hughes wrote:
> > It seems that the addition of DEFAULT_PROMOTED_VERSION_PRE
> > was backported to 11u for 11.0.7:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8223464
> > https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-
> December/002302.html
> >
> > However, the value does not seem to have been updated since.
> >
> > Should this not be set to the empty string when the jdk11
> > tree is tagged with a *-ga release?
> 
> Yeah it could. But is it worth doing? Even if it was done it would have
> no effect on the build downstream consumers do, unless they
> specifically take that value and pass it to configure.
> 
> So I'm somewhat on the fence about this as it would be yet annother
> change which would needed to be done as part of the CPU patching (and
> reverted once the next dev-cycle starts). A lot of churn for little
> gain.
> 
> It feels like it's not really worth doing. YMMV.
> 
> Thanks,
> Severin
> 
> > This is what was done recently for the RC of OpenJDK 16:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8259794
> >
> > Thanks,


From omikhaltcova at openjdk.java.net  Fri Feb 19 14:34:00 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 19 Feb 2021 14:34:00 GMT
Subject: [jdk13u-dev] RFR: 8245801: StressRecompilation triggers assert
 "redundunt OSR recompilation detected. memory leak in CodeCache!"
Message-ID: <LskNRU0zv5YFhWOedj9n0YDDyHKzLzes2w5tBfSj5I0=.7cefd2af-820f-4842-b64c-d7b5930d760b@github.com>

I'd like to backport JDK-8245801 to jdk13u for parity with jdk11u.
The original patch applied cleanly.
All regular tests passed.

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

Commit messages:
 - Backport 76ac62139463f1cbdb6029118b79cf8458861863

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/128/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=128&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245801
  Stats: 43 lines in 2 files changed: 40 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/128.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/128/head:pull/128

PR: https://git.openjdk.java.net/jdk13u-dev/pull/128

From omikhaltcova at openjdk.java.net  Fri Feb 19 15:47:47 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 19 Feb 2021 15:47:47 GMT
Subject: [jdk13u-dev] Integrated: 8245801: StressRecompilation triggers assert
 "redundunt OSR recompilation detected. memory leak in CodeCache!"
In-Reply-To: <LskNRU0zv5YFhWOedj9n0YDDyHKzLzes2w5tBfSj5I0=.7cefd2af-820f-4842-b64c-d7b5930d760b@github.com>
References: <LskNRU0zv5YFhWOedj9n0YDDyHKzLzes2w5tBfSj5I0=.7cefd2af-820f-4842-b64c-d7b5930d760b@github.com>
Message-ID: <avPDq6aToARtgdJAz2QOjWIeMI_he6TVGE2vEDdD4is=.79c63256-b152-4614-aede-6a4c0c6b65d8@github.com>

On Fri, 19 Feb 2021 14:27:56 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8245801 to jdk13u for parity with jdk11u.
> The original patch applied cleanly.
> All regular tests passed.

This pull request has now been integrated.

Changeset: 93aca5fb
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/93aca5fb
Stats:     43 lines in 2 files changed: 40 ins; 0 del; 3 mod

8245801: StressRecompilation triggers assert "redundunt OSR recompilation detected. memory leak in CodeCache!"

Assert is too strong.

Backport-of: 76ac62139463f1cbdb6029118b79cf8458861863

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/128

From clanger at openjdk.java.net  Fri Feb 19 18:16:13 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 19 Feb 2021 18:16:13 GMT
Subject: [jdk16u] RFR: 8253702: BigSur version number reported as 10.16,
 should be 11.nn
Message-ID: <V0e4qQ_BXuuR-cPV3vqebndZnW4h_vckPZLq5TrS2D0=.b19723b0-847a-4a58-a809-4862b02bff1a@github.com>

Backport JDK-8253702

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

Commit messages:
 - Backport 66757750a2adf0739d0f5bf98a3f50a123b7adcf

Changes: https://git.openjdk.java.net/jdk16u/pull/35/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=35&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253702
  Stats: 30 lines in 1 file changed: 22 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/35.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/35/head:pull/35

PR: https://git.openjdk.java.net/jdk16u/pull/35

From clanger at openjdk.java.net  Fri Feb 19 18:21:54 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 19 Feb 2021 18:21:54 GMT
Subject: [jdk16u] Integrated: 8253702: BigSur version number reported as 10.16,
 should be 11.nn
In-Reply-To: <V0e4qQ_BXuuR-cPV3vqebndZnW4h_vckPZLq5TrS2D0=.b19723b0-847a-4a58-a809-4862b02bff1a@github.com>
References: <V0e4qQ_BXuuR-cPV3vqebndZnW4h_vckPZLq5TrS2D0=.b19723b0-847a-4a58-a809-4862b02bff1a@github.com>
Message-ID: <SrRpVWeoOvuJkCOgVJ2aHb4IqYgTasuGI0a68XfrY7I=.502ba021-6a15-40e5-a84c-54111a13b2c0@github.com>

On Fri, 19 Feb 2021 18:10:26 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Backport JDK-8253702

This pull request has now been integrated.

Changeset: c7275282
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/c7275282
Stats:     30 lines in 1 file changed: 22 ins; 2 del; 6 mod

8253702: BigSur version number reported as 10.16, should be 11.nn

Backport-of: 66757750a2adf0739d0f5bf98a3f50a123b7adcf

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

PR: https://git.openjdk.java.net/jdk16u/pull/35

From clanger at openjdk.java.net  Fri Feb 19 18:28:02 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 19 Feb 2021 18:28:02 GMT
Subject: [jdk16u] Integrated: 8261753: Test
 java/lang/System/OsVersionTest.java still failing on BigSur patch versions
 after JDK-8253702
Message-ID: <HBWA6Cb1S0XHOWR7JFMfL6W7AXVXHFk3mCYbMwy-xNY=.e83a51f6-3df3-433a-aa5d-1981abd789bb@github.com>

Backport of JDK-8261753

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

Commit messages:
 - Backport 8ba390d1e243c5ec2e637263fa44907b664e8ceb

Changes: https://git.openjdk.java.net/jdk16u/pull/36/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=36&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261753
  Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/36.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/36/head:pull/36

PR: https://git.openjdk.java.net/jdk16u/pull/36

From clanger at openjdk.java.net  Fri Feb 19 18:28:02 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 19 Feb 2021 18:28:02 GMT
Subject: [jdk16u] Integrated: 8261753: Test
 java/lang/System/OsVersionTest.java still failing on BigSur patch versions
 after JDK-8253702
In-Reply-To: <HBWA6Cb1S0XHOWR7JFMfL6W7AXVXHFk3mCYbMwy-xNY=.e83a51f6-3df3-433a-aa5d-1981abd789bb@github.com>
References: <HBWA6Cb1S0XHOWR7JFMfL6W7AXVXHFk3mCYbMwy-xNY=.e83a51f6-3df3-433a-aa5d-1981abd789bb@github.com>
Message-ID: <T84nUBvmmRGaheaxRFXO7_tYJzYrdCbYYJUFgm-rTqA=.72631ae0-402f-44ca-b683-13813ae40aef@github.com>

On Fri, 19 Feb 2021 18:22:10 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Backport of JDK-8261753

This pull request has now been integrated.

Changeset: 1bed23ac
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/1bed23ac
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8261753: Test java/lang/System/OsVersionTest.java still failing on BigSur patch versions after JDK-8253702

Backport-of: 8ba390d1e243c5ec2e637263fa44907b664e8ceb

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

PR: https://git.openjdk.java.net/jdk16u/pull/36

From christoph.langer at sap.com  Fri Feb 19 18:51:31 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 19 Feb 2021 18:51:31 +0000
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel
In-Reply-To: <8FC616E5EC1A774287430B1CC2696FE30476B3DC@dggeml513-mbs.china.huawei.com>
References: <8FC616E5EC1A774287430B1CC2696FE30476B3DC@dggeml513-mbs.china.huawei.com>
Message-ID: <AM4PR02MB31385D539C7C629278296F248A849@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Dongbohe,

this backport looks good to me. I'll run it once again through SAP's regression testing. In case you don't hear from me by next Monday, you can consider it as reviewed.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of hedongbo
> Sent: Freitag, 19. Februar 2021 08:57
> To: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
> AsynchronousCloseException on closed channel
> 
> Gentle Ping :-)
> 
> From: hedongbo
> Sent: Tuesday, February 9, 2021 9:18 AM
> To: jdk-updates-dev at openjdk.java.net
> Subject: FW: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
> AsynchronousCloseException on closed channel
> 
> Ping?
> 
> From: hedongbo
> Sent: Wednesday, February 3, 2021 5:16 PM
> To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-
> dev at openjdk.java.net>
> Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
> AsynchronousCloseException on closed channel
> 
> 
> Hi,
> 
> 
> 
> Please review the backport of JDK-8246707 to 11u:
> 
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246707
> 
> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c8c6030e4d1f
> 
> 11u webrev: http://cr.openjdk.java.net/~dongbohe/8246707/webrev.00/
> 
> 
> 
> This patch doesn't apply cleanly but is fairly trivial. The reason is that the
> latest jdk11u-dev has no ` blockingRead ` and `blockingWriteFully` function,
> because they were added in jdk13 through JDK-8222774.
> 
> 
> 
> 
> Tested with tier1, tier2. No regression in tests.
> 
> 
> 
> 
> 
> 
> Thanks,
> dongbohe


From omikhaltcova at openjdk.java.net  Fri Feb 19 22:18:54 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 19 Feb 2021 22:18:54 GMT
Subject: [jdk13u-dev] RFR: 8246027: Minimal fastdebug build broken after
 JDK-8245801
Message-ID: <-OkhLQGlTcZCpYRxfkOkA9uKN4bUV7WhtA321Uy3Z4A=.04af19d2-4324-4dbd-b3cb-0dcf380dc64e@github.com>

I'd like to backport JDK-8246027 to jdk13u for parity with jdk11u.
The original patch applied cleanly.
All regular tests passed.

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

Commit messages:
 - Backport dfc7905a10ab89609fef8fa2457577d830b53efa

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/129

From erikj at openjdk.java.net  Fri Feb 19 22:50:47 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 19 Feb 2021 22:50:47 GMT
Subject: [jdk16u] Integrated: 8261261: The version extra fields needs to be
 overridable in jib-profiles.js
In-Reply-To: <IM7Q_Hf88jNqE51FvsS0Q9NrT-kC5T5mVRt5gWpohTg=.044b4fc4-08c1-49c7-98ef-2ed18b566c5c@github.com>
References: <IM7Q_Hf88jNqE51FvsS0Q9NrT-kC5T5mVRt5gWpohTg=.044b4fc4-08c1-49c7-98ef-2ed18b566c5c@github.com>
Message-ID: <2psQ6Maoxd4z0sD7nIa0qy5313sXMX9ovLUO3DyfqV4=.1f42a9f2-2ea8-4d95-b552-b222b0c0199e@github.com>

On Wed, 17 Feb 2021 23:38:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> 8261261: The version extra fields needs to be overridable in jib-profiles.js

This pull request has now been integrated.

Changeset: cdeef37a
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/cdeef37a
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8261261: The version extra fields needs to be overridable in jib-profiles.js

Reviewed-by: mikael
Backport-of: ab65d53edf926235231e94dcefe94becf7545d81

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

PR: https://git.openjdk.java.net/jdk16u/pull/30

From omikhaltcova at openjdk.java.net  Sat Feb 20 07:16:55 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Sat, 20 Feb 2021 07:16:55 GMT
Subject: [jdk13u-dev] Integrated: 8246027: Minimal fastdebug build broken
 after JDK-8245801
In-Reply-To: <-OkhLQGlTcZCpYRxfkOkA9uKN4bUV7WhtA321Uy3Z4A=.04af19d2-4324-4dbd-b3cb-0dcf380dc64e@github.com>
References: <-OkhLQGlTcZCpYRxfkOkA9uKN4bUV7WhtA321Uy3Z4A=.04af19d2-4324-4dbd-b3cb-0dcf380dc64e@github.com>
Message-ID: <IfP28JUqyywbLWx6T6ZcdGTdLVmcDXmnJqCucAbzBZQ=.986e2938-4f81-470e-8e13-97e622cb7a79@github.com>

On Fri, 19 Feb 2021 22:10:18 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8246027 to jdk13u for parity with jdk11u.
> The original patch applied cleanly.
> All regular tests passed.

This pull request has now been integrated.

Changeset: 72d9bf55
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/72d9bf55
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8246027: Minimal fastdebug build broken after JDK-8245801

Added COMPILER2_PRESENT macro

Backport-of: dfc7905a10ab89609fef8fa2457577d830b53efa

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/129

From yan at openjdk.java.net  Sat Feb 20 12:42:56 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Sat, 20 Feb 2021 12:42:56 GMT
Subject: [jdk13u-dev] RFR: 8243559: Remove root certificates with 1024-bit keys
Message-ID: <Y60Q9whwdJVP6WR6mYulBMmDPe4WGyKYK3OxNP56rjk=.931b93a7-c430-47cd-b2ae-5d90fb6a9fb3@github.com>

I'd like to port this fix to 13u, too. Applied clean, all relevant tests run as expected.

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

Commit messages:
 - Backport dbfeb90d3a50b6bb0966e44164e6cf199e34cf47

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/130/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=130&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8243559
  Stats: 137 lines in 6 files changed: 1 ins; 134 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/130.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/130/head:pull/130

PR: https://git.openjdk.java.net/jdk13u-dev/pull/130

From bae at openjdk.java.net  Sat Feb 20 12:56:43 2021
From: bae at openjdk.java.net (Andrew Brygin)
Date: Sat, 20 Feb 2021 12:56:43 GMT
Subject: [jdk13u-dev] RFR: 8243559: Remove root certificates with 1024-bit
 keys
In-Reply-To: <Y60Q9whwdJVP6WR6mYulBMmDPe4WGyKYK3OxNP56rjk=.931b93a7-c430-47cd-b2ae-5d90fb6a9fb3@github.com>
References: <Y60Q9whwdJVP6WR6mYulBMmDPe4WGyKYK3OxNP56rjk=.931b93a7-c430-47cd-b2ae-5d90fb6a9fb3@github.com>
Message-ID: <sQbuEMbGyaRk1CoCzcFO3IsOObyY1i7dQV5VFbxULGA=.fbf53164-d45e-4e8e-aeac-c316ed93507f@github.com>

On Sat, 20 Feb 2021 12:38:50 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I'd like to port this fix to 13u, too. Applied clean, all relevant tests run as expected.

The change looks fine to me.

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

Marked as reviewed by bae (Reviewer).

PR: https://git.openjdk.java.net/jdk13u-dev/pull/130

From ge.guo at huawei.com  Sun Feb 21 09:33:44 2021
From: ge.guo at huawei.com (Guoge(JVM))
Date: Sun, 21 Feb 2021 09:33:44 +0000
Subject: [11u] RFR: 8240353: AArch64: missing support for
 -XX:+ExtendedDTraceProbes in C1
Message-ID: <5161f937268b42fb8c548c56576e9ad6@huawei.com>

Hi,

I would like to request a review for backport of JDK-8240353.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8240353
webrev for 11u: http://cr.openjdk.java.net/~gguo/8240353-11u/webrev.00/

The fix is trivial and clean, performed full jtreg test with aarch64 release/fastdebug build.

Thanks,
Guo Ge

From ramanand.patil at in.ibm.com  Mon Feb 22 06:02:45 2021
From: ramanand.patil at in.ibm.com (Ramanand Patil)
Date: Mon, 22 Feb 2021 06:02:45 +0000
Subject: [11u] RFR: JDK-8247753: UIManager.getSytemLookAndFeelClassName()
 returns wrong value on Fedora 32
In-Reply-To: <OF69AE76A8.0527445A-ON00258673.001B269E-00258673.001B26A5@LocalDomain>
References: <OF69AE76A8.0527445A-ON00258673.001B269E-00258673.001B26A5@LocalDomain>
Message-ID: <OF277C6B4D.8492A031-ON00258684.001F70C6-00258684.0021364C@notes.na.collabserv.com>

Hi all,
Request you to review this trivial patch.

Regards,
Ramanand.

-----Ramanand Patil/India/IBM wrote: -----
To: jdk-updates-dev at openjdk.java.net
From: Ramanand Patil/India/IBM
Date: 02/05/2021 10:26AM
Subject: [11u] RFR: JDK-8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32

Hi all,
Please review the JDK11u backport of JDK-8247753: UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
Bug Link: https://bugs.openjdk.java.net/browse/JDK-8247753
Webrev: http://cr.openjdk.java.net/~rpatil/8247753/webrev.00/
JDK-16 Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/97a5fd3612ef
The patch was not applied cleanly from JDK16 to JDK11u as the check for the environmental variables "GNOME_DESKTOP_SESSION_ID" and "XDG_CURRENT_DESKTOP" is done in native code (unix/native/libjava/java_props_md.c) in jdk11u.
The test case is taken from the latest jdk repo by ignoring the changes done to the test via "JDK-8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports".
Testing is mainly done on Ubuntu(18.04) and Fedora(version 32 and 33) and is a pass.

Note:
- I am actually resending this mail as it was not delivered earlier.
- Copyright year will be updated before push or if there are any other revisions to the patch.

Regards,
Ramanand.


From aph at redhat.com  Mon Feb 22 10:06:02 2021
From: aph at redhat.com (Andrew Haley)
Date: Mon, 22 Feb 2021 10:06:02 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com>

On 17/02/2021 21:46, Langer, Christoph wrote:
> collecting the responses in this mail thread so far, I hear that we're about to reach some kind of consensus with regards to a git switch of JDK11u. ??
> 
> If nobody objects, I will go ahead now and approach the Skara team to concretely discuss the envisioned switch for the 11.0.13 cycle.
> 
> I'll seek to get answers to some open questions:
> - How do Merge PRs work?
> - Will "git bundle" work for the CPU process?
> - What about "git backport" and the "/backport" command in github?
> - What's the status of "clean" backports?

That seems like a reasonable list. We need to be sure that OpenJDK
Jira and the mailing lists don't miss anything important. Right now
we have a log in Jira of the issue being raised, when it gets approved
for backport and by whom, and when it gets committed.

-- 
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 clanger at openjdk.java.net  Mon Feb 22 10:20:08 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 22 Feb 2021 10:20:08 GMT
Subject: [jdk16u] RFR: 8262018: Wrong format in SAP copyright header of
 OsVersionTest
Message-ID: <9R75-5FEtHms0fyBdtyJ6bgLEHdaS4F2lWJLNblTBxc=.08f074c2-7d5c-4234-b920-6191b01f0c15@github.com>

Wrong format in SAP copyright header of OsVersionTest

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

Commit messages:
 - Backport efbaedeb815d7913bdef6fe19a798ed4b83d58e7

Changes: https://git.openjdk.java.net/jdk16u/pull/37/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=37&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262018
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk16u/pull/37

From christoph.langer at sap.com  Mon Feb 22 10:29:57 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Feb 2021 10:29:57 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com>
Message-ID: <VI1PR02MB31491F03B439DA22D1D575178A819@VI1PR02MB3149.eurprd02.prod.outlook.com>

Hi,

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Montag, 22. Februar 2021 11:06
> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> dev at openjdk.java.net
> Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Severin Gehwolf <sgehwolf at redhat.com>
> Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> 11.0.13 cycle
> 
> On 17/02/2021 21:46, Langer, Christoph wrote:
> > collecting the responses in this mail thread so far, I hear that we're about to
> reach some kind of consensus with regards to a git switch of JDK11u. ??
> >
> > If nobody objects, I will go ahead now and approach the Skara team to
> concretely discuss the envisioned switch for the 11.0.13 cycle.
> >
> > I'll seek to get answers to some open questions:
> > - How do Merge PRs work?
> > - Will "git bundle" work for the CPU process?
> > - What about "git backport" and the "/backport" command in github?
> > - What's the status of "clean" backports?
> 
> That seems like a reasonable list. We need to be sure that OpenJDK
> Jira and the mailing lists don't miss anything important. Right now
> we have a log in Jira of the issue being raised, when it gets approved
> for backport and by whom, and when it gets committed.

Thanks for the feedback. The points you made here seem to be covered as far as my experiences with Skara backports go, e.g. in 16u. So the approval process will still be handled using the appropriate Jira labels and backport bug items will be created and/or updated by the Skara bots in a way that pretty much resembles what hgupdater has done before.

Cheers
Christoph


From clanger at openjdk.java.net  Mon Feb 22 11:27:45 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 22 Feb 2021 11:27:45 GMT
Subject: [jdk16u] Integrated: 8262018: Wrong format in SAP copyright header of
 OsVersionTest
In-Reply-To: <9R75-5FEtHms0fyBdtyJ6bgLEHdaS4F2lWJLNblTBxc=.08f074c2-7d5c-4234-b920-6191b01f0c15@github.com>
References: <9R75-5FEtHms0fyBdtyJ6bgLEHdaS4F2lWJLNblTBxc=.08f074c2-7d5c-4234-b920-6191b01f0c15@github.com>
Message-ID: <fNaTTGYkA6W8xlA3k5s0RhtZjjZiya1_hpJjSqwN3MQ=.bc31ce17-f57e-4c1e-819e-4ac0d048fa80@github.com>

On Mon, 22 Feb 2021 10:13:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Wrong format in SAP copyright header of OsVersionTest

This pull request has now been integrated.

Changeset: 1dcf54f1
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/1dcf54f1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8262018: Wrong format in SAP copyright header of OsVersionTest

Backport-of: efbaedeb815d7913bdef6fe19a798ed4b83d58e7

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

PR: https://git.openjdk.java.net/jdk16u/pull/37

From akashche at redhat.com  Mon Feb 22 12:17:21 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 22 Feb 2021 12:17:21 +0000
Subject: [11u] RFR: 8213116:
 javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java
 fails in Windows
Message-ID: <CABUxsJ1Cq=DZFPGD8iZPF_dUrEcV2EnWb6SS4qB3ByL0rw-9cQ@mail.gmail.com>

Hi,

Please review the backport of JDK-8213116 to 11u:

Bug: https://bugs.openjdk.java.net/browse/JDK-8213116

Original change: http://hg.openjdk.java.net/jdk/jdk/rev/7f67b8184ffc

11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8213116/webrev.00/

Patch applies cleanly except the changes to ProblemList.txt, that were
introduced by JDK-8213130 (not in 11u) and are excluded. Testing:
checked that corresponding test fails without the patch and passes
with it, ran: jck:api/javax_swing.

-- 
-Alex


From sgehwolf at redhat.com  Mon Feb 22 13:14:08 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 22 Feb 2021 14:14:08 +0100
Subject: [11u] RFR: JDK-8247753:
 UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora 32
In-Reply-To: <OF277C6B4D.8492A031-ON00258684.001F70C6-00258684.0021364C@notes.na.collabserv.com>
References: <OF69AE76A8.0527445A-ON00258673.001B269E-00258673.001B26A5@LocalDomain>
 <OF277C6B4D.8492A031-ON00258684.001F70C6-00258684.0021364C@notes.na.collabserv.com>
Message-ID: <539f75e37eeb240a9b51e9de54888e995fd30db5.camel@redhat.com>

Hi,

On Mon, 2021-02-22 at 06:02 +0000, Ramanand Patil wrote:
> Hi all,
> Please review the JDK11u backport of JDK-8247753:
> UIManager.getSytemLookAndFeelClassName() returns wrong value on Fedora
> 32
> Bug Link: https://bugs.openjdk.java.net/browse/JDK-8247753
> Webrev: http://cr.openjdk.java.net/~rpatil/8247753/webrev.00/

 461         if (getenv("GNOME_DESKTOP_SESSION_ID") != NULL
 462             || getenv("XDG_CURRENT_DESKTOP") != NULL) {
 463             sprops.desktop = "gnome";
 464         }

This doesn't match the functionality in jdk/jdk, which only returns a
desktop value of "gnome" if XDG_CURRENT_DESKTOP contains the string,
ignoring case, "gnome".

The current patch actually fails the test if XDG_CURRENT_DESKTOP=FOO.

Suggested change:

diff --git a/src/java.base/unix/native/libjava/java_props_md.c b/src/java.base/unix/native/libjava/java_props_md.c
--- a/src/java.base/unix/native/libjava/java_props_md.c
+++ b/src/java.base/unix/native/libjava/java_props_md.c
@@ -457,9 +457,10 @@
 #endif /* MACOSX */
 
         sprops.os_arch = ARCHPROPNAME;
+        char* curr_desktop = getenv("XDG_CURRENT_DESKTOP");
 
         if (getenv("GNOME_DESKTOP_SESSION_ID") != NULL
-            || getenv("XDG_CURRENT_DESKTOP") != NULL) {
+            || (curr_desktop != NULL && strcasestr(curr_desktop, "gnome") != NULL)) {
             sprops.desktop = "gnome";
         }
         else {

Thanks,
Severin


From goetz.lindenmaier at sap.com  Mon Feb 22 13:18:12 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Feb 2021 13:18:12 +0000
Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line
 number 0
Message-ID: <AM0PR0202MB344383431A8FC465003F7DB0EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

We tried to backport "8244287: JFR: Methods samples have line number 0"
to 11.0.9 [1].  The first downport had to be backed out, though [2].

I now propose this change for the issue. Please review.
http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287-JFR_line_no_0-jdk11/01/
I have verified that we do not see the crashes we saw with the
original change.

New Issue:
https://bugs.openjdk.java.net/browse/JDK-8262121

Original Change: 
https://bugs.openjdk.java.net/browse/JDK-8244287
Previous downport:
 https://bugs.openjdk.java.net/browse/JDK-8253576
Backout:
https://bugs.openjdk.java.net/browse/JDK-8253813

I don't understand why the previous backport is
flagged as 11.010. It was pushed on 2020-09-23,
which was in the 11.0.9 time frame. But we had 
issues with the automatic tagging in the past, probably
this is the reason.

I will only push this to 11.0.12.
I would also adapt the backport information so that
JBS shows that this is only fixed in 11.0.12.

Best regards,
  Goetz

[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003312.html
[2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003886.html

From goetz.lindenmaier at sap.com  Mon Feb 22 13:10:37 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Feb 2021 13:10:37 +0000
Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line
 number 0
Message-ID: <AM0PR0202MB3443731BB9C9DD2F98129B61EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

We tried to backport "8244287: JFR: Methods samples have line number 0"
to 11.0.9 [1].  The first downport had to be backed out, though [2].

I now propose this change for the issue. Please review.
http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287-JFR_line_no_0-jdk11/01/
I have verified that we do not see the crashes we saw with the
original change.

New Issue:
https://bugs.openjdk.java.net/browse/JDK-8262121

Original Change: 
https://bugs.openjdk.java.net/browse/JDK-8244287
Previous downport:
 https://bugs.openjdk.java.net/browse/JDK-8253576
Backout:
https://bugs.openjdk.java.net/browse/JDK-8253813

I don't understand why the previous backport is
flagged as 11.010. It was pushed on 2020-09-23,
which was in the 11.0.9 time frame. But we had 
issues with the automatic tagging in the past, probably
this is the reason.

I will only push this to 11.0.12.
I would also adapt the backport information so that
JBS shows that this is only fixed in 11.0.12.

Best regards,
  Goetz

[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-June/003312.html
[2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-September/003886.html

From hseigel at openjdk.java.net  Mon Feb 22 13:42:08 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 22 Feb 2021 13:42:08 GMT
Subject: [jdk16u] RFR: 8260349: Cannot programmatically retrieve Metaspace max
 set via JAVA_TOOL_OPTIONS
Message-ID: <R2PqHf4gzyhRWoGTMckq3A8VZAi7DlxI898mhlPDftA=.202b6e74-fa24-429a-8df3-952a823918cc@github.com>

Backport of JDK-8260349 to JDK-16u.  The patch applied cleanly and was tested with tiers 1-2 on Linux, Windows, and Mac OS, and tiers 3-5 on Linux x64.

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

Commit messages:
 - Backport b6a736738ae025604d86924298fdd04a7851b85f

Changes: https://git.openjdk.java.net/jdk16u/pull/38/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=38&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260349
  Stats: 123 lines in 2 files changed: 120 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/38/head:pull/38

PR: https://git.openjdk.java.net/jdk16u/pull/38

From goetz.lindenmaier at sap.com  Mon Feb 22 13:50:44 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Feb 2021 13:50:44 +0000
Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-11.0.12
Message-ID: <AM0PR0202MB3443D32D2C38BDA5CC224A7CEC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

Next week 11.0.12 development will start in jdk11u-dev.
We need to bump the version.  Please review.
See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

Please review:
http://cr.openjdk.java.net/~goetz/wr21/8257580-version_11.0.12-jdk11/01/

Best regards,
  Goetz.

From hseigel at openjdk.java.net  Mon Feb 22 13:56:48 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 22 Feb 2021 13:56:48 GMT
Subject: [jdk16u] Integrated: 8260349: Cannot programmatically retrieve
 Metaspace max set via JAVA_TOOL_OPTIONS
In-Reply-To: <R2PqHf4gzyhRWoGTMckq3A8VZAi7DlxI898mhlPDftA=.202b6e74-fa24-429a-8df3-952a823918cc@github.com>
References: <R2PqHf4gzyhRWoGTMckq3A8VZAi7DlxI898mhlPDftA=.202b6e74-fa24-429a-8df3-952a823918cc@github.com>
Message-ID: <2kiZ-1LKUM_Q9nyx2hV4kItEzUbZF2PaQTf65lSSriU=.de1e554e-d68c-41d3-b8b6-7695d6fd9479@github.com>

On Mon, 22 Feb 2021 13:37:08 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Backport of JDK-8260349 to JDK-16u.  The patch applied cleanly and was tested with tiers 1-2 on Linux, Windows, and Mac OS, and tiers 3-5 on Linux x64.

This pull request has now been integrated.

Changeset: 5828fc5b
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/5828fc5b
Stats:     123 lines in 2 files changed: 120 ins; 0 del; 3 mod

8260349: Cannot programmatically retrieve Metaspace max set via JAVA_TOOL_OPTIONS

Backport-of: b6a736738ae025604d86924298fdd04a7851b85f

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

PR: https://git.openjdk.java.net/jdk16u/pull/38

From rob.mckenna at oracle.com  Mon Feb 22 14:19:13 2021
From: rob.mckenna at oracle.com (Robert Mckenna)
Date: Mon, 22 Feb 2021 14:19:13 +0000
Subject: [15u Communication] Future Lead Maintainer for the JDK15 Updates
 repository: Yuri Nesterenko
Message-ID: <BN6PR1001MB2099BC0BDCC2EF1E4AB4840A93819@BN6PR1001MB2099.namprd10.prod.outlook.com>

Voting for Yuri Nesterenko as the lead Maintainer [0] for the JDK15 Updates repository has now closed.

Yes: 5
Veto: 0
Abstain: 0

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

Yuri will take over as lead maintainer when the existing maintainers step down at the end-of-support date for 15.0.2. In the interim, and in an effort to make the transition smoother, Yuri will be approving fix requests for 15.0.3 once we stop accepting requests for 15.0.2.

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

    -Rob

From martin.doerr at sap.com  Mon Feb 22 14:41:42 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 22 Feb 2021 14:41:42 +0000
Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-11.0.12
In-Reply-To: <AM0PR0202MB3443D32D2C38BDA5CC224A7CEC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3443D32D2C38BDA5CC224A7CEC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3057B86D5A2BC5C3EB298C009A819@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi G?tz,

this looks good. But let's double-check if all desired backports are integrated before pushing.

Best regards,
Martin


> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Montag, 22. Februar 2021 14:51
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-11.0.12
> 
> Hi,
> 
> Next week 11.0.12 development will start in jdk11u-dev.
> We need to bump the version.  Please review.
> See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> 
> Please review:
> http://cr.openjdk.java.net/~goetz/wr21/8257580-version_11.0.12-jdk11/01/
> 
> Best regards,
>   Goetz.

From goetz.lindenmaier at sap.com  Mon Feb 22 14:52:08 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Mon, 22 Feb 2021 14:52:08 +0000
Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-11.0.12
In-Reply-To: <AM4PR02MB3057B86D5A2BC5C3EB298C009A819@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3443D32D2C38BDA5CC224A7CEC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
 <AM4PR02MB3057B86D5A2BC5C3EB298C009A819@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <AM0PR0202MB3443A9C35E949D73DB60D619EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi Martin, 

11.0.12 development ends in jdk11u-dev on Tuesday March 2nd, 18:00 CET.
This is when we pull the changes for the 11.0.12+5 tag to jdk11u.
But that is no problem for 11.0.11, downports can still be pushed
to jdk11u with critical requests -- assuming they qualify for critical
requests.  Else, if they are not critical, it is no matter if they only go to 11.0.12.

As always, this version bump should be the first change pushed after the 
jdk-updater has been switchted to 11.0.12 for jdk11u-dev. I.e., I will only push 
it on March 3rd when this has happened.

Best regards,
  Goetz.


> -----Original Message-----
> From: Doerr, Martin <martin.doerr at sap.com>
> Sent: Monday, February 22, 2021 3:42 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> <jdk-updates-dev at openjdk.java.net>
> Subject: RE: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-
> 11.0.12
> 
> Hi G?tz,
> 
> this looks good. But let's double-check if all desired backports are integrated
> before pushing.
> 
> Best regards,
> Martin
> 
> 
> > -----Original Message-----
> > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > Behalf Of Lindenmaier, Goetz
> > Sent: Montag, 22. Februar 2021 14:51
> > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-
> 11.0.12
> >
> > Hi,
> >
> > Next week 11.0.12 development will start in jdk11u-dev.
> > We need to bump the version.  Please review.
> > See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> >
> > Please review:
> > http://cr.openjdk.java.net/~goetz/wr21/8257580-version_11.0.12-
> jdk11/01/
> >
> > Best regards,
> >   Goetz.

From martin.doerr at sap.com  Mon Feb 22 15:08:09 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 22 Feb 2021 15:08:09 +0000
Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-11.0.12
In-Reply-To: <AM0PR0202MB3443A9C35E949D73DB60D619EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3443D32D2C38BDA5CC224A7CEC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
 <AM4PR02MB3057B86D5A2BC5C3EB298C009A819@AM4PR02MB3057.eurprd02.prod.outlook.com>
 <AM0PR0202MB3443A9C35E949D73DB60D619EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB30570EC96136B1FA9F7332059A819@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi G?tz,

you certainly mean 11.0.11 development ends in jdk11u-dev on Tuesday March 2nd, 18:00 CET.
That's fine. I just need to keep track of further 11.0.11-oracle backports. We're in good shape at the moment.

Best regards,
Martin


> -----Original Message-----
> From: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
> Sent: Montag, 22. Februar 2021 15:52
> To: Doerr, Martin <martin.doerr at sap.com>; jdk-updates-dev <jdk-updates-
> dev at openjdk.java.net>
> Subject: RE: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-
> 11.0.12
> 
> Hi Martin,
> 
> 11.0.12 development ends in jdk11u-dev on Tuesday March 2nd, 18:00 CET.
> This is when we pull the changes for the 11.0.12+5 tag to jdk11u.
> But that is no problem for 11.0.11, downports can still be pushed
> to jdk11u with critical requests -- assuming they qualify for critical
> requests.  Else, if they are not critical, it is no matter if they only go to 11.0.12.
> 
> As always, this version bump should be the first change pushed after the
> jdk-updater has been switchted to 11.0.12 for jdk11u-dev. I.e., I will only
> push
> it on March 3rd when this has happened.
> 
> Best regards,
>   Goetz.
> 
> 
> > -----Original Message-----
> > From: Doerr, Martin <martin.doerr at sap.com>
> > Sent: Monday, February 22, 2021 3:42 PM
> > To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; jdk-updates-dev
> > <jdk-updates-dev at openjdk.java.net>
> > Subject: RE: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-
> > 11.0.12
> >
> > Hi G?tz,
> >
> > this looks good. But let's double-check if all desired backports are
> integrated
> > before pushing.
> >
> > Best regards,
> > Martin
> >
> >
> > > -----Original Message-----
> > > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> > > Behalf Of Lindenmaier, Goetz
> > > Sent: Montag, 22. Februar 2021 14:51
> > > To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> > > Subject: [11u] RFR: 8257580: Bump update version for OpenJDK: jdk-
> > 11.0.12
> > >
> > > Hi,
> > >
> > > Next week 11.0.12 development will start in jdk11u-dev.
> > > We need to bump the version.  Please review.
> > > See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u
> > >
> > > Please review:
> > > http://cr.openjdk.java.net/~goetz/wr21/8257580-version_11.0.12-
> > jdk11/01/
> > >
> > > Best regards,
> > >   Goetz.

From hseigel at openjdk.java.net  Mon Feb 22 21:41:08 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 22 Feb 2021 21:41:08 GMT
Subject: [jdk16u] Integrated: 8261585: Restore HandleArea used in
 Deoptimization::uncommon_trap
Message-ID: <3jjeHuzgt9BwGmq5ay5IzsK3nyBmE3D75KrFxpG6_WA=.99d728ab-0b17-4672-96b5-d0bac32e2a54@github.com>

This is a clean backport of the fix for bug JDK-8261585.  The fix was regression tested by running Mac5 tiers 1-3 on Windows, Linux,  and Mac OS, and tiers 3-5 on Linux x64.

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

Commit messages:
 - Backport 95d73129ce5074d3510710e7e238761a9af9ef3a

Changes: https://git.openjdk.java.net/jdk16u/pull/39/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=39&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261585
  Stats: 64 lines in 2 files changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/39.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/39/head:pull/39

PR: https://git.openjdk.java.net/jdk16u/pull/39

From hseigel at openjdk.java.net  Mon Feb 22 21:41:10 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 22 Feb 2021 21:41:10 GMT
Subject: [jdk16u] Integrated: 8261585: Restore HandleArea used in
 Deoptimization::uncommon_trap
In-Reply-To: <3jjeHuzgt9BwGmq5ay5IzsK3nyBmE3D75KrFxpG6_WA=.99d728ab-0b17-4672-96b5-d0bac32e2a54@github.com>
References: <3jjeHuzgt9BwGmq5ay5IzsK3nyBmE3D75KrFxpG6_WA=.99d728ab-0b17-4672-96b5-d0bac32e2a54@github.com>
Message-ID: <STlu-ykEzmqlqBp4IDxIBmOLLrQCREeHp0zebsOfrjA=.fc26a329-a2bf-4ac3-9c9f-892803810c60@github.com>

On Mon, 22 Feb 2021 21:34:41 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> This is a clean backport of the fix for bug JDK-8261585.  The fix was regression tested by running Mac5 tiers 1-3 on Windows, Linux,  and Mac OS, and tiers 3-5 on Linux x64.

This pull request has now been integrated.

Changeset: 5c130eb5
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/5c130eb5
Stats:     64 lines in 2 files changed: 64 ins; 0 del; 0 mod

8261585: Restore HandleArea used in Deoptimization::uncommon_trap

Backport-of: 95d73129ce5074d3510710e7e238761a9af9ef3a

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

PR: https://git.openjdk.java.net/jdk16u/pull/39

From mdoerr at openjdk.java.net  Mon Feb 22 21:49:56 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 22 Feb 2021 21:49:56 GMT
Subject: [jdk16u] RFR: 8261522: [PPC64] AES intrinsics write beyond the
 destination array
Message-ID: <0n_ctFfxmtaND_WcDF7BwWZ2WSX_Ki53jSGBx2UwuM4=.cd1d51f1-7d39-4326-a1b9-a6f18e16cbc0@github.com>

8261522: [PPC64] AES intrinsics write beyond the destination array

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

Commit messages:
 - Backport 05d59556381a0927b6d3901173d64a804cd7a5b0

Changes: https://git.openjdk.java.net/jdk16u/pull/40/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=40&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261522
  Stats: 76 lines in 1 file changed: 32 ins; 20 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/40.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/40/head:pull/40

PR: https://git.openjdk.java.net/jdk16u/pull/40

From christoph.langer at sap.com  Mon Feb 22 22:00:33 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Feb 2021 22:00:33 +0000
Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have
 line number 0
In-Reply-To: <AM0PR0202MB3443731BB9C9DD2F98129B61EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
References: <AM0PR0202MB3443731BB9C9DD2F98129B61EC819@AM0PR0202MB3443.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB3138B0B7D18D7A556EA5D42D8A819@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Goetz,

Thanks for tackling this now!

The original change, JDK-8244287, did only apply to 11u, so it was done in 11.0.9. As it was pushed to 11u at the time, consolidation into jdk11u-dev created "backport" JDK-8253576 to 11.0.10. The same goes for the backout, JDK-8253813. It has JDK-8253888 as backport.

Your change looks good to me. As it is a net new change in 11u, you should probably update the copyright years in jfrStackTrace.hpp and .cpp.

Since the tests show no regressions this time, I would be good if you still push it to 11.0.11. Rampdown hasn't started yet and the change isn't unclear or large at all. But I leave it to you.

Please don't modify the versions of the existing bugs. The linked items of JDK-8244287 contain all the history.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Montag, 22. Februar 2021 14:11
> To: jdk-updates-dev <jdk-updates-dev at openjdk.java.net>
> Subject: [11u]: 8262121: [11u] Redo 8244287: JFR: Methods samples have line
> number 0
> 
> Hi,
> 
> We tried to backport "8244287: JFR: Methods samples have line number 0"
> to 11.0.9 [1].  The first downport had to be backed out, though [2].
> 
> I now propose this change for the issue. Please review.
> http://cr.openjdk.java.net/~goetz/wr21/8262121-Redo-8244287-
> JFR_line_no_0-jdk11/01/
> I have verified that we do not see the crashes we saw with the
> original change.
> 
> New Issue:
> https://bugs.openjdk.java.net/browse/JDK-8262121
> 
> Original Change:
> https://bugs.openjdk.java.net/browse/JDK-8244287
> Previous downport:
>  https://bugs.openjdk.java.net/browse/JDK-8253576
> Backout:
> https://bugs.openjdk.java.net/browse/JDK-8253813
> 
> I don't understand why the previous backport is
> flagged as 11.010. It was pushed on 2020-09-23,
> which was in the 11.0.9 time frame. But we had
> issues with the automatic tagging in the past, probably
> this is the reason.
> 
> I will only push this to 11.0.12.
> I would also adapt the backport information so that
> JBS shows that this is only fixed in 11.0.12.
> 
> Best regards,
>   Goetz
> 
> [1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> June/003312.html
> [2] http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-
> September/003886.html

From christoph.langer at sap.com  Mon Feb 22 22:11:15 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Feb 2021 22:11:15 +0000
Subject: [11u] RFR: 8213116:
 javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java fails
 in Windows
In-Reply-To: <CABUxsJ1Cq=DZFPGD8iZPF_dUrEcV2EnWb6SS4qB3ByL0rw-9cQ@mail.gmail.com>
References: <CABUxsJ1Cq=DZFPGD8iZPF_dUrEcV2EnWb6SS4qB3ByL0rw-9cQ@mail.gmail.com>
Message-ID: <AM4PR02MB313876E588962D0767FC5C218A819@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Alex,

looks good to me. Thanks for backporting.

Cheers
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Alex Kashchenko
> Sent: Montag, 22. Februar 2021 13:17
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8213116:
> javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeT
> est.java fails in Windows
> 
> Hi,
> 
> Please review the backport of JDK-8213116 to 11u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8213116
> 
> Original change: http://hg.openjdk.java.net/jdk/jdk/rev/7f67b8184ffc
> 
> 11u webrev:
> https://cr.openjdk.java.net/~akasko/jdk11u/8213116/webrev.00/
> 
> Patch applies cleanly except the changes to ProblemList.txt, that were
> introduced by JDK-8213130 (not in 11u) and are excluded. Testing:
> checked that corresponding test fails without the patch and passes
> with it, ran: jck:api/javax_swing.
> 
> --
> -Alex


From christoph.langer at sap.com  Mon Feb 22 22:16:05 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Feb 2021 22:16:05 +0000
Subject: [11u] RFR: 8240353: AArch64: missing support for
 -XX:+ExtendedDTraceProbes in C1
In-Reply-To: <5161f937268b42fb8c548c56576e9ad6@huawei.com>
References: <5161f937268b42fb8c548c56576e9ad6@huawei.com>
Message-ID: <AM4PR02MB3138BE3455F3270708D7CA7F8A819@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Guo Ge,

if the fix applies clean, you don't need a review here on the list. Just add a jdk11u-fix-request label to the bug and add a fix request comment with some reasoning why you want the backport, the testing you did and how you'd assess the risk involved. Maintainers will then have a look and take an approval decision.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Guoge(JVM)
> Sent: Sonntag, 21. Februar 2021 10:34
> To: jdk-updates-dev at openjdk.java.net
> Subject: [11u] RFR: 8240353: AArch64: missing support for -
> XX:+ExtendedDTraceProbes in C1
> 
> Hi,
> 
> I would like to request a review for backport of JDK-8240353.
> 
> Original bug: https://bugs.openjdk.java.net/browse/JDK-8240353
> webrev for 11u: http://cr.openjdk.java.net/~gguo/8240353-11u/webrev.00/
> 
> The fix is trivial and clean, performed full jtreg test with aarch64
> release/fastdebug build.
> 
> Thanks,
> Guo Ge

From christoph.langer at sap.com  Mon Feb 22 22:27:59 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 22 Feb 2021 22:27:59 +0000
Subject: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
In-Reply-To: <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>
References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
 <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>
Message-ID: <AM4PR02MB3138D58C524B03CFB71F58938A819@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Yang Yi,

thanks for proposing this backport. I don't have a review, rather a maintainers comment.

There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today.

There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event.

Any thoughts by people involved with JFR?

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html 
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html 

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Yang Yi
> Sent: Donnerstag, 18. Februar 2021 06:27
> To: Yang Yi <qingfeng.yy at alibaba-inc.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] -
> Deoptimization
> 
> Gentle Ping :-)
>  ------------------Original Mail ------------------
> Sender:Yang Yi <qingfeng.yy at alibaba-inc.com>
> Send Date:Sun Feb 7 16:54:52 2021
> Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-
> dev at openjdk.java.net>
> Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
> 
> Hi,
> 
> Please can I request a review of this webrev for the backport of
> https://bugs.openjdk.java.net/browse/JDK-8216041 ?
> 
> Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-
> 8216041/webrev.00/
> 
> This patch doesn't apply cleanly but is fairly trivial. The signature of
> method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)`
> is
> not different comparing to upstream and jdk11u. Simply adjusting the
> argument position and adding extra parameters can solve this problem.
> 
> Best,Yang Yi

From qingfeng.yy at alibaba-inc.com  Tue Feb 23 02:20:03 2021
From: qingfeng.yy at alibaba-inc.com (Yang Yi)
Date: Tue, 23 Feb 2021 10:20:03 +0800
Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUjogQmFja3BvcnQgb2YgODIxNjA0MTogW0V2ZW50IFJlcXVlc3RdIC0g?=
 =?UTF-8?B?RGVvcHRpbWl6YXRpb24=?=
In-Reply-To: <AM4PR02MB3138D58C524B03CFB71F58938A819@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
 <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>,
 <AM4PR02MB3138D58C524B03CFB71F58938A819@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>

Hi Christoph,

Thanks for sharing the information, it's really useful, I will withdraw other JFR feature backports. However, as for Deoptimization event, the reason why deoptimization event probably could be considered are as follows:

1. It's actually an essential JFR event rather than a feature/enhancement event
2. There are customers who really need this event to estimate their code on the new architecture.(That's why I did this backport)

Just IMHO, please let me know more inputs :-)

Cheers,
Yang Yi
, I think we could carefully consider it.

,?????????????


------------------------------------------------------------------
From:Langer, Christoph <christoph.langer at sap.com>
Send Time:2021 Feb. 23 (Tue.) 06:28
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject:RE: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Yang Yi,

thanks for proposing this backport. I don't have a review, rather a maintainers comment.

There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today.

There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event.

Any thoughts by people involved with JFR?

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html 
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html 

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Yang Yi
> Sent: Donnerstag, 18. Februar 2021 06:27
> To: Yang Yi <qingfeng.yy at alibaba-inc.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] -
> Deoptimization
> 
> Gentle Ping :-)
>  ------------------Original Mail ------------------
> Sender:Yang Yi <qingfeng.yy at alibaba-inc.com>
> Send Date:Sun Feb 7 16:54:52 2021
> Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-
> dev at openjdk.java.net>
> Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
> 
> Hi,
> 
> Please can I request a review of this webrev for the backport of
> https://bugs.openjdk.java.net/browse/JDK-8216041 ?
> 
> Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-
> 8216041/webrev.00/
> 
> This patch doesn't apply cleanly but is fairly trivial. The signature of
> method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)`
> is
> not different comparing to upstream and jdk11u. Simply adjusting the
> argument position and adding extra parameters can solve this problem.
> 
> Best,Yang Yi

From hedongbo at huawei.com  Tue Feb 23 02:35:21 2021
From: hedongbo at huawei.com (hedongbo)
Date: Tue, 23 Feb 2021 02:35:21 +0000
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel
In-Reply-To: <AM4PR02MB31385D539C7C629278296F248A849@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <8FC616E5EC1A774287430B1CC2696FE30476B3DC@dggeml513-mbs.china.huawei.com>
 <AM4PR02MB31385D539C7C629278296F248A849@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <8FC616E5EC1A774287430B1CC2696FE304782244@dggeml513-mbx.china.huawei.com>

Thank you for your review, Christoph.  
I've tagged it for approval.

-----Original Message-----
From: Langer, Christoph [mailto:christoph.langer at sap.com] 
Sent: Saturday, February 20, 2021 2:52 AM
To: hedongbo <hedongbo at huawei.com>; jdk-updates-dev at openjdk.java.net
Subject: RE: [11u] RFR:8246707: (sc) SocketChannel.read/write throws AsynchronousCloseException on closed channel

Hi Dongbohe,

this backport looks good to me. I'll run it once again through SAP's regression testing. In case you don't hear from me by next Monday, you can consider it as reviewed.

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On 
> Behalf Of hedongbo
> Sent: Freitag, 19. Februar 2021 08:57
> To: jdk-updates-dev at openjdk.java.net
> Subject: RE: [11u] RFR:8246707: (sc) SocketChannel.read/write throws 
> AsynchronousCloseException on closed channel
> 
> Gentle Ping :-)
> 
> From: hedongbo
> Sent: Tuesday, February 9, 2021 9:18 AM
> To: jdk-updates-dev at openjdk.java.net
> Subject: FW: [11u] RFR:8246707: (sc) SocketChannel.read/write throws 
> AsynchronousCloseException on closed channel
> 
> Ping?
> 
> From: hedongbo
> Sent: Wednesday, February 3, 2021 5:16 PM
> To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-
> dev at openjdk.java.net>
> Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws 
> AsynchronousCloseException on closed channel
> 
> 
> Hi,
> 
> 
> 
> Please review the backport of JDK-8246707 to 11u:
> 
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8246707
> 
> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c8c6030e4d1f
> 
> 11u webrev: http://cr.openjdk.java.net/~dongbohe/8246707/webrev.00/
> 
> 
> 
> This patch doesn't apply cleanly but is fairly trivial. The reason is 
> that the latest jdk11u-dev has no ` blockingRead ` and 
> `blockingWriteFully` function, because they were added in jdk13 through JDK-8222774.
> 
> 
> 
> 
> Tested with tier1, tier2. No regression in tests.
> 
> 
> 
> 
> 
> 
> Thanks,
> dongbohe


From martin.doerr at sap.com  Tue Feb 23 10:36:16 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 23 Feb 2021 10:36:16 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <VI1PR02MB31491F03B439DA22D1D575178A819@VI1PR02MB3149.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com>
 <VI1PR02MB31491F03B439DA22D1D575178A819@VI1PR02MB3149.eurprd02.prod.outlook.com>
Message-ID: <AM4PR02MB30575ED8D41B5AACC49156A19A809@AM4PR02MB3057.eurprd02.prod.outlook.com>

Hi,

I have done my first jdk16u backport according to [1] and it has worked pretty smoothly even without Skara CLI tools.
It will certainly be even simpler when using them.
So I appreciate establishing the same backport process for 11u. It would be great to have the same backport process for all update releases, especially when we need to backport the same fix to several update releases.

Thanks and best regards,
Martin

[1] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-BackportPullRequests


> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> On Behalf Of Langer,
> Christoph
> Sent: Montag, 22. Februar 2021 11:30
> To: Andrew Haley <aph at redhat.com>; jdk-updates-dev at openjdk.java.net
> Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Severin Gehwolf <sgehwolf at redhat.com>
> Subject: RE: [11u] Proposal: Switch jdk11u development to Git/Skara with
> 11.0.13 cycle
> 
> Hi,
> 
> > -----Original Message-----
> > From: Andrew Haley <aph at redhat.com>
> > Sent: Montag, 22. Februar 2021 11:06
> > To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
> > dev at openjdk.java.net
> > Cc: jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz
> > <goetz.lindenmaier at sap.com>; Severin Gehwolf <sgehwolf at redhat.com>
> > Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> > 11.0.13 cycle
> >
> > On 17/02/2021 21:46, Langer, Christoph wrote:
> > > collecting the responses in this mail thread so far, I hear that we're about
> to
> > reach some kind of consensus with regards to a git switch of JDK11u. ??
> > >
> > > If nobody objects, I will go ahead now and approach the Skara team to
> > concretely discuss the envisioned switch for the 11.0.13 cycle.
> > >
> > > I'll seek to get answers to some open questions:
> > > - How do Merge PRs work?
> > > - Will "git bundle" work for the CPU process?
> > > - What about "git backport" and the "/backport" command in github?
> > > - What's the status of "clean" backports?
> >
> > That seems like a reasonable list. We need to be sure that OpenJDK
> > Jira and the mailing lists don't miss anything important. Right now
> > we have a log in Jira of the issue being raised, when it gets approved
> > for backport and by whom, and when it gets committed.
> 
> Thanks for the feedback. The points you made here seem to be covered as
> far as my experiences with Skara backports go, e.g. in 16u. So the approval
> process will still be handled using the appropriate Jira labels and backport bug
> items will be created and/or updated by the Skara bots in a way that pretty
> much resembles what hgupdater has done before.
> 
> Cheers
> Christoph


From christoph.langer at sap.com  Tue Feb 23 15:51:29 2021
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 23 Feb 2021 15:51:29 +0000
Subject: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
In-Reply-To: <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>
References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
 <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>,
 <AM4PR02MB3138D58C524B03CFB71F58938A819@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>
Message-ID: <AM4PR02MB3138FAF39159325AE295FC968A809@AM4PR02MB3138.eurprd02.prod.outlook.com>

Hi Yang Yi,

thanks for those points. I would defer the decision to the Red Hat folks (Andrew, Mario on cc) as they are more involved with the JFR backports.

Best regards
Christoph

From: Yang Yi <qingfeng.yy at alibaba-inc.com>
Sent: Dienstag, 23. Februar 2021 03:20
To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Christoph,

Thanks for sharing the information, it's really useful, I will withdraw other JFR feature backports. However, as for Deoptimization event, the reason why deoptimization event probably could be considered are as follows:

1. It's actually an essential JFR event rather than a feature/enhancement event
2. There are customers who really need this event to estimate their code on the new architecture.(That's why I did this backport)

Just IMHO, please let me know more inputs :-)

Cheers,
Yang Yi
, I think we could carefully consider it.


,?????????????

------------------------------------------------------------------
From:Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Send Time:2021 Feb. 23 (Tue.) 06:28
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com<mailto:qingfeng.yy at alibaba-inc.com>>; jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net> <jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-dev at openjdk.java.net>>; Mario Torre <neugens at redhat.com<mailto:neugens at redhat.com>>; Andrew Haley <aph at redhat.com<mailto:aph at redhat.com>>
Subject:RE: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Yang Yi,

thanks for proposing this backport. I don't have a review, rather a maintainers comment.

There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today.

There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event.

Any thoughts by people involved with JFR?

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net<mailto:jdk-updates-dev-retn at openjdk.java.net>> On
> Behalf Of Yang Yi
> Sent: Donnerstag, 18. Februar 2021 06:27
> To: Yang Yi <qingfeng.yy at alibaba-inc.com<mailto:qingfeng.yy at alibaba-inc.com>>; jdk-updates-
> dev at openjdk.java.net<mailto:dev at openjdk.java.net>
> Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] -
> Deoptimization
>
> Gentle Ping :-)
>  ------------------Original Mail ------------------
> Sender:Yang Yi <qingfeng.yy at alibaba-inc.com<mailto:qingfeng.yy at alibaba-inc.com>>
> Send Date:Sun Feb 7 16:54:52 2021
> Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-
> dev at openjdk.java.net<mailto:dev at openjdk.java.net>>
> Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
>
> Hi,
>
> Please can I request a review of this webrev for the backport of
> https://bugs.openjdk.java.net/browse/JDK-8216041 ?
>
> Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-
> 8216041/webrev.00/
>
> This patch doesn't apply cleanly but is fairly trivial. The signature of
> method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)`
> is
> not different comparing to upstream and jdk11u. Simply adjusting the
> argument position and adding extra parameters can solve this problem.
>
> Best,Yang Yi

From erik.gahlin at oracle.com  Tue Feb 23 17:14:15 2021
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 23 Feb 2021 17:14:15 +0000
Subject: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
In-Reply-To: <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>
References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
 <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>,
 <AM4PR02MB3138D58C524B03CFB71F58938A819@AM4PR02MB3138.eurprd02.prod.outlook.com>,
 <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>
Message-ID: <BYAPR10MB319160C0E686F5CCA48FD52A9D809@BYAPR10MB3191.namprd10.prod.outlook.com>

Hi Yang,

I'm not sure I understand what you mean with an essential JFR event, or how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release, but we like to avoid backporting of events.  Besides bugs introduced by the event itself, it can also lead to unexpected problems in tools/libraries that consume the data.

Thanks
Erik
________________________________
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Yang Yi <qingfeng.yy at alibaba-inc.com>
Sent: Tuesday, February 23, 2021 3:20 AM
To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Christoph,

Thanks for sharing the information, it's really useful, I will withdraw other JFR feature backports. However, as for Deoptimization event, the reason why deoptimization event probably could be considered are as follows:

1. It's actually an essential JFR event rather than a feature/enhancement event
2. There are customers who really need this event to estimate their code on the new architecture.(That's why I did this backport)

Just IMHO, please let me know more inputs :-)

Cheers,
Yang Yi
, I think we could carefully consider it.

,?????????????


------------------------------------------------------------------
From:Langer, Christoph <christoph.langer at sap.com>
Send Time:2021 Feb. 23 (Tue.) 06:28
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject:RE: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Yang Yi,

thanks for proposing this backport. I don't have a review, rather a maintainers comment.

There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today.

There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event.

Any thoughts by people involved with JFR?

Best regards
Christoph

[0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html
[1] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Yang Yi
> Sent: Donnerstag, 18. Februar 2021 06:27
> To: Yang Yi <qingfeng.yy at alibaba-inc.com>; jdk-updates-
> dev at openjdk.java.net
> Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] -
> Deoptimization
>
> Gentle Ping :-)
>  ------------------Original Mail ------------------
> Sender:Yang Yi <qingfeng.yy at alibaba-inc.com>
> Send Date:Sun Feb 7 16:54:52 2021
> Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-
> dev at openjdk.java.net>
> Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
>
> Hi,
>
> Please can I request a review of this webrev for the backport of
> https://bugs.openjdk.java.net/browse/JDK-8216041 ?
>
> Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-
> 8216041/webrev.00/
>
> This patch doesn't apply cleanly but is fairly trivial. The signature of
> method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)`
> is
> not different comparing to upstream and jdk11u. Simply adjusting the
> argument position and adding extra parameters can solve this problem.
>
> Best,Yang Yi

From akashche at redhat.com  Tue Feb 23 18:28:19 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 23 Feb 2021 18:28:19 +0000
Subject: [11u] RFR: 8213116:
 javax/swing/JComboBox/WindowsComboBoxSize/WindowsComboBoxSizeTest.java
 fails in Windows
In-Reply-To: <AM4PR02MB313876E588962D0767FC5C218A819@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <CABUxsJ1Cq=DZFPGD8iZPF_dUrEcV2EnWb6SS4qB3ByL0rw-9cQ@mail.gmail.com>
 <AM4PR02MB313876E588962D0767FC5C218A819@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <CABUxsJ1dmKQDGxZcK7vjAQN_UuvJ+r-in2Pw1QHa_iEiDfrFyg@mail.gmail.com>

On 2/22/21, Langer, Christoph <christoph.langer at sap.com> wrote:
> Hi Alex,
>
> looks good to me. Thanks for backporting.

Thanks for the review! I've added fix request to the issue.


>
> [...]
>

-- 
-Alex


From qingfeng.yy at alibaba-inc.com  Wed Feb 24 02:45:28 2021
From: qingfeng.yy at alibaba-inc.com (Yang Yi)
Date: Wed, 24 Feb 2021 10:45:28 +0800
Subject: =?UTF-8?B?UmU6IFsxMXVdIFJGUjogQmFja3BvcnQgb2YgODIxNjA0MTogW0V2ZW50IFJlcXVlc3RdIC0g?=
 =?UTF-8?B?RGVvcHRpbWl6YXRpb24=?=
In-Reply-To: <BYAPR10MB319160C0E686F5CCA48FD52A9D809@BYAPR10MB3191.namprd10.prod.outlook.com>
References: <80fd05f0-9a1c-4e50-a3fb-e855f626bd43.qingfeng.yy@alibaba-inc.com>
 <3f2288be-bd71-48be-93c6-73b9214150b8.qingfeng.yy@alibaba-inc.com>,
 <AM4PR02MB3138D58C524B03CFB71F58938A819@AM4PR02MB3138.eurprd02.prod.outlook.com>,
 <74d45cb0-9779-40c0-921f-917159b424c9.qingfeng.yy@alibaba-inc.com>,
 <BYAPR10MB319160C0E686F5CCA48FD52A9D809@BYAPR10MB3191.namprd10.prod.outlook.com>
Message-ID: <81cf7fbc-db6a-4bed-8014-22762c9baa5c.qingfeng.yy@alibaba-inc.com>

Hi Erik,

Let me clarify the previous response and add some content.

> I'm not sure I understand what you mean with an essential JFR event,

I mean, deoptimization is an important mechanism of VM, so deoptimization is also an important event. However, there are no quantitative indicators to measure what is "important". Given some JFR events like GCReferenceStatistics, G1MMU, G1GarbageCollection, OldGarbageCollection, I would like to say that G1GarbageCollection and OldGarbageCollection are more important than GCReferenceStatistics and G1MMU .

> how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release

Our customer has an application that uses code generation, the generated code contains many if statements that might cause unstable_if deoptimization, and the generated code shows a significant performance degradation. They hope to continuously monitor what is causing the performance degradation of the generated code, so they need to monitor some indicators like full gc, deoptimize, etc.
There are advantages and disadvantages to introducing a new event. Whether we are worth backporting is a question that needs broad consideration. If the community believes that the benefits of this backport are less than the risk, I will only backport it in the internal fork.

Thanks,Yang


------------------------------------------------------------------
From:Erik Gahlin <erik.gahlin at oracle.com>
Send Time:2021 Feb. 24 (Wed.) 01:14
To:"Langer, Christoph" <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>; "YANG, Yi" <qingfeng.yy at alibaba-inc.com>
Subject:Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

  
 Hi Yang,

I'm not sure I understand what you mean with an essential JFR event, or how customer can use this event to "estimate their code" in a new architecture that they can't do with a later release, but we like to avoid backporting of events.  Besides bugs introduced by the event itself, it can also lead to unexpected problems in tools/libraries that consume the data.

Thanks
Erik

From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> on behalf of Yang Yi <qingfeng.yy at alibaba-inc.com>
Sent: Tuesday, February 23, 2021 3:20 AM
To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

Hi Christoph,

 Thanks for sharing the information, it's really useful, I will withdraw other JFR feature backports. However, as for Deoptimization event, the reason why deoptimization event probably could be considered are as follows:

 1. It's actually an essential JFR event rather than a feature/enhancement event
 2. There are customers who really need this event to estimate their code on the new architecture.(That's why I did this backport)

 Just IMHO, please let me know more inputs :-)

 Cheers,
 Yang Yi
 , I think we could carefully consider it.

 ,?????????????


 ------------------------------------------------------------------
 From:Langer, Christoph <christoph.langer at sap.com>
 Send Time:2021 Feb. 23 (Tue.) 06:28
 To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk-updates-dev at openjdk.java.net <jdk-updates-dev at openjdk.java.net>; Mario Torre <neugens at redhat.com>; Andrew Haley <aph at redhat.com>
 Subject:RE: [11u] RFR: Backport of 8216041: [Event Request] - Deoptimization

 Hi Yang Yi,

 thanks for proposing this backport. I don't have a review, rather a maintainers comment.

 There was an earlier discussion regarding JFR feature backports, e.g. additional events. See [0] and its predecessor mails. At the time we were reluctant to accept a proposed JFR event backport and I think it hasn't changed until today.

 There was a list compiled by Azul about potentially interesting JFR backports [1] which also contains the Deoptimization event but afterwards nothing happened. Since then I believe only bug fixes for JFR were accepted. I don't know whether we should change that for the Deoptimization event.

 Any thoughts by people involved with JFR?

 Best regards
 Christoph

 [0]  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-December/002276.html 
 [1]  https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-January/002427.html 

 > -----Original Message-----
 > From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
 > Behalf Of Yang Yi
 > Sent: Donnerstag, 18. Februar 2021 06:27
 > To: Yang Yi <qingfeng.yy at alibaba-inc.com>; jdk-updates-
 > dev at openjdk.java.net
 > Subject: Re: [11u] RFR: Backport of 8216041: [Event Request] -
 > Deoptimization
 > 
 > Gentle Ping :-)
 >  ------------------Original Mail ------------------
 > Sender:Yang Yi <qingfeng.yy at alibaba-inc.com>
 > Send Date:Sun Feb 7 16:54:52 2021
 > Recipients:jdk-updates-dev at openjdk.java.net <jdk-updates-
 > dev at openjdk.java.net>
 > Subject:[11u] RFR: Backport of 8216041: [Event Request] - Deoptimization
 > 
 > Hi,
 > 
 > Please can I request a review of this webrev for the backport of
 > https://bugs.openjdk.java.net/browse/JDK-8216041 ?
 > 
 > Webrev: http://cr.openjdk.java.net/~ddong/yiyang/11u-
 > 8216041/webrev.00/
 > 
 > This patch doesn't apply cleanly but is fairly trivial. The signature of
 > method `Atomic::cmpxchg` and `register_static_type(jfrTypeManager.cpp)`
 > is
 > not different comparing to upstream and jdk11u. Simply adjusting the
 > argument position and adding extra parameters can solve this problem.
 > 
 > Best,Yang Yi

From goetz.lindenmaier at sap.com  Wed Feb 24 08:49:24 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 24 Feb 2021 08:49:24 +0000
Subject: [11u reminder]: jdk 11.0.11 rampdown starts Tuesday, March 2nd, 18:00
 CET.
Message-ID: <AM0PR0202MB34435D3C548D7ECC70089F88EC9F9@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

I would like to remind everybody who is working on jdk 11 updates
that rampdown of 11.0.11 starts next Tuesday, March 2nd, at 18:00 CET.

At that point in time the last merge from jdk11u-dev to jdk11u
will take place.  Please push all changes you want to get to 11.0.11
before that date.

After that, changes for 11.0.11 must be requested with 
jdk11u-critical-request tags, and they need to be pushed 
directly to jdk11u.

Best regards,
  Goetz
  
See also https://wiki.openjdk.java.net/display/JDKUpdates/JDK11u

From yan at azul.com  Wed Feb 24 09:17:24 2021
From: yan at azul.com (Yuri Nesterenko)
Date: Wed, 24 Feb 2021 12:17:24 +0300
Subject: [15u Communication] Future Lead Maintainer for the JDK15 Updates
 repository: Yuri Nesterenko
In-Reply-To: <BN6PR1001MB2099BC0BDCC2EF1E4AB4840A93819@BN6PR1001MB2099.namprd10.prod.outlook.com>
References: <BN6PR1001MB2099BC0BDCC2EF1E4AB4840A93819@BN6PR1001MB2099.namprd10.prod.outlook.com>
Message-ID: <febbcadc-adde-bdd4-49e8-57ff4887a4a7@azul.com>

Great! Thank you. I will try to do my best in this role, and hope for the community support.

--yan



On 22.02.2021 17:19, Robert Mckenna wrote:
> Voting for Yuri Nesterenko as the lead Maintainer [0] for the JDK15 Updates repository has now closed.
> 
> Yes: 5
> Veto: 0
> Abstain: 0
> 
> According to the Bylaws definition of Lazy Consensus [1], this is sufficient to approve the nomination.
> 
> Yuri will take over as lead maintainer when the existing maintainers step down at the end-of-support date for 15.0.2. In the interim, and in an effort to make the transition smoother, Yuri will be approving fix requests for 15.0.3 once we stop accepting requests for 15.0.2.
> 
> [0] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/004853.html
> [1] https://openjdk.java.net/bylaws#lazy-consensus
> 
>     -Rob
> 


From alexey at azul.com  Wed Feb 24 10:28:02 2021
From: alexey at azul.com (Alexey Bakhtin)
Date: Wed, 24 Feb 2021 10:28:02 +0000
Subject: [11u] RFR: 8245527: LDAP Channel Binding support for Java GSS/Kerberos
Message-ID: <782AB7FB-9E5F-4390-A622-C3E869B6FCA5@azul.com>

Hi all,
Can you please review backport of JDK-8245527 to JDK11u
Applied clean, all relevant tests run as expected.

Webrev: http://cr.openjdk.java.net/~abakhtin/8245527_11u/webrev.v0/
JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
CSR: https://bugs.openjdk.java.net/browse/JDK-8262258

Regards
Alexey

From aph at redhat.com  Wed Feb 24 10:32:55 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2021 10:32:55 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB30575ED8D41B5AACC49156A19A809@AM4PR02MB3057.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <AM4PR02MB313873D6D35CD06E103B38B38A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <62231fa4-8736-9738-1c61-cce18bf86f10@redhat.com>
 <VI1PR02MB31491F03B439DA22D1D575178A819@VI1PR02MB3149.eurprd02.prod.outlook.com>
 <AM4PR02MB30575ED8D41B5AACC49156A19A809@AM4PR02MB3057.eurprd02.prod.outlook.com>
Message-ID: <4b282384-0fff-9a32-d6cf-bfd3fd9e31c1@redhat.com>

On 23/02/2021 10:36, Doerr, Martin wrote:
> I have done my first jdk16u backport according to [1] and it has worked pretty smoothly even without Skara CLI tools.
> It will certainly be even simpler when using them.
> So I appreciate establishing the same backport process for 11u. It would be great to have the same backport process for all update releases, especially when we need to backport the same fix to several update releases.

OK, thanks for letting us know. Sounds good.

-- 
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  Wed Feb 24 11:00:35 2021
From: aph at redhat.com (Andrew Haley)
Date: Wed, 24 Feb 2021 11:00:35 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB313894F2D5DABE2506DE2BAC8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
 <8eec61ac-201c-5a41-ff6c-491d0ebde26b@oracle.com>
 <CA+3eh10ZyVgeMYYK3GzZPk-+=Y0EbC9obfXP_U6uRnKcJ_17SA@mail.gmail.com>
 <15fb175913bd4861a788ce1586111fa5@azul.com>
 <F9E0F090-EEDC-4660-A516-956011291C64@azul.com>
 <AM4PR02MB313894F2D5DABE2506DE2BAC8A869@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <088d28d7-151d-9508-505b-70945cac77f9@redhat.com>

On 17/02/2021 21:26, Langer, Christoph wrote:
> When we had a call with the Skara team, we talked about this point. For the case when the bot doesn't identify a backport as clean but we'd usually argue that it's a clean backport since e.g. only copyright headers changed or similar, we asked for a command to override the bot's decision. E.g. comment the PR with "/clean" or something like that. I don't know how the status of this development item is, though.
> 
> Anyway, even if such a "/clean" command isn't available, I'd rather think this wouldn't mean a big slowdown. You'd just have to find some reviewer to approve the PR.

Yeah, exactly. I'd suggest we have a REALLY CLEAN Subject line and
then any reviewer, even the approver, can tock the box.

-- 
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 abakhtin at openjdk.java.net  Wed Feb 24 11:49:50 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 24 Feb 2021 11:49:50 GMT
Subject: [jdk13u-dev] RFR: 8259707: LDAP channel binding does not work with
 StartTLS extension
Message-ID: <aX2j_PzLGfrd-cn-fZZ0j-k7Edia2ZMzSilP2fZFGuU=.c5452a72-0ca8-4d46-8e64-56fd472c7b69@github.com>

I'd like to port this fix to 13u. Applied clean, all relevant tests run as expected.

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

Commit messages:
 - Backport 874aef4a8f7ca503591e21333c092d1a969bc5a8

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/131/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=131&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259707
  Stats: 74 lines in 2 files changed: 39 ins; 21 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/131/head:pull/131

PR: https://git.openjdk.java.net/jdk13u-dev/pull/131

From mdoerr at openjdk.java.net  Wed Feb 24 12:23:40 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 24 Feb 2021 12:23:40 GMT
Subject: [jdk16u] Integrated: 8261522: [PPC64] AES intrinsics write beyond the
 destination array
In-Reply-To: <0n_ctFfxmtaND_WcDF7BwWZ2WSX_Ki53jSGBx2UwuM4=.cd1d51f1-7d39-4326-a1b9-a6f18e16cbc0@github.com>
References: <0n_ctFfxmtaND_WcDF7BwWZ2WSX_Ki53jSGBx2UwuM4=.cd1d51f1-7d39-4326-a1b9-a6f18e16cbc0@github.com>
Message-ID: <OMQ9iykYeJ_nS2IJqzCyKtOYTDL7fZcV6zGiCX59lA8=.e06fed43-6e66-41bf-813b-f4cc6611dd57@github.com>

On Mon, 22 Feb 2021 21:43:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> 8261522: [PPC64] AES intrinsics write beyond the destination array

This pull request has now been integrated.

Changeset: c000594e
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/c000594e
Stats:     76 lines in 1 file changed: 32 ins; 20 del; 24 mod

8261522: [PPC64] AES intrinsics write beyond the destination array

Backport-of: 05d59556381a0927b6d3901173d64a804cd7a5b0

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

PR: https://git.openjdk.java.net/jdk16u/pull/40

From abakhtin at openjdk.java.net  Wed Feb 24 12:59:44 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Wed, 24 Feb 2021 12:59:44 GMT
Subject: [jdk13u-dev] Integrated: 8259707: LDAP channel binding does not work
 with StartTLS extension
In-Reply-To: <aX2j_PzLGfrd-cn-fZZ0j-k7Edia2ZMzSilP2fZFGuU=.c5452a72-0ca8-4d46-8e64-56fd472c7b69@github.com>
References: <aX2j_PzLGfrd-cn-fZZ0j-k7Edia2ZMzSilP2fZFGuU=.c5452a72-0ca8-4d46-8e64-56fd472c7b69@github.com>
Message-ID: <rW7uUnvgMyuGMdNPK8n3Ss-hX4h1BhYgOGzPGaUrjzA=.e1d7135f-d3bd-4077-b92d-2e0e0e58adf1@github.com>

On Wed, 24 Feb 2021 11:44:31 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> I'd like to port this fix to 13u. Applied clean, all relevant tests run as expected.

This pull request has now been integrated.

Changeset: a71cc1db
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/a71cc1db
Stats:     74 lines in 2 files changed: 39 ins; 21 del; 14 mod

8259707: LDAP channel binding does not work with StartTLS extension

Backport-of: 874aef4a8f7ca503591e21333c092d1a969bc5a8

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/131

From sgehwolf at redhat.com  Wed Feb 24 17:30:09 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 24 Feb 2021 18:30:09 +0100
Subject: [11u] RFR: 8257746: Regression introduced with JDK-8250984 - memory
 might be null in some machines
Message-ID: <95023e2d396629a063779c6ee0d165f773fde3ea.camel@redhat.com>

Hi,

Please review this backport which adds necessary null checks before
actually using the memory controller which might be null in some cases.
JDK-8250984 introduced this regression and has been backported to
11.0.10. There have been reports where an NPE happens. For example on
an old SLES 11 system (cgroups v1) which only has the cpu controller
mounted and a jtreg test is attempted to be run. jtreg itselfs as some
initialization logic that uses OperatingSystemMXBean which has been
made container aware via JDK-8226575.

The JDK head patch doesn't apply since it has cgroups v2 support. It's
a rather simple rewrite though.

Bug: https://bugs.openjdk.java.net/browse/JDK-8257746
webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8257746/jdk11/01/webrev/

Testing:
Container tests on Linux (cgroups v1). Mattias Baesken reports that on
a system which reproduces the issue it's fixed with the proposed patch.

Thoughts?

Thanks,
Severin


From gnu.andrew at redhat.com  Thu Feb 25 05:01:51 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 25 Feb 2021 05:01:51 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
 <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com>
Message-ID: <20210225050151.GA1162457@rincewind>

On 18:52 Fri 12 Feb     , Andrew Haley wrote:
> On 12/02/2021 07:15, Andrew Hughes wrote:
> > even been released yet. Why the rush?
> > 
> > I don't see any reason at all to start altering 8u at such a late
> > stage in its development.  All risk and no gain.
> > 
> > [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241
> 
> We've always been a bit short of boots on the ground, and being
> stuck on an obsolete VCS will only isolate 8u even more. Maybe this
> is an optimist-versus-pessimist thing, but 8u may be about halfway
> through its lifetime! <ducks>
> 
> -- 
> 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
> 

Since when is Mercurial obsolete? Looking at its Wikipedia page, it
seems to have had a new release more recently than OpenJDK!

Are there people who want to contribute to 8u, but are being prevented
by the choice of version control system? It seems unlikely to me. I'm
much more concerned about the disruption a change would cause to
those who already contribute to 8u.

That goes further than just developers active on this mailing list. It
includes many people testing it and distributing it via various
channels. Over the course of the last week, I've had to redirect two
IcedTea bugs that will filed for IcedTea-Web, which moved to a git
repository elsewhere some time ago, and take over our update to 16u,
which was initially pointing at the last Mercurial sources, which
apparently are still around to cause confusion. In short, it takes
time for such changes to filter to all concerned and the impact
is more extensive than it may initially appear.

There are really two issues here. The first is the choice of version
control system.  As one of the people who has to do more with the
repositories than just pushing my own patches, I'm probably more aware
of the failings of Mercurial than some. In particular, 11u's use of a
mono repository is painfully slow in Mercurial. 8u, on the other hand,
would likely be slower as a git mono repository than the current
individual Mercurial repositories.  However, I don't see the great
rush to switch to git.  The potential disruption that would cause
seems greater than the pains of Mercurial.

What baffles me about OpenJDK's use of git is why the main advantage
of branches hasn't been used, and update repositories are being
created as separate trees as before. The obvious advantage of using
git to me would be to have one repository with multiple branches and
thus fewer things to check out.

However, as someone who already uses git for other projects, I wouldn't
have a problem with our repositories using it; my concern there is more
for the impact downstream and on those not familiar with git. My much
greater concern is we don't seem to be apply to just switch VCS, but
have to adopt a completely different set of processes as well, which
are frankly more confusing, less trustworthy and still seem to be
heavily in development.

If we could just switch to git without this SKARA thing, I'd be
much less concerned. As it stands, SKARA has not yet even been
used to produce a new OpenJDK release, yet there seems to be
some bizarre rush to use it on production update releases. I
really don't understand this and I've put off even replying
to this thread because it's making me quite angry.

Are we expecting all the Mercurial trees to vanish by the end
of the year? I can't otherwise see why we need to jump on this
so quickly.

Reading other comments on this thread, it seems backporting support
isn't yet ready in SKARA. If so, why are we even considering switching
to it so soon? My own experience is that I still have a bug pending
to backport to 13u & 16u and no idea how to do it. Pushing it to 11u
was trivial. Why do we want to make lives harder for ourselves?
-- 
Andrew :)

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

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

From gnu.andrew at redhat.com  Thu Feb 25 05:06:37 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 25 Feb 2021 05:06:37 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <AM4PR02MB3138ACF737D31A99F0E0A3D68A8B9@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
 <AM4PR02MB3138ACF737D31A99F0E0A3D68A8B9@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <20210225050637.GB1162457@rincewind>

On 08:38 Fri 12 Feb     , Langer, Christoph wrote:
> Hi Andrew,
> 
> you have valid concerns which I hope we can get sorted out until the proposed 11u switch. Let me answer in detail:
> 
> > I have still not seen any answer to my question of how a bulk update is
> > pushed for the CPU.
> 
> I think generally this is kind of answered. For the 11u <-> 11u-dev merges we can use a facility called "Merge PR", something like people used to merge jdk16 back into jdk [0].
> Although I've not yet done it myself and will need to talk to Skara folks to get it explained better, I think this is what we can use.
>
> For working on the CPU I hope to be able to use "git bundle" to distribute the state of work on vuln-dev (Similar to what we do with hg bundle now) and eventually push the release via a Merge PR. I will explore this in detail in the next weeks and see if it's bound to work. In case I don't see it working, I'd consider it a showstopper. So I'll update you on this soon, in time before the advised github switch.
> 
> > My own attempts to backport to jdk13u suggest the tooling still needs
> > work on this, or at least better documentation. [0]
> 
> I think you have a point here. As far as I know the "git backport" command does not exist yet and also the process to backport a change by commenting "/backport" on the original change in the jdk repository is not activated yet. I've brought this up to the skara team and they said that they hope to be able to enable it soon [1]. At the moment a backport would work like documented in the manual steps of this link [2] - which is not too convenient. I'll approach Skara folks again about that.
>

This all sounds like deploying this in just four months is too soon
for me. Why not allow Skara to mature first, if we must use it at all?

Can we not just switch 11u to git only and retain the existing processes that work fine?

> > OpenJDK 16, the first release to use git during development, has not
> > even been released yet. Why the rush?
> 
> Well, I would not consider it to be in a rush, given the proposal of switching in about 4 months from now. But overall, to align processes, to me it seems favorable to go to git with 11u and we should not overly delay it. At that time JDK16 and its first update release 16.0.1 will have been delivered out of git (as well as a few jdk13u update releases).
>

It's less git I'm concerned about, than that it seems to bring along
Skara with it. I found jcheck painful enough with Mercurial. Skara
terrifies me and seems to steal a lot of control away from us.

> > I don't see any reason at all to start altering 8u at such a late
> > stage in its development.  All risk and no gain.
> 
> That's a different discussion which I won't take part in as I'm not involved so much in 8u. The only point I have on that is that there's no reason to couple the decisions for 8 and 11, as was stated by Severin and Goetz already.
>

No, I agree on that. 8u is quite different and doesn't suffer from the painfully slow monorepo 11u does.

> Best regards
> Christoph
> 
> [0] https://github.com/openjdk/jdk/pull/2392
> [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-January/004051.html
> [2] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI
> 

-- 
Andrew :)

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

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

From yan at openjdk.java.net  Thu Feb 25 07:24:56 2021
From: yan at openjdk.java.net (Yuri Nesterenko)
Date: Thu, 25 Feb 2021 07:24:56 GMT
Subject: [jdk13u-dev] Integrated: 8243559: Remove root certificates with
 1024-bit keys
In-Reply-To: <Y60Q9whwdJVP6WR6mYulBMmDPe4WGyKYK3OxNP56rjk=.931b93a7-c430-47cd-b2ae-5d90fb6a9fb3@github.com>
References: <Y60Q9whwdJVP6WR6mYulBMmDPe4WGyKYK3OxNP56rjk=.931b93a7-c430-47cd-b2ae-5d90fb6a9fb3@github.com>
Message-ID: <uqiUkV7SdXey7V-zKG7ZOh0ORKUm9JFucx5oH1SK0RU=.aaee748c-513a-4630-8fd8-9d3d47d9aa51@github.com>

On Sat, 20 Feb 2021 12:38:50 GMT, Yuri Nesterenko <yan at openjdk.org> wrote:

> I'd like to port this fix to 13u, too. Applied clean, all relevant tests run as expected.

This pull request has now been integrated.

Changeset: 422eb196
Author:    Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/422eb196
Stats:     137 lines in 6 files changed: 1 ins; 134 del; 2 mod

8243559: Remove root certificates with 1024-bit keys

Reviewed-by: bae
Backport-of: dbfeb90d3a50b6bb0966e44164e6cf199e34cf47

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/130

From matthias.baesken at sap.com  Thu Feb 25 07:39:39 2021
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 25 Feb 2021 07:39:39 +0000
Subject: jdk-updates-dev Digest, Vol 40, Issue 88
In-Reply-To: <mailman.5299.1614229326.17574.jdk-updates-dev@openjdk.java.net>
References: <mailman.5299.1614229326.17574.jdk-updates-dev@openjdk.java.net>
Message-ID: <AM0PR02MB5412466BBA08FC90EC4A4D00939E9@AM0PR02MB5412.eurprd02.prod.outlook.com>

Hi Severin,  thanks for backporting this.
Looks good to me .

Best regards, Matthias


>Please review this backport which adds necessary null checks before
>actually using the memory controller which might be null in some cases.
>JDK-8250984 introduced this regression and has been backported to
>11.0.10. There have been reports where an NPE happens. For example on
>an old SLES 11 system (cgroups v1) which only has the cpu controller
>mounted and a jtreg test is attempted to be run. jtreg itselfs as some
>initialization logic that uses OperatingSystemMXBean which has been
>made container aware via JDK-8226575.
>
>The JDK head patch doesn't apply since it has cgroups v2 support. It's
>a rather simple rewrite though.
>
>Bug: https://bugs.openjdk.java.net/browse/JDK-8257746
>webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8257746/jdk11/01/webrev/
>
>Testing:
>Container tests on Linux (cgroups v1). Mattias Baesken reports that on
>a system which reproduces the issue it's fixed with the proposed patch.





From matthias.baesken at sap.com  Thu Feb 25 07:40:52 2021
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 25 Feb 2021 07:40:52 +0000
Subject: [11u] RFR: 8257746: Regression introduced with JDK-8250984 -
 memory might be null in some machines
Message-ID: <AM0PR02MB54124A86834424DDFA05CB3A939E9@AM0PR02MB5412.eurprd02.prod.outlook.com>



Hi Severin,  thanks for backporting this.
Looks good to me .

Best regards, Matthias


>Please review this backport which adds necessary null checks before
>actually using the memory controller which might be null in some cases.
>JDK-8250984 introduced this regression and has been backported to
>11.0.10. There have been reports where an NPE happens. For example on
>an old SLES 11 system (cgroups v1) which only has the cpu controller
>mounted and a jtreg test is attempted to be run. jtreg itselfs as some
>initialization logic that uses OperatingSystemMXBean which has been
>made container aware via JDK-8226575.
>
>The JDK head patch doesn't apply since it has cgroups v2 support. It's
>a rather simple rewrite though.
>
>Bug: https://bugs.openjdk.java.net/browse/JDK-8257746
>webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8257746/jdk11/01/webrev/
>
>Testing:
>Container tests on Linux (cgroups v1). Mattias Baesken reports that on
>a system which reproduces the issue it's fixed with the proposed patch.





From goetz.lindenmaier at sap.com  Thu Feb 25 08:12:42 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Thu, 25 Feb 2021 08:12:42 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <20210225050637.GB1162457@rincewind>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
 <AM4PR02MB3138ACF737D31A99F0E0A3D68A8B9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <20210225050637.GB1162457@rincewind>
Message-ID: <AM0PR0202MB3443CED4B55065C1C296BE62EC9E9@AM0PR0202MB3443.eurprd02.prod.outlook.com>

Hi,

could you please start a mail thread of its own
for discussing the move of 8u to git?

This mail thread is about moving 11u to git.

Best regards,
  Goetz.



> -----Original Message-----
> From: Andrew Hughes <gnu.andrew at redhat.com>
> Sent: Thursday, February 25, 2021 6:07 AM
> To: Langer, Christoph <christoph.langer at sap.com>
> Cc: Andrew Haley <aph at redhat.com>; jdk-updates-dev at openjdk.java.net;
> jdk8u-dev at openjdk.java.net; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; Severin Gehwolf <sgehwolf at redhat.com>
> Subject: Re: [11u] Proposal: Switch jdk11u development to Git/Skara with
> 11.0.13 cycle
> 
> On 08:38 Fri 12 Feb     , Langer, Christoph wrote:
> > Hi Andrew,
> >
> > you have valid concerns which I hope we can get sorted out until the
> proposed 11u switch. Let me answer in detail:
> >
> > > I have still not seen any answer to my question of how a bulk update is
> > > pushed for the CPU.
> >
> > I think generally this is kind of answered. For the 11u <-> 11u-dev merges
> we can use a facility called "Merge PR", something like people used to merge
> jdk16 back into jdk [0].
> > Although I've not yet done it myself and will need to talk to Skara folks to
> get it explained better, I think this is what we can use.
> >
> > For working on the CPU I hope to be able to use "git bundle" to distribute
> the state of work on vuln-dev (Similar to what we do with hg bundle now)
> and eventually push the release via a Merge PR. I will explore this in detail in
> the next weeks and see if it's bound to work. In case I don't see it working,
> I'd consider it a showstopper. So I'll update you on this soon, in time before
> the advised github switch.
> >
> > > My own attempts to backport to jdk13u suggest the tooling still needs
> > > work on this, or at least better documentation. [0]
> >
> > I think you have a point here. As far as I know the "git backport" command
> does not exist yet and also the process to backport a change by commenting
> "/backport" on the original change in the jdk repository is not activated yet.
> I've brought this up to the skara team and they said that they hope to be able
> to enable it soon [1]. At the moment a backport would work like
> documented in the manual steps of this link [2] - which is not too convenient.
> I'll approach Skara folks again about that.
> >
> 
> This all sounds like deploying this in just four months is too soon
> for me. Why not allow Skara to mature first, if we must use it at all?
> 
> Can we not just switch 11u to git only and retain the existing processes that
> work fine?
> 
> > > OpenJDK 16, the first release to use git during development, has not
> > > even been released yet. Why the rush?
> >
> > Well, I would not consider it to be in a rush, given the proposal of switching
> in about 4 months from now. But overall, to align processes, to me it seems
> favorable to go to git with 11u and we should not overly delay it. At that time
> JDK16 and its first update release 16.0.1 will have been delivered out of git
> (as well as a few jdk13u update releases).
> >
> 
> It's less git I'm concerned about, than that it seems to bring along
> Skara with it. I found jcheck painful enough with Mercurial. Skara
> terrifies me and seems to steal a lot of control away from us.
> 
> > > I don't see any reason at all to start altering 8u at such a late
> > > stage in its development.  All risk and no gain.
> >
> > That's a different discussion which I won't take part in as I'm not involved
> so much in 8u. The only point I have on that is that there's no reason to
> couple the decisions for 8 and 11, as was stated by Severin and Goetz already.
> >
> 
> No, I agree on that. 8u is quite different and doesn't suffer from the painfully
> slow monorepo 11u does.
> 
> > Best regards
> > Christoph
> >
> > [0] https://github.com/openjdk/jdk/pull/2392
> > [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-
> January/004051.html
> > [2] https://wiki.openjdk.java.net/display/SKARA/Backports#Backports-CLI
> >
> 
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> OpenJDK Package Owner
> Red Hat, Inc. (http://www.redhat.com)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From cgo at openjdk.java.net  Thu Feb 25 08:39:48 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Thu, 25 Feb 2021 08:39:48 GMT
Subject: [jdk16u] RFR: 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java
 fails if ergonomics detect too small InitialHeapSize
In-Reply-To: <GMtJHRkFj0GJQ31-m5HIy7lyEGEzuUQOVzHytiifsEY=.107d2988-3c2b-488d-8cc6-49683de1fa16@github.com>
References: <aLStUULoyMCKqYH6qjmSG7m0b6Mm9G3qJnVTMbYzf18=.4a633e4e-2640-453a-84b4-9e858b83df87@github.com>
 <GMtJHRkFj0GJQ31-m5HIy7lyEGEzuUQOVzHytiifsEY=.107d2988-3c2b-488d-8cc6-49683de1fa16@github.com>
Message-ID: <3SNfK5iVAWTgUVX2DMr1N9iMPtw0SJLDt4tIQKkwSNQ=.ac652ec6-29a5-4967-8ebe-3d650097e95f@github.com>

On Fri, 19 Feb 2021 10:48:13 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> 8261758: [TESTBUG] gc/g1/TestGCLogMessages.java fails if ergonomics detect too small InitialHeapSize
>
> Am I actually supposed to open the pull request on the jdk16u repository, or on [jdk16](https://github.com/openjdk/jdk16)?

Could someone please sponsor this clean backport?

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

PR: https://git.openjdk.java.net/jdk16u/pull/32

From sgehwolf at redhat.com  Thu Feb 25 08:56:40 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 25 Feb 2021 09:56:40 +0100
Subject: [11u] RFR: 8257746: Regression introduced with JDK-8250984 -
 memory might be null in some machines
In-Reply-To: <AM0PR02MB54124A86834424DDFA05CB3A939E9@AM0PR02MB5412.eurprd02.prod.outlook.com>
References: <AM0PR02MB54124A86834424DDFA05CB3A939E9@AM0PR02MB5412.eurprd02.prod.outlook.com>
Message-ID: <a873f78c43c1f4ecac9c60bd0f0d963a9746f860.camel@redhat.com>

Hi Matthias,

On Thu, 2021-02-25 at 07:40 +0000, Baesken, Matthias wrote:
> Hi Severin,? thanks for backporting this.
> Looks good to me .

Thanks for the review! Requested maintainer approval now.

Thanks,
Severin


From evergizova at openjdk.java.net  Thu Feb 25 09:43:08 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Thu, 25 Feb 2021 09:43:08 GMT
Subject: [jdk13u-dev] RFR: 8245283: JFR: Can't handle constant dynamic used by
 Jacoco agent
Message-ID: <DhI_-PJ61R3Hdw8V9c66hPB4DJTjK14JynZ_RiNYqtI=.f4700755-b54a-4c56-aa11-d306517956cb@github.com>

I'd like to backport JDK-8245283 to 13u for parity with 11u.
The patch applies cleanly.
Tested with tier1 and jdk/jfr tests.

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

Commit messages:
 - Backport 2bfc64ad1f590795f3a507fc8c099a665855a68b

Changes: https://git.openjdk.java.net/jdk13u-dev/pull/132/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk13u-dev&pr=132&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8245283
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk13u-dev/pull/132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk13u-dev pull/132/head:pull/132

PR: https://git.openjdk.java.net/jdk13u-dev/pull/132

From aph at redhat.com  Thu Feb 25 10:08:03 2021
From: aph at redhat.com (Andrew Haley)
Date: Thu, 25 Feb 2021 10:08:03 +0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <20210225050151.GA1162457@rincewind>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
 <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com>
 <20210225050151.GA1162457@rincewind>
Message-ID: <f5efeb4a-fb31-0360-239d-d2c51f9ff00d@redhat.com>

On 25/02/2021 05:01, Andrew Hughes wrote:
> On 18:52 Fri 12 Feb     , Andrew Haley wrote:
>> On 12/02/2021 07:15, Andrew Hughes wrote:
>>> even been released yet. Why the rush?

Who's rushing? All we're doing right now is talking.

>>> I don't see any reason at all to start altering 8u at such a late
>>> stage in its development.  All risk and no gain.
>>>
>>> [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241
>>
>> We've always been a bit short of boots on the ground, and being
>> stuck on an obsolete VCS will only isolate 8u even more. Maybe this
>> is an optimist-versus-pessimist thing, but 8u may be about halfway
>> through its lifetime! <ducks>
>
> Since when is Mercurial obsolete? Looking at its Wikipedia page, it
> seems to have had a new release more recently than OpenJDK!

It's very slow and doesn't scale well, and is rapidly losing out to
Git. Its maintainers may heroically try to keep it going, but it's
obsolescent now and will be obsolete some time during the life of
OpenJDK 8.

> Are there people who want to contribute to 8u, but are being prevented
> by the choice of version control system? It seems unlikely to me.

I'm thinking of a contributor who wants to push a bug fix through to
all supported versions of OpenJDK. I don't want to put roadblocks in
their way. I very much expect that anyone who joins OpenJDK today will
*never* use Mercurial, for anything. This means that they'll either
need a proxy to push their patch to 8u or it simply won't get fixed.

> I'm much more concerned about the disruption a change would cause to
> those who already contribute to 8u.

That's a general-purpose argument against any change, even one that is
in the long (or even medium) term beneficial. But Skara has proved to
be a huge improvement in workflow across all of OpenJDK active
development, such that it makes no sense to starve 8u forever of its
benefits. Now, it doesn't work so well with backports; they have not
been Skara's primary goal, that is true. But Skara development is
moving fast, and I expect there will be a good backport process soon.

> There are really two issues here. The first is the choice of version
> control system.  As one of the people who has to do more with the
> repositories than just pushing my own patches, I'm probably more
> aware of the failings of Mercurial than some. In particular, 11u's
> use of a mono repository is painfully slow in Mercurial. 8u, on the
> other hand, would likely be slower as a git mono repository than the
> current individual Mercurial repositories.

Maybe, but I doubt it.

> However, I don't see the great rush to switch to git.  The potential
> disruption that would cause seems greater than the pains of
> Mercurial.

> What baffles me about OpenJDK's use of git is why the main advantage
> of branches hasn't been used, and update repositories are being
> created as separate trees as before. The obvious advantage of using
> git to me would be to have one repository with multiple branches and
> thus fewer things to check out.

Having many individual forks is the GitHub way of working. It works
well, IMO better than multiple branches would, but that's another
discussion.

> However, as someone who already uses git for other projects, I
> wouldn't have a problem with our repositories using it; my concern
> there is more for the impact downstream and on those not familiar
> with git. My much greater concern is we don't seem to be apply to
> just switch VCS, but have to adopt a completely different set of
> processes as well, which are frankly more confusing, less
> trustworthy and still seem to be heavily in development.
>
> If we could just switch to git without this SKARA thing, I'd be much
> less concerned.

OK. So let's do that to start with, and see how it goes. We don't have
to use the Skara tooling if we don't want to.

-- 
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 evergizova at openjdk.java.net  Thu Feb 25 13:34:45 2021
From: evergizova at openjdk.java.net (Ekaterina Vergizova)
Date: Thu, 25 Feb 2021 13:34:45 GMT
Subject: [jdk13u-dev] Integrated: 8245283: JFR: Can't handle constant dynamic
 used by Jacoco agent
In-Reply-To: <DhI_-PJ61R3Hdw8V9c66hPB4DJTjK14JynZ_RiNYqtI=.f4700755-b54a-4c56-aa11-d306517956cb@github.com>
References: <DhI_-PJ61R3Hdw8V9c66hPB4DJTjK14JynZ_RiNYqtI=.f4700755-b54a-4c56-aa11-d306517956cb@github.com>
Message-ID: <6qcPRkl-5bW_w8z6YUypJz3N2Bqlyej6YO0DfeuUeIE=.3c5878de-9cdc-44eb-b0a7-9915c515a13f@github.com>

On Thu, 25 Feb 2021 09:36:24 GMT, Ekaterina Vergizova <evergizova at openjdk.org> wrote:

> I'd like to backport JDK-8245283 to 13u for parity with 11u.
> The patch applies cleanly.
> Tested with tier1 and jdk/jfr tests.

This pull request has now been integrated.

Changeset: a3174be7
Author:    Ekaterina Vergizova <evergizova at openjdk.org>
URL:       https://git.openjdk.java.net/jdk13u-dev/commit/a3174be7
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8245283: JFR: Can't handle constant dynamic used by Jacoco agent

Backport-of: 2bfc64ad1f590795f3a507fc8c099a665855a68b

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

PR: https://git.openjdk.java.net/jdk13u-dev/pull/132

From hseigel at openjdk.java.net  Thu Feb 25 13:42:47 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 13:42:47 GMT
Subject: [jdk16u] Integrated: 8260029: aarch64: fix typo in verify_oop_array
In-Reply-To: <tMo2VoNkxnf6xp13zkAmSh7Z576b-TSgo03WZBMUf_M=.cadfeb82-1682-4c3c-b8d8-c01189404c75@github.com>
References: <tMo2VoNkxnf6xp13zkAmSh7Z576b-TSgo03WZBMUf_M=.cadfeb82-1682-4c3c-b8d8-c01189404c75@github.com>
Message-ID: <7CwRku4bRGFU8wDEQaKjkrdWox5fhG0IRQZggg3ySoM=.7e2cf004-bff9-4e96-a364-188f486f53c8@github.com>

On Thu, 25 Feb 2021 13:32:54 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tier 3 on Linux aarch64.

This pull request has now been integrated.

Changeset: 262c9894
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/262c9894
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8260029: aarch64: fix typo in verify_oop_array

Backport-of: 4bcffeb9f4a8861f875f4792d71c2cf7ceae5530

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

PR: https://git.openjdk.java.net/jdk16u/pull/41

From hseigel at openjdk.java.net  Thu Feb 25 13:42:46 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 13:42:46 GMT
Subject: [jdk16u] Integrated: 8260029: aarch64: fix typo in verify_oop_array
Message-ID: <tMo2VoNkxnf6xp13zkAmSh7Z576b-TSgo03WZBMUf_M=.cadfeb82-1682-4c3c-b8d8-c01189404c75@github.com>

The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tier 3 on Linux aarch64.

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

Commit messages:
 - Backport 4bcffeb9f4a8861f875f4792d71c2cf7ceae5530

Changes: https://git.openjdk.java.net/jdk16u/pull/41/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=41&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260029
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/41.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/41/head:pull/41

PR: https://git.openjdk.java.net/jdk16u/pull/41

From hseigel at openjdk.java.net  Thu Feb 25 13:47:00 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 13:47:00 GMT
Subject: [jdk16u] Integrated: 8261334: NMT: tuning statistic shows incorrect
 hash distribution
Message-ID: <0WMFiMCCTYpWVf-oYXfDkX552-k0ZnnembQXqS8TrLc=.be16eb4c-48e5-49ed-ab33-24c014db22af@github.com>

The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64.

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

Commit messages:
 - Backport 20d7713c57d312e7f196f6887666c195f00da99c

Changes: https://git.openjdk.java.net/jdk16u/pull/42/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=42&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261334
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/42.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/42/head:pull/42

PR: https://git.openjdk.java.net/jdk16u/pull/42

From hseigel at openjdk.java.net  Thu Feb 25 13:47:00 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 13:47:00 GMT
Subject: [jdk16u] Integrated: 8261334: NMT: tuning statistic shows incorrect
 hash distribution
In-Reply-To: <0WMFiMCCTYpWVf-oYXfDkX552-k0ZnnembQXqS8TrLc=.be16eb4c-48e5-49ed-ab33-24c014db22af@github.com>
References: <0WMFiMCCTYpWVf-oYXfDkX552-k0ZnnembQXqS8TrLc=.be16eb4c-48e5-49ed-ab33-24c014db22af@github.com>
Message-ID: <eU6tEn3sMMCFDgs8x-53-wQKQbbwL8Tv-jLHFumjGxI=.e25a44fc-c42b-45ee-bb51-ece618275a6a@github.com>

On Thu, 25 Feb 2021 13:39:52 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> The original bug fix patch applied cleanly. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64.

This pull request has now been integrated.

Changeset: 9fa0e03d
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/9fa0e03d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8261334: NMT: tuning statistic shows incorrect hash distribution

Backport-of: 20d7713c57d312e7f196f6887666c195f00da99c

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

PR: https://git.openjdk.java.net/jdk16u/pull/42

From volker.simonis at gmail.com  Thu Feb 25 14:56:31 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 25 Feb 2021 15:56:31 +0100
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <f5efeb4a-fb31-0360-239d-d2c51f9ff00d@redhat.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <20210212071559.GC340416@rincewind>
 <8d6e4b2e-16c6-efe1-dfff-622d724467ec@redhat.com>
 <20210225050151.GA1162457@rincewind>
 <f5efeb4a-fb31-0360-239d-d2c51f9ff00d@redhat.com>
Message-ID: <CA+3eh12C-k-ByuATs6jWkXQhF+JyD9yAW+1_BEbN4BLjDVfbxA@mail.gmail.com>

On Thu, Feb 25, 2021 at 11:08 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 25/02/2021 05:01, Andrew Hughes wrote:
> > On 18:52 Fri 12 Feb     , Andrew Haley wrote:
> >> On 12/02/2021 07:15, Andrew Hughes wrote:
> >>> even been released yet. Why the rush?
>
> Who's rushing? All we're doing right now is talking.
>
> >>> I don't see any reason at all to start altering 8u at such a late
> >>> stage in its development.  All risk and no gain.
> >>>
> >>> [0] https://github.com/openjdk/jdk/pull/2153#issuecomment-766960241
> >>
> >> We've always been a bit short of boots on the ground, and being
> >> stuck on an obsolete VCS will only isolate 8u even more. Maybe this
> >> is an optimist-versus-pessimist thing, but 8u may be about halfway
> >> through its lifetime! <ducks>
> >
> > Since when is Mercurial obsolete? Looking at its Wikipedia page, it
> > seems to have had a new release more recently than OpenJDK!
>
> It's very slow and doesn't scale well, and is rapidly losing out to
> Git. Its maintainers may heroically try to keep it going, but it's
> obsolescent now and will be obsolete some time during the life of
> OpenJDK 8.
>
> > Are there people who want to contribute to 8u, but are being prevented
> > by the choice of version control system? It seems unlikely to me.
>
> I'm thinking of a contributor who wants to push a bug fix through to
> all supported versions of OpenJDK. I don't want to put roadblocks in
> their way. I very much expect that anyone who joins OpenJDK today will
> *never* use Mercurial, for anything. This means that they'll either
> need a proxy to push their patch to 8u or it simply won't get fixed.
>
> > I'm much more concerned about the disruption a change would cause to
> > those who already contribute to 8u.
>

It might also be worth mentioning that at least three major downstream
distributions (AdoptOpenJDK, SapMachine and Corretto) already use
GitHub to manage their update releases and each of them on their own
already convert the up-stream Mercurial repositories to Git.

> That's a general-purpose argument against any change, even one that is
> in the long (or even medium) term beneficial. But Skara has proved to
> be a huge improvement in workflow across all of OpenJDK active
> development, such that it makes no sense to starve 8u forever of its
> benefits. Now, it doesn't work so well with backports; they have not
> been Skara's primary goal, that is true. But Skara development is
> moving fast, and I expect there will be a good backport process soon.
>
> > There are really two issues here. The first is the choice of version
> > control system.  As one of the people who has to do more with the
> > repositories than just pushing my own patches, I'm probably more
> > aware of the failings of Mercurial than some. In particular, 11u's
> > use of a mono repository is painfully slow in Mercurial. 8u, on the
> > other hand, would likely be slower as a git mono repository than the
> > current individual Mercurial repositories.
>
> Maybe, but I doubt it.
>
> > However, I don't see the great rush to switch to git.  The potential
> > disruption that would cause seems greater than the pains of
> > Mercurial.
>
> > What baffles me about OpenJDK's use of git is why the main advantage
> > of branches hasn't been used, and update repositories are being
> > created as separate trees as before. The obvious advantage of using
> > git to me would be to have one repository with multiple branches and
> > thus fewer things to check out.
>
> Having many individual forks is the GitHub way of working. It works
> well, IMO better than multiple branches would, but that's another
> discussion.
>
> > However, as someone who already uses git for other projects, I
> > wouldn't have a problem with our repositories using it; my concern
> > there is more for the impact downstream and on those not familiar
> > with git. My much greater concern is we don't seem to be apply to
> > just switch VCS, but have to adopt a completely different set of
> > processes as well, which are frankly more confusing, less
> > trustworthy and still seem to be heavily in development.
> >
> > If we could just switch to git without this SKARA thing, I'd be much
> > less concerned.
>
> OK. So let's do that to start with, and see how it goes. We don't have
> to use the Skara tooling if we don't want to.
>
> --
> 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 hseigel at openjdk.java.net  Thu Feb 25 16:02:12 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 16:02:12 GMT
Subject: [jdk16u] RFR: 8258077: Using -Xcheck:jni can lead to a double-free
 after JDK-8193234
Message-ID: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>

The original bug fix patch applied cleanly and included regression tests. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64.

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

Commit messages:
 - Backport 712014c5956cf74982531d212b03460843e4e5b6

Changes: https://git.openjdk.java.net/jdk16u/pull/43/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=43&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258077
  Stats: 325 lines in 5 files changed: 306 ins; 6 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/43/head:pull/43

PR: https://git.openjdk.java.net/jdk16u/pull/43

From coleenp at openjdk.java.net  Thu Feb 25 17:26:46 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 25 Feb 2021 17:26:46 GMT
Subject: [jdk16u] RFR: 8258077: Using -Xcheck:jni can lead to a
 double-free after JDK-8193234
In-Reply-To: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>
References: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>
Message-ID: <iUN1yX5JyXtlY9uMtpzaD9X08b0ObLyJH_ZpWNy_2Ug=.4ae96b71-4d3c-4b4a-bdd2-9915146f3042@github.com>

On Thu, 25 Feb 2021 15:56:35 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> The original bug fix patch applied cleanly and included regression tests. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64.

Marked as reviewed by coleenp (Reviewer).

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

PR: https://git.openjdk.java.net/jdk16u/pull/43

From hseigel at openjdk.java.net  Thu Feb 25 18:07:44 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 18:07:44 GMT
Subject: [jdk16u] RFR: 8258077: Using -Xcheck:jni can lead to a
 double-free after JDK-8193234
In-Reply-To: <iUN1yX5JyXtlY9uMtpzaD9X08b0ObLyJH_ZpWNy_2Ug=.4ae96b71-4d3c-4b4a-bdd2-9915146f3042@github.com>
References: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>
 <iUN1yX5JyXtlY9uMtpzaD9X08b0ObLyJH_ZpWNy_2Ug=.4ae96b71-4d3c-4b4a-bdd2-9915146f3042@github.com>
Message-ID: <BbNz3kyAPksq4rtoesmtgwoqqPCWX4m46719RHzR43M=.d6373e12-5b08-4d05-abed-e3b3a6bc6d77@github.com>

On Thu, 25 Feb 2021 17:23:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The original bug fix patch applied cleanly and included regression tests. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64.
>
> Marked as reviewed by coleenp (Reviewer).

Thanks Coleen, for the review!

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

PR: https://git.openjdk.java.net/jdk16u/pull/43

From hseigel at openjdk.java.net  Thu Feb 25 18:07:45 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 25 Feb 2021 18:07:45 GMT
Subject: [jdk16u] Integrated: 8258077: Using -Xcheck:jni can lead to a
 double-free after JDK-8193234
In-Reply-To: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>
References: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>
Message-ID: <bp96-H2IJu2ME2rG6wN9jGZsxySYtMLye4VZKvXrmaQ=.2ec20c83-d987-41ce-b86d-278403fe4ebb@github.com>

On Thu, 25 Feb 2021 15:56:35 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> The original bug fix patch applied cleanly and included regression tests. After applying the patch to a JDK-16u repo, the fix was regression tested by running Mach5 tiers 1 and 2 on Linux, Windows, and Mac OS, and running tiers 3-5 on Linux x64.

This pull request has now been integrated.

Changeset: b7b2f61b
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/b7b2f61b
Stats:     325 lines in 5 files changed: 306 ins; 6 del; 13 mod

8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234
8259446: runtime/jni/checked/TestCheckedReleaseArrayElements.java fails with stderr not empty

Reviewed-by: coleenp
Backport-of: 712014c5956cf74982531d212b03460843e4e5b6

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

PR: https://git.openjdk.java.net/jdk16u/pull/43

From darcy at openjdk.java.net  Thu Feb 25 20:47:59 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Feb 2021 20:47:59 GMT
Subject: [jdk16u] Integrated: 8253409: Double-rounding possibility in float fma
Message-ID: <1JM334WNTvZcJ7XuCd0Vg5JcDx-5hS4pdxd-svaej5g=.f698c211-74c4-46cd-ad1c-9946b35e35c3@github.com>

8253409:  Double-rounding possibility in float fma

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

Commit messages:
 - 8253409: Double-rounding possibility in float fma

Changes: https://git.openjdk.java.net/jdk16u/pull/44/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=44&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253409
  Stats: 32 lines in 2 files changed: 4 ins; 11 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/44/head:pull/44

PR: https://git.openjdk.java.net/jdk16u/pull/44

From darcy at openjdk.java.net  Thu Feb 25 20:47:59 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Feb 2021 20:47:59 GMT
Subject: [jdk16u] Integrated: 8253409: Double-rounding possibility in float fma
In-Reply-To: <1JM334WNTvZcJ7XuCd0Vg5JcDx-5hS4pdxd-svaej5g=.f698c211-74c4-46cd-ad1c-9946b35e35c3@github.com>
References: <1JM334WNTvZcJ7XuCd0Vg5JcDx-5hS4pdxd-svaej5g=.f698c211-74c4-46cd-ad1c-9946b35e35c3@github.com>
Message-ID: <P8drgyTw2UxUholoTmtWhR4p_YFQ0pM8WDvIknzi6XM=.61a057dd-2424-490b-8864-fc75c0dc00b8@github.com>

On Thu, 25 Feb 2021 20:40:21 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8253409:  Double-rounding possibility in float fma

This pull request has now been integrated.

Changeset: b7470f48
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/b7470f48
Stats:     32 lines in 2 files changed: 4 ins; 11 del; 17 mod

8253409: Double-rounding possibility in float fma

Backport-of: e5304b3a994b1e291e4ac5258f473dd7874f163f

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

PR: https://git.openjdk.java.net/jdk16u/pull/44

From dholmes at openjdk.java.net  Thu Feb 25 21:32:43 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 25 Feb 2021 21:32:43 GMT
Subject: [jdk16u] RFR: 8258077: Using -Xcheck:jni can lead to a
 double-free after JDK-8193234
In-Reply-To: <BbNz3kyAPksq4rtoesmtgwoqqPCWX4m46719RHzR43M=.d6373e12-5b08-4d05-abed-e3b3a6bc6d77@github.com>
References: <LXS3In9HnM27yiuUTI1Wot-_jHn7teL3da34rfVDzOE=.42ac6bcf-1055-40b3-b359-2b03e663e97e@github.com>
 <iUN1yX5JyXtlY9uMtpzaD9X08b0ObLyJH_ZpWNy_2Ug=.4ae96b71-4d3c-4b4a-bdd2-9915146f3042@github.com>
 <BbNz3kyAPksq4rtoesmtgwoqqPCWX4m46719RHzR43M=.d6373e12-5b08-4d05-abed-e3b3a6bc6d77@github.com>
Message-ID: <GGzGGxIjZLpI5KHhu2m1cxiVmA5bR-H963Rtcy_QBgU=.662d5c5b-e337-4cfc-b7f5-326ae109b416@github.com>

On Thu, 25 Feb 2021 18:04:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Marked as reviewed by coleenp (Reviewer).
>
> Thanks Coleen, for the review!

Thanks for doing the backport Harold!

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

PR: https://git.openjdk.java.net/jdk16u/pull/43

From michaelm at openjdk.java.net  Fri Feb 26 18:25:03 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 26 Feb 2021 18:25:03 GMT
Subject: [jdk16u] RFR: 8252971: WindowsFileAttributes does not know about Unix
 domain sockets
Message-ID: <oGFZjA9BxP6k4eE0V8Rfy9XY-FFv5BBfNG89N5gx1Xs=.5265d088-66c8-4fba-b45a-29719115609f@github.com>

Hi,

This is a backport of 8252971 to 16u. The patch applies cleanly.

- Michael

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

Commit messages:
 - Backport 9ffabf30c33c87ae5347b7abc76c6a2c8b4fda01

Changes: https://git.openjdk.java.net/jdk16u/pull/47/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16u&pr=47&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252971
  Stats: 245 lines in 10 files changed: 228 ins; 10 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk16u/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16u pull/47/head:pull/47

PR: https://git.openjdk.java.net/jdk16u/pull/47

From michaelm at openjdk.java.net  Fri Feb 26 19:32:50 2021
From: michaelm at openjdk.java.net (Michael McMahon)
Date: Fri, 26 Feb 2021 19:32:50 GMT
Subject: [jdk16u] Integrated: 8252971: WindowsFileAttributes does not know
 about Unix domain sockets
In-Reply-To: <oGFZjA9BxP6k4eE0V8Rfy9XY-FFv5BBfNG89N5gx1Xs=.5265d088-66c8-4fba-b45a-29719115609f@github.com>
References: <oGFZjA9BxP6k4eE0V8Rfy9XY-FFv5BBfNG89N5gx1Xs=.5265d088-66c8-4fba-b45a-29719115609f@github.com>
Message-ID: <cSVbmEPg60v9dkXoo3i-aEbLv5JdTnmDzIs-W_cNzHk=.1b34b129-80aa-473c-8c6e-c5023d754139@github.com>

On Fri, 26 Feb 2021 18:18:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Hi,
> 
> This is a backport of 8252971 to 16u. The patch applies cleanly.
> 
> - Michael

This pull request has now been integrated.

Changeset: 2a9780ab
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16u/commit/2a9780ab
Stats:     245 lines in 10 files changed: 228 ins; 10 del; 7 mod

8252971: WindowsFileAttributes does not know about Unix domain sockets

Backport-of: 9ffabf30c33c87ae5347b7abc76c6a2c8b4fda01

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

PR: https://git.openjdk.java.net/jdk16u/pull/47

From Pengfei.Li at arm.com  Tue Feb  9 03:21:45 2021
From: Pengfei.Li at arm.com (Pengfei Li)
Date: Tue, 09 Feb 2021 03:21:45 -0000
Subject: [11u] RFR(S): 8261022: Fix incorrect result of Math.abs() with char
 type
Message-ID: <PR3PR08MB58505A8740860AE313B7FAFA968E9@PR3PR08MB5850.eurprd08.prod.outlook.com>

Hi,

I'd like to backport JDK-8261022 to jdk11u.

Original JBS: https://bugs.openjdk.java.net/browse/JDK-8261022
Modified webrev: http://cr.openjdk.java.net/~pli/rfr/8261022/backport11u/

This issue causes vectorized abs generate incorrect result when the argument has char type. Root cause is that the vector abs operation is not specially handled in computing vector element types after we enabled that in JDK-8222074 in jdk13. As JDK-8222074 was backported to jdk11u, jdk11u is also affected.

The patch to fix this is in jdk17 now. The fix does not apply to jdk11u cleanly, as VectorNode::is_shift_opcode() is not defined in jdk11u. I have modified the patch a little bit to fit this difference.

Tested jtreg hotspot::tier1 and the newly added jtreg case. No failure after the modified patch.

--
Thanks,
Pengfei


From erik.joelsson at oracle.com  Tue Feb 16 19:39:22 2021
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Tue, 16 Feb 2021 19:39:22 -0000
Subject: [11u] Proposal: Switch jdk11u development to Git/Skara with
 11.0.13 cycle
In-Reply-To: <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
References: <AM4PR02MB313822C82887B1595211B2FC8A8D9@AM4PR02MB3138.eurprd02.prod.outlook.com>
 <47fd2096-5d05-2dbb-0395-d5d215384fdf@redhat.com>
 <bb5f5af6-1141-13a1-bee7-84971c7f426d@redhat.com>
 <9c714833-e1d8-5abc-90e5-658c67e79086@redhat.com>
 <09c3a83d36037a3fcebbae65bdfe87a83d7b2c95.camel@redhat.com>
 <d2e6b1cc-747a-528d-2e6a-13f363045956@redhat.com>
 <a765d03528fa527d7be403643677474b84b29f6b.camel@redhat.com>
 <4df22c05-9996-894f-8f20-e71830ec9909@redhat.com>
 <CA+3eh10E-Smge9dofVASJmOopCq=f5dHciUxtCbffp2_XT9JeA@mail.gmail.com>
Message-ID: <05733f7a-3f5d-4420-0d7d-baea4f39398c@oracle.com>

(resending this with full to/cc list)

Hello,

As you may have seen, Erik Duveblad just posted about our prototype 
conversions on skara-dev [1]. These are based on the same kind of 
forest->mono repo conversion, followed by hg->git conversion that 
mainline went through.

I have been working for a while now on adapting the scripts from JEP 296 
to work for the old update releases. This has required more work than I 
first anticipated as the problem now requires a more generalized 
solution, but I believe I now have something that works reasonably well. 
If you are curious on the details, please continue reading.

Volker's description of the processes is pretty accurate on a high 
level. The main difference in 8u compared to a main release is that the 
tags are not sequential in history. This means that we can't transplant 
(or splice as it's called in Mercurial terms) changes as freely on top 
of each tagged change. In the original JDK 10 consolidation, we had a 
handful of changes that weren't linear (around the transition between 
JDK 9 and 10), and I handled them differently (basically just merging 
them together to recreate the point in history, but not splicing 
anything on top afterwards). Since they were only a handful, I could 
just list them out explicitly in the script. For 8u, a majority of the 
tags are non linear, so a big problem was creating an algorithm that 
would automatically figure out a reasonable line of tags in sequence 
that I could use to splice changes on top of.

Another big problem is that there are often tags merged together in 
different order in different repos. When this happens, the script needs 
to figure out the best order to do the conversion. I have tried to 
automate this process as much as possible. The ordering is sensitive 
when some of the tags are used to splice changes on top of them. There 
are also cases of tags missing completely.

In the end, the state of the mono repo at each tag is verified to be 
exactly the same as the forest of repos at each tag. The state of 
changes between tags is however less predictable in 8u compared to 
mainline due to the large amount of non linear tags.

For the extra curious, here is what the current algorithm for choosing 
the "splice tags" looks like:

1. Start with the first tag

2. Continue with each consecutive build for current release until a gap 
in build numbers is detected (we typically have update release builds 
 >b30 that probably aren't that interesting)

3. Find the next release in order and then find the first tag in that 
release that is also a descendant of the previous splice tag in every repo.

4. Repeat from 2 until all tags have been considered.

/Erik

[1] 
https://mail.openjdk.java.net/pipermail/skara-dev/2021-February/004228.html

On 2021-02-12 13:33, Volker Simonis wrote:
> On Fri, Feb 12, 2021 at 6:40 PM Andrew Dinn <adinn at redhat.com> wrote:
>> On 12/02/2021 16:37, Severin Gehwolf wrote:
>>> Don't get me wrong, moving JDK 8u to git is doable, but it'll need some
>>> more thought than 11u.
>> That's what I was thinking.
>>
>>> My preference would be to do it in steps:
>>> 1.) HG forest -> monorepo conversion (using JEP 296 scripts)
>>> 2.) HG -> git conversion using Skara tooling (should take care of
>>>       proper metadata, etc.)
>> Yes, I think this is the right way to go about it. If nothing else
>> because the tools for the second step assumed that the first one had
>> happened.
>>
>> The really tricky differences I see happen at step 1 (although they
>> might have a knock-on effect at step 2)
>>
> I think converting 8u to a Git mono-repo might not be as complicated
> and risky as it seems. We have to remember that most of the work has
> already been done by JEP 296 in jdk10. That process already converted
> all the old history and as nobody seems to have been complaining about
> it in jdk10 and later, that conversion must have been fine. I.e. The
> jdk 10 repository naturally contains the sources of jdk8 from which is
> was initially forked (I think at jdk8-b120).
>
> So we "only" have to take a clone of jdk10 or 11 up to the tag jdk8-b120:
>
> hg clone -r jdk8-b120 jdk11u-dev/ jdk11u-dev-jdk8-b120
>
> This will give us a mono-repo at the stage of jdk8-b120. Afterwards,
> we only have to use the JEP 296 scripts or something equivalent (I
> hope that the Oracle build group can assist or at least give some good
> advice here :)
>
>  From a quick look at the "jdk11u-dev-jdk8-b120" repo which I created
> with the above command, it looks like the "JEP 296" script worked as
> follows:
> - let's assume were at a changeset which merges all the subrepos at a
> specific build tag "jdk8-bXX" (builds were usually  tagged weekly, so
> every jdk8-bXX tag corresponds to a weekly version).
> - sequentially transplant all the changes from a single subrepo up
> until the next tag "jdk8-bXX+1" into the new repo
> - do this sequentially for all the other sub-repositories
> - create a merge change in the new mono-repo which merges all the
> newly transplanted changes and tag it with "jdk8-bXX+1"
> - verify that the sources of the new mono-repo at tag "jdk8-bXX+1" are
> bit-wise equal to the sources of the jdk8u forest when every single
> repo is synced to the same tag.
> - repeat the procedure for all the other jdk8-bXX tags
>
> We can probably take the above jdk11u-dev-jdk8-b120 repo and follow
> the described procedure for all the additional changes between
> jdk8-b121 up to the latest jdk8u-XXX tag from the jdk8u-dev forest.
> Needless to say that the Corretto team is fully supporting the
> transition of jdk8u from a Mercurial forest to a Git mono-repo and
> will be happy to get involved into the process :)
>
> Best regards,
> Volker
>
>>     JEP 296 had to relocate all the java code into modules
>>     JEP 296 did not have to retain (and therefore relocate) all of the
>> java code we need to keep in jdk8u (corba?, jaxb?, jaxws?)
>>
>> I don't suppose these differences would be impossible to sort out but I
>> think they would require some effort.
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>

From ilarion at azul.com  Fri Feb 19 18:19:19 2021
From: ilarion at azul.com (Ilarion Nakonechnyy)
Date: Fri, 19 Feb 2021 18:19:19 -0000
Subject: [11u] RFR: JDK-8236859 backport: WebSocket over authenticating proxy
 fails with NPE
Message-ID: <EB8BB4A0-A66C-4A15-A6BA-BC6FBC044F59@azul.com>

Dear sirs, I?d like to backport JDK-8236859 to JDK11.

The bug causes jtreg test java/net/httpclient/websocket/WebSocketProxyTest.java to fail with timeout.
Was caught on x86_64 platform, but seems that it?s platform independent.

Patch applied unclear, manually merged files src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java and src/java.net.http/share/classes/jdk/internal/net/http/HttpResponseImpl.java
Jdk was built on Ubuntu x86_64 and tested with tier1

Could you please review my changes?

Bug: <https://bugs.openjdk.java.net/browse/JDK-8260378>  https://bugs.openjdk.java.net/browse/JDK-8236859
Webrev: <https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8260378/jdk11/02/webrev/>  http://cr.openjdk.java.net/~yan/8236859/webrev.11.0/

Original change: https://hg.openjdk.java.net/jdk/jdk/rev/ed8e7bf32188



From hedongbo at huawei.com  Tue Feb 23 01:58:24 2021
From: hedongbo at huawei.com (dongbo he)
Date: Tue, 23 Feb 2021 01:58:24 -0000
Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
 AsynchronousCloseException on closed channel
In-Reply-To: <AM4PR02MB31385D539C7C629278296F248A849@AM4PR02MB3138.eurprd02.prod.outlook.com>
References: <8FC616E5EC1A774287430B1CC2696FE30476B3DC@dggeml513-mbs.china.huawei.com>
 <AM4PR02MB31385D539C7C629278296F248A849@AM4PR02MB3138.eurprd02.prod.outlook.com>
Message-ID: <e3ecb814-d183-d750-c757-2e9e04c6e657@huawei.com>

Thank you for your review,? Christoph.

I have added jdk11u-fix-requtest label on? JDK-8246707.


  
Thanks,
dongbohe

? 2/20/2021 2:51 AM, Langer, Christoph ??:
> Hi Dongbohe,
>
> this backport looks good to me. I'll run it once again through SAP's regression testing. In case you don't hear from me by next Monday, you can consider it as reviewed.
>
> Best regards
> Christoph
>
>> -----Original Message-----
>> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
>> Behalf Of hedongbo
>> Sent: Freitag, 19. Februar 2021 08:57
>> To: jdk-updates-dev at openjdk.java.net
>> Subject: RE: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
>> AsynchronousCloseException on closed channel
>>
>> Gentle Ping :-)
>>
>> From: hedongbo
>> Sent: Tuesday, February 9, 2021 9:18 AM
>> To: jdk-updates-dev at openjdk.java.net
>> Subject: FW: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
>> AsynchronousCloseException on closed channel
>>
>> Ping?
>>
>> From: hedongbo
>> Sent: Wednesday, February 3, 2021 5:16 PM
>> To: jdk-updates-dev at openjdk.java.net<mailto:jdk-updates-
>> dev at openjdk.java.net>
>> Subject: [11u] RFR:8246707: (sc) SocketChannel.read/write throws
>> AsynchronousCloseException on closed channel
>>
>>
>> Hi,
>>
>>
>>
>> Please review the backport of JDK-8246707 to 11u:
>>
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8246707
>>
>> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/c8c6030e4d1f
>>
>> 11u webrev: http://cr.openjdk.java.net/~dongbohe/8246707/webrev.00/
>>
>>
>>
>> This patch doesn't apply cleanly but is fairly trivial. The reason is that the
>> latest jdk11u-dev has no ` blockingRead ` and `blockingWriteFully` function,
>> because they were added in jdk13 through JDK-8222774.
>>
>>
>>
>>
>> Tested with tier1, tier2. No regression in tests.
>>
>>
>>
>>
>>
>>